[Bug c/60156] New: GCC doesn't warn about variadic main

[mpolacek at gcc dot gnu.org]

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

Bug ID: 60156
   Summary: GCC doesn't warn about variadic main
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org

E.g. on
int main (int argc, char *argv[], ...) { }
with -Wpedantic.

[Bug c/60156] GCC doesn't warn about variadic main

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2014-02-12
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
I have a patch for 5.0.

[Bug c++/60047] [4.7/4.8/4.9 Regression] ICE with defaulted copy constructor and virtual base class

[paolo at gcc dot gnu.org]

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

--- Comment #3 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Wed Feb 12 08:45:46 2014
New Revision: 207712

URL: http://gcc.gnu.org/viewcvs?rev=207712&root=gcc&view=rev
Log:
/cp
2014-02-12  Paolo Carlini  

PR c++/60047
* method.c (implicitly_declare_fn): A constructor of a class with
virtual base classes isn't constexpr (7.1.5p4).

/testsuite
2014-02-12  Paolo Carlini  

PR c++/60047
* g++.dg/cpp0x/pr60047.C: New.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/pr60047.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/method.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/60047] [4.7/4.8 Regression] ICE with defaulted copy constructor and virtual base class

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 CC|jason at gcc dot gnu.org   |
 Resolution|--- |FIXED
   Assignee|paolo.carlini at oracle dot com|unassigned at gcc dot 
gnu.org
   Target Milestone|--- |4.9.0
Summary|[4.7/4.8/4.9 Regression]|[4.7/4.8 Regression] ICE
   |ICE with defaulted copy |with defaulted copy
   |constructor and virtual |constructor and virtual
   |base class  |base class

--- Comment #4 from Paolo Carlini  ---
Fixed for 4.9.0. Note that there is no ICE in release mode anyway.

[Bug target/60157] New: adding -mstrict-align for i386 and x86_64 architecture

[vinxxe at gmail dot com]

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

Bug ID: 60157
   Summary: adding -mstrict-align for i386 and x86_64 architecture
   Product: gcc
   Version: 4.4.6
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vinxxe at gmail dot com

Created attachment 32113
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32113&action=edit
source code to reproduce the problem

the pthread_cond_wait nptl function enters an infinite loop, never suspending
the calling thread, if the address of the condition variable is misaligned.
Now, this is not a gcc bug, obviously, but my question is: 
does it make sense to add the target option 

-mstrict-align

to the i386 and x86_64 architectures, so that these kind of problem can be
detected at compilation time?

attached you will find a source code example to reproduce the problem
execute the program with 

strace -f 

to see a neverending series of 

[pid  2922] futex(0x80499fd, FUTEX_WAIT_PRIVATE, 1, NULL) = -1 EINVAL (Invalid
argument)

here follows some info of my linux machine


cat /proc/version
Linux version 2.6.32-220.7.1.el6.centos.plus.i686 (root@thalix11dev) (gcc
version 4.4.6 20110731 (Red Hat 4.4.6-3) (GCC) ) #1 SMP Mon Oct 21 07:05:28
UTC 2013

rpm -qa | grep glibc
glibc-devel-2.12-1.47.i686
glibc-common-2.12-1.47.i686
glibc-2.12-1.47.i686
glibc-debuginfo-2.12-1.47.i686
glibc-headers-2.12-1.47.i686
glibc-utils-2.12-1.47.i686
glibc-debuginfo-common-2.12-1.47.i686
glibc-static-2.12-1.47.i686

cat /proc/cpuinfo
processor: 0
vendor_id: GenuineIntel
cpu family: 15
model: 3
model name: Intel(R) Pentium(R) 4 CPU 2.80GHz
stepping: 4
cpu MHz: 2799.930
cache size: 1024 KB
fdiv_bug: no
hlt_bug: no
f00f_bug: no
coma_bug: no
fpu: yes
fpu_exception: yes
cpuid level: 5
wp: yes
flags: fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat
pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe constant_tsc up pebs bts
pni dtes64 monitor ds_cpl cid xtpr
bogomips: 5586.31
clflush size: 64
cache_alignment: 128
address sizes: 36 bits physical, 32 bits virtual
power management:

rpm -qa | grep gcc
gcc-4.4.6-3.el6.i686
libgcc-4.4.6-3.el6.i686
gcc-c++-4.4.6-3.el6.i686

[Bug rtl-optimization/60116] [4.8/4.9 Regression] wrong code at -Os on x86_64-linux-gnu in 32-bit mode

[ebotcazou at gcc dot gnu.org]

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

--- Comment #16 from Eric Botcazou  ---
Author: ebotcazou
Date: Wed Feb 12 08:49:55 2014
New Revision: 207713

URL: http://gcc.gnu.org/viewcvs?rev=207713&root=gcc&view=rev
Log:
PR rtl-optimization/60116
* combine.c (try_combine): Also remove dangling REG_DEAD notes on the
other_insn once the combination has been validated.

Added:
trunk/gcc/testsuite/gcc.c-torture/execute/20140212-1.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/combine.c
trunk/gcc/testsuite/ChangeLog

[Bug target/60157] adding -mstrict-align for i386 and x86_64 architecture

[vinxxe at gmail dot com]

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

vinxxe at gmail dot com changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug rtl-optimization/60116] [4.8/4.9 Regression] wrong code at -Os on x86_64-linux-gnu in 32-bit mode

[ebotcazou at gcc dot gnu.org]

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

--- Comment #17 from Eric Botcazou  ---
Author: ebotcazou
Date: Wed Feb 12 08:51:57 2014
New Revision: 207714

URL: http://gcc.gnu.org/viewcvs?rev=207714&root=gcc&view=rev
Log:
PR rtl-optimization/60116
* combine.c (try_combine): Also remove dangling REG_DEAD notes on the
other_insn once the combination has been validated.

Added:
branches/gcc-4_8-branch/gcc/testsuite/gcc.c-torture/execute/20140212-1.c
  - copied unchanged from r207713,
trunk/gcc/testsuite/gcc.c-torture/execute/20140212-1.c
Modified:
branches/gcc-4_8-branch/gcc/ChangeLog
branches/gcc-4_8-branch/gcc/combine.c
branches/gcc-4_8-branch/gcc/testsuite/ChangeLog

[Bug rtl-optimization/60116] [4.8/4.9 Regression] wrong code at -Os on x86_64-linux-gnu in 32-bit mode

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #18 from Eric Botcazou  ---
Thanks for reporting the problem.

[Bug fortran/60060] [4.9 Regression] lto1: internal compiler error: in add_AT_specification, at dwarf2out.c:4096

[rguenth at gcc dot gnu.org]

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

--- Comment #9 from Richard Biener  ---
Author: rguenth
Date: Wed Feb 12 09:01:30 2014
New Revision: 207715

URL: http://gcc.gnu.org/viewcvs?rev=207715&root=gcc&view=rev
Log:
2014-02-12  Richard Biener  

PR lto/60060
* lto-lang.c (lto_write_globals): Do not call
wrapup_global_declarations or emit_debug_global_declarations
but emit debug info for non-function scope variables
directly.

Modified:
trunk/gcc/lto/ChangeLog
trunk/gcc/lto/lto-lang.c

[Bug fortran/49636] [F03] ASSOCIATE construct confused with slightly complicated case

[paul.richard.thomas at gmail dot com]

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

--- Comment #6 from paul.richard.thomas at gmail dot com  ---
 Dear Dominique,

Thanks for the heads-up about -m32 - I thought that the code would be
immune to word length changes ***sigh***

Cheers

Paul

On 12 February 2014 00:40, dominiq at lps dot ens.fr
 wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49636
>
> --- Comment #5 from Dominique d'Humieres  ---
>> Created attachment 32098 [details]
>> A fix for this problem
>
> AFAICT it fixes the problem for 64 bit mode only. In 32 bit mode the ICE is
> gone, but I get at run time
>
> i_good= 1 3 5
>  i_bad= 1** 3
>
>> I am sure that this trick will fix pr57019 too.  This latter is claimed
>> to be a regression but I am sure that it never worked :-)  Nonetheless,
>> I will take advantage of the regression label!
>>
>> I will work on it tomorrow night.
>>
>> By the way, this patch regtests OK on trunk.  I have to make sure
>> that substrings of character arrays work OK with ASSOCIATE.
>
> Did you regtest with -m32? I see gfortran.dg/associated_target_5.f03 failing 
> at
> execution time with -m32, as well as the first test in pr57522
>
>0   1   2   3
>0   4   1   5
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
> You are the assignee for the bug.

[Bug debug/60152] [4.9 Regression] multiple AT_calling_convention attributes generated after r205679

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-02-12
 CC|rguenth at gcc dot gnu.org |
   Target Milestone|--- |4.9.0
Summary|[4.9.0 Regression] multiple |[4.9 Regression] multiple
   | AT_calling_convention  |AT_calling_convention
   |attributes generated after  |attributes generated after
   |r205679 |r205679
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed.

[Bug fortran/60060] [4.9 Regression] lto1: internal compiler error: in add_AT_specification, at dwarf2out.c:4096

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #10 from Richard Biener  ---
Fixed.

[Bug middle-end/60092] posix_memalign not recognized to derive alias and alignment info

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu.org

--- Comment #18 from Tobias Burnus  ---
(In reply to Richard Biener from comment #1)
> We could "lower"
>   posix_memalign (&ptr, align, size);
> to
>   posix_memalign (&ptr, align, size);
>   ptr = __builtin_assume_algined (ptr, align);
> and hope for FRE to fix things up enough to make that useful.


I wonder about mm_malloc. I assume for config/i386/pmm_malloc.h, it is already
handled via posix_memalign, but shouldn't one also handle
config/i386/gmm_malloc.h? For instance via

--- a/gcc/config/i386/gmm_malloc.h
+++ b/gcc/config/i386/gmm_malloc.h
@@ -61,7 +61,11 @@ _mm_malloc (size_t size, size_t align)
   /* Store the original pointer just before p.  */
   ((void **) aligned_ptr) [-1] = malloc_ptr;

+#if defined(__GNUC__) && __GNUC__ >= 4 && __GNUC_MINOR__ >= 7
+  return __builtin_assume_aligned(aligned_ptr, align);
+#else
   return aligned_ptr;
+#endif
 }

 static __inline__ void

[Bug debug/60152] [4.9 Regression] multiple AT_calling_convention attributes generated after r205679

[burnus at gcc dot gnu.org]

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

--- Comment #2 from Tobias Burnus  ---
See PR 60060 comment 7 for some details and a backtrace of the two
add_calling_convention_attribute calls.

[Bug rtl-optimization/60116] [4.8/4.9 Regression] wrong code at -Os on x86_64-linux-gnu in 32-bit mode

[ebotcazou at gcc dot gnu.org]

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

--- Comment #19 from Eric Botcazou  ---
Author: ebotcazou
Date: Wed Feb 12 10:16:34 2014
New Revision: 207716

URL: http://gcc.gnu.org/viewcvs?rev=207716&root=gcc&view=rev
Log:
PR rtl-optimization/60116
* combine.c (try_combine): Fix oversight in previous change.

Modified:
trunk/gcc/combine.c

[Bug rtl-optimization/60116] [4.8/4.9 Regression] wrong code at -Os on x86_64-linux-gnu in 32-bit mode

[ebotcazou at gcc dot gnu.org]

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

--- Comment #20 from Eric Botcazou  ---
Author: ebotcazou
Date: Wed Feb 12 10:17:08 2014
New Revision: 207717

URL: http://gcc.gnu.org/viewcvs?rev=207717&root=gcc&view=rev
Log:
PR rtl-optimization/60116
* combine.c (try_combine): Fix oversight in previous change.

Modified:
branches/gcc-4_8-branch/gcc/combine.c

[Bug middle-end/60092] posix_memalign not recognized to derive alias and alignment info

[jakub at gcc dot gnu.org]

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

--- Comment #19 from Jakub Jelinek  ---
(In reply to Tobias Burnus from comment #18)
> (In reply to Richard Biener from comment #1)
> > We could "lower"
> >   posix_memalign (&ptr, align, size);
> > to
> >   posix_memalign (&ptr, align, size);
> >   ptr = __builtin_assume_algined (ptr, align);
> > and hope for FRE to fix things up enough to make that useful.
> 
> 
> I wonder about mm_malloc. I assume for config/i386/pmm_malloc.h, it is
> already handled via posix_memalign, but shouldn't one also handle
> config/i386/gmm_malloc.h? For instance via
> 
> --- a/gcc/config/i386/gmm_malloc.h
> +++ b/gcc/config/i386/gmm_malloc.h
> @@ -61,7 +61,11 @@ _mm_malloc (size_t size, size_t align)
>/* Store the original pointer just before p.  */
>((void **) aligned_ptr) [-1] = malloc_ptr;
> 
> +#if defined(__GNUC__) && __GNUC__ >= 4 && __GNUC_MINOR__ >= 7
> +  return __builtin_assume_aligned(aligned_ptr, align);
> +#else
>return aligned_ptr;
> +#endif
>  }
> 
>  static __inline__ void

No, why?  ccp of course understands the dynamic realignment:
  aligned_ptr = (void *) (((size_t) malloc_ptr + align)
  & ~((size_t) (align) - 1));
so will know that aligned_ptr is align bytes aligned.

[Bug c/60158] New: powerpc: usage of the .data.rel.ro.local section

[jal2 at gmx dot de]

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

Bug ID: 60158
   Summary: powerpc: usage of the .data.rel.ro.local section
   Product: gcc
   Version: 4.8.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jal2 at gmx dot de

This bug may concern the gcc documentation on section usage only.

Crosscompiling "Das U-Boot" with gcc 4.8.2 for powerpc with
-fpic -mrelocatable, some addresses are put into a section .data.rel.ro.local,
e.g. the address of "qwerty" from

printf("%p\n", "qwerty");

There is no corresponding entry in the .fixup section.
As "Das U-Boot" relocates itself to RAM using .got2/.got and .fixup sections
only, how shall the section .data.rel.ro.local be handled?

Currently it contains addresses only, but this may depend on the source code.
I put .data.rel.ro.local into the GOT which solved my problem, but I'm not sure
if this is the intention of the gcc developers.

I've tried gcc 4.7.3 which put the address of "qwerty" into the GOT directly,
i.e. there was no .data.rel.ro.local section and the string address was
accessed with one redirection less.

details:
- gcc version: powerpc-softfloat-linux-gnuspe-gcc (Gentoo 4.8.2 p1.3r1,
pie-0.5.8r1) 4.8.2
- gcc command line (some -I removed):
  -g -gdwarf-2  -Os   -fpic -mrelocatable \
  -meabi \
  -D__KERNEL__ -DCONFIG_SYS_TEXT_BASE=0xef77 \
  -fno-builtin  -ffreestanding \
  -isystem /usr/lib/gcc/powerpc-softfloat-linux-gnuspe/4.8.1/include \
  -nostdinc -pipe  -DCONFIG_PPC -D__powerpc__ -ffixed-r2 -Wa,-me500 \
  -msoft-float -mno-string -mspe=yes -mno-spe -Wall -Wstrict-prototypes \
  -fno-stack-protector -Wno-format-nonliteral -Wno-format-security \
  -fstack-usage"

[Bug rtl-optimization/60159] New: improve code for conditional sibcall

[jay.foad at gmail dot com]

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

Bug ID: 60159
   Summary: improve code for conditional sibcall
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jay.foad at gmail dot com

If I compile this code for x86-64 I get:

$ cat jcc.c
extern int f(int x);
int g(int x) { return x > 3 ? f(x) : x; }

$ cc1 -quiet -O3 jcc.c -o -
...
g:
.LFB0:
.cfi_startproc
cmpl$3, %edi
jg  .L4
movl%edi, %eax
ret
.p2align 4,,10
.p2align 3
.L4:
jmp f
.cfi_endproc

This code would be simpler and shorter if the jg-to-jmp sequence was replaced
with a single "jg f" instruction.

I'm using gcc built from svn trunk r207717.

[Bug lto/60150] [4.9 Regression] ICE in function_and_variable_visibility, at ipa.c:1000

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |4.9.0

[Bug target/43546] [4.7/4.8/4.9 Regression] ICE: in assign_stack_local_1, at function.c:353 with -mpreferred-stack-boundary=2 -msseregparm

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #14 from Jakub Jelinek  ---
Created attachment 32114
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32114&action=edit
gcc49-pr43546.patch

This untested patch fixes this for me, the dynamic stack realignment code is
then aware of the DFmode that might need to be possibly spilled.
The cost patch isn't wrong either, but at that level we really can't determine
if the constant load will be zero cost (when we will attempt to load it into a
i387 stack register) or more expensive (if it is loaded into a SSE register).

[Bug target/43546] [4.7/4.8/4.9 Regression] ICE: in assign_stack_local_1, at function.c:353 with -mpreferred-stack-boundary=2 -msseregparm

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||uros at gcc dot gnu.org

--- Comment #15 from Jakub Jelinek  ---
Yet another option, perhaps better, would be to add a new predicate, that would
return true for a MEM operand for which avoid_constant_pool_reference returns a
CONST_DOUBLE floating point constant (other than signalling NaN?), and add
another define_insn before *extendsfdf2_i387 that would use that predicate on
the second operand and would do what *extendsfdf2_i387 does, but have also a
"=x", "m" alternative that would be later on split into a load of the constant
widened to DFmode in memory.  Then we should get better code when trying to
load a DFmode constant into a DFmode register and compress_float_constant
decided to compress it, while it isn't a win in the end.

Or both my patch and this change.

[Bug rtl-optimization/60159] improve code for conditional sibcall

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
Not sure if that is desirable though, it will mess up debug/unwind info.

[Bug rtl-optimization/59999] [4.9 Regression] Sign extension in loop regression blocks generation of zero overhead loop

[pa...@matos-sorge.com]

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

--- Comment #22 from Paulo J. Matos  ---
After some thought, I am concluding this cannot actually be optimized and that
GCC 4.5.4 was better because it was taking advantage of an undefined behaviour
that doesn't exist.

The thought process is as follows. The whole process has to do with this type
of loop:
void foo (int loopCount)
{
  short i;
  for (i = 0; (int)i < loopCount; i++)
...
}

GCC 4.5.4 was assuming i++ could have undefined behaviour and the increment was
done in type short. Then i was promoted to int through a sign_extend and
compared to loopCount. This undefined behaviour allows GCC 4.5.4 to generate an
int scev for the loop.

In GCC 4.8 or later (haven't tested with 4.6 or 4.7), i++ is known not to have
undefined behaviour. i++ due to C integer promotion rules is: i = (short)
((int) i + 1). GCC validly simplifies to i = (short) ((unsigned short)i + 1).
This is then sign extended to int for comparison. GCC cannot generate an int
scev because it's not simple: (int) (short) {1, +, 1}_1.

This can validly loop forever if loopCount > SHORT_MAX.
For example, is loopCount is SHORT_MAX + 1, then when i reaches SHORT_MAX and
is incremented by one the addition is fine because is done in (unsigned short)
and then truncated using modulo 2 (implementation defined behaviour) to short,
therefore never reaching loopCount and looping forever.

In RTL we get the following sequence:
r4:SI <- [loopCount]
r0:HI <- 0

code label...

...

r2:HI <- r1:HI + 1
r3:SI <- sign_extend r2:HI

p0:BI <- r3:SI < r4:SI
loop to code label if p0:BI

I was tempted to simplify this to:
r4:SI <- [loopCount]
r0:SI <- 0

code label...

...

r2:SI <- r1:SI + 1

p0:BI <- r2:SI < r4:SI
loop to code label if p0:BI

However this will never have an infinite loop behaviour if r4:SI == SHORT_MAX,
therefore I think that at least in this case this cannot be optimized.

I am tempted to close the bug report. Richard?

[Bug rtl-optimization/60155] ICE: in get_pressure_class_and_nregs at gcse.c:3438

[danglin at gcc dot gnu.org]

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

--- Comment #1 from John David Anglin  ---
With 4.6 and 4.7 compilers, this appears as:

gcc-4.6 -g -O2 -Wall -Wpointer-arith -Wuninitialized -Wsign-compare
-Wformat-security -Wno-pointer-sign -Wno-unused-result -fno-strict-aliasing
-D_FORTIFY_SOURCE=2 -ftrapv -fno-builtin-memset -D_FORTIFY_SOURCE=2 -g -O2
-Wformat -Werror=format-security -DLOGIN_PROGRAM=\"/bin/login\"
-DLOGIN_NO_ENDOPT -DSSH_EXTRAVERSION=\"Debian-2\"  -I. -I.. 
-I/usr/include/editline -DSSHDIR=\"/etc/ssh\"
-D_PATH_SSH_PROGRAM=\"/usr/bin/ssh\"
-D_PATH_SSH_ASKPASS_DEFAULT=\"/usr/bin/ssh-askpass\"
-D_PATH_SFTP_SERVER=\"/usr/lib/openssh/sftp-server\"
-D_PATH_SSH_KEY_SIGN=\"/usr/lib/openssh/ssh-keysign\"
-D_PATH_SSH_PKCS11_HELPER=\"/usr/lib/openssh/ssh-pkcs11-helper\"
-D_PATH_SSH_PIDDIR=\"/var/run\" -D_PATH_PRIVSEP_CHROOT_DIR=\"/var/run/sshd\"
-DHAVE_CONFIG_H -c ../ssh-keygen.c
../ssh-keygen.c: In function ‘do_fingerprint’:
../ssh-keygen.c:887:1: internal compiler error: in hoist_code, at gcse.c:4631

[Bug target/57202] Please make the intrinsics headers like immintrin.h be usable without compiler flags

[glisse at gcc dot gnu.org]

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

--- Comment #4 from Marc Glisse  ---
Can this be closed?

[Bug rtl-optimization/59999] [4.9 Regression] Sign extension in loop regression blocks generation of zero overhead loop

[rguenther at suse dot de]

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

--- Comment #23 from rguenther at suse dot de  ---
On Wed, 12 Feb 2014, pa...@matos-sorge.com wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
> 
> --- Comment #22 from Paulo J. Matos  ---
> After some thought, I am concluding this cannot actually be optimized and that
> GCC 4.5.4 was better because it was taking advantage of an undefined behaviour
> that doesn't exist.
> 
> The thought process is as follows. The whole process has to do with this type
> of loop:
> void foo (int loopCount)
> {
>   short i;
>   for (i = 0; (int)i < loopCount; i++)
> ...
> }
> 
> GCC 4.5.4 was assuming i++ could have undefined behaviour and the increment 
> was
> done in type short. Then i was promoted to int through a sign_extend and
> compared to loopCount. This undefined behaviour allows GCC 4.5.4 to generate 
> an
> int scev for the loop.
> 
> In GCC 4.8 or later (haven't tested with 4.6 or 4.7), i++ is known not to have
> undefined behaviour. i++ due to C integer promotion rules is: i = (short)
> ((int) i + 1). GCC validly simplifies to i = (short) ((unsigned short)i + 1).
> This is then sign extended to int for comparison. GCC cannot generate an int
> scev because it's not simple: (int) (short) {1, +, 1}_1.
> 
> This can validly loop forever if loopCount > SHORT_MAX.
> For example, is loopCount is SHORT_MAX + 1, then when i reaches SHORT_MAX and
> is incremented by one the addition is fine because is done in (unsigned short)
> and then truncated using modulo 2 (implementation defined behaviour) to short,
> therefore never reaching loopCount and looping forever.
> 
> In RTL we get the following sequence:
> r4:SI <- [loopCount]
> r0:HI <- 0
> 
> code label...
> 
> ...
> 
> r2:HI <- r1:HI + 1
> r3:SI <- sign_extend r2:HI
> 
> p0:BI <- r3:SI < r4:SI
> loop to code label if p0:BI
> 
> I was tempted to simplify this to:
> r4:SI <- [loopCount]
> r0:SI <- 0
> 
> code label...
> 
> ...
> 
> r2:SI <- r1:SI + 1
> 
> p0:BI <- r2:SI < r4:SI
> loop to code label if p0:BI
> 
> However this will never have an infinite loop behaviour if r4:SI == SHORT_MAX,
> therefore I think that at least in this case this cannot be optimized.
> 
> I am tempted to close the bug report. Richard?

Yes.  That sounds correct.

[Bug middle-end/60092] posix_memalign not recognized to derive alias and alignment info

[rguenth at gcc dot gnu.org]

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

--- Comment #20 from Richard Biener  ---
Author: rguenth
Date: Wed Feb 12 13:36:08 2014
New Revision: 207720

URL: http://gcc.gnu.org/viewcvs?rev=207720&root=gcc&view=rev
Log:
2014-02-12  Richard Biener  

PR middle-end/60092
* gimple-low.c (lower_builtin_posix_memalign): Lower conditional
of posix_memalign being successful.
(lower_stmt): Restrict lowering of posix_memalign to when
-ftree-bit-ccp is enabled.

* gcc.dg/torture/pr60092.c: New testcase.
* gcc.dg/tree-ssa/alias-31.c: Disable SRA.

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr60092.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple-low.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/tree-ssa/alias-31.c

[Bug rtl-optimization/59999] [4.9 Regression] Sign extension in loop regression blocks generation of zero overhead loop

[pmatos at gcc dot gnu.org]

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

pmatos at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #24 from pmatos at gcc dot gnu.org ---
Closing as invalid. Thanks Richard.

[Bug sanitizer/60142] [4.9 Regression][asan] -fsanitize=address breaks debugging - stepping into functions no longer possible

[jan.kratochvil at redhat dot com]

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

Jan Kratochvil  changed:

   What|Removed |Added

 CC||jan.kratochvil at redhat dot 
com

--- Comment #4 from Jan Kratochvil  ---
Verified GDB fails with it.
GDB puts breakpoint on second ".loc" (that is not the fist/initial ".loc") in a
function as currently neither GCC nor GCC use DW_LNS_set_prologue_end.

g++ (GCC) 4.9.0 20140212 (experimental)
-S -g -fsanitize=address

.type   _Z4testv, @function
_Z4testv:
.LASANPC512:
.LFB512:
.file 2 "asantest.C"
.loc 2 4 0
.cfi_startproc
.cfi_personality 0x3,__gxx_personality_v0
.cfi_lsda 0x3,.LLSDA512
pushq   %rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
movq%rsp, %rbp
.cfi_def_cfa_register 6
pushq   %r14
pushq   %r13
pushq   %r12
pushq   %rbx
subq$112, %rsp
.cfi_offset 14, -24
.cfi_offset 13, -32
.cfi_offset 12, -40
.cfi_offset 3, -48
leaq-128(%rbp), %rbx
movq%rbx, %r14
cmpl$0, __asan_option_detect_stack_use_after_return(%rip)
je  .L3
.loc 2 4 0
<--- here GDB puts the breakpoint
movq%rbx, %rsi
movl$96, %edi
call__asan_stack_malloc_1
movq%rax, %rbx
.L3:

GDB already workarounds a similar case of GCC PR debug/48827, this asan
prologue may look standard enough it could be possibly also workarounded in
GDB.

[Bug target/57202] Please make the intrinsics headers like immintrin.h be usable without compiler flags

[thiago at kde dot org]

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

--- Comment #5 from Thiago Macieira  ---
(In reply to Marc Glisse from comment #4)
> Can this be closed?

Oh, yeah, this is working fine in GCC 4.9.

[Bug bootstrap/60160] New: Building with -flto in CFLAGS_FOR_TARGET / CXXFLAGS_FOR_TARGET

[d.g.gorbachev at gmail dot com]

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

Bug ID: 60160
   Summary: Building with -flto in CFLAGS_FOR_TARGET /
CXXFLAGS_FOR_TARGET
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: d.g.gorbachev at gmail dot com

Created attachment 32115
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32115&action=edit
Tentative patch

Someone might want to build everything with LTO. Currently, I see two problems.

1. crtstuff.c: perhaps it'd be better to compile it with -fno-lto.
2. attribute used for _Unwind_* functions.

[Bug bootstrap/60160] Building with -flto in CFLAGS_FOR_TARGET / CXXFLAGS_FOR_TARGET

[glisse at gcc dot gnu.org]

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

--- Comment #1 from Marc Glisse  ---
Note the related: http://gcc.gnu.org/ml/gcc-patches/2014-01/msg01480.html (PR
43538) and PR 59893.

[Bug bootstrap/60160] Building with -flto in CFLAGS_FOR_TARGET / CXXFLAGS_FOR_TARGET

[trippels at gcc dot gnu.org]

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

--- Comment #2 from Markus Trippelsdorf  ---
libstdc++ also causes problems:

/var/tmp/gcc_build_dir_/./prev-gcc/xg++ -B/var/tmp/gcc_build_dir_/./prev-gcc/
-B/usr/x86_64-pc-linux-gnu/bin/ -nostdinc++
-B/var/tmp/gcc_build_dir_/prev-x86_64-pc-linux-gnu/l
ibstdc++-v3/src/.libs
-B/var/tmp/gcc_build_dir_/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs
-I/var/tmp/gcc_build_dir_/prev-x86_64-pc-linux-gnu/libstdc++-v3/include/
x86_64-pc-linux-gnu
-I/var/tmp/gcc_build_dir_/prev-x86_64-pc-linux-gnu/libstdc++-v3/include
-I/var/tmp/gcc/libstdc++-v3/libsupc++
-L/var/tmp/gcc_build_dir_/prev-x86_64-pc-lin
ux-gnu/libstdc++-v3/src/.libs
-L/var/tmp/gcc_build_dir_/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs
  -march=native -O3 -pipe -flto=jobserver -frandom-seed=1 -fprof
ile-generate -fno-lto -DIN_GCC-fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wmissing-format-attribute -pedan
tic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings  
-DHAVE_CONFIG_H -DGENERATOR_FILE
-Wl,-O1,--hash-style=gnu,--as-needed,--gc-sections,--icf=safe,--icf-iterati
ons=3  -o build/genconstants \
build/genconstants.o build/read-md.o build/errors.o
.././libiberty/libiberty.a

/var/tmp/gcc_build_dir_/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so:
error: undefined reference to 'std::istream::ignore(long)'
/var/tmp/gcc_build_dir_/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so:
error: undefined reference to 'std::basic_istream >::
ignore(long)'

[Bug target/57202] Please make the intrinsics headers like immintrin.h be usable without compiler flags

[glisse at gcc dot gnu.org]

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

Marc Glisse  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
  Known to work||4.9.0
 Resolution|--- |FIXED
   Target Milestone|--- |4.9.0

--- Comment #6 from Marc Glisse  ---
Thanks.

[Bug rtl-optimization/56965] nonoverlapping_component_refs_p is bogus and slow

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug target/60151] HAVE_AS_GOTOFF_IN_DATA is mis-detected on x86-64

[hjl at gcc dot gnu.org]

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

--- Comment #1 from hjl at gcc dot gnu.org  ---
Author: hjl
Date: Wed Feb 12 16:12:36 2014
New Revision: 207731

URL: http://gcc.gnu.org/viewcvs?rev=207731&root=gcc&view=rev
Log:
Pass --32 to GNU assembler for .long foo@GOTOFF check

PR target/60151
* configure.ac (HAVE_AS_GOTOFF_IN_DATA): Pass --32 to GNU
assembler.
* configure: Regenerated.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/configure
trunk/gcc/configure.ac

[Bug target/60151] HAVE_AS_GOTOFF_IN_DATA is mis-detected on x86-64

[hjl at gcc dot gnu.org]

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

--- Comment #2 from hjl at gcc dot gnu.org  ---
Author: hjl
Date: Wed Feb 12 16:38:50 2014
New Revision: 207733

URL: http://gcc.gnu.org/viewcvs?rev=207733&root=gcc&view=rev
Log:
Pass --32 to GNU assembler for .long foo@GOTOFF check

Backport from mainline
PR target/60151
* configure.ac (HAVE_AS_GOTOFF_IN_DATA): Pass --32 to GNU
assembler.

Modified:
branches/gcc-4_8-branch/gcc/ChangeLog
branches/gcc-4_8-branch/gcc/configure
branches/gcc-4_8-branch/gcc/configure.ac

[Bug target/60151] HAVE_AS_GOTOFF_IN_DATA is mis-detected on x86-64

[hjl at gcc dot gnu.org]

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

--- Comment #3 from hjl at gcc dot gnu.org  ---
Author: hjl
Date: Wed Feb 12 16:43:47 2014
New Revision: 207734

URL: http://gcc.gnu.org/viewcvs?rev=207734&root=gcc&view=rev
Log:
Pass --32 to GNU assembler for .long foo@GOTOFF check

Backport from mainline
PR target/60151
* configure.ac (HAVE_AS_GOTOFF_IN_DATA): Pass --32 to GNU
assembler.

Modified:
branches/gcc-4_7-branch/gcc/ChangeLog
branches/gcc-4_7-branch/gcc/configure
branches/gcc-4_7-branch/gcc/configure.ac

[Bug target/60151] HAVE_AS_GOTOFF_IN_DATA is mis-detected on x86-64

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #4 from H.J. Lu  ---
Fixed in GCC 4.7.4/4.8.3/4.9.0.

[Bug other/59893] Use LTO for libgcc.a, libstdc++.a, etc

[d.g.gorbachev at gmail dot com]

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

--- Comment #7 from Dmitry Gorbachev  ---
I used to build GCC 4.8/4.9 with -flto in C(XX)FLAGS_FOR_TARGET for quite some
time (both native i686-pc-linux-gnu and a cross), and it seems to work.  I saw
two problems: PR 60160 (for which a patch exists), and PR 59472 (annoying, but
not fatal).

[Bug middle-end/59737] [4.9 Regression] ice from optimize_inline_calls

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||jakub at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #5 from Jakub Jelinek  ---
Author: hubicka
Date: Tue Feb 11 22:54:21 2014
New Revision: 207702

URL: http://gcc.gnu.org/viewcvs?rev=207702&root=gcc&view=rev
Log:

PR lto/59468
* ipa-utils.h (possible_polymorphic_call_targets): Update prototype
and wrapper.
* ipa-devirt.c: Include demangle.h
(odr_violation_reported): New static variable.
(add_type_duplicate): Update odr_violations.
(maybe_record_node): Add completep parameter; update it.
(record_target_from_binfo): Add COMPLETEP parameter;
update it as needed.
(possible_polymorphic_call_targets_1): Likewise.
(struct polymorphic_call_target_d): Add nonconstruction_targets;
rename FINAL to COMPLETE.
(record_targets_from_bases): Sanity check we found the binfo;
fix COMPLETEP updating.
(possible_polymorphic_call_targets): Add NONCONSTRUTION_TARGETSP
parameter, fix computing of COMPLETEP.
(dump_possible_polymorphic_call_targets): Imrove readability of dump; at
LTO time do demangling.
(ipa_devirt): Use nonconstruction_targets; Improve dumps.
* gimple-fold.c (gimple_get_virt_method_for_vtable): Add can_refer
parameter.
(gimple_get_virt_method_for_binfo): Likewise.
* gimple-fold.h (gimple_get_virt_method_for_binfo,
gimple_get_virt_method_for_vtable): Update prototypes.

PR lto/59468
* g++.dg/ipa/devirt-27.C: New testcase.
* g++.dg/ipa/devirt-26.C: New testcase.

Added:
trunk/gcc/testsuite/g++.dg/ipa/devirt-26.C
trunk/gcc/testsuite/g++.dg/ipa/devirt-27.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/cp/decl2.c
trunk/gcc/gimple-fold.c
trunk/gcc/gimple-fold.h
trunk/gcc/ipa-devirt.c
trunk/gcc/ipa-utils.h
trunk/gcc/testsuite/ChangeLog

[Bug libgcc/60161] New: updating collapsed because of no authentified software packets (lib32cc1)

[dierk.zeissler at gmail dot com]

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

Bug ID: 60161
   Summary: updating collapsed because of no authentified software
packets (lib32cc1)
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: blocker
  Priority: P3
 Component: libgcc
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dierk.zeissler at gmail dot com

Installation von Paketen erforderlich, denen nicht vertraut werden kann

Diese Aktion würde die Installation von Paketen aus nicht authentifizierten
Software-Paketquellen erfordern.

lib32gcc1

Installierte Version: 4:0.8.9-0ubuntu0.12.04.1

Hardware 64 Bit-Version

[Bug middle-end/59737] [4.9 Regression] ice from optimize_inline_calls

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Wed Feb 12 16:55:51 2014
New Revision: 207735

URL: http://gcc.gnu.org/viewcvs?rev=207735&root=gcc&view=rev
Log:
PR middle-end/59737
* g++.dg/ipa/pr59737.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/ipa/pr59737.C
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug libgcc/60161] updating collapsed because of no authentified software packets (lib32cc1)

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

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

Andreas Schwab  changed:

   What|Removed |Added

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

--- Comment #1 from Andreas Schwab  ---
Please report that to Ubuntu, this has nothing to do with gcc.

[Bug target/58115] testcase gcc.target/i386/intrinsics_4.c failure

[bernd.edlinger at hotmail dot de]

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

Bernd Edlinger  changed:

   What|Removed |Added

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

--- Comment #16 from Bernd Edlinger  ---
fixed on trunk.

Thanks!

[Bug c++/43680] [DR 1022] G++ is too aggressive in optimizing away bounds checking with enums

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

  Known to fail||

--- Comment #19 from Jason Merrill  ---
It looks like the committee is making this code undefined again:

http://open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1766

[Bug target/59516] [4.9 Regression] Multiple definition of `X' / of `non-virtual thunk to X' errors with LTO

[ktietz at gcc dot gnu.org]

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

Kai Tietz  changed:

   What|Removed |Added

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

--- Comment #1 from Kai Tietz  ---
This issue is a known binutils' ld bug. Issue here is that object-file
arguments aren't treated proper for LTO-plugin.
Work-a-round for this is adding all files into library by ar-tool, and doing
linking via it (Side-note be aware that you will need to mark classes then via
dllexport).

[Bug c/59193] Unused postfix operator temporaries

[mtewoodbury at gmail dot com]

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

Max TenEyck Woodbury  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|INVALID |---

--- Comment #2 from Max TenEyck Woodbury  ---
The practice is very common in C (and the GCC code) and is NOT peculiar to C++.

The creation of temporary values that are never used is a waste of resources
and, even when removed by the optimizer, represent an, admittedly minor,
defect.
This may be a minor point but it is NOT controversial.  Also, it is not really
a
matter of style.  Your lack of insight on this is somewhat disturbing.  Marking
the argument as INVALID is just plain wrong.  It should be left open to provide
a reference for patches that address this problem.

[Bug c/59193] Unused postfix operator temporaries

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |INVALID

--- Comment #3 from Andrew Pinski  ---
a++ and ++a should be treated as similar and don't change the semantics of the
loading from the variable or increase the number of loads if never used for
scalar types.  Now in C++, they are different when you overload them for
classes but we don't use that feature yet.

[Bug rtl-optimization/57193] [4.7/4.8/4.9 Regression] suboptimal register allocation for SSE registers

[rth at gcc dot gnu.org]

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

Richard Henderson  changed:

   What|Removed |Added

   Last reconfirmed|2013-05-07 00:00:00 |2014-2-12
 CC||rth at gcc dot gnu.org

--- Comment #4 from Richard Henderson  ---
It seems like incomplete reload inheritance:

(insn 19 16 21 2 (set (reg:V8HI 107)
  (truncate:V8HI
(lshiftrt:V8SI
  (mult:V8SI (zero_extend:V8SI (subreg:V8HI (reg:V16QI 105) 0))
 (zero_extend:V8SI (subreg:V8HI (reg/v:V2DI 101 [ f ]) 0)))
  (const_int 16 [0x10]
  include/emmintrin.h:1362 2134 {*umulv8hi3_highpart}
  (expr_list:REG_DEAD (reg:V16QI 105) (nil)))

  Creating newreg=111 from oldreg=107, assigning class SSE_REGS to r111
   19: r111:V8HI=trunc(zero_extend(r111:V8HI)*zero_extend(r101:V2DI#0) 0>>0x10)
  REG_DEAD r105:V16QI
Inserting insn reload before:
   31: r111:V8HI=r105:V16QI#0
Inserting insn reload after:
   32: r107:V8HI=r111:V8HI

The new register r111 does wind up inheriting from r107, but not
transitively to r105.  Thus we wind up leaving the copy insn 31.

[Bug target/58158] [4.8/4.9 Regression] ICE with conditional moves on GPRs with a floating point conditional on mipsel with loongson2f

[rth at gcc dot gnu.org]

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

Richard Henderson  changed:

   What|Removed |Added

 CC||rth at gcc dot gnu.org

--- Comment #13 from Richard Henderson  ---
(In reply to Tom Li from comment #12)
>  {
> +  if (!ISA_HAS_FP_CONDMOVE &&
> +  GET_MODE_CLASS (GET_MODE (XEXP (operands[1], 0))) != MODE_INT)
> +FAIL;

The patch is clearly wrong.  It's attempting to look through
a subreg around operands[1], but of course that subreg will
not always exist.

[Bug target/58158] [4.8/4.9 Regression] ICE with conditional moves on GPRs with a floating point conditional on mipsel with loongson2f

[pinskia at gcc dot gnu.org]

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

--- Comment #14 from Andrew Pinski  ---
(In reply to Richard Henderson from comment #13)
> (In reply to Tom Li from comment #12)
> >  {
> > +  if (!ISA_HAS_FP_CONDMOVE &&
> > +  GET_MODE_CLASS (GET_MODE (XEXP (operands[1], 0))) != MODE_INT)
> > +FAIL;
> 
> The patch is clearly wrong.  It's attempting to look through
> a subreg around operands[1], but of course that subreg will
> not always exist.

Actually it is correct as operands[1] will be an comparison_operator which
always have two operands itself.

[Bug middle-end/60162] New: [4.9 lra regression] mlra appears to be using the FP registers as a set of spill registers for ARM.

[ramana at gcc dot gnu.org]

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

Bug ID: 60162
   Summary: [4.9 lra regression] mlra appears to be using the FP
registers as a set of spill registers for ARM.
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ramana at gcc dot gnu.org

This is something that I've just noticed with spec2k gzip : longest_match. 

If the function is compiled for a cross arm-none-linux-gnueabihf toolchain with
the following parameters, 

--with-arch=armv7-a --with-fpu=neon --with-float=hard

With a cross toolchain using mlra by default I get code that loads a value into
an FP register and then moves this over to an integer register. While this is
not that big a problem on some of the newer cores, it will be an issue on older
cores where the latency of such transfers can be pretty high.

You can experiment with -mno-lra to see the difference in code generated and
this is essentially something that has shown up rather recently. 

Bisecting and will follow up in the morning with a testcase.

[Bug ada/60163] New: Ada style checks: token spacing enforces space only around the first of several multiplying operators

[piotr.trojanek at gmail dot com]

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

Bug ID: 60163
   Summary: Ada style checks: token spacing enforces space only
around the first of several multiplying operators
   Product: gcc
   Version: 4.7.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: piotr.trojanek at gmail dot com

Created attachment 32116
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32116&action=edit
Example of wrong

The -gnatyt option of the GNAT Ada compiler should check if binary operators
other than ** are surrounded by spaces. However, it works correctly only for
the first of several multiplying operators in an expression.

For example, expression "x * x + x*x" does not trigger any warning.

When compiling the attached file with "gnatmake -gnatyt -gnatwe -gnatf style"
there should be 4 warning messages, but currently there are only 2.

The problem occurs in the 4.7.4 version of the GNAT compiler; tested on Linux
x86_64, but probably is platform-independent.

[Bug libgomp/60035] [PATCH] make it possible to use OMP on both sides of a fork (without violating standard)

[njs at pobox dot com]

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

--- Comment #2 from Nathaniel J. Smith  ---
Good point -- sent.

http://gcc.gnu.org/ml/gcc-patches/2014-02/msg00813.html

[Bug rtl-optimization/60162] [4.9 lra regression] mlra appears to be using the FP registers for integer values and then moving on to GPR registers.

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|middle-end  |rtl-optimization

--- Comment #1 from Andrew Pinski  ---
This sounds like the cost model of moving between register classes is not
correct for the arm backend.

[Bug ada/60163] Ada style checks: token spacing enforces space only around the first of several multiplying operators

[piotr.trojanek at gmail dot com]

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

--- Comment #1 from Piotr Trojanek  ---
Created attachment 32117
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32117&action=edit
Patch to solve the problem

The attached patch solves the problem. I tested it with GNAT GPL 2013, but the
file is against the latest FSF sources.

[Bug ada/60164] New: Missing parenthesis in the documentation

[piotr.trojanek at gmail dot com]

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

Bug ID: 60164
   Summary: Missing parenthesis in the documentation
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: piotr.trojanek at gmail dot com

Created attachment 32118
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32118&action=edit
Correct nested parentheses in the gnatmem documentation.

There are nested parentheses in the documentation of the gnatmem. The closing
parenthesis is missing. The attached patch solves the problem.

[Bug rtl-optimization/60155] ICE: in get_pressure_class_and_nregs at gcse.c:3438

[danglin at gcc dot gnu.org]

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

--- Comment #2 from John David Anglin  ---
Breakpoint 1, get_pressure_class_and_nregs (insn=0xfab51d98, nregs=0xfaf028c0)
at ../../gcc/gcc/gcse.c:3459
3459  gcc_assert (set != NULL_RTX);
(gdb) p debug_rtx (insn)
(insn 212 211 213 18 (parallel [
(set (reg/v:SI 114 [ num ])
(plus:SI (reg/v:SI 114 [ num ])
(const_int 1 [0x1])))
(trap_if (ne (plus:DI (sign_extend:DI (reg/v:SI 114 [ num ]))
(sign_extend:DI (const_int 1 [0x1])))
(sign_extend:DI (plus:SI (reg/v:SI 114 [ num ])
(const_int 1 [0x1]
(const_int 0 [0]))
]) ../ssh-keygen.c:830 113 {addvsi3}
 (nil))
$1 = void

[Bug rtl-optimization/60155] ICE: in get_pressure_class_and_nregs at gcse.c:3438

[danglin at gcc dot gnu.org]

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

--- Comment #3 from John David Anglin  ---
Function compiles without "-ftrapv".

[Bug c/16602] Spurious warnings about pointer to array -> const pointer to array conversion

[sebunger44 at gmail dot com]

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

Sebastian Unger  changed:

   What|Removed |Added

 CC||sebunger44 at gmail dot com

--- Comment #11 from Sebastian Unger  ---
(In reply to Joseph S. Myers from comment #6)
> When you apply const to "array of int", the resulting type is "array of
> const int" not "const array of int"; that's how type qualifiers and arrays
> interact in C, there is no such thing as a qualified array type.  "array of
> const int" is not a const-qualified type in C.

Can anybody provide a reference to the standard to the effect of this claim?
Because I can't find any, and I do believe this statement is wrong. All other
comments claiming this issue to be invalid are based on this (as are all
examples claiming to show that the original issue breaks the constness
promise).

I'm inclined to reopen this issue unless someone can point me to the standard
for this.

[Bug c/16602] Spurious warnings about pointer to array -> const pointer to array conversion

[pinskia at gcc dot gnu.org]

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

--- Comment #12 from Andrew Pinski  ---
(In reply to Sebastian Unger from comment #11)
> I'm inclined to reopen this issue unless someone can point me to the
> standard for this.

From 6.7.3/9 (in the C11 draft):
If the specification of an array type includes any type qualifiers, the element
type is so qualified, not the array type. If the specification of a function type
includes any type
qualifiers, the behavior is undefined. 136)

[Bug c/16602] Spurious warnings about pointer to array -> const pointer to array conversion

[sebunger44 at gmail dot com]

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

--- Comment #13 from Sebastian Unger  ---
I believe the intent behind that is that the qualification of an array type is
identical to that of its element type.

I.e. the statement here is that an 'array of const ints' is identical to a
'const array of ints' rather than that the latter does not exist.

Thus a 'pointer to array of ints' is perfectly convertible to 'pointer to array
of const ints' which makes perfect sense. Note that this is completely
different from a 'pointer to pointer to int' or any such as has been given in
previous examples.

At the very least GCC should treat it such in Gnu99 mode, as it makes perfect
sense to have the following code compile successfully:


typedef int IntArray[3];

void foo(IntArray const* a);

void bar(IntArray* a)
{
   foo(a);
}

[Bug fortran/60148] strings in NAMELIST do not honor DELIM= in open statement

[jvdelisle at gcc dot gnu.org]

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

--- Comment #7 from Jerry DeLisle  ---
The regressions are two fold:

1) Tests are specifically looking for a " or a ' when no longer generated,

and

2) We need to also revise namelist reading of character types which are no
longer delimited

namelist_18.f90, modify test
namelist_38.f90, error in read
namelist_56.f90, ...
namelist_70.f90, ...

My patch is as follows so far, a little different from Steve's. With this patch
I don't explicitly write a space delim because we write one in the first chunk
below.  This was needed for namelist_16.f90

Index: write.c
===
--- write.c(revision 206864)
+++ write.c(working copy)
@@ -1921,7 +1921,8 @@
  to column 2. Reset the repeat counter.  */

   dtp->u.p.no_leading_blank = 0;
-  write_character (dtp, &semi_comma, 1, 1);
+  if (dtp->u.p.nml_delim || (obj->type != BT_CHARACTER))
+write_character (dtp, &semi_comma, 1, 1);
   if (num > 5)
 {
   num = 0;
@@ -1971,9 +1972,18 @@

   /* Set the delimiter for namelist output.  */
   tmp_delim = dtp->u.p.current_unit->delim_status;
+  switch (tmp_delim)
+{
+  case DELIM_APOSTROPHE:
+dtp->u.p.nml_delim = '\'';
+break;
+  case DELIM_QUOTE:
+dtp->u.p.nml_delim = '"';
+break;
+  default:
+dtp->u.p.nml_delim = '\0';
+}

-  dtp->u.p.nml_delim = tmp_delim == DELIM_APOSTROPHE ? '\'' : '"';
-
   /* Temporarily disable namelist delimters.  */
   dtp->u.p.current_unit->delim_status = DELIM_NONE;

I have not looked at read yet.

[Bug tree-optimization/60165] New: "may be used uninitialized" warning with -O3 but not with -O2

[vincent-gcc at vinc17 dot net]

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

Bug ID: 60165
   Summary: "may be used uninitialized" warning with -O3 but not
with -O2
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vincent-gcc at vinc17 dot net

With:

gcc (Debian 20140111-1) 4.9.0 20140111 (experimental) [trunk revision 206552]

I get the following inconsistency in the warnings:

ypig% cat out.i
int a, b;
int fn2 (int, int);
int fn1 (int *p1)
{
if (fn2 (a, 0))
*p1 = b;
int c;
fn1 (&c);
return c;
}
ypig% gcc-snapshot -c -Wall -Werror=maybe-uninitialized -O2 out.i
ypig% gcc-snapshot -c -Wall -Werror=maybe-uninitialized -O3 out.i
out.i: In function 'fn1':
out.i:9:5: error: 'c' may be used uninitialized in this function
[-Werror=maybe-uninitialized]
 return c;
 ^
cc1: some warnings being treated as errors
ypig% 

I don't know whether this is regarded as normal, but this looks strange.

Note: I got this problem when compiling round_prec.c from the GNU MPFR trunk. I
generated the preprocessed file with -E, then used creduce on the following
script:

#!/bin/sh
{
  gcc-snapshot -c -Wall -Werror=maybe-uninitialized -O2 out.i && \
  ! gcc-snapshot -c -Wall -Werror=maybe-uninitialized -O3 out.i
} >/dev/null 2>&1

to generate the simple testcase (and fixed the declarations to avoid additional
warnings -- I think I should have used -Werror in the script to avoid them in
the first place).

[Bug libgcc/60166] New: ARM default NAN encoding violates EABI

[joey.ye at arm dot com]

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

Bug ID: 60166
   Summary: ARM default NAN encoding violates EABI
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgcc
  Assignee: unassigned at gcc dot gnu.org
  Reporter: joey.ye at arm dot com

#include 
#include 
#include 
int g;
float i = 0.0 ,j = 0.0 ;

int main()
{
float f = i / j;
memcpy(&g, &f, sizeof(g));
printf("f=%f, hex=%x\n", f, g);
return 0;
}

When built for ARM thumb1, result is:
f=nan, hex=7fff

While according to the RTABI
(http://infocenter.arm.com/help/topic/com.arm.doc.ihi0043d/IHI0043D_rtabi.pdf)
section 4.1.1.1:

When not otherwise specified by IEEE 754, the result on an invalid operation
should be the quiet NaN bit pattern with only the most significant bit of the
significand set, and all other significand bits zero.

So current libgcc is violating ARM EABI.

I have a patch under testing.

[Bug c++/60167] New: [4.9 regression] Bogus error: conflicting declaration

[ppluzhnikov at google dot com]

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

Bug ID: 60167
   Summary: [4.9 regression] Bogus error: conflicting declaration
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ppluzhnikov at google dot com

The test case below fails to compile with current trunk:
g++ (GCC) 4.9.0 20140213 (experimental)

g++ -c t.cc
t.cc:10:48: error: conflicting declaration ‘typename Foo::Bar Foo::cache’
 template  typename Foo::Bar Foo::cache;
^
t.cc:5:14: note: previous declaration as ‘Foo::Bar Foo::cache’
   static Bar cache;
  ^
t.cc:10:48: error: declaration of ‘Foo::Bar Foo::cache’ outside of class
is not definition [-fpermissive]
 template  typename Foo::Bar Foo::cache;
^

/// --- cut ---
template 
struct Foo {
  typedef int Bar;

  static Bar cache;
};

// template  int Foo::cache;  // OK

template  typename Foo::Bar Foo::cache;

/// --- cut ---

Removing reference (template  struct Foo) also makes it compile.

Compiles fine with gcc-4.8 and Clang.

[Bug c++/60168] New: Incorrect check in ~unique_ptr() when Deleter::pointer type is not a pointer type

[ashish.sadanandan at gmail dot com]

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

Bug ID: 60168
   Summary: Incorrect check in ~unique_ptr() when Deleter::pointer
type is not a pointer type
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ashish.sadanandan at gmail dot com

The following compiles on both VS2013 and ICC 13.0.1

#include 

struct del
{
using pointer = int;
void operator()(int) {}
};

int main()
{
std::unique_ptr p;
}

It fails on gcc4.8.1 with this error

/usr/include/c++/4.8/bits/unique_ptr.h: In instantiation of
'std::unique_ptr<_Tp, _Dp>::~unique_ptr() [with _Tp = int; _Dp = del]':

main.cpp:13:35:   required from here

/usr/include/c++/4.8/bits/unique_ptr.h:183:12: error: invalid operands of types
'int' and 'std::nullptr_t' to binary 'operator!='

  if (__ptr != nullptr)

I believe that last if statement should be

if (__ptr != pointer())

[Bug target/60169] New: ICE ARM thumb1 handles far jump

[joey.ye at arm dot com]

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

Bug ID: 60169
   Summary: ICE ARM thumb1 handles far jump
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: joey.ye at arm dot com

Created attachment 32119
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32119&action=edit
testcase

Trunk gcc 20140210:

arm-none-eabi-gcc -mthumb -fomit-frame-pointer -mthumb -fPIC -mcpu=cortex-m0
-mno-lra png.c -c

png.c: In function 'png_do_read_swap_alpha':
png.c:104:1: internal compiler error: in reload, at reload1.c:1058
 }
 ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug c++/60168] Incorrect check in ~unique_ptr() when Deleter::pointer type is not a pointer type

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
Not a bug, the type unique_ptr::pointer must meet the requirements of a
NullablePointer which includes being comparable with nullptr, so int is not
allowed

[Bug target/60169] ICE ARM thumb1 handles far jump

[joey.ye at arm dot com]

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

--- Comment #1 from Joey Ye  ---
Caused by http://gcc.gnu.org/ml/gcc-patches/2012-12/msg01229.html, reason is
that stack layout shouldn't change during and after reload.

I have a patch fixing it under testing.

[Bug c++/60168] Incorrect check in ~unique_ptr() when Deleter::pointer type is not a pointer type

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
The standard also specifies the behaviour of ~unique_ptr in terms of
comparing the stored pointer with nullptr.

[Bug plugins/59335] Plugin doesn't build on trunk

[joey.ye at arm dot com]

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

Joey Ye  changed:

   What|Removed |Added

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

--- Comment #9 from Joey Ye  ---
Resolved in trunk

[Bug c++/60168] Incorrect check in ~unique_ptr() when Deleter::pointer type is not a pointer type

[ashish.sadanandan at gmail dot com]

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

--- Comment #3 from Ashish Sadanandan  ---
You are right, of course. Not a bug, but it's disappointing that it isn't. If
that comparison were against a value initialized unique_ptr::pointer,
instead of nullptr, it'd allow unique_ptr to be used to manage any generic
`handle` type, which may not meet the requirements of NullablePointer.

[Bug c/60170] New: No -Wtype-limits warning with -O1

[chengniansun at gmail dot com]

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

Bug ID: 60170
   Summary: No -Wtype-limits warning with -O1
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chengniansun at gmail dot com

For the expression "-4L == (*g = l == 0)": 
1) gcc -O0 warns that the comparison is always false, which is desired. 
2) with gcc -O1, the expression is optimized away, and the function fn1
directly returns "0". No -Wtype-limits warning for this expression. 

Since warning is a way to notify the programmers of potential bugs, IMHO it may
still be necessary to report the warning at -O1, even though Gcc has no policy
to ensure the warning consistency between -O0 and -O. 



$: cat s.c
unsigned short *g;
int fn1() {
  unsigned char ***const l = 0;
  return -4L == (*g = l == 0);
}
$: gcc-trunk -Wtype-limits -c s.c
s.c: In function ‘fn1’:
s.c:4:14: warning: comparison is always false due to limited range of data type
[-Wtype-limits]
   return -4L == (*g = l == 0);
  ^
$: gcc-trunk -Wtype-limits -c -O1 s.c
$: gcc-trunk --version
gcc-trunk (GCC) 4.9.0 20140210 (experimental)
Copyright (C) 2014 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.