[Bug fortran/49010] Result of MOD and MODULO intrinsic has wrong sign

[thenlich at users dot sourceforge.net]

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

--- Comment #5 from Thomas Henlich  
2011-05-17 05:51:56 UTC ---
The fmod behaviour is correct for x < 0 according to N1548:

double fmod(double x, double y);
float fmodf(float x, float y);

The fmod functions return the value x−ny, for some integer n such that, if y is
nonzero, the result has the same sign as x and magnitude less than the
magnitude of y. If y is zero, whether  a  domain  error  occurs  or  the fmod
functions  return  zero  is  implementation-defined.

[Bug target/46655] invalid '.line 0' directive emitted with -g

[ebotcazou at gcc dot gnu.org]

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

--- Comment #30 from Eric Botcazou  2011-05-17 
05:55:57 UTC ---
> I'm now running AIX 6.1,  oslevel -s returns 6100-06-03-1048 and the 
> problem seems to persist with newer versions of gcc as well. I installed 
> gcc 4.4.6 today after having issues trying to build GNU barcode from source.
> gcc -v

Look at comment #17 or the "target milestone" field.

[Bug c/49016] always_inline causes references below the current stack pointer

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||jakub at gcc dot gnu.org
 Resolution||INVALID

--- Comment #5 from Jakub Jelinek  2011-05-17 
05:22:06 UTC ---
Yeah, 128 bytes below %rsp can be freely used on x86_64, interrupts must not
clobber those.

[Bug target/46655] invalid '.line 0' directive emitted with -g

[richard.nolde at cybox dot com]

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

--- Comment #29 from Richard Nolde  2011-05-16 
23:19:24 UTC ---
On 04/01/2011 06:24 AM, michael.haubenwallner at salomon dot at wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46655
>
> --- Comment #28 from Michael Haubenwallner dot at>  2011-04-01 12:24:32 UTC ---
> Looks like IBM "fixed" their Assembler to ignore invalid .line pseudo-ops
> again:
> https://www-304.ibm.com/support/docview.wss?uid=isg1IZ87535
I seem to be unable to use my Gcc Bugzilla account at the moment 
(waiting for an updated password token message), so I'll send this one 
to you in the hope that it adds to the known database of issues for Gcc 
on AIX. I received the URL to update my Bugzilla password and it 
accepted it but I still cannot login.  "The username or password you 
entered is not valid." comes up each time I try.

I'm now running AIX 6.1,  oslevel -s returns 6100-06-03-1048 and the 
problem seems to persist with newer versions of gcc as well. I installed 
gcc 4.4.6 today after having issues trying to build GNU barcode from source.
gcc -v
Using built-in specs.
Target: powerpc-ibm-aix6.1.0.0
Configured with: ../gcc-4.4.6/configure --with-as=/usr/bin/as 
--with-ld=/usr/bin/ld --enable-languages=c,c++,fortran 
--prefix=/opt/freeware --enable-threads 
--enable-version-specific-runtime-libs --disable-nls 
--enable-decimal-float=dpd --host=powerpc-ibm-aix6.1.0.0
Thread model: aix
gcc version 4.4.6 (GCC)

The original Makefile includes -g among the CFLAGS, which produces the 
now well documented error message from the AIX assembler as noted in 
this thread. After revisiting the GCC Bugzilla site today, I added 
initializations for all the Static variables in the source code files 
that were not arrays and were not already initialized and then I tried 
to recompile with -g in the CFLAGS. This attempt now fails with the also 
reported message:
...
/usr/bin/gcc -g -std=gnu89 -O2 -Wall -DPACKAGE_NAME=\"\" 
-DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\" 
-DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -DSTDC_HEADERS=1 
-DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 
-DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 
-DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 
-DHAVE_UNISTD_H=1 -DHAVE_STRCASECMP=1main.o cmdline.o  -L. -lbarcode 
-lpaper -lm -o barcode
ld: 0711-596 SEVERE ERROR: Object main.o
 An RLD for section 2 (.data) refers to symbol 944,
 but the storage class of the symbol is not C_EXT or C_HIDEXT.
collect2: ld returned 12 exit status
make: *** [barcode] Error 1

The only way to get a successful compile under AIX 6.1 TL 3 with IBM's 
fix-du-jour is to remove -g from the CFLAGS.
Here is the top of the GNU barcode Makefile, the rest is standard 
install targets etc.

#
# This Makefile should run fine with both pmake and gmake
#

CC = /usr/bin/gcc
CFLAGS = -std=gnu89 -O2 -Wall -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" 
-DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" 
-DPACKAGE_URL=\"\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 
-DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 
-DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 
-DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_UNISTD_H=1 -DHAVE_STRCASECMP=1
RANLIB = /usr/bin/ranlib

INSTALL = /opt/freeware/bin/install -c

LDFLAGS = -L. -l$(TARGET) -lpaper -lm

prefix = /opt/freeware
BINDIR = $(bindir)
LIBDIR = $(libdir)
INCDIR = $(includedir)
MANDIR = $(prefix)/share
MAN1DIR = $(mandir)/man1
MAN3DIR = $(mandir)/man3
INFODIR = $(infodir)

# getopt may be installed or not, if not take our copy
GETOPT_O =

TARGET = barcode
LIBRARY = lib$(TARGET).a
MAN1 = $(TARGET).1
MAN3 = $(TARGET).3
#INFO = doc/$(TARGET).info
HEADER = $(TARGET).h

LIBOBJECTS = library.o ean.o code128.o code39.o code93.o i25.o \
 msi.o plessey.o codabar.o \
 ps.o pcl.o code11.o fonts.o
EXEOBJECTS = main.o cmdline.o $(GETOPT_O)
ALLSOURCES = $(LIBOBJECTS:.o=.c) $(EXEOBJECT:.o=.c)


#Hmm... "RM" is undefined in pmake
RM = rm

#all: $(TARGET) $(LIBRARY) $(MAN1) $(MAN3) $(INFO) sample
all: $(TARGET) $(LIBRARY) sample

$(TARGET): $(LIBRARY) $(EXEOBJECTS)
 $(CC) $(CFLAGS) $(EXEOBJECTS) $(LDFLAGS) -o $(TARGET)



ALSO, FWIW, gdb 7.2.1 under AIX 6.1 coredumps when trying to print any 
variable that is a pointer to char. I can compile programs that don't 
have static variables with -g, but I get a coredump when I tried to 
debug them. I can try to create a simple test case if this is not a 
known bug.

Thanks,
   Richard Nolde

[Bug c/49016] always_inline causes references below the current stack pointer

[merrill_707_1 at yahoo dot com]

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

--- Comment #3 from Lee Merrill  2011-05-16 
22:51:33 UTC ---
A disassembly snippet to show the problem:

 :
   0:   55  push   %rbp
   1:   48 89 e5mov%rsp,%rbp
# Note that these statements reference memory below the
#   current stack pointer. So any interrupt which occurs
#   here will corrupt these variables.
   4:   48 89 7d e8 mov%rdi,-0x18(%rbp)
   8:   89 75 e4mov%esi,-0x1c(%rbp)
   b:   8b 45 e4mov-0x1c(%rbp),%eax
   e:   89 45 fcmov%eax,-0x4(%rbp)
  11:   48 8b 45 e8 mov-0x18(%rbp),%rax
  15:   48 89 45 f0 mov%rax,-0x10(%rbp)
  19:   48 8b 55 f0 mov-0x10(%rbp),%rdx
  1d:   8b 45 fcmov-0x4(%rbp),%eax
  20:   89 02   mov%eax,(%rdx)
  22:   c9  leaveq
  23:   c3  retq

[Bug c/49016] always_inline causes references below the current stack pointer

[pinskia at gcc dot gnu.org]

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

--- Comment #4 from Andrew Pinski  2011-05-16 
23:09:13 UTC ---
Well x86_64 ABI has a red zone which allows for these references to happen if
they are under 128 bytes.

[Bug c/49017] [avr] -ffunction-sections causes linker to fail

[stefan.hladnik at gmail dot com]

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

--- Comment #1 from stefan.hladnik at gmail dot com 2011-05-16 22:51:14 UTC ---
Created attachment 24259
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24259
Object files before and after linking

[Bug c/49016] always_inline causes references below the current stack pointer

[merrill_707_1 at yahoo dot com]

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

--- Comment #2 from Lee Merrill  2011-05-16 
22:49:14 UTC ---
Created attachment 24258
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24258
The output of running rc with "-v -save-temps" added.

This is the output from running the "rc" script, with gcc parameters "-v
-save-temps" added to the command line.

[Bug c/49016] always_inline causes references below the current stack pointer

[merrill_707_1 at yahoo dot com]

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

--- Comment #1 from Lee Merrill  2011-05-16 
22:45:58 UTC ---
Created attachment 24257
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24257
The source file which generates the problem

This file, when compiled via the attached "rc" script, will have references
below the current stack pointer.

[Bug c/49017] New: [avr] -ffunction-sections causes linker to fail

[stefan.hladnik at gmail dot com]

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

   Summary: [avr] -ffunction-sections causes linker to fail
   Product: gcc
   Version: 4.5.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: stefan.hlad...@gmail.com


I was compiling my code with -ffunction-sections for quite some time, so not
sure why this problem now constantly appears when using this flag. I have a
toolchain compiled with "crossdev -t avr" on gentoo, which means gcc-4.5.2 at
the moment. When linking my object file with other files "__muldi3" from
libgcc.a is linked incorrectly.

Attaching pre-linking (nol*) & post-linking (obj*) object files. I'm not really
sure about what to provide, so please let me know what you need.


Stefan

[Bug c/49016] New: always_inline causes references below the current stack pointer

[merrill_707_1 at yahoo dot com]

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

   Summary: always_inline causes references below the current
stack pointer
   Product: gcc
   Version: 4.3.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: merrill_70...@yahoo.com


Created attachment 24256
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24256
A script to run to compile t.c

When "inline __attribute__((always_inline))" is used, as is set up in some
Linux 2.6 kernel builds in gcc-compiler.h / compiler.h etc., then references to
memory below the current stack pointer can be made, when optimization is turned
off.

In fact, such references can also occur with -O2, but that is not such a simple
test program to generate. Here is a test program which generates the problem
with no optimization turned on.

To compile, run the "rc" script.

[Bug preprocessor/48677] cpp.exe broken ?

[jsm28 at gcc dot gnu.org]

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

Joseph S. Myers  changed:

   What|Removed |Added

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

--- Comment #19 from Joseph S. Myers  2011-05-16 
22:09:38 UTC ---
Fixed for 4.6.1 and 4.7.

[Bug fortran/49010] Result of MOD and MODULO intrinsic has wrong sign

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #4 from Steve Kargl  
2011-05-16 21:43:57 UTC ---
On Mon, May 16, 2011 at 09:31:57PM +, sgk at troutmask dot
apl.washington.edu wrote:
> In F95, one finds "P = 0, the result is processor dependent."
> 
> In F2003 and F2008, one finds "P shall not be zero."
> 
> Consider the code,
> 
> program foo
>real, parameter :: b = 0.
>real a, p, m1, m2
>a = 2.
>p = 0.
>m1 = mod(a, p)
>m2 = mod(a, b)

for the above case, I forgot to also make 'a' a parameter.
so simplification did not occur.  both mod and modulo is
an error if both 'a' and 'b' are constants and b = 0.
So, we are only missing a runtime error, which should 
probably be triggered with -fno-fast-math.

[Bug preprocessor/48677] cpp.exe broken ?

[jsm28 at gcc dot gnu.org]

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

--- Comment #18 from Joseph S. Myers  2011-05-16 
21:23:18 UTC ---
Author: jsm28
Date: Mon May 16 21:23:14 2011
New Revision: 173808

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=173808
Log:
PR preprocessor/48677
* cppspec.c (lang_specific_driver): Set new_decoded_options[0]
from decoded_options[0], not from itself.

Modified:
branches/gcc-4_6-branch/gcc/ChangeLog
branches/gcc-4_6-branch/gcc/cppspec.c

[Bug bootstrap/49013] [4.7 Regression] LTO bootstrap failed with bootstrap-profiled

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org
   Target Milestone|--- |4.7.0

--- Comment #1 from H.J. Lu  2011-05-16 21:26:10 
UTC ---
It is caused by revision 173794:

http://gcc.gnu.org/ml/gcc-cvs/2011-05/msg00573.html

[Bug c++/49015] New: [C++0x] Non-defining constexpr function declarations require complete argument/return types

[daniel.kruegler at googlemail dot com]

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

   Summary: [C++0x] Non-defining constexpr function declarations
require complete argument/return types
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: daniel.krueg...@googlemail.com
CC: ja...@redhat.com


After successful resolution of bug 48948 gcc 4.7.0 20110514 (experimental) in
C++0x mode now rejects the following code at the lines marked with #L-4 until
#L-13:

//---
class A;
class B;

constexpr B f(A); // #L-4

class B {
  friend constexpr B g(A); // #L-7
};

class A {};

constexpr B f(A) { return B(); } // #L-12
constexpr B g(A) { return B(); } // #L-13
//---

"4|error: invalid type for parameter 1 of constexpr function 'constexpr B
f(A)'|
4|error: invalid return type 'B' of constexpr function 'constexpr B f(A)'|
7|error: invalid type for parameter 1 of constexpr function 'constexpr B g(A)'|
7|error: invalid type for parameter 1 of constexpr function 'constexpr B g(A)'|
|In function 'constexpr B f(A)':|
12|error: redeclaration 'constexpr B f(A)' differs in 'constexpr'|
4|error: from previous declaration 'B f(A)'|
|In function 'constexpr B g(A)':|
13|error: redeclaration 'constexpr B g(A)' differs in 'constexpr'|
7|error: from previous declaration 'B g(A)'|
||=== Build finished: 8 errors, 0 warnings ===|

The parts following line 8 have mainly be added to demonstrate the general
usefulness of the non-defining declarations and the error described by #L-12
and #L-13 is possibly overlaid by bug 48945 as well, so the main aspect of this
issue are the #L-4 and #L-7 rejections if interaction with bug 48945 is the
cause of #L-12 and #L-13.

I don't think that the literal-type requirements as of 3.9 p. 10 impose the
requirements of complete types for the non-defining declarations of these
constexpr functions, IMO the requirement for the complete type is only required
for the final definition of f and g, which also seems to be intended as
described by the example of 7.1.5 p. 1. In principle these examples are also
not much different from constexpr function templates, which must delay the
evaluation until the concrete instantiation and usage (The last aspect becomes
clear by the 7.1.5 p. 1 example and demonstrates that this is a general
character of constexpr functions irrespective of templates).

[Bug c++/46071] [C++0x] ill-formed use of decltype and auto causes segfault

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #1 from Paolo Carlini  2011-05-16 
21:20:25 UTC ---
Jason, this doesn't ICE anymore in mainline, I guess thanks to your recent
work. Shall we close it as fixed / dup ?

[Bug fortran/49010] Result of MOD and MODULO intrinsic has wrong sign

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #3 from Steve Kargl  
2011-05-16 21:17:44 UTC ---
There is an additional problem with MOD(A,P) and MODULO(A,P).

In F95, one finds "P = 0, the result is processor dependent."

In F2003 and F2008, one finds "P shall not be zero."

Consider the code,

program foo
   real, parameter :: b = 0.
   real a, p, m1, m2
   a = 2.
   p = 0.
   m1 = mod(a, p)
   m2 = mod(a, b)
   print *, m1, m2
end program foo

with the __builtin_fmod function we get

troutmask:sgk[215] gfc4x -o z t.f90 && ./z
  NaN  NaN

(ie., there is no error or warning that P=0).

If we simply eliminate the __builtin_fmod function,
we get 

troutmask:sgk[212] gfc4x -o z t.f90 && ./z
   2.   2.

which is worse than the NaN. :(
__ 
Steve

[Bug c++/48969] ICE with -std=c++0x

[jason at gcc dot gnu.org]

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

--- Comment #4 from Jason Merrill  2011-05-16 
20:52:24 UTC ---
Author: jason
Date: Mon May 16 20:52:18 2011
New Revision: 173805

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=173805
Log:
PR c++/48969
* pt.c (deduction_tsubst_fntype): Use a VEC initially.

Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c

[Bug fortran/49010] Result of MOD and MODULO intrinsic has wrong sign

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #2 from kargl at gcc dot gnu.org 2011-05-16 20:44:08 UTC ---
This appears to be caused by the use of __builtin_fmod in
trans-intrinsic.c (gfc_conv_intrinsic_mod).  By hacking
the code to disallow the use of the builtin, one uses
the fallback code (which implements the simply code).

program foo
   real a, p, m1, m2
   a = -4.
   p = 2.
   m1 = mod(a, p)
   m2 = a - int(a / p) * p
   print *, m1, m2
end program foo
troutmask:sgk[239] gfc4x -o z t.f90 && ./z
   0.   0.

Thus, one gets the right answer.  Also, note

#include 
#include 
int
main(void)
{
  float a, p, m1, m2;
  a = -4.f;
  p = 2.f;
  m1 = fmodf(a, p);
  m2 = a - (int)(a / p) * p;
  printf("%f %f\n", m1, m2);
  return 0;
}
troutmask:sgk[241] cc -o z t.c -lm && ./z
-0.00 0.00

which probably means that we either want to not
use the __builtin_fmod() (which is probably some
optimized bit twiddling routine).

[Bug c++/45853] Segfault while experimenting with c++-0x initializer lists

[JamesMikeDuPont at googlemail dot com]

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

--- Comment #5 from James Michael DuPont  2011-05-16 19:17:06 UTC ---
Ok,
I will have to look into it,
thanks,
mike

On Mon, May 16, 2011 at 1:19 PM, redi at gcc dot gnu.org
 wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45853
>
> Jonathan Wakely  changed:
>
>           What    |Removed                     |Added
> 
>             Status|UNCONFIRMED                 |WAITING
>   Last reconfirmed|                            |2011.05.16 11:00:14
>     Ever Confirmed|0                           |1
>
> --- Comment #4 from Jonathan Wakely  2011-05-16 
> 11:00:14 UTC ---
> please try to reproduce this with a current FSF release or report it to Ubuntu
>
> for C++0x bugs please try 4.5 or later, lots of initializer list bugs have 
> been
> fixed already
>
> --
> Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email
> --- You are receiving this mail because: ---
> You reported the bug.
>

[Bug rtl-optimization/49014] New: ICE: in reset_sched_cycles_in_current_ebb, at sel-sched.c:7132 with even more insane set of flags

[zsojka at seznam dot cz]

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

   Summary: ICE: in reset_sched_cycles_in_current_ebb, at
sel-sched.c:7132 with even more insane set of flags
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz
CC: a...@gcc.gnu.org
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu


Created attachment 24255
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24255
reduced testcase (from gcc.dg/pr45352-3.c)

Compiler output:
$ gcc testcase.c -O -fprofile-generate -fgcse -fno-gcse-lm -fno-tree-loop-im
-funroll-loops -fno-web -fschedule-insns2 -fselective-scheduling2
-fsel-sched-pipelining -fPIC -fno-forward-propagate -ftree-vrp
testcase.c: In function 'foo':
testcase.c:11:1: internal compiler error: in reset_sched_cycles_in_current_ebb,
at sel-sched.c:7132
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Tested revisions:
r173785 - crash
4.6 r173059 - OK
4.5 r173059 - OK

[Bug bootstrap/49013] New: [4.7 Regression] LTO bootstrap failed with bootstrap-profiled

[hjl.tools at gmail dot com]

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

   Summary: [4.7 Regression] LTO bootstrap failed with
bootstrap-profiled
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hjl.to...@gmail.com


On Linux/x86-64, revision 173795 gave

../../src-trunk/gcc/read-md.c: In function 'print_c_condition':
../../src-trunk/gcc/read-md.c:230:1: internal compiler error: in
splice_child_die, at dwarf2out.c:8274
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[7]: *** [/tmp/cc1LdCxa.ltrans2.ltrans.o] Error 1
lto-wrapper: make returned 2 exit status
/usr/local/x86_64-unknown-linux-gnu/bin/ld: lto-wrapper failed
collect2: ld returned 1 exit status
make[6]: *** [build/genpreds] Error 1
In file included from ../../src-trunk/gcc/gensupport.c:312:0,
from :82:
../../src-trunk/gcc/read-md.c: In function 'read_char':
../../src-trunk/gcc/read-md.c:517:9: internal compiler error: in
splice_child_die, at dwarf2out.c:8274
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[7]: *** [/tmp/ccqJAwqa.ltrans4.ltrans.o] Error 1
make[7]: *** Waiting for unfinished jobs
lto-wrapper: make returned 2 exit status
/usr/local/x86_64-unknown-linux-gnu/bin/ld: lto-wrapper failed
collect2: ld returned 1 exit status
make[6]: *** [build/genattr] Error 1
In file included from ../../src-trunk/gcc/gensupport.c:312:0,
from :82:
../../src-trunk/gcc/read-md.c: In function 'read_char':
../../src-trunk/gcc/read-md.c:517:9: internal compiler error: in
splice_child_die, at dwarf2out.c:8274
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[7]: *** [/tmp/ccl8rWMa.ltrans4.ltrans.o] Error 1
make[7]: *** Waiting for unfinished jobs
lto-wrapper: make returned 2 exit status
/usr/local/x86_64-unknown-linux-gnu/bin/ld: lto-wrapper failed
collect2: ld returned 1 exit status
make[6]: *** [build/gencodes] Error 1
In file included from ../../src-trunk/gcc/gensupport.c:312:0,
from :82:
../../src-trunk/gcc/read-md.c: In function 'read_char':
../../src-trunk/gcc/read-md.c:517:9: internal compiler error: in
splice_child_die, at dwarf2out.c:8274
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[7]: *** [/tmp/ccMyblKa.ltrans4.ltrans.o] Error 1
make[7]: *** Waiting for unfinished jobs
lto-wrapper: make returned 2 exit status
/usr/local/x86_64-unknown-linux-gnu/bin/ld: lto-wrapper failed
collect2: ld returned 1 exit status
make[6]: *** [build/genconfig] Error 1
In file included from ../../src-trunk/gcc/gensupport.c:312:0,
from :82:
../../src-trunk/gcc/read-md.c: In function 'read_char':
../../src-trunk/gcc/read-md.c:517:9: internal compiler error: in
splice_child_die, at dwarf2out.c:8274
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[7]: *** [/tmp/ccxpFOla.ltrans5.ltrans.o] Error 1
make[7]: *** Waiting for unfinished jobs
lto-wrapper: make returned 2 exit status
/usr/local/x86_64-unknown-linux-gnu/bin/ld: lto-wrapper failed
collect2: ld returned 1 exit status
make[6]: *** [build/genflags] Error 1
In file included from ../../src-trunk/gcc/gensupport.c:320:0,
from :86:
../../src-trunk/gcc/read-md.c: In function 'read_char':
../../src-trunk/gcc/read-md.c:487:9: internal compiler error: in
splice_child_die, at dwarf2out.c:8274
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[7]: *** [/tmp/cc0kEiJc.ltrans4.ltrans.o] Error 1
make[7]: *** Waiting for unfinished jobs
In file included from ../../src-trunk/gcc/read-md.c:344:0,
from :89:
../../src-trunk/gcc/read-md.c: In function 'read_char':
../../src-trunk/gcc/read-md.c:332:9: internal compiler error: in
splice_child_die, at dwarf2out.c:8274
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
lto1: internal compiler error: in splice_child_die, at dwarf2out.c:8274
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
profiling:/export/gnu/import/svn/gcc-test-profile/bld/libiberty/filename_cmp.gcda:Invocation
mismatch - some data files may have been
removedprofiling:/export/gnu/import/svn/gcc-test-profile/bld/gcc/insn-recog.gcda:Invocation
mismatch - some data files may have been removedmake[7]: ***
[/tmp/cc0kEiJc.ltrans6.ltrans.o] Error 1
make[7]: *** [/tmp/cc0kEiJc.ltrans8.ltrans.o] Error 1
lto-w

[Bug preprocessor/48677] cpp.exe broken ?

[jsm28 at gcc dot gnu.org]

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

--- Comment #17 from Joseph S. Myers  2011-05-16 
18:34:34 UTC ---
Author: jsm28
Date: Mon May 16 18:34:31 2011
New Revision: 173801

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=173801
Log:
PR preprocessor/48677
* cppspec.c (lang_specific_driver): Set new_decoded_options[0]
from decoded_options[0], not from itself.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/cppspec.c

[Bug fortran/48955] [4.6/4.7 Regression] Wrong result for array assignment due to missing temporary

[tkoenig at netcologne dot de]

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

--- Comment #7 from tkoenig at netcologne dot de  
2011-05-16 18:10:03 UTC ---
Hi Paul,

> Indeed - I just need to find the time to sort out the logic.
> Structurally the patch is OK.

I think the logic could be as follows: You could have two flags, one
FORWARD_ALLOWED and one BACKWARD_ALLOWED.

Initialize both flags to true.

Run through all the references which could introduce a dependency.
If there is a GFC_EQUAL dependency, do nothing.  If there is a
GFC_FORWARD dependency, set BACKWARD_ALLOW to false.  If there
is a GFC_BACKWARD dependency, set FORWARD_ALLOW to false.

When selecting the loop direction:

- If FORWARD_ALLOW is set, select a forward loop; else
 If BACKWARD_ALLOW is set, select a forward loop;
else mark this dimension as needing a temporary.

Does this sound OK?

Thomas

[Bug tree-optimization/49000] [4.6/4.7 Regression] ICE: verify_ssa failed with -O2 -g

[ian at airs dot com]

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

Ian Lance Taylor  changed:

   What|Removed |Added

 CC||aoliva at gcc dot gnu.org

--- Comment #3 from Ian Lance Taylor  2011-05-16 18:01:25 
UTC ---
Adding lxo as this is related to DEBUG insns.

[Bug tree-optimization/49000] [4.6/4.7 Regression] ICE: verify_ssa failed with -O2 -g

[ian at airs dot com]

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

Ian Lance Taylor  changed:

   What|Removed |Added

 CC||ian at airs dot com,
   ||jamborm at gcc dot gnu.org

--- Comment #2 from Ian Lance Taylor  2011-05-16 18:00:37 
UTC ---
Extremely unlikely that that patch introduced the bug.  That patch just fixes a
bug introduced by

2010-09-10  Martin Jambor  

PR tree-optimization/44972
* ipa-prop.c (ipa_modify_call_arguments): Build MEM_REF instead of
calling build_ref_for_offset.

Since that patch, Martin has rewritten the code further.

Adding Martin to CC in case this is somehow related to that work.

As far as I can see, the bug here is either that a GIMPLE_DEBUG statement has
been created with a memory op, or that gimple_has_mem_ops returns false for
GIMPLE_DEBUG.

It looks like the GIMPLE_DEBUG statement is created when l_234 is addressable,
but l_234 later becomes addressable due to inlining.  So something has to
change somewhere when that happens.

[Bug c++/48999] [4.7 Regression] FAIL: g++.dg/torture/20090706-1.C due to an ICE on *-*-darwin*

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #4 from Jason Merrill  2011-05-16 
17:30:35 UTC ---
Fixed.

[Bug c++/45873] Parameter packs not expanding consistently in function return types

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  2011-05-16 
17:04:12 UTC ---
(In reply to comment #3)
> This seems like a dup of 35722.

Ah yes, it definitely is for the call to foo in my second example in
comment 2: modifying pt.c to always complain at the FIXME in
coerce_template_parms produces the "sorry" for the call to foo

45873.c2.cc: In function 'int main()':
45873.c2.cc:14:18: sorry, unimplemented: cannot expand 'Args ...' into a
fixed-length argument list
45873.c2.cc:14:18: error: no matching function for call to 'foo(int, double)'
45873.c2.cc:14:18: note: candidate is:
45873.c2.cc:8:6: note: template class T, class ... Args>
T foo(Args ...)
45873.c2.cc:15:18: error: no matching function for call to 'foo(int, double)'
45873.c2.cc:15:18: note: candidate is:
45873.c2.cc:8:6: note: template class T, class ... Args>
T foo(Args ...)

But that "sorry" isn't reached for foo or for any foo in the other
testcases.

I don't know if that means something else is going on there, or if it's just an
undiagnosed case of the same situation.

[Bug rtl-optimization/49007] ICE in extract_true_false_edges_from_block at tree-cfg.c:7379

[dave at hiauly1 dot hia.nrc.ca]

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

--- Comment #4 from dave at hiauly1 dot hia.nrc.ca 2011-05-16 16:22:28 UTC ---
On Mon, 16 May 2011, danglin at gcc dot gnu.org wrote:

> By trial and error, it appears tree-cfgcleanup.c is miscompiled at -O1
> without -fno-delayed-branch.

Attached .i file.

Dave

[Bug c++/45873] Parameter packs not expanding consistently in function return types

[jason at gcc dot gnu.org]

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

--- Comment #3 from Jason Merrill  2011-05-16 
15:42:36 UTC ---
This seems like a dup of 35722.

[Bug c/48996] fixincl on Red Hat EL 5 breaks sys/stat.h fstat64()

[psmith at gnu dot org]

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

--- Comment #5 from psmith at gnu dot org 2011-05-16 15:08:35 UTC ---
Created attachment 24253
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24253
Test invocation of fstat64()

[Bug c/48996] fixincl on Red Hat EL 5 breaks sys/stat.h fstat64()

[psmith at gnu dot org]

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

--- Comment #4 from psmith at gnu dot org 2011-05-16 15:07:40 UTC ---
I'm attaching a small test program that fails for me.  I'm just running the
compiler with "c++ -o tstfstat.o -c tstfstat.cpp"; no extra flags.

After looking more carefully I can see that when I build this without
optimization I get this problem; the ifdef around the definition of the inline
version is:

# if defined __USE_LARGEFILE64 \
  && (! defined __USE_FILE_OFFSET64 \
  || (defined __REDIRECT_NTH && defined __OPTIMIZE__))

In my system __USE_LARGEFILE64 is 1, __USE_FILE_OFFSET64 is 1, and
__REDIRECT_NTH is defined.  So, this entire if statement is true if
__OPTIMIZE__ is true, and false otherwise.

On the other hand the declaration doesn't care about __OPTIMIZE__; it declares
the function to be __inline__ regardless.

Sure enough, when I add -O2 to the compile line I don't see any complaints from
the compiler.  However that's not something I can do :-).

[Bug middle-end/27663] missed-optimization transforming a byte array to unsigned long

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

 CC||gjl at gcc dot gnu.org
  Known to fail||

--- Comment #7 from Georg-Johann Lay  2011-05-16 
15:05:41 UTC ---
The patch tries to fix the middle-end flaw in the BE by introducing some
combine patterns that recognize byte-insert.

Wouldn't it be possible to recognize such situations in the middle-end and map
them to something like (set (zero_extract:QI (reg:SI) ...)) or (set (subreg:QI
(reg:SI) ...)?

Even if the bytes inserted do not come from consecutive memory locations, such
a recognition would help.

The patch does not lead to optimal code, there is still room for improvement:

With -Os -mmcu=atmega8:

f:
push r16
push r17
/* prologue: function */
/* frame size = 0 */
/* stack size = 2 */
.L__stack_usage = 2
movw r30,r24
ldd r24,Z+1
ldd r16,Z+2
ldi r17,lo8(0)
ldi r18,lo8(0)
ldi r19,hi8(0)
movw r18,r16
clr r17
clr r16
or r19,r24
ldd r24,Z+4
or r16,r24
ldd r24,Z+3
or r17,r24
movw r22,r16
movw r24,r18
/* epilogue start */
pop r17
pop r16
ret

The usage of r16/r17 might be an artifact of IRA because only half of a SI reg
is call-saved, the other half is call-used. There is the following comment in
ira-color.c:

/* We need to save/restore the hard register in
   epilogue/prologue.  Therefore we increase the cost.  */
{
  /* ??? If only part is call clobbered.  */

Despite subreg lowering, the call-used r26/r27 are not used.

Maybe you should also try to disable subreg lowering by means of
-fno-split-wide-types. For the code in question that gives:

With -Os -mmcu=atmega8 -fno-split-wide-types:

f:
/* prologue: function */
/* frame size = 0 */
/* stack size = 0 */
.L__stack_usage = 0
movw r30,r24
ldd r18,Z+1
ldd r22,Z+2
mov r24,r22
ldi r25,lo8(0)
ldi r26,lo8(0)
ldi r27,hi8(0)
clr r23
clr r22
or r25,r18
ldd r18,Z+4
or r22,r18
ldd r18,Z+3
or r23,r18
/* epilogue start */
ret

What I do not understand are the insns clearing r26/r27 because they are dead
(which is not detected). It is an HI insn that looks like that:

; (insn 32 34 42 (set (reg:HI 26 r26 [ MEM[(unsigned char *)P_1(D) + 2B]+2 ])
; (const_int 0 [0])) insert-byte.c:5 10 {*movhi}
;  (nil))
ldi r26,lo8(0) ;  32*movhi/1[length = 2]
ldi r27,hi8(0)

[Bug c++/49003] [C++0x] decltype in member function's trailing return type should deduce constness of *this

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  2011-05-16 
14:48:13 UTC ---
A simpler test for DR 1207 being implemented is:

struct A {
auto a() const -> decltype(this) { return this; }
};

nc.cc:2:32: error: invalid use of 'this' at top level
nc.cc:2:32: error: invalid use of 'this' at top level

The late-specified return type should be accepted with the same type as the
return statement's expression i.e. const A*

[Bug target/45099] [avr] Warning could be issued for use of register variables that will fail.

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||gjl at gcc dot gnu.org
 Resolution||FIXED
   Target Milestone|--- |4.7.0

--- Comment #2 from Georg-Johann Lay  2011-05-16 
14:36:32 UTC ---
Closed as resolved+fixed according to the patch above.

The patch issues an error and not a warning as indicated in the PR. This is
because the code will break at runtime if it reaches the spot, anyway, so the
program will always show malfunction.

A global register is *global*, so it would be an error to save/restore it in
function prologue/epilogue. For that reason, avr-gcc explicitely excludes
global registers from prologue/epilogue (otherwise the value of a global reg
could never escape a function, as opposed to being global).

[Bug c++/48999] [4.7 Regression] FAIL: g++.dg/torture/20090706-1.C due to an ICE on *-*-darwin*

[jason at gcc dot gnu.org]

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

--- Comment #3 from Jason Merrill  2011-05-16 
14:30:36 UTC ---
Author: jason
Date: Mon May 16 14:30:30 2011
New Revision: 173793

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=173793
Log:
PR c++/48999
* tree-inline.c (copy_statement_list): Put back recursion.

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

[Bug c/49012] weak const optimisations

[etienne_lorrain at yahoo dot fr]

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

--- Comment #2 from etienne_lorrain at yahoo dot fr 2011-05-16 14:36:41 UTC ---
Well, with gcc-4.4.5-8 the weak attribute did the trick:

$ gcc -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.4.5-8'
--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
--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
--enable-targets=all --with-arch-32=i586 --with-tune=generic
--enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu
--target=i486-linux-gnu
Thread model: posix
gcc version 4.4.5 (Debian 4.4.5-8) 

$ cat t.c
//const struct { int a,b; } mystruct __attribute__((weak))= {15, 0};
const struct { int a,b; } mystruct = {15, 0};
int adder (int x) { return x + mystruct.b; };

$ gcc -Os -fomit-frame-pointer t.c -S -o t.s
$ cat t.s
.file"t.c"
.text
.globl adder
.typeadder, @function
adder:
movl4(%esp), %eax
ret
.sizeadder, .-adder
.globl mystruct
.section.rodata
.align 4
.typemystruct, @object
.sizemystruct, 8
mystruct:
.long15
.long0
.ident"GCC: (Debian 4.4.5-8) 4.4.5"
.section.note.GNU-stack,"",@progbits

$ cat t.c
const struct { int a,b; } mystruct __attribute__((weak))= {15, 0};
//const struct { int a,b; } mystruct = {15, 0};
int adder (int x) { return x + mystruct.b; };

$ cat t.s
.file"t.c"
.text
.globl adder
.typeadder, @function
adder:
movl4(%esp), %eax
addlmystruct+4, %eax
ret
.sizeadder, .-adder
.weakmystruct
.section.rodata
.align 4
.typemystruct, @object
.sizemystruct, 8
mystruct:
.long15
.long0
.ident"GCC: (Debian 4.4.5-8) 4.4.5"
.section.note.GNU-stack,"",@progbits

But in fact I just discovered "volatile const" structures which enables me to
have a C constant
initialised at run-time by the assembly preceding main(), so personally I do
not need this
"weak" trick.

Thanks for the quick answer,
Etienne.

[Bug middle-end/27663] missed-optimization transforming a byte array to unsigned long

[gjl at gcc dot gnu.org]

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

--- Comment #6 from Georg-Johann Lay  2011-05-16 
14:20:25 UTC ---
Author: gjl
Date: Mon May 16 14:20:19 2011
New Revision: 173792

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=173792
Log:
PR target/27663
PR target/41076
* config/avr/predicates.md (const_8_16_24_operand): New predicate.
* config/avr/avr.md ("*iorqi.byte0",
"*iorqi.byte1-3"): New define_insn_and_split patterns.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/avr/avr.md
trunk/gcc/config/avr/predicates.md

[Bug target/41076] [avr] pessimal code for logical OR of 8-bit fields

[gjl at gcc dot gnu.org]

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

--- Comment #2 from Georg-Johann Lay  2011-05-16 
14:20:25 UTC ---
Author: gjl
Date: Mon May 16 14:20:19 2011
New Revision: 173792

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=173792
Log:
PR target/27663
PR target/41076
* config/avr/predicates.md (const_8_16_24_operand): New predicate.
* config/avr/avr.md ("*iorqi.byte0",
"*iorqi.byte1-3"): New define_insn_and_split patterns.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/avr/avr.md
trunk/gcc/config/avr/predicates.md

[Bug c++/48999] [4.7 Regression] FAIL: g++.dg/torture/20090706-1.C due to an ICE on *-*-darwin*

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

   Target Milestone|--- |4.7.0

[Bug target/45099] [avr] Warning could be issued for use of register variables that will fail.

[gjl at gcc dot gnu.org]

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

--- Comment #1 from Georg-Johann Lay  2011-05-16 
14:16:30 UTC ---
Author: gjl
Date: Mon May 16 14:16:22 2011
New Revision: 173791

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=173791
Log:
PR target/45099
* config/avr/avr.c (avr_function_arg_advance): Error if a fixed
register is needed for a function argument.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/avr/avr.c

[Bug c++/48999] [4.7 Regression] FAIL: g++.dg/torture/20090706-1.C due to an ICE on *-*-darwin*

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||jason at gcc dot gnu.org
 AssignedTo|unassigned at gcc dot   |jason at gcc dot gnu.org
   |gnu.org |
   Target Milestone|4.7.0   |---

[Bug c/49012] weak const optimisations

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  2011-05-16 
13:46:10 UTC ---
You aren't compiling with -fpic, therefore the weak attribute is there
irrelevant - the symbol is known to be defined in the current TU, and for
anything that goes into the executable it can't be overridden.  Note LD_PRELOAD
inserts preloaded lib symbol search scope after executables, not before.

[Bug c/49012] New: weak const optimisations

[etienne_lorrain at yahoo dot fr]

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

   Summary: weak const optimisations
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: etienne_lorr...@yahoo.fr


With newer GCC compilers,

const struct { int a,b; } mystruct = {15, 0};
int adder (int x) { return x + mystruct.b; };

there isn't any addition performed in adder() because GCC knows that mystruct.b
is null,
and assumes that nobody is initialising mystruct.b is assembler or declaring
mystruct as
non-const in another module.

But if we add the weak attribute to mystruct, GCC-4.4.5 does the addition in
case mystruct
has been pre-loaded by for instance LD_PRELOAD, GCC-4.6 do not do the addition.

const struct { int a,b; } mystruct __attribute__((weak))= {15, 0};
int adder (int x) { return x + mystruct.b; };

LD_PRELOAD=/home/etienne/projet/toolchain/lib/libmpc.so.2:/home/etienne/projet/toolchain/lib/libgmp.so.10
/home/etienne/projet/toolchain/bin/gcc -Os -fomit-frame-pointer -S t.c -o t.s

gives:

.file"t.c"
.text
.globladder
.typeadder, @function
adder:
.LFB0:
.cfi_startproc
movl4(%esp), %eax
ret
.cfi_endproc
.LFE0:
.sizeadder, .-adder
.weakmystruct
.section.rodata
.align 4
.typemystruct, @object
.sizemystruct, 8
mystruct:
.long15
.long0
.ident"GCC: (GNU) 4.6.0"
.section.note.GNU-stack,"",@progbits

[Bug c/48996] fixincl on Red Hat EL 5 breaks sys/stat.h fstat64()

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Guenther  2011-05-16 
13:07:56 UTC ---
I don't see anything wrong with the fixinclude though it is a bit fragile
as it wants to fixup both prototype and redicrected inline function and
both are not guarded with the same #ifdefs:


#ifdef __USE_LARGEFILE64
extern int stat64 (__const char *__restrict __file,
   struct stat64 *__restrict __buf) __THROW __nonnull ((1, 2));
extern int fstat64 (int __fd, struct stat64 *__buf) __THROW __nonnull ((2));
#endif

but

# if defined __USE_LARGEFILE64 \
  && (! defined __USE_FILE_OFFSET64 \
  || (defined __REDIRECT_NTH && defined __OPTIMIZE__))
extern __inline__ int
__NTH (fstat64 (int __fd, struct stat64 *__statbuf))
{
  return __fxstat64 (_STAT_VER, __fd, __statbuf);
}
...

so if only the fixed fstat64 prototype remains after preprocessing that
will trigger the error you saw.

So, do you have a testcase that fails to build?  And which flags do
you pass?

[Bug fortran/48955] [4.6/4.7 Regression] Wrong result for array assignment due to missing temporary

[paul.richard.thomas at gmail dot com]

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

--- Comment #6 from paul.richard.thomas at gmail dot com  2011-05-16 12:48:32 UTC ---
Indeed - I just need to find the time to sort out the logic.
Structurally the patch is OK.

Cheers

Paul

On Mon, May 16, 2011 at 9:56 AM, burnus at gcc dot gnu.org
 wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48955
>
> --- Comment #5 from Tobias Burnus  2011-05-16 
> 07:27:07 UTC ---
> Submitted patch: http://gcc.gnu.org/ml/fortran/2011-05/msg00090.html
> It fixes the test case of comment 0, but (cf. review comment) it does not
> handle a modified version.
>
> --
> Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email
> --- You are receiving this mail because: ---
> You are on the CC list for the bug.
> You are the assignee for the bug.
>

[Bug target/48986] Missed optimization in atomic decrement on x86/x64

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  2011-05-16 
12:50:59 UTC ---
Created attachment 24252
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24252
gcc47-pr48986.patch

Untested patch using peephole2.

[Bug c/48996] fixincl on Red Hat EL 5 breaks sys/stat.h fstat64()

[psmith at gnu dot org]

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

--- Comment #2 from psmith at gnu dot org 2011-05-16 11:56:33 UTC ---
Created attachment 24251
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24251
Un-fixed sys/stat.h

Yes, sorry, it was silly not to have done that.

[Bug bootstrap/48679] [4.7 regression] bootstrap comparison failures on m68k-linux

[mikpe at it dot uu.se]

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

--- Comment #7 from Mikael Pettersson  2011-05-16 
12:17:45 UTC ---
The bootstrap comparison failure appears to be gone in a c-only build of
gcc-4.7-20110514.  I'll run a bisect to identify which rev fixed this bug.

[Bug c++/45873] Parameter packs not expanding consistently in function return types

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #2 from Jonathan Wakely  2011-05-16 
12:01:31 UTC ---
Jason, should deduction succeed here?

template
struct pair
{
template
pair(T1&& t, U1&& u) { }
};

template  class T, class ...Args>
auto foo(Args... args) -> T
{ return T(args...); }

int main()
{
   // error: no matching function for call to 'foo(int, double)'
   foo(1, 2.0);
}


It looks as though substituting T=pair fails because T's single parameter pack
fails to match pair's two parameters.

If pair is a variadic template with exactly one parameter pack , like p0 below,
then it matches T:

template struct p0 { };

template struct p1 { };

template struct p2 { };

template  class T, class ...Args>
auto foo(Args... args) -> T
{ return T(); }

int main()
{
   foo(1, 2.0);  // ok
   foo(1, 2.0);  // error
   foo(1, 2.0);  // error
}

Is this behaviour correct?

Clang accepts all three calls

[Bug c++/49003] [C++0x] decltype in member function's trailing return type should deduce constness of *this

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  2011-05-16 
11:09:05 UTC ---
ah I was thinking of PR 45908 (where I provided that reduced testcase - I knew
it looked familiar!) but that was for an ICE which is fixed, so this one should
be kept for the change in semantics

[Bug target/48554] Regression for coldfire platform

[mikpe at it dot uu.se]

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

--- Comment #3 from Mikael Pettersson  2011-05-16 
11:52:32 UTC ---
gcc-4.6-20110513 still ICEs on this test case, but after backporting the fix
for PR47612 (r173393) compilation succeeds.

[Bug rtl-optimization/48986] Missed optimization in atomic decrement on x86/x64

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  2011-05-16 
11:26:51 UTC ---
On:
int
foo (int *p)
{
  return __sync_fetch_and_add (p, -1) == 1;
}

int
bar (int *p)
{
  return __sync_add_and_fetch (p, -1) == 0;
}

I get better generated code for the second routine if I do:
--- gcc/config/i386/sync.md.jj 72010-05-21 11:46:29.0 +0200
+++ gcc/config/i386/sync.md 2011-05-16 13:06:13.0 +0200
@@ -170,7 +170,7 @@
   [(match_operand:SWI 1 "memory_operand" "+m")] UNSPECV_XCHG))
(set (match_dup 1)
 (plus:SWI (match_dup 1)
-  (match_operand:SWI 2 "register_operand" "0")))
+  (match_operand:SWI 2 "nonmemory_operand" "0")))
(clobber (reg:CC FLAGS_REG))]
   "TARGET_XADD"
   "lock{%;} xadd{}\t{%0, %1|%1, %0}")

and for foo identical code, so maybe that change is always beneficial, allowing
combiner and other early RTL passes to see there a constant instead of a REG.
Unfortunately, even with this change the combiner doesn't attempt to combine
this pattern with the following cmpsi_1 pattern, supposedly because
sync_old_addsi pattern isn't single_set.  I guess we could handle this during
expansion, but it would be a mess, or some other pass (e.g. peephole2 or
something similar).  peephole2 might kind of too late though, by that time the
constant must be loaded already into some register, so we'd need to peephole2 3
insns, where the load of the constant might often not be the first one.

[Bug tree-optimization/49006] [4.6/4.7 Regression] Missed vectorization due to revision 167531

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Target Milestone|--- |4.6.1

[Bug c/48996] fixincl on Red Hat EL 5 breaks sys/stat.h fstat64()

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2011.05.16 11:04:03
 Ever Confirmed|0   |1

--- Comment #1 from Richard Guenther  2011-05-16 
11:04:03 UTC ---
Please provide the un-fixincluded sys/stat.h file.

[Bug c++/48999] [4.7 Regression] FAIL: g++.dg/torture/20090706-1.C due to an ICE on *-*-darwin*

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Target Milestone|--- |4.7.0

[Bug c++/45853] Segfault while experimenting with c++-0x initializer lists

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2011.05.16 11:00:14
 Ever Confirmed|0   |1

--- Comment #4 from Jonathan Wakely  2011-05-16 
11:00:14 UTC ---
please try to reproduce this with a current FSF release or report it to Ubuntu

for C++0x bugs please try 4.5 or later, lots of initializer list bugs have been
fixed already

[Bug fortran/49011] Wrong repeat count in error message for REPEAT intrinsic

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu.org

--- Comment #2 from Tobias Burnus  2011-05-16 
10:15:03 UTC ---
With -m64:

_gfortran_runtime_error_at (&"At line 3 of file foo.f90"[1]{lb: 1 sz: 1},
&"Argument NCOPIES of REPEAT intrinsic is negative (its value is %lld)"[1]{lb:
1 sz: 1}, (integer(kind=8)) D.1547);

With -m32:

_gfortran_runtime_error_at (&"At line 3 of file foo.f90"[1]{lb: 1 sz: 1},
&"Argument NCOPIES of REPEAT intrinsic is negative (its value is %lld)"[1]{lb:
1 sz: 1}, () D.1501);


Thus, in both cases the argument value is wrongly cast; cf. POSIX's printf(3):

   ll (ell-ell)
  Specifies  that  a  following d , i , o , u , x , or X
  conversion  specifier  applies  to  a  long  long   or
  unsigned  long  long  argument;  or that a following n
  conversion specifier applies to a pointer  to  a  long
  long argument.

[Bug tree-optimization/49006] [4.6/4.7 Regression] Missed vectorization due to revision 167531

[rguenther at suse dot de]

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

--- Comment #3 from rguenther at suse dot de  
2011-05-16 10:41:58 UTC ---
On Mon, 16 May 2011, dominiq at lps dot ens.fr wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49006
> 
> --- Comment #2 from Dominique d'Humieres  
> 2011-05-16 09:24:28 UTC ---
> > The patch changes inliner heuristics only.
> 
> Yes, but the vectorization of induct.f90 is very sensitive to inlining: see
> pr34265. Did you checked the vectorization of the test case on your favorite
> platform?

I did not check it at all.  The patch causes more inlining, making the
cost of x*x the same with/without -ffast-math.

Richard.

[Bug fortran/49010] Result of MOD and MODULO intrinsic has wrong sign

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu.org

--- Comment #1 from Tobias Burnus  2011-05-16 
10:18:20 UTC ---
I obtain as result for the test program: -0  0;  -0  0

If "a" and "p" are PARAMETERs, the result is:  0  0;  0  0.

[Bug tree-optimization/49006] [4.6/4.7 Regression] Missed vectorization due to revision 167531

[dominiq at lps dot ens.fr]

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

--- Comment #2 from Dominique d'Humieres  2011-05-16 
09:24:28 UTC ---
> The patch changes inliner heuristics only.

Yes, but the vectorization of induct.f90 is very sensitive to inlining: see
pr34265. Did you checked the vectorization of the test case on your favorite
platform?

[Bug fortran/49011] Wrong repeat count in error message for REPEAT intrinsic

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.05.16 09:22:14
 Ever Confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  2011-05-16 
09:22:14 UTC ---
On x86_64-apple-darwin10, the test returns

Fortran runtime error: Argument NCOPIES of REPEAT intrinsic is negative (its
value is -1)

with -m64 (default). The value returned with -m32 depends on the version:
72057598332895231 for 4.4.4 and 4.5.2, 118064355999743 for 4.6.0 (r169227), and
4294967295 for trunk (r173786).

[Bug tree-optimization/49006] [4.6/4.7 Regression] Missed vectorization due to revision 167531

[rguenther at suse dot de]

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

--- Comment #1 from rguenther at suse dot de  
2011-05-16 08:57:46 UTC ---
On Sun, 15 May 2011, dominiq at lps dot ens.fr wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49006
> 
>Summary: [4.6/4.7 Regression] Missed vectorization due to
> revision 167531
>Product: gcc
>Version: 4.6.0
> Status: UNCONFIRMED
>   Severity: normal
>   Priority: P3
>  Component: tree-optimization
> AssignedTo: unassig...@gcc.gnu.org
> ReportedBy: domi...@lps.ens.fr
> CC: rgue...@gcc.gnu.org
> 
> 
> Created attachment 24250
>   --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24250
> source code
> 
> On x86_64-apple-darwin10 the attached code (an avatar of the polyhedron test
> induct.f90) is no longer properly vectorized after revision 167531:

The patch changes inliner heuristics only.

[Bug c++/49004] Improve the error message for linking failure

[qiaomuf at gentoo dot org]

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

Mu Qiao  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #3 from Mu Qiao  2011-05-16 08:51:02 UTC 
---
Ok, I reported this problem in the binutil bug tracker:
http://sourceware.org/bugzilla/show_bug.cgi?id=12768
Mark this as bug as invalid.

[Bug fortran/49011] New: Wrong repeat count in error message for REPEAT intrinsic

[thenlich at users dot sourceforge.net]

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

   Summary: Wrong repeat count in error message for REPEAT
intrinsic
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: thenl...@users.sourceforge.net


If the REPEAT intrinsic is given a negative NCOPIES argument at runtime, in the
resulting error message an erraneous value is printed.

Example:
program test_repeat
integer :: i = -1
print *, repeat("x", i)
end program test_repeat

$ ./a.out
At line 3 of file test_repeat.f90
Fortran runtime error: Argument NCOPIES of REPEAT intrinsic is negative (its
value is 4294967295)

Expected result:
At line 3 of file test_repeat.f90
Fortran runtime error: Argument NCOPIES of REPEAT intrinsic is negative (its
value is -1)

[Bug target/48941] [arm gcc] NEON: Stack pointer operations performed even tho stack is not accessed at all in function.

[rearnsha at gcc dot gnu.org]

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

--- Comment #4 from Richard Earnshaw  2011-05-16 
08:13:04 UTC ---
(In reply to comment #3)
> Created attachment 24234 [details]
> Proposed patch
> 
> The attached patch seems to fix the testcase and doesn't
> regress neon.exp.  I'll test it fully next week.
> We still generate more moves than necessary, but that's
> a separate problem.

I think we should try to preserve the existing internal API, so that if someone
manages to pick up an older version of arm_neon.h they won't get bizarre errors
out of the compiler.

[Bug fortran/49010] New: Result of MOD and MODULO intrinsic has wrong sign

[thenlich at users dot sourceforge.net]

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

   Summary: Result of MOD and MODULO intrinsic has wrong sign
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: thenl...@users.sourceforge.net


If the first argument to the MOD and MODULO intrinsic is negative, and the
magnitude of the result is zero, the function returns a negative zero.

Fortran 2003/2008:
MOD: The value of the result is A − INT (A/P) * P.
MODULO: The value of the result is A − FLOOR (A / P) * P.

The values returned by these intrinsics should be the same as the expressions
by which the functions are defined; which is zero, without a negative sign.

Example:
program test_mod
real :: a, p

a = -4.0
p = 2.0
print *, mod(a, p), a - int(a / p) * p ! -0 0 expected 0 0
print *, modulo(a, p), a - floor(a / p) * p ! -0 0 expected 0 0
end program test_mod

[Bug target/46934] gcc ICE: error: unrecognizable insn: in extract_insn, at recog.c:2109

[cltang at gcc dot gnu.org]

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

Chung-Lin Tang  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #6 from Chung-Lin Tang  2011-05-16 
08:09:48 UTC ---
This is fixed now.

[Bug middle-end/48989] [4.7 Regression] FAIL: gfortran.dg/lto/pr46036 f_lto_pr46036_0.o assemble

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 CC||Joost.VandeVondele at pci
   ||dot uzh.ch

--- Comment #3 from Dominique d'Humieres  2011-05-16 
07:26:55 UTC ---
*** Bug 49009 has been marked as a duplicate of this bug. ***

[Bug middle-end/49009] internal compiler error: verify_gimple failed

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE

--- Comment #1 from Dominique d'Humieres  2011-05-16 
07:26:55 UTC ---
Duplicate of 48989. A patch has been submitted at
http://gcc.gnu.org/ml/gcc-patches/2011-05/msg01033.html .

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

[Bug fortran/48955] [4.6/4.7 Regression] Wrong result for array assignment due to missing temporary

[burnus at gcc dot gnu.org]

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

--- Comment #5 from Tobias Burnus  2011-05-16 
07:27:07 UTC ---
Submitted patch: http://gcc.gnu.org/ml/fortran/2011-05/msg00090.html
It fixes the test case of comment 0, but (cf. review comment) it does not
handle a modified version.

[Bug middle-end/49009] New: internal compiler error: verify_gimple failed

[Joost.VandeVondele at pci dot uzh.ch]

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

   Summary: internal compiler error: verify_gimple failed
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: joost.vandevond...@pci.uzh.ch


current trunk fails with

> gfortran -flto -c  bug.f90
bug.f90: In function ‘__min_heap_MOD_heap_pop’:
bug.f90:13:0: error: invalid types in truth not
logical(kind=4)
logical(kind=4)
D.1556_3 = !D.1555_2;

bug.f90:13:0: internal compiler error: verify_gimple failed

> cat bug.f90
MODULE min_heap
  TYPE heap_t
 INTEGER :: n
  END TYPE heap_t
CONTAINS
  SUBROUTINE heap_pop (heap, key, value, found, error)
TYPE(heap_t), INTENT(INOUT)  :: heap
LOGICAL, INTENT(OUT) :: found, error
IF (.NOT. error .AND. found) THEN
   IF (heap%n .GT. 1) THEN
   ENDIF
ENDIF
  END SUBROUTINE heap_pop
END MODULE min_heap