[Bug fortran/51758] ICE with optional arguments of elemental procedures

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51758

Tobias Burnus  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-01-05
 CC||burnus at gcc dot gnu.org
 Ever Confirmed|0   |1

--- Comment #2 from Tobias Burnus  2012-01-05 
08:03:28 UTC ---
Compiles and runs with ifort 12.1.1; compiles but fails at run time with ifort
12.0.5.

Nit: The commented
  ! print *, a
should be 
  ! print *, b

[Bug c++/23383] builtin array operator new is not marked with malloc attribute

[rguenther at suse dot de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23383

--- Comment #19 from rguenther at suse dot de  
2012-01-05 08:39:57 UTC ---
On Wed, 4 Jan 2012, xinliangli at gmail dot com wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23383
> 
> --- Comment #18 from davidxl  2012-01-04 
> 17:11:26 UTC ---
> (In reply to comment #17)
> > On Wed, 4 Jan 2012, xinliangli at gmail dot com wrote:
> > 
> > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23383
> > > 
> > > --- Comment #16 from davidxl  2012-01-04 
> > > 00:28:55 UTC ---
> > > A related topic - aliasing property of realloc -- the malloc attribute is 
> > > not
> > > applied in the glibc header and the comment is like
> > > 
> > > /* __attribute_malloc__ is not used, because if realloc returns
> > >the same pointer that was passed to it, aliasing needs to be allowed
> > >between objects pointed by the old and new pointers.  *
> > > 
> > > 
> > > It is true that the realloc can return an address is physically aliased 
> > > with
> > > the pointer passed to it -- but assuming no-alias by the compiler should 
> > > cause
> > > no harm -- as all code motions/CSEs across the realloc call will not be
> > > possible because realloc may modify/use the memory location.
> > > 
> > > 
> > > Any comment on this? 
> > 
> > The malloc attribute assumes that the contents of the memory pointed
> > to by the return value is undefined, so the comment is inaccurate
> > but the malloc attribute can indeed be not used.
> 
> Which part of the optimizer takes advantage of the 'undefinedness' of returned
> memory?

points-to analysis.  It assumes that the returned blob of memory
points to nothing (yet).  So for

 int i;
 int **p = malloc (8);
 *p = &i;
 int **q = realloc (p, 8);

you'd get that *q points to nothing insteda of i.

> > We can explicitly handle REALLOC in the points-to code to honor the
> > fact that it is not (we do not at the moment).
> 
> ok.

which needs to be fixed here.

Richard.

[Bug c++/51755] -Wconversion generates false warnings when the ternary operator is used

[james.kanze at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51755

--- Comment #2 from James Kanze  2012-01-05 
08:45:22 UTC ---
I'd miss PR 51294.  My report is almost certainly a duplicate of this one.

It's a minor bug, in that it only affects warnings, but it does make
-Wconversion unusable in certain contexts.

[Bug c++/51755] -Wconversion generates false warnings when the ternary operator is used

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51755

Paolo Carlini  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org,
   ||paolo.carlini at oracle dot
   ||com

--- Comment #3 from Paolo Carlini  2012-01-05 
09:29:02 UTC ---
Hi Jason. Looks like people are really unhappy with the -Wconversion warnings
vs the ternary operator, and I'd like to look into these issues in time for
4.7. At the moment I'm confused, however, because I don't understand if the
patch linked by Manuel in PR51294 (maybe we can consolidate these two issues)
was rejected in a unamendable way, or we (I) can start from it and complete the
work. Can you guide me a bit? Thanks...

[Bug bootstrap/51648] [4.7 Regression] Profiledbootstrap failure on x86_64-linux

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51648

--- Comment #15 from Jakub Jelinek  2012-01-05 
09:32:56 UTC ---
Author: jakub
Date: Thu Jan  5 09:32:52 2012
New Revision: 182902

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182902
Log:
PR bootstrap/51648
* tree-cfg.c (need_fake_edge_p): Return true also for noreturn
calls that have any non-fake successor edges.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-cfg.c

[Bug c++/51759] New: miscompile writes past end of bitfield

[nobled at dreamwidth dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51759

 Bug #: 51759
   Summary: miscompile writes past end of bitfield
Classification: Unclassified
   Product: gcc
   Version: 4.5.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: nob...@dreamwidth.org


Compiling the attached preprocessed file with this:
g++-4.5 -Os -fPIC -g -pedantic -Wno-long-long -fno-exceptions -o Type2.cpp.o -c
Type2.ii

Results in writing 32 bits to a 24-bit bitfield, overwriting the first byte of
the next member variable.

These two members of class Type are (on x86_64) at offset 0x8:
  TypeID   ID : 8;
  unsigned SubclassData : 24;

When setSubclassData() isn't inlined, it's called (from StructType::setBody()
and PointerType's constructor) with the address of 'SubclassData' in %rdi...:

   0x776d684f <+71>:lea 0x9(%rdi),%r12
   0x776d6853 <+75>:or $0x1,%esi
   0x776d6856 <+78>:mov %r12,%rdi
   0x776d6859 <+81>:callq 0x776d6774


...but then, setSubclassData writes more than 24 bits to that address:

   0x776d6774 <+0>:mov %esi,%eax
   0x776d6776 <+2>:sub $0x8,%rsp
   0x776d677a <+6>:and $0xff,%eax
   0x776d677f <+11>:cmp %esi,%eax
   0x776d6781 <+13>:mov %eax,(%rdi) # corruption

[Bug c++/51759] miscompile writes past end of bitfield

[nobled at dreamwidth dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51759

--- Comment #1 from nobled at dreamwidth dot org 2012-01-05 09:35:51 UTC ---
Created attachment 26244
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26244
output of `gcc -v -save-temps`

[Bug c++/51759] miscompile writes past end of bitfield

[nobled at dreamwidth dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51759

--- Comment #2 from nobled at dreamwidth dot org 2012-01-05 09:38:45 UTC ---
Created attachment 26245
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26245
pre-processed file (gzip-compressed)

[Bug c++/51757] friend defined inside class and declared inside main linker error

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51757

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #2 from Richard Guenther  2012-01-05 
09:39:28 UTC ---
Hm?  How should it _not_ fail to link?  You declare void func() inside
main which puts it in ::, but there is no definition.  Obviously
A::func() is not found by lookup - why should it?

[Bug gcov-profile/50127] [4.7 regression] g++.dg/tree-prof/partition2.C FAILs on several targets

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50127

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #5 from Jakub Jelinek  2012-01-05 
09:41:13 UTC ---
Can't reproduce on x86_64-linux, nor with cross from that to
i686-sun-solaris2.11 with -m64 and using x86_64-linux bb-reorder.gcda.

[Bug tree-optimization/51759] [4.5 Regression] miscompile writes past end of bitfield

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51759

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Known to work||4.4.6, 4.6.0
   Keywords||wrong-code
   Last reconfirmed||2012-01-05
  Component|c++ |tree-optimization
 CC||jamborm at gcc dot gnu.org
 Ever Confirmed|0   |1
Summary|miscompile writes past end  |[4.5 Regression] miscompile
   |of bitfield |writes past end of bitfield
   Target Milestone|--- |4.5.4

--- Comment #3 from Richard Guenther  2012-01-05 
10:00:37 UTC ---
It's a bug in IPA-SRA that creates non-mode-size stores:

void llvm::Type::_ZN4llvm4Type15setSubclassDataEj.clone.1(unsigned int:24*,
unsigned int) ( * ISRA.6, unsigned int val)
{
...
:
  D.87358_2 = () val_1(D);
  *ISRA.6_8(D) = D.87358_2;

I think this has been fixed in 4.6 (not on the 4.5 branch though) which
no longer performs this substitution.  You can work around this using
-fno-ipa-sra.

The following is a simplified testcase:

extern "C" void abort (void);
struct S
{
  void __attribute__((noinline)) set(unsigned val)
{
  data = val;
  if (data != val)
abort ();
}
  int pad0;
  unsigned pad1 : 8;
  unsigned data : 24;
  int pad2;
};
int main()
{
  S s;
  s.pad2 = -1;
  s.set(0);
  if (s.pad2 != -1)
abort ();
}

Where 4.6 says:

Candidate (2069): this
! Disqualifying this - Encountered a bit-field access.

which hints at what needs backporting.

Martin?

[Bug c++/51757] friend defined inside class and declared inside main linker error

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51757

Jonathan Wakely  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
   Last reconfirmed||2012-01-05
 Resolution|INVALID |
 Ever Confirmed|0   |1

--- Comment #3 from Jonathan Wakely  2012-01-05 
10:35:56 UTC ---
There is no A::func, that's a friend not a member function. 

[class.friend]

-6-  A function can be defined in a friend declaration of a class if and only
if the class is a non-local class (9.8), the function name is unqualified, and
the function has namespace scope. [ Example:
class M {
  friend void f() { } // definition of global f, a friend of M,
  // not the definition of a member function
};
—end example ]
-7- Such a function is implicitly inline. A friend function defined in a class
is in the (lexical) scope of the class in which it is defined. A friend
function defined outside the class is not (3.4.1).

[Bug c++/51757] friend defined inside class and declared inside main linker error

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51757

--- Comment #4 from Jonathan Wakely  2012-01-05 
10:42:56 UTC ---
Also, if there's no definition, why would it link when -fkeep-inline-functions
is used?  My guess would be that the call in main doesn't mark the inline
function as used, so it is not emitted.

For the record, Solaris CC fails in the same way, it links OK with clang++

[Bug fortran/51638] gfortran optimization breaks a single variable used as both input and output for subroutine call

[bardeau at iram dot fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51638

--- Comment #6 from Sebastien Bardeau  2012-01-05 
10:43:52 UTC ---
Dear all,

(In reply to comment #4)
> Your
> Fortran code is invalid.  We have a clear diagnostic.
> The bug is in your code not the Fortran compiler.

This code is like it is since its first commit on 11-Jun-93 under our CVS
repository. And it is probably much older. It has been used since that time
under many systems (VAX, HP-UX, Sun, OSF, AIX, Linux, MS Windows at least) and
compiled by many compilers (ifc/ifort, g95, xlf, lf95, pgf90, etc). All this
without any problem.

If you look twice at this code you will see it does nothing clever: it just
assumes (!) that an INTEGER*4 is 4 bytes aligned. Then it swaps these 4 bytes
by using a local copy

I still do think there is a problem with gfortran, because 1) it is the only
one which breaks this simple code regarding our 25 years experience, and 2)
because it randomly breaks it depending on the architecture and options.


(In reply to comment #5)
> The issue is essentially that GCC will optimize in
> 
> subroutine iei4ei(inpu,oupu)
>   inte(:) = inpu(:)
>   oupu(4) = inte(1)
>   oupu(3) = inte(2)
>   oupu(2) = inte(3)
>   oupu(1) = inte(4)
> 
> the "inte" away, which is perfectly valid as "inpu" and "outu" may not point 
> to
> the same memory.

Ok at least the diagnostic is clear.


> To be more precise (cf. -fdump-tree-optimized), instead of (-O0):
>   MEM[(c_char * {ref-all})&inte] = MEM[(c_char * {ref-all})inpu_1(D)];
>   D.1820_2 = inte[0];
>   *oupu_3(D)[3] = D.1820_2;
>   ...
> the compiler generates (-O2, -O3):
>   inte$0_14 = MEM[(c_char * {ref-all})inpu_1(D)];
>   inte$1_15 = MEM[(c_char * {ref-all})inpu_1(D) + 1B];
>   ...
>   *oupu_3(D)[3] = inte$0_14;
>   ...
> and depending on the assembler generation (order, register usage), this will
> work or not. Seemingly, on i386 the generated assembler will break your 
> program
> while it happens to work on x86-64.
> 
> This optimization is perfectly valid according the Fortran standard and speeds
> valid programs. I am sure that other compilers do the same, though whether it
> will break your program depends on the generated assembler code. I wouldn't be
> surprised if the program also breaks with other compilers with some compiler
> flag or a slightly different compiler version.

We have never observed this behavior anywhere else for the past 25 years. I
won't be so confident that the other compilers perform the same optimization
(at least at level O1), exactly because of all the Fortran 66/77 legacy code
the Fortran community uses...


> This "breakage" happens in principle for all optimization levels (-O1, -O2,
> ...). However, if "iei8ei"/"iei4ei" and "program gfortran_debug" are in the
> same file, inlining and other optimizations happen such that the program
> happens to work by chance for -O2/-O3.
> 
> 
> Work-around solutions: Use -O0
Well, we do want a first (i.e. considered as safe) level of optimization...


> or make "inte" VOLATILE.
This seems an interesting path. I am just wondering about computing efficiency
then, but since this avoids making copies out or in the subroutine, this might
be the solution.


> [The program is then
> still formally wrong, but should work.]
> 
> 
> The better change is to change the call to:
>   call iei4ei((in4),in4)
>   call iei8ei((in8),in8)
> That will force the generation of a temporary variable in the caller, which
> makes this part of the program valid.

We definitely want to avoid this kind of requirement when calling subroutines,
this is error prone. If we have to work with a copy, the ideal would be to
factorize it in the subroutine, which is already done...


> (You still have the issue of passing an
> INTEGER(4) to an INTEGER(1)

This subroutine is part of our low-level set of subroutines (here: IEEE <->
EEEI byte swapping), which have to be as simple and efficient as possible (they
can be used on large amount of data). Fortran 77 is pretty well suited for
this.


> and misuse of EQUIVALENCE.)
EQUIVALENCE was just used for the debugging messages, it is not used in our
real code.


> (The "()" seems to be enough to fix the program; I don't know why it didn't
> seem to fix the issue when I wrote comment 1.)
> 
> 
> Alternatively, you can add to both arguments of "iei4ei" and "iei8ei" the
> TARGET attribute - in that case the compiler knows that the arguments may be
> storage associated each other. However, Fortran then requires an explicit
> interface. (This will be difficult as you pass an integer(kind=4) to an
> integer(kind=1), which is invalid.)

Indeed, we can not use explicit interfaces in this context.

[Bug tree-optimization/51760] New: [4.7 Regression] ICE in set_lattice_value, at tree-ssa-ccp.c:456

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51760

 Bug #: 51760
   Summary: [4.7 Regression] ICE in set_lattice_value, at
tree-ssa-ccp.c:456
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: rgue...@gcc.gnu.org
Target: x86_64-*-*, i?86-*-*


Building coreutils reveals

> ./cc1 -quiet expand.i -O -m32
expand.c: In function 'expand_multibyte':
expand.c:591:1: internal compiler error: in set_lattice_value, at
tree-ssa-ccp.c:456
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug tree-optimization/51760] [4.7 Regression] ICE in set_lattice_value, at tree-ssa-ccp.c:456

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51760

--- Comment #1 from Richard Guenther  2012-01-05 
10:54:42 UTC ---
Created attachment 26246
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26246
preprocessed source

[Bug tree-optimization/51760] [4.7 Regression] ICE in set_lattice_value, at tree-ssa-ccp.c:456

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51760

Richard Guenther  changed:

   What|Removed |Added

   Target Milestone|--- |4.7.0

[Bug middle-end/51761] New: [4.7 Regression] ICE in verify_gimple_stmt, at tree-cfg.c:4241

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51761

 Bug #: 51761
   Summary: [4.7 Regression] ICE in verify_gimple_stmt, at
tree-cfg.c:4241
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: rgue...@gcc.gnu.org
CC: m...@gcc.gnu.org
Target: i?86-*-*


Created attachment 26247
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26247
preprocessed source

Building strongswan reveals:

> ./cc1 -quiet chunk.i -O -m32
chunk.c: In function 'chunk_printable':
chunk.c:558:7: internal compiler error: in verify_gimple_stmt, at
tree-cfg.c:4314
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

#1  0x00b57d26 in verify_gimple_stmt (stmt=0x758bbf28)
at /space/rguenther/src/svn/trunk/gcc/tree-cfg.c:4314
4314  gcc_unreachable ();
(gdb) call debug_gimple_stmt (stmt)
<<< Unknown GIMPLE statement: gimple_with_cleanup_expr >>>

[Bug middle-end/51761] [4.7 Regression] ICE in verify_gimple_stmt, at tree-cfg.c:4241

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51761

Richard Guenther  changed:

   What|Removed |Added

   Target Milestone|--- |4.7.0

[Bug debug/51762] [4.7 Regression] ICE in maybe_record_trace_start, at dwarf2cfi.c:2231

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51762

Richard Guenther  changed:

   What|Removed |Added

   Target Milestone|--- |4.7.0

[Bug debug/51762] New: [4.7 Regression] ICE in maybe_record_trace_start, at dwarf2cfi.c:2231

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51762

 Bug #: 51762
   Summary: [4.7 Regression] ICE in maybe_record_trace_start, at
dwarf2cfi.c:2231
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: debug
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: rgue...@gcc.gnu.org
Target: i?86-*-*


Created attachment 26248
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26248
preprocessed source

Building trustedgrub reveals:

> ./cc1 -quiet -m32 stage1_5.i -g -Os -fomit-frame-pointer  
> -fno-asynchronous-unwind-tables
stage1_5.c: In function 'cmain':
stage1_5.c:69:1: internal compiler error: in maybe_record_trace_start, at
dwarf2cfi.c:2231
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug middle-end/51761] [4.7 Regression] ICE in verify_gimple_stmt, at tree-cfg.c:4241

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51761

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-01-05
 CC||jakub at gcc dot gnu.org
 Ever Confirmed|0   |1

--- Comment #1 from Jakub Jelinek  2012-01-05 
11:08:25 UTC ---
Started with http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=181332
Reducing...

[Bug tree-optimization/51760] [4.7 Regression] ICE in set_lattice_value, at tree-ssa-ccp.c:456

[markus at trippelsdorf dot de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51760

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||markus at trippelsdorf dot
   ||de

--- Comment #2 from Markus Trippelsdorf  
2012-01-05 11:10:46 UTC ---
 typedef size_t;
__attribute__ ( ( __always_inline__ ) ) memmove ( void *__dest, void *__src,
  size_t __len )
{
  return __builtin___memmove_chk ( __dest, __src, 0, __builtin_object_size );
}

expand_multibyte (  )
{
  int buf[0];
  int *bufpos;

  for ( ;; )
{
  memmove ( buf, bufpos, 0 );
  bufpos = buf;
}
}

[Bug middle-end/51761] [4.7 Regression] ICE in verify_gimple_stmt, at tree-cfg.c:4241

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51761

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  2012-01-05 
11:21:38 UTC ---
Reduced testcase (-O -m32):

struct S { unsigned int len; };
struct S foo (struct S);

struct S
bar (struct S x)
{
  return ({ struct S a = x; foo (a); });
}

The C FE isn't inserting CLEANUP_POINT_EXPRs everywhere, so I wonder if the
r181332 change to add the clobber must not be limited to C++ or if e.g.
gimplify_cleanup_point_expr shouldn't set some (new) flag in *gimplify_ctxp for
the duration of the embedded gimplify_stmt call (and restore it from previous
value afterwards) and use this flag to decide whether to add the cleanup or
not.

[Bug tree-optimization/51760] [4.7 Regression] ICE in set_lattice_value, at tree-ssa-ccp.c:456

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51760

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-01-05
 CC||jakub at gcc dot gnu.org
 Ever Confirmed|0   |1

--- Comment #3 from Jakub Jelinek  2012-01-05 
11:33:03 UTC ---
That reduced testcase is quite questionable.

Anyway, this started with
http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=177615

[Bug tree-optimization/51760] [4.7 Regression] ICE in set_lattice_value, at tree-ssa-ccp.c:456

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51760

--- Comment #4 from Jakub Jelinek  2012-01-05 
11:41:56 UTC ---
Reduced testcase:

extern inline __attribute__ ((always_inline)) void *
memmove (void *dest, const void *src, __SIZE_TYPE__ len)
{
  return __builtin___memmove_chk (dest, src, len, __builtin_object_size (dest,
0));
}

void
foo (void)
{
  char a[64], *b;
  for (;;)
{
  memmove (a, b, 0);
  b = a;
}
}

[Bug tree-optimization/51760] [4.7 Regression] ICE in set_lattice_value, at tree-ssa-ccp.c:456

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51760

--- Comment #5 from Richard Guenther  2012-01-05 
11:48:28 UTC ---
This is because likely_value says VARYING for __builtin___memmove_chk (&a, b_1,
0, D.1724_7) if b_1 is not already CONSTANT.  But we evaluate it with

/* These builtins return their first argument, unmodified.  */
case BUILT_IN_MEMCPY:
case BUILT_IN_MEMMOVE:

anyway, so likely_value should return CONSTANT if the first arg of these
builtins is constant.

[Bug tree-optimization/51760] [4.7 Regression] ICE in set_lattice_value, at tree-ssa-ccp.c:456

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51760

--- Comment #6 from Richard Guenther  2012-01-05 
11:49:06 UTC ---
Or simply return CONSTANT for all builtins.

[Bug middle-end/51761] [4.7 Regression] ICE in verify_gimple_stmt, at tree-cfg.c:4241

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51761

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 AssignedTo|unassigned at gcc dot   |jakub at gcc dot gnu.org
   |gnu.org |

--- Comment #3 from Jakub Jelinek  2012-01-05 
12:02:13 UTC ---
Created attachment 26249
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26249
gcc47-pr51761.patch

Untested fix.  With the exception of C++/Obj-C++ FEs I'm afraid other FEs don't
add all the needed CPEs.

[Bug tree-optimization/51760] [4.7 Regression] ICE in set_lattice_value, at tree-ssa-ccp.c:456

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51760

Richard Guenther  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 AssignedTo|unassigned at gcc dot   |rguenth at gcc dot gnu.org
   |gnu.org |

--- Comment #7 from Richard Guenther  2012-01-05 
12:04:24 UTC ---
I have a patch.

[Bug c++/51763] New: SEVERE ERROR: Symbol C_BSTAT

[bhatia.sandip at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51763

 Bug #: 51763
   Summary: SEVERE ERROR: Symbol C_BSTAT
Classification: Unclassified
   Product: gcc
   Version: 3.3.2
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bhatia.san...@gmail.com


Hi All

We are upgrading our Apache web server from 1.3.34 to 2.0.59 on AIX 5.3.

We are using the GCC 3.3.2.

We are getting error durig "make"

>> make
.
.
.

Target "local-all" is up to date.
Target "all" is up to date.
/bin/sh /sapinstall/httpd-2.0.59/srclib/apr/libtool --silent --mode=link gcc -g
-O2 -pthread -DHAVE_CONFIG_H -U__STR__ -D_THREAD_SAFE -D_USE_IRS -I./include
-I../include -version-info 9:12:9 -Wl,-brtl -o libapr-0.la -rpath
/app/apache/csd/csdcs/lib strings/apr_cpystrn.lo strings/apr_fnmatch.lo
strings/apr_snprintf.lo strings/apr_strings.lo strings/apr_strnatcmp.lo
strings/apr_strtok.lo passwd/apr_getpass.lo tables/apr_hash.lo
tables/apr_tables.lo file_io/unix/copy.lo file_io/unix/dir.lo
file_io/unix/fileacc.lo file_io/unix/filedup.lo file_io/unix/filepath.lo
file_io/unix/filepath_util.lo file_io/unix/filestat.lo file_io/unix/flock.lo
file_io/unix/fullrw.lo file_io/unix/mktemp.lo file_io/unix/open.lo
file_io/unix/pipe.lo file_io/unix/readwrite.lo file_io/unix/seek.lo
file_io/unix/tempdir.lo network_io/unix/inet_ntop.lo
network_io/unix/inet_pton.lo network_io/unix/sendrecv.lo
network_io/unix/sockaddr.lo network_io/unix/sockets.lo
network_io/unix/sockopt.lo threadproc/unix/proc.lo threadproc/unix/procsup.lo
threadproc/unix/signals.lo threadproc/unix/thread.lo
threadproc/unix/threadpriv.lo misc/unix/charset.lo misc/unix/env.lo
misc/unix/errorcodes.lo misc/unix/getopt.lo misc/unix/otherchild.lo
misc/unix/rand.lo misc/unix/start.lo misc/unix/version.lo
locks/unix/global_mutex.lo locks/unix/proc_mutex.lo locks/unix/thread_cond.lo
locks/unix/thread_mutex.lo locks/unix/thread_rwlock.lo time/unix/time.lo
time/unix/timestr.lo mmap/unix/common.lo mmap/unix/mmap.lo shmem/unix/shm.lo
user/unix/groupinfo.lo user/unix/userinfo.lo memory/unix/apr_pools.lo
atomic/unix/apr_atomic.lo poll/unix/poll.lo poll/unix/pollacc.lo
support/unix/waitio.lo dso/unix/dso.lo -lm -lnsl -lpthread
ld: 0711-593 SEVERE ERROR: Symbol C_BSTAT (entry 859) in object
network_io/unix/.libs/sendrecv.o:
The symbol refers to a csect with symbol number 0, which was not
found. The new symbol cannot be associated with a csect and
is being ignored.
ld: 0711-593 SEVERE ERROR: Symbol C_BSTAT (entry 841) in object
threadproc/unix/.libs/signals.o:
The symbol refers to a csect with symbol number 0, which was not
found. The new symbol cannot be associated with a csect and
is being ignored.
ld: 0711-593 SEVERE ERROR: Symbol C_BSTAT (entry 1356) in object
locks/unix/.libs/proc_mutex.o:
The symbol refers to a csect with symbol number 0, which was not
found. The new symbol cannot be associated with a csect and
is being ignored.
ld: 0711-593 SEVERE ERROR: Symbol C_BSTAT (entry 1359) in object
locks/unix/.libs/proc_mutex.o:
The symbol refers to a csect with symbol number 0, which was not
found. The new symbol cannot be associated with a csect and
is being ignored.
ld: 0711-593 SEVERE ERROR: Symbol C_BSTAT (entry 1362) in object
locks/unix/.libs/proc_mutex.o:
The symbol refers to a csect with symbol number 0, which was not
found. The new symbol cannot be associated with a csect and
is being ignored.
ld: 0711-593 SEVERE ERROR: Symbol C_BSTAT (entry 1365) in object
locks/unix/.libs/proc_mutex.o:
The symbol refers to a csect with symbol number 0, which was not
found. The new symbol cannot be associated with a csect and
is being ignored.
ld: 0711-593 SEVERE ERROR: Symbol C_BSTAT (entry 960) in object
time/unix/.libs/time.o:
The symbol refers to a csect with symbol number 0, which was not
found. The new symbol cannot be associated with a csect and
is being ignored.
ld: 0711-593 SEVERE ERROR: Symbol C_BSTAT (entry 481) in object
atomic/unix/.libs/apr_atomic.o:
The symbol refers to a csect with symbol number 0, which was not
found. The new symbol cannot be associated with a csect and
is being ignored.
collect2: ld returned 12 exit status
make: 1254-004 The error code from the last command is 1.


Stop.
make: 1254-004 The error code from the last command is 1.


Stop.
make: 1254-004 The error code from the last command is 1.


Stop.
make: 1254-004 The error code from the last command is 1.


Stop.

We are getting the error.

Regards,
Sandeep

[Bug debug/51762] [4.7 Regression] ICE in maybe_record_trace_start, at dwarf2cfi.c:2231

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51762

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-01-05
 CC||jakub at gcc dot gnu.org,
   ||rth at gcc dot gnu.org
 Ever Confirmed|0   |1

--- Comment #1 from Jakub Jelinek  2012-01-05 
12:30:17 UTC ---
/* PR debug/51762 */
/* { dg-do compile } */
/* { dg-options "-g -Os -fomit-frame-pointer -fno-asynchronous-unwind-tables" }
*/

void noret (void) __attribute__ ((noreturn));
int bar (void);
void baz (const char *);
static int v = -1;

void
foo (void)
{
  if (bar () && v == -1)
{
  baz ("baz");
  noret ();
}
  noret ();
}

Started with
http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=176705

[Bug c++/51763] SEVERE ERROR: Symbol C_BSTAT

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51763

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2012-01-05
 Ever Confirmed|0   |1

--- Comment #1 from Jonathan Wakely  2012-01-05 
12:38:37 UTC ---
Please read http://gcc.gnu.org/bugs/

You should try a more recent version of GCC and provide the requested
information if the problem persists. GCC 3.3.2 hasn't been maintained for
several years, and 'ld' is not part of GCC anyway.

[Bug debug/51762] [4.7 Regression] ICE in maybe_record_trace_start, at dwarf2cfi.c:2231

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51762

--- Comment #2 from Jakub Jelinek  2012-01-05 
12:58:11 UTC ---
Seems cross-jumping during csa pass cross-jumps the two noret calls, eventhough
they have different args size depths.

[Bug lto/41576] LTO complains about mismatches in common sections

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41576

--- Comment #4 from Richard Guenther  2012-01-05 
13:28:37 UTC ---
Author: rguenth
Date: Thu Jan  5 13:28:34 2012
New Revision: 182907

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182907
Log:
2012-01-05  Richard Guenther  

PR lto/41576
* gfortran.dg/lto/pr41576_0.f90: New testcase.
* gfortran.dg/lto/pr41576_1.f90: Likewise.

Added:
trunk/gcc/testsuite/gfortran.dg/lto/pr41576_0.f90
trunk/gcc/testsuite/gfortran.dg/lto/pr41576_1.f90
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug lto/41576] LTO complains about mismatches in common sections

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41576

Richard Guenther  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.6.0

--- Comment #5 from Richard Guenther  2012-01-05 
13:29:02 UTC ---
This was fixed for 4.6.

[Bug middle-end/51472] ICE: verify_gimple failed: invalid rhs for gimple memory store with -fgnu-tm --param tm-max-aggregate-size=32

[aldyh at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51472

--- Comment #9 from Aldy Hernandez  2012-01-05 
13:36:37 UTC ---
Author: aldyh
Date: Thu Jan  5 13:36:32 2012
New Revision: 182908

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182908
Log:
PR middle-end/51472
* trans-mem.c (expand_assign_tm): Handle TM_MEMMOVE loads correctly.
testsuite/
PR middle-end/51472
* gcc.dg/tm/memopt-6.c: Adjust regexp.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/tm/memopt-6.c
trunk/gcc/trans-mem.c

[Bug fortran/41227] COMMON block, BIND(C) and LTO interoperability issues

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41227

--- Comment #9 from Richard Guenther  2012-01-05 
13:37:09 UTC ---
This is still not fixed (at least by design -
bind_c_coms.f90/bind_c_coms_driver.c
passes with -flto now).  Can somebody produce a reduced testcase pair that
just has a bind-C named common with a single int so I can experiment a bit?

Thx.

[Bug middle-end/51472] ICE: verify_gimple failed: invalid rhs for gimple memory store with -fgnu-tm --param tm-max-aggregate-size=32

[aldyh at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51472

Aldy Hernandez  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #10 from Aldy Hernandez  2012-01-05 
13:38:00 UTC ---
fixed on trunk

[Bug tree-optimization/51759] [4.5 Regression] miscompile writes past end of bitfield

[jamborm at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51759

Martin Jambor  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 AssignedTo|unassigned at gcc dot   |jamborm at gcc dot gnu.org
   |gnu.org |

--- Comment #4 from Martin Jambor  2012-01-05 
13:39:22 UTC ---
(In reply to comment #3)
> Where 4.6 says:
> 
> Candidate (2069): this
> ! Disqualifying this - Encountered a bit-field access.
> 
> which hints at what needs backporting.
> 
> Martin?

Right, this seems to be PR 45644, for some reason I did not backport
the fix to 4.5.  It should be fixed by committing 
http://gcc.gnu.org/viewcvs?view=revision&revision=164313
I'll do the backport and test it today.

[Bug tree-optimization/51760] [4.7 Regression] ICE in set_lattice_value, at tree-ssa-ccp.c:456

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51760

--- Comment #8 from Richard Guenther  2012-01-05 
13:41:38 UTC ---
Author: rguenth
Date: Thu Jan  5 13:41:34 2012
New Revision: 182909

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182909
Log:
2012-01-05  Richard Guenther  

PR tree-optimization/51760
* tree-ssa-ccp.c (likely_value): Drop UNDEFINED to CONSTANT,
not VARYING.
(bit_value_unop): Handle UNDEFINED operands.
(bit_value_binop): Likewise.

* gcc.dg/torture/pr51760.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr51760.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-ccp.c

[Bug target/51685] FAIL: gcc.dg/tm/pr51472.c (internal compiler error) on ppc*-*-*, s390*-*-*, spu-*-*

[aldyh at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51685

Aldy Hernandez  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE

--- Comment #2 from Aldy Hernandez  2012-01-05 
13:41:15 UTC ---
fixed on trunk

*** This bug has been marked as a duplicate of bug 51472 ***

[Bug tree-optimization/51760] [4.7 Regression] ICE in set_lattice_value, at tree-ssa-ccp.c:456

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51760

Richard Guenther  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #9 from Richard Guenther  2012-01-05 
13:41:50 UTC ---
Fixed.

[Bug middle-end/51472] ICE: verify_gimple failed: invalid rhs for gimple memory store with -fgnu-tm --param tm-max-aggregate-size=32

[aldyh at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51472

Aldy Hernandez  changed:

   What|Removed |Added

 CC||dominiq at lps dot ens.fr

--- Comment #11 from Aldy Hernandez  2012-01-05 
13:41:15 UTC ---
*** Bug 51685 has been marked as a duplicate of this bug. ***

[Bug middle-end/51764] New: mudflap does not work with LTO

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51764

 Bug #: 51764
   Summary: mudflap does not work with LTO
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: rgue...@gcc.gnu.org


lto1 is not linked with tree-mudflap.o but with tree-nomudflap.o which causes
us to ICE when you combine -flto and -fmudflap.

Even if you fix that we ICE because the 2nd stage of mudflap depends on
state set up by the 1st stage which runs in different contexts (link-time
vs. compile-time).  So to work with LTO this state would need to be streamed
and combined.

Instead of ICEing we should sorry () for the -flto -fmudflap combination
already at compile-time and reject -fmudflap at link-time (why is that
a common.opt flag anyway when it only applies to a subset of all languages?)

[Bug c++/29615] Class can't be friend of itself?

[jason at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29615

Jason Merrill  changed:

   What|Removed |Added

  Known to work||4.4.6
   Target Milestone|--- |4.4.0

--- Comment #10 from Jason Merrill  2012-01-05 
14:01:02 UTC ---
This seems to have been fixed in 4.4.

[Bug middle-end/51761] [4.7 Regression] ICE in verify_gimple_stmt, at tree-cfg.c:4241

[jason at redhat dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51761

--- Comment #4 from Jason Merrill  2012-01-05 14:03:22 
UTC ---
OK.

Jason

[Bug c++/51755] -Wconversion generates false warnings when the ternary operator is used

[jason at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51755

--- Comment #4 from Jason Merrill  2012-01-05 
14:11:19 UTC ---
(In reply to comment #3)
> At the moment I'm confused, however, because I don't understand if the
> patch linked by Manuel in PR51294 (maybe we can consolidate these two issues)
> was rejected in a unamendable way, or we (I) can start from it and complete 
> the
> work. Can you guide me a bit? Thanks...

I'm not the one who rejected it, so I don't know what Joseph's thinking is; I'd
suggest responding to his mail.

[Bug other/51171] XFAIL: libitm.c/reentrant.c execution test

[aldyh at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51171

--- Comment #1 from Aldy Hernandez  2012-01-05 
14:14:34 UTC ---
Author: aldyh
Date: Thu Jan  5 14:14:29 2012
New Revision: 182911

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182911
Log:
PR other/51171
* testsuite/libitm.c/reentrant.c: Remove xfail.
(thread): Pass x to pure().


Modified:
trunk/libitm/ChangeLog
trunk/libitm/testsuite/libitm.c/reentrant.c

[Bug other/51171] XFAIL: libitm.c/reentrant.c execution test

[aldyh at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51171

Aldy Hernandez  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #2 from Aldy Hernandez  2012-01-05 
14:15:35 UTC ---
fixed on trunk

[Bug fortran/51638] gfortran optimization breaks a single variable used as both input and output for subroutine call

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51638

--- Comment #7 from Tobias Burnus  2012-01-05 
14:26:25 UTC ---
(In reply to comment #6)
> > Fortran code is invalid.
> This code is like it is since its first commit on 11-Jun-93

This does not mean that was and/or is valid. Newer compilers tend to optimize
more aggressively than older.


> I still do think there is a problem with gfortran, because 1) it is the only
> one which breaks this simple code regarding our 25 years experience, and 2)
> because it randomly breaks it depending on the architecture and options.

Well, as long as there is no valid program which breaks, I believe that
gfortran does not have a bug (with regards to the this problem report).

In particular, as Steve quoted in comment 2 the 12.4.1.7 guarantees that
nontarget/nonpointer arguments either do not alias or are not modified. With
this in mind, let's look at the generated assembler (compile with "-S" to
generate the assembler file).

If one looks at the assembler for

subroutine iei4ei(inpu,oupu)
  integer(kind=1) :: inpu(4)
  integer(kind=1) :: oupu(4)
  integer(kind=1) :: inte(4)
  inte(:) = inpu(:)
  oupu(4) = inte(1)
  oupu(3) = inte(2)
  oupu(2) = inte(3)
  oupu(1) = inte(4)
end subroutine iei4ei

one gets with -O1 the following (i386-Linux):

.LFB0:
subl$8, %esp ! Make space on the stack for 8 byte
.LCFI0:
movl%ebx, (%esp)   ! Save %ebx register on the stack
movl%esi, 4(%esp)  ! Save %esi register on the stack
.LCFI1:
movl12(%esp), %esi ! %esi = addr of inpu
movl16(%esp), %ebx ! %ebx = addr of outpu
movzbl1(%esi), %ecx  ! %ecx = inpu(2)  ! (zero-extended load)
movzbl2(%esi), %edx  ! %edx = inpu(3)  ! (zero-extended load)
movzbl3(%esi), %eax  ! %ecx = inpu(4)  ! (zero-extended load)
movb%al, (%ebx)! outpu(1) = inpu(4) ! al == lowest byte of eax
movzbl(%esi), %eax   ! %eax = inpu(1)
movb%al, 3(%ebx)   ! outpu(4) = inpu(1)
movb%cl, 2(%ebx)   ! outpu(3) = inpu(2)
movb%dl, 1(%ebx)   ! outpu(2) = inpu(3)
movl(%esp), %ebx  ! Restore ebx register
movl4(%esp), %esi ! Restore esi register
addl$8, %esp  ! Free the allocated stack
.LCFI2:
ret   ! Return


With x86-64-Linux, the assembler is as follows (again with -O1):

.LFB0:
movzbl  1(%rdi), %ecx  ! ecx = inpu(2)
movzbl  2(%rdi), %edx  ! edx = inpu(3)
movzbl  3(%rdi), %eax  ! eax = inpu(4)
movzbl  (%rdi), %edi   ! edi = inpu(1)
movb%dil, 3(%rsi)  ! outpu(4) = inpu(3)
movb%cl, 2(%rsi)   ! outpu(3) = inpu(2)
movb%dl, 1(%rsi)   ! outpu(2) = inpu(3)
movb%al, (%rsi)! outpu(1) = inpu(4)
ret

Thus, it is not surprising that it works with x86-64-Linux and that it fails
with i386-Linux. However, both assembler outputs look perfectly valid - only
that the second version also works if the arguments alias while the first one
does not.


For completeness, ifort 11.1 (ia32) generates with -O2 the code:

pushl %edi ! Save %edi on the stack
pushl %esi ! Save %eds on the stack
pushl %ebx ! Save %ebx on the stack
movl  16(%esp), %eax  ! eax = inpu
movl  20(%esp), %esi  ! esi = outpu
movzbl(%eax), %edx! edx = inpu(1)
movzbl1(%eax), %ecx   ! ecx = inpu(2)
movzbl2(%eax), %ebx   ! ebx = inpu(3)
movzbl3(%eax), %eax   ! eax = inpu(4)
movb  %dl, iei4ei_$INTE.0.1   ! inte(1) = dl(1)
movb  %al, (%esi) ! outpu(1) = inpu(4)
movb  %cl, 1+iei4ei_$INTE.0.1 ! inte(2) = dl(2)
movb  %dl, 3(%esi)! outpu(4) = inpu(1)
movb  %cl, 2(%esi)! outpu(3) = inpu(2)
movb  %bl, 2+iei4ei_$INTE.0.1 ! inte(3) = dl(3)
movb  %al, 3+iei4ei_$INTE.0.1 ! inte(4) = dl(4)
movb  %bl, 1(%esi) ! outpu(2) = inpu(3)
popl  %ebx ! Restore %ebx
popl  %esi ! Restore %esi
popl  %edi ! Restore %edi
ret! Return


Thus, in principle ICC does the same, except that it the generated assembler is
slightly differed such that it works without running into the alias issues.
(I wonder why "ifort" does not optimize the "inte = inpu" away as it is never
used in the assembler.)


> We have never observed this behavior anywhere else for the past 25 years. I
> won't be so confident that the other compilers perform the same optimization
> (at least at level O1), exactly because of all the Fortran 66/77 legacy code
> the Fortran community uses...

I think any well-optimizing compiler takes into account that any pair of
nontarget, nonpointer arguments do not alias (if one of them gets modified).
The C equivalent is that the pointer arguments have the

[Bug middle-end/51752] trans-mem: publication safety violated

[aldyh at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51752

--- Comment #1 from Aldy Hernandez  2012-01-05 
14:30:15 UTC ---
Ok, I'm a complete neophyte on this, but that seems very restrictive.  Does
that mean that basically we can't hoist any loads inside a transaction...ever?

  __transaction_atomic
{
  for (i = 0; i < 10; i++)
if (x[i])
  x[i] += data;
}

[Bug fortran/50981] [4.4/4.5/4.6 Regression] Wrong-code for scalarizing ELEMENTAL call with absent OPTIONAL argument

[mikael at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50981

--- Comment #10 from Mikael Morin  2012-01-05 
14:50:38 UTC ---
Created attachment 26250
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26250
Another failing variant, with allocatables

This is not fixed by the patch above.

[Bug fortran/50981] [4.4/4.5/4.6 Regression] Wrong-code for scalarizing ELEMENTAL call with absent OPTIONAL argument

[mikael at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50981

--- Comment #11 from Mikael Morin  2012-01-05 
14:51:26 UTC ---
Created attachment 26252
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26252
Another failing variant, with pointers

This is not fixed by the patch above.

[Bug lto/51765] New: Testsuite ICEs with -flto

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51765

 Bug #: 51765
   Summary: Testsuite ICEs with -flto
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: rgue...@gcc.gnu.org


Created attachment 26251
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26251
full testsuite summary

Currently we ICE compiling the following tests on x86_64 when running the
testsuite with RUNTESTFLAGS="--target_board=unix/-flto"

FAIL: g++.dg/tm/pr45940-3.C -std=gnu++98 (internal compiler error)
FAIL: g++.dg/tm/pr45940-3.C -std=gnu++98 (test for excess errors)
FAIL: g++.dg/tm/pr45940-3.C -std=gnu++11 (internal compiler error)
FAIL: g++.dg/tm/pr45940-3.C -std=gnu++11 (test for excess errors)
FAIL: g++.dg/tm/pr45940-4.C -std=gnu++98 (internal compiler error)
FAIL: g++.dg/tm/pr45940-4.C -std=gnu++98 (test for excess errors)
FAIL: g++.dg/tm/pr45940-4.C -std=gnu++11 (internal compiler error)
FAIL: g++.dg/tm/pr45940-4.C -std=gnu++11 (test for excess errors)

FAIL: gcc.dg/O16384.c (internal compiler error)
FAIL: gcc.dg/O16384.c (test for excess errors)

FAIL: gcc.dg/pr37106-1.c (internal compiler error)
FAIL: gcc.dg/pr37106-1.c (test for excess errors)
FAIL: gcc.dg/pr43562.c (internal compiler error)
FAIL: gcc.dg/pr43562.c (test for excess errors)
FAIL: gcc.dg/pr43564.c (internal compiler error)
FAIL: gcc.dg/pr43564.c (test for excess errors)

FAIL: gcc.target/i386/funcspec-9.c (internal compiler error)
FAIL: gcc.target/i386/funcspec-9.c (test for excess errors)
FAIL: gcc.target/i386/opt-1.c (internal compiler error)
FAIL: gcc.target/i386/opt-1.c (test for excess errors)
FAIL: gcc.target/i386/opt-2.c (internal compiler error)
FAIL: gcc.target/i386/opt-2.c (test for excess errors)

FAIL: gfortran.dg/alloc_comp_assign_2.f90  -O0  (internal compiler error)
FAIL: gfortran.dg/alloc_comp_assign_2.f90  -O0  (test for excess errors)
FAIL: gfortran.dg/alloc_comp_assign_3.f90  -O0  (internal compiler error)
FAIL: gfortran.dg/alloc_comp_assign_3.f90  -O0  (test for excess errors)
FAIL: gfortran.dg/alloc_comp_assign_4.f90  -O0  (internal compiler error)
FAIL: gfortran.dg/alloc_comp_assign_4.f90  -O0  (test for excess errors)
FAIL: gfortran.dg/alloc_comp_auto_array_2.f90  -O0  (internal compiler error)
FAIL: gfortran.dg/alloc_comp_auto_array_2.f90  -O0  (test for excess errors)
FAIL: gfortran.dg/alloc_comp_bounds_1.f90  -O0  (internal compiler error)
FAIL: gfortran.dg/alloc_comp_bounds_1.f90  -O0  (test for excess errors)
FAIL: gfortran.dg/alloc_comp_constructor_1.f90  -O0  (internal compiler error)
FAIL: gfortran.dg/alloc_comp_constructor_1.f90  -O0  (test for excess errors)
FAIL: gfortran.dg/alloc_comp_constructor_2.f90  -O0  (internal compiler error)
FAIL: gfortran.dg/alloc_comp_constructor_2.f90  -O0  (test for excess errors)
FAIL: gfortran.dg/alloc_comp_constructor_3.f90  -O0  (internal compiler error)
FAIL: gfortran.dg/alloc_comp_constructor_3.f90  -O0  (test for excess errors)
FAIL: gfortran.dg/alloc_comp_constructor_4.f90  -O0  (internal compiler error)
FAIL: gfortran.dg/alloc_comp_constructor_4.f90  -O0  (test for excess errors)

FAIL: gfortran.dg/class_array_7.f03  -O0  (internal compiler error)
FAIL: gfortran.dg/class_array_7.f03  -O0  (test for excess errors)
FAIL: gfortran.dg/class_array_7.f03  -O1  (internal compiler error)
FAIL: gfortran.dg/class_array_7.f03  -O1  (test for excess errors)
...
FAIL: gfortran.dg/class_to_type_1.f03  -O0  (internal compiler error)
FAIL: gfortran.dg/class_to_type_1.f03  -O0  (test for excess errors)
...
FAIL: gfortran.dg/extends_4.f03  -O0  (internal compiler error)
FAIL: gfortran.dg/extends_4.f03  -O0  (test for excess errors)
FAIL: gfortran.dg/pr43808.f90  -O0  (internal compiler error)
FAIL: gfortran.dg/pr43808.f90  -O0  (test for excess errors)
...
FAIL: gfortran.dg/type_to_class_1.f03  -O0  (internal compiler error)
FAIL: gfortran.dg/type_to_class_1.f03  -O0  (test for excess errors)
...

FAIL: gnat.dg/aggr1.adb (internal compiler error)
FAIL: gnat.dg/aggr1.adb (test for excess errors)


I didn't check whether any of them are regressions.  If so, please create
individual bugs for them.

[Bug lto/50490] ICE when compiling libglib2.0 with LTO, tree code 'optimization_node' is not supported in LTO streams

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50490

Richard Guenther  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 AssignedTo|unassigned at gcc dot   |rguenth at gcc dot gnu.org
   |gnu.org |

--- Comment #2 from Richard Guenther  2012-01-05 
14:59:29 UTC ---
I have a patch.

[Bug middle-end/51766] New: [4.7 regression] sync_fetch_and_xxx atomicity

[dje at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51766

 Bug #: 51766
   Summary: [4.7 regression] sync_fetch_and_xxx atomicity
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: d...@gcc.gnu.org


During the C++11 memory model conversion, expand_builtin_sync_operation was
updated.  __sync_fetch_and_xxx and __sync_xxx_and_fetch now invoke
expand_atomic_fetch_op with MEMMODEL_SEQUENTIAL_CST.

  return expand_atomic_fetch_op (target, mem, val, code, MEMMODEL_SEQ_CST,
 after);

This has changed the memory model semantics of the builtins and causes the
rs6000/POWER architecture to emit a heavy-weight "sync" instruction instead of
a light-weight "lwsync" instruction, which is a regression.

[Bug middle-end/51766] [4.7 regression] sync_fetch_and_xxx atomicity

[dje at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51766

David Edelsohn  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-01-05
 CC||rth at gcc dot gnu.org
  Known to work||4.6.0, 4.6.1
   Target Milestone|--- |4.7.0
 Ever Confirmed|0   |1
  Known to fail||4.7.0

[Bug middle-end/51764] mudflap does not work with LTO

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51764

--- Comment #1 from Richard Guenther  2012-01-05 
15:08:47 UTC ---
Author: rguenth
Date: Thu Jan  5 15:08:42 2012
New Revision: 182913

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182913
Log:
2012-01-05  Richard Guenther  

PR middle-end/51764
* common.opt (Wmudflap, fmudflap, fmudflapth, fmudflapir): Move
to c.opt.
* toplev.c (process_options): Reject combining mudflap and LTO.
* tree-nomudflap.c (nogo): Use sorry instead of internal_error.

c-family/
* c.opt (Wmudflap, fmudflap, fmudflapth, fmudflapir): Move here
from common.opt.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c.opt
trunk/gcc/common.opt
trunk/gcc/toplev.c
trunk/gcc/tree-nomudflap.c

[Bug middle-end/51764] mudflap does not work with LTO

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51764

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-01-05
 Ever Confirmed|0   |1

--- Comment #2 from Richard Guenther  2012-01-05 
15:09:46 UTC ---
Remains to make mudflap actually work with LTO.  A possible solution might
be to just move the pass to the end of early optimizations.

[Bug middle-end/51761] [4.7 Regression] ICE in verify_gimple_stmt, at tree-cfg.c:4241

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51761

--- Comment #5 from Jakub Jelinek  2012-01-05 
15:10:36 UTC ---
Author: jakub
Date: Thu Jan  5 15:10:26 2012
New Revision: 182914

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182914
Log:
PR middle-end/51761
* gimple.h (struct gimplify_ctx): Add in_cleanup_point_expr
field.
* gimplify.c (gimplify_cleanup_point_expr): Save and set
in_cleanup_point_expr before gimplify_stmt call and restore it
afterwards.
(gimplify_target_expr): Don't add {CLOBBER} cleanup if
in_cleanup_point_expr is false.

* gcc.c-torture/compile/pr51761.c: New test.

Added:
trunk/gcc/testsuite/gcc.c-torture/compile/pr51761.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple.h
trunk/gcc/gimplify.c
trunk/gcc/testsuite/ChangeLog

[Bug lto/51765] Testsuite ICEs with -flto

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51765

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-01-05
 Ever Confirmed|0   |1

--- Comment #1 from Richard Guenther  2012-01-05 
15:15:46 UTC ---
All C ICEs are due to us not supporting the 'optimization_node' trees
(PR50490).

The C++ ICEs are all TM and

/space/rguenther/src/svn/trunk/gcc/testsuite/g++.dg/tm/pr45940-3.C:69:1:
internal compiler error: in write_symbol, at lto-streamer-out.c:1333^M


The gfortran ICEs are all GIMPLE IL verification ICEs with regarding to
structure compatibility (thus, TYPE_CANONICAL mismatches).  Two kinds
can be observed:

/space/rguenther/src/svn/trunk/gcc/testsuite/gfortran.dg/alloc_comp_assign_2.f90:7:0:
error: non-trivial conversion at assignment^M
struct array1_integer(kind=4)^M
struct array1_integer(kind=4)^M
a.68.i = parm.70;^M

and

/space/rguenther/src/svn/trunk/gcc/testsuite/gfortran.dg/class_array_7.f03: In
function 'main':^M
/space/rguenther/src/svn/trunk/gcc/testsuite/gfortran.dg/class_array_7.f03:49:0:
internal compiler error: in fold_convert_loc, at fold-const.c:2016^M

The single Ada ICE is

/space/rguenther/src/svn/trunk/gcc/testsuite/gnat.dg/aggr1.adb: In function
'aggr1':^M
/space/rguenther/src/svn/trunk/gcc/testsuite/gnat.dg/aggr1.adb:3:1: error: type
mismatch in array reference^M
struct aggr1__graph_table_t___PAD^M
^M
struct aggr1__graph_table_t___PAD^M
^M
VIEW_CONVERT_EXPR(graph_table[1]{lb: 1 sz: 59956}.F).active
= 0;^M
^M

and two more similar ones.

[Bug middle-end/51761] [4.7 Regression] ICE in verify_gimple_stmt, at tree-cfg.c:4241

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51761

Jakub Jelinek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #6 from Jakub Jelinek  2012-01-05 
15:20:17 UTC ---
Fixed.

[Bug rtl-optimization/51767] New: [4.5/4.6/4.7 Regression] ICE with degenerated asm goto

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51767

 Bug #: 51767
   Summary: [4.5/4.6/4.7 Regression] ICE with degenerated asm goto
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ja...@gcc.gnu.org
Target: x86_64-linux


extern void fn1 (void), fn2 (void);

static inline __attribute__((always_inline)) int
foo (int *x, long y)
{
  asm goto ("" : : "r" (x), "r" (y) : "memory" : lab);
  return 0;
lab:
  return 1;
}

void
bar (int *x)
{
  if (foo (x, 23))
fn1 ();
  else
fn2 ();

  foo (x, 2);
}

ICEs at -O2 on x86_64-linux.

[Bug rtl-optimization/51767] [4.5/4.6/4.7 Regression] ICE with degenerated asm goto

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51767

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2012-01-05
 AssignedTo|unassigned at gcc dot   |jakub at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

--- Comment #1 from Jakub Jelinek  2012-01-05 
15:28:35 UTC ---
Created attachment 26253
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26253
gcc47-pr51767.patch

Untested fix.

[Bug c++/51755] -Wconversion generates false warnings when the ternary operator is used

[manu at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51755

Manuel López-Ibáñez  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||manu at gcc dot gnu.org
 Resolution||DUPLICATE

--- Comment #5 from Manuel López-Ibáñez  2012-01-05 
15:32:03 UTC ---
(In reply to comment #3)
> Hi Jason. Looks like people are really unhappy with the -Wconversion warnings
> vs the ternary operator, and I'd like to look into these issues in time for
> 4.7. At the moment I'm confused, however, because I don't understand if the
> patch linked by Manuel in PR51294 (maybe we can consolidate these two issues)
> was rejected in a unamendable way, or we (I) can start from it and complete 
> the
> work. Can you guide me a bit? Thanks...

In fact, it would be the opposite. Start from it and cut out what Joseph was
against, which is to not warn for char a,b,c; a = b * c, which is what PR40752
asks for. The ternary operator (PR51294) was orthogonal to this issue but the
patch fixed both.

(I wouldn't send a patch like that now, but I was a newbie then.)

I think this is a clearly a duplicate of 51294.

*** This bug has been marked as a duplicate of bug 51294 ***

[Bug c/51294] spurious warning from -Wconversion in C and C++ in conditional expressions

[manu at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51294

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||james.kanze at gmail dot
   ||com

--- Comment #6 from Manuel López-Ibáñez  2012-01-05 
15:32:03 UTC ---
*** Bug 51755 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/42283] regression: ICE when bootstrapping trunk with -O2 -ftree-loop-distribution

[matt at use dot net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42283

Matt Hargett  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #2 from Matt Hargett  2012-01-05 15:41:15 UTC 
---
No longer happens on trunk.

[Bug lto/50490] ICE when compiling libglib2.0 with LTO, tree code 'optimization_node' is not supported in LTO streams

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50490

--- Comment #3 from Richard Guenther  2012-01-05 
15:44:01 UTC ---
Author: rguenth
Date: Thu Jan  5 15:43:54 2012
New Revision: 182917

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182917
Log:
2012-01-05  Richard Guenther  

PR lto/50490
* tree-streamer-out.c (write_ts_optimization): New function.
(streamer_write_tree_body): Call it.
* tree-streamer-in.c (lto_input_ts_optimization): New function.
(streamer_read_tree_body): Call it.
* lto-streamer-out.c (lto_is_streamable): Handle OPTIMIZATION_NODE.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/lto-streamer-out.c
trunk/gcc/tree-streamer-in.c
trunk/gcc/tree-streamer-out.c

[Bug rtl-optimization/51767] [4.5/4.6/4.7 Regression] ICE with degenerated asm goto

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51767

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|--- |4.5.4

[Bug middle-end/51768] New: [4.5/4.6/4.7 Regression] ICE with invalid asm goto

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51768

 Bug #: 51768
   Summary: [4.5/4.6/4.7 Regression] ICE with invalid asm goto
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Keywords: ice-on-invalid-code
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ja...@gcc.gnu.org


void
foo (void)
{
  asm goto ("" : : : : lab, lab, lab2, lab);/* { dg-error "duplicate asm
operand name" } */
lab:;
lab2:;
}

void
bar (void)
{
  asm goto ("" : : [lab] "i" (0) : : lab);/* { dg-error "duplicate asm operand
name" } */
lab:;
}

ICEs with tree-checking (or just crashes during error reporting if not tree
checking).

[Bug middle-end/51768] [4.5/4.6/4.7 Regression] ICE with invalid asm goto

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51768

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|--- |4.5.4

[Bug c++/16168] -Weffc++ item 14 improvements

[f-roth at megaera dot de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16168

--- Comment #4 from Frederick Roth  2012-01-05 
15:55:30 UTC ---
this still happens with version 4.6.2. Can someone reconfirm this?

[Bug middle-end/51768] [4.5/4.6/4.7 Regression] ICE with invalid asm goto

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51768

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2012-01-05
 AssignedTo|unassigned at gcc dot   |jakub at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

--- Comment #1 from Jakub Jelinek  2012-01-05 
15:56:53 UTC ---
Created attachment 26254
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26254
gcc47-pr51768.patch

Untested fix.

[Bug middle-end/51769] New: bootstrap fails when using -O2 -funswitch-loops -floop-flatten

[matt at use dot net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51769

 Bug #: 51769
   Summary: bootstrap fails when using  -O2 -funswitch-loops
-floop-flatten
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: m...@use.net


Bootstrap has failed for at least a few months now when adding -floop-flatten
and other options. I've filed several other bugs where loop-flatten with other
options causes the same ICE across other popular open source projects: PR50398
and PR50561 come to mind.

To reproduce:

g++
-I/tmp/gcc-obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu
-I/tmp/gcc-obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include
-I/home/matt/src/gcc-4.7.0/libstdc++-v3/libsupc++
-L/tmp/gcc-obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs
-L/tmp/gcc-obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -c  
-g -O2 -funswitch-loops -floop-flatten -DIN_GCC -fno-common  -DHAVE_CONFIG_H
-I. -I. -I/home/matt/src/gcc-4.7.0/gcc -I/home/matt/src/gcc-4.7.0/gcc/.
-I/home/matt/src/gcc-4.7.0/gcc/../include
-I/home/matt/src/gcc-4.7.0/gcc/../libcpp/include 
-I/home/matt/src/gcc-4.7.0/gcc/../libdecnumber
-I/home/matt/src/gcc-4.7.0/gcc/../libdecnumber/bid -I../libdecnumber   
/home/matt/src/gcc-4.7.0/gcc/caller-save.c -o caller-save.o


/home/matt/src/gcc-4.7.0/gcc/caller-save.c: In function ‘void
init_save_areas()’:
/home/matt/src/gcc-4.7.0/gcc/caller-save.c:292:1: internal compiler error: in
psct_dynamic_dim, at graphite-poly.h:659


This one does produce some potentially relevant valgrind output:

==5057== Conditional jump or move depends on uninitialised value(s)
==5057==at 0x9E46B6:
_ZL24call_may_clobber_ref_p_1P18gimple_statement_dP8ao_ref_s.951695.39962
(tree-ssa-alias.c:1494)
==5057==by 0x9E506E: stmt_may_clobber_ref_p_1(gimple_statement_d*,
ao_ref_s*) (tree-ssa-alias.c:1753)
==5057==by 0x9E51F9:
_ZL20walk_aliased_vdefs_1P8ao_ref_sP9tree_nodePFbS0_S2_PvES3_PP15bitmap_head_defj.951731.constprop.2807.35016
(tree-ssa-alias.c:2158)
==5057==by 0x9E53D6: walk_aliased_vdefs(ao_ref_s*, tree_node*, bool
(*)(ao_ref_s*, tree_node*, void*), void*, bitmap_head_def**)
(tree-ssa-alias.c:2178)
==5057==by 0xD6E9F4:
_ZL20detect_type_change_1P9tree_nodeS0_S0_P18gimple_statement_dP13ipa_jump_funcl.496274.33562
(ipa-prop.c:460)
==5057==by 0xD6F90B:
_ZL35ipa_compute_jump_functions_for_edgeP19param_analysis_infoP11cgraph_edge.496762.33448
(ipa-prop.c:922)
==5057==by 0xD70591: ipa_analyze_node(cgraph_node*) (ipa-prop.c:1203)
==5057==by 0xD70CEC: _ZL21ipcp_generate_summaryv.1440941 (ipa-cp.c:2498)
==5057==by 0xD99B92: execute_ipa_summary_passes(ipa_opt_pass_d*)
(passes.c:1957)
==5057==by 0xE87E94: cgraph_optimize() (cgraphunit.c:2059)
==5057==by 0xE889D9: cgraph_finalize_compilation_unit() (cgraphunit.c:1327)
==5057==by 0xE89046: cp_write_global_declarations() (decl2.c:4050)
==5057== 
==5057== Conditional jump or move depends on uninitialised value(s)
==5057==at 0x9DF9DE: refs_may_alias_p_1(ao_ref_s*, ao_ref_s*, bool)
(tree-ssa-alias.c:1027)
==5057==by 0x9E5026: stmt_may_clobber_ref_p_1(gimple_statement_d*,
ao_ref_s*) (tree-ssa-alias.c:1762)
==5057==by 0x9E51F9:
_ZL20walk_aliased_vdefs_1P8ao_ref_sP9tree_nodePFbS0_S2_PvES3_PP15bitmap_head_defj.951731.constprop.2807.35016
(tree-ssa-alias.c:2158)
==5057==by 0x9E53D6: walk_aliased_vdefs(ao_ref_s*, tree_node*, bool
(*)(ao_ref_s*, tree_node*, void*), void*, bitmap_head_def**)
(tree-ssa-alias.c:2178)
==5057==by 0xD6E9F4:
_ZL20detect_type_change_1P9tree_nodeS0_S0_P18gimple_statement_dP13ipa_jump_funcl.496274.33562
(ipa-prop.c:460)
==5057==by 0xD6F90B:
_ZL35ipa_compute_jump_functions_for_edgeP19param_analysis_infoP11cgraph_edge.496762.33448
(ipa-prop.c:922)
==5057==by 0xD70591: ipa_analyze_node(cgraph_node*) (ipa-prop.c:1203)
==5057==by 0xD70CEC: _ZL21ipcp_generate_summaryv.1440941 (ipa-cp.c:2498)
==5057==by 0xD99B92: execute_ipa_summary_passes(ipa_opt_pass_d*)
(passes.c:1957)
==5057==by 0xE87E94: cgraph_optimize() (cgraphunit.c:2059)
==5057==by 0xE889D9: cgraph_finalize_compilation_unit() (cgraphunit.c:1327)
==5057==by 0xE89046: cp_write_global_declarations() (decl2.c:4050)

[Bug middle-end/51769] bootstrap fails when using -O2 -funswitch-loops -floop-flatten

[matt at use dot net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51769

--- Comment #1 from Matt Hargett  2012-01-05 16:03:06 UTC 
---
Created attachment 26255
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26255
pre-processed source of the file that triggers the ICE

commandline to trigger the ICE with the attached file (once decompressed):
g++ -O2 -funswitch-loops -floop-flatten -c caller-save.i

Removing any one of the options, or replacing the O2 with Os, eliminated the
ICE.

[Bug tree-optimization/51737] [4.6 Regression] g++ crashes (internal compiler error: Segmentation fault) when compiling quickbook

[jamborm at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51737

--- Comment #9 from Martin Jambor  2012-01-05 
16:16:29 UTC ---
I can reproduce the segfault when compiling both the testcase from
comment #8 and the original unreduced test case on the 4.6 branch but
not on my trunk checkout (revision 182785).  I will have a look at
what is going on nevertheless.

[Bug c++/51541] ICE on ill-formed alias template declarations

[dodji at seketeli dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51541

--- Comment #1 from dodji at seketeli dot org  
2012-01-05 16:58:29 UTC ---
A candidate fix has been posted to
http://gcc.gnu.org/ml/gcc-patches/2012-01/msg00256.html

[Bug c++/48680] -Weffc++ update description for 2nd and 3rd edition of Scott Meyers

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48680

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2012-01-05
 AssignedTo|unassigned at gcc dot   |redi at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

--- Comment #2 from Jonathan Wakely  2012-01-05 
17:01:36 UTC ---
see also PR 16166 comment 3

[Bug c++/16168] -Weffc++ item 14 improvements

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16168

Jonathan Wakely  changed:

   What|Removed |Added

   Last reconfirmed|2005-06-28 01:34:16 |2012-01-05
  Known to fail||4.6.2

--- Comment #5 from Jonathan Wakely  2012-01-05 
17:03:35 UTC ---
The bug is still open, that means it still applies, it doesn't need to be
reconfirmed

see also PR 16166 comment 3, and my comments on various bugs saying -Weffc++ is
pretty useless.

[Bug c++/22395] -Weffc++ shouldn't warn about non-virtual dtor of private subclasses

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22395

--- Comment #5 from Jonathan Wakely  2012-01-05 
17:13:02 UTC ---
private inheritance doesn't mean the destructor can't be called with the wrong
static type

class Foo {
public:
~Foo() {}
virtual void f() { }
};

class Bar : private Foo {
public:
Foo* get() { return this; }
};

int main()
{
Bar* b = new Bar;
delete b->get();
}

as stated in PR 16166 comment 3, the 3rd edition of Effective C++ changes the
guideline, and -Wdelete-non-virtual-dtor is usually a better option anyway

[Bug tree-optimization/41881] [4.5/4.6 regression] Complete unrolling (inner) versus vectorization of reduction

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41881

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org
Summary|[4.5/4.6/4.7 regression]|[4.5/4.6 regression]
   |Complete unrolling (inner)  |Complete unrolling (inner)
   |versus vectorization of |versus vectorization of
   |reduction   |reduction

--- Comment #12 from Jakub Jelinek  2012-01-05 
17:14:11 UTC ---
Fixed on the trunk, thanks.

[Bug bootstrap/51648] [4.7 Regression] Profiledbootstrap failure on x86_64-linux

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51648

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED
 AssignedTo|unassigned at gcc dot   |jakub at gcc dot gnu.org
   |gnu.org |

--- Comment #16 from Jakub Jelinek  2012-01-05 
17:16:48 UTC ---
Fixed.

[Bug rtl-optimization/49936] [4.7 Regression] IRA handles CANNOT_CHANGE_MODE_CLASS poorly, + spills to memory on 4.7

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49936

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #9 from Jakub Jelinek  2012-01-05 
17:17:44 UTC ---
Sandra, ping re: #c8?

[Bug middle-end/48668] [4.6 regression] COMDAT Group signature not emitted in group

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48668

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org
Summary|[4.6/4.7 regression] COMDAT |[4.6 regression] COMDAT
   |Group signature not emitted |Group signature not emitted
   |in group|in group

--- Comment #8 from Jakub Jelinek  2012-01-05 
17:19:06 UTC ---
Assuming fixed on the trunk.  If not, please respond to Richard's questions and
provide details.

[Bug gcov-profile/50127] [4.7 regression] g++.dg/tree-prof/partition2.C FAILs on several targets

[ro at CeBiTec dot Uni-Bielefeld.DE]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50127

--- Comment #6 from ro at CeBiTec dot Uni-Bielefeld.DE  2012-01-05 17:16:21 UTC ---
> --- Comment #5 from Jakub Jelinek  2012-01-05 
> 09:41:13 UTC ---
> Can't reproduce on x86_64-linux, nor with cross from that to
> i686-sun-solaris2.11 with -m64 and using x86_64-linux bb-reorder.gcda.

It reproduces for me on x86_64-linux with the following configuration:

/vol/gcc/src/hg/trunk/local/configure --prefix=/vol/gcc
--target=i686-unknown-linux-gnu --enable-checking=release --enable-targets=all
--enable-objc-gc --with-as=/vol/gcc/bin/gas-2.22 --with-gnu-as
--with-as=/vol/gcc/bin/gas-2.22 --with-gnu-as
--with-ld=/vol/gcc/bin/i686/gld-2.22 --with-gnu-ld --disable-initfini-array
--with-ld=/vol/gcc/bin/i686/gld-2.22 --with-gnu-ld --disable-initfini-array
--with-gmp-include=/vol/gcc/include --with-gmp-lib=/vol/gcc/lib/i686
--with-mpfr-include=/vol/gcc/include --with-mpfr-lib=/vol/gcc/lib/i686
--with-mpc-include=/vol/gcc/include --with-mpc-lib=/vol/gcc/lib/i686
--enable-languages=all,ada,obj-c++,go --build=i686-unknown-linux-gnu
--host=i686-unknown-linux-gnu

i.e. with a 32-bit compiler executable.  It doesn't with a 64-bit
compiler executable.

Rainer

[Bug rtl-optimization/49936] [4.7 Regression] IRA handles CANNOT_CHANGE_MODE_CLASS poorly, + spills to memory on 4.7

[sandra at codesourcery dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49936

--- Comment #10 from Sandra Loosemore  
2012-01-05 17:31:39 UTC ---
My notes are that the unnecessary register moves in the loop have been present
since at least GCC 4.3, so it is not a 4.6->4.7 regression, at least.

[Bug c++/50012] [4.5/4.6/4.7 Regression] C++ front end misses -Wsign-compare warnings when extraneous parentheses are present

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50012

--- Comment #6 from Jakub Jelinek  2012-01-05 
17:41:47 UTC ---
Ian, ping?

[Bug target/47333] [4.6/4.7 regression] g++.dg/lto/20091219 FAILs on Solaris 2 with SUN as

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47333

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #21 from Jakub Jelinek  2012-01-05 
17:46:27 UTC ---
Indeed, with #c3 testcase I can reproduce it after #undef HAVE_GAS_WEAKREF in
auto-host.h.
When assembler doesn't support weakrefs, gcc performs what the assembler does,
i.e. transparently uses the weakref arg symbols instead of the weakref symbols,
and if there is any direct reference to the weakref arg symbol in the source
doesn't make it .weak, if there are none, makes it .weak.
Without -flto this seems to work fine, with -flto it doesn't.

[Bug target/48308] [4.6/4.7 Regression] crosscompiling to arm fails with assembler: can't resolve '.LC4' {.rodata.str1.1 section} - '.LPIC4' {*UND* section}

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48308

--- Comment #16 from Jakub Jelinek  2012-01-05 
17:48:11 UTC ---
Ramana (or some other ARM maintainer), could you please try to implement this? 
Thanks.

[Bug c++/23383] builtin array operator new is not marked with malloc attribute

[xinliangli at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23383

--- Comment #20 from davidxl  2012-01-05 18:11:18 
UTC ---
(In reply to comment #19)
> On Wed, 4 Jan 2012, xinliangli at gmail dot com wrote:
> 
> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23383
> > 
> > --- Comment #18 from davidxl  2012-01-04 
> > 17:11:26 UTC ---
> > (In reply to comment #17)
> > > On Wed, 4 Jan 2012, xinliangli at gmail dot com wrote:
> > > 
> > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23383
> > > > 
> > > > --- Comment #16 from davidxl  2012-01-04 
> > > > 00:28:55 UTC ---
> > > > A related topic - aliasing property of realloc -- the malloc attribute 
> > > > is not
> > > > applied in the glibc header and the comment is like
> > > > 
> > > > /* __attribute_malloc__ is not used, because if realloc returns
> > > >the same pointer that was passed to it, aliasing needs to be allowed
> > > >between objects pointed by the old and new pointers.  *
> > > > 
> > > > 
> > > > It is true that the realloc can return an address is physically aliased 
> > > > with
> > > > the pointer passed to it -- but assuming no-alias by the compiler 
> > > > should cause
> > > > no harm -- as all code motions/CSEs across the realloc call will not be
> > > > possible because realloc may modify/use the memory location.
> > > > 
> > > > 
> > > > Any comment on this? 
> > > 
> > > The malloc attribute assumes that the contents of the memory pointed
> > > to by the return value is undefined, so the comment is inaccurate
> > > but the malloc attribute can indeed be not used.
> > 
> > Which part of the optimizer takes advantage of the 'undefinedness' of 
> > returned
> > memory?
> 
> points-to analysis.  It assumes that the returned blob of memory
> points to nothing (yet).  So for
> 
>  int i;
>  int **p = malloc (8);
>  *p = &i;
>  int **q = realloc (p, 8);
> 
> you'd get that *q points to nothing insteda of i.

The malloc attribute documentation is confusing:

malloc
The malloc attribute is used to tell the compiler that a function may be
treated as if any non-NULL pointer it returns cannot alias any other pointer
valid when the function returns. This will often improve optimization. Standard
functions with this property include malloc and calloc. realloc-like functions
have this property as long as the old pointer is never referred to (including
comparing it to the new pointer) after the function returns a non-NULL value. 


It does not mention the undefineness explicitly.

It might be better to fix the semantics of this attribute to only specify the
aliasing property so that it can also be applied to realloc. Points-to needs to
be fixed to special case realloc for the initialization.

David


> 
> > > We can explicitly handle REALLOC in the points-to code to honor the
> > > fact that it is not (we do not at the moment).
> > 
> > ok.
> 
> which needs to be fixed here.
> 
> Richard.

[Bug c++/41090] [4.4/4.5/4.6/4.7/4.8 Regression] Using static label reference in c++ class constructor produces wrong code

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41090

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org
   Target Milestone|4.4.7   |4.8.0
Summary|[4.4/4.5/4.6/4.7|[4.4/4.5/4.6/4.7/4.8
   |Regression] Using static|Regression] Using static
   |label reference in c++  |label reference in c++
   |class constructor produces  |class constructor produces
   |wrong code  |wrong code
  Known to fail||

--- Comment #14 from Jakub Jelinek  2012-01-05 
18:11:57 UTC ---
Well, we could perhaps detect the problematic ctors or dtors and instead of
cloning them as we do now create a helper function which all of the ctors resp.
dtors would use.  Doesn't look like a 4.7 material at this point though.

[Bug c++/23383] builtin array operator new is not marked with malloc attribute

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23383

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #21 from Jakub Jelinek  2012-01-05 
18:26:17 UTC ---
But can't a valid code also compare the result from realloc with the old
pointer, and if they are equal, do something, otherwise do something else?
I think it is pretty common e.g. if the malloced block contains pointers to
parts of the malloced area and upon realloc that didn't return the passed
address wants to adjust all those pointers.
Having a malloc attribute on realloc would still break this.
I'd say we want realloc attribute and handle it where we currently handle
BUILT_IN_REALLOC.

[Bug c++/23383] builtin array operator new is not marked with malloc attribute

[xinliangli at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23383

--- Comment #22 from davidxl  2012-01-05 18:54:51 
UTC ---
(In reply to comment #21)
> But can't a valid code also compare the result from realloc with the old
> pointer, and if they are equal, do something, otherwise do something else?
> I think it is pretty common e.g. if the malloced block contains pointers to
> parts of the malloced area and upon realloc that didn't return the passed
> address wants to adjust all those pointers.
> Having a malloc attribute on realloc would still break this.
> I'd say we want realloc attribute and handle it where we currently handle
> BUILT_IN_REALLOC.

Right, the case you describe may be common. On the other hand, the compiler
probably should not optimize away pointer comparisons without knowing if the
pointer is used after 'free' or 'free' like function 'realloc'.

David

[Bug rtl-optimization/49710] [4.7 Regression] segfault

[hubicka at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49710

--- Comment #7 from Jan Hubicka  2012-01-05 
19:25:19 UTC ---
Author: hubicka
Date: Thu Jan  5 19:25:14 2012
New Revision: 182919

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182919
Log:
PR middle-end/49710
* cfgloopmanip.c (remove_path): Walk loop hiearchy upwards when
unlooping loops.

Added:
trunk/gcc/testsuite/gcc.c-torture/compile/pr49710.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/cfgloopmanip.c
trunk/gcc/testsuite/ChangeLog

[Bug rtl-optimization/49710] [4.7 Regression] segfault

[hubicka at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49710

Jan Hubicka  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #8 from Jan Hubicka  2012-01-05 
19:27:26 UTC ---
Fixed.

[Bug middle-end/44777] [4.4/4.5/4.6/4.7 Regression] ICE: SIGSEGV with -fprofile-use in gcc.c-torture/execute/comp-goto-2.c

[hubicka at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44777

--- Comment #9 from Jan Hubicka  2012-01-05 
19:34:08 UTC ---
OK, so the problem is separating the actual two builtins, not that profiling
would choke on the multiple returns now?
In that case I think the patch is OK (otherwise I would be concerned about
fork, that also returns twice, like setjmp receivers do).

Thanks a lot for looking into that!
Honza

[Bug middle-end/44777] [4.4/4.5/4.6/4.7 Regression] ICE: SIGSEGV with -fprofile-use in gcc.c-torture/execute/comp-goto-2.c

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44777

--- Comment #10 from Jakub Jelinek  2012-01-05 
19:54:21 UTC ---
Author: jakub
Date: Thu Jan  5 19:54:16 2012
New Revision: 182920

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182920
Log:
PR middle-end/44777
* profile.c (branch_prob): Split bbs that have exit edge
and need a fake entry edge too.

* gcc.dg/tree-prof/pr44777.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/tree-prof/pr44777.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/profile.c
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/51770] New: dump gimple lineno when dumping bb

[nash11228 at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51770

 Bug #: 51770
   Summary: dump gimple lineno when dumping bb
Classification: Unclassified
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: nash11...@gmail.com


Hi all,

  I know gcc can dump lineno information before each gimple statement.
[filename : line:col] gimple statement.
 But it's not convenient to look, too much lineno's and no alignment again.

how about dump lineno at bb level just before gimple statement when lineno
changes ?

# line 11
gs1
gs2
...
# line 12
...

just like dwarf debugging information format.

here is example code


--- gimple-pretty-print.c(revision 182877)
+++ gimple-pretty-print.c(working copy)
@@ -2284,6 +2284,7 @@
   gimple_stmt_iterator gsi;
   gimple stmt;
   int label_indent = indent - 2;
+  int lineno = 0;

   if (label_indent < 0)
 label_indent = 0;
@@ -2299,6 +2300,15 @@

   curr_indent = gimple_code (stmt) == GIMPLE_LABEL ? label_indent :
indent;

+  if (gimple_lineno (stmt) != lineno)
+{
+  lineno = gimple_lineno (stmt);
+
+  INDENT (curr_indent);
+  pp_printf (buffer, "# line %d", lineno);
+  pp_newline (buffer);
+}
+  
   INDENT (curr_indent);
   dump_gimple_stmt (buffer, stmt, curr_indent, flags);
   pp_newline (buffer);

[Bug middle-end/44777] [4.4/4.5/4.6 Regression] ICE: SIGSEGV with -fprofile-use in gcc.c-torture/execute/comp-goto-2.c

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44777

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[4.4/4.5/4.6/4.7|[4.4/4.5/4.6 Regression]
   |Regression] ICE: SIGSEGV|ICE: SIGSEGV with
   |with -fprofile-use in   |-fprofile-use in
   |gcc.c-torture/execute/comp- |gcc.c-torture/execute/comp-
   |goto-2.c|goto-2.c

--- Comment #11 from Jakub Jelinek  2012-01-05 
20:10:09 UTC ---
(In reply to comment #9)
> OK, so the problem is separating the actual two builtins, not that profiling
> would choke on the multiple returns now?

Yes, profiling code was fine, it was the expansion of the two setjmp halves
that was upset by anything unexpected in between the two.

Thus, committed, thanks.