[Bug c++/48759] New: Inconsistency in code generation for inline virtual functions depending on position of the "inline" keyword

[siddhesh.poyarekar at gmail dot com]

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

   Summary: Inconsistency in code generation for inline virtual
functions depending on position of the "inline"
keyword
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: siddhesh.poyare...@gmail.com


Description:

The c+ parser seems to differentiate between inline virtual functions that have
the inline keyword only in the function definition as opposed to when it is
present in the declaration. When the inline keyword is only in the definition,
the function is flagged such that code is generated for it, which is not
correct.

How Reproducible:

Always:

Steps to Reproduce and Results:

[siddhesh@localhost ~]$ cat foo.ii
class A {
public:
virtual void f();
};

inline void
A::f()
{
}
[siddhesh@localhost ~]$ g++ -c foo.ii
[siddhesh@localhost ~]$ objdump -dC foo.o

foo.o: file format elf64-x86-64


Disassembly of section .text._ZN1A1fEv:

 :
   0:55   push   %rbp
   1:48 89 e5 mov%rsp,%rbp
   4:48 89 7d f8  mov%rdi,-0x8(%rbp)
   8:c9   leaveq 
   9:c3   retq   

Expected Result:

The correct output, as shown when the inline keyword is present (at least) in
the declaration:

[siddhesh@localhost ~]$ cat foo.ii
class A {
public:
virtual inline void f();
};

void
A::f()
{
}
[siddhesh@localhost ~]$ g++ -c foo.ii
[siddhesh@localhost ~]$ objdump -dC foo.o

foo.o: file format elf64-x86-64

Additional Information:

Chapter 9.3 in the C++ standard says:

"an inline member function (whether static or non-static) may also be defined
outside of its class definition provided either its declaration in the class
definition or its definition outside of the class definition declares the
function as inline."

I could not find any exceptions to this rule for virtual functions.

[Bug c/48758] gcc miscompiles Emacs by incorrectly substituting memcpy for memmove

[sch...@linux-m68k.org]

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

Andreas Schwab  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #1 from Andreas Schwab  2011-04-25 07:43:50 
UTC ---
http://sourceware.org/git/?p=glibc.git;a=commit;h=42acbb92c861e97a6e1293ea853db88342a1bf53

[Bug libfortran/48615] Invalid UP/DOWN rounding with E and ES descriptors

[thenlich at users dot sourceforge.net]

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

--- Comment #12 from Thomas Henlich  
2011-04-25 08:43:32 UTC ---
The patch submitted to the list is different to the one I based my comments on.
My mistake.

Good work.

With the current method of letting printf do the conversion, there seems to be
no better way than always converting the full 40 digits, and then throwing away
most of them.

In Bug 48511 David Gay's dtoa implementation was mentioned. I looked into that
and I think it can be modified to be fully Fortran standard compliant. It
combines digit generation and rounding in one step and is probably
significantly more efficient than our current solution. Will investigate
further.

[Bug libfortran/48684] Incorrect field alignment with Gw.dEe descriptor

[thenlich at users dot sourceforge.net]

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

--- Comment #6 from Thomas Henlich  
2011-04-25 08:46:38 UTC ---
(In reply to comment #5)
> On 04/23/2011 02:27 PM, jvdelisle at gcc dot gnu.org wrote:
> --- snip ---
> >
> > Unpatched gfortran and ifort give:
> 
> I meant patched gfortran and ifort give:
> >
> > 12345678901234567890
> > 0.100
> >  1.00
> >  10.0
> >  100.
> > 0.100E+4
> > 0.100E+5
> > 0.100E+6
> > 0.100E+7
> > 0.100E+8
> > 0.100E+9
> > 0.100E+00010
> > 0.100E+00011
> > 0.100E+00012
> --- snip ---
> >
> > My question, are the values of 1.0, 10.0, and 100. formatted correctly?
> >

Yes, the number of spaces is e+2=7, so they are aligned correctly.

[Bug lto/48725] 4.6.0 fails to link p7zip 9.20.1 with LTO and gold

[gmarkhor at gmail dot com]

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

--- Comment #3 from Vadim Markovtsev  2011-04-25 
09:47:25 UTC ---
BTW, gold fails to link if used in a similar way in LLVM LTO, so it is likely
not a GCC bug.

[Bug libstdc++/48760] New: std::complex constructor buggy in the face of NaN's

[john at johnmaddock dot co.uk]

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

   Summary: std::complex constructor buggy in the face of NaN's
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: blocker
  Priority: P3
 Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: j...@johnmaddock.co.uk


If a std::complex is constructed where one argument is finite and one a NaN
then the result is a complex number with both parts NaN, which is in violation
of 26.4.4 in the C++2011 std.

For example:

std::complex c(0, std::numeric::limits::quiet_NaN());

results in both real and imaginary parts of c being a NaN.

This causes failures in the Boost.Math regression tests, see also section
G.6.1.1 in C99 where such values can have well defined results for complex-trig
operations.

[Bug middle-end/48760] [4.6 / 4.7 Regression (?)] std::complex constructor buggy in the face of NaN's

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC||jsm28 at gcc dot gnu.org
  Component|libstdc++   |middle-end
Summary|std::complex constructor|[4.6 / 4.7 Regression (?)]
   |buggy in the face of NaN's  |std::complex constructor
   ||buggy in the face of NaN's
   Severity|blocker |normal

--- Comment #1 from Paolo Carlini  2011-04-25 
12:07:44 UTC ---
I don't think this is a library proper issue, how can it be? We have just:

  constexpr // In C++0x mode
  complex(float __r = 0.0f, float __i = 0.0f)
  : _M_value(__r + __i * 1.0fi) { }

where _M_value is a __complex__ float. Joseph, can you have a look? By the way,
what is reported did *not* happen in 4.5.x and nothing changed in the lib in
this area in the meanwhile (besides the C++0x bits, not at issue here).

Note a complete C++ snippet would be:

#include 
#include 
#include 

int main()
{
  std::complex c(0, std::numeric_limits::quiet_NaN());

  std::cout << c << std::endl;
}

[Bug middle-end/48760] [4.6 / 4.7 Regression (?)] std::complex constructor buggy in the face of NaN's

[paolo.carlini at oracle dot com]

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

--- Comment #2 from Paolo Carlini  2011-04-25 
12:41:59 UTC ---
PR24581 can be related, its additional, "unexpected", nans.

A C snippet showing the issue would be:

int main()
{
  float r = 0;
  float i = __builtin_nanf ("");

  __complex__ float c = r + i * 1.0fi; 

  /*
  __complex__ float c;
  __real__ c = r;
  __imag__ c = i;
  */

  __builtin_printf("%f\n", __real__ c);
  __builtin_printf("%f\n", __imag__ c);
}

Indeed, I could tweak the library to construct the complex by pieces, avoiding
the multiplication by the imaginary constant in the constructor, but the
problem would definitely reappear at any following multiplication...

[Bug middle-end/48760] [4.6 / 4.7 Regression (?)] std::complex constructor buggy in the face of NaN's

[paolo.carlini at oracle dot com]

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

--- Comment #3 from Paolo Carlini  2011-04-25 
13:21:58 UTC ---
By the way, just in case isn't super-clear to people coming from C, there is
nothing C++1x specific here (26.4.4/1 and /2 are identical to 26.2.4 in the old
standard)

[Bug lto/48725] 4.6.0 fails to link p7zip 9.20.1 with LTO and gold

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2011.04.25 14:51:25
 CC||hjl.tools at gmail dot com
 Ever Confirmed|0   |1

--- Comment #4 from H.J. Lu  2011-04-25 14:51:25 
UTC ---
Does it work with BFD linker in CVS?

[Bug middle-end/48761] New: Indirect inlining needs to perform type checking

[hubicka at gcc dot gnu.org]

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

   Summary: Indirect inlining needs to perform type checking
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hubi...@gcc.gnu.org


Hi,
I believe that the following bug is not preventing Mozilla from building with
LTO. Though I did not reduced the testcase, yet, I can easily reproduce similar
bug. I will still look into Mozilla testcase as I can not imagine this to match
on any sane code.

Martin/Richi, at some point we need to test type compatibility after declaring
edge direct and possible set the uninlinable flag.  Bit tricky to do as the
call type is not easily accessible from the indirect edge.

Honza

evans:/abuild/jh/trunk-3/build-inst5/gcc/:[1]$ cat ~/t.c
struct a{
  double b;
};
double a(struct a b)
{
  return b.b;
}

callptr(int (*p)(int))
{
   p(10);
}
main()
{
  callptr (a);
}
evans:/abuild/jh/trunk-3/build-inst5/gcc/:[0]$ ./xgcc -B ./ -O3 ~/t.c
-fno-early-inlining -S
/root/t.c: In function 'main':
/root/t.c:15:3: warning: passing argument 1 of 'callptr' from incompatible
pointer type [enabled by default]
/root/t.c:9:1: note: expected 'int (*)(int)' but argument is of type 'double
(*)(struct a)'
/root/t.c:13:1: error: conversion of register to a different size
VIEW_CONVERT_EXPR(D.2717_2);

# .MEM_4 = VDEF <.MEM_1(D)>
b = VIEW_CONVERT_EXPR(D.2717_2);

/root/t.c:13:1: internal compiler error: verify_gimple failed
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug middle-end/48760] [4.6 / 4.7 Regression (?)] std::complex constructor buggy in the face of NaN's

[joseph at codesourcery dot com]

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

--- Comment #4 from joseph at codesourcery dot com  2011-04-25 16:02:11 UTC ---
On Mon, 25 Apr 2011, paolo.carlini at oracle dot com wrote:

> A C snippet showing the issue would be:
> 
> int main()
> {
>   float r = 0;
>   float i = __builtin_nanf ("");
> 
>   __complex__ float c = r + i * 1.0fi; 
> 
>   /*
>   __complex__ float c;
>   __real__ c = r;
>   __imag__ c = i;
>   */
> 
>   __builtin_printf("%f\n", __real__ c);
>   __builtin_printf("%f\n", __imag__ c);
> }
> 
> Indeed, I could tweak the library to construct the complex by pieces, avoiding
> the multiplication by the imaginary constant in the constructor, but the
> problem would definitely reappear at any following multiplication...

I don't see any C bug here.  Without imaginary types it's correct that 
1.0fi is a complex constant and so you get NaN for both real and imaginary 
parts.  To avoid that, assign to real and imaginary parts as shown in the 
comment, or implement __builtin_cmplx* that correspond to C1X CMPLX* 
macros (which should be pretty easy to do; the built-in functions just 
need to map to COMPLEX_EXPR and handle constants correctly) and use those.

[Bug lto/48725] 4.6.0 fails to link p7zip 9.20.1 with LTO and gold

[gmarkhor at gmail dot com]

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

--- Comment #5 from Vadim Markovtsev  2011-04-25 
16:06:25 UTC ---
(In reply to comment #4)
> Does it work with BFD linker in CVS?

I will check that out tomorrow.

[Bug libstdc++/48760] [4.6 / 4.7 Regression (?)] std::complex constructor buggy in the face of NaN's

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

  Component|middle-end  |libstdc++

--- Comment #5 from Paolo Carlini  2011-04-25 
16:12:35 UTC ---
Ok, no problem, I can certainly tweak the C++ library in this sense. Strange,
anyway, that the behavior of this std::complex constructor changed only in
4.6.0, after so *many* years (and, by the way, if I compile the same library
code with current ICC I get again (0,nan))

[Bug libstdc++/48760] [4.6 / 4.7 Regression (?)] std::complex constructor buggy in the face of NaN's

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.04.25 16:18:13
 AssignedTo|unassigned at gcc dot   |paolo.carlini at oracle dot
   |gnu.org |com
   Target Milestone|--- |4.6.1
 Ever Confirmed|0   |1

[Bug tree-optimization/48762] New: valgrind: Invalid read/write of size 8 in cse_main with -O --param max-cse-path-length=0 on basic code

[zsojka at seznam dot cz]

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

   Summary: valgrind: Invalid read/write of size 8 in cse_main
with -O --param max-cse-path-length=0 on basic code
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu


- testcase.c -
void foo (void) {};
--

Compiler output (under valgrind):
$ cc1 -O --param max-cse-path-length=0 testcase.c -quiet
==7641== Invalid read of size 8
==7641==at 0x10F8710: search_line_sse2 (lex.c:394)
==7641==by 0x10F88B9: _cpp_clean_line (lex.c:665)
==7641==by 0x10F9297: _cpp_get_fresh_line (lex.c:1886)
==7641==by 0x10FAA50: _cpp_lex_direct (lex.c:1951)
==7641==by 0x10FB836: _cpp_lex_token (lex.c:1825)
==7641==by 0x10FE0BF: cpp_get_token (macro.c:1239)
==7641==by 0x10FE21F: cpp_get_token_with_location (macro.c:1351)
==7641==by 0x56ABA2: c_lex_with_flags (c-lex.c:302)
==7641==by 0x521983: c_lex_one_token (c-parser.c:216)
==7641==by 0x534237: c_parse_file (c-parser.c:398)
==7641==by 0x570274: c_common_parse_file (c-opts.c:1092)
==7641==by 0x9002EB: toplev_main (toplev.c:579)
==7641==  Address 0x7231680 is 16 bytes inside a block of size 21 alloc'd
==7641==at 0x4C29504: realloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==7641==by 0x1121D9C: xrealloc (xmalloc.c:179)
==7641==by 0x10ED063: _cpp_convert_input (charset.c:1734)
==7641==by 0x10F5F52: read_file (files.c:648)
==7641==by 0x10F68FA: _cpp_stack_file (files.c:723)
==7641==by 0x10F8135: cpp_read_main_file (init.c:570)
==7641==by 0x56F92A: c_common_post_options (c-opts.c:1031)
==7641==by 0x8FFCF6: toplev_main (toplev.c:1283)
==7641==by 0x644AB6C: (below main) (in /lib64/libc-2.11.3.so)
==7641== 
==7641== Invalid write of size 8
==7641==at 0x101CE2E: cse_main (cse.c:6118)
==7641==by 0x101E05D: rest_of_handle_cse (cse.c:7380)
==7641==by 0x8132C5: execute_one_pass (passes.c:1555)
==7641==by 0x8135A4: execute_pass_list (passes.c:1610)
==7641==by 0x8135B6: execute_pass_list (passes.c:1611)
==7641==by 0x95B4AA: tree_rest_of_compilation (tree-optimize.c:423)
==7641==by 0xB3E632: cgraph_expand_function (cgraphunit.c:1576)
==7641==by 0xB40B4B: cgraph_optimize (cgraphunit.c:1635)
==7641==by 0xB410D9: cgraph_finalize_compilation_unit (cgraphunit.c:1096)
==7641==by 0x4F9623: c_write_global_declarations (c-decl.c:9883)
==7641==by 0x900327: toplev_main (toplev.c:591)
==7641==by 0x644AB6C: (below main) (in /lib64/libc-2.11.3.so)
==7641==  Address 0x7527030 is 0 bytes inside a block of size 1 alloc'd
==7641==at 0x4C26F30: malloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==7641==by 0x1121D07: xmalloc (xmalloc.c:147)
==7641==by 0x101CC54: cse_main (cse.c:6473)
==7641==by 0x101E05D: rest_of_handle_cse (cse.c:7380)
==7641==by 0x8132C5: execute_one_pass (passes.c:1555)
==7641==by 0x8135A4: execute_pass_list (passes.c:1610)
==7641==by 0x8135B6: execute_pass_list (passes.c:1611)
==7641==by 0x95B4AA: tree_rest_of_compilation (tree-optimize.c:423)
==7641==by 0xB3E632: cgraph_expand_function (cgraphunit.c:1576)
==7641==by 0xB40B4B: cgraph_optimize (cgraphunit.c:1635)
==7641==by 0xB410D9: cgraph_finalize_compilation_unit (cgraphunit.c:1096)
==7641==by 0x4F9623: c_write_global_declarations (c-decl.c:9883)
==7641== 
==7641== Invalid read of size 8
==7641==at 0x101D218: cse_main (cse.c:6266)
==7641==by 0x101E05D: rest_of_handle_cse (cse.c:7380)
==7641==by 0x8132C5: execute_one_pass (passes.c:1555)
==7641==by 0x8135A4: execute_pass_list (passes.c:1610)
==7641==by 0x8135B6: execute_pass_list (passes.c:1611)
==7641==by 0x95B4AA: tree_rest_of_compilation (tree-optimize.c:423)
==7641==by 0xB3E632: cgraph_expand_function (cgraphunit.c:1576)
==7641==by 0xB40B4B: cgraph_optimize (cgraphunit.c:1635)
==7641==by 0xB410D9: cgraph_finalize_compilation_unit (cgraphunit.c:1096)
==7641==by 0x4F9623: c_write_global_declarations (c-decl.c:9883)
==7641==by 0x900327: toplev_main (toplev.c:591)
==7641==by 0x644AB6C: (below main) (in /lib64/libc-2.11.3.so)
==7641==  Address 0x7527030 is 0 bytes inside a block of size 1 alloc'd
==7641==at 0x4C26F30: malloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==7641==by 0x1121D07: xmalloc (xmalloc.c:147)
==7641==by 0x101CC54: cse_main (cse.c:6473)
==7641==by 0x101E05D: rest_of_handle_cse (cse.c:7380)
==7641==by 0x8132C5: execute_one_pass (passes.c:1555)
==7641==by 0x8135A4: execute_pass_list (passes.c:1610)
==7641==by 0x8135B6: execute_pass_list (passes.c:1611)
==7641==by 0x95B4AA: tree_rest_of_compilation (tr

[Bug libfortran/25830] [libgfortran] Optionally support multi-process locking

[jb at gcc dot gnu.org]

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

--- Comment #4 from Janne Blomqvist  2011-04-25 16:41:26 
UTC ---
Some writings arguing that POSIX locking is more or less fundamentally broken:

http://0pointer.de/blog/projects/locking.html

http://0pointer.de/blog/projects/locking2.html

http://www.samba.org/samba/news/articles/low_point/tale_two_stds_os2.html

AFAICS, if gfortran is to eventually support multi-image IO in the context of
Co-array Fortran as in the TR

http://j3-fortran.org/doc/meeting/192/10-166.pdf ,

it is possible to implement all of this without relying on POSIX locking
(fcntl) for synchronization, instead using the existing IPC channels that
co-arrays provide. 

That being said, it might be necessary to do a fcntl lock+unlock at appropriate
places in order to force the NFS client to flush dirty bytes to the server;
alternatives to using fcntl() to force NFS flushing is fsync or a close+reopen
of the POSIX file descriptor. Close+reopen does have the nice property of being
portable and not relying on a working NFS locking implementation.

FWIW, one strange thing about the 10-166 TR is that there is no mention of
stream access, which AFAICS is suited to parallel access just like direct
access.

[Bug libstdc++/48760] [4.6 / 4.7 Regression (?)] std::complex constructor buggy in the face of NaN's

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC||g...@integrable-solutions.ne
   ||t

--- Comment #6 from Paolo Carlini  2011-04-25 
16:46:39 UTC ---
Gaby, can you give me an opinion on this? Now the constructor is constexpr,
thus we can't have a non-empty body. I can't believe that now we can't fix this
without new builtins, and I have yet to understand why the same library code
worked fine in 4.5.x and also together with current ICC...

[Bug lto/48763] New: Inliner type ICE

[hubicka at gcc dot gnu.org]

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

   Summary: Inliner type ICE
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hubi...@gcc.gnu.org


Hi,
Mozilla now gets the following ICE:

jh@evans:~> cat t1.C
extern "C" {
  void StoreSpline(int ax, int ay, int bx, int by, int cx, int cy, int dx, int
dy);
}
static int crash_ax;
static int crash_ay;
static int crash_bx;
static int crash_by;
static int crash_cx;
static int crash_cy;
static int crash_dx;
static int crash_dy;

void
StoreSpline(int ax, int ay, int bx, int by, int cx, int cy, int dx, int dy) {
crash_ax = ax;
crash_ay = ay;
crash_bx = bx;
crash_by = by;
crash_cx = cx;
crash_cy = cy;
crash_dx = dx;
crash_dy = dy;
}

jh@evans:~> cat t2.c
void StoreSpline(int ax, int ay, int bx, int by, int cx, double cy, int dx, int
dy);
int a;
double b;
main(void)
{
  StoreSpline (a,a,a,a,a,b,a,a);
}
jh@evans:~> /abuild/jh/trunk-install/bin/gcc -O3 -flto t2.c t1.C 
In file included from :1:0:
t2.c: In function 'main':
t2.c:4:1: error: conversion of register to a different size
VIEW_CONVERT_EXPR(b.1_3);

cy_11 = VIEW_CONVERT_EXPR(b.1_3);

t2.c:4:1: internal compiler error: verify_gimple failed
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
lto-wrapper: /abuild/jh/trunk-install/bin/gcc returned 1 exit status
collect2: lto-wrapper returned 1 exit status


Seems the code marking edges uninlinable during type merging doen't quite do
the job.

[Bug lto/48763] Inliner type ICE

[hubicka at gcc dot gnu.org]

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

--- Comment #1 from Jan Hubicka  2011-04-25 
17:04:55 UTC ---
OK,
the problem is that we check only return types for compatibility:
244   /* Redirect all incoming edges.  */
245   compatible_p
246 = gimple_types_compatible_p (TREE_TYPE (TREE_TYPE
(prevailing_node->decl)),
247  TREE_TYPE (TREE_TYPE (node->decl)),
GTC_DIAG);

Honza

[Bug c++/48707] [4.6/4.7 Regression] [c++0x] ICE initializing static const int

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2011.04.25 17:13:33
 CC||jason at gcc dot gnu.org
 AssignedTo|unassigned at gcc dot   |jason at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

[Bug libstdc++/48760] [4.6 / 4.7 Regression (?)] std::complex constructor buggy in the face of NaN's

[john at johnmaddock dot co.uk]

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

--- Comment #7 from John Maddock  2011-04-25 
17:21:15 UTC ---
Sorry to be dumb, but doesn't the result of the C code violate section G.5.2 in
C99 - which is to say that no matter what the value of the imaginary part of an
expression, it never changes the real part - even if that is a NaN?

[Bug libstdc++/48760] [4.6 / 4.7 Regression (?)] std::complex constructor buggy in the face of NaN's

[gdr at gcc dot gnu.org]

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

Gabriel Dos Reis  changed:

   What|Removed |Added

 CC||gdr at gcc dot gnu.org

--- Comment #8 from Gabriel Dos Reis  2011-04-25 
17:57:15 UTC ---
(In reply to comment #1)
> I don't think this is a library proper issue, how can it be? We have just:
> 
>   constexpr // In C++0x mode
>   complex(float __r = 0.0f, float __i = 0.0f)
>   : _M_value(__r + __i * 1.0fi) { }

I believe we need a compiler support to construct a complex
value from its independent components -- instead of the low-level
C-style assignments that we are currently forced to do (or use
multiplication.)   I think that is the way to go.

-- Gaby

[Bug libstdc++/48760] [4.6 / 4.7 Regression (?)] std::complex constructor buggy in the face of NaN's

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

--- Comment #9 from Paolo Carlini  2011-04-25 
18:10:34 UTC ---
I guess, in the 4.6.1 time frame we can only workaround the issue in C++03 mode
by doing the piecewise work in the body. I can maybe help for the compiler work
too but I need more guidance: is there an agreement about the C1X inspired
builtin suggested by Joseph? In case, can I have a more specific reference?

I'm adding in CC Richi too, in case he has additional tips and/or hints about
the builtin work..

[Bug testsuite/48753] [4.7 Regression] FAIL: gcc.dg/tree-prof/val-prof-2.c

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2011.04.25 18:42:40
  Component|middle-end  |testsuite
 AssignedTo|unassigned at gcc dot   |rguenth at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

--- Comment #2 from Richard Guenther  2011-04-25 
18:42:40 UTC ---
Mine.  Looks like a testsuite issue.

[Bug fortran/48720] quad precision literals do not work

[kargl at gcc dot gnu.org]

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

--- Comment #7 from kargl at gcc dot gnu.org 2011-04-25 18:44:48 UTC ---
See

http://gcc.gnu.org/ml/gcc-patches/2011-04/msg01986.html

for a patch.

[Bug tree-optimization/48764] New: wrong-code bug in gcc-4.5.x, related to __restrict

[wouter.vermaelen at scarlet dot be]

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

   Summary: wrong-code bug in gcc-4.5.x, related to __restrict
   Product: gcc
   Version: 4.5.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: wouter.vermae...@scarlet.be


I had originally posted this on gcc-help because I wasn't sure it was an actual
compiler bug or undefined behavior. Ian Lance Taylor replied that he didn't see
any undefined behavior. So I'm reporting it now as a bug.

Here's the original message:
   http://gcc.gnu.org/ml/gcc-help/2011-04/msg00476.html
But I'll repeat it below:





Hi all,

I believe I found a wrong-code bug. The problem triggers when using
gcc-4.5.1, 4.5.2 or 4.5.3, but not when using 4.4.5 or 4.7.0 (snapshot
20110419). It also only triggers with certain optimization levels/flags.
I wonder if this is a known problem and already fixed in 4.7.0, or that
the problem still exists but for some reason doesn't trigger in 4.7.0
(I couldn't easily find something in bugzilla).


Below is a reduced test-case that shows the problem. I tried, but I
couldn't get it smaller than these 4 files (combined about 60 lines).


While reducing this problem I realized that it *might* not be a compiler
bug, but undefined behaviour with the usage of __restrict in
Buffer::read(). What I wanted to express there is that the memory write
done by memcpy() can never overwrite the member variable 'p'. At the
moment I still believe it's a compiler bug, but I'm not 100% sure
anymore.


So is this a compiler bug or undefined behavior in my program? In case
of the latter I would appreciate if someone could explain what the
problem is and maybe suggest a way to fix it.


Thanks.

Wouter


BTW: The code for gcc-4.7.0 is correct but contains some useless extra
instructions (which I tried to avoid with __restrict). I'd also appreciate
hints on how to improve the generate code.
I do realize that the code in this reduced test-case may look a bit silly
and that suggestions to optimize the code may be hard because of this.






/// FooBar.hh /

struct Loader;
struct FooBar {
void load(Loader& l);
char c1, c2;
};




/// Loader.hh /

#include 

struct Buffer {
Buffer(const char* data) : p(data) {}
void read(void* __restrict out) __restrict {
memcpy(out, p, 1);
++p;
}
const char* p;
};


template struct Base {
void load2(char& t) {
Derived& self = static_cast(*this);
self.load1(t);
}
int dummy;
};


struct Loader : Base {
Loader(const char* data) : buffer(data) {}
void load1(char& t) { buffer.read(&t); }
Buffer buffer;
};




/// FooBar.cc /

#include "FooBar.hh"
#include "Loader.hh"
#include 


void FooBar::load(Loader& l)
{
l.load1(c1);
//printf("This print hides the bug\n");
l.load2(c2);
}




/// main.cc ///

#include "FooBar.hh"
#include "Loader.hh"
#include 


int main()
{
char data[2] = { 3, 5 };
Loader loader(data);
FooBar fb;
fb.load(loader);


if ((fb.c1 == 3) && (fb.c2 == 5)) {
printf("Ok\n");
} else {
printf("Wrong!\n");
}
}




> g++ --version
g++ (GCC) 4.5.3 20110423 (prerelease)


> uname -a
Linux argon 2.6.35-28-generic #49-Ubuntu SMP Tue Mar 1 14:39:03 UTC 2011 x86_64
GNU/Linux


> g++ -O3 FooBar.cc -c
> g++ -O3 main.cc -c
> g++ -o bug FooBar.o main.o


> ./bug
Wrong!






> objdump -d FooBar.o  (gcc-4.5.3 prerelease)
  mov0x8(%rsi),%rdx
  lea0x8(%rsi),%rax
  movzbl (%rdx),%edx
  mov%dl,(%rdi)
  mov0x8(%rsi),%rdx  <-- WRONG: still uses original value of Buffer::p
  addq   $0x1,(%rax) <-- it is only increased here (for the 1st time)
  movzbl (%rdx),%edx
  mov%dl,0x1(%rdi)
  addq   $0x1,(%rax)
  retq



> objdump -d FooBar.o  (gcc-4.7.0 20110419)
  mov0x8(%rsi),%rax
  movzbl (%rax),%edx
  mov%dl,(%rdi)
  lea0x1(%rax),%rdx   <-- correct, but I know this is not
  mov%rdx,0x8(%rsi)   <-- required for my application
  movzbl 0x1(%rax),%edx
  add$0x2,%rax
  mov%dl,0x1(%rdi)
  mov%rax,0x8(%rsi)
  retq

[Bug debug/48670] explosion in time and stack usage when using -ggdb

[matt at use dot net]

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

--- Comment #4 from Matt Hargett  2011-04-25 18:55:36 UTC 
---
ping? Anything else you need from me on this?

[Bug middle-end/48722] ICE in df_refs_verify() with -mno-push-args

[pthaugen at gcc dot gnu.org]

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

--- Comment #1 from Pat Haugen  2011-04-25 
20:47:52 UTC ---
Created attachment 24095
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24095
reduced testcase

Similar failure on powerpc64-linux when building cpu2006 benchmark 435.gromacs.

> /home/pthaugen/install/gcc/trunk/bin/gcc -c -m64 -O2 -mcpu=power6 pdbio.c
pdbio.c: In function ‘write_pdbfile_indexed’:
pdbio.c:65:1: internal compiler error: in df_refs_verify, at df-scan.c:4267
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug tree-optimization/48765] New: ICE in vect_transform_stmt

[pthaugen at gcc dot gnu.org]

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

   Summary: ICE in vect_transform_stmt
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: pthau...@gcc.gnu.org
CC: berg...@gcc.gnu.org, meiss...@gcc.gnu.org
  Host: powerpc64-linux
Target: powerpc64-linux
 Build: powerpc64-linux


Created attachment 24096
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24096
reduced testcase

Following showed up recently in build of cpu2000 benchmark 176.gcc.

> /home/pthaugen/install/gcc/trunk/bin/gcc -c -m64 -O3 -mcpu=power6 stupid.c
stupid.c: In function ‘stupid_life_analysis’:
stupid.c:33:1: internal compiler error: in vect_transform_stmt, at
tree-vect-stmts.c:4867
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug libstdc++/48760] [4.6 / 4.7 Regression (?)] std::complex constructor buggy in the face of NaN's

[gdr at gcc dot gnu.org]

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

Gabriel Dos Reis  changed:

   What|Removed |Added

 CC||jason at redhat dot com

--- Comment #10 from Gabriel Dos Reis  2011-04-25 
21:38:59 UTC ---
(In reply to comment #9)
> I guess, in the 4.6.1 time frame we can only workaround the issue in C++03 
> mode
> by doing the piecewise work in the body. I can maybe help for the compiler 
> work
> too but I need more guidance: is there an agreement about the C1X inspired
> builtin suggested by Joseph? In case, can I have a more specific reference?
> 
> I'm adding in CC Richi too, in case he has additional tips and/or hints about
> the builtin work..

I believe in 4.6.1 it should still be possible to have the initialization
from components.  All we need is to be able to write

complex(float __r, float __i) : _M_value{__r,__i} { }

or

complex(float __r, float __i) : _M_value({__r, __i}) { }

the work that people are testing really isn't C++03, it is C++0x.
It is fine if the C people don't want it.  But in C++0x, we already
have the syntax (so no parser surgery is needed).  All that remains is
to have the C++ front-end elaborate that syntax into the proper 
initialization (ideal outcome) or a sequence of assignment (less ideal.)
Note that we already have that syntax for iniialization of array members
and a _Complex is supposed to behave like a 2-element array...

It is good that Richi is in the CC (as a RM) but, I suspect Jason should
be too. 

-- Gaby

[Bug c++/48707] [4.6/4.7 Regression] [c++0x] ICE initializing static const int

[jason at gcc dot gnu.org]

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

--- Comment #2 from Jason Merrill  2011-04-25 
21:51:36 UTC ---
Author: jason
Date: Mon Apr 25 21:51:33 2011
New Revision: 172941

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172941
Log:
PR c++/48707
* decl.c (type_dependent_init_p): New.
(cp_finish_decl): Check it.
* pt.c (any_type_dependent_elements_p): New.
* cp-tree.h: Declare it.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/regress/template-const2.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/decl.c
trunk/gcc/cp/pt.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/48707] [4.6/4.7 Regression] [c++0x] ICE initializing static const int

[jason at gcc dot gnu.org]

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

--- Comment #3 from Jason Merrill  2011-04-25 
21:54:04 UTC ---
Author: jason
Date: Mon Apr 25 21:53:57 2011
New Revision: 172942

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172942
Log:
PR c++/48707
* pt.c (value_dependent_expression_p): Handle type-dependent
expression.

Added:
   
branches/gcc-4_6-branch/gcc/testsuite/g++.dg/cpp0x/regress/template-const2.C
Modified:
branches/gcc-4_6-branch/gcc/cp/ChangeLog
branches/gcc-4_6-branch/gcc/cp/pt.c
branches/gcc-4_6-branch/gcc/testsuite/ChangeLog

[Bug c++/48707] [4.6/4.7 Regression] [c++0x] ICE initializing static const int

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #4 from Jason Merrill  2011-04-25 
21:54:31 UTC ---
Fixed.

[Bug libstdc++/48760] [4.6 / 4.7 Regression (?)] std::complex constructor buggy in the face of NaN's

[paolo.carlini at oracle dot com]

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

--- Comment #11 from Paolo Carlini  2011-04-25 
22:04:56 UTC ---
Thanks Gaby, your analysis certainly helps. Let's see what Jason, thinks, then.

[Bug middle-end/48663] [4.7 regression] final.c:dump_basic_block_info breaks several Tru64 UNIX tests

[hp at gcc dot gnu.org]

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

Hans-Peter Nilsson  changed:

   What|Removed |Added

 CC||hp at gcc dot gnu.org

--- Comment #2 from Hans-Peter Nilsson  2011-04-26 
00:19:37 UTC ---
I believe this was fixed by commit r172682, "Mon Apr 18 23:58:49 2011".
If so, please confirm and close.

[Bug tree-optimization/48766] New: Infinite recursion in fold_binary_loc()

[arthur.j.odwyer at gmail dot com]

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

   Summary: Infinite recursion in fold_binary_loc()
   Product: gcc
   Version: 4.4.5
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: arthur.j.odw...@gmail.com


Created attachment 24097
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24097
Output of "ajo-gcc -O2 -fwrapv -ftrapv -S test746998981.c -v"

The following test case causes gcc to enter an infinite regress, recursing
among fold_binary_loc() and fold_build2_stat_loc(). They can't decide whether
the tree should contain a MINUS_EXPR or a PLUS_EXPR.  This reproduces for me
with svn revision 172796 (2011-04-20), and at least as far back as gcc 4.4.5.
I'm on Ubuntu 10.10, x86-64.  Attached "gcc-v.txt".

cat >test746998981.c  test746998981.c

[Bug c/48767] New: compiler error: Segmentation fault with set void in va_arg

[iwamatsu at nigauri dot org]

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

   Summary: compiler error: Segmentation fault with set void in
va_arg
   Product: gcc
   Version: 4.4.6
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: iwama...@nigauri.org
CC: kkoj...@gcc.gnu.org
  Host: sh4-linux-gnu
Target: sh4-linux-gnu
 Build: sh4-linux-gnu


Hi,

When we set void in va_arg, it becomes Segmentation fault.
This problem was confirmed on gcc-4.3, 4.4, 4.5 and 4.6.

$ cat a.c
#include 
void f(va_list ap) { va_arg(ap,void); }
$ gcc -c  a.c
a.c: In function 'f':
a.c:2: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

$gcc -v 
Using built-in specs.
Target: sh4-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.4.6-2'
--with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.4 --enable-shared --enable-multiarch
--with-multiarch-defaults=sh4-linux-gnu --enable-linker-build-id
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.4
--libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug
--enable-objc-gc --with-multilib-list=m4,m4-nofpu --with-cpu=sh4
--enable-checking=release --build=sh4-linux-gnu --host=sh4-linux-gnu
--target=sh4-linux-gnu
Thread model: posix
gcc version 4.4.6 (Debian 4.4.6-2)

[Bug middle-end/48752] [4.7 Regression] ICE in evaulate_conditions_for_edge at ipa-inline-analysis.c:466

[danglin at gcc dot gnu.org]

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

--- Comment #7 from John David Anglin  2011-04-26 
01:57:57 UTC ---
ICE occurs at i==2.

Breakpoint 1, evaulate_conditions_for_edge (e=0x78730cf0, inline_p=1 '\001') at
../../gcc/gcc/ipa-inline-analysis.c:481
481   tree val = VEC_index (tree, known_vals, c->operand_num);
(gdb) p i
$6 = 2
(gdb) p *c
$7 = {val = 0x0, operand_num = 1, code = ERROR_MARK}
(gdb) p *known_vals
$9 = {base = {num = 1, alloc = 1, vec = {0x7af2ab28}}}
(gdb) p debug_tree (e->callee->decl)
 >
SI
size 
unit size 
align 32 symtab 0 alias set -1 canonical type 7861ae40
arg-types 
chain >>
pointer_to_this >
addressable used static in_system_header decl_5 SI file
/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include/bits/unordered_set.h
line 398 col 1 align 32 initial 
arguments  unit size 
align 32 symtab 8 alias set 5 canonical type 7af3b2a0 precision 32
min  max 
pointer_to_this  reference_to_this
>
used SI file
/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include/bits/unordered_set.h
line 398 col 1 size  unit size 
align 32 context  arg-type 
chain 
used SI file
/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include/bits/unordered_set.h
line 398 col 1 size  unit size 
align 32 context  arg-type >>
result 
ignored VOID file
/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include/bits/unordered_set.h
line 398 col 1
align 8 context >
full-name "void
_Z41__static_initialization_and_destruction_0ii.constprop.19(int)"
pending-inline-info 785a8ee0>
$16 = void
(gdb) p debug_tree (e->caller->decl)
 >
type_6 SI
size 
unit size 
align 32 symtab 420 alias set -1 canonical type 7af478a0
arg-types >
pointer_to_this >
used public static in_system_header preserve SI file
/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include/bits/unordered_set.h
line 398 col 1 align 32 initial 
result 
VOID file
/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include/bits/unordered_set.h
line 398 col 1
align 8 context >
struct-function 79bc1580>

[Bug middle-end/48752] [4.7 Regression] ICE in evaulate_conditions_for_edge at ipa-inline-analysis.c:466

[danglin at gcc dot gnu.org]

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

John David Anglin  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org

--- Comment #8 from John David Anglin  2011-04-26 
02:30:52 UTC ---
Looks like the issue is somehow caused by caller being a global
constructor.

I believe it should be possible to reproduce with a cross.

[Bug tree-optimization/48768] New: ICE in get_expr_operands()

[arthur.j.odwyer at gmail dot com]

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

   Summary: ICE in get_expr_operands()
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: arthur.j.odw...@gmail.com


Created attachment 24098
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24098
Output of "ajo-gcc -O1 -finline-small-functions test746970675.c -g -c -v"

This reproduces for me with svn revision 172950 (2011-04-25), but it doesn't
reproduce with gcc-4.5.  I'm on Ubuntu 10.10, x86-64.  Attached "gcc-v.txt".

cat >test746970675.c < 0 && si1 > si2) || (si1 < 0 && si1 < si2) ? 0 : (si1 + 1);
}
int func_75() {
int i, l_90 = 1;
for (i = 0; i != 10; i = foo(i, 1)) {
  lbl_131:
if (i) {
int *l_126 = &l_90;
} else if (l_90)
goto lbl_131;
}
return 0;
}
unsigned func_58(int p_59) {
return g_23;
}
int func_62() {
unsigned char p_67;
int i, p_63;
if (func_58(func_75())) {
return 0;
} else {
for (p_67 = 250; p_67 > 0; p_67 += 6) {
for (i = 10; i >= 0; --i) {
if (func_58(p_63) >= 0u) {
p_63 = func_75();
g_79 = (g_23 < 0) ? 0 : (g_23 - 1);
}
}
}
}
return p_63;
}
EOF
gcc -O1 -finline-small-functions test746970675.c -g -c


unhandled expression in get_expr_operands():
 

test746970675.c: In function ‘func_62’:
test746970675.c:19:5: internal compiler error: in get_expr_operands, at
tree-ssa-operands.c:1024


This test case is reduced from the output of Csmith
(http://embed.cs.utah.edu/csmith/), using the following command line:
csmith --bitfields --packed-struct -s 746970675 > test746970675.c

[Bug target/48723] ICE in ix86_expand_prologue() with -fstack-check + function returning struct, on corei7-avx

[zsojka at seznam dot cz]

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

--- Comment #9 from Zdenek Sojka  2011-04-26 06:10:02 
UTC ---
This task is in state RESOLVED FIXED, but the testcase still ICEs in current
trunk (r172940, x86_64-linux) as the fix was reverted. Where can I track this
ICE? Thanks

[Bug tree-optimization/48734] [4.6/4.7 Regression] ICE in eliminate_redundant_comparison, at tree-ssa-reassoc.c:1321

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.04.26 06:14:36
  Component|c   |tree-optimization
 CC||jakub at gcc dot gnu.org
 Ever Confirmed|0   |1
Summary|ICE in  |[4.6/4.7 Regression] ICE in
   |eliminate_redundant_compari |eliminate_redundant_compari
   |son, at |son, at
   |tree-ssa-reassoc.c:1321 |tree-ssa-reassoc.c:1321
   Target Milestone|--- |4.6.1

--- Comment #1 from Jakub Jelinek  2011-04-26 
06:14:36 UTC ---
Related to PR45059, caused by
http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159189

[Bug target/48769] New: [4.7 Regression] Multiple failures in libjava for -m64 on powerpc-apple-darwin9

[dominiq at lps dot ens.fr]

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

   Summary: [4.7 Regression] Multiple failures in libjava for -m64
on powerpc-apple-darwin9
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: domi...@lps.ens.fr
CC: ia...@gcc.gnu.org
  Host: powerpc-apple-darwin9
Target: powerpc-apple-darwin9
 Build: powerpc-apple-darwin9


Between revisions 172592 and 172898 multiple failures appeared in libjava for
-m64 on powerpc-apple-darwin9 (see
http://gcc.gnu.org/ml/gcc-testresults/2011-04/msg02373.html). My G5 will be
down for at least the next two weeks and I'll be out of town for this period of
time, so I'll unable to do further testing before mid May.

[Bug libfortran/48589] Invalid G0/G0.d editing for NaN/infinity

[thenlich at users dot sourceforge.net]

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

Thomas Henlich  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #6 from Thomas Henlich  
2011-04-26 06:40:41 UTC ---
Tested ok on snapshot 20110423.

[Bug tree-optimization/48734] [4.6/4.7 Regression] ICE in eliminate_redundant_comparison, at tree-ssa-reassoc.c:1321

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  2011-04-26 
06:56:46 UTC ---
Reduced testcase:

unsigned int
foo (int x, unsigned int y, unsigned int z)
{
  z &= (x == -__INT_MAX__ - 1 ? x : -x) > y;
  z &= (x == -__INT_MAX__ - 1 ? x : -x) > y;
  z &= (x == -__INT_MAX__ - 1 ? x : -x) > y;
  return z;
}

The problem is that fold (from maybe_fold_and_comparisons) in this case
canonicalizes the comparison in:
/* The following case also applies to X < signed_max+1
   and X >= signed_max+1 because previous transformations.  */
if (code == LE_EXPR || code == GT_EXPR)
  {
tree st;
st = signed_type_for (TREE_TYPE (arg1));   
return fold_build2_loc (loc,
code == LE_EXPR ? GE_EXPR : LT_EXPR,
type, fold_convert_loc (loc, st, arg0),
build_int_cst (st, 0));
  }
to include the extra cast to the signed cast and eliminate_redundant_comparison
is prepared to handle just one operation instead of two.  I think expecting
fold to return some particular form of result is just wrong assumption, it will
break sooner or later, so while the code could perhaps handle on extra cast or
something similar, it needs to give up on elimination if the returned
expression can't be handled.