[Bug regression/62102] [5 Regression]: gcc.dg/torture/pr48953.c -O2 -flto

[hubicka at ucw dot cz]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62102

--- Comment #8 from Jan Hubicka  ---
> 
> My autotester picked up that commit, and this regression is gone, thanks!
> I'm closing this PR.

Great!  I was starring in that patch and did not notice this quite obvious
omision
for at least 20 times :(  Good it is gone.
The consequences of not remapping the type were particularly confusing to deal
with...

Honza
> 
> Specifically, this regression is gone with a commit in the range
> (216146:216158], matching the commit in question.  Incidentally, at r216158
> there's only gcc.dg/tls/alias-1.c i.e. PR61548 (since I started tracking
> regressions for cris-elf in 2007).
> 
> -- 
> You are receiving this mail because:
> You are on the CC list for the bug.

[Bug c++/63531] gcc segfaults on some sourcefiles when using '-Weffc++' and '-fsanitize=undefined' together

[allizgubccg at reallysoft dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63531

--- Comment #1 from Ralf  ---
Created attachment 33711
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33711&action=edit
preprocessed file generated by segfaulting call

Sorry. needed to zip the file, because it hit the size-limit. No smaller
example known.

[Bug c++/63531] New: gcc segfaults on some sourcefiles when using '-Weffc++' and '-fsanitize=undefined' together

[allizgubccg at reallysoft dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63531

Bug ID: 63531
   Summary: gcc segfaults on some sourcefiles when using
'-Weffc++' and '-fsanitize=undefined' together
   Product: gcc
   Version: 4.9.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: allizgubccg at reallysoft dot de

gcc version: can reproduce segfault with gcc 4.9.0 and 4.9.1.
System: ubuntu 


Only happens when using '-Weffc++' and '-fsanitize=undefined' together,
removing any of them removes the problem.

Does only crash for 3 out of several hundred source files (all build with
similar switches).

command line: /opt/gcc-4.9.1/bin/g++ -v -save-temps -DDEBUG -DARB_MOTIF
-Weffc++ -fsanitize=undefined -std=gnu++11 -c MG_preserves.cxx -I.
-I/home/ralf/ARB-bilbo/ARB.sanitize.491.DEBUG/INCLUDE -I/usr/X11R6/include
-I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include

gcc output:
Using built-in specs.
COLLECT_GCC=/opt/gcc-4.9.1/bin/g++
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.9.1/configure --prefix=/opt/gcc-4.9.1 --disable-nls
Thread model: posix
gcc version 4.9.1 (GCC) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-D' 'DEBUG' '-D' 'ARB_MOTIF' '-Weffc++'
'-fsanitize=undefined' '-std=gnu++11' '-c' '-I' '.' '-I'
'/home/ralf/ARB-bilbo/ARB.sanitize.491.DEBUG/INCLUDE' '-I' '/usr/X11R6/include'
'-I' '/usr/include/glib-2.0' '-I' '/usr/lib/glib-2.0/include' '-shared-libgcc'
'-mtune=generic' '-march=x86-64'
 /opt/gcc-4.9.1/libexec/gcc/x86_64-unknown-linux-gnu/4.9.1/cc1plus -E -quiet -v
-I . -I /home/ralf/ARB-bilbo/ARB.sanitize.491.DEBUG/INCLUDE -I
/usr/X11R6/include -I /usr/include/glib-2.0 -I /usr/lib/glib-2.0/include
-D_GNU_SOURCE -D DEBUG -D ARB_MOTIF MG_preserves.cxx -mtune=generic
-march=x86-64 -std=gnu++11 -Weffc++ -fsanitize=undefined -fpch-preprocess -o
MG_preserves.ii
ignoring nonexistent directory
"/opt/gcc-4.9.1/lib/gcc/x86_64-unknown-linux-gnu/4.9.1/../../../../x86_64-unknown-linux-gnu/include"
ignoring nonexistent directory "/usr/X11R6/include"
#include "..." search starts here:
#include <...> search starts here:
 .
 /home/ralf/ARB-bilbo/ARB.sanitize.491.DEBUG/INCLUDE
 /usr/include/glib-2.0
 /usr/lib/glib-2.0/include

/opt/gcc-4.9.1/lib/gcc/x86_64-unknown-linux-gnu/4.9.1/../../../../include/c++/4.9.1

/opt/gcc-4.9.1/lib/gcc/x86_64-unknown-linux-gnu/4.9.1/../../../../include/c++/4.9.1/x86_64-unknown-linux-gnu

/opt/gcc-4.9.1/lib/gcc/x86_64-unknown-linux-gnu/4.9.1/../../../../include/c++/4.9.1/backward
 /opt/gcc-4.9.1/lib/gcc/x86_64-unknown-linux-gnu/4.9.1/include
 /usr/local/include
 /opt/gcc-4.9.1/include
 /opt/gcc-4.9.1/lib/gcc/x86_64-unknown-linux-gnu/4.9.1/include-fixed
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-D' 'DEBUG' '-D' 'ARB_MOTIF' '-Weffc++'
'-fsanitize=undefined' '-std=gnu++11' '-c' '-I' '.' '-I'
'/home/ralf/ARB-bilbo/ARB.sanitize.491.DEBUG/INCLUDE' '-I' '/usr/X11R6/include'
'-I' '/usr/include/glib-2.0' '-I' '/usr/lib/glib-2.0/include' '-shared-libgcc'
'-mtune=generic' '-march=x86-64'
 /opt/gcc-4.9.1/libexec/gcc/x86_64-unknown-linux-gnu/4.9.1/cc1plus
-fpreprocessed MG_preserves.ii -quiet -dumpbase MG_preserves.cxx -mtune=generic
-march=x86-64 -auxbase MG_preserves -Weffc++ -std=gnu++11 -version
-fsanitize=undefined -o MG_preserves.s
GNU C++ (GCC) version 4.9.1 (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.9.1, GMP version 4.3.2, MPFR version 2.4.2-p1,
MPC version 0.8.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++ (GCC) version 4.9.1 (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.9.1, GMP version 4.3.2, MPFR version 2.4.2-p1,
MPC version 0.8.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: db47d1062a26475ee5d0bac184f79f7f
In file included from MG_adapt_ali.hxx:18:0,
 from MG_preserves.cxx:16:
/home/ralf/ARB-bilbo/ARB.sanitize.491.DEBUG/INCLUDE/arb_strarray.h:31:7:
warning: 'class CharPtrArray' has pointer data members [-Weffc++]
 class CharPtrArray : virtual Noncopyable {
   ^
/home/ralf/ARB-bilbo/ARB.sanitize.491.DEBUG/INCLUDE/arb_strarray.h:31:7:
warning:   but does not override 'CharPtrArray(const CharPtrArray&)' [-Weffc++]
/home/ralf/ARB-bilbo/ARB.sanitize.491.DEBUG/INCLUDE/arb_strarray.h:31:7:
warning:   or 'operator=(const CharPtrArray&)' [-Weffc++]
In file included from MG_adapt_ali.hxx:18:0,
 from MG_preserves.cxx:16:
/home/ralf/ARB-bilbo/ARB.sanitize.491.DEBUG/INCLUDE/arb_strarray.h:163:7:
warning: 'class ConstStrArray' has pointer data members [-Weffc++]
 class ConstStrArray : public CharPtrArray { // derived from a Noncopyable
   ^
/home/ralf/ARB-bilbo/ARB.sanitize.491.DEBUG/INCLUDE/arb_strarray.h:163:7:
warning:   but does not override 'ConstStrArray(const ConstStrArray&)'
[-Weffc++]
/home/ralf/ARB-bilbo/ARB.sanitize.491.DEBUG/INCLUDE

[Bug target/63173] performance problem with simd intrinsics vld2_dup_* on aarch64-none-elf

[venkataramanan.kumar at amd dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63173

--- Comment #2 from Venkataramanan  ---
Changed the test case to work with latest GCC trunk 

#include 
int16x4x2_t foo(int16_t * __restrict pDataA,
 int16_t *  __restrict pDataB)
{
int16x4x2_t DataA, DataB, DataC;

DataA = vld2_dup_s16(pDataA);
DataB = vld2_dup_s16(pDataB);

DataC.val[0] = vqadd_s16( DataA.val[0], DataB.val[0] );
DataC.val[1] = vqadd_s16( DataA.val[1], DataB.val[1] );

return DataC;
}

Still seeing loads and stores via memory.

 foo:
sub sp, sp, #16
// Start of user assembly
// 11788
"/home/venkataramanan-kumar/work/pr62308/builds/destdir/x86_64-unknown-linux-gnu/lib/gcc/aarch64-none-elf/5.0.0/include/arm_neon.h"
1
ld2r {v16.4h, v17.4h}, [x0]
st1 {v16.4h, v17.4h}, [sp]

// 0 "" 2
// End of user assembly
ldr d0, [sp]
ldr d1, [sp, 8]
// Start of user assembly
// 11788
"/home/venkataramanan-kumar/work/pr62308/builds/destdir/x86_64-unknown-linux-gnu/lib/gcc/aarch64-none-elf/5.0.0/include/arm_neon.h"
1
ld2r {v16.4h, v17.4h}, [x1]
st1 {v16.4h, v17.4h}, [sp]

// 0 "" 2
// End of user assembly
ldr d3, [sp]
ldr d2, [sp, 8]
add sp, sp, 16
sqadd   v0.4h, v0.4h, v3.4h
sqadd   v1.4h, v1.4h, v2.4h
ret
.size   foo, .-foo
.ident  "GCC: (Linaro GCC 2014.10) 5.0.0 20140930 (experimental)"

[Bug fortran/63529] Bad error and ICE with Cray Pointers in Modules

[russelldub at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63529

--- Comment #4 from russelldub at gmail dot com ---

> With ifort, are you compiling with whatever flag enforces
> standards conformance.  I need to go hunting through the
> standard to see if assumed size arrays are allowed in the
> declaration section of a module.
> 

I don't think so.  Need to check and see if any of the flags affect it.

> >> Which operating system?  It compiles and executes for me on
> >> x86_64-*-freebsd with 5.0, 4.9.3, and 4.8.something.
> > 
> > RHEL derivative on x86_64, tried 4.4.6, 4.6.1, 4.7.1, 4.8.2,
> > and 4.9.0.  No ICE on Fedora 20 x86_64 with gcc-4.8.3.  Can try
> > my Ubuntu laptop later if necessary.
> 
> Hmmm, this smells like a 'used after free' issue.  Do you
> have valgrind on the system where the failure occurs? That
> might point at the smoking gun.


I get the ICE on Ubuntu 13.04, gcc-4.8.  Valgrind doesn't tell me anything:

$ valgrind gfortran -fcray-pointer cray_ptr_error2.f90 
==6319== Memcheck, a memory error detector
==6319== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==6319== Using Valgrind-3.10.0.SVN and LibVEX; rerun with -h for copyright info
==6319== Command: gfortran -fcray-pointer cray_ptr_error.f90
==6319== 
f951: internal compiler error: backend decl for module variable ptr1 already
exists
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
==6319== 
==6319== HEAP SUMMARY:
==6319== in use at exit: 41,057 bytes in 88 blocks
==6319==   total heap usage: 194 allocs, 106 frees, 50,830 bytes allocated
==6319== 
==6319== LEAK SUMMARY:
==6319==definitely lost: 5,169 bytes in 33 blocks
==6319==indirectly lost: 16 bytes in 1 blocks
==6319==  possibly lost: 0 bytes in 0 blocks
==6319==still reachable: 35,872 bytes in 54 blocks
==6319== suppressed: 0 bytes in 0 blocks
==6319== Rerun with --leak-check=full to see details of leaked memory
==6319== 
==6319== For counts of detected and suppressed errors, rerun with: -v
==6319== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

[Bug c++/63526] O1 O2 O3 optimization and inline template constructor - uninitialized member

[eles.david.88 at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63526

--- Comment #5 from Dávid Éles  ---
(In reply to Daniel Krügler from comment #3)
> (In reply to Dávid Éles from comment #2)
> > I uses the default mechanism to initialization of members. 
> > As far as I know the C++ standard says (8.5/5):
> > To default-initialize an object of type T means:
> > * If T is a non-POD class type (clause 9), the default constructor for T is
> > called (and the initialization is ill-formed if T has no accessible default
> > constructor).
> 
> [Based on your quotes and your compiler settings you seem to quote the
> C++98/03 standard. This is where my response is referred to as well]
> 
> In your example an object of type Foo is default-initialized. Class
> Foo is a non-POD class type, and therefore exactly this bullet is
> entered. The result is what the wording says: the default constructor for T
> (that is Foo in this example is called. The semantics of calling the
> default-constructor of a class that has no member-initializer provided (such
> as in this case) is specified in [class.base.init] p5:
> 
> "If a given nonstatic data member or base class is not named by a
> mem-initializer-id (including the case where there is no
> mem-initializer-list because the constructor has no ctor-initializer), then
> — If the entity is a nonstatic data member of (possibly cv-qualified) class
> type (or array thereof) or a base class, and the entity class is a non-POD
> class [..]
> — Otherwise, the entity is not initialized. [..]
> 
> The first bullet here does not apply, because the member is of type double
> and thus does not match a class type. The second bullet therefore
> unconditionally applied and says that the member is not initialized at all.
> 
> > * If T is an array type, each element is default-initialized.
> 
> This bullet does not apply
> 
> > * Otherwise, the object is zero-initialized.
> 
> This bullet does not apply.
> 
> > In case of c++ it should be zero initialized if it is the member of a
> > class/struct.
> 
> No, you are incorrectly interpreting the Standard.
>  
> > As far as I know I have to force to not doing zero initialization something
> > like that Foo* f = new Foo;
> 
> That has essentially the same initialization semantics as your example code.
You are right, I missed it, thanks for your quick answer. Sorry to waste your
time.

[Bug target/53513] [SH] Add support for fschg and fpchg insns and improve fenv support

[olegendo at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53513

--- Comment #21 from Oleg Endo  ---
(In reply to Oleg Endo from comment #17)
> 
> In the 'addsf3_i' pattern, I've tried replacing the
> 
> (use (match_operand:PSI 3 "fpscr_operand" "c"))
> 
> with
> 
> (set (match_operand:PSI 3 "fpscr_operand" "=&c")
>  (unspec:PSI [(match_dup 3)] UNSPEC_FPSCR_SET))]
> 
> 
> I haven't checked all the other side effects it could have, but at least the
> FMA combine patterns still seem work after that change.

With those changes above applied to all the other FP insns, the FMA tests in
gcc.target/sh fail.

One problem is that at -O1, FMA patterns won't be expanded initially, but are
rather formed during combine.  With the more complex FPSCA set/use combine
won't match the patterns at -O1 but only at -O2.  This is regression is
probably acceptable.

The other issue is that the fix for PR 56547 doesn't work anymore, because for
some reason combine can't figure out what to do with the 1.0 constant. 
Probably because now it'd need to deal with multiple-set insns, which it
doesn't do well.  Adding a combine bridge pattern doesn't make it go further,
as it won't try to combine 'fpreg = fpreg + 1.0' and 'fpreg = fpreg * fpreg'. 
In this case it's probably better to do a manual fma combine in the split1
pass.  This is more effort, but would also fix the first problem.

[Bug target/59401] [SH] GBR addressing mode optimization produces wrong code

[olegendo at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59401

--- Comment #10 from Oleg Endo  ---
(In reply to Kazumoto Kojima from comment #9)
> (In reply to Oleg Endo from comment #8)
> > change the
> > value for gbr in sh.h CALL_USED_REGISTERS from '1' to '0' and confirm that
> > everything is still OK?
> 
> The comment and document about CALL_USED_REGISTERS say that it must be
> a superset of FIXED_REGISTERS.  CALL_REALLY_USED_REGISTERS might be
> a macro for that purpose.

Right.  In this case it's probably better to do it in
sh_conditional_register_usage.  It would be nice if '-fcall-saved-gbr' and
'-fcall-used-gbr' still remained functional afterwards ... I'll give it a try.

[Bug target/59401] [SH] GBR addressing mode optimization produces wrong code

[kkojima at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59401

--- Comment #9 from Kazumoto Kojima  ---
(In reply to Oleg Endo from comment #8)
> change the
> value for gbr in sh.h CALL_USED_REGISTERS from '1' to '0' and confirm that
> everything is still OK?

The comment and document about CALL_USED_REGISTERS say that it must be
a superset of FIXED_REGISTERS.  CALL_REALLY_USED_REGISTERS might be
a macro for that purpose.

[Bug tree-optimization/63530] New: GCC generates incorrect aligned store on ARM after the loop is unrolled.

[congh at google dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63530

Bug ID: 63530
   Summary: GCC generates incorrect aligned store on ARM after the
loop is unrolled.
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: congh at google dot com

Created attachment 33710
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33710&action=edit
assembly

When compile the code shown below using GCC 5.0 for ARM with the following
options:

-O2 -ftree-vectorize -march=armv7-a -mfpu=neon -funroll-loops
--param=max-completely-peeled-insns=400


// The code:

typedef struct {
  unsigned char map[256];
  int i;
} A, *AP;

void* calloc(int, int);

AP foo(int n)
{
  AP b = calloc(1, sizeof(A));
  int i;
  for (i = n; i < 256; i++)
b->map[i] = i;
  return b;
}


A instruction

vst1.64{d0-d1}, [r2:64]

is generated, which is an aligned store with 8 bytes alignment requirement.
However this requirement cannot be satisfied as the loop is not peeled for
alignment, and the start address on the array is unknown at compile time.

I have attached the generated assembly code here.

[Bug target/59401] [SH] GBR addressing mode optimization produces wrong code

[olegendo at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59401

--- Comment #8 from Oleg Endo  ---
(In reply to Kazumoto Kojima from comment #7)
> (In reply to Oleg Endo from comment #6)
> > Kaz, what's your opinion on making GBR to be call preserved by default?
> 
> Looks OK to me for 5.0.  It's clearly an ABI change but a change to
> the more robust direction and wouldn't be surprising to users.

Yes, I was thinking to do that for 5.0, not for the released branches.  Just to
be on the safe side, for your next test run, could you please change the value
for gbr in sh.h CALL_USED_REGISTERS from '1' to '0' and confirm that everything
is still OK?

[Bug target/59401] [SH] GBR addressing mode optimization produces wrong code

[kkojima at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59401

--- Comment #7 from Kazumoto Kojima  ---
(In reply to Oleg Endo from comment #6)
> Kaz, what's your opinion on making GBR to be call preserved by default?

Looks OK to me for 5.0.  It's clearly an ABI change but a change to
the more robust direction and wouldn't be surprising to users.

[Bug fortran/63529] Bad error and ICE with Cray Pointers in Modules

[sgk at troutmask dot apl.washington.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63529

--- Comment #3 from Steve Kargl  ---
On Tue, Oct 14, 2014 at 12:49:52AM +, russelldub at gmail dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63529
> 
> --- Comment #2 from russelldub at gmail dot com ---
> (In reply to kargl from comment #1)
> > (In reply to russelldub from comment #0)
> > > 
> > > > gfortran -fcray-pointer cray_ptr_issue1.f90
> > > cray_ptr_issue.f90:7.6:
> > > 
> > >   USE PTR_MOD
> > >   1
> > > Error: Assumed size array at (1) must be a dummy argument
> > 
> > Error makes more sense if compiled without -fcray-pointer.
> > 
> 
> I suppose, but I'm using cray pointers, so I would expect to include
> the flag, and shouldn't assumed size arrays be allowed?  What's the
> correct syntax if so.
>  (This works with ifort.)

With ifort, are you compiling with whatever flag enforces
standards conformance.  I need to go hunting through the
standard to see if assumed size arrays are allowed in the
declaration section of a module.

>>> Scratch head.  Change "REAL :: ptee1(*)" to REAL :: ptee1(10)".
>>> 
 gfortran -fcray-pointer cray_ptr_issue2.f90
>>> f951: internal compiler error: backend decl for module variable ptr1 already
>>> exists
>> 
>> Which operating system?  It compiles and executes for me on
>> x86_64-*-freebsd with 5.0, 4.9.3, and 4.8.something.
> 
> RHEL derivative on x86_64, tried 4.4.6, 4.6.1, 4.7.1, 4.8.2,
> and 4.9.0.  No ICE on Fedora 20 x86_64 with gcc-4.8.3.  Can try
> my Ubuntu laptop later if necessary.

Hmmm, this smells like a 'used after free' issue.  Do you
have valgrind on the system where the failure occurs? That
might point at the smoking gun.

[Bug target/55212] [SH] Switch to LRA

[kkojima at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212

--- Comment #68 from Kazumoto Kojima  ---
Created attachment 33709
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33709&action=edit
CSiBE result-runtime.cvs trunk rev.215912

0.54% runtime regression.

[Bug target/55212] [SH] Switch to LRA

[kkojima at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212

--- Comment #67 from Kazumoto Kojima  ---
Created attachment 33708
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33708&action=edit
CSiBE result-runtime.cvs sh-lra+c#29+c#55+c#57+c#61+c#66

[Bug target/55212] [SH] Switch to LRA

[kkojima at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212

--- Comment #66 from Kazumoto Kojima  ---
Created attachment 33707
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33707&action=edit
a possible patch

With it, foo is compiled to

foo:
sts.l   pr,@-r15
mov.w   .L4,r1
mov r4,r5
mov.l   .L3,r0
mov #16,r4
sub r1,r15
jsr @r0
add r15,r4
mov.l   @(16,r15),r0
mov.w   .L4,r7
add r7, r15
lds.l   @r15+,pr
rts
nop
.align 1
.L4:
.short  400

and the code size regression for CSiBE is reduced to 0.74%.

[Bug target/55212] [SH] Switch to LRA

[kkojima at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212

--- Comment #65 from Kazumoto Kojima  ---
We can see ~2% code size regression on average with CSiBE.
There are some cases which register elimination doesn't
work well.  An example is

int foo (int x)
{
  int y[100];

  bar (&y[4], x);
  return y[4];
}

which is compiled to a lengthy code:

foo:
sts.l   pr,@-r15
mov.w   .L6,r1
mov r4,r5
mov.w   .L3,r2
sub r1,r15
mov.l   .L4,r0
mov r15,r3
mov.w   .L5,r1
add #4,r3
add r3,r2
add r2,r1
mov.l   r1,@r15
mov r1,r4
jsr @r0
add #16,r4
mov.l   @r15,r1
mov.l   @(16,r1),r0
mov.w   .L6,r7
add r7,r15
lds.l   @r15+,pr
rts
nop
.align 1
.L6:
.short  404
.L3:
.short  400
.L5:
.short  -400

with -O2.  It seems that SH's very limited addsi3 insn doesn't
match with the LRA's register elimination.  The canonical insn
like (set reg_a (plus reg_b const_int)) are scaned at register
elimination phase.
On SH, it's expanded to the 2 insns (set reg_a const_int) and
(set reg_a (plus reg_a reg_b)) when const_int doesn't fit in 8-bit.
This makes the elimination process unhappy.

[Bug target/55212] [SH] Switch to LRA

[kkojima at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212

--- Comment #64 from Kazumoto Kojima  ---
Created attachment 33706
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33706&action=edit
CSiBE result-size.cvs trunk rev.215912

[Bug target/55212] [SH] Switch to LRA

[kkojima at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212

--- Comment #63 from Kazumoto Kojima  ---
Created attachment 33705
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33705&action=edit
CSiBE result-size.cvs sh-lra+c#29+c#55+c#57+c#61

[Bug target/63260] [SH] fabs, fneg do not need fp-mode setting and do not use fpscr

[olegendo at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63260

Oleg Endo  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #8 from Oleg Endo  ---
Fixed for 5.0.

[Bug target/63260] [SH] fabs, fneg do not need fp-mode setting and do not use fpscr

[olegendo at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63260

--- Comment #7 from Oleg Endo  ---
Author: olegendo
Date: Tue Oct 14 00:50:18 2014
New Revision: 216173

URL: https://gcc.gnu.org/viewcvs?rev=216173&root=gcc&view=rev
Log:
gcc/
PR target/63260
* config/sh/sh.md (negsf2, negsf2_i, negdf2, negdf2_i, abssf2,
abssf2_i, absdf2, absdf2_i): Remove fp_mode attribute.  Remove use
of FPSCR.
(negsf2_i): Rename to *negsf2_i.
(abssf2_i): Rename to *abssf2_i.
(negdf2_i): Rename to *negdf2_i.
(absdf2_i): Rename to *absdf2_i.

gcc/testsuite/
PR target/63260
* gcc.target/sh/pr63260.c: New.

Added:
trunk/gcc/testsuite/gcc.target/sh/pr63260.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/sh/sh.md
trunk/gcc/testsuite/ChangeLog

[Bug fortran/63529] Bad error and ICE with Cray Pointers in Modules

[russelldub at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63529

--- Comment #2 from russelldub at gmail dot com ---
(In reply to kargl from comment #1)
> (In reply to russelldub from comment #0)
> > Consider the following "cray_ptr_issue1.f90":
> > 
> > MODULE PTR_MOD
> >   IMPLICIT NONE
> >   REAL :: ptee1(*)
> >   POINTER (ptr1, ptee1)
> > END MODULE PTR_MOD
> > PROGRAM MAIN
> >   USE PTR_MOD
> >   IMPLICIT NONE
> >   WRITE(*,*) "Hello, world!"
> > END PROGRAM MAIN
> > 
> > > gfortran -fcray-pointer cray_ptr_issue1.f90
> > cray_ptr_issue.f90:7.6:
> > 
> >   USE PTR_MOD
> >   1
> > Error: Assumed size array at (1) must be a dummy argument
> 
> Error makes more sense if compiled without -fcray-pointer.
> 

I suppose, but I'm using cray pointers, so I would expect to include the flag,
and shouldn't assumed size arrays be allowed?  What's the correct syntax if so.
 (This works with ifort.)

> > 
> > Scratch head.  Change "REAL :: ptee1(*)" to REAL :: ptee1(10)".
> > 
> > > gfortran -fcray-pointer cray_ptr_issue2.f90
> > f951: internal compiler error: backend decl for module variable ptr1 already
> > exists
> 
> Which operating system?  It compiles and executes for me on
> x86_64-*-freebsd with 5.0, 4.9.3, and 4.8.something.
> 

RHEL derivative on x86_64, tried 4.4.6, 4.6.1, 4.7.1, 4.8.2, and 4.9.0.  No ICE
on Fedora 20 x86_64 with gcc-4.8.3.  Can try my Ubuntu laptop later if
necessary.

> PS: Do you have a copyright assignment with the FSF?
> 

No.  I suppose I should get that?

[Bug regression/62102] [5 Regression]: gcc.dg/torture/pr48953.c -O2 -flto

[hp at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62102

Hans-Peter Nilsson  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #7 from Hans-Peter Nilsson  ---
(In reply to Jan Hubicka from comment #6)
> Since this testcase also involves VLA, can you, please, test if the patch
> for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62127
(now in mainline)
> fixes the problem?

My autotester picked up that commit, and this regression is gone, thanks!
I'm closing this PR.

Specifically, this regression is gone with a commit in the range
(216146:216158], matching the commit in question.  Incidentally, at r216158
there's only gcc.dg/tls/alias-1.c i.e. PR61548 (since I started tracking
regressions for cris-elf in 2007).

[Bug fortran/63529] Bad error and ICE with Cray Pointers in Modules

[kargl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63529

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #1 from kargl at gcc dot gnu.org ---
(In reply to russelldub from comment #0)
> Consider the following "cray_ptr_issue1.f90":
> 
> MODULE PTR_MOD
>   IMPLICIT NONE
>   REAL :: ptee1(*)
>   POINTER (ptr1, ptee1)
> END MODULE PTR_MOD
> PROGRAM MAIN
>   USE PTR_MOD
>   IMPLICIT NONE
>   WRITE(*,*) "Hello, world!"
> END PROGRAM MAIN
> 
> > gfortran -fcray-pointer cray_ptr_issue1.f90
> cray_ptr_issue.f90:7.6:
> 
>   USE PTR_MOD
>   1
> Error: Assumed size array at (1) must be a dummy argument

Error makes more sense if compiled without -fcray-pointer.

> 
> Scratch head.  Change "REAL :: ptee1(*)" to REAL :: ptee1(10)".
> 
> > gfortran -fcray-pointer cray_ptr_issue2.f90
> f951: internal compiler error: backend decl for module variable ptr1 already
> exists

Which operating system?  It compiles and executes for me on
x86_64-*-freebsd with 5.0, 4.9.3, and 4.8.something.

PS: Do you have a copyright assignment with the FSF?

-- 
steve

[Bug target/63527] [5 Regression] -fPIC uses 2 registers for GOT

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63527

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-10-14
Summary|[5 Regression] -fPIC|[5 Regression] -fPIC uses 2
   |generates more instructions |registers for GOT
 Ever confirmed|0   |1

--- Comment #1 from H.J. Lu  ---
GCC uses 2 registers for GOT access, instead of one.  One register
is allocated by LRA and EBX is used by ix86_expand_call.

[Bug target/63260] [SH] fabs, fneg do not need fp-mode setting and do not use fpscr

[olegendo at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63260

--- Comment #6 from Oleg Endo  ---
GDB patch submitted:
https://sourceware.org/ml/gdb-patches/2014-10/msg00334.html

[Bug c++/63526] O1 O2 O3 optimization and inline template constructor - uninitialized member

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63526

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #4 from Jonathan Wakely  ---
The text you quote describes how f is initialized, it does not apply to f._foo.

You provided a default constructor, so the compiler uses that and assumes that
you wrote it correctly to do what you want.

If you want Foo's members to be initialized then fix your constructor.

[Bug c++/63515] Deduced number of parameters can be deduced from unrelated type

[luka.rahne at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63515

--- Comment #3 from Luka Rahne  ---
Extra observations:

It looks to me that assignment "auto c = CurriedImpl<2,some_type>(f);" tries to
construct an operator();

If operator() is renamed to function fun or assignment is replaced by
constructor there is no issues.

[Bug target/59401] [SH] GBR addressing mode optimization produces wrong code

[olegendo at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59401

--- Comment #6 from Oleg Endo  ---
(In reply to Oleg Endo from comment #5)
> Ugh, there's actually another problem with this thing, I think:
> 
> ...
> 
> By default, GBR is marked as call-clobbered.  Currently, if the GBR mem
> optimization thing sees any calls in a function it will not form the GBR
> address.  It's not optimal, but was supposed to produce at least correct
> code.  Obviously the code above is wrong.  The __builtin_thread_pointer insn
> is hoisted by something else before combine/split1.  The patch from r216128
> is incomplete.  I'm checking it out.

No, hoisting __builtin_thread_pointer is OK.
It only makes the following impossible to do:

void foo (void* otherthread)
{
  ...
  access current thread's context
  ...

  switch_thread (otherthread);

  ...
  access otherthread's context
  ...
}

The compiler doesn't know that switch_thread modifies the thread pointer.  One
workaround is:

  switch_thread (otherthread);
  void* newtp;
  __asm__ __volatile__ ("stc gbr, %0" : "=r" (newtp));
  __builtin_set_thread_pointer (newtp);

However, this is just a hypothetical use case.  I don't think there is an
immediate use for that.  Usually the thread pointer is not switched like that
in the middle of a function, probably not even when implementing cooperative
threading/fibers.

Thus I think it would make sense to change the default behavior from GBR call
clobbered to GBR call preserved.  Actually making GBR call preserved is the
only way for the GBR mem access optimization to make any sense because
otherwise it will never form GBR mems if calls are present in a function, which
defeats its purpose.  It would be possible to make a better analysis of when
GBR is used (before / after calls etc), but I think it's worth it in this case.


Kaz, what's your opinion on making GBR to be call preserved by default?

[Bug gcov-profile/61889] [5 Regression] gcov-tool.c uses nftw, ftw.h

[xur at google dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61889

--- Comment #20 from xur at google dot com ---
Thanks for the comments. I'll work on this to get it fixed this time.

Let me understand your idea correctly:
We will have two patches: The first one will check FTW-API and make
the gcov-tool build configurable.
if -disable-gcov-tool is specified, we will not build gcov-tool.
if -enable-gcov-tool is specified, we will build gcov-tool
if neither specified, we will check the FTW-API and build gcovtool if
FTW-API is available.

The second patch is to emulate FTW in libiberty for MINGW32?
I'm a little confused here. libiberty is built after the configure. Do
we need to a special handling of MINGW32 in config?

Thanks,

-Rong

On Mon, Oct 13, 2014 at 3:03 PM, ktietz at gcc dot gnu.org
 wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61889
>
> --- Comment #19 from Kai Tietz  ---
> Hi Xur,
>
> I asked you in my intial support to check for existance of FTW-API, and not to
> implement it for Win32.
>
> So first, send patch checking in a valid way if API can be used.
>
> The ftw/nftw emulation you wrote seems to me more suitable for libiberty.  And
> again in most places the check for _WIN32 isn't right.  You should check
> instead for mingw-target, means for __MINGW32__ instead, as for cygwin this
> macro might be defined in some circumstances.  And make sure that you disable
> code-paths only for mingw-targets iff we don't have the FTW-API.
>
> I would suggest to make out this patch 2 separate patches.
>
> --
> You are receiving this mail because:
> You are the assignee for the bug.

[Bug fortran/63529] New: Bad error and ICE with Cray Pointers in Modules

[russelldub at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63529

Bug ID: 63529
   Summary: Bad error and ICE with Cray Pointers in Modules
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: russelldub at gmail dot com

Consider the following "cray_ptr_issue1.f90":

MODULE PTR_MOD
  IMPLICIT NONE
  REAL :: ptee1(*)
  POINTER (ptr1, ptee1)
END MODULE PTR_MOD
PROGRAM MAIN
  USE PTR_MOD
  IMPLICIT NONE
  WRITE(*,*) "Hello, world!"
END PROGRAM MAIN

> gfortran -fcray-pointer cray_ptr_issue1.f90
cray_ptr_issue.f90:7.6:

  USE PTR_MOD
  1
Error: Assumed size array at (1) must be a dummy argument

Scratch head.  Change "REAL :: ptee1(*)" to REAL :: ptee1(10)".

> gfortran -fcray-pointer cray_ptr_issue2.f90
f951: internal compiler error: backend decl for module variable ptr1 already
exists
0x5fd8f8 gfc_create_module_variable
../../gcc-4.9.0/gcc/fortran/trans-decl.c:4251
0x5ca9ab do_traverse_symtree
../../gcc-4.9.0/gcc/fortran/symbol.c:3575
0x5fe552 gfc_generate_module_vars(gfc_namespace*)
../../gcc-4.9.0/gcc/fortran/trans-decl.c:4694
0x5e0851 gfc_generate_module_code(gfc_namespace*)
../../gcc-4.9.0/gcc/fortran/trans.c:1946
0x59ea59 translate_all_program_units
../../gcc-4.9.0/gcc/fortran/parse.c:4522
0x59ea59 gfc_parse_file()
../../gcc-4.9.0/gcc/fortran/parse.c:4732
0x5db795 gfc_be_parse_file
../../gcc-4.9.0/gcc/fortran/f95-lang.c:188
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug gcov-profile/61889] [5 Regression] gcov-tool.c uses nftw, ftw.h

[ktietz at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61889

--- Comment #19 from Kai Tietz  ---
Hi Xur,

I asked you in my intial support to check for existance of FTW-API, and not to
implement it for Win32.

So first, send patch checking in a valid way if API can be used.

The ftw/nftw emulation you wrote seems to me more suitable for libiberty.  And
again in most places the check for _WIN32 isn't right.  You should check
instead for mingw-target, means for __MINGW32__ instead, as for cygwin this
macro might be defined in some circumstances.  And make sure that you disable
code-paths only for mingw-targets iff we don't have the FTW-API.

I would suggest to make out this patch 2 separate patches.

[Bug c++/63515] unused templated member can be instatiated

[luka.rahne at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63515

--- Comment #2 from Luka Rahne  ---
This bug boils to to point where in member function

template 
CurriedImpl 
//sizeof...(Rem) depends here on size of arguments of std::function
operator()(Rem ... a_rem) 
{
}

deduced number of arguments depends on number of arguments in F

[Bug c++/63515] unused templated member can be instatiated

[luka.rahne at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63515

--- Comment #1 from Luka Rahne  ---
Created attachment 33704
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33704&action=edit
Shorter Example

[Bug gcov-profile/61889] [5 Regression] gcov-tool.c uses nftw, ftw.h

[xur at google dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61889

--- Comment #18 from xur at google dot com ---
This patch is after Kai Tietz's comment. and it does check the nfw headers.

On Mon, Oct 13, 2014 at 2:40 PM, fxcoudert at gcc dot gnu.org
 wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61889
>
> --- Comment #17 from Francois-Xavier Coudert  
> ---
> (In reply to xur from comment #16)
>> I sent a patch to fix this, a few weeks ago, but I have got the review
>> or approval.
>> https://gcc.gnu.org/ml/gcc-patches/2014-09/msg00186.html
>
> Kai Tietz, mingw maintainer, commented on it (comment #6 above) and it is not
> OK as is (support should be checked, not hard-coded).
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.

[Bug gcov-profile/61889] [5 Regression] gcov-tool.c uses nftw, ftw.h

[fxcoudert at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61889

--- Comment #17 from Francois-Xavier Coudert  ---
(In reply to xur from comment #16)
> I sent a patch to fix this, a few weeks ago, but I have got the review
> or approval.
> https://gcc.gnu.org/ml/gcc-patches/2014-09/msg00186.html

Kai Tietz, mingw maintainer, commented on it (comment #6 above) and it is not
OK as is (support should be checked, not hard-coded).

[Bug bootstrap/63432] [5 Regression] profiledbootstrap failure with bootstrap-lto

[tejohnson at google dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63432

--- Comment #28 from Teresa Johnson  ---
On Mon, Oct 13, 2014 at 8:53 AM, hjl.tools at gmail dot com
 wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63432
>
> --- Comment #27 from H.J. Lu  ---
> (In reply to Teresa Johnson from comment #24)
>
>> Arg, looks very similar so maybe another instance of the duplicate
>> threading is slipping through? My own lto profiled bootstrap succeeded
>> with my patch. I will try updating to r216039 and redo it to see if I
>> can provoke the same failure.
>>
>
> I sent you another testcase against r216150.

Thanks for the testcase, I reproduced it. It is a case of garbage in /
garbage out. The fre2 pass is introducing some big profile count
insanities, leading to the probability insanity being introduced when
we try to use the counts to compute the new probability in
recompute_probabilities. There is already handling for really large
probabilities due to this issue, and we need to add the same thing for
negative probabilities - essentially the patch you had originally
suggested for the first problem which wasn't necessary for that one
since that was an actually jump threading induced issue.

Will test that and send for review.

>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.

[Bug gcov-profile/61889] [5 Regression] gcov-tool.c uses nftw, ftw.h

[xur at google dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61889

--- Comment #16 from xur at google dot com ---
I sent a patch to fix this, a few weeks ago, but I have got the review
or approval.

https://gcc.gnu.org/ml/gcc-patches/2014-09/msg00186.html

Honza, could you take a quick look?


-Rong

On Mon, Oct 13, 2014 at 12:29 PM, rai...@emrich-ebersheim.de
 wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61889
>
> --- Comment #11 from Rainer Emrich  ---
> Dear friends this issue seems to become a never ending story.
> In my understanding the person causing the issue is responsible for a fix.
> There are several hints in this thread how to solve the issue. So please get 
> on
> to it.
> Otherwise we have a massive issue here.
> And last but not least I don't see any reason why this bug has status WAITING.
> If there is a solid reason please post it here.
>
> --
> You are receiving this mail because:
> You are the assignee for the bug.

[Bug target/59401] [SH] GBR addressing mode optimization produces wrong code

[olegendo at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59401

--- Comment #5 from Oleg Endo  ---
Ugh, there's actually another problem with this thing, I think:

void other (void);

int test0 (void)
{
  int x = ((int*)__builtin_thread_pointer ())[2];

  other ();

  return ((int*)__builtin_thread_pointer ())[5] + x;
}

compiles to:
stcgbr,r8
mov.l.L3,r1
jsr@r1
mov.l@(8,r8),r9

mov.l@(20,r8),r0  << use GBR value before the call
addr9,r0
lds.l@r15+,pr
mov.l@r15+,r9

rts
mov.l@r15+,r8

By default, GBR is marked as call-clobbered.  Currently, if the GBR mem
optimization thing sees any calls in a function it will not form the GBR
address.  It's not optimal, but was supposed to produce at least correct code. 
Obviously the code above is wrong.  The __builtin_thread_pointer insn is
hoisted by something else before combine/split1.  The patch from r216128 is
incomplete.  I'm checking it out.

[Bug fortran/40958] module files too large

[russelldub at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40958

--- Comment #18 from russelldub at gmail dot com ---
Created attachment 33703
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33703&action=edit
Proposed patch to fix module equivalence duplicates

Here is a proposed fix for the problem related to equivalence statements in
nested/recursive use (see also PR 60780).  I've run 'make check-fortran' on
rev. 216017 with and without this patch had a FAIL on
gfortran.dg/typebound_operator_3.f03 (as discussed in PR 63404) both ways.

[Bug c++/63528] A variadic variable template cannot use the ::value of a variadic trait

[daniel.kruegler at googlemail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63528

Daniel Krügler  changed:

   What|Removed |Added

 CC||daniel.kruegler@googlemail.
   ||com

--- Comment #1 from Daniel Krügler  ---
Reduced example free of library stuff:

//
template
struct X
{
  constexpr static bool value = true;  
};

static_assert(X::value, "");

template 
constexpr bool X_v = X::value;

static_assert(X_v, "");
//

[Bug driver/61106] [4.8/4.9] impliedness of -Wunused-parameter depends on -W option ordering

[manu at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61106

--- Comment #22 from Manuel López-Ibáñez  ---
(In reply to lucier from comment #21)
> so I think it also affects -Wunused-result.

You can always retest the patches in the 4.8 and 4.9 branches and resubmit. And
ping until someone reviews it.

[Bug c++/63526] O1 O2 O3 optimization and inline template constructor - uninitialized member

[daniel.kruegler at googlemail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63526

Daniel Krügler  changed:

   What|Removed |Added

 CC||daniel.kruegler@googlemail.
   ||com

--- Comment #3 from Daniel Krügler  ---
(In reply to Dávid Éles from comment #2)
> I uses the default mechanism to initialization of members. 
> As far as I know the C++ standard says (8.5/5):
> To default-initialize an object of type T means:
> * If T is a non-POD class type (clause 9), the default constructor for T is
> called (and the initialization is ill-formed if T has no accessible default
> constructor).

[Based on your quotes and your compiler settings you seem to quote the C++98/03
standard. This is where my response is referred to as well]

In your example an object of type Foo is default-initialized. Class
Foo is a non-POD class type, and therefore exactly this bullet is
entered. The result is what the wording says: the default constructor for T
(that is Foo in this example is called. The semantics of calling the
default-constructor of a class that has no member-initializer provided (such as
in this case) is specified in [class.base.init] p5:

"If a given nonstatic data member or base class is not named by a
mem-initializer-id (including the case where there is no mem-initializer-list
because the constructor has no ctor-initializer), then
— If the entity is a nonstatic data member of (possibly cv-qualified) class
type (or array thereof) or a base class, and the entity class is a non-POD
class [..]
— Otherwise, the entity is not initialized. [..]

The first bullet here does not apply, because the member is of type double and
thus does not match a class type. The second bullet therefore unconditionally
applied and says that the member is not initialized at all.

> * If T is an array type, each element is default-initialized.

This bullet does not apply

> * Otherwise, the object is zero-initialized.

This bullet does not apply.

> In case of c++ it should be zero initialized if it is the member of a
> class/struct.

No, you are incorrectly interpreting the Standard.

> As far as I know I have to force to not doing zero initialization something
> like that Foo* f = new Foo;

That has essentially the same initialization semantics as your example code.

[Bug c/16351] NULL dereference warnings

[manu at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351

--- Comment #20 from Manuel López-Ibáñez  ---
(In reply to Jeffrey A. Law from comment #19)
> Nobody ever reviewed the changes :(

If precisely you cannot get someone to review your patches, the lack of
manpower in GCC is becoming truly desperate, including the middle-end.

In any case, you are a middle-end maintainer. Give a period for last minute
comments and commit it? If something breaks, you can always revert it. This is
not some major architectural work, it seems quite independent piece.

[Bug driver/61106] [4.8/4.9] impliedness of -Wunused-parameter depends on -W option ordering

[lucier at math dot purdue.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61106

lucier at math dot purdue.edu changed:

   What|Removed |Added

 CC||lucier at math dot purdue.edu

--- Comment #21 from lucier at math dot purdue.edu ---
Regarding:

I think this issue may affect other options, not just -Wunused-parameter.

I just built mainline gcc and the following bug from 4.8.2 disappeared:

gcc -W -Wall -march=native -Wno-unused -Wno-write-strings -O1 -fno-math-errno
-fschedule-insns2 -fno-trapping-math -fno-strict-aliasing -fwrapv
-fomit-frame-pointer -fPIC -fno-common -mieee-fp   -I"../include" -c -o
"os_io.o" -I. -DHAVE_CONFIG_H -D___GAMBCDIR="\"/usr/local/Gambit-C/v4.7.3\""
-D___SYS_TYPE_CPU="\"x86_64\"" -D___SYS_TYPE_VENDOR="\"unknown\""
-D___SYS_TYPE_OS="\"linux-gnu\"" -D___CONFIGURE_COMMAND="\"./configure 'CC=gcc
-W -Wall -march=native' '--enable-single-host' '--enable-multiple-versions'"\"
-D___OBJ_EXTENSION="\".o\"" -D___EXE_EXTENSION="\"\"" -D___BAT_EXTENSION="\"\""
-D___PRIMAL os_io.c -D___LIBRARY
os_io.c: In function '___device_stream_setup_from_process':
os_io.c:7212:17: warning: ignoring return value of 'write', declared with
attribute warn_unused_result [-Wunused-result]
   write (hdp_errno.writing_fd, &execvp_errno, sizeof (execvp_errno));

so I think it also affects -Wunused-result.

Brad

[Bug c++/57622] -W -Wall -Werror -Wno-unused gives Wunused-parameter warning

[manu at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57622

Manuel López-Ibáñez  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #3 from Manuel López-Ibáñez  ---
The patch was reverted in the branches, that is why PR61106 is still open. It
was reverted because it exposed a Fortran issue that has since been fixed, thus
I could be reapplied.

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

[Bug driver/61106] [4.8/4.9] impliedness of -Wunused-parameter depends on -W option ordering

[manu at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61106

--- Comment #20 from Manuel López-Ibáñez  ---
*** Bug 57622 has been marked as a duplicate of this bug. ***

[Bug c++/57622] -W -Wall -Werror -Wno-unused gives Wunused-parameter warning

[lucier at math dot purdue.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57622

--- Comment #2 from lucier at math dot purdue.edu ---
This was fixed by the patch for PR61106 and backported to 4.8 and 4.9, so it
should be closed as FIXED.

[Bug c++/63528] New: A variadic variable template cannot use the ::value of a variadic trait

[ville.voutilainen at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63528

Bug ID: 63528
   Summary: A variadic variable template cannot use the ::value of
a variadic trait
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ville.voutilainen at gmail dot com
CC: jason at redhat dot com

Created attachment 33702
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33702&action=edit
Preprocessed testcase

#include 

static_assert(std::is_constructible::value, "");

template 
constexpr bool is_constructible_v = std::is_constructible::value;

static_assert(is_constructible_v, "");

Using built-in specs.
COLLECT_GCC=/usr/local/bin/g++
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --prefix=/usr/local --enable-languages=c,c++ :
(reconfigured) ../configure --prefix=/usr/local --enable-languages=c,c++
Thread model: posix
gcc version 5.0.0 20141013 (experimental) (GCC) 

COLLECT_GCC_OPTIONS='-std=c++14' '-v' '-save-temps' '-c' '-shared-libgcc'
'-mtune=generic' '-march=x86-64'
 /usr/local/libexec/gcc/x86_64-unknown-linux-gnu/5.0.0/cc1plus -E -quiet -v
-D_GNU_SOURCE variable-template-isconstructible.cpp -mtune=generic
-march=x86-64 -std=c++14 -fpch-preprocess -o
variable-template-isconstructible.ii
ignoring nonexistent directory
"/usr/local/lib/gcc/x86_64-unknown-linux-gnu/5.0.0/../../../../x86_64-unknown-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:

/usr/local/lib/gcc/x86_64-unknown-linux-gnu/5.0.0/../../../../include/c++/5.0.0

/usr/local/lib/gcc/x86_64-unknown-linux-gnu/5.0.0/../../../../include/c++/5.0.0/x86_64-unknown-linux-gnu

/usr/local/lib/gcc/x86_64-unknown-linux-gnu/5.0.0/../../../../include/c++/5.0.0/backward
 /usr/local/lib/gcc/x86_64-unknown-linux-gnu/5.0.0/include
 /usr/local/include
 /usr/local/lib/gcc/x86_64-unknown-linux-gnu/5.0.0/include-fixed
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-std=c++14' '-v' '-save-temps' '-c' '-shared-libgcc'
'-mtune=generic' '-march=x86-64'
 /usr/local/libexec/gcc/x86_64-unknown-linux-gnu/5.0.0/cc1plus -fpreprocessed
variable-template-isconstructible.ii -quiet -dumpbase
variable-template-isconstructible.cpp -mtune=generic -march=x86-64 -auxbase
variable-template-isconstructible -std=c++14 -version -o
variable-template-isconstructible.s
GNU C++ (GCC) version 5.0.0 20141013 (experimental) (x86_64-unknown-linux-gnu)
compiled by GNU C version 5.0.0 20141013 (experimental), GMP version 5.0.2,
MPFR version 3.1.0, MPC version 0.9
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU C++ (GCC) version 5.0.0 20141013 (experimental) (x86_64-unknown-linux-gnu)
compiled by GNU C version 5.0.0 20141013 (experimental), GMP version 5.0.2,
MPFR version 3.1.0, MPC version 0.9
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: 50a3aa5021e9015dd41af708b42ad2d3
variable-template-isconstructible.cpp:8:1: error: non-constant condition for
static assertion
 static_assert(is_constructible_v, "");
 ^
variable-template-isconstructible.cpp:8:1: error: the value of
‘is_constructible_v >’ is not usable in a constant
expression
variable-template-isconstructible.cpp:6:16: note: ‘is_constructible_v >’ used in its own initializer
 constexpr bool is_constructible_v = std::is_constructible::value;

[Bug gcov-profile/61889] [5 Regression] gcov-tool.c uses nftw, ftw.h

[StaffLeavers at arm dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61889

--- Comment #15 from StaffLeavers at arm dot com ---
tony.wang no longer works for ARM.

Your email will be forwarded to their line manager.


Please do not reply to this email.
If you need more information, please email real-postmas...@arm.com

Thank you.

[Bug gcov-profile/61889] [5 Regression] gcov-tool.c uses nftw, ftw.h

[StaffLeavers at arm dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61889

--- Comment #14 from StaffLeavers at arm dot com ---
tony.wang no longer works for ARM.

Your email will be forwarded to their line manager.


Please do not reply to this email.
If you need more information, please email real-postmas...@arm.com

Thank you.

[Bug gcov-profile/61889] [5 Regression] gcov-tool.c uses nftw, ftw.h

[fxcoudert at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61889

Francois-Xavier Coudert  changed:

   What|Removed |Added

 Status|WAITING |NEW
 CC|tony.wang at arm dot com   |

[Bug gcov-profile/61889] [5 Regression] gcov-tool.c uses nftw, ftw.h

[StaffLeavers at arm dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61889

--- Comment #13 from StaffLeavers at arm dot com ---
tony.wang no longer works for ARM.

Your email will be forwarded to their line manager.


Please do not reply to this email.
If you need more information, please email real-postmas...@arm.com

Thank you.

[Bug gcov-profile/61889] [5 Regression] gcov-tool.c uses nftw, ftw.h

[StaffLeavers at arm dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61889

--- Comment #12 from StaffLeavers at arm dot com ---
tony.wang no longer works for ARM.

Your email will be forwarded to their line manager.


Please do not reply to this email.
If you need more information, please email real-postmas...@arm.com

Thank you.

[Bug gcov-profile/61889] [5 Regression] gcov-tool.c uses nftw, ftw.h

[rai...@emrich-ebersheim.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61889

--- Comment #11 from Rainer Emrich  ---
Dear friends this issue seems to become a never ending story.
In my understanding the person causing the issue is responsible for a fix.
There are several hints in this thread how to solve the issue. So please get on
to it.
Otherwise we have a massive issue here.
And last but not least I don't see any reason why this bug has status WAITING.
If there is a solid reason please post it here.

[Bug target/63527] New: [5 Regression] -fPIC generates more instructions

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63527

Bug ID: 63527
   Summary: [5 Regression] -fPIC generates more instructions
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: evstupac at gmail dot com
Target: i686-linux

On Linux/x86, r216154 generates more instructions with -O2 -fPIC
for


struct cache_file
{
  char magic[sizeof "ld.so-1.7.0" - 1];
  unsigned int nlibs;
};
typedef unsigned int size_t;
size_t cachesize __attribute__ ((visibility ("hidden")));
struct cache_file *cache __attribute__ ((visibility ("hidden")));
extern int __munmap (void *__addr, size_t __len);
void
_dl_unload_cache (void)
{
  if (cache != ((void *)0) && cache != (struct cache_file *) -1)
{
  __munmap (cache, cachesize);
  cache = ((void *)0) ;
}
}


r216153 generates

---
.text
.LHOTB0:
.p2align 4,,15
.globl_dl_unload_cache
.type_dl_unload_cache, @function
_dl_unload_cache:
pushl%ebx
call__x86.get_pc_thunk.bx
addl$_GLOBAL_OFFSET_TABLE_, %ebx
subl$8, %esp
movlcache@GOTOFF(%ebx), %eax
leal-1(%eax), %edx
cmpl$-3, %edx
ja.L1
subl$8, %esp
pushlcachesize@GOTOFF(%ebx)
pushl%eax
call__munmap@PLT
movl$0, cache@GOTOFF(%ebx)
addl$16, %esp
.L1:
addl$8, %esp
popl%ebx
ret
.size_dl_unload_cache, .-_dl_unload_cache
.section.text.unlikely
.LCOLDE0:
.text
.LHOTE0:
.hiddencache
.commcache,4,4
.hiddencachesize
.commcachesize,4,4
.section   
.text.__x86.get_pc_thunk.bx,"axG",@progbits,__x86.get_pc_thunk.bx,comdat
.globl__x86.get_pc_thunk.bx
.hidden__x86.get_pc_thunk.bx
.type__x86.get_pc_thunk.bx, @function
__x86.get_pc_thunk.bx:
movl(%esp), %ebx
ret
---

r216154 generates

--
.text
.LHOTB0:
.p2align 4,,15
.globl_dl_unload_cache
.type_dl_unload_cache, @function
_dl_unload_cache:
pushl%esi
pushl%ebx
call__x86.get_pc_thunk.si
addl$_GLOBAL_OFFSET_TABLE_, %esi
subl$4, %esp
movlcache@GOTOFF(%esi), %eax
leal-1(%eax), %edx
cmpl$-3, %edx
ja.L1
subl$8, %esp
pushlcachesize@GOTOFF(%esi)
movl%esi, %ebx
pushl%eax
call__munmap@PLT
movl$0, cache@GOTOFF(%esi)
addl$16, %esp
.L1:
addl$4, %esp
popl%ebx
popl%esi
ret
.size_dl_unload_cache, .-_dl_unload_cache
.section.text.unlikely
.LCOLDE0:
.text
.LHOTE0:
.hiddencache
.commcache,4,4
.hiddencachesize
.commcachesize,4,4
.section   
.text.__x86.get_pc_thunk.si,"axG",@progbits,__x86.get_pc_thunk.si,comdat
.globl__x86.get_pc_thunk.si
.hidden__x86.get_pc_thunk.si
.type__x86.get_pc_thunk.si, @function
__x86.get_pc_thunk.si:
movl(%esp), %esi
ret
--

Why doesn't r216154 simply use %ebx to access cache, cachesize
and __munmap?

[Bug tree-optimization/63288] [5 Regression] gcc.c-torture/execute/20140326-1.c FAILs with -Og -fgcse -fif-conversion2

[zsojka at seznam dot cz]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63288

--- Comment #1 from Zdenek Sojka  ---
The original testcase also fails with a very different set of flags:
$ gcc -Os -fno-if-conversion -fsched2-use-superblocks
--param=tracer-min-branch-probability=14 20140326-1.i
$ valgrind -q ./a.out 
==8525== Invalid read of size 1
==8525==at 0x40043A: main (in /home/smatz/Downloads/xx/a.out)
==8525==  Address 0xfff01f9e6 is not stack'd, malloc'd or (recently) free'd
==8525== 
==8525== 
==8525== Process terminating with default action of signal 11 (SIGSEGV)
==8525==  Access not within mapped region at address 0xFFF01F9E6
==8525==at 0x40043A: main (in /home/smatz/Downloads/xx/a.out)
==8525==  If you believe this happened as a result of a stack
==8525==  overflow in your program's main thread (unlikely but
==8525==  possible), you can try to increase the size of the
==8525==  main thread stack using the --main-stacksize= flag.
==8525==  The main thread stack size used in this run was 8388608.
Segmentation fault

[Bug middle-end/47602] Permit inline asm to clobber PIC register

[kyukhin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47602

--- Comment #16 from Kirill Yukhin  ---
Author: kyukhin
Date: Mon Oct 13 17:26:49 2014
New Revision: 216154

URL: https://gcc.gnu.org/viewcvs?rev=216154&root=gcc&view=rev
Log:

gcc/
PR target/8340
PR middle-end/47602
PR rtl-optimization/55458
* config/i386/i386.c (ix86_use_pseudo_pic_reg): New.
(ix86_init_pic_reg): New.
(ix86_select_alt_pic_regnum): Add check on pseudo register.
(ix86_save_reg): Likewise.
(ix86_expand_prologue): Remove PIC register initialization
now performed in ix86_init_pic_reg.
(ix86_output_function_epilogue): Add check on pseudo register.
(set_pic_reg_ever_alive): New.
(legitimize_pic_address): Replace df_set_regs_ever_live with new
set_pic_reg_ever_alive.
(legitimize_tls_address): Likewise.
(ix86_pic_register_p): New check.
(ix86_delegitimize_address): Add check on pseudo register.
(ix86_expand_call): Insert move from pseudo PIC register to ABI
defined REAL_PIC_OFFSET_TABLE_REGNUM.
(TARGET_INIT_PIC_REG): New.
(TARGET_USE_PSEUDO_PIC_REG): New.
* config/i386/i386.h (PIC_OFFSET_TABLE_REGNUM): Return INVALID_REGNUM
if pic_offset_table_rtx exists.
* doc/tm.texi.in (TARGET_USE_PSEUDO_PIC_REG, TARGET_INIT_PIC_REG):
Document.
* doc/tm.texi: Regenerate.
* function.c (assign_parms): Generate pseudo register for PIC.
* init-regs.c (initialize_uninitialized_regs): Ignor pseudo PIC
register.
* ira-color.c (color_pass): Add check on pseudo register.
* ira-emit.c (change_loop): Don't create copies for PIC pseudo
register.
* ira.c (split_live_ranges_for_shrink_wrap): Add check on pseudo
register.
(ira): Add target specific PIC register initialization.
(do_reload): Keep PIC pseudo register.
* lra-assigns.c (spill_for): Add checks on pseudo register.
* lra-constraints.c (contains_symbol_ref_p): New.
(lra_constraints): Enable lra risky transformations when PIC is pseudo
register.
* shrink-wrap.c (try_shrink_wrapping): Add check on pseudo register.
* target.def (use_pseudo_pic_reg): New.
(init_pic_reg): New.

gcc/testsuite/
PR target/8340
PR middle-end/47602
PR rtl-optimization/55458
* gcc.target/i386/pic-1.c: Remove dg-error as test should pass now.
* gcc.target/i386/pr55458.c: Likewise.
* gcc.target/i386/pr47602.c: New.
* gcc.target/i386/pr23098.c: Move to XFAIL.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/config/i386/i386.h
trunk/gcc/doc/tm.texi
trunk/gcc/doc/tm.texi.in
trunk/gcc/function.c
trunk/gcc/init-regs.c
trunk/gcc/ira-color.c
trunk/gcc/ira-emit.c
trunk/gcc/ira.c
trunk/gcc/lra-assigns.c
trunk/gcc/lra-constraints.c
trunk/gcc/shrink-wrap.c
trunk/gcc/target.def
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/i386/pic-1.c
trunk/gcc/testsuite/gcc.target/i386/pr23098.c
trunk/gcc/testsuite/gcc.target/i386/pr55458.c

[Bug rtl-optimization/55458] [4.8 Regression] ICE: in assign_by_spills, at lra-assigns.c:1212 with -fPIC -m32 and simple asm volatile

[kyukhin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55458

--- Comment #4 from Kirill Yukhin  ---
Author: kyukhin
Date: Mon Oct 13 17:26:49 2014
New Revision: 216154

URL: https://gcc.gnu.org/viewcvs?rev=216154&root=gcc&view=rev
Log:

gcc/
PR target/8340
PR middle-end/47602
PR rtl-optimization/55458
* config/i386/i386.c (ix86_use_pseudo_pic_reg): New.
(ix86_init_pic_reg): New.
(ix86_select_alt_pic_regnum): Add check on pseudo register.
(ix86_save_reg): Likewise.
(ix86_expand_prologue): Remove PIC register initialization
now performed in ix86_init_pic_reg.
(ix86_output_function_epilogue): Add check on pseudo register.
(set_pic_reg_ever_alive): New.
(legitimize_pic_address): Replace df_set_regs_ever_live with new
set_pic_reg_ever_alive.
(legitimize_tls_address): Likewise.
(ix86_pic_register_p): New check.
(ix86_delegitimize_address): Add check on pseudo register.
(ix86_expand_call): Insert move from pseudo PIC register to ABI
defined REAL_PIC_OFFSET_TABLE_REGNUM.
(TARGET_INIT_PIC_REG): New.
(TARGET_USE_PSEUDO_PIC_REG): New.
* config/i386/i386.h (PIC_OFFSET_TABLE_REGNUM): Return INVALID_REGNUM
if pic_offset_table_rtx exists.
* doc/tm.texi.in (TARGET_USE_PSEUDO_PIC_REG, TARGET_INIT_PIC_REG):
Document.
* doc/tm.texi: Regenerate.
* function.c (assign_parms): Generate pseudo register for PIC.
* init-regs.c (initialize_uninitialized_regs): Ignor pseudo PIC
register.
* ira-color.c (color_pass): Add check on pseudo register.
* ira-emit.c (change_loop): Don't create copies for PIC pseudo
register.
* ira.c (split_live_ranges_for_shrink_wrap): Add check on pseudo
register.
(ira): Add target specific PIC register initialization.
(do_reload): Keep PIC pseudo register.
* lra-assigns.c (spill_for): Add checks on pseudo register.
* lra-constraints.c (contains_symbol_ref_p): New.
(lra_constraints): Enable lra risky transformations when PIC is pseudo
register.
* shrink-wrap.c (try_shrink_wrapping): Add check on pseudo register.
* target.def (use_pseudo_pic_reg): New.
(init_pic_reg): New.

gcc/testsuite/
PR target/8340
PR middle-end/47602
PR rtl-optimization/55458
* gcc.target/i386/pic-1.c: Remove dg-error as test should pass now.
* gcc.target/i386/pr55458.c: Likewise.
* gcc.target/i386/pr47602.c: New.
* gcc.target/i386/pr23098.c: Move to XFAIL.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/config/i386/i386.h
trunk/gcc/doc/tm.texi
trunk/gcc/doc/tm.texi.in
trunk/gcc/function.c
trunk/gcc/init-regs.c
trunk/gcc/ira-color.c
trunk/gcc/ira-emit.c
trunk/gcc/ira.c
trunk/gcc/lra-assigns.c
trunk/gcc/lra-constraints.c
trunk/gcc/shrink-wrap.c
trunk/gcc/target.def
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/i386/pic-1.c
trunk/gcc/testsuite/gcc.target/i386/pr23098.c
trunk/gcc/testsuite/gcc.target/i386/pr55458.c

[Bug target/8340] ICE on x86 inline asm w/ -fPIC

[kyukhin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=8340

--- Comment #9 from Kirill Yukhin  ---
Author: kyukhin
Date: Mon Oct 13 17:26:49 2014
New Revision: 216154

URL: https://gcc.gnu.org/viewcvs?rev=216154&root=gcc&view=rev
Log:

gcc/
PR target/8340
PR middle-end/47602
PR rtl-optimization/55458
* config/i386/i386.c (ix86_use_pseudo_pic_reg): New.
(ix86_init_pic_reg): New.
(ix86_select_alt_pic_regnum): Add check on pseudo register.
(ix86_save_reg): Likewise.
(ix86_expand_prologue): Remove PIC register initialization
now performed in ix86_init_pic_reg.
(ix86_output_function_epilogue): Add check on pseudo register.
(set_pic_reg_ever_alive): New.
(legitimize_pic_address): Replace df_set_regs_ever_live with new
set_pic_reg_ever_alive.
(legitimize_tls_address): Likewise.
(ix86_pic_register_p): New check.
(ix86_delegitimize_address): Add check on pseudo register.
(ix86_expand_call): Insert move from pseudo PIC register to ABI
defined REAL_PIC_OFFSET_TABLE_REGNUM.
(TARGET_INIT_PIC_REG): New.
(TARGET_USE_PSEUDO_PIC_REG): New.
* config/i386/i386.h (PIC_OFFSET_TABLE_REGNUM): Return INVALID_REGNUM
if pic_offset_table_rtx exists.
* doc/tm.texi.in (TARGET_USE_PSEUDO_PIC_REG, TARGET_INIT_PIC_REG):
Document.
* doc/tm.texi: Regenerate.
* function.c (assign_parms): Generate pseudo register for PIC.
* init-regs.c (initialize_uninitialized_regs): Ignor pseudo PIC
register.
* ira-color.c (color_pass): Add check on pseudo register.
* ira-emit.c (change_loop): Don't create copies for PIC pseudo
register.
* ira.c (split_live_ranges_for_shrink_wrap): Add check on pseudo
register.
(ira): Add target specific PIC register initialization.
(do_reload): Keep PIC pseudo register.
* lra-assigns.c (spill_for): Add checks on pseudo register.
* lra-constraints.c (contains_symbol_ref_p): New.
(lra_constraints): Enable lra risky transformations when PIC is pseudo
register.
* shrink-wrap.c (try_shrink_wrapping): Add check on pseudo register.
* target.def (use_pseudo_pic_reg): New.
(init_pic_reg): New.

gcc/testsuite/
PR target/8340
PR middle-end/47602
PR rtl-optimization/55458
* gcc.target/i386/pic-1.c: Remove dg-error as test should pass now.
* gcc.target/i386/pr55458.c: Likewise.
* gcc.target/i386/pr47602.c: New.
* gcc.target/i386/pr23098.c: Move to XFAIL.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/config/i386/i386.h
trunk/gcc/doc/tm.texi
trunk/gcc/doc/tm.texi.in
trunk/gcc/function.c
trunk/gcc/init-regs.c
trunk/gcc/ira-color.c
trunk/gcc/ira-emit.c
trunk/gcc/ira.c
trunk/gcc/lra-assigns.c
trunk/gcc/lra-constraints.c
trunk/gcc/shrink-wrap.c
trunk/gcc/target.def
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/i386/pic-1.c
trunk/gcc/testsuite/gcc.target/i386/pr23098.c
trunk/gcc/testsuite/gcc.target/i386/pr55458.c

[Bug c++/63526] O1 O2 O3 optimization and inline template constructor - uninitialized member

[eles.david.88 at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63526

--- Comment #2 from Dávid Éles  ---
(In reply to Jonathan Wakely from comment #1)
> Why do you think the member should be zero-initialized? Your constructor
> fails to initialize it.

I uses the default mechanism to initialization of members. 
As far as I know the C++ standard says (8.5/5):
To default-initialize an object of type T means:
* If T is a non-POD class type (clause 9), the default constructor for T is
called (and the initialization is ill-formed if T has no accessible default
constructor).
* If T is an array type, each element is default-initialized.
* Otherwise, the object is zero-initialized.

In case of c++ it should be zero initialized if it is the member of a
class/struct.

As far as I know I have to force to not doing zero initialization something
like that 
Foo* f = new Foo;

[Bug libfortran/63471] [5.0 Regression] unix.c:1906:10: error: implicit declaration of function 'ttyname_r'

[danglin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63471

John David Anglin  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #11 from John David Anglin  ---
Fixed.

[Bug c++/63526] O1 O2 O3 optimization and inline template constructor - uninitialized member

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63526

--- Comment #1 from Jonathan Wakely  ---
Why do you think the member should be zero-initialized? Your constructor fails
to initialize it.

[Bug libfortran/63471] [5.0 Regression] unix.c:1906:10: error: implicit declaration of function 'ttyname_r'

[danglin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63471

--- Comment #10 from John David Anglin  ---
Author: danglin
Date: Mon Oct 13 17:02:35 2014
New Revision: 216152

URL: https://gcc.gnu.org/viewcvs?rev=216152&root=gcc&view=rev
Log:
PR libfortran/63471
* config/pa/pa-hpux11.h (TARGET_OS_CPP_BUILTINS): Define _REENTRANT
when _HPUX_SOURCE is defined.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/pa/pa-hpux11.h

[Bug c++/63526] New: O1 O2 O3 optimization and inline template constructor - uninitialized member

[eles.david.88 at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63526

Bug ID: 63526
   Summary: O1 O2 O3 optimization and inline template constructor
- uninitialized member
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eles.david.88 at gmail dot com

Created attachment 33701
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33701&action=edit
Test case

It seems due to missing zero-initialization in case of inline constructor, I
got a warning for uninitialized value for the following code:
- main.cpp 
#include 

template 
struct Foo
{
  Foo()
  {}

  void foo()
  {std::cout << _foo << std::endl;}
  T _foo;
};

int main()
{
  Foo f;
  f.foo();
  return 0;
}

Compilation with "g++ -Wall", the result:
everything is ok.

Compilation with "g++ -Wall -O1", the result:

main.cpp: In function ‘int main()’:
main.cpp:10:4: warning: ‘f.Foo::_foo’ is used uninitialized in this
function [-Wuninitialized]
main.cpp:16:15: note: ‘f’ was declared here

I got a same result with -O2, -O3.
If the constructor is not inline, everything is ok. 
It seems that due to optimization the constructor "is inlined", but not in a
prepare way, it "is inlined" without zero-initialization.

Environment information:
--
$uname -a
Linux debian 3.2.0-4-686-pae #1 SMP Debian 3.2.51-1 i686 GNU/Linux
$g++ --version
g++ (Debian 4.7.2-5) 4.7.2
Copyright (C) 2012 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
---
A same behavior can be observed in older releases and distributions:
---
$uname -a
Linux rdv 2.6.18-164.6.1.el5 #1 SMP Tue Oct 27 11:28:30 EDT 2009 x86_64 x86_64
x86_64 GNU/Linux
$g++ --version
g++ (GCC) 4.1.2 20080704 (Red Hat 4.1.2-46)
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
---
But not in the version:
---
$g++ --version
g++ (GCC) 3.4.6 20060404 (Red Hat 3.4.6-4)
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
---

[Bug rtl-optimization/63525] New: unnecessary reloads generated in loop

[wmi at google dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63525

Bug ID: 63525
   Summary: unnecessary reloads generated in loop
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wmi at google dot com
CC: vmakarov at gcc dot gnu.org

Created attachment 33700
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33700&action=edit
testcase 1.cxx

For the testcase 1.cxx attached, trunk (r214579) generates an addpd with mem
operand and one extra reload insn in kernel loop. For g++ before r204274, it
generate less insns in the kernel loop.

~/workarea/gcc-r214579/build/install/bin/g++ -O2 -S 1.cxx -o 1.s
kernel loop:
.L3:
   pxor%xmm0, %xmm0
   cvtsi2sd%eax, %xmm0
   addl$1, %eax
   cmpl%edx, %eax
   unpcklpd%xmm0, %xmm0
   addpd   -24(%rsp), %xmm0 ===> mem operand used
   movaps  %xmm0, -24(%rsp)   ===> reload
   jne .L3

~/workarea/gcc-r199418/build/install/bin/g++ -O2 -S 1.cxx -o 2.s
kernel loop:
.L3:
   xorpd   %xmm1, %xmm1
   cvtsi2sd%eax, %xmm1
   addl$1, %eax
   unpcklpd%xmm1, %xmm1
   addpd   %xmm1, %xmm0
   cmpl%edx, %eax
   jne .L3


The reload insns in trunk are generated because of following steps:

With r204274, the IR after expand like this:
Loop:
...
(insn 15 14 16 5 (set (reg/v:V2DF 83 [ v ])
   (plus:V2DF (reg/v:V2DF 83 [ v ])
   (reg:V2DF 92 [ D.5005 ]))) 1.cxx:14 -1
(nil))
...
end Loop.
(insn 23 22 24 7 (set (reg/v:TI 90 [ tmp ])
   (subreg:TI (reg/v:V2DF 83 [ v ]) 0))
/usr/local/google/home/wmi/workarea/gcc-r212442/build/install/lib/gcc/x86_64-unknown-linux-gnu/4.10.0/include/emmintrin.h:157
-1
(nil))
(insn 24 23 25 7 (set (mem/c:DF (symbol_ref:DI ("x") [flags 0x2]  ) [2 x+0 S8 A64])
   (subreg:DF (reg/v:TI 90 [ tmp ]) 0)) 1.cxx:17 -1
(nil))
(insn 25 24 0 7 (set (mem/c:DF (symbol_ref:DI ("y") [flags 0x2]  ) [2 y+0 S8 A64])
   (subreg:DF (reg/v:TI 90 [ tmp ]) 8)) 1.cxx:18 -1
(nil))

forward propagation will propagate reg 90 from insn 23 to insn 24 and insn 25,
and remove subreg:TI, so we get the IR before IRA like this:

Loop:
...
(insn 15 14 16 4 (set (reg/v:V2DF 83 [ v ])
   (plus:V2DF (reg/v:V2DF 83 [ v ])
   (reg:V2DF 92 [ D.5005 ]))) 1.cxx:14 1263 {*addv2df3}
(expr_list:REG_DEAD (reg:V2DF 92 [ D.5005 ])
   (nil)))
...
end Loop.
(insn 24 22 25 5 (set (mem/c:DF (symbol_ref:DI ("x") [flags 0x2]  ) [2 x+0 S8 A64])
   (subreg:DF (reg/v:V2DF 83 [ v ]) 0)) 1.cxx:17 128 {*movdf_internal}
(nil))
(insn 25 24 0 5 (set (mem/c:DF (symbol_ref:DI ("y") [flags 0x2]  ) [2 y+0 S8 A64])
   (subreg:DF (reg/v:V2DF 83 [ v ]) 8)) 1.cxx:18 128 {*movdf_internal}
(expr_list:REG_DEAD (reg/v:V2DF 83 [ v ])
   (nil)))

ix86_cannot_change_mode_class doesn't allow such subreg: "subreg:DF (reg/v:V2DF
83 [ v ]) 8)" in insn 25, so reg 83 will be added in invalid_mode_changes by
record_subregs_of_mode and will be allocated NO_REGS regclass.

reg 83 has NO_REGS regclass while plus:V2DF requires the target operand to be
xmm register in insn 15, so reload insns are needed. The kernel loop has low
register pressure and it doesn't form a separate IRA region, so live range
splitting on region boarder doesn't kick in here.

Without r204274, IR after expand is like this:
Loop:
...
(insn 15 14 16 5 (set (reg/v:V2DF 61 [ v ])
   (plus:V2DF (reg/v:V2DF 61 [ v ])
   (reg:V2DF 68 [ D.4966 ]))) 1.cxx:14 -1
(nil))
...
End Loop.
(insn 25 24 26 7 (set (subreg:V2DF (reg/v:TI 66 [ tmp ]) 0)
   (reg/v:V2DF 61 [ v ]))
/usr/local/google/home/wmi/workarea/gcc-r199418/build/install/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/include/emmintrin.h:147
-1
(nil))
(insn 26 25 27 7 (set (mem/c:DF (symbol_ref:DI ("x") [flags 0x2]  ) [2 x+0 S8 A64])
   (subreg:DF (reg/v:TI 66 [ tmp ]) 0)) 1.cxx:17 -1
(nil))
(insn 27 26 0 7 (set (mem/c:DF (symbol_ref:DI ("y") [flags 0x2]  ) [2 y+0 S8 A64])
   (subreg:DF (reg/v:TI 66 [ tmp ]) 8)) 1.cxx:18 -1
(nil))

Because the subreg is on the left handside of insn 25, it is impossible for
forward propagation to merge insn 25 to insn 26 and insn 27. reg 61 will not
have reference like this: "subreg:DF (reg/v:V2DF 61 [ v ]) 8)", so it gets SSE
regclass and will not introduce extra reload insns in kernel loop.

r204274 just enables more forward propagations and exposes the problem here.

[Bug rtl-optimization/63475] Postreload CSE propagates aliased memory operand

[ubizjak at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63475

--- Comment #4 from Uroš Bizjak  ---
(In reply to Uroš Bizjak from comment #3)
> Created attachment 33699 [details]
> Updated patch

I have started native alpha bootstrap with the above attached patch.

The idea implemented the patch is as follows:
- always dig into X and MEM addresses using get_addr
- use this expanded address when checking for AND codes with MEM_READONLY_P
operand
- also use expanded address in find_base_term and base_alias_check and
canon_rtx.
- for canonicalized address, use original address as passed to the functions.

(get_addr can still return VALUE, but in this case find_base_term returns
ADDRESS RTX, and this prevents invalid detection of non-aliased condition in:

  /* Differing symbols not accessed via AND never alias.  */
  if (GET_CODE (x_base) != ADDRESS && GET_CODE (y_base) != ADDRESS)
return 0;
)

Bootstrap and regression test went OK on x86_64.

[Bug rtl-optimization/63475] Postreload CSE propagates aliased memory operand

[ubizjak at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63475

Uroš Bizjak  changed:

   What|Removed |Added

  Attachment #33695|0   |1
is obsolete||

--- Comment #3 from Uroš Bizjak  ---
Created attachment 33699
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33699&action=edit
Updated patch

[Bug target/63442] [AArch64] ICE with ubsan/overflow-int128.c test

[jiwang at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63442

--- Comment #2 from Jiong Wang  ---
Have done a quick investigation, it's caused by the implementation of

TARGET_LIBGCC_CMP_RETURN_MODE
  aarch64_libgcc_cmp_return_mode

AArch64 define the return mode to be SImode which seems broken gcc genric code
when expand builtin lib call

[Bug c++/57622] -W -Wall -Werror -Wno-unused gives Wunused-parameter warning

[lucier at math dot purdue.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57622

lucier at math dot purdue.edu changed:

   What|Removed |Added

 CC||lucier at math dot purdue.edu

--- Comment #1 from lucier at math dot purdue.edu ---
This bug has bitten me, too.

I built and tested the current mainline with the idea that I'd try to implement
the suggested fix, but this is the first time I've looked at any of the
autogenerated files and I'm afraid that I have no clue what's going on.

Brad

[Bug bootstrap/63523] [5.0 regression] gcc/cp/pt.c -Werror=format breaks bootstrap on sparc-linux

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63523

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from H.J. Lu  ---
Should be fixed by r216151.

[Bug fortran/63514] functions containing volatile are considered pure

[Joost.VandeVondele at mat dot ethz.ch]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63514

--- Comment #3 from Joost VandeVondele  
---
(In reply to Richard Biener from comment #2)
> The fortran frontend must do sth wrong here - it seems to mark the function
> pure itself and either fold or the FE even does the optimization (look at
> the .original dump).

yes, it certainly is a FE issue.

[Bug tree-optimization/63464] compare one character to many: faster

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63464

--- Comment #10 from Jakub Jelinek  ---
Created attachment 33698
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33698&action=edit
bittest.c

Testcase I've been playing with.

[Bug bootstrap/63432] [5 Regression] profiledbootstrap failure with bootstrap-lto

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63432

--- Comment #27 from H.J. Lu  ---
(In reply to Teresa Johnson from comment #24)

> Arg, looks very similar so maybe another instance of the duplicate
> threading is slipping through? My own lto profiled bootstrap succeeded
> with my patch. I will try updating to r216039 and redo it to see if I
> can provoke the same failure.
> 

I sent you another testcase against r216150.

[Bug c/16351] NULL dereference warnings

[law at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351

--- Comment #19 from Jeffrey A. Law  ---
Nobody ever reviewed the changes :(

[Bug tree-optimization/63464] compare one character to many: faster

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63464

--- Comment #9 from Jakub Jelinek  ---
Created attachment 33697
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33697&action=edit
gcc5-pr63464.patch

WIP patch.  What is missing:
1) the optimize_range_tests_to_bit_test call should be guarded by
lshift_cheap_p (), Richard, any preference on where to declare that function
(tree-switch-conversion.h and include that in tree-ssa-reassoc.c, somewhere
else?)
2) much more importantly, it right now doesn't actually fixup the IL, so
instead of the desirable jump around the shift we have there just BIT_IOR_EXPR
(and the shift actually happens to be done first, before the range test).
Richard, any preference how to represent it in the IL from in between the
optimization and fixup once all bbs are reassociated?  I've been thinking about
e.g. some pass-through internal call on the TRUTH_ORIF_EXPR operand.  Another
option might be, if we'd adjust update_range_test, so that it would not only
emit a gimplification of the range test, but also an optional gimple_seq before
that, would be to push all the SSA_NAMEs that would be otherwise passed to the
internal call, into some vector, and just split bb after the def stmt of those
SSA_NAMEs and also before the (single, hopefully) user of that SSA_NAME, adding
an edge around the middle of the bb and PHI.

[Bug libstdc++/57997] Segmentation fault after returning valarray expression from an auto function

[glisse at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57997

--- Comment #9 from Marc Glisse  ---
I'd rather work on improving the warnings so we can tell the user how bad his
code is, but in case, we had a similar request in GMP, a code that was inspired
by libstdc++ valarray:

https://gmplib.org/list-archives/gmp-bugs/2014-January/003315.html

and the discussion may contain hints relevant to the valarray case.

[Bug target/63442] [AArch64] ICE with ubsan/overflow-int128.c test

[jiwang at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63442

Jiong Wang  changed:

   What|Removed |Added

 CC||jiwang at gcc dot gnu.org

--- Comment #1 from Jiong Wang  ---
I noticed this also, my code base is 216144, quite new.

[Bug libstdc++/57997] Segmentation fault after returning valarray expression from an auto function

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57997

Jonathan Wakely  changed:

   What|Removed |Added

   Severity|normal  |enhancement

--- Comment #8 from Jonathan Wakely  ---
I'm pretty sure our implementation conforms to the standard, expression
templates don't mix well with auto/decltype, but libc++ does seem to make code
like this work somehow so it is a reasonable enhancement request.

[Bug libstdc++/60519] Debug mode should check comparators for irreflexivity

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60519

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-10-13
 CC||fdumont at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug libstdc++/57740] C++11 std::thread not usable with static linking

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57740

--- Comment #11 from Jonathan Wakely  ---
Since r213922 pthread_create should get linked in, but apparently not
pthread_join.

[Bug regression/62102] [5 Regression]: gcc.dg/torture/pr48953.c -O2 -flto

[hubicka at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62102

--- Comment #6 from Jan Hubicka  ---
Since this testcase also involves VLA, can you, please, test if the patch for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62127
(now in mainline) fixes the problem?

[Bug c++/62127] [5 Regression] ICE with VLA in constructor

[hubicka at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62127

Jan Hubicka  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #6 from Jan Hubicka  ---
Fixed.

[Bug c++/62127] [5 Regression] ICE with VLA in constructor

[hubicka at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62127

--- Comment #5 from Jan Hubicka  ---
Author: hubicka
Date: Mon Oct 13 14:43:24 2014
New Revision: 216150

URL: https://gcc.gnu.org/viewcvs?rev=216150&root=gcc&view=rev
Log:

PR tree-optimization/62127
* g++.dg/torture/pr62127.C: New testcase.
* tree.c (remap_type_1): When remapping array, remap
also its type.

Added:
trunk/gcc/testsuite/g++.dg/torture/pr62127.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-inline.c

[Bug libstdc++/57403] A vector of volatile int doesn't work, but one of volatile void * does

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57403

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #6 from Jonathan Wakely  ---
The standard containers don't support volatile types.

[Bug target/53513] [SH] Add support for fschg and fpchg insns and improve fenv support

[olegendo at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53513

--- Comment #20 from Oleg Endo  ---
(In reply to Oleg Endo from comment #19)
> 
> No I didn't.  That was a patch for PR 63260.  Sorry for the noise.


Now I have.  For both '-m4 -ml' and '-m4 -mb' there are a few new failures:

FAIL: gcc.dg/attr-isr.c scan-assembler-times [^f]r[0-9][ \t]*, 8
(SH specific test 'gcc.dg/attr-isr.c' should be moved to 'gcc.target/sh')

FAIL: gcc.target/sh/attr-isr-nosave_low_regs.c scan-assembler-not [^f]r1[,0-3]
FAIL: gcc.target/sh/attr-isr-nosave_low_regs.c scan-assembler-not [^f]r[0-9][
\t]*,
FAIL: gcc.target/sh/attr-isr-trapa.c scan-assembler-not r1[,0-3]
FAIL: gcc.target/sh/pr54680.c scan-assembler-times lds\t 6
FAIL: gcc.target/sh/pragma-isr-nosave_low_regs.c scan-assembler-not
[^f]r1[,0-3]
FAIL: gcc.target/sh/pragma-isr-nosave_low_regs.c scan-assembler-not [^f]r[0-9][
\t]*,
FAIL: gcc.target/sh/pragma-isr-trapa.c scan-assembler-not r1[,0-3]
FAIL: gcc.target/sh/pragma-isr-trapa2.c scan-assembler-not r1[,0-3]
FAIL: gcc.target/sh/pragma-isr-trapa2.c scan-assembler-times [^_]fpscr 3
FAIL: gcc.target/sh/pragma-isr-trapa2.c scan-assembler-times r[0-7]\n 3


The failures seem to be related to ISR-like function handling or the tests need
adjustments because they assume that fpscr is accessed in a particular way,
which is now about to change.

I'd like to ignore ISR function problems for now, and fix it as part of PR
57339.

[Bug middle-end/63376] [5.0 Regression] ICE: in operator[], at vec.h:736 compiling team.c

[danglin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63376

John David Anglin  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #7 from John David Anglin  ---
Fixed.

[Bug libstdc++/63524] New: FAIL: 27_io/basic_ostream/inserters_arithmetic/char/hexfloat.cc (test for excess errors)

[danglin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63524

Bug ID: 63524
   Summary: FAIL:
27_io/basic_ostream/inserters_arithmetic/char/hexfloat
.cc (test for excess errors)
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: danglin at gcc dot gnu.org
  Host: hppa2.0w-hp-hpux11.11
Target: hppa2.0w-hp-hpux11.11
 Build: hppa2.0w-hp-hpux11.11

spawn /test/gnu/gcc/objdir/./gcc/xg++ -shared-libgcc
-B/test/gnu/gcc/objdir/./gc
c -nostdinc++ -L/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/src
-L/t
est/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/src/.libs
-L/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/libsupc++/.libs
-B/opt/gnu/gcc/gcc-5.0
/hppa2.0w-hp-hpux11.11/bin/ -B/opt/gnu/gcc/gcc-5.0/hppa2.0w-hp-hpux11.11/lib/
-isystem /opt/gnu/gcc/gcc-5.0/hppa2.0w-hp-hpux11.11/include -isystem
/opt/gnu/gcc/
gcc-5.0/hppa2.0w-hp-hpux11.11/sys-include
-B/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libstdc++-v3/src/.libs
-D_GLIBCXX_ASSERT -fmessage-length=0 -g -O2 -DLO
CALEDIR="." -nostdinc++
-I/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include/hppa2.0w-hp-hpux11.11
-I/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/lib
stdc++-v3/include -I/test/gnu/gcc/gcc/libstdc++-v3/libsupc++
-I/test/gnu/gcc/gcc/libstdc++-v3/include/backward
-I/test/gnu/gcc/gcc/libstdc++-v3/testsuite/util /
test/gnu/gcc/gcc/libstdc++-v3/testsuite/27_io/basic_ostream/inserters_arithmetic/char/hexfloat.cc
-std=gnu++11 ./libtestc++.a -lm -o ./hexfloat.exe
In file included from
/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include/cassert:43:0,
 from
/test/gnu/gcc/gcc/libstdc++-v3/testsuite/util/testsuite_hooks.h:58,
 from
/test/gnu/gcc/gcc/libstdc++-v3/testsuite/27_io/basic_ostre
am/inserters_arithmetic/char/hexfloat.cc:26:/test/gnu/gcc/gcc/libstdc++-v3/testsuite/27_io/basic_ostream/inserters_arithmeti
c/char/hexfloat.cc: In function 'void test01()':
/test/gnu/gcc/gcc/libstdc++-v3/testsuite/27_io/basic_ostream/inserters_arithmetic/char/hexfloat.cc:51:17:
error: 'stod' is not a member of 'std'
   VERIFY( os && std::stod(os.str()) == d );
 ^
/test/gnu/gcc/gcc/libstdc++-v3/testsuite/27_io/basic_ostream/inserters_arithmetic/char/hexfloat.cc:51:3:
note: in expansion of macro 'VERIFY'
   VERIFY( os && std::stod(os.str()) == d );
   ^
/test/gnu/gcc/gcc/libstdc++-v3/testsuite/27_io/basic_ostream/inserters_arithmetic/char/hexfloat.cc:60:17:
error: 'stod' is not a member of 'std'
   VERIFY( os && std::stod(os.str()) == d );
 ^
/test/gnu/gcc/gcc/libstdc++-v3/testsuite/27_io/basic_ostream/inserters_arithmetic/char/hexfloat.cc:60:3:
note: in expansion of macro 'VERIFY'
   VERIFY( os && std::stod(os.str()) == d );
   ^
/test/gnu/gcc/gcc/libstdc++-v3/testsuite/27_io/basic_ostream/inserters_arithmetic/char/hexfloat.cc:80:17:
error: 'stod' is not a member of 'std'
   VERIFY( os && std::stod(os.str()) == d );
 ^
/test/gnu/gcc/gcc/libstdc++-v3/testsuite/27_io/basic_ostream/inserters_arithmetic/char/hexfloat.cc:80:3:
note: in expansion of macro 'VERIFY'
   VERIFY( os && std::stod(os.str()) == d );
   ^
/test/gnu/gcc/gcc/libstdc++-v3/testsuite/27_io/basic_ostream/inserters_arithmetic/char/hexfloat.cc:86:17:
error: 'stod' is not a member of 'std'
   VERIFY( os && std::stod(os.str()) == d );
 ^
/test/gnu/gcc/gcc/libstdc++-v3/testsuite/27_io/basic_ostream/inserters_arithmetic/char/hexfloat.cc:86:3:
note: in expansion of macro 'VERIFY'
   VERIFY( os && std::stod(os.str()) == d );
   ^
/test/gnu/gcc/gcc/libstdc++-v3/testsuite/27_io/basic_ostream/inserters_arithmetic/char/hexfloat.cc:
In function 'void test02()':
/test/gnu/gcc/gcc/libstdc++-v3/testsuite/27_io/basic_ostream/inserters_arithmetic/char/hexfloat.cc:107:17:
error: 'stold' is not a member of 'std'
   VERIFY( os && std::stold(os.str()) == d );
 ^
/test/gnu/gcc/gcc/libstdc++-v3/testsuite/27_io/basic_ostream/inserters_arithmetic/char/hexfloat.cc:107:3:
note: in expansion of macro 'VERIFY'
   VERIFY( os && std::stold(os.str()) == d );
   ^
/test/gnu/gcc/gcc/libstdc++-v3/testsuite/27_io/basic_ostream/inserters_arithmetic/char/hexfloat.cc:113:17:
error: 'stold' is not a member of 'std'
   VERIFY( os && std::stold(os.str()) == d );
 ^
/test/gnu/gcc/gcc/libstdc++-v3/testsuite/27_io/basic_ostream/inserters_arithmetic/char/hexfloat.cc:113:3:
note: in expansion of macro 'VERIFY'
   VERIFY( os && std::stold(os.str()) == d );
   ^
/test/gnu/gcc/gcc/libstdc++-v3/testsuite/27_io/basic_ostream/inserters_arithmetic/char/hexfloat.cc:130:17:
error: 'stold' is not a member of 'std'
   VERIFY( os && std::stold(os.str()) == d );
 ^
/test/gnu/gcc/gcc/libstdc++-v3/testsuite/27_io/basic_ostream/inserters

[Bug tree-optimization/63379] [4.8 Regression] Incorrect vectorization when enabling SSE and O3, initialises loop with wrong value

[clyon at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63379

clyon at gcc dot gnu.org changed:

   What|Removed |Added

 CC||clyon at gcc dot gnu.org

--- Comment #8 from clyon at gcc dot gnu.org ---
After this commit, I've noticed that this new test appears as FAIL on target
aarch64_be-none-linux-gnu.

My gcc.log shows:
PASS: gcc.dg/vect/pr63379.c (test for excess errors)

*** EXIT code 4242
emu: host signal 6
FAIL: gcc.dg/vect/pr63379.c execution test

I'm using qemu as execution engine.

[Bug libstdc++/56109] Add light-weight ABI-compatible debug checks to standard containers

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56109

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-10-13
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
Confirmed.

c.f. https://gcc.gnu.org/ml/libstdc++/2014-06/msg00105.html

[Bug libstdc++/41628] _GLIBCXX_DEBUG feature: check for unstable iterators

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41628

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2014-10-13
 Ever confirmed|0   |1

--- Comment #3 from Jonathan Wakely  ---
We need example code showing the problem you want to check for.

[Bug libstdc++/57350] std::align missing

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57350

Jonathan Wakely  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |5.0

--- Comment #13 from Jonathan Wakely  ---
Fixed on trunk.

[Bug libstdc++/57350] std::align missing

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57350

--- Comment #12 from Jonathan Wakely  ---
Author: redi
Date: Mon Oct 13 14:08:44 2014
New Revision: 216149

URL: https://gcc.gnu.org/viewcvs?rev=216149&root=gcc&view=rev
Log:
PR libstdc++/57350
* include/std/memory (align): Do not adjust correctly aligned address.
* testsuite/20_util/align/2.cc: New.

Added:
trunk/libstdc++-v3/testsuite/20_util/align/2.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/std/memory

[Bug target/63260] [SH] fabs, fneg do not need fp-mode setting and do not use fpscr

[kkojima at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63260

--- Comment #5 from Kazumoto Kojima  ---
(In reply to Oleg Endo from comment #4)
> If the failures on my side go away after that, I'll commit
> the patch from comment #2, OK?

Please go ahead.

[Bug bootstrap/63496] ../../gcc/ipa-polymorphic-call.c:2117:1: error: assuming signed overflow does not occur when assuming that (X + c) < X is always false [-Werror=strict-overflow]

[hubicka at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63496

Jan Hubicka  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #5 from Jan Hubicka  ---
Fixed.

[Bug rtl-optimization/60664] comparison of constant SPR_POINTER with unsigned_flag is always false

[manu at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60664

Manuel López-Ibáñez  changed:

   What|Removed |Added

   Keywords|diagnostic  |
  Component|c++ |rtl-optimization
Summary|bool / out of range int |comparison of constant
   |comparison warning failure  |SPR_POINTER with
   ||unsigned_flag is always
   ||false

--- Comment #8 from Manuel López-Ibáñez  ---
(In reply to David Binderman from comment #7)
> 
> #define SUBREG_CHECK_PROMOTED_SIGN(RTX, SIGN)   \
> ((SIGN) == SRP_POINTER ? SUBREG_PROMOTED_GET (RTX) == SRP_POINTER   \
>  : (SIGN) == SRP_SIGNED ? SUBREG_PROMOTED_SIGNED_P (RTX)\
>  : SUBREG_PROMOTED_UNSIGNED_P (RTX))
> 
> Leaving aside the side issue of ? : being right associative,
> so some () would help clarify, I notice that 
> 
> const int SRP_POINTER = -1;
> const int SRP_SIGNED = 0;
> const int SRP_UNSIGNED = 1;
> const int SRP_SIGNED_AND_UNSIGNED = 2;
> 
> so it looks as if this bitfield 
> 
>   unsigned unsigned_flag : 1;
> 
> is being compared to SRP_POINTER. One possible fix might be to change 
> the value of SRP_POINTER to 3 and see if the problem goes away.
> 
> Clang certainly seems to be finding a problem, AFAIK.


It seems to me that independently of the value of SRP_POINTER, the result will
be always false. Thus, I don't see the bug. In any case, someone else would
need to decide whether this is actually a bug or not. RTL is not my expertise.

[Bug tree-optimization/63512] [5 Regression] ICE: error: virtual use of statement not up-to-date

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63512

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2014-10-13
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Richard Biener  ---
Mine.

[Bug fortran/63514] functions containing volatile are considered pure

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63514

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-10-13
 Ever confirmed|0   |1

--- Comment #2 from Richard Biener  ---
The fortran frontend must do sth wrong here - it seems to mark the function
pure itself and either fold or the FE even does the optimization (look at
the .original dump).

[Bug c++/60664] bool / out of range int comparison warning failure

[dcb314 at hotmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60664

David Binderman  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

--- Comment #7 from David Binderman  ---
(In reply to Manuel López-Ibáñez from comment #6)
> I think it is a different warning for which clang uses the same switch
> (-Wbool-compare only warns about boolean expressions). It is also not
> obvious that there is a bug there. Perhaps it is a false positive by Clang.

I looked into this and the definition of SUBREG_CHECK_PROMOTED_SIGN
around line 2200 of gcc/rtl.h seems important.

#define SUBREG_CHECK_PROMOTED_SIGN(RTX, SIGN)   \
((SIGN) == SRP_POINTER ? SUBREG_PROMOTED_GET (RTX) == SRP_POINTER   \
 : (SIGN) == SRP_SIGNED ? SUBREG_PROMOTED_SIGNED_P (RTX)\
 : SUBREG_PROMOTED_UNSIGNED_P (RTX))

Leaving aside the side issue of ? : being right associative,
so some () would help clarify, I notice that 

const int SRP_POINTER = -1;
const int SRP_SIGNED = 0;
const int SRP_UNSIGNED = 1;
const int SRP_SIGNED_AND_UNSIGNED = 2;

so it looks as if this bitfield 

  unsigned unsigned_flag : 1;

is being compared to SRP_POINTER. One possible fix might be to change 
the value of SRP_POINTER to 3 and see if the problem goes away.

Clang certainly seems to be finding a problem, AFAIK.

[Bug bootstrap/63523] [5.0 regression] gcc/cp/pt.c -Werror=format breaks bootstrap on sparc-linux

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63523

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |5.0