[Bug debug/63623] New: Lots of functions get -fvar-tracking silently turned off unnecessarily

[jakub at gcc dot gnu.org]

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

Bug ID: 63623
   Summary: Lots of functions get -fvar-tracking silently turned
off unnecessarily
   Product: gcc
   Version: 4.8.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org

I have got a report that when glibc is compiled with gcc 4.8.x, the debug info
for the bytes parameter to __libc_malloc is wrong in the prologue (and
epilogue).

Here is a reduced testcase for x86_64-linux:
-std=gnu99 -fgnu89-inline -O2 -fmerge-all-constants -frounding-math -g -dA
-fPIC:

void *a;
extern void *(*d) (__SIZE_TYPE__, const void *);
void *foo (void *, __SIZE_TYPE__);
void *bar (void *, __SIZE_TYPE__);

void *
__libc_malloc (__SIZE_TYPE__ bytes)
{
  void *b, *c;
  if (__builtin_expect (d != 0, 0))
return d (bytes, 0);
  b = a;
  if (!b)
return 0;
  c = foo (b, bytes);
  if (!c)
b = bar (b, bytes);
  return b;
}

r203167 on the trunk "fixed" this by slightly changing the CFG (because of the
__builtin_expect), so the bug went latent on this testcase.

I've investigated this and found that this is because the function doesn't have
frame pointer and vt_stack_adjustments failed on the function, which precludes
not just -fvar-tracking-assignments, but also -fvar-tracking altogether.
And the reason for that is that it doesn't handle i?86/x86_64 pop instructions,
like:
(insn/f:TI 76 81 77 8 (set (reg:DI 3 bx)
(mem:DI (post_inc:DI (reg/f:DI 7 sp)) [0 S8 A8])) rh1151226.i:19 75
{*popdi1}
 (expr_list:REG_CFA_ADJUST_CFA (set (reg/f:DI 7 sp)
(plus:DI (reg/f:DI 7 sp)
(const_int 8 [0x8])))
(nil)))
where it doesn't account for any stack adjustment in such functions.  Thus,
stack_adjust values may be either wrong in the VTA info, leading to wrong
debug, or, if because of that there is some disagreement on the edges between
what the stack_adjust value should be, it gives up on -fvar-tracking
altogether.

[Bug lto/63603] [4.9/5 Regression] Linking with -fno-lto still invokes LTO

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

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

--- Comment #9 from Tobias Burnus  ---
FIXED on the trunk and the 4.9 branch.

[Bug rtl-optimization/58726] [4.7 Regression] wrong code at -Os on x86_64-linux-gnu (affecting trunk/4.7/4.6, but not 4.8)

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|4.7.4   |4.8.3

[Bug go/55969] libgo fails to build on darwin

[ian at gcc dot gnu.org]

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

--- Comment #7 from ian at gcc dot gnu.org  ---
Author: ian
Date: Thu Oct 23 03:34:02 2014
New Revision: 216573

URL: https://gcc.gnu.org/viewcvs?rev=216573&root=gcc&view=rev
Log:
Commit old ChangeLog entry forgotten in commit of actual change.

PR go/55969
* configure.ac: Disable libgo on some systems where it does not
work.

Modified:
trunk/ChangeLog

[Bug c++/63497] std::regex can't handle [^class] correctly and cause runtime crash

[timshen at gcc dot gnu.org]

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

--- Comment #5 from Tim Shen  ---
Author: timshen
Date: Thu Oct 23 03:15:52 2014
New Revision: 216572

URL: https://gcc.gnu.org/viewcvs?rev=216572&root=gcc&view=rev
Log:
PR libstdc++/63497
include/bits/regex_executor.h (_Executor::_M_word_boundary): Remove
unused parameter.
include/bits/regex_executor.tcc (_Executor::_M_dfs,
_Executor::_M_word_boundary): Avoid dereferecing _M_current at _M_end
or other invalid position.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/regex_executor.h
trunk/libstdc++-v3/include/bits/regex_executor.tcc

[Bug target/63615] [5 Regression] FAIL: gcc.target/i386/addr-sel-1.c

[amodra at gmail dot com]

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

--- Comment #2 from Alan Modra  ---
Breakpoint 1, simplify_plus_minus (code=code@entry=PLUS,
mode=mode@entry=SImode, op0=op0@entry=0x76d4b558,
op1=op1@entry=0x76d483a8) at /src/gcc-virgin/gcc/simplify-rtx.c:3967
(gdb) p debug_rtx(op0)
(plus:SI (reg:SI 0 ax [96])
(const_int 1 [0x1]))
$1 = void
(gdb) p debug_rtx(op1)
(symbol_ref:SI ("a") )
$2 = void

Believe it or not, this PR is due to fixing the accounting of n_constants. 
Previously seeing n_constants > 1 (which is wrong, there is only one int
constant above) set "canonicalized".  Now, nothing sets "canonicalized" and
simplify_plus_minus exits with NULL.

[Bug target/63615] [5 Regression] FAIL: gcc.target/i386/addr-sel-1.c

[amodra at gmail dot com]

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

Alan Modra  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2014-10-23
 CC|amodra at gcc dot gnu.org  |amodra at gmail dot com
   Assignee|unassigned at gcc dot gnu.org  |amodra at gmail dot com
 Ever confirmed|0   |1

--- Comment #1 from Alan Modra  ---
Investigating

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

[kkojima at gcc dot gnu.org]

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

--- Comment #77 from Kazumoto Kojima  ---
Created attachment 33788
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33788&action=edit
another reduced test case of compiler/vam

This is an another test case got from compiler/vam test.
The generated code for the second foo call with non LRA compiler at
-O2 looks like

mov.b@(7,r8),r0
extu.br0,r7
mov.b@(6,r8),r0
extu.br0,r6
mov.b@(5,r8),r0
extu.br0,r5
mov.b@(4,r8),r0
jsr@r9
extu.br0,r4

and the corresponding code with sh-lra is here

mov.b@(7,r8),r0
mov.br0,@(1,r15)
mov.b@(6,r8),r0
mov.br0,@(2,r15)
mov.b@(5,r8),r0
mov.br0,@(3,r15)
mov.b@(4,r8),r0
mov.br0,@r15
mov.b@(1,r15),r0
extu.br0,r7
mov.b@(2,r15),r0
extu.br0,r6
mov.b@(3,r15),r0
extu.br0,r5
mov.b@r15,r0
jsr@r9
extu.br0,r4

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

[kkojima at gcc dot gnu.org]

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

--- Comment #76 from Kazumoto Kojima  ---
Created attachment 33787
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33787&action=edit
a reduced test case of SCiBE compiler/vam test

compiler/vam is a test which is an example of code size regression
from non LRA compiler.  With -O2, non LRA compiler generates code like

mov.lr0,@(56,r15)
mov#64,r1
add#2,r0
movr13,r2
addr15,r1
mov.lr0,@(60,r15)
add#18,r2
movr13,r14
add#2,r0
mov.lr2,@(0,r1)
mov.lr0,@(4,r1)
add#2,r2
add#2,r0
mov.lr2,@(8,r1)
mov.lr0,@(12,r1)

and the corresponding code generated by sh-lra compiler looks like

mov.lr1,@(56,r15)
mov#17,r1
addr2,r1
mov.lr1,@(60,r15)
mov#2,r14
mov#16,r10
mov#18,r1
addr2,r1
addr2,r14
addr2,r10
mov#64,r2
addr15,r2
mov.lr1,@r2
mov#19,r1
mov#68,r2
addr13,r1
addr15,r2
mov.lr1,@r2
mov#20,r1
mov#72,r2
addr13,r1
addr15,r2
mov.lr1,@r2
mov#21,r1
mov#76,r2
addr13,r1
addr15,r2
mov.lr1,@r2

which shows that base+disp addressing mode wasn't used for the insn
(set reg (mem (plus sp N))) when N >= 64.
It looks that non LRA compiler uses targetm.legitimize_address to
handle that case and splits it to (set new_reg (plus sp M)) and
(set reg (mem (plus new_reg N-M))) so as to N-M is a legitimate
display constant for base+disp addressing.

[Bug target/63503] [AArch64] A57 executes fused multiply-add poorly in some situations

[wdijkstr at arm dot com]

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

--- Comment #19 from Wilco  ---
(In reply to Evandro from comment #16)
> (In reply to Wilco from comment #15)
> > Using -Ofast is not any different from -O3 -ffast-math when compiling
> > non-Fortran code. As comment 10 shows, both loops are vectorized, however
> > LLVM unrolls twice and uses multiple accumulators while GCC doesn't.
> 
> You're right.  LLVM produces:
> 
> .LBB0_1:// %vector.body
> // =>This Inner Loop Header: Depth=1
> add  x11, x9, x8
> add  x12, x10, x8
> ldp  q2, q3, [x11]
> ldp  q4, q5, [x12]
> add  x8, x8, #32 // =32
> fmla v0.2d, v2.2d, v4.2d
> fmla v1.2d, v3.2d, v5.2d
> cmp  x8, #128, lsl #12  // =524288
> b.ne.LBB0_1
> 
> And GCC:
> 
> .L3:
> ldr q2, [x2, x0]
> add w1, w1, 1
> ldr q1, [x3, x0]
> cmp w1, w4
> add x0, x0, 16
> fmlav0.2d, v2.2d, v1.2d
> bcc .L3
> 
> > I still don't see what this has to do with A57. You should open a generic
> > bug about GCC not applying basic loop optimizations with -O3 (in fact
> > limited unrolling is useful even for -O2).
> 
> Indeed, but I think that there's still a code-generation opportunity for A57
> here.
> 
> Note above that the registers are loaded in pairs by LLVM, while GCC, when
> it unrolls the loop, more aggressively BTW, each vector is loaded
> individually:

Load/store pair optimization should be committed soon:
https://gcc.gnu.org/ml/gcc-patches/2014-10/msg02005.html

> .L3:
> ldr q28, [x15, x16]
> add x17, x16, 16
> ldr q29, [x14, x16]
> add x0, x16, 32
> ldr q30, [x15, x17]
> add x18, x16, 48
> ldr q31, [x14, x17]
> add x1, x16, 64
> ...
> fmlav27.2d, v28.2d, v29.2d
> ...
> fmlav27.2d, v30.2d, v31.2d
> ... # Rest of 8x unroll
> bcc .L3
> 
> It also goes without saying that this code could also benefit from the
> post-increment addressing mode.

Yes I've noticed bad addressing like that and fixes are in progress. It's an
issue in iv-opt - even without post-increment enabled the obvious addressing
mode to use is immediate offset.

[Bug target/63503] [AArch64] A57 executes fused multiply-add poorly in some situations

[e.menezes at samsung dot com]

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

Evandro  changed:

   What|Removed |Added

  Attachment #33774|0   |1
is obsolete||

--- Comment #18 from Evandro  ---
Created attachment 33786
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33786&action=edit
Simple test-case

[Bug target/63503] [AArch64] A57 executes fused multiply-add poorly in some situations

[e.menezes at samsung dot com]

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

--- Comment #17 from Evandro  ---
Created attachment 33785
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33785&action=edit
Simple matrix multiplication

[Bug target/63503] [AArch64] A57 executes fused multiply-add poorly in some situations

[e.menezes at samsung dot com]

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

--- Comment #16 from Evandro  ---
(In reply to Wilco from comment #15)
> Using -Ofast is not any different from -O3 -ffast-math when compiling
> non-Fortran code. As comment 10 shows, both loops are vectorized, however
> LLVM unrolls twice and uses multiple accumulators while GCC doesn't.

You're right.  LLVM produces:

.LBB0_1:// %vector.body
// =>This Inner Loop Header: Depth=1
add  x11, x9, x8
add  x12, x10, x8
ldp  q2, q3, [x11]
ldp  q4, q5, [x12]
add  x8, x8, #32 // =32
fmla v0.2d, v2.2d, v4.2d
fmla v1.2d, v3.2d, v5.2d
cmp  x8, #128, lsl #12  // =524288
b.ne.LBB0_1

And GCC:

.L3:
ldr q2, [x2, x0]
add w1, w1, 1
ldr q1, [x3, x0]
cmp w1, w4
add x0, x0, 16
fmlav0.2d, v2.2d, v1.2d
bcc .L3

> I still don't see what this has to do with A57. You should open a generic
> bug about GCC not applying basic loop optimizations with -O3 (in fact
> limited unrolling is useful even for -O2).

Indeed, but I think that there's still a code-generation opportunity for A57
here.

Note above that the registers are loaded in pairs by LLVM, while GCC, when it
unrolls the loop, more aggressively BTW, each vector is loaded individually:

.L3:
ldr q28, [x15, x16]
add x17, x16, 16
ldr q29, [x14, x16]
add x0, x16, 32
ldr q30, [x15, x17]
add x18, x16, 48
ldr q31, [x14, x17]
add x1, x16, 64
...
fmlav27.2d, v28.2d, v29.2d
...
fmlav27.2d, v30.2d, v31.2d
... # Rest of 8x unroll
bcc .L3

It also goes without saying that this code could also benefit from the
post-increment addressing mode.

[Bug target/61915] [AArch64] High amounts of GP to FP register moves using LRA on AArch64

[wdijkstr at arm dot com]

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

--- Comment #10 from Wilco  ---
(In reply to Andrew Pinski from comment #2)
> https://gcc.gnu.org/ml/gcc/2014-05/msg00160.html

Note currently it is not possible to use FP registers for spilling using the
hooks - basically you still end up with int<->fp moves for every definition and
use (even when multiple uses are right next to each other), and
rematerialization does not happen at all.

However what you'd expect is that all spill optimizations apply first and if
all else fails every load/store of a stack slot is turned into an int<->fp
move.

[Bug rtl-optimization/63620] RELOAD lost SET_GOT dependency on Darwin

[evstupac at gmail dot com]

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

--- Comment #2 from Stupachenko Evgeny  ---
Created attachment 33784
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33784&action=edit
patch making the test and darwin bootstrap pass

[Bug lto/63603] [4.9/5 Regression] Linking with -fno-lto still invokes LTO

[burnus at gcc dot gnu.org]

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

--- Comment #8 from Tobias Burnus  ---
Author: burnus
Date: Wed Oct 22 21:42:48 2014
New Revision: 216568

URL: https://gcc.gnu.org/viewcvs?rev=216568&root=gcc&view=rev
Log:
2014-10-22  Richard Biener  
Tobias Burnus 

PR lto/63603
* gcc.c (LINK_COMMAND_SPEC): Add %{fno-lto}.


Modified:
branches/gcc-4_9-branch/gcc/ChangeLog
branches/gcc-4_9-branch/gcc/gcc.c

[Bug c/5694] Generate warnings about using unsafe string functions

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||mpolacek at gcc dot gnu.org
 Resolution|--- |FIXED
  Known to fail||

--- Comment #5 from Marek Polacek  ---
Let's close this one.

[Bug rtl-optimization/63618] CSE at IRA pass delete SET_GOT which is used later

[law at redhat dot com]

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

--- Comment #4 from Jeffrey A. Law  ---
Ignore my last comment.  I found the official submission in my queue.  Somehow
I missed it when I first went looking.

[Bug c++/63619] warning: deleting ‘void*’ is undefined has no -W flag

[fuscated at gmail dot com]

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

--- Comment #3 from Teodor Petrov  ---
We already use -Werror=delete-incomplete, so it will be easier for us, because
it will just work.

But if you ask me (as a user) it is best to just change the standard to force
these two as errors. I know this will never happen, but I have to murmur about
it.

BTW: Thanks for looking at this in such a short time :)

[Bug rtl-optimization/63618] CSE at IRA pass delete SET_GOT which is used later

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com

--- Comment #3 from Jeffrey A. Law  ---
Evgeny,

Can you post that patch for formal review along with a testcase,
bootstrap/regression test results, etc?

In general, if the patch isn't posted to gcc-patches then it's not going to get
reviewed and I really don't like having darwin (or any port for that matter)
broken this long.

[Bug bootstrap/63573] [5 Regression] libgo: ICE building libgo on powerpc-linux-gnu

[pthaugen at gcc dot gnu.org]

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

Pat Haugen  changed:

   What|Removed |Added

 CC||bergner at gcc dot gnu.org,
   ||hubicka at gcc dot gnu.org,
   ||mliska at suse dot cz

--- Comment #1 from Pat Haugen  ---
Bisected to r216305.

[Bug target/61915] [AArch64] High amounts of GP to FP register moves using LRA on AArch64

[wdijkstr at arm dot com]

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

Wilco  changed:

   What|Removed |Added

 CC||wdijkstr at arm dot com

--- Comment #9 from Wilco  ---
(In reply to Evandro Menezes from comment #0)
> The issue that I observed in code size due to the default use of the LRA
> results in the spilling of the FP register used to spill variables into,
> which increases code-size.

The performance cost is a much bigger issue than codesize. The problem is that
when register pressure is high, the register allocator decides to allocate
integer liveranges to FP registers and insert int<->fp moves for every
use/define (ie. you end up with far more moves than you would if it were
spilled, so it is a bad thing even if int<->fp moves are cheap).

I committed a workaround
(http://gcc.gnu.org/ml/gcc-patches/2014-09/msg00362.html) by increasing the
int<->fp move cost. Can you try this and check the issue has indeed gone? You
need -mcpu=cortex-a57.

[Bug lto/45729] -flto conflicts with -mthumb

[andre.rosa at lge dot com]

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

Andre Goddard Rosa  changed:

   What|Removed |Added

 CC||andre.rosa at lge dot com

--- Comment #3 from Andre Goddard Rosa  ---
Is LTO playing well with thumb as far as 4.8.3 is concerned or still not
supported?

Got the following when mixing "-mthumb" with "-flto=8 -fuse-linker-plugin":

| /tmp/ccQ4Z3ej.s: Assembler messages:
| /tmp/ccQ4Z3ej.s:21: Error: lo register required -- `str lr,[sp,#4]'
| /tmp/ccQ4Z3ej.s:31: Error: lo register required -- `str lr,[sp,#4]'
...
| /tmp/ccQ4Z3ej.s:1134: Error: lo register required -- `ldr lr,[sp,#0x38]'
| /tmp/ccQ4Z3ej.s:1158: Error: instruction not supported in Thumb16 mode --
`adds r3,#5'
| /tmp/ccQ4Z3ej.s:1173: Error: lo register required -- `ldr r10,[r1,#60]'
| /tmp/ccQ4Z3ej.s:1174: Error: lo register required -- `ldr r3,[r10,#0]'
| /tmp/ccQ4Z3ej.s:1186: Error: instruction not supported in Thumb16 mode --
`adds r3,#5'
| /tmp/ccQ4Z3ej.s:1201: Error: lo register required -- `ldr r10,[r1,#60]'
| /tmp/ccQ4Z3ej.s:1202: Error: lo register required -- `ldr r3,[r10,#0]'
| /tmp/ccQ4Z3ej.s:1216: Error: instruction not supported in Thumb16 mode --
`adds r3,#5'
| /tmp/ccQ4Z3ej.s:1234: Error: lo register required -- `ldr r10,[r1,#60]'
| /tmp/ccQ4Z3ej.s:1241: Error: dest must overlap one source register -- `mul
r2,r3,r0'
| /tmp/ccQ4Z3ej.s:1242: Error: instruction not supported in Thumb16 mode --
`lsls r0,r0,#3'
| /tmp/ccQ4Z3ej.s:1245: Error: unshifted register required -- `add
r3,r5,r0,lsl#0'
| /tmp/ccQ4Z3ej.s:1247: Error: instruction not supported in Thumb16 mode --
`subs r4,r4,#32'
| /tmp/ccQ4Z3ej.s:1249: Error: unshifted register required -- `add
r3,r5,r0,lsl#0'
| /tmp/ccQ4Z3ej.s:1252: Error: unshifted register required -- `mvn r3,#7'
| /tmp/ccQ4Z3ej.s:1253: Error: instruction not supported in Thumb16 mode --
`adds r0,r3'
| /tmp/ccQ4Z3ej.s:1261: Error: instruction not supported in Thumb16 mode --
`lsls r0,r0,#3'
| /tmp/ccQ4Z3ej.s:1262: Error: instruction not supported in Thumb16 mode --
`subs r0,r5,r0'

Removing LTO or -mthumb makes the problem go away.
$ ld --version
GNU ld (crosstool-NG 1.19.0 - 4.8-2014.10-x86_64) 2.24.0.20140311 Linaro
2014.03
Copyright 2013 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) a later version.
This program has absolutely no warranty.
$ gcc --version
gcc-original (crosstool-NG 1.19.0 - 4.8-2014.10-x86_64) 4.8.3 20140401
(prerelease)
Copyright (C) 2013 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 lto/63603] [4.9/5 Regression] Linking with -fno-lto still invokes LTO

[burnus at gcc dot gnu.org]

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

--- Comment #7 from Tobias Burnus  ---
Author: burnus
Date: Wed Oct 22 20:51:00 2014
New Revision: 216566

URL: https://gcc.gnu.org/viewcvs?rev=216566&root=gcc&view=rev
Log:
2014-10-22  Richard Biener  
Tobias Burnus 

PR lto/63603
* gcc.c (LINK_COMMAND_SPEC): Add %{fno-lto}.


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

[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux

[evstupac at gmail dot com]

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

--- Comment #36 from Stupachenko Evgeny  ---
(In reply to Iain Sandoe from comment #35)
> (In reply to Stupachenko Evgeny from comment #33)
> > Created attachment 33769 [details]
> > patch includes 3 patches fixing darwin bootstrap
> 
> > Do you have any ideas where darwin can treat the LC0 symbol so?
> 
> This deserves a proper answer - but I don't have enough context to give one.
> - can you point me at something specific to build or attach the .i and .s
> file relevant?

I've created PR63618 and PR63620 with small reproducers.
PR63620 is darwin only issue (note that patch from PR63618 should be applied).

> 
> Mike - any comments?
> 
> > Please try attached patch (includes all fixes) moving pushtf split earlier.
> > The bootstrap (c,c++,fortran,lto) on MAC passed (patch applied on top of
> > 216304).
> 
> this worked for me - although we're still hosed by multiple other issues
> from later commits.

[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux

[iains at gcc dot gnu.org]

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

Iain Sandoe  changed:

   What|Removed |Added

 CC||mrs at gcc dot gnu.org

--- Comment #35 from Iain Sandoe  ---
(In reply to Stupachenko Evgeny from comment #33)
> Created attachment 33769 [details]
> patch includes 3 patches fixing darwin bootstrap

> Do you have any ideas where darwin can treat the LC0 symbol so?

This deserves a proper answer - but I don't have enough context to give one.
- can you point me at something specific to build or attach the .i and .s file
relevant?

Mike - any comments?

> Please try attached patch (includes all fixes) moving pushtf split earlier.
> The bootstrap (c,c++,fortran,lto) on MAC passed (patch applied on top of
> 216304).

this worked for me - although we're still hosed by multiple other issues from
later commits.

[Bug bootstrap/63622] New: [5.0 Regression] Bootstrap fails on x86_64-apple-darwin1[34] after revision r216305

[dominiq at lps dot ens.fr]

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

Bug ID: 63622
   Summary: [5.0 Regression] Bootstrap fails on
x86_64-apple-darwin1[34] after revision r216305
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dominiq at lps dot ens.fr
CC: iains at gcc dot gnu.org, marxin at gcc dot gnu.org
  Host: x86_64-apple-darwin1[34]
Target: x86_64-apple-darwin1[34]
 Build: x86_64-apple-darwin1[34]

Bootstrap fails on x86_64-apple-darwin1[34] after revision r216305:

...
libtool: link:  /opt/gcc/p_build/./gcc/xgcc -shared-libgcc
-B/opt/gcc/p_build/./gcc -nostdinc++
-L/opt/gcc/p_build/x86_64-apple-darwin14.0.0/libstdc++-v3/src
-L/opt/gcc/p_build/x86_64-apple-darwin14.0.0/libstdc++-v3/src/.libs
-L/opt/gcc/p_build/x86_64-apple-darwin14.0.0/libstdc++-v3/libsupc++/.libs
-B/opt/gcc/gcc4.10p-216305p1/x86_64-apple-darwin14.0.0/bin/
-B/opt/gcc/gcc4.10p-216305p1/x86_64-apple-darwin14.0.0/lib/ -isystem
/opt/gcc/gcc4.10p-216305p1/x86_64-apple-darwin14.0.0/include -isystem
/opt/gcc/gcc4.10p-216305p1/x86_64-apple-darwin14.0.0/sys-include-dynamiclib
-Wl,-undefined -Wl,dynamic_lookup -o .libs/libstdc++.6.dylib 
.libs/compatibility.o .libs/compatibility-debug_list.o
.libs/compatibility-debug_list-2.o .libs/compatibility-c++0x.o
.libs/compatibility-atomic-c++0x.o .libs/compatibility-thread-c++0x.o
.libs/compatibility-chrono.o .libs/compatibility-condvar.o  
-Wl,-force_load,../libsupc++/.libs/libsupc++convenience.a
-Wl,-force_load,../src/c++98/.libs/libc++98convenience.a
-Wl,-force_load,../src/c++11/.libs/libc++11convenience.a 
-L/opt/gcc/p_build/x86_64-apple-darwin14.0.0/libstdc++-v3/libsupc++/.libs
-L/opt/gcc/p_build/x86_64-apple-darwin14.0.0/libstdc++-v3/src
-L/opt/gcc/p_build/x86_64-apple-darwin14.0.0/libstdc++-v3/src/.libs -lm 
-Wl,-single_module -Wl,-exported_symbols_list -Wl,libstdc++-symbols.explist  
-install_name  /opt/gcc/gcc4.10p-216305p1/lib/libstdc++.6.dylib
-compatibility_version 7 -current_version 7.21 -Wl,-single_module
ld: warning: cannot export hidden symbol
__cxxabiv1::__pbase_type_info::__pointer_catch(__cxxabiv1::__pbase_type_info
const*, void**, unsigned int) const from
../libsupc++/.libs/libsupc++convenience.a(pbase_type_info.o)
ld: warning: cannot export hidden symbol std::basic_stringbuf, std::allocator >::~basic_stringbuf() from
../src/c++98/.libs/libc++98convenience.a(complex_io.o)
ld: warning: cannot export hidden symbol std::basic_stringbuf, std::allocator >::~basic_stringbuf() from
../src/c++98/.libs/libc++98convenience.a(complex_io.o)
ld: warning: cannot export hidden symbol std::ctype::do_widen(char) const
from ../src/c++98/.libs/libc++98convenience.a(ctype.o)
ld: warning: cannot export hidden symbol std::ctype::do_narrow(char,
char) const from ../src/c++98/.libs/libc++98convenience.a(ctype.o)
ld: warning: cannot export hidden symbol std::ctype::do_narrow(char
const*, char const*, char, char*) const from
../src/c++98/.libs/libc++98convenience.a(ctype.o)
ld: warning: cannot export hidden symbol std::ctype::do_widen(char
const*, char const*, char*) const from
../src/c++98/.libs/libc++98convenience.a(ctype.o)
ld: warning: cannot export hidden symbol construction vtable for
std::basic_istream >-in-std::istrstream from
../src/c++98/.libs/libc++98convenience.a(strstream.o)
ld: warning: cannot export hidden symbol construction vtable for
std::basic_ostream >-in-std::ostrstream from
../src/c++98/.libs/libc++98convenience.a(strstream.o)
ld: warning: cannot export hidden symbol construction vtable for
std::basic_istream >-in-std::strstream from
../src/c++98/.libs/libc++98convenience.a(strstream.o)
ld: warning: cannot export hidden symbol construction vtable for
std::basic_iostream >-in-std::strstream from
../src/c++98/.libs/libc++98convenience.a(strstream.o)
ld: warning: cannot export hidden symbol std::ctype::do_widen(char) const
from ../src/c++98/.libs/libc++98convenience.a(ctype_members.o)
ld: warning: cannot export hidden symbol std::ctype::do_narrow(char,
char) const from ../src/c++98/.libs/libc++98convenience.a(ctype_members.o)
ld: warning: cannot export hidden symbol std::ctype::do_narrow(char
const*, char const*, char, char*) const from
../src/c++98/.libs/libc++98convenience.a(ctype_members.o)
ld: warning: cannot export hidden symbol std::ctype::do_widen(char
const*, char const*, char*) const from
../src/c++98/.libs/libc++98convenience.a(ctype_members.o)
ld: warning: cannot export hidden symbol std::ctype::do_widen(char) const
from ../src/c++98/.libs/libc++98convenience.a(locale-inst.o)
ld: warning: cannot export hidden symbol std::ctype::do_narrow(char,
char) const from ../src/c++98/.libs/libc++98convenience.a(locale-inst.o)
ld: warning: cannot export hidden symbol std::ctype::do_widen(char
const*, char const*, char*) const from
..

[Bug middle-end/63621] [5 Regression] ICE: error: Both section and comdat group is set

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org
  Component|c++ |middle-end

--- Comment #2 from Markus Trippelsdorf  ---
Started with r211434.

[Bug c/28901] -Wunused-variable ignores unused const initialised variables

[petschy at gmail dot com]

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

petschy at gmail dot com changed:

   What|Removed |Added

 CC||petschy at gmail dot com

--- Comment #7 from petschy at gmail dot com ---
For backward compatibility, wouldn't it be better to add a new flag,
-Wunused-static-const-variable, instead of changing the behaviour of
-Wunused-variable?

[Bug c++/63621] [5 Regression] ICE: error: Both section and comdat group is set

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Target|i686-pc-cygwin  |
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-10-22
  Component|target  |c++
 CC||trippels at gcc dot gnu.org
   Host|i686-pc-cygwin  |
 Ever confirmed|0   |1
Summary|[ICE] symtab_node::verify   |[5 Regression] ICE: error:
   |failed  |Both section and comdat
   ||group is set
   Target Milestone|--- |5.0
  Build|i686-pc-cygwin  |

--- Comment #1 from Markus Trippelsdorf  ---
markus@x4 tmp % cat fhandler_socket.ii
class A
{
  int m_fn1 (void *);
  int m_fn2 (bool);
};
inline int
A::m_fn2 (bool)
{
  static __attribute__ ((section (""))) int a;
  if (a)
;
  return 0;
}

int
A::m_fn1 (void *)
{
  return m_fn2 (0);
}

markus@x4 tmp % g++ -c fhandler_socket.ii
fhandler_socket.ii:19:1: error: Both section and comdat group is set
 }
 ^
_ZZN1A5m_fn2EbE1a/0 (int a) @0x7f1c0f6e1380
  Type: variable definition analyzed
  Visibility: public weak comdat comdat_group:_ZZN1A5m_fn2EbE1a one_only
section:
  References: 
  Referring: _ZN1A5m_fn2Eb/1 (read)
  Availability: not-ready
  Varpool flags:
fhandler_socket.ii:19:1: internal compiler error: symtab_node::verify failed
0x8905ac symtab_node::verify()
../../gcc/gcc/symtab.c:1145
0x890e47 symtab_node::verify_symtab_nodes()
../../gcc/gcc/symtab.c:1160
0x8a0bfd symbol_table::compile()
../../gcc/gcc/cgraphunit.c:2118
0x8a2b07 symbol_table::finalize_compilation_unit()
../../gcc/gcc/cgraphunit.c:2290
0x68498a cp_write_global_declarations()
../../gcc/gcc/cp/decl2.c:4666
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug target/63621] New: [ICE] symtab_node::verify failed

[jojelino at gmail dot com]

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

Bug ID: 63621
   Summary: [ICE] symtab_node::verify failed
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jojelino at gmail dot com
  Host: i686-pc-cygwin
Target: i686-pc-cygwin
 Build: i686-pc-cygwin

Created attachment 33783
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33783&action=edit
preprocesed source

g++ -L/tmp/winsup/i686-pc-cygwin/winsup/cygwin -isystem
/tmp/winsup/winsup/cygwin/include -B/tmp/winsup/i686-pc-cygwin/newlib/ -isystem
/tmp/winsup/i686-pc-cygwin/newlib/targ-include -isystem
/tmp/winsup/newlib/libc/include -xc++ -nostdinc -I. -I../../.././winsup/cygwin
-isystem /tmp/winsup/winsup/cygwin/include -isystem
/tmp/winsup/i686-pc-cygwin/newlib/targ-include -isystem
/tmp/winsup/newlib/libc/include -isystem /tmp/winsup/winsup/cygwin/include
-isystem /tmp/winsup/i686-pc-cygwin/newlib/targ-include -isystem
/tmp/winsup/newlib/libc/include -isystem /usr/include/c++/5.0.0 -isystem
/usr/include/c++/5.0.0/i686-pc-cygwin -isystem /usr/include/c++/5.0.0/backward
-isystem /usr/lib/gcc/i686-pc-cygwin/5.0.0/include -isystem /usr/local/include
-isystem /usr/lib/gcc/i686-pc-cygwin/5.0.0/include-fixed -isystem /usr/include
-isystem /usr/include/w32api -fomit-frame-pointer -mstackrealign -march=core2
-mfpmath=sse -O2 -g -fno-rtti -fno-exceptions -fno-use-cxa-atexit -Wall
-Wstrict-aliasing -Wwrite-strings -fno-common -pipe -fbuiltin
-fmessage-length=0 -MMD -fomit-frame-pointer -fmerge-constants -ftracer -c -o
fhandler_socket.o ../../.././winsup/cygwin/fhandler_socket.cc -save-temps -v


g++: warning: -pipe ignored because -save-temps specified
Using built-in specs.
COLLECT_GCC=g++
Target: i686-pc-cygwin
Configured with: ./configure --config-cache --prefix=/usr
--disable-win32-registry --enable-threads=win32
--enable-languages=c,c++,lto,fortran --with-win32-nlsapi=unicode
--disable-bootstrap --enable-shared --disable-sjlj-exceptions --enable-gomp
--enable-cloog-backend=isl LTLDFLAGS=-no-undefined
lt_cv_deplibs_check_method=pass_all
Thread model: win32
gcc version 5.0.0 20141022 (experimental) (GCC)

COLLECT_GCC_OPTIONS='-L/tmp/winsup/i686-pc-cygwin/winsup/cygwin' '-isystem'
'/tmp/winsup/winsup/cygwin/include' '-B' '/tmp/winsup/i686-pc-cygwin/newlib/'
'-isystem' '/tmp/winsup/i686-pc-cygwin/newlib/targ-include' '-isystem'
'/tmp/winsup/newlib/libc/include' '-nostdinc' '-I' '.' '-I'
'../../.././winsup/cygwin' '-isystem' '/tmp/winsup/winsup/cygwin/include'
'-isystem' '/tmp/winsup/i686-pc-cygwin/newlib/targ-include' '-isystem'
'/tmp/winsup/newlib/libc/include' '-isystem'
'/tmp/winsup/winsup/cygwin/include' '-isystem'
'/tmp/winsup/i686-pc-cygwin/newlib/targ-include' '-isystem'
'/tmp/winsup/newlib/libc/include' '-isystem' '/usr/include/c++/5.0.0'
'-isystem' '/usr/include/c++/5.0.0/i686-pc-cygwin' '-isystem'
'/usr/include/c++/5.0.0/backward' '-isystem'
'/usr/lib/gcc/i686-pc-cygwin/5.0.0/include' '-isystem' '/usr/local/include'
'-isystem' '/usr/lib/gcc/i686-pc-cygwin/5.0.0/include-fixed' '-isystem'
'/usr/include' '-isystem' '/usr/include/w32api' '-mstackrealign' '-march=core2'
'-mfpmath=sse' '-O2' '-g' '-fno-rtti' '-fno-exceptions' '-fno-use-cxa-atexit'
'-Wall' '-Wstrict-aliasing' '-Wwrite-strings' '-fno-common' '-pipe' '-fbuiltin'
'-fmessage-length=0' '-MMD' '-fomit-frame-pointer' '-fmerge-constants'
'-ftracer' '-c' '-o' 'fhandler_socket.o' '-save-temps' '-v' '-shared-libgcc'
 /usr/libexec/gcc/i686-pc-cygwin/5.0.0/cc1plus.exe -E -quiet -nostdinc -v -I .
-I ../../.././winsup/cygwin -MMD fhandler_socket.d -MQ fhandler_socket.o -Dunix
-isystem /tmp/winsup/winsup/cygwin/include -isystem
/tmp/winsup/i686-pc-cygwin/newlib/targ-include -isystem
/tmp/winsup/newlib/libc/include -isystem /tmp/winsup/winsup/cygwin/include
-isystem /tmp/winsup/i686-pc-cygwin/newlib/targ-include -isystem
/tmp/winsup/newlib/libc/include -isystem /tmp/winsup/winsup/cygwin/include
-isystem /tmp/winsup/i686-pc-cygwin/newlib/targ-include -isystem
/tmp/winsup/newlib/libc/include -isystem /usr/include/c++/5.0.0 -isystem
/usr/include/c++/5.0.0/i686-pc-cygwin -isystem /usr/include/c++/5.0.0/backwa

[Bug target/63503] [AArch64] A57 executes fused multiply-add poorly in some situations

[wdijkstr at arm dot com]

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

--- Comment #15 from Wilco  ---
(In reply to Evandro Menezes from comment #14)
> Compiling the test-case above with just -O2, I can reproduce the code I
> mentioned initially and easily measure the cycle count to run it on target
> using perf.
> 
> The binary created by GCC runs in about 447000 user cycles and the one
> created by LLVM, in about 499000 user cycles.  IOW, fused multiply-add is a
> win on A57.
> 
> Looking further why Geekbench's {D,S}GEMM performs worse with GCC than with
> LLVM, both using "-Ofast", GCC fails to vectorize the loop in
> "gemm_block_kernel", while LLVM does.
>   
> I should've done a more detailed analysis in this issue before submitting
> this bug, sorry.

Using -Ofast is not any different from -O3 -ffast-math when compiling
non-Fortran code. As comment 10 shows, both loops are vectorized, however LLVM
unrolls twice and uses multiple accumulators while GCC doesn't.

I still don't see what this has to do with A57. You should open a generic bug
about GCC not applying basic loop optimizations with -O3 (in fact limited
unrolling is useful even for -O2).

[Bug c++/63619] warning: deleting ‘void*’ is undefined has no -W flag

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
The simplest fix would be:

--- a/gcc/cp/decl2.c
+++ b/gcc/cp/decl2.c
@@ -478,7 +478,7 @@ delete_sanity (tree exp, tree size, bool doing_vec, int
use_global_delete,
   /* Deleting ptr to void is undefined behavior [expr.delete/3].  */
   if (VOID_TYPE_P (TREE_TYPE (type)))
 {
-  warning (0, "deleting %qT is undefined", type);
+  warning (OPT_Wdelete_incomplete, "deleting %qT is undefined", type);
   doing_vec = 0;
 }

Although it's possible someone would want deleting void to be an error but not
deleting an incomplete type (because it's only undefined to delete an
incomplete type if it has a non-trivial destructor or a custom deallocation
function).

[Bug c++/63619] warning: deleting ‘void*’ is undefined has no -W flag

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-10-22
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
Yes, this is a very good candidate for wanting a -Werror=xxx option

[Bug tree-optimization/61502] == comparison on "one-past" pointer gives wrong result

[joseph at codesourcery dot com]

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

--- Comment #13 from joseph at codesourcery dot com  ---
On Wed, 22 Oct 2014, Keith.S.Thompson at gmail dot com wrote:

> Do you believe that the authors of the standard meant it the way you do?

The "authors of the standard" are an amorphous group over 30 years and I 
don't think a single intent can meaningfully be assigned to them.

In recent years, the general position has included:

* C is a high-level language supporting a wide range of implementations, 
not just ones with a conventional linear address space and otherwise 
conventional direct mappings to machine operations;

* edge cases should generally be resolved in the way that is convenient 
for optimization rather than the way that is simplest to specify.

For the latter, see for example the discussion in the Parma minutes of 
instability of uninitialized variables with automatic storage duration.  
That is, if you have

  unsigned char a; // uninitialized, inside a function
  unsigned char b = a;
  unsigned char c = b;

then even if there isn't undefined behavior, there is no requirement 
(given no further assignments to b or c) for b == c, or for the value of b 
== c to stay unchanged, or for the values of b and c to remain unchanged.

(As another example, C11 chose to make INT_MIN % -1 explicitly undefined 
for implementation convenience, even though users might think the value is 
obviously 0.)

[Bug tree-optimization/61502] == comparison on "one-past" pointer gives wrong result

[harald at gigawatt dot nl]

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

--- Comment #12 from Harald van Dijk  ---
(In reply to Richard Biener from comment #11)
> I can't reproduce your findings with any of the specified GCC version nor
> with any other I tried (I tried on x86_64-linux and x86_64-linux with -m32).
> The test program always prints "x = 2, y = 2" as expected.

The wrong code should be visible by inspecting the generated assembly, but it
only actually fails at run-time if y directly follows x in memory. It did for
me back when I commented, but it no longer does. Here is a version that should
fail more reliably, by having only x and y as global variables, and by covering
both the case where y immediately follows x and the case where x immediately
follows y:

#include 
#include 

int x, y;

int main()
{
  int *volatile v;
  int *p;

  v = &y;
  p = v;
  x = 2, y = 1;
  if (p == &x + 1)
*p = 2;
  else
y = 2;
  printf ("x = %d, y = %d\n", x, y);

  v = &x;
  p = v;
  x = 2, y = 1;
  if (p == &y + 1)
*p = 1;
  else
x = 1;
  printf ("x = %d, y = %d\n", x, y);

  return 0;
}

The only correct output is "x = 2, y = 2" followed by "x = 1, y = 1". On my
main system, I get "x = 2, y = 1" followed by "x = 1, y = 1". On another, I get
"x = 2, y = 2" followed by "x = 2, y = 1".

[Bug target/63503] [AArch64] A57 executes fused multiply-add poorly in some situations

[e.menezes at samsung dot com]

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

--- Comment #14 from Evandro Menezes  ---
Compiling the test-case above with just -O2, I can reproduce the code I
mentioned initially and easily measure the cycle count to run it on target
using perf.

The binary created by GCC runs in about 447000 user cycles and the one created
by LLVM, in about 499000 user cycles.  IOW, fused multiply-add is a win on A57.

Looking further why Geekbench's {D,S}GEMM performs worse with GCC than with
LLVM, both using "-Ofast", GCC fails to vectorize the loop in
"gemm_block_kernel", while LLVM does.

I should've done a more detailed analysis in this issue before submitting this
bug, sorry.

[Bug rtl-optimization/63620] RELOAD lost SET_GOT dependency on Darwin

[evstupac at gmail dot com]

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

--- Comment #1 from Stupachenko Evgeny  ---
The issue reproduced only if patch from PR63618 is applied.

[Bug bootstrap/63574] [5 Regression] ICE building libjava (segfault) on arm-linux-gnueabihf

[jiwang at gcc dot gnu.org]

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

--- Comment #3 from Jiong Wang  ---
finally, reproduced on latest gcc revision 216547 on chrome book native build

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@216547

./cc1plus -O2 natUnsafe.ii

Performing interprocedural optimizations
 <*free_lang_data>   
  
Program received signal SIGSEGV, Segmentation fault.
0x00f4f558 in ipa_icf_gimple::func_checker::compatible_types_p (t1=0x0, t2=0x0,
compare_polymorphic=true, first_argument=false) at
../../gcc/gcc/ipa-icf-gimple.c:172
172  if (TREE_CODE (t1) != TREE_CODE (t2))
(gdb) bt
#0  0x00f4f558 in ipa_icf_gimple::func_checker::compatible_types_p (t1=0x0,
t2=0x0, compare_polymorphic=true, first_argument=false) at
../../gcc/gcc/ipa-icf-gimple.c:172
#1  0x00f4f7b0 in ipa_icf_gimple::func_checker::compare_operand
(this=0x1526590, t1=0xb67bf4d0, t2=0xb67bf1b8) at
../../gcc/gcc/ipa-icf-gimple.c:220
#2  0x00f512aa in ipa_icf_gimple::func_checker::compare_tree_ssa_label
(this=0x1526590, t1=0xb67bf4d0, t2=0xb67bf1b8) at
../../gcc/gcc/ipa-icf-gimple.c:737
#3  0x00f51374 in ipa_icf_gimple::func_checker::compare_gimple_label
(this=0x1526590, g1=0xb67c0780, g2=0xb67c00f0) at
../../gcc/gcc/ipa-icf-gimple.c:755
#4  0x00f50f18 in ipa_icf_gimple::func_checker::compare_bb (this=0x1526590,
bb1=0x1518ee0, bb2=0x1524560) at ../../gcc/gcc/ipa-icf-gimple.c:604
#5  0x00f4569a in ipa_icf::sem_function::equals_private (this=0x1518db8,
item=0x1524438, ignored_nodes=...) at ../../gcc/gcc/ipa-icf.c:455
#6  0x00f45090 in ipa_icf::sem_function::equals (this=0x1518db8,
item=0x1524438, ignored_nodes=...) at ../../gcc/gcc/ipa-icf.c:355
#7  0x00f48a6a in ipa_icf::sem_item_optimizer::subdivide_classes_by_equality
(this=0x1516a90, in_wpa=false) at ../../gcc/gcc/ipa-icf.c:1771
#8  0x00f4834e in ipa_icf::sem_item_optimizer::execute (this=0x1516a90) at
../../gcc/gcc/ipa-icf.c:1590
#9  0x00f4a1da in ipa_icf::ipa_icf_driver () at ../../gcc/gcc/ipa-icf.c:2319
#10 0x00f4a6ca in ipa_icf::pass_ipa_icf::execute (this=0x14e24e0) at
../../gcc/gcc/ipa-icf.c:2366
#11 0x0086f32e in execute_one_pass (pass=0x14e24e0) at
../../gcc/gcc/passes.c:2156
#12 0x0086ff56 in execute_ipa_pass_list (pass=0x14e24e0) at
../../gcc/gcc/passes.c:2550
#13 0x00570d4a in ipa_passes () at ../../gcc/gcc/cgraphunit.c:2057
#14 0x00570fc0 in symbol_table::compile (this=0xb6c4c000) at
../../gcc/gcc/cgraphunit.c:2137
#15 0x005712b2 in symbol_table::finalize_compilation_unit (this=0xb6c4c000) at
../../gcc/gcc/cgraphunit.c:2290
#16 0x0031bd4e in cp_write_global_declarations () at
../../gcc/gcc/cp/decl2.c:4666
#17 0x00948aee in compile_file () at ../../gcc/gcc/toplev.c:574
#18 0x0094b2e0 in do_compile () at ../../gcc/gcc/toplev.c:1981
#19 0x0094b51a in toplev::main (this=0xbefffb54, argc=3, argv=0xbefffcb4) at
../../gcc/gcc/toplev.c:2078
#20 0x00fb1732 in main (argc=3, argv=0xbefffcb4) at ../../gcc/gcc/main.c:38
(gdb)

[Bug rtl-optimization/63620] New: RELOAD lost SET_GOT dependency on Darwin

[evstupac at gmail dot com]

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

Bug ID: 63620
   Summary: RELOAD lost SET_GOT dependency on Darwin
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: evstupac at gmail dot com
CC: law at redhat dot com, vmakarov at redhat dot com
Target: Darwin

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

For the attached tests even with fix in pr63618 SET_GOT is deleted on Darwin.

For some reason there are no dependency between:

(RELOAD PASS)

(insn/f 43 6 2 2 (parallel [ 
(set (reg:SI 0 ax [87])
(unspec:SI [
(const_int 0 [0]) 
] UNSPEC_SET_GOT)) 
(clobber (reg:CC 17 flags)) 
]) 679 {set_got} 
 (expr_list:REG_EQUIV (unspec:SI [ 
(const_int 0 [0]) 
] UNSPEC_SET_GOT) 
(expr_list:REG_CFA_FLUSH_QUEUE (nil)
(nil 

and

(insn 46 17 47 3 (set (reg:SI 0 ax [93]) 
(plus:SI (reg:SI 0 ax [87]) 
(const:SI (unspec:SI [ 
(symbol_ref/u:SI ("*LC0") [flags 0x2]) 
] UNSPEC_MACHOPIC_OFFSET elim_setgot_darwin.c:20 213
{*leasi}
 (expr_list:REG_EQUAL (symbol_ref/u:SI ("*LC0") [flags 0x2])
(nil))) 

And at 231r.ce3 SET_GOT is deleted which lead to incorrect code.

The issue reproduced on Darwin only, however it can be reproduced at cross
build configured as:
../configure --target=x86_64-apple-darwin11 --prefix=...
--enable-languages=c,c++ --enable-bootstrap=no

To reproduce we need only cc1:

gcc/cc1 elim_setgot_darwin.c -m32 -fPIE -O2 -msse4.2 -mtune=corei7 -fno-inline
-fdump-rtl-all

[Bug c++/63619] New: warning: deleting ‘void*’ is undefined has no -W flag

[fuscated at gmail dot com]

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

Bug ID: 63619
   Summary: warning: deleting ‘void*’ is undefined has no -W flag
   Product: gcc
   Version: 4.9.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fuscated at gmail dot com

Save this snippet in delete_void.cpp
int main() {
void *a=new char[100];
delete [] a;
return 0;
}

$ g++ -fdiagnostics-show-option delete_void.cpp 
delete_void.cpp: In function ‘int main()’:
delete_void.cpp:3:12: warning: deleting ‘void*’ is undefined
  delete [] a;
^
The compiler poroduces a warning, but doesn't allow the user to turn it into
error and thus such bugs cannot be detected at compile time.

[Bug rtl-optimization/63618] CSE at IRA pass delete SET_GOT which is used later

[evstupac at gmail dot com]

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

--- Comment #2 from Stupachenko Evgeny  ---
Created attachment 33781
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33781&action=edit
leave SET_GOT while pic_offset_table_rtx is pseudo

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

[carrot at gcc dot gnu.org]

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

--- Comment #4 from carrot at gcc dot gnu.org ---
Author: carrot
Date: Wed Oct 22 15:56:59 2014
New Revision: 216562

URL: https://gcc.gnu.org/viewcvs?rev=216562&root=gcc&view=rev
Log:
PR tree-optimization/63530
tree-vect-data-refs.c (vect_create_addr_base_for_vector_ref): Set
pointer alignment according to DR_MISALIGNMENT.
gcc.dg/vect/pr63530.c: New testcase.


Added:
trunk/gcc/testsuite/gcc.dg/vect/pr63530.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vect-data-refs.c

[Bug other/63613] dejagnu.h needs to be fix included

[pinskia at gcc dot gnu.org]

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

--- Comment #9 from Andrew Pinski  ---
(In reply to dmalcolm from comment #7)
> (In reply to Andrew Pinski from comment #6)
> > Let's keep this open for a fix includes solution.
> 
> Does anything in gcc's bootstrap or testsuite actually use dejagnu.h? (other
> than my jit.exp on the jit branch, and I've fixed that now by adding
> -fgnu89-inline)

Nothing I know of but that does not mean we want to make dejagnu.h work for C11
even without -fgnu89-inline.

[Bug other/63613] dejagnu.h needs to be fix included

[dmalcolm at gcc dot gnu.org]

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

--- Comment #8 from dmalcolm at gcc dot gnu.org ---
(In reply to dmalcolm from comment #7)
[...]
>   (B) GCC release notes, for some kind of 5.0 porting guide (i.e.
>   "what does an end-user need to know about the gnu11 change?")

...and I see that Marek just posted just such a thing :)
https://gcc.gnu.org/ml/gcc-patches/2014-10/msg02268.html

[Bug other/63613] dejagnu.h needs to be fix included

[dmalcolm at gcc dot gnu.org]

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

--- Comment #7 from dmalcolm at gcc dot gnu.org ---
(In reply to Andrew Pinski from comment #6)
> Let's keep this open for a fix includes solution.

Does anything in gcc's bootstrap or testsuite actually use dejagnu.h? (other
than my jit.exp on the jit branch, and I've fixed that now by adding
-fgnu89-inline)

It seems to be that this is more an issue for both:

  (A) DejaGnu upstream (where I've reported it), and

  (B) GCC release notes, for some kind of 5.0 porting guide (i.e.
  "what does an end-user need to know about the gnu11 change?")

[Bug c++/63609] incompatibility with C++11 standard on 14.5.6.2 Partial ordering of function templates

[dccmmccd1 at gmail dot com]

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

--- Comment #2 from dccmmccd1 at gmail dot com ---
(In reply to Jonathan Wakely from comment #1)
> Please don't set severity=blocker just because you think it's quite
> important to you. We're not going to block a GCC release for this issue,
> especially since it's been present in several releases already!

As this is the first time I report a gcc bug, I didn't really understand the
meaning of severity here. I was under the impression it meant something very
different. After a bit of investigation I know see that normal is much more
appropriate here.

[Bug other/63613] Regression: Unable to link .c file using API (inline functions not appearing)

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|RESOLVED|NEW
   Last reconfirmed||2014-10-22
  Component|c   |other
 Resolution|INVALID |---
 Ever confirmed|0   |1

--- Comment #6 from Andrew Pinski  ---
Let's keep this open for a fix includes solution.

[Bug rtl-optimization/63618] CSE at IRA pass delete SET_GOT which is used later

[evstupac at gmail dot com]

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

--- Comment #1 from Stupachenko Evgeny  ---
Created attachment 33780
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33780&action=edit
Reproducer

[Bug rtl-optimization/63618] New: CSE at IRA pass delete SET_GOT which is used later

[evstupac at gmail dot com]

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

Bug ID: 63618
   Summary: CSE at IRA pass delete SET_GOT which is used later
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: evstupac at gmail dot com

Test failed on execution compiled with:
gcc elim_set_got.c -fPIE -m32 -msse4.2 -O2 -fno-inline -mtune=corei7
./a.out
Segmentation fault (core dumped)

That occurs because CSE delete SET_GOT at IRA as it has no uses.
However the instruction:

(insn 20 17 21 3 (set (mem:TF (pre_dec:SI (reg/f:SI 7 sp)) [2  S16 A128])
(const_double:TF 1.0e+9 [0x0.ee6b28p+30])) elim_setgot.c:26 121
{*pushtf} 
 (expr_list:REG_ARGS_SIZE (const_int 16 [0x10]) 
(nil))) 

have hidden use of GOT register as it is split into:

(insn 45 47 46 3 (set (reg:SI 0 ax [92]) 
(plus:SI (reg:SI 0 ax [87]) 
(const:SI (unspec:SI [ 
(symbol_ref/u:SI ("*.LC2") [flags 0x2]) 
] UNSPEC_GOTOFF elim_setgot.c:26 213 {*leasi} 
 (expr_list:REG_EQUAL (symbol_ref/u:SI ("*.LC2") [flags 0x2]) 
(nil))) 
(insn 46 45 20 3 (set (reg:TF 23 xmm2 [93]) 
(mem/u/c:TF (reg:SI 0 ax [92]) [2  S16 A128])) elim_setgot.c:26 126
{*movtf_internal} 
 (nil))

[Bug libstdc++/63614] With gcc-4.8.3 and -stdgnu++0x call to std::this_thread::get_id() creates SIGSEV

[dyle at dyle dot org]

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

--- Comment #3 from dyle at dyle dot org ---
(In reply to Jonathan Wakely from comment #2)
> (In reply to dyle from comment #0)
> > Is this a gcc bug? Is it possible that std::this_thread::get_id() SIGSEVs?
> 
> Yes it's possible if you don't use -pthread to link to libpthread.

Ok. I'll attach it then.

> > (Yes, there's a race condition on std::cout. But this is not the point.) Is
> > there a drawback by creating a threads that way and could there be any
> > correlation to my sigsev?
> 
> No, it's unlikely.
> 
> You can rule that out by using std::thread(&A::foo, this)

Good, I'll use this pattern then. I do not sense any pros/cons compared to my
previous lambda approach.


> (In reply to dyle from comment #1)
> > Huh. It ain't std::this_thread::get_id(), it is the assignment! 
> > Because this 
> > 
> > auto nThread = 1;
> > 
> > as first statement in the thread crashes also. o.O
> 
> Then that's unlikely to be a GCC bug, are you running out of stack, or
> scribbling on the stack from another function?

Not that I'm aware of. I always try to be extra cautious and super paranoid,
hence my compiler flags: -Wall -Wextra -Werror -pedantic. But these ain't no
silver bullets either.

> Have you tried using valgrind, or asan, or -fstack-protector ?

Good idea. I'll go for these tomorrow.

Thx.

[Bug libstdc++/63614] With gcc-4.8.3 and -stdgnu++0x call to std::this_thread::get_id() creates SIGSEV

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
(In reply to dyle from comment #0)
> Is this a gcc bug? Is it possible that std::this_thread::get_id() SIGSEVs?

Yes it's possible if you don't use -pthread to link to libpthread.

> (Yes, there's a race condition on std::cout. But this is not the point.) Is
> there a drawback by creating a threads that way and could there be any
> correlation to my sigsev?

No, it's unlikely.

You can rule that out by using std::thread(&A::foo, this)

(In reply to dyle from comment #1)
> Huh. It ain't std::this_thread::get_id(), it is the assignment! 
> Because this 
> 
> auto nThread = 1;
> 
> as first statement in the thread crashes also. o.O

Then that's unlikely to be a GCC bug, are you running out of stack, or
scribbling on the stack from another function?

Have you tried using valgrind, or asan, or -fstack-protector ?

[Bug target/63600] [5 Regression] ice in ix86_expand_sse2_abs

[kyukhin at gcc dot gnu.org]

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

--- Comment #4 from Kirill Yukhin  ---
(In reply to Jakub Jelinek from comment #3)
> I would have expected VI instead of IV in the iterator name, but I never
> understood the rules for i?86 iterator names.
> And, you want the testcase in the testsuite too.

Agh, right! Thanks. I'll post patch w/ renamed iterator and
a testcase (from this bug)

[Bug libstdc++/63617] Crash in libstdc++ on AIX.

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
GCC 4.6 is no longer supported, so unless you can reproduce this with a current
release noone is going to investigate.

I'm assuming you've configured GCC to use the bitmap_allocator as the default
C++ allocator, so one likely cause is that an exception was thrown due to
failure to allocate memory.

In any case, please provide the information requested by
https://gcc.gnu.org/bugs/

[Bug target/63600] [5 Regression] ice in ix86_expand_sse2_abs

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
I would have expected VI instead of IV in the iterator name, but I never
understood the rules for i?86 iterator names.
And, you want the testcase in the testsuite too.

[Bug target/63615] [5 Regression] FAIL: gcc.target/i386/addr-sel-1.c

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||amodra at gcc dot gnu.org,
   ||jakub at gcc dot gnu.org
   Target Milestone|--- |5.0
Summary|[i686][5 Regression] FAIL:  |[5 Regression] FAIL:
   |gcc.target/i386/addr-sel-1. |gcc.target/i386/addr-sel-1.
   |c   |c

[Bug c/63326] whether a #pragma is a statement depends on the type of pragma

[manu at gcc dot gnu.org]

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

--- Comment #12 from Manuel López-Ibáñez  ---
(In reply to steveren from comment #11)
> So assuming it's not actually beyond somebody completely unfamiliar with the
> innards of gcc, what would be the response to a patch which changed #pragma
> message from 'statement' to 'not-a-statement'?

I think that even if not a definitive solution, it would be a positive step
towards understanding what would it take to change the behavior for specific
#pragmas (since we cannot change how OMP #pragmas behave).

[Bug c++/63609] incompatibility with C++11 standard on 14.5.6.2 Partial ordering of function templates

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-10-22
 Ever confirmed|0   |1
   Severity|blocker |normal

--- Comment #1 from Jonathan Wakely  ---
Please don't set severity=blocker just because you think it's quite important
to you. We're not going to block a GCC release for this issue, especially since
it's been present in several releases already!

[Bug c/63326] whether a #pragma is a statement depends on the type of pragma

[q....@rsn-tech.co.uk]

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

--- Comment #11 from steveren  ---
(In reply to Manuel López-Ibáñez from comment #10)
> (In reply to steveren from comment #6)
> > Seems the consensus is that it's not contrary to Standard, but it's agreed
> > to be confusing and undesirable by everyone except the gcc maintainers :-)
> 
> Not sure how you reached such conclusion, but it clearly misinterprets
> reality, otherwise this PR would be closed as INVALID already.

Ok, my apologies. However, this bug /was/ closed as invalid before being
reopened, and my own report was closed as invalid before being marked as a dupe
of this one, so it's not entirely clear that there's a general feeling of a
real problem that needs to be addressed.

> I'm pretty sure if you submitted a patch making the behavior of all pragmas 
> consistent with comment #9,

But I don't /want/ behaviour consistent with #9 (ie, warning that the usage is
invalid), I want the usage to be valid /and/ sensible - ie, the same as other
compilers. I suspect that's more difficult...

Don't get me wrong - I'm not whingeing that other people should solve my
problems for me without being prepared to get involved myself, but if this is
WAD in the eyes of the majority, then I'll live with it sooner than create my
own fork!

So assuming it's not actually beyond somebody completely unfamiliar with the
innards of gcc, what would be the response to a patch which changed #pragma
message from 'statement' to 'not-a-statement'?

[Bug c/63613] Regression: Unable to link .c file using API (inline functions not appearing)

[dmalcolm at gcc dot gnu.org]

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

--- Comment #5 from dmalcolm at gcc dot gnu.org ---
FWIW I've reported this on the DejaGnu mailing list here:
http://lists.gnu.org/archive/html/dejagnu/2014-10/msg00011.html

[Bug libstdc++/63617] New: Crash in libstdc++ on AIX.

[adivilceanu at yahoo dot com]

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

Bug ID: 63617
   Summary: Crash in libstdc++ on AIX.
   Product: gcc
   Version: 4.6.3
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: adivilceanu at yahoo dot com

Hello,

We have a program "myapp" build with gcc 4.6.3 on AIX 6.1 Tl05.

At runtime the program crashed once very weird with the following stack:

pth_signal.pthread_kill(??, ??) at 0xd053c8d4
pth_signal._p_raise(??) at 0xd053bd64
raise.raise(??) at 0xd01209a0
abort.abort() at 0xd017c164
unnamed block in vterminate._ZN9__gnu_cxx27__verbose_terminate_handlerEv(),
line 95 in "vterminate.cc"
vterminate._ZN9__gnu_cxx27__verbose_terminate_handlerEv(), line 95 in
"vterminate.cc"
eh_terminate._ZN10__cxxabiv111__terminateEPFvvE(handler = ??), line 40 in
"eh_terminate.cc"
eh_terminate._ZSt9terminatev(), line 50 in "eh_terminate.cc"
unnamed block in
bitmap_allocator._ZN9__gnu_cxx8__detail13__mini_vectorISt4pairIPNS_16bitmap_allocatorIwE12_Alloc_blockES6_EE6insertEPS7_RKS7_(this
= @0x32d17f78, __pos = ??, __x = ??), line 116 in "bitmap_allocator.cc"
bitmap_allocator._ZN9__gnu_cxx8__detail13__mini_vectorISt4pairIPNS_16bitmap_allocatorIwE12_Alloc_blockES6_EE6insertEPS7_RKS7_(this
= @0x32d17f78, __pos = ??, __x = ??), line 116 in "bitmap_allocator.cc"
thread._ZN6Thread11mainFEPv(??) at 0xd114422c

The "Thread::mainF" is a thread routine that was passed to pthread_create.
We consider our code inside this method clean.

Please advise what kind of system call from our side could have generated this
stack. I mean we do not call directly any "bitmap_allocator".

Our program(myapp) has the following dependencies:
bash-4.2# ldd myapp
myapp needs:
 /usr/lib/threads/libc.a(shr.o)
 /usr/lib/libpthread.a(shr_xpg5.o)
 /usr/mypath/libstdc++.a(libstdc++.so.6)
 /usr/mypath/libgcc_s.a(shr.o)
 /usr/lib/libiconv.a(shr4.o)
 /usr/lib/libpthread.a(shr_comm.o)
 /usr/lib/libqb.a(shr.o)
 /unix
 /usr/lib/libcrypt.a(shr.o)
 /usr/lib/libpthreads.a(shr_comm.o)
 /usr/lib/libpthreads_compat.a(shr.o)
 /usr/lib/libz.a(libz.so.1)
 /usr/lib/libpthreads.a(shr.o)
The libstdc++.a and libgcc_s.a are taken from the gcc 4.6.3 compiler.

Thank you !

[Bug libstdc++/63614] With gcc-4.8.3 and -stdgnu++0x call to std::this_thread::get_id() creates SIGSEV

[dyle at dyle dot org]

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

dyle at dyle dot org changed:

   What|Removed |Added

   Severity|critical|minor

--- Comment #1 from dyle at dyle dot org ---
Huh. It ain't std::this_thread::get_id(), it is the assignment! 
Because this 

auto nThread = 1;

as first statement in the thread crashes also. o.O


$ gdb bin/modules/qkd-hardware-pickup/qkd-hardware-pickup core.1327 
GNU gdb (Gentoo 7.8 vanilla) 7.8
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-pc-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from
bin/modules/qkd-hardware-pickup/qkd-hardware-pickup...done.

warning: core file may not match specified executable file.
[New LWP 1339]
[New LWP 1327]
[New LWP 1335]
[New LWP 1333]
[New LWP 1338]
[New LWP 1331]

warning: Could not load shared library symbols for linux-vdso.so.1.
Do you need "set solib-search-path" or "set sysroot"?
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Core was generated by `/home/dyle/doc/src/ait/qkd/build/bin/qkd-hardware-pickup
--debug-core-presiftin'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  qkd_hardware_pickup_alice::presifter (this=0x1405bc0) at
/home/dyle/doc/src/ait/qkd/bin/modules/qkd-hardware-pickup/qkd-hardware-pickup-alice.cpp:1199
1199auto nThreadId = 1;
(gdb) bt
#0  qkd_hardware_pickup_alice::presifter (this=0x1405bc0) at
/home/dyle/doc/src/ait/qkd/bin/modules/qkd-hardware-pickup/qkd-hardware-pickup-alice.cpp:1199
#1  0x7f63182425e0 in std::(anonymous
namespace)::execute_native_thread_routine (__p=) at
/var/tmp/portage/sys-devel/gcc-4.8.3/work/gcc-4.8.3/libstdc++-v3/src/c++11/thread.cc:84
#2  0x7f631849d073 in start_thread (arg=0x7f630c6f8700) at
pthread_create.c:309
#3  0x7f63179c74ad in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:111
(gdb) info frame
Stack level 0, frame at 0x7f630c6f7ec0:
 rip = 0x43138b in qkd_hardware_pickup_alice::presifter
(/home/dyle/doc/src/ait/qkd/bin/modules/qkd-hardware-pickup/qkd-hardware-pickup-alice.cpp:1199);
saved rip = 0x7f63182425e0
 called by frame at 0x7f630c6f7ee0
 source language c++.
 Arglist at 0x7f630b5ccef8, args: this=0x1405bc0
 Locals at 0x7f630b5ccef8, Previous frame's sp is 0x7f630c6f7ec0
 Saved registers:
  rbx at 0x7f630c6f7e88, rbp at 0x7f630c6f7e90, r12 at 0x7f630c6f7e98, r13 at
0x7f630c6f7ea0, r14 at 0x7f630c6f7ea8, r15 at 0x7f630c6f7eb0, rip at
0x7f630c6f7eb8
(gdb) list
/home/dyle/doc/src/ait/qkd/bin/modules/qkd-hardware-pickup/qkd-hardware-pickup-alice.cpp:1199
1194
1195// this line SIGSEVs for unknown reasons:
1196//  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63614
1197//
1198// std::thread::id nThreadId = std::this_thread::get_id();
1199auto nThreadId = 1;
1200
1201// this method is run at start by PRESIFT_THREADS concurrent
threads
1202if (debug_core_presifting()) {
1203qkd::utility::debug(true) << 

So: Sorry for the noise.

But still I do not know what is happening ...

[Bug target/63600] [5 Regression] ice in ix86_expand_sse2_abs

[kyukhin at gcc dot gnu.org]

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

--- Comment #2 from Kirill Yukhin  ---
Created attachment 33779
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33779&action=edit
Patch is under testing now.

[Bug rtl-optimization/63616] PRE failure

[ubizjak at gmail dot com]

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

--- Comment #1 from Uroš Bizjak  ---
Created attachment 33778
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33778&action=edit
_.178r.cprop1 and _.179r.pre RTL dumps

[Bug rtl-optimization/63616] New: PRE failure

[ubizjak at gmail dot com]

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

Bug ID: 63616
   Summary: PRE failure
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ubizjak at gmail dot com
Target: alpha-linux-gnu

Currently text/template/parse testcase from libgo fails on alpha-linux-gnu due
to failure of PRE pass.

Before PRE pass, we have:

  409: r229:DI=[FP:DI+0x60]
  410: pc={(r229:DI==0)?L437:pc}
  REG_DEAD r229:DI
  REG_BR_PROB 1500
  ...
  427: L427:   [***] <--- jump target
  428: NOTE_INSN_BASIC_BLOCK 33
  430: r236:SI=[r70:DI+0x10]   <--- load from r70+0x10
  431: r235:QI#0=zero_extract(r236:SI#0,0x8,0)
  REG_DEAD r236:SI
  432: r95:DI=zero_extend(r235:QI)
  REG_DEAD r235:QI
  433: pc={(r95:DI!=0)?L458:pc}
  REG_DEAD r95:DI
  REG_BR_PROB 5000
  437: L437:
  438: NOTE_INSN_BASIC_BLOCK 34
  439: r237:QI=0x1
  440: r238:SI=[r70:DI+0x10]   <--- load from r70+0x10
  441: r238:SI#0=r238:SI#0&0xff00
  443: r239:SI#0=r238:SI#0|0x1
  REG_DEAD r238:SI
  444: [r70:DI+0x10]=r239:SI   <--- store to r70+0x10
  REG_DEAD r239:SI
  445: [r70:DI+0x18]=r94:DI
  446: pc={(r94:DI!=0)?L427:pc}jump back ---> [***]
  REG_DEAD r94:DI
  REG_BR_PROB 5000
  ...

PRE pass eliminates load to:

  ...
  409: r229:DI=[FP:DI+0x60]
  410: pc={(r229:DI==0)?L437:pc}
  REG_DEAD r229:DI
  REG_BR_PROB 1500
  708: NOTE_INSN_BASIC_BLOCK 30
  699: r307:SI=[r70:DI+0x10]   <--- load to temp from r70+0x10
  ...
  427: L427:   [***] <--- jump target
  428: NOTE_INSN_BASIC_BLOCK 32
  698: r236:SI=r307:SI <--- move from temp
  REG_EQUAL [r70:DI+0x10]
  431: r235:QI#0=zero_extract(r236:SI#0,0x8,0)
  REG_DEAD r236:SI
  432: r95:DI=zero_extend(r235:QI)
  REG_DEAD r235:QI
  433: pc={(r95:DI!=0)?L458:pc}
  REG_DEAD r95:DI
  REG_BR_PROB 5000
  437: L437:
  438: NOTE_INSN_BASIC_BLOCK 33
  439: r237:QI=0x1
  440: r307:SI=[r70:DI+0x10]   <--- load to temp from r70+0x10
  707: r238:SI=r307:SI <--- move from temp
  441: r238:SI#0=r238:SI#0&0xff00
  443: r239:SI#0=r238:SI#0|0x1
  REG_DEAD r238:SI
  444: [r70:DI+0x10]=r239:SI   <--- store to r70+0x10
  REG_DEAD r239:SI
  445: [r70:DI+0x18]=r94:DI
  446: pc={(r94:DI!=0)?L427:pc}jump back ---> [***]
  REG_DEAD r94:DI
  REG_BR_PROB 5000
  ...

As shown above, PRE inserted BB 30, but when progam jumps back, the value is
moved from temporary, not from the memory. It looks that when a new BB is
inserted, the compiler forgot to update the jumpback label.

I will attach complete cprop1 and pre dumps. I didn't find any kind of
"preprocessed" go file with -fsave-temps to attach.

[Bug c/63326] whether a #pragma is a statement depends on the type of pragma

[manu at gcc dot gnu.org]

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

--- Comment #10 from Manuel López-Ibáñez  ---
(In reply to steveren from comment #6)
> Seems the consensus is that it's not contrary to Standard, but it's agreed
> to be confusing and undesirable by everyone except the gcc maintainers :-)

Not sure how you reached such conclusion, but it clearly misinterprets reality,
otherwise this PR would be closed as INVALID already.

I'm pretty sure if you submitted a patch making the behavior of all pragmas
consistent with comment #9, this will be fixed by next week.
(https://gcc.gnu.org/wiki/GettingStarted#Basics:_Contributing_to_GCC_in_10_easy_steps)

> I'll take a lot of persuading that this isn't a reasonable thing to want to
> do. (Flagging the nasty, that is; purists who say you should never /do/
> anything you need to warn people about need not apply :-) )

I'm not sure to which "purists" you are referring but, from my experience, GCC
welcomes warnings that help people to write better code and prevent mistakes as
long as patches are written and tested properly and do not generate too many
hard-to-work-around false positives. New warnings are added in every release.
Thus, I would encourage you to submit a patch and see for yourself.

[Bug target/63615] New: [i686][5 Regression] FAIL: gcc.target/i386/addr-sel-1.c

[izamyatin at gmail dot com]

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

Bug ID: 63615
   Summary: [i686][5 Regression] FAIL:
gcc.target/i386/addr-sel-1.c
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: izamyatin at gmail dot com
Target: i686

There is a new fail for gcc.target/i386/addr-sel-1.c on i686 after r216462

For this test we now have in asm file

movl4(%esp), %eax
leal1(%eax), %edx
movsbl  a(%edx), %ecx
movsbl  b(%edx), %eax
addl%ecx, %eax
ret


instead of earlier

movl4(%esp), %eax
movsbl  a+1(%eax), %ecx
movsbl  b+1(%eax), %eax
addl%ecx, %eax
ret

Seems the change resticts some opts in postreload. Now in .postreload there are 

(insn 6 21 8 2 (parallel [
  (set (reg:SI 1 dx [orig:83 D.1733 ] [83])
  (plus:SI (reg:SI 0 ax [96])
  (const_int 1 [0x1])))
  (clobber (reg:CC 17 flags))
  ]) ../gcc/testsuite/gcc.target/i386/addr-sel-1.c:13 220 {*addsi_1}
   (nil))
(insn 8 6 10 2 (set (reg:SI 2 cx [orig:93 D.1733 ] [93])
  (sign_extend:SI (mem/j:QI (plus:SI (reg:SI 1 dx [orig:83 D.1733 ]
[83])
  (symbol_ref:SI ("a")  )) [0 a
S1 A8]))) ../gcc/testsuite/gcc.target/i386/addr-sel-1.c:13 148 {extendqisi2}
   (nil))

while earlier there were

(insn 6 21 8 2 (parallel [
(set (reg:SI 1 dx [orig:83 D.1733 ] [83])
(plus:SI (reg:SI 0 ax [96])
(const_int 1 [0x1])))
(clobber (reg:CC 17 flags))
]) addr-sel-1-good.c:13 220 {*addsi_1}
 (nil))
(insn 8 6 10 2 (set (reg:SI 2 cx [orig:93 D.1733 ] [93])
(sign_extend:SI (mem/j:QI (plus:SI (reg:SI 0 ax [96])
(const:SI (plus:SI (symbol_ref:SI ("a")  )
(const_int 1 [0x1] [0 a S1 A8])))
addr-sel-1-good.c:13 148 {extendqisi2}
 (nil))

so insn 6 is not needed

[Bug target/63503] [AArch64] A57 executes fused multiply-add poorly in some situations

[wdijkstr at arm dot com]

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

--- Comment #13 from Wilco  ---
(In reply to Andrew Pinski from comment #11)
> (In reply to Wilco from comment #10)
> > The loops shown are not the correct inner loops for those options - with
> > -ffast-math they are vectorized. LLVM unrolls 2x but GCC doesn't. So the
> > question is why GCC doesn't unroll vectorized loops like LLVM?
> 
> Because unrolling is not enabled at -O3.  Try adding -funroll-loops.

Isn't it odd that GCC doesn't even do the most basic unrolling at its maximum
optimization setting? But it does do vectorization?

Note -funroll-loops is not sufficient either, you need
-fvariable-expansion-in-unroller as well for this particular loop which also
isn't enabled at -O3. Plus setting the associated param to 4 or 8.

So GCC is certainly capable of generating quality code for this example, it
just doesn't do so by default - unlike LLVM.

[Bug libstdc++/63614] New: With gcc-4.8.3 and -stdgnu++0x call to std::this_thread::get_id() creates SIGSEV

[dyle at dyle dot org]

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

Bug ID: 63614
   Summary: With gcc-4.8.3 and -stdgnu++0x call to
std::this_thread::get_id() creates SIGSEV
   Product: gcc
   Version: 4.8.3
Status: UNCONFIRMED
  Severity: critical
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dyle at dyle dot org

Things have worked recently until I run into a SIGSEV rigtht in the guts of
std::this_thread::id(). I tried several compiler options but still the program
crashes.

The whole compiler line within a cmake projekt for my sources causing the crash
read:

...
[ 56%] Building CXX object
bin/modules/qkd-hardware-pickup/CMakeFiles/qkd-hardware-pickup.dir/qkd-hardware-pickup-alice.cpp.o
cd /home/dyle/doc/src/ait/qkd/build/bin/modules/qkd-hardware-pickup &&
/usr/bin/c++   -DQT_CORE_LIB -DQT_DBUS_LIB -DQT_GUI_LIB -DQT_NETWORK_LIB
-DQT_NO_DEBUG -DQT_XML_LIB -DVERSION=\"9..2\" -D_BSD_SOURCE -D_GNU_SOURCE
-std=gnu++0x -Werror -Wall -Wextra -pedantic -g -ggdb3 -rdynamic -O3
-I/usr/include/dbus-1.0 -I/usr/lib64/dbus-1.0/include -isystem /usr/include/qt4
-isystem /usr/include/qt4/QtGui -isystem /usr/include/qt4/QtDBus -isystem
/usr/include/qt4/QtXml -isystem /usr/include/qt4/QtNetwork -isystem
/usr/include/qt4/QtCore -I/usr/include/qwt6 -I/home/dyle/doc/src/ait/qkd/build
-I/home/dyle/doc/src/ait/qkd -I/home/dyle/doc/src/ait/qkd/include
-I/home/dyle/doc/src/ait/qkd/build/bin/modules/qkd-hardware-pickup-o
CMakeFiles/qkd-hardware-pickup.dir/qkd-hardware-pickup-alice.cpp.o -c
/home/dyle/doc/src/ait/qkd/bin/modules/qkd-hardware-pickup/qkd-hardware-pickup-alice.cpp
/usr/bin/cmake -E cmake_progress_report
/home/dyle/doc/src/ait/qkd/build/CMakeFiles
...


This is then gdb:


GNU gdb (Gentoo 7.8 vanilla) 7.8
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-pc-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from
bin/modules/qkd-hardware-pickup/qkd-hardware-pickup...done.

warning: core file may not match specified executable file.
[New LWP 27565]
[New LWP 27561]
[New LWP 27564]
[New LWP 27562]
[New LWP 27554]
[New LWP 27560]

warning: Could not load shared library symbols for linux-vdso.so.1.
Do you need "set solib-search-path" or "set sysroot"?
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Core was generated by `/home/dyle/doc/src/ait/qkd/build/bin/qkd-hardware-pickup
--debug-core-presiftin'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  __gthread_self () at
/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/include/g++-v4/x86_64-pc-linux-gnu/bits/gthr-default.h:686
686   return __gthrw_(pthread_self) ();
(gdb) bt
#0  __gthread_self () at
/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/include/g++-v4/x86_64-pc-linux-gnu/bits/gthr-default.h:686
#1  get_id () at
/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/include/g++-v4/thread:252
#2  qkd_hardware_pickup_alice::presifter (this=0x1f1fbc0) at
/home/dyle/doc/src/ait/qkd/bin/modules/qkd-hardware-pickup/qkd-hardware-pickup-alice.cpp:1195
#3  0x7f9f31cdd5e0 in std::(anonymous
namespace)::execute_native_thread_routine (__p=) at
/var/tmp/portage/sys-devel/gcc-4.8.3/work/gcc-4.8.3/libstdc++-v3/src/c++11/thread.cc:84
#4  0x7f9f31f38073 in start_thread (arg=0x7f9f26193700) at
pthread_create.c:309
#5  0x7f9f314624ad in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:111
(gdb) list
/home/dyle/doc/src/ait/qkd/bin/modules/qkd-hardware-pickup/qkd-hardware-pickup-alice.cpp:1195
1190 * 
1191 * here the presift calculation starts
1192 */
1193void qkd_hardware_pickup_alice::presifter() {
1194
1195std::thread::id nThreadId = std::this_thread::get_id();
1196
1197// this method is run at start by PRESIFT_THREADS concurrent
threads
1198if (debug_core_presifting()) {
1199qkd::utility::debug(true) << 

The thread itself is created at line 622, here:

(gdb) list
/home/dyle/doc/src/ait/qkd/bin/modules/qkd-hardware-pickup/qkd-hardware-pickup-alice.cpp:622
617 
618 set_role((unsigned long)qkd::module::module_role::ROLE_ALICE);
619 
620 // launch worker threads
621 d->cPusher = std::thread([this]{ pusher(); });
622 for (int i = 0; i < PRESIFT_THREADS; ++i) d->cPresifter[i] =
std::thread([this]{ pr

[Bug target/63223] [avr] Make jumptables work with -Wl,--section-start,.text=

[gjl at gcc dot gnu.org]

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

--- Comment #12 from Georg-Johann Lay  ---
Author: gjl
Date: Wed Oct 22 10:46:11 2014
New Revision: 216551

URL: https://gcc.gnu.org/viewcvs?rev=216551&root=gcc&view=rev
Log:
PR target/63223
* config/avr/lib1funcs.S (__do_global_dtors): Reverse execution
order to first...last.


Modified:
branches/gcc-4_9-branch/libgcc/ChangeLog
branches/gcc-4_9-branch/libgcc/config/avr/lib1funcs.S

[Bug bootstrap/63574] [5 Regression] ICE building libjava (segfault) on arm-linux-gnueabihf

[jiwang at gcc dot gnu.org]

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

Jiong Wang  changed:

   What|Removed |Added

 CC||jiwang at gcc dot gnu.org

--- Comment #2 from Jiong Wang  ---
I run into this issue with the same crash back trace when building libstdc++
around 19 Oct, but can't reproduce with latest code.

[Bug c++/57248] string parameter to constexpr functions

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

--- Comment #10 from Paolo Carlini  ---
Let's close this then. The diagnostics could be better, but that's another
issue.

[Bug c++/55004] [meta-bug] constexpr issues

[paolo.carlini at oracle dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55004
Bug 55004 depends on bug 57248, which changed state.

Bug 57248 Summary: string parameter to constexpr functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57248

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

[Bug c++/51213] [C++11][DR 1170] Access control checking has to be done under SFINAE conditions

[mizvekov at gmail dot com]

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

--- Comment #22 from Matheus Izvekov  ---
Apologies, it was a problem on my end!
The fault was just clang and gcc having different default binary names on msys,
'a.out' vs 'a.exe', and me using a stale exe when testing gcc...
Sorry!

[Bug c/63612] #pragma breaks if...else

[q....@rsn-tech.co.uk]

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

--- Comment #6 from steveren  ---
(In reply to Dietmar Schindler from comment #5)

> In news:comp.std.c there is a thread "#pragma are considered statements" -
> https://groups.google.com/forum/#!topic/comp.std.c/A1rhyQ5zB7g/discussion -

Thanks Dietmar.

Seems the consensus is that it's not contrary to Standard, but it's agreed to
be confusing and undesirable by everyone except the gcc maintainers :-)

FWIW, the actual context in which I found the behaviour was this:

if (whatever...)
{
stuff...
}
#ifdef FOO
#pragma message ("QUICK AND DIRTY HACK!!!")
else if (special case...)
{
other stuff...
}
#endif // FOO

I'll take a lot of persuading that this isn't a reasonable thing to want to do.
(Flagging the nasty, that is; purists who say you should never /do/ anything
you need to warn people about need not apply :-) )

[Bug c++/51213] [C++11][DR 1170] Access control checking has to be done under SFINAE conditions

[paolo.carlini at oracle dot com]

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

--- Comment #21 from Paolo Carlini  ---
As a matter of fact, I can't reproduce the issue with 4.9.1.

[Bug c/63326] whether a #pragma is a statement depends on the type of pragma

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #9 from Jakub Jelinek  ---
Note, we already error out on OpenMP pragmas in such places, because the OpenMP
standard requires that the pragmas aren't used in contexts where accepting them
as statements or ignoring them would make a difference for parsing the
function:
"For C/C++, a stand-alone directive may not be used in place of the statement
following an if, while, do, switch, or label. See Appendix B for the formal
grammar."
so for other pragmas we could use similar conditions.

[Bug c++/51213] [C++11][DR 1170] Access control checking has to be done under SFINAE conditions

[paolo.carlini at oracle dot com]

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

--- Comment #20 from Paolo Carlini  ---
This is already fixed in mainline, though. I'm adding the testcase.

[Bug target/63424] Octave -O3 build: internal compiler error: in prepare_cmp_insn, at optabs.c:4237

[renlin.li at arm dot com]

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

--- Comment #2 from Renlin Li  ---
VEC_COND_EXPR with V2DI mode is generated as aarch64 target supports it
(vcond). The VEC_COND_EXPR expression will further folded into
MIN_EXPR/MAX_EXPR expression in the dom pass.

However, aarch64 min/max expanders don't support V2DI mode. The compiler tries
to generate compare and jump sequence for this, and no vector compare can be
found(aarch64 dose have one, however, the compiler uses cbranch as a key to
search for a compare insn). And no library function is provided, it asserts.

[Bug target/63223] [avr] Make jumptables work with -Wl,--section-start,.text=

[gjl at gcc dot gnu.org]

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

--- Comment #11 from Georg-Johann Lay  ---
(In reply to Jorn Wolfgang Rennecke from comment #10)
> Created attachment 33768 [details]
> patch for dtor direction
> 
> I have this patch for fixing the direction of the dtor execution,
> but I got stuck trying to write a testcase.

That won't work.  I'll install a working implementation soon so you can
proceed.

[Bug lto/63603] [4.9/5 Regression] Linking with -fno-lto still invokes LTO

[rguenther at suse dot de]

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

--- Comment #6 from rguenther at suse dot de  ---
On Wed, 22 Oct 2014, burnus at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63603
> 
> --- Comment #5 from Tobias Burnus  ---
> (In reply to rguent...@suse.de from comment #4)
> > That means that
> > /* We pass any -flto flags on to the linker, which is expected
> >to understand them.  In practice, this means it had better be collect2.  
> 
> > #define LINK_COMMAND_SPEC "\
> 
> >"%{flto|flto=*:% > %{flto} %{flto=*} %l " LINK_PIE_SPEC \
> > doesn't pass on -fno-lto as expected.  Does adding %{fno-lto} after
> > %{flto} work?
> 
> That seems to do the trick: I no longer see lto1 with -fno-lto (independent of
> -f(no-)use-linker-plugin) - and, unsurprisingly, without -fno-lto it still
> invokes lto1.

Great.  Patch pre-approved for trunk and 4.9 branch.

Thanks,
Richard.

[Bug lto/63603] [4.9/5 Regression] Linking with -fno-lto still invokes LTO

[burnus at gcc dot gnu.org]

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

--- Comment #5 from Tobias Burnus  ---
(In reply to rguent...@suse.de from comment #4)
> That means that
> /* We pass any -flto flags on to the linker, which is expected
>to understand them.  In practice, this means it had better be collect2.  

> #define LINK_COMMAND_SPEC "\

>"%{flto|flto=*:% %{flto} %{flto=*} %l " LINK_PIE_SPEC \
> doesn't pass on -fno-lto as expected.  Does adding %{fno-lto} after
> %{flto} work?

That seems to do the trick: I no longer see lto1 with -fno-lto (independent of
-f(no-)use-linker-plugin) - and, unsurprisingly, without -fno-lto it still
invokes lto1.

[Bug tree-optimization/61502] == comparison on "one-past" pointer gives wrong result

[rguenth at gcc dot gnu.org]

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

--- Comment #11 from Richard Biener  ---
(In reply to Harald van Dijk from comment #4)
> That's an interesting argument. You may well be right that the original
> code, strictly speaking, does not prove that GCC has a bug, but I do think
> GCC has a bug nonetheless, and have come up with a different example.
> 
> #include 
> #include 
> 
> int x, y;
> 
> char buf[sizeof (int *)];
> 
> int main()
> {
>   int *p = &y;
>   memcpy (buf, &p, sizeof p);
>   memcpy (&p, buf, sizeof p);
>   x = 2, y = 1;
>   if (p == &x + 1)
> *p = 2;
>   else
> y = 2;
>   printf ("x = %d, y = %d\n", x, y);
>   return 0;
> }
> 
> Compiling with -O2, I see "x = 2, y = 1". p has been assigned &y. Whether it
> compares equal to &x + 1 is unspecified, but it doesn't change its origins:
> p points to y. Therefore, either the assignment to *p should change y, or in
> the else branch, the plain assignment to y should change y. Either way, the
> correct result is "x = 2, y = 2".
> 
> It seems like GCC is assuming that if p == &x + 1, and &x + 1 != &y, then p
> != &y, so the assignment to *p cannot change y. The flaw in that logic is
> again the optimisation of &x + 1 != &y to a constant.
> 
> I see the behaviour I describe in versions 4.9.0 and 4.8.2. This program
> does print "x = 2, y = 2" in my testing on GCC 4.7.3, but that is because p
> == &x + 1 happens to not compare as true in that version. Slightly tweaked
> versions of this fail with versions 4.7.3, 4.6.4, 4.5.4 and 4.4.7, but not
> 4.3.6.

I can't reproduce your findings with any of the specified GCC version nor
with any other I tried (I tried on x86_64-linux and x86_64-linux with -m32).
The test program always prints "x = 2, y = 2" as expected.

[Bug c/63326] whether a #pragma is a statement depends on the type of pragma

[rguenth at gcc dot gnu.org]

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

--- Comment #8 from Richard Biener  ---
Maybe we should also warn about

  if (...)
#pragma STDC ...
foo ();

both if we are treating the #pragma as stmt and if not.  That is, if the
#pragma appears in a place where that would make a difference.

[Bug c/63613] Regression: Unable to link .c file using API (inline functions not appearing)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #4 from Richard Biener  ---
Invalid.

[Bug c/63613] Regression: Unable to link .c file using API (inline functions not appearing)

[dmalcolm at gcc dot gnu.org]

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

--- Comment #3 from dmalcolm at gcc dot gnu.org ---
Aha.  Thanks.

Indeed, "git bisect" just confirmed that r216247 is the first commit in which
my testcase stops working:

commit b2601928b5bf34a817b5a9a2a371c476018e634d
Author: mpolacek 
Date:   Wed Oct 15 10:08:00 2014 +

* doc/invoke.texi: Update to reflect that GNU11 is the default
mode for C.
* c-common.h (c_language_kind): Update comment.
c-family/
* c-opts.c (c_common_init_options): Make -std=gnu11 the default for C.


git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@216247
138bc75d-0d04-0410-961f-82ee72b054a4

[Bug sanitizer/57316] [4.8 regression] build failure in libsanitizer

[y.gribov at samsung dot com]

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

--- Comment #28 from Yury Gribov  ---
(In reply to Paul H. Hargrove from comment #26)
> (In reply to Yury Gribov from comment #25)
> > Can we close this?
> 
> Just tried to build the released 4.8.3 and still see the original problem
> (see error messages below).  Same is true at the tip of the gcc-4_8-branch
> in svn (at r216525).
> 
> However, 4.9.1 is fine.

Right, I fixed this in 4.9 and never bothered to backport to 4.8.

[Bug c/63613] Regression: Unable to link .c file using API (inline functions not appearing)

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
That means dejagnu.h assumes the GNU inline semantics, but doesn't use
__gnu_inline__ attribute.  So, either compile with -fgnu89-inline, or get
dejagnu.h fixed.

[Bug c/63613] Regression: Unable to link .c file using API (inline functions not appearing)

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
C11 inline semantics vs gnu89 ones. Not a gcc bug. A fix includes is needed.

[Bug c/63613] New: Regression: Unable to link .c file using API (inline functions not appearing)

[dmalcolm at gcc dot gnu.org]

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

Bug ID: 63613
   Summary: Regression: Unable to link .c file using 
API (inline functions not appearing)
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dmalcolm at gcc dot gnu.org

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

I'm no longer able to build test programs that use the 
header, due to a linker failure.

$ cat ../../test-dg-api.c

#include 

int
main (int argc, char **argv)
{
  pass ("got here");
  return 0;
}

The dejagnu.h API consists purely of functions marked "inline" e.g.:

63  inline void
64  pass (const char* fmt, ...)
65  {
66va_list ap;
67  
68passed++;
69va_start (ap, fmt);
70vsnprintf (buffer, sizeof (buffer), fmt, ap);
71va_end (ap);
72printf ("\tPASSED: %s\n", buffer);
73wait ();
74  }

See http://git.savannah.gnu.org/cgit/dejagnu.git/tree/dejagnu.h

With gcc 4.8.3:
  $ gcc ../../test-dg-api.c -o test-dg-api
  $ ./test-dg-api 
  PASSED: got here

and examination of the generated assembler shows it contains an
implementation of e.g. "pass".

With trunk:
  $ ./xgcc -B. ../../test-dg-api.c -o test-dg-api
  /tmp/ccc7PdfM.o: In function `main':
  test-dg-api.c:(.text+0x21): undefined reference to `pass'
  collect2: error: ld returned 1 exit status
and the generated asm doesn't contain an implementation of "pass".

This is with r216530.  I believe the problem appears somewhere between
  r215958: WORKS (aka e012cdc775868e9922f5fef9068a764546876d93, 2014-10-06)
and
  r216524: ERROR (aka d14cac46135326115f0dc589b0b3d2d249d74cf7, 2014-10-21)

Am attempting to isolate further.

With -v -save-temps:

  $ ./xgcc -B. -v -save-temps ../../test-dg-api.c -o test-dg-api

command line of cc1 is:

  ./cc1 -fpreprocessed test-dg-api.i -quiet -dumpbase test-dg-api.c
-mtune=generic -march=x86-64 -auxbase test-dg-api -version -o test-dg-api.s

and link line:

 ./collect2 -plugin ./liblto_plugin.so -plugin-opt=./lto-wrapper
-plugin-opt=-fresolution=test-dg-api.res -plugin-opt=-pass-through=-lgcc
-plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lc
-plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s
--eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o
test-dg-api /lib/../lib64/crt1.o /lib/../lib64/crti.o ./crtbegin.o -L.
-L/lib/../lib64 -L/usr/lib/../lib64 test-dg-api.o -lgcc --as-needed -lgcc_s
--no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed ./crtend.o
/lib/../lib64/crtn.o

Will attach the test-dg-api.i

This is with build,host,target==x86_64-unknown-linux-gnu (Fedora 20 x86_64)

This affects merger of my jit branch, since my testsuite is based on
dejagnu.h.

[Bug target/63594] [5 Regression] ICE: in ix86_vector_duplicate_value, at config/i386/i386.c:39831 with -mavx512f

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  ---
Fixed for AVX2, for AVX512{F,BW,VL} I'm keeping this open, as something needs
to be done about those patterns, Kyrill, can you please take care of that?

[Bug target/63542] My build log is full of "non-delegitimized UNSPEC UNSPEC_GOT (0) found in variable location"

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #6 from Jakub Jelinek  ---
Should be mostly fixed.