Ben Elliston | 1 Dec 01:32 2006
Picon

PATCH: reorganise SPU crt0 files

The following patch, written by Sa Liu (Cc'ed), reorganises the C
runtime files to move much of the code to libgloss.  I will be
submitting the corresponding patch to libgloss shortly and will not
commit either patch until they are approved by both projects to
minimise bother.  :-)

Okay for the trunk?  [I've just noticed that we need to update the
documentation, so I will work on that now while this patch is being
reviewed.]

Thanks,
Ben

2006-12-01  Sa Liu  <saliu <at> de.ibm.com>

        * config/spu/spu-elf.h (STARTFILE_SPEC): Update.
        (ENDFILE_SPEC): Likewise.
        (INIT_SECTION_ASM_OP): Define, if not already.
        (FINI_SECTION_ASM_OP): Likewise.
        * config/spu/spu.opt (mstdmain): New option.
        * config/spu/crti.asm: Remove.
        * config/spu/crtn.asm: Likewise.
        * config/spu/crt0.c: Likewise.
        * config/spu/crtend.c: Likewise.
        * config/spu/t-spu-elf (EXTRA_MULTILIB_PARTS): Remove crt0 files
        listed above.
        ($(T)crti.o, $(T)crtn.o, $(T)crt1.o, $(T)crtend1.o): Remove.

Index: crti.asm
===================================================================
(Continue reading)

H. J. Lu | 1 Dec 01:42 2006

Re: Ping PATCH: Add SSE3 builtin tests

On Thu, Nov 30, 2006 at 02:53:26PM -0800, Janis Johnson wrote:
> On Thu, Nov 30, 2006 at 02:40:46PM -0800, H. J. Lu wrote:
> > Who can review/approve new SSE3 builtin tests
> > 
> > http://gcc.gnu.org/ml/gcc-patches/2006-10/msg01237.html
> 
> Sorry, I meant to look at this patch long ago.
> 
> I don't know anything about SSE3, but the format of the tests looks fine
> to me.  Unless someone else speaks up, check them into trunk now.  If
> they are apppriate for a branch (4.2?), check them in there after a few
> days if no problems have shown up with them on mainline.

I checked it into mainline. I will check it into 4.2 branch in a few
days if it doesn't cause problems. I will submit a patch for SSSE3
builtin tests later.

Thanks.

H.J.

Andrew_Pinski | 1 Dec 02:03 2006
Picon

Re: PATCH: reorganise SPU crt0 files

pinskia <at> physics.uc.edu wrote on 11/30/2006 04:32:48 PM:

> The following patch, written by Sa Liu (Cc'ed), reorganises the C
> runtime files to move much of the code to libgloss.  I will be
> submitting the corresponding patch to libgloss shortly and will not
> commit either patch until they are approved by both projects to
> minimise bother.  :-)
> 
> Okay for the trunk?  [I've just noticed that we need to update the
> documentation, so I will work on that now while this patch is being
> reviewed.]

I don't see a need for the follow part of the patch:

+#undef INIT_SECTION_ASM_OP
+#define INIT_SECTION_ASM_OP     "\t.section\t\".init\""
+#undef FINI_SECTION_ASM_OP
+#define FINI_SECTION_ASM_OP     "\t.section\t\".fini\""

as INIT_SECTION_ASM_OP/FINI_SECTION_ASM_OP are defined in config/elfos.h:
/* On svr4, we *do* have support for the .init and .fini sections, and we
   can put stuff in there to be executed before and after `main'.  We let
   crtstuff.c and other files know this by defining the following symbols.
   The definitions say how to change sections to the .init and .fini
   sections.  This is the same for all known svr4 assemblers.  */

#define INIT_SECTION_ASM_OP              "\t.section\t.init"
#define FINI_SECTION_ASM_OP              "\t.section\t.fini"

The patch is ok if you remove those two defines.
(Continue reading)

Joseph S. Myers | 1 Dec 02:14 2006

Ping Re: Subregs and objects with holes (new patch)

Ping.  This patch is pending review.

Current version: http://gcc.gnu.org/ml/gcc-patches/2006-11/msg01700.html

Original version and description: 
http://gcc.gnu.org/ml/gcc-patches/2006-11/msg01642.html

(The differences relate to macro naming, comments and documentation, not 
to the substance of the patch.)

--

-- 
Joseph S. Myers
joseph <at> codesourcery.com

Roger Sayle | 1 Dec 01:59 2006

Re: Ping Re: Subregs and objects with holes (new patch)


On Fri, 1 Dec 2006, Joseph S. Myers wrote:
> Current version: http://gcc.gnu.org/ml/gcc-patches/2006-11/msg01700.html
> (The differences relate to macro naming, comments and documentation, not
> to the substance of the patch.)

This OK for mainline.  Thanks.  I assume that David has no further
issues with the E500/PowerPC ABI tweaks, and I do like your approach
of making the whole SUBREGs with holes issue explicit via documented
target macros.

Thanks again to you both.

Roger
--

Daniel Berlin | 1 Dec 03:04 2006

Re: [Bug tree-optimization/29680] [4.3 Regression] Misscompilation of spec2006 gcc

When merging things to branches using svnmerge, please do not commit
it's huge generated changelog as the log message.

It ends up copying things to tons of bug reports.

>

David Edelsohn | 1 Dec 03:04 2006
Picon

Re: Ping Re: Subregs and objects with holes (new patch)

>>>>> Joseph S Myers writes:

Joseph> Ping.  This patch is pending review.
Joseph> Current version: http://gcc.gnu.org/ml/gcc-patches/2006-11/msg01700.html

Joseph> Original version and description: 
Joseph> http://gcc.gnu.org/ml/gcc-patches/2006-11/msg01642.html

Joseph> (The differences relate to macro naming, comments and documentation, not 
Joseph> to the substance of the patch.)

	The rs6000 bits are okay with me.

Thanks, David

Andrew_Pinski | 1 Dec 03:34 2006
Picon

[Committed] Move stuff around to allow for compiling other front-ends for SPU

The problem here is that the SPU back-end uses a couple of C family 
front-end stuff without being in spu-c.c.
This fixes the problem by moving around a couple functions and setting of 
target variables so they only
get referenced by the C front-end or if they need to be referenced by 
generic code moved from spu-c.c to spu.c.

And yes there is missing documention in front of each function, I will fix 
that in my next set of patches.

Committed after a build and test for spu-elf.  Also built the f951 
front-end but 95% of the tests fail because of the
lack of POSIX functions in newlib like dup and access.

Thanks,
Andrew Pinski

ChangeLog:

        * config/spu/spu.c (spu_builtin_range): Move from spu-c.c
        (TARGET_RESOLVE_OVERLOADED_BUILTIN): Delete.
        (spu_cpu_cpp_builtins): Remove.
        (spu_override_options): Don't set warn_main.
        (spu_force_reg): Move from spu-c.c.
        (spu_check_builtin_parm): Likewise.
        (expand_builtin_args): Likewise.
        (spu_expand_builtin_1): Likewise.
        (spu_expand_builtin): Likewise.
        * config/spu/spu.h (REGISTER_TARGET_PRAGMAS): Define, set
        warn_main and targetm.resolve_overloaded_builtin.
(Continue reading)

Dirk Mueller | 1 Dec 04:25 2006
Picon
Picon

PATCH: diagnostic: fix PR c++/19756


Hi, 

I don't quite understand why the implementation in the C frontend is so overly 
complicated, while the simple patch (see below) works as well. 

bootstrapped, regtested on i686-suse-linux. 

Ok for mainline?

Dirk

:ADDPATCH diagnostic:

2006-12-01  Dirk Mueller  <dmueller <at> suse.de>

        PR c++/19756
        * parser.c (cp_parser_selection_statement): Warn for
        ambiguous if/else constructs.

        * invoke.texi (-Wparentheses): Mark it as partially
        supported for C++.

        * g++.dg/warn/Wparentheses-5.C: New testcase.

--- parser.c	(revision 119391)
+++ parser.c	(working copy)
 <at>  <at>  -6531,9 +6531,13  <at>  <at>  cp_parser_selection_statement (cp_parser

 	if (keyword == RID_IF)
(Continue reading)

Mark Mitchell | 1 Dec 08:00 2006

Re: PR middle-end/30017 (ICE in C++ size hook)

Jan Hubicka wrote:

> the attached testcase hits sanity check in C++ frontend after converting:
>             __builtin_memcpy(this,&f,sizeof(FIND_RESULT));
> to an assignment.  The hook cp_expr_size is called when expanding this
> assignment resulting in ICE.  I think the check is just too strict
> and can safely be dropped (as it also mentions that assignment is OK).

That check has been valuable in finding back-end bugs.  The problem is
that asking for the size of an expression is not well-defined in the
presence of C++ virtual bases.  In other words, while "sizeof (C)" is
well-defined in C++ for all "C", that does not mean that given a "C*" it
is safe to copy "sizeof (C)" bytes to/from there!  And, the back end
must never make copies of C++ objects with constructors/assignment
operators since all such copies need to go through the user-defined
functions for copying.

> I wonder why we still need expr_size hook that late in gimple form?

That's my question too.  Why does the backend need the size of
FIND_RESULT at all in this context?

I suspect that we're trying to change:

  __builtin_memcpy(a, b, sizeof (*a))

into:

  *a = *b

(Continue reading)


Gmane