[Bug target/63304] Aarch64 pc-relative load offset out of range

[e.menezes at samsung dot com]

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

--- Comment #36 from Evandro  ---
(In reply to Ramana Radhakrishnan from comment #35)
> (In reply to Evandro from comment #32)
> > Because of side effects of the Haiffa scheduler, the loads now pile up, and
> > the ADRPs may affect the load issue rate rather badly if not fused.  At leas
> > on our processor.  
> 
> In straight line code I can imagine this happening - In loopy code I would
> have expected the constants to be hoisted - atleast that's what I remember
> seeing in my analysis. You have seen -mcprelative-literal-loads haven't you
> ? 

The cases that I have in mind involve SL code in functions which are called
form a loop.  Since they are external, only LTO would address such cases.  And,
since we do not control how they are built, we have to handle them as they
come.

As long as there's an opening to investigate the benefits and drawbacks of
reverting to the legacy way considering the function size, I think that it's
interesting to find out the results.

Thank you.

[Bug fortran/52673] implement -fheap-arrays in gfortran

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|NEW |WAITING

--- Comment #2 from Dominique d'Humieres  ---
Compiling the two tests with -fsanitize=address gives at run time

==74945==ERROR: AddressSanitizer: stack-buffer-overflow on address
0x7fff5d39d2b4 at pc 0x000102862c9d bp 0x7fff5d39d230 sp 0x7fff5d39d228
WRITE of size 4 at 0x7fff5d39d2b4 thread T0
#0 0x102862c9c in ss3_ (a.out+0x10c9c)
#1 0x102862c46 in ss2_ (a.out+0x10c46)
#2 0x102862bcc in ss1_ (a.out+0x10bcc)
#3 0x102862cb3 in MAIN__ (a.out+0x10cb3)
#4 0x102862cec in main (a.out+0x10cec)
#5 0x7fff8e6de5c8 in start (libdyld.dylib+0x35c8)
#6 0x0  ()

Address 0x7fff5d39d2b4 is located in stack of thread T0 at offset 52 in frame
#0 0x102862b52 in ss1_ (a.out+0x10b52)

  This frame has 1 object(s):
[32, 44) 'ia' <== Memory access at offset 52 overflows this variable
...

for the first test and

==84952==ERROR: AddressSanitizer: heap-buffer-overflow on address
0x6020e044 at pc 0x00010384ea41 bp 0x7fff5c3b1210 sp 0x7fff5c3b1208
WRITE of size 4 at 0x6020e044 thread T0
#0 0x10384ea40 in ss3_ (a.out+0x10a40)
#1 0x10384e9ea in ss2_ (a.out+0x109ea)
#2 0x10384e94a in ss1_ (a.out+0x1094a)
#3 0x10384ea57 in MAIN__ (a.out+0x10a57)
#4 0x10384ea90 in main (a.out+0x10a90)
#5 0x7fff8e6de5c8 in start (libdyld.dylib+0x35c8)
#6 0x0  ()

0x6020e044 is located 8 bytes to the right of 12-byte region
[0x6020e030,0x6020e03c)
allocated by thread T0 here:
#0 0x1038a3697 in wrap_malloc (libasan.3.dylib+0x50697)
#1 0x10384e8f8 in ss1_ (a.out+0x108f8)
#2 0x10384ea57 in MAIN__ (a.out+0x10a57)
#3 0x10384ea90 in main (a.out+0x10a90)
#4 0x7fff8e6de5c8 in start (libdyld.dylib+0x35c8)
#5 0x0  ()
...

for the second one.

This PR has not evolved since three years and a half and now new options are
available to catch such issues. IMO This PR should be closed as WONTFIX.

[Bug middle-end/67295] [ARM][6 Regression] FAIL: gcc.target/arm/builtin-bswap-1.c scan-assembler-times revshne\\t 1

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-11-07
 CC||ramana at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #4 from Ramana Radhakrishnan  ---
(In reply to Alexandre Oliva from comment #3)
> Still no luck on a x86_64-linux-gnu build machine, running ../configure
> --target=arm-none-eabi --disable-shared --disable-nls --disable-threads
> --disable-tls --enable-checking=yes --enable-languages=c,c++,fortran
> --with-newlib --with-fpu=neon-fp-armv8 --with-arch=armv8-a --without-isl
> building binutils (+gdb commit db1ff28b60) and newlib (+cygwin commit
> c7806ef76a) on the same tree.  I'm afraid this is going to be very hard to
> debug if I can't duplicate it.  Any chance you could build a toolchain that
> works on some machine on the gcc build farm, so that I could get access to
> it as well and debug from there, or at least try to figure out what the
> differences are between our setups?  Thanks,

I can see that this is a regression from GCC 5 - however something is fishy
here. 

Is there a chance Kyrill and you have different --enable-checking options ?

[Bug fortran/68216] [F2003] IO problem with allocatable, deferred character length arrays

[dominiq at lps dot ens.fr]

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

--- Comment #7 from Dominique d'Humieres  ---
> I think that a meta-bug would be an excellent idea.

It is pr68241.

[Bug target/68178] [arm] Relative address expressions bind at as-time, even if symbol is weak

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 Status|REOPENED|ASSIGNED
 CC||ramana at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |ramana at gcc dot 
gnu.org

--- Comment #9 from Ramana Radhakrishnan  ---
I'm testing a patch.

[Bug go/66138] json decoder Decode function fails for some structure return values

[ian at gcc dot gnu.org]

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

--- Comment #4 from ian at gcc dot gnu.org  ---
Author: ian
Date: Sat Nov  7 01:25:43 2015
New Revision: 229908

URL: https://gcc.gnu.org/viewcvs?rev=229908=gcc=rev
Log:
PR go/66138
reflect, encoding/json, encoding/xml: fix unexported embedded structs

Bring in three changes from the master Go repository.  These changes
will be in Go 1.6, but they are appropriate for gccgo now because they
resolve a long-standing discrepancy between how gc and gccgo handle the
PkgPath field for embedded unexported struct fields.  The core issue is
described at https://golang.org/cl/7247.  This has been reported against
gccgo as https://gcc.gnu.org/PR66138.

The three changes being brought over are:

https://golang.org/cl/14010

reflect: adjust access to unexported embedded structs

This CL changes reflect to allow access to exported fields and
methods in unexported embedded structs for gccgo and after gc
has been adjusted to disallow access to embedded unexported structs.

Adresses #12367, #7363, #11007, and #7247.

https://golang.org/cl/14011

encoding/json: check for exported fields in embedded structs

Addresses issue #12367.

https://golang.org/cl/14012

encoding/xml: check for exported fields in embedded structs

Addresses issue #12367.

Reviewed-on: https://go-review.googlesource.com/16723

Modified:
branches/gcc-5-branch/libgo/go/encoding/json/decode_test.go
branches/gcc-5-branch/libgo/go/encoding/json/encode.go
branches/gcc-5-branch/libgo/go/encoding/xml/marshal_test.go
branches/gcc-5-branch/libgo/go/encoding/xml/typeinfo.go
branches/gcc-5-branch/libgo/go/reflect/export_test.go
branches/gcc-5-branch/libgo/go/reflect/type.go
branches/gcc-5-branch/libgo/go/reflect/value.go

[Bug go/66138] json decoder Decode function fails for some structure return values

[ian at airs dot com]

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

Ian Lance Taylor  changed:

   What|Removed |Added

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

--- Comment #5 from Ian Lance Taylor  ---
Should be fixed now.  Patch is on mainline and GCC 5 branch.

[Bug go/66138] json decoder Decode function fails for some structure return values

[ian at gcc dot gnu.org]

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

--- Comment #3 from ian at gcc dot gnu.org  ---
Author: ian
Date: Sat Nov  7 01:24:57 2015
New Revision: 229907

URL: https://gcc.gnu.org/viewcvs?rev=229907=gcc=rev
Log:
PR go/66138
reflect, encoding/json, encoding/xml: fix unexported embedded structs

Bring in three changes from the master Go repository.  These changes
will be in Go 1.6, but they are appropriate for gccgo now because they
resolve a long-standing discrepancy between how gc and gccgo handle the
PkgPath field for embedded unexported struct fields.  The core issue is
described at https://golang.org/cl/7247.  This has been reported against
gccgo as https://gcc.gnu.org/PR66138.

The three changes being brought over are:

https://golang.org/cl/14010

reflect: adjust access to unexported embedded structs

This CL changes reflect to allow access to exported fields and
methods in unexported embedded structs for gccgo and after gc
has been adjusted to disallow access to embedded unexported structs.

Adresses #12367, #7363, #11007, and #7247.

https://golang.org/cl/14011

encoding/json: check for exported fields in embedded structs

Addresses issue #12367.

https://golang.org/cl/14012

encoding/xml: check for exported fields in embedded structs

Addresses issue #12367.

Reviewed-on: https://go-review.googlesource.com/16723

Modified:
trunk/gcc/go/gofrontend/MERGE
trunk/libgo/go/encoding/json/decode_test.go
trunk/libgo/go/encoding/json/encode.go
trunk/libgo/go/encoding/xml/marshal_test.go
trunk/libgo/go/encoding/xml/typeinfo.go
trunk/libgo/go/reflect/export_test.go
trunk/libgo/go/reflect/type.go
trunk/libgo/go/reflect/value.go

[Bug inline-asm/10396] Constraint alternatives cause error " `asm' operand requires impossible reload"

[gccbugzilla at limegreensocks dot com]

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

David  changed:

   What|Removed |Added

 CC||gccbugzilla@limegreensocks.
   ||com

--- Comment #22 from David  ---
Despite the impression you may get from comments 17-21, gcc DOES support
multi-alternatives with inline asm (see
https://gcc.gnu.org/ml/gcc/2015-10/msg00249.html).

I do not have an arm build with which to test, but using 5.2 on x64, the
samples in this bug do not produce errors.  Perhaps in the 7-12 years since
they were added, something got fixed?  Or maybe this problem is
platform-specific.

[Bug middle-end/65947] Vectorizer misses conditional assignment of constant

[alan.hayward at arm dot com]

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

Alan Hayward  changed:

   What|Removed |Added

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

--- Comment #8 from Alan Hayward  ---
Work with patch below plus the additional fix up patch for the compiler error.

[Bug tree-optimization/53947] [meta-bug] vectorizer missed-optimizations

[alan.hayward at arm dot com]

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

Bug 65947 Summary: Vectorizer misses conditional assignment of constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65947

   What|Removed |Added

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

[Bug target/68233] Performance : GCC not uses possible LDP-Instruction on ARM64

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
  Known to work||5.2.1, 6.0
 Resolution|--- |FIXED
  Known to fail||4.9.4

--- Comment #3 from ktkachov at gcc dot gnu.org ---
With GCC 5 and current trunk I get something like this.

zgemm:
cbz x2, .L2
.p2align 2
.L3:
ldp d2, d1, [x1]
subsx2, x2, #1
add x1, x1, 16
ldp d7, d6, [x0]
ldp d5, d4, [x0, 16]
add x0, x0, 32
fmadd   d3, d7, d2, d3
fmadd   d18, d7, d1, d18
fmadd   d21, d6, d2, d21
fmadd   d17, d6, d1, d17
fmadd   d20, d5, d2, d20
fmadd   d19, d4, d2, d19
fmadd   d0, d5, d1, d0
fmadd   d16, d4, d1, d16
bne .L3
.L2:
faddd3, d3, d21
faddd1, d3, d20
faddd1, d1, d19
faddd1, d1, d18
faddd1, d1, d17
faddd0, d1, d0
faddd0, d0, d16
ret

[Bug tree-optimization/68234] New: tree-vrp pass need to be improved when handling ASSERT/PLUS/MINUS/_EXPR and Phi node

[jiwang at gcc dot gnu.org]

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

Bug ID: 68234
   Summary: tree-vrp pass need to be improved when handling
ASSERT/PLUS/MINUS/_EXPR and Phi node
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jiwang at gcc dot gnu.org
  Target Milestone: ---

Created attachment 36661
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36661=edit
experimental-patch

r226850 will cause gcc generate more ASSERT_EXPR thus trigger some latent
issues in gcc tree-vrp pass.  For example, we are generating sub-optimal
code for gcc.c-torture/compile/20121027-1.c since r226850.

For ARM target:

./cc1 -O3 -nostdinc 20121027-1.c  -march=armv8-a -mthumb
-mfpu=crypto-neon-fp-armv8 -mfloat-abi=hard -nostdinc

before r226850:

"bl/64" turned into "bl >> 6"
==
.L3:
asrsr3, r4, #6
add r2, sp, #1024
addsr4, r4, #1
add r3, r2, r3, lsl #3
subwr3, r3, #1019
vld1.64 {d16}, [r3]
vmovr0, r1, d16 @ int
bl  ff
ldr r3, [r5]
cmp r3, r4
bgt .L3


after ("bl/64" is not turned into "bl >> 6")
===
.L3:
add r3, r4, #63
add r2, sp, #1024
andsr3, r3, r4, asr #32
it  cc
movcc   r3, r4
addsr4, r4, #1
asrsr3, r3, #6
add r3, r2, r3, lsl #3
subwr3, r3, #1019
vld1.64 {d16}, [r3]
vmovr0, r1, d16 @ int
bl  ff
ldr r3, [r5]
cmp r3, r4
bgt .L3

For mips target:

./cc1 -O2 -march=mips32r2 -mabi=32 20121027-1.c   -nostdinc

before
===
$L8:
addiu   $16,$16,1
sll $2,$2,3
addu$2,$17,$2
lwl $5,9($2)
lwl $4,5($2)
lwr $5,12($2)
lwr $4,8($2)
jal ff
lw  $2,0($18)
slt $2,$16,$2
bne $2,$0,$L8
sra $2,$16,6
after
===
$L9:
slt $2,$16,0
movz$3,$16,$2
addiu   $16,$16,1
sra $2,$3,6
sll $2,$2,3
addu$2,$17,$2
lwl $5,9($2)
lwl $4,5($2)
lwr $5,12($2)
lwr $4,8($2)
jal ff
lw  $2,0($18)
slt $2,$16,$2
bne $2,$0,$L9
addiu   $3,$16,63

This is because previously gcc can deduct the value range for the variable
"bl", and conclude it will be positive, then later optimization can turn the
signed division to right shift thus we can avoid runtime overhead for signed
division. After r226850, gcc can't deduct this. The initial cause if r226850
will introduce more ASSERT_EXPR which is fine but it caused problem for
tree-vrp.

From .vrp1 dump, tree-vrp pass is too conservative at three places:

1. When handling ASSERT_EXPR

  Visiting statement:
  c_13 = ASSERT_EXPR ;
  Intersecting
[-INF, nc.0_4 + -1]
  and
[0, 0]
  to
[-INF, nc.0_4 + -1]

the range info should be [0, nc.0_4 + -1].

my understanding is for ASSERT_EXPR ,  if var is SSA_NAME and
have valid range info, then it's minimum should be honored.

2. When handling PLUS_EXPR with symbolic range

After fixed issue 1, the range of c_13 will be [0, nc.0_4 + -1], but the
following PLUS_EXPR range b1_11 to be VARYING which is wrong.

  Visiting statement:
  bl_11 = c_13 + 1;
  Found new range for bl_11: VARYING

The range of bl_11 should be [1, nc.0_4].

looks to me the following code at the bottom of
extract_range_from_binary_expr_1 is overkilling. At least for
PLUS_EXPR/MINUS_EXPR. "cmp == -2" which means there is symbolic range,
should be allowed for both, otherwise why there are lots of code in
PLUS_EXPR/MINUS_EXPR hunk deliberately handling symbolic range?

  cmp = compare_values (min, max);
  if (cmp == -2 || cmp == 1)
  set_value_range_to_varying (vr);

So I think we should relax the condition to not included
PLUS_EXPR/MINUS_EXPR when cmp == -2.

3. When handling phi node

Even after both 1 and 2 fixed, there still be another issue for phi node.

Given, bl_11 now with the range  [1, nc.0_4], I found it's range info is
not honored when visiting PHI node, looks to me, the following code in
vrp_visit_phi_node is overkilling, and I don't know how to relax it
properly, if we simply remove this block of code, then gcc can finally get
correct range info for the testcase 20121027-1.c and generate optimized
instruction sequences.

  /* Do not allow equivalences or symbolic ranges to leak in from
 backedges.  That creates invalid equivalencies.
 See PR53465 and PR54767.  */
  if (e->flags & EDGE_DFS_BACK)
{
  if (vr_arg.type == VR_RANGE
  || vr_arg.type == VR_ANTI_RANGE)
{
  vr_arg.equiv = NULL;
  if 

[Bug rtl-optimization/64164] [4.9/5/6 Regression] one more stack slot used due to one less inlining level

[aoliva at gcc dot gnu.org]

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

--- Comment #56 from Alexandre Oliva  ---
Author: aoliva
Date: Fri Nov  6 10:34:13 2015
New Revision: 229840

URL: https://gcc.gnu.org/viewcvs?rev=229840=gcc=rev
Log:
[PR67753] fix copy of PARALLEL entry_parm to CONCAT target_reg

In assign_parms_setup_block, the copy of args in PARALLELs from
entry_parm to stack_parm is deferred to the parm conversion insn seq,
but the copy from stack_parm to target_reg was inserted in the normal
copy seq, that is executed before the conversion insn seq.  Oops.

We could do away with the need for an actual stack_parm in general,
which would have avoided the need for emitting the copy to target_reg
in the conversion seq, but at least on pa, due to the need for stack
to copy between SI and SF modes, it seems like using the reserved
stack slot is beneficial, so I put in logic to use a pre-reserved
stack slot when there is one, and emit the copy to target_reg in the
conversion seq if stack_parm was set up there.

for  gcc/ChangeLog

PR rtl-optimization/67753
PR rtl-optimization/64164
* function.c (assign_parm_setup_block): Avoid allocating a
stack slot if we don't have an ABI-reserved one.  Emit the
copy to target_reg in the conversion seq if the copy from
entry_parm is in it too.  Don't use the conversion seq to copy
a PARALLEL to a REG or a CONCAT.

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

[Bug rtl-optimization/67753] [6 Regression] FAIL: cxg1005, cxg2002, cxg2006, cxg2007, cxg2008, cxg2018, cxg2019 and cxg2020

[aoliva at gcc dot gnu.org]

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

--- Comment #6 from Alexandre Oliva  ---
Author: aoliva
Date: Fri Nov  6 10:34:13 2015
New Revision: 229840

URL: https://gcc.gnu.org/viewcvs?rev=229840=gcc=rev
Log:
[PR67753] fix copy of PARALLEL entry_parm to CONCAT target_reg

In assign_parms_setup_block, the copy of args in PARALLELs from
entry_parm to stack_parm is deferred to the parm conversion insn seq,
but the copy from stack_parm to target_reg was inserted in the normal
copy seq, that is executed before the conversion insn seq.  Oops.

We could do away with the need for an actual stack_parm in general,
which would have avoided the need for emitting the copy to target_reg
in the conversion seq, but at least on pa, due to the need for stack
to copy between SI and SF modes, it seems like using the reserved
stack slot is beneficial, so I put in logic to use a pre-reserved
stack slot when there is one, and emit the copy to target_reg in the
conversion seq if stack_parm was set up there.

for  gcc/ChangeLog

PR rtl-optimization/67753
PR rtl-optimization/64164
* function.c (assign_parm_setup_block): Avoid allocating a
stack slot if we don't have an ABI-reserved one.  Emit the
copy to target_reg in the conversion seq if the copy from
entry_parm is in it too.  Don't use the conversion seq to copy
a PARALLEL to a REG or a CONCAT.

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

[Bug fortran/68227] ICE on using variable limit in forall header (gfc_do_allocate)

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-11-06
 Ever confirmed|0   |1

--- Comment #2 from Dominique d'Humieres  ---
Confirmed from 4.4 up to trunk (6.0).

Note that 4.3 gives the following error for both tests:

  type(t), pointer :: a
   1
Error: The pointer component 'a' of 't2' at (1) is a type that has not been
declared

[Bug middle-end/68221] libgomp reduction-11/12 failures

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

--- Comment #1 from Richard Biener  ---
We could fold it to MEM[(short int *)] (without the array-ref).  Does the
same problem exist for variable indexed array?

I'll have a look during stage3 - I believe the oracle should be have sanely
here and thus there is likely a bug somewhere.

[Bug bootstrap/68231] [6 Regression] bootstrap failure after placement new

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target|powerpc-ibm-aix*|
Summary|[6 Regression] AIX  |[6 Regression] bootstrap
   |bootstrap failure after |failure after placement new
   |placement new   |

--- Comment #4 from Richard Biener  ---
Same on x86_64-linux configured with

/gcc/spec/sb-czerny-head-64-2006/gcc/configure --disable-bootstrap
--prefix=/gcc/spec/sb-czerny-head-64-2006/x86_64/install-hack
--enable-languages=c,c++,f95 --enable-threads=posix --disable-nls
--enable-__cxa_atexit --enable-clocale=gnu --enable-checking=release
--disable-libsanitizer --disable-libcilkrts

[Bug debug/68229] .debug_pubnames length field is too large

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-debug
 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2015-11-06
 Ever confirmed|0   |1

--- Comment #3 from Richard Biener  ---
Works for me with GCC 5 (?), so can you please check a newer GCC as GCC 4.8 is
no longer supported.

readelf -S progtest.o libtest.o progtest.x | grep -A1 .debug_pubnames
  [ 9] .debug_pubnames   PROGBITS   01da
   0028     0 0 1
--
  [ 9] .debug_pubnames   PROGBITS   01ee
   0025     0 0 1
--
  [29] .debug_pubnames   PROGBITS   1230
   004d     0 0 1
readelf -wp progtest.o libtest.o

File: progtest.o
Contents of the .debug_pubnames section:

  Length:  36
  Version: 2
  Offset into .debug_info section: 0x0
  Size of area in .debug_info section: 218

Offset  Name
80  main
c4  variable


File: libtest.o
Contents of the .debug_pubnames section:

  Length:  33
  Version: 2
  Offset into .debug_info section: 0x0
  Size of area in .debug_info section: 241

Offset  Name
a2  f
b9  i
dc  pt

readelf -wp progtest.x
Contents of the .debug_pubnames section:

  Length:  36
  Version: 2
  Offset into .debug_info section: 0x15b
  Size of area in .debug_info section: 218

Offset  Name
80  main
c4  variable
  Length:  33
  Version: 2
  Offset into .debug_info section: 0x235
  Size of area in .debug_info section: 241

Offset  Name
a2  f
b9  i
dc  pt

[Bug middle-end/68232] New: gcc.dg/ifcvt-4.c fails on some arm configurations

[clyon at gcc dot gnu.org]

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

Bug ID: 68232
   Summary: gcc.dg/ifcvt-4.c fails on some arm configurations
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: clyon at gcc dot gnu.org
  Target Milestone: ---
Target: arm

gcc.dg/ifcvt-4.c as introduced by r229822 fails in these configurations:

* target arm-none-linux-gnueabi
  arch armv5t
  mode thumb

* target arm-none-linux-gnueabihf
  cpu cortex-a5
  fpu vfpv3-d16-fp16

FAIL: gcc.dg/ifcvt-4.c scan-rtl-dump ce1 "2 true changes made"

[Bug c/68162] [5/6 Regression] Incompatible pointer type using a typedef

[rguenth at gcc dot gnu.org]

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

--- Comment #9 from Richard Biener  ---
(In reply to jos...@codesourcery.com from comment #8)
> I don't know what DWARF semantics are meant to be, but the language 
> semantics are definitely that in C array types are always unqualified, 
> whereas in C++, while the qualifiers still apply to the element type, the 
> array type is also considered qualified for most/all purposes.
> 
> > When I just not do that main variant punning here I get
> > 
> >  <1><60>: Abbrev Number: 10 (DW_TAG_variable)
> > <61>   DW_AT_name: (indirect string, offset: 0x7b): harry
> > <65>   DW_AT_decl_file   : 1
> > <66>   DW_AT_decl_line   : 5
> > <67>   DW_AT_type: <0x75>
> > ...
> >  <1><75>: Abbrev Number: 6 (DW_TAG_const_type)
> > <76>   DW_AT_type: <0x49>
> >  <1><49>: Abbrev Number: 7 (DW_TAG_array_type)
> > <4a>   DW_AT_type: <0x39>
> > <4e>   DW_AT_sibling : <0x59>
> >  <1><39>: Abbrev Number: 5 (DW_TAG_typedef)
> > <3a>   DW_AT_name: (indirect string, offset: 0x0): Harry_t
> > <3e>   DW_AT_decl_file   : 1
> > <3f>   DW_AT_decl_line   : 4
> > <40>   DW_AT_type: <0x44>
> > 
> > instead.  Not sure about that "extra" const qualifier on the array type
> > though.
> 
> Does the extra qualifier come from decl_quals extracting qualifiers from a 
> decl to combine with those for the type?  My guess would be that such code 
> for extracting qualifiers is a legacy of when, a long time ago (before 
> ), the types of 
> decls in the C and C++ front ends did not include top-level qualifiers, 
> and so should be obsolete now.

I have no idea and my dives into dwarf2out.c have not been volutary for now ;)

Cleaning it up and removing cruft is always welcome.

[Bug tree-optimization/65963] Missed vectorization of loads strided with << when equivalent * succeeds

[clyon at gcc dot gnu.org]

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

Christophe Lyon  changed:

   What|Removed |Added

 CC||clyon at gcc dot gnu.org

--- Comment #3 from Christophe Lyon  ---
The new test gcc.dg/vect/vect-strided-shift-1.c fails at execution on
armeb-none-linux-gnueabihf:

FAIL:
  gcc.dg/vect/vect-strided-shift-1.c -flto -ffat-lto-objects execution test
  gcc.dg/vect/vect-strided-shift-1.c execution test

[Bug target/68233] New: Performance : GCC not uses possible LDP-Instruction on ARM64

[gunnar.von.boehn at huawei dot com]

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

Bug ID: 68233
   Summary: Performance : GCC not uses possible LDP-Instruction on
ARM64
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gunnar.von.boehn at huawei dot com
  Target Milestone: ---

Dear List,

it seems to me that GCC not fully utilizes available LDP-instruction on ARM64.
On Cortex-A57 the LDP instruction could load 2 64bit registers in 1 cycle,
while when using LDR-instructions only 1 can be loaded.




I have ARM64 / Cortex-A57 System: 
acc@linaro-nano:~/minibench9$ cat /proc/cpuinfo
processor   : 0
Features: fp asimd evtstrm aes pmull sha1 sha2 crc32
CPU implementer : 0x41
CPU architecture: 8
CPU variant : 0x1
CPU part: 0xd07
CPU revision: 1



gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/aarch64-linux-gnu/4.9/lto-wrapper
Target: aarch64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro
4.9.2-10ubuntu13' --with-bugurl=file:///usr/share/doc/gcc-4.9/README.Bugs
--enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.9 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.9 --libdir=/usr/lib --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-libsanitizer
--disable-libquadmath --enable-plugin --with-system-zlib
--disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.9-arm64/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.9-arm64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.9-arm64
--with-arch-directory=arm64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-multiarch --disable-werror --enable-checking=release
--build=aarch64-linux-gnu --host=aarch64-linux-gnu --target=aarch64-linux-gnu
Thread model: posix
gcc version 4.9.2 (Ubuntu/Linaro 4.9.2-10ubuntu13)


compile options:

gcc -O2 -S -mcpu=cortex-A57 -mtune=cortex-A57 ldp.c



C Source:

acc@linaro-nano:~/minibench9$ cat ldp.c
#include 
#include 
#include 
#include 
#include 
#include 

 double zgemm(double * ptrba, double * ptrbb, size_t bk){
double  load0,load1,load2,load3,load4,load5;
double  res0,res1,res2,res3,res4,res5,res6,res7;

 for( ; bk; bk--)
   {

  load0 = ptrba[4*0+0];
  load2 = ptrba[4*0+1];
  load4 = ptrba[4*0+2];
  load5 = ptrba[4*0+3];

  load1 = ptrbb[4*0+0];
  load3 = ptrbb[4*0+1];

  res0 = res0+load0*load1;
  res1 = res1+load2*load1;
  res2 = res2+load4*load1;
  res3 = res3+load5*load1;
  res4 = res4+load0*load3;
  res5 = res5+load2*load3;
  res6 = res6+load4*load3;
  res7 = res7+load5*load3;

  ptrba += 4;
  ptrbb += 2;

}
res0 += res1;
res0 += res2;
res0 += res3;
res0 += res4;
res0 += res5;
res0 += res6;
res0 += res7;
return res0;
}

***
Created ASM code:


acc@linaro-nano:~/minibench9$ cat ldp.s
.cpu cortex-a57+fp+simd+crc
.file   "ldp.c"
.text
.align  2
.global zgemm
.type   zgemm, %function
zgemm:
cbz x2, .L2
.L3:
ldr d2, [x1]
subsx2, x2, #1
add x0, x0, 32
ldr d1, [x1, 8]
add x1, x1, 16
ldr d7, [x0, -32]
ldr d6, [x0, -24]
ldr d5, [x0, -16]
ldr d4, [x0, -8]
fmadd   d3, d7, d2, d3
fmadd   d18, d7, d1, d18
fmadd   d21, d6, d2, d21
fmadd   d20, d5, d2, d20
fmadd   d19, d4, d2, d19
fmadd   d0, d6, d1, d0
fmadd   d17, d5, d1, d17
fmadd   d16, d4, d1, d16
bne .L3
.L2:
faddd2, d3, d21
faddd3, d2, d20
faddd3, d3, d19
faddd1, d3, d18
faddd1, d1, d0
faddd0, d1, d17
faddd0, d0, d16
ret
.size   zgemm, .-zgemm
.ident  "GCC: (Ubuntu/Linaro 4.9.2-10ubuntu13) 

[Bug middle-end/68232] gcc.dg/ifcvt-4.c fails on some arm configurations

[jgreenhalgh at gcc dot gnu.org]

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

James Greenhalgh  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-11-06
 CC||jgreenhalgh at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from James Greenhalgh  ---
For this testcase to succeed you need a branch cost >= 1. I had thought that
this would cover all targets, but it looks like the ARM target defines branch
target to zero for some configurations.

  static int
  arm_default_branch_cost (bool speed_p, bool predictable_p ATTRIBUTE_UNUSED)
  {
if (TARGET_32BIT)
  return (TARGET_THUMB2 && !speed_p) ? 1 : 4;
else
  return (optimize > 0) ? 2 : 0;
  }

  static int
  arm_cortex_a5_branch_cost (bool speed_p, bool predictable_p)
  {
return speed_p ? 0 : arm_default_branch_cost (speed_p, predictable_p);
  }

  /* Thumb-2 branches are relatively cheap on Cortex-M processors ("1 + P
cycles"
 on Cortex-M4, where P varies from 1 to 3 according to some criteria),
since
 sequences of non-executed instructions in IT blocks probably take the same
 amount of time as executed instructions (and the IT instruction itself
takes
 space in icache).  This function was experimentally determined to give
good
 results on a popular embedded benchmark.  */

  static int
  arm_cortex_m_branch_cost (bool speed_p, bool predictable_p)
  {
return (TARGET_32BIT && speed_p) ? 1
   : arm_default_branch_cost (speed_p, predictable_p);
  }

This test should be an XFAIL wherever BRANCH_COST == 0, but I'm not sure what
the polite way to explain that to the test harness is.

Confirmed (and expected) anyway.

[Bug target/68233] Performance : GCC not uses possible LDP-Instruction on ARM64

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
Can you try GCC 5 or the trunk, I think this was just fixed recently.

And it is not 1 cycle, it is 4 cycles (the latency to L1).

[Bug target/68233] Performance : GCC not uses possible LDP-Instruction on ARM64

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 CC||ktkachov at gcc dot gnu.org

--- Comment #2 from ktkachov at gcc dot gnu.org ---
Indeed I get load-pairs with latest GCC 5 and trunk

[Bug tree-optimization/53852] [4.9/5/6 Regression] -ftree-loop-linear: large compile time / memory usage

[vondele at gcc dot gnu.org]

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

--- Comment #21 from vondele at gcc dot gnu.org ---
Author: vondele
Date: Fri Nov  6 09:51:12 2015
New Revision: 229839

URL: https://gcc.gnu.org/viewcvs?rev=229839=gcc=rev
Log:
Add testcases for middle-end/53852 and middle-end/67518

2015-11-06  Joost VandeVondele  

PR middle-end/53852
PR middle-end/67518
* gfortran.dg/PR67518.f90: New test.
* gfortran.dg/PR53852.f90: New test.



Added:
trunk/gcc/testsuite/gfortran.dg/PR53852.f90
trunk/gcc/testsuite/gfortran.dg/PR67518.f90
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/67518] [6 Regression][graphite] ISL: position out of bounds

[vondele at gcc dot gnu.org]

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

--- Comment #4 from vondele at gcc dot gnu.org ---
Author: vondele
Date: Fri Nov  6 09:51:12 2015
New Revision: 229839

URL: https://gcc.gnu.org/viewcvs?rev=229839=gcc=rev
Log:
Add testcases for middle-end/53852 and middle-end/67518

2015-11-06  Joost VandeVondele  

PR middle-end/53852
PR middle-end/67518
* gfortran.dg/PR67518.f90: New test.
* gfortran.dg/PR53852.f90: New test.



Added:
trunk/gcc/testsuite/gfortran.dg/PR53852.f90
trunk/gcc/testsuite/gfortran.dg/PR67518.f90
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/66612] [6 regression] FAIL: gcc.target/powerpc/20050830-1.c scan-assembler bdn

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 CC||segher at gcc dot gnu.org

--- Comment #8 from Segher Boessenkool  ---
I experimented a bit with this.  If I force the candidate cost of the
iv cand that has step -1 and ends at 0 (after the final increment) to
be COST_N_INSNS (1) less, simulating what the cost should be taking
our doloop into account, we get the expected loop body (and the usual
mess in the header, alas).

Let's not XFAIL it (yet); it's a regression, we can still fix it in
stage 3.

[Bug fortran/68227] ICE on using variable limit in forall header (gfc_do_allocate)

[dominiq at lps dot ens.fr]

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

--- Comment #3 from Dominique d'Humieres  ---
The ICE occurs at

  gcc_assert (INTEGER_CST_P (size));

I don't follow the logic of

gfc_do_allocate (tree bytesize, tree size, tree * pdata, stmtblock_t * pblock,
 tree elem_type)
{
  tree tmpvar;
  tree type;
  tree tmp;

  if (INTEGER_CST_P (size))
tmp = fold_build2_loc (input_location, MINUS_EXPR, gfc_array_index_type,
   size, gfc_index_one_node);
  else
tmp = NULL_TREE;

  type = build_range_type (gfc_array_index_type, gfc_index_zero_node, tmp);
  type = build_array_type (elem_type, type);
  if (gfc_can_put_var_on_stack (bytesize))
{
  gcc_assert (INTEGER_CST_P (size));
  tmpvar = gfc_create_var (type, "temp");
  *pdata = NULL_TREE;
}
  else
...

>From the first 'if' block, I understand that INTEGER_CST_P (size) can be NULL,
why the first branch in the second if block can be taken in this case?

May be related to pr55086.

[Bug tree-optimization/68235] New: gimple optimisations always use global -fmath-errno setting

[rsandifo at gcc dot gnu.org]

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

Bug ID: 68235
   Summary: gimple optimisations always use global -fmath-errno
setting
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rsandifo at gcc dot gnu.org
  Target Milestone: ---

At the moment the ECF_* flags for a gimple call to a built-in
function are derived from the function decl, which in turn is
derived from the global command-line options.  So if the compiler
is run with -fno-math-errno, we always assume functions don't set
errno, regardless of local optimisation options.  Similarly if the
compiler is run with -fmath-errno, we always assume functions set errno.

This shows up in gcc.dg/lto/20110201-1_0.c, where we compile
the file with -O0 and use -O2 -ffast-math for a specific function.
-O2 -ffast-math is enough for us to convert cabs to sqrt as hoped,
but because of the global -fmath-errno setting, we assume that the
call to sqrt is not pure or const and create vops for it.  This makes
it appear to the gimple code that a simple sqrt optab isn't enough.

[Bug target/57845] ICE with -freg-struct-return on SPARC

[sorganov at gmail dot com]

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

--- Comment #8 from Sergey Organov  ---
I'm trying to upgrade from 3.4.4 to 5.2.0, and I used -freg-struct-return for
years with 3.4.4 with no issues. Not that there is huge amount of code that
actually uses functions returning structures, but the project itself is about
5Mb of compiled code.

I immediately ran to this ICE compiling real code, and then narrowed it down to
these toy examples. I can easily check any code on 3.4.4, but I doubt it'd be
productive for me to dig into current gcc sources I'm not familiar with,
especially provided you doubt the feature is to be at all supported. 

On the other hand, I doubt the case I provided works in 5.2.0 by pure accident
either, and there is some hope a fix for the ICE is rather simple for somebody
who is familiar with gcc code base.

[Bug fortran/55099] Surprising but valid 'PROCEDURE attribute conflicts with INTENT attribute' error

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #4 from Dominique d'Humieres  ---
Improving the message will be quite trivial once an agreement is found about
the improvement. Would the addition of "This name has not been declared as an
array or a function." be OK? Can someone find a better one?

[Bug tree-optimization/68234] tree-vrp pass need to be improved when handling ASSERT/PLUS/MINUS/_EXPR and Phi node

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
 CC||rguenth at gcc dot gnu.org

--- Comment #1 from Richard Biener  ---
(In reply to Jiong Wang from comment #0)
> Created attachment 36661 [details]
> experimental-patch
> 
> r226850 will cause gcc generate more ASSERT_EXPR thus trigger some latent
> issues in gcc tree-vrp pass.  For example, we are generating sub-optimal
> code for gcc.c-torture/compile/20121027-1.c since r226850.
> 
> For ARM target:
> 
> ./cc1 -O3 -nostdinc 20121027-1.c  -march=armv8-a -mthumb
> -mfpu=crypto-neon-fp-armv8 -mfloat-abi=hard -nostdinc
> 
> before r226850:
> 
> "bl/64" turned into "bl >> 6"
> ==
> .L3:
> asrsr3, r4, #6
> add r2, sp, #1024
> addsr4, r4, #1
> add r3, r2, r3, lsl #3
> subwr3, r3, #1019
> vld1.64 {d16}, [r3]
> vmovr0, r1, d16 @ int
> bl  ff
> ldr r3, [r5]
> cmp r3, r4
> bgt .L3
> 
> 
> after ("bl/64" is not turned into "bl >> 6")
> ===
> .L3:
> add r3, r4, #63
> add r2, sp, #1024
> andsr3, r3, r4, asr #32
> it  cc
> movcc   r3, r4
> addsr4, r4, #1
> asrsr3, r3, #6
> add r3, r2, r3, lsl #3
> subwr3, r3, #1019
> vld1.64 {d16}, [r3]
> vmovr0, r1, d16 @ int
> bl  ff
> ldr r3, [r5]
> cmp r3, r4
> bgt .L3
> 
> For mips target:
> 
> ./cc1 -O2 -march=mips32r2 -mabi=32 20121027-1.c   -nostdinc
> 
> before
> ===
> $L8:
> addiu   $16,$16,1
> sll $2,$2,3
> addu$2,$17,$2
> lwl $5,9($2)
> lwl $4,5($2)
> lwr $5,12($2)
> lwr $4,8($2)
> jal ff
> lw  $2,0($18)
> slt $2,$16,$2
> bne $2,$0,$L8
> sra $2,$16,6
> after
> ===
> $L9:
> slt $2,$16,0
> movz$3,$16,$2
> addiu   $16,$16,1
> sra $2,$3,6
> sll $2,$2,3
> addu$2,$17,$2
> lwl $5,9($2)
> lwl $4,5($2)
> lwr $5,12($2)
> lwr $4,8($2)
> jal ff
> lw  $2,0($18)
> slt $2,$16,$2
> bne $2,$0,$L9
> addiu   $3,$16,63
> 
> This is because previously gcc can deduct the value range for the variable
> "bl", and conclude it will be positive, then later optimization can turn the
> signed division to right shift thus we can avoid runtime overhead for signed
> division. After r226850, gcc can't deduct this. The initial cause if r226850
> will introduce more ASSERT_EXPR which is fine but it caused problem for
> tree-vrp.
> 
> From .vrp1 dump, tree-vrp pass is too conservative at three places:
> 
> 1. When handling ASSERT_EXPR
> 
>   Visiting statement:
>   c_13 = ASSERT_EXPR ;
>   Intersecting
> [-INF, nc.0_4 + -1]
>   and
> [0, 0]
>   to
> [-INF, nc.0_4 + -1]
> 
> the range info should be [0, nc.0_4 + -1].

No, the intersection is [0,0].  Basically the code fails to properly
intersect and can choose either original range.  We at the moment
choose the first because always choosing a non-symbolic range
regresses symbolic range handling (AFAIR).

Note that [0, nc.0_4 + 1] is not correct as nc.0_4 + 1 could be
less than zero (in which case the intersection result would be
UNDEFINED).  So eventually choosing [0, nc.0_4 + 1] is ok.

> 
> my understanding is for ASSERT_EXPR ,  if var is SSA_NAME
> and
> have valid range info, then it's minimum should be honored.
> 
> 2. When handling PLUS_EXPR with symbolic range
> 
> After fixed issue 1, the range of c_13 will be [0, nc.0_4 + -1], but the
> following PLUS_EXPR range b1_11 to be VARYING which is wrong.
> 
>   Visiting statement:
>   bl_11 = c_13 + 1;
>   Found new range for bl_11: VARYING
> 
> The range of bl_11 should be [1, nc.0_4].

If the type is a wrapping type then nc.0_4 -1 + 1 might wrap around
and the range become invalid (an anti-range).

Note that symbolic range handling is _very_ limited right now.

> looks to me the following code at the bottom of
> extract_range_from_binary_expr_1 is overkilling. At least for
> PLUS_EXPR/MINUS_EXPR. "cmp == -2" which means there is symbolic range,
> should be allowed for both, otherwise why there are lots of code in
> PLUS_EXPR/MINUS_EXPR hunk deliberately handling symbolic range?
> 
>   cmp = compare_values (min, max);
>   if (cmp == -2 || cmp == 1)
>   set_value_range_to_varying (vr);
> 
> So I think we should relax the condition to not included
> PLUS_EXPR/MINUS_EXPR when cmp == -2.

See above for the overflow issues.  For 

[Bug target/68228] __builtin_ia32_pbroadcastd256 generates wrong insn at >= -O1

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

  Known to work||5.3.0, 6.0

--- Comment #3 from Uroš Bizjak  ---
The testcase produces correct VPBROADCASTD with gcc-5 and newer.

[Bug tree-optimization/68145] [6 Regression] ICE: in vectorizable_store, at tree-vect-stmts.c:5684

[ienkovich at gcc dot gnu.org]

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

Ilya Enkovich  changed:

   What|Removed |Added

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

--- Comment #4 from Ilya Enkovich  ---
Fixed

[Bug target/57845] ICE with -freg-struct-return on SPARC

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|REOPENED|ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |ebotcazou at gcc dot 
gnu.org

--- Comment #10 from Eric Botcazou  ---
Investigating.

[Bug tree-optimization/68235] gimple optimisations always use global -fmath-errno setting

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-11-06
 CC||jsm28 at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed.  The solution for this specific case is to have distinct builtins
for
no-math-errno, like __builtin_sqrt_no_math_errno ().

Note that slightly related is -frounding-math which causes math functions
to become pure rather than const (and thus get a VUSE).

[Bug target/68236] [6 Regression] selective scheduling with --param=sched-autopref-queue-depth=10 ICEs a lot @ aarch64

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |6.0

[Bug target/63304] Aarch64 pc-relative load offset out of range

[e.menezes at samsung dot com]

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

--- Comment #30 from Evandro  ---
The performance impact of always referring to constants as if they were far
away is significant on targets which do not fuse ADRP and LDR together.  What's
the status of the solution that evaluates the function size?  Should this be
optionally enabled only?  Would it be the case to come up with a medium code
model? :-P  Could the assembler be left to address this issue by relaxing such
loads? :-P  

Thank you.

[Bug fortran/68216] [F2003] IO problem with allocatable, deferred character length arrays

[paul.richard.thomas at gmail dot com]

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

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

I think that a meta-bug would be an excellent idea.  I am 5
regressions away from a fix for this PR. I'll get the patch to you
over the weekend.

Many thanks for your support

Paul

On 5 November 2015 at 10:33, dominiq at lps dot ens.fr
 wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68216
>
> --- Comment #2 from Dominique d'Humieres  ---
> If this help, I have found the following PRs related to deferred-length:
> pr49630, pr49954, pr50221, pr54070, pr55735, pr57735, pr57910, pr63932,
> pr65677, pr66408, and pr67674. Will it worth opening a "meta-bug" for them? or
> adding '[DL]' at the beginning of the summaries?
>
> --
> You are receiving this mail because:
> You reported the bug.

[Bug fortran/68216] [F2003] IO problem with allocatable, deferred character length arrays

[neil.n.carlson at gmail dot com]

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

--- Comment #5 from neil.n.carlson at gmail dot com ---
Paul, I'm delighted than someone is finally working on this long-standing
problem. I hope you're also taking a look at all the other related PRs that
Dominique pointed out; I suspect that they all share the same core error. 
-Neil

[Bug fortran/44491] Diagnostic just shows "" instead of a locus

[manu at gcc dot gnu.org]

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

--- Comment #5 from Manuel López-Ibáñez  ---
(In reply to Dominique d'Humieres from comment #4)
> Compiling the test in comment 0 with 5.2.0 or trunk gives an ICE
> 
> in gfc_format_decoder, at fortran/error.c:936

There is an assert at that line:

 gcc_assert (loc->nextc - loc->lb->line >= 0);

why is it not true?

This predates my changes, since the original code did not have a correct
location there either, that is why it printed 

  if (l1 == NULL || l1->lb == NULL)
{
  error_printf ("\n");
  return;
}

If printing that is the correct behavior (which the original reporter thinks is
not), then the assert needs to be replaced with something else. When Tobias and
I moved Fortran to the common diagnostics, it was not clear what should happen
with some Fortran specific codes (like the one that handles ""). The code is still there, but it is not used anymore.
Ideally, Fortran devs should decide what behavior they expect and figure out a
way to implement this behavior. I'm certain it is possible with either no or
minimal changes to the common diagnostics. In this case, it is a matter of
implementing whatever behavior Fortran wants on either gfc_diagnostic_starter
or gfc_diagnostic_finalizer.

(Have you tried patch in comment #2?)

[Bug rtl-optimization/68236] [6 Regression] selective scheduling with --param=sched-autopref-queue-depth=10 ICEs a lot @ aarch64

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
  Component|target  |rtl-optimization
   Assignee|unassigned at gcc dot gnu.org  |ktkachov at gcc dot 
gnu.org

--- Comment #2 from ktkachov at gcc dot gnu.org ---
I'm testing a patch and I think this is a haifa-sched issue.

[Bug fortran/68237] New: ICE on invalid with submodules

[mar...@mpa-garching.mpg.de]

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

Bug ID: 68237
   Summary: ICE on invalid with submodules
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mar...@mpa-garching.mpg.de
  Target Milestone: ---

Current trunk gfortran ICEs on the code below instead of producing an eror
message:

module m1
end module

submodule (m1) m2

contains

module procedure foo
end procedure

end submodule

gfortran bug.f08
f951: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug tree-optimization/68238] New: Vector cost model overestimates prologue cost for SLPed code

[jgreenhalgh at gcc dot gnu.org]

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

Bug ID: 68238
   Summary: Vector cost model overestimates prologue cost for
SLPed code
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jgreenhalgh at gcc dot gnu.org
  Target Milestone: ---
  Host: *-*-*
Target: *-*-*

Created attachment 36663
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36663=edit
reduced testcase showing high costs analysis

The attached testcase is derived from a benchmark which shows a performance
regression under GCC 4.9 and GCC 5.2. At the root of the regression is the
runtime profitability calculation which decides whether to execute the scalar
or the vector code path. GCC 4.9 and 5.2 both return a much higher guess at the
minimum number of iterations for the vector code-path to be profitable,
consequently low values of "size" are sent on the scalar path and show a drop
in performance along the magnitude of the number of vector lanes your target
can load. 

I'm compiling the testcase (on x86_64-none-linux-gnu or aarch64-none-linux-gnu
- though AArch64 vector costs are unreliable in 4.9 and 5.2) with:

   -O3 slp-costs.c

On my (x86_64) system GCC 4.8.2 the cost analysis looks like:

slp-costs.c:7: note: Cost model analysis: 
  Vector inside of loop cost: 32
  Vector prologue cost: 10
  Vector epilogue cost: 0
  Scalar iteration cost: 64
  Scalar outside cost: 1
  Vector outside cost: 10
  prologue iterations: 0
  epilogue iterations: 0
  Calculated minimum iters for profitability: 1

On my (x86_64) 5.2 the cost analysis looks like:

slp-costs.c:7:3: note: Cost model analysis: 
  Vector inside of loop cost: 32
  Vector prologue cost: 1033
  Vector epilogue cost: 0
  Scalar iteration cost: 64
  Scalar outside cost: 1
  Vector outside cost: 1033
  prologue iterations: 0
  epilogue iterations: 0
  Calculated minimum iters for profitability: 33

Trunk starts to get this right again after r228751 . I had a look at
backporting that patch but it uses some of the new hash-table stuff so it won't
be a trivial backport.

slp-costs.c:7:3: note: Cost model analysis: 
  Vector inside of loop cost: 32
  Vector prologue cost: 10
  Vector epilogue cost: 0
  Scalar iteration cost: 64
  Scalar outside cost: 1
  Vector outside cost: 10
  prologue iterations: 0
  epilogue iterations: 0
  Calculated minimum iters for profitability: 1
slp-costs.c:7:3: note:   Runtime profitability threshold = 0

[Bug fortran/68237] ICE on invalid with submodules

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2015-11-06
 CC||pault at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Which revision are you using (gfortran -v). I get

pr68237.f90:4:13:

 submodule (m1) m2
 1
Fatal Error: Can't open module file 'm1.smod' for reading at (1): No such file
or directory
compilation terminated.

with revision r229438 (2015-10-27) or more recent.

[Bug fortran/68237] ICE on invalid with submodules

[mar...@mpa-garching.mpg.de]

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

--- Comment #2 from Martin Reinecke <mar...@mpa-garching.mpg.de> ---
I'm using

gcc version 6.0.0 20151106 (experimental) [trunk revision
2aebc1a:abfaa95:74905ec39301718edde3609ddd97ef8e0f9eb934] (GCC)

[Bug fortran/68237] ICE on invalid with submodules

[mar...@mpa-garching.mpg.de]

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

--- Comment #3 from Martin Reinecke  ---
Sorry, I update my sources via git... I hope this still helps.

[Bug bootstrap/68231] [6 Regression] bootstrap failure after placement new

[dje at gcc dot gnu.org]

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

--- Comment #6 from David Edelsohn  ---
This seems to be fixed after Martin's second patch.  Although the placement new
size test in the testsuite fails on AIX.

[Bug tree-optimization/65963] Missed vectorization of loads strided with << when equivalent * succeeds

[alalaw01 at gcc dot gnu.org]

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

--- Comment #4 from alalaw01 at gcc dot gnu.org ---
I confirm the testcase fails execution on armeb-none-eabi (also at -O0), but it
does so both with and without the patch to tree-scalar-evolution.c, which did
not change codegen (at -O2 -ftree-vectorize; the loop was not vectorized). So
this looks to be exposing a different, pre-existing, bug.

[Bug debug/68229] .debug_pubnames length field is too large

[todd.allen at ccur dot com]

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

--- Comment #4 from Todd Allen  ---
It appears to have been fixed in gcc-4.9.0 by Sterling Augustine, 2013-07-25,
with the new include_pubname_in_output function.  I don't have a 4.9.0
compiler, but I did test it with gcc-4.9.2 on Fedora 21, and that worked.  I'll
take up the issue with RedHat, since it's RHEL 7.0 that provides gcc-4.8.x
still.

[Bug fortran/68237] ICE on invalid with submodules

[pault at gcc dot gnu.org]

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

--- Comment #4 from Paul Thomas  ---
(In reply to Dominique d'Humieres from comment #1)
> Which revision are you using (gfortran -v). I get
> 
> pr68237.f90:4:13:
> 
>  submodule (m1) m2
>  1
> Fatal Error: Can't open module file 'm1.smod' for reading at (1): No such
> file or directory
> compilation terminated.
> 
> with revision r229438 (2015-10-27) or more recent.

I get the same us Dominique with GNU Fortran (GCC) 6.0.0 20151030
(experimental) I'll update my tree tonight.

Cheers

Paul

[Bug fortran/68237] ICE on invalid with submodules

[dominiq at lps dot ens.fr]

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

--- Comment #5 from Dominique d'Humieres  ---
I still get the error with revision r229832 (2015-11-06).

> gcc version 6.0.0 20151106 (experimental) [trunk revision
> 2aebc1a:abfaa95:74905ec39301718edde3609ddd97ef8e0f9eb934] (GCC)

exactly why I don't like git!-(

[Bug bootstrap/68231] [6 Regression] bootstrap failure after placement new

[dominiq at lps dot ens.fr]

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

--- Comment #7 from Dominique d'Humieres  ---
Note that bootstrap fails also with

../../work/gcc/cp/init.c: In function 'void warn_placement_new_too_small(tree,
tree, tree, tree)':
  ../../work/gcc/cp/init.c:2454:17: error: format '%lu' expects
argument of type 'long unsigned int', but argument 5 has type 'long long
unsigned int' [-Werror=format=]
bytes_avail);
   ^
at r229827, see the mess at https://gcc.gnu.org/ml/gcc-regression/2015-11/.

[Bug fortran/68216] [F2003] IO problem with allocatable, deferred character length arrays

[dominiq at lps dot ens.fr]

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

--- Comment #6 from Dominique d'Humieres  ---
> Paul, I'm delighted than someone is finally working on this long-standing
> problem.

Seconded!

> I hope you're also taking a look at all the other related PRs that Dominique
> pointed out; I suspect that they all share the same core error.  -Neil

Well, don't hope too much! If I had found obvious duplicates, I'ld say so
(besides pr55735 appearing twice after correction and this PR being probably a
duplicate of pr50221).

[Bug fortran/68237] ICE on invalid with submodules

[mar...@mpa-garching.mpg.de]

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

--- Comment #6 from Martin Reinecke  ---
Ah, my bad ... I still had an old m1.smod lying on disk from earlier tests!

This slightly changed test case should demonstrate the problem:

module m1

interface
module subroutine bar
end subroutine
end interface
end module m1

submodule (m1) m2

contains

module procedure foo
end procedure

end submodule

[Bug c++/67942] diagnose placement new buffer overflow

[msebor at gcc dot gnu.org]

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

--- Comment #6 from Martin Sebor  ---
Author: msebor
Date: Fri Nov  6 15:42:41 2015
New Revision: 229857

URL: https://gcc.gnu.org/viewcvs?rev=229857=gcc=rev
Log:
Correct entry for PR c++/67942.

Modified:
trunk/gcc/ChangeLog

[Bug fortran/50221] Allocatable string length fails with array assignment

[dominiq at lps dot ens.fr]

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

--- Comment #5 from Dominique d'Humieres  ---
Note that the output for comment 0 is

 array=xxyyzz   2   3

when compiled with 

Using built-in specs.
COLLECT_GCC=/opt/gcc/gcc6a-222042/bin/gfortran
COLLECT_LTO_WRAPPER=/opt/gcc/gcc6a-222042/bin/../libexec/gcc/x86_64-apple-darwin14.3.0/6.0.0/lto-wrapper
Target: x86_64-apple-darwin14.3.0
Configured with: ../_clean/configure --prefix=/opt/gcc/gcc6a
--enable-languages=c,c++,fortran,ada,lto --with-gmp=/opt/mp-new
--with-system-zlib --enable-checking=release --with-isl=/opt/mp-new
--enable-lto --enable-plugin
Thread model: posix
gcc version 6.0.0 20150413 (experimental) [trunk revision 222042] (GCC) 

and

Using built-in specs.
COLLECT_GCC=/opt/gcc/gcc6p-227742/bin/gfortran
COLLECT_LTO_WRAPPER=/opt/gcc/gcc6p-227742/libexec/gcc/x86_64-apple-darwin14.5.0/6.0.0/lto-wrapper
Target: x86_64-apple-darwin14.5.0
Configured with: ../p_work/configure --prefix=/opt/gcc/gcc6p-227742
--enable-languages=c,c++,lto,fortran,ada,objc,obj-c++ --with-gmp=/opt/mp-new
--with-system-zlib --enable-checking=release --with-isl=/opt/mp-new
--enable-lto --enable-plugin --with-arch=core2 --with-cpu=core2
Thread model: posix
gcc version 6.0.0 20150914 (experimental) [trunk revision 227742] (GCC) 

I still get the wrong output 'array=zz' with

[Book15] f90/bug% /opt/gcc/gcc6p-226431/bin/gfortran -v
Using built-in specs.
COLLECT_GCC=/opt/gcc/gcc6p-226431/bin/gfortran
COLLECT_LTO_WRAPPER=/opt/gcc/gcc6p-226431/libexec/gcc/x86_64-apple-darwin14.4.0/6.0.0/lto-wrapper
Target: x86_64-apple-darwin14.4.0
Configured with: ../p_work/configure --prefix=/opt/gcc/gcc6p-226431
--enable-languages=c,c++,lto,fortran,ada,objc,obj-c++ --with-gmp=/opt/mp-new
--with-system-zlib --enable-checking=release --with-isl=/opt/mp-new
--enable-lto --enable-plugin --with-arch=core2 --with-cpu=core2
Thread model: posix
gcc version 6.0.0 20150731 (experimental) [trunk revision 226431] (GCC) 

However for all versions I have tested I get a wrong output (depending on the
revision) for the test in comment 4.

[Bug fortran/68237] ICE on invalid with submodules

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #7 from Dominique d'Humieres  ---
> This slightly changed test case should demonstrate the problem:

Confirmed, the backtrace is

Program received signal SIGSEGV, Segmentation fault.
0x0001000288c7 in gfc_match_submod_proc () at
../../work/gcc/fortran/decl.c:7649
7649  if (sym->ts.interface->attr.function)
(gdb) bt
#0  0x0001000288c7 in gfc_match_submod_proc () at
../../work/gcc/fortran/decl.c:7649
#1  0x000100082e8d in decode_statement () at
../../work/gcc/fortran/parse.c:384
#2  0x000100084bc5 in next_statement () at
../../work/gcc/fortran/parse.c:1075
#3  0x00010008b0f4 in parse_contained (module=) at
../../work/gcc/fortran/parse.c:4990
#4  0x00010008c1df in parse_module () at
../../work/gcc/fortran/parse.c:5390
#5  0x00010008cc43 in gfc_parse_file () at
../../work/gcc/fortran/parse.c:5696
#6  0x0001000d39db in gfc_be_parse_file () at
../../work/gcc/fortran/f95-lang.c:205
#7  0x000100aec62a in compile_file () at ../../work/gcc/toplev.c:466
#8  0x000100fc173c in ?? ()
#9  0x000100fc30f9 in main (argc=2, argv=0x7fff5fbff308) at
../../work/gcc/main.c:39

[Bug bootstrap/68231] [6 Regression] bootstrap failure after placement new

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #8 from Martin Sebor  ---
The first problem was fixed in a subsequent patch committed in r229831.
The -Wformat issue was subsequently fixed in r229849.
I'm looking into the excess testsuite failures on ILP32.

[Bug ipa/68057] [6 Regression] 450.soplex in SPEC CPU 2006 failed to build

[hubicka at gcc dot gnu.org]

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

--- Comment #11 from Jan Hubicka  ---
Author: hubicka
Date: Fri Nov  6 16:04:38 2015
New Revision: 229859

URL: https://gcc.gnu.org/viewcvs?rev=229859=gcc=rev
Log:

PR ipa/68057
PR ipa/68220
* ipa-polymorphic-call.c
(ipa_polymorphic_call_context::restrict_to_inner_type): Fix ordering
issue when offset is out of range.
(contains_type_p): Fix out of range check, clear dynamic flag.
* g++.dg/lto/pr68057_0.C: New testcase.
* g++.dg/lto/pr68057_1.C: New testcase.
* g++.dg/torture/pr68220.C: New testcase.

Added:
trunk/gcc/testsuite/g++.dg/lto/pr68057_0.C
trunk/gcc/testsuite/g++.dg/lto/pr68057_1.C
trunk/gcc/testsuite/g++.dg/torture/pr68220.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/ipa-polymorphic-call.c
trunk/gcc/testsuite/ChangeLog

[Bug ipa/68220] [5/6 Regression] Devirtualization ICE in record_target_from_binfo, at ipa-devirt.c:2389

[hubicka at gcc dot gnu.org]

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

--- Comment #6 from Jan Hubicka  ---
Author: hubicka
Date: Fri Nov  6 16:04:38 2015
New Revision: 229859

URL: https://gcc.gnu.org/viewcvs?rev=229859=gcc=rev
Log:

PR ipa/68057
PR ipa/68220
* ipa-polymorphic-call.c
(ipa_polymorphic_call_context::restrict_to_inner_type): Fix ordering
issue when offset is out of range.
(contains_type_p): Fix out of range check, clear dynamic flag.
* g++.dg/lto/pr68057_0.C: New testcase.
* g++.dg/lto/pr68057_1.C: New testcase.
* g++.dg/torture/pr68220.C: New testcase.

Added:
trunk/gcc/testsuite/g++.dg/lto/pr68057_0.C
trunk/gcc/testsuite/g++.dg/lto/pr68057_1.C
trunk/gcc/testsuite/g++.dg/torture/pr68220.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/ipa-polymorphic-call.c
trunk/gcc/testsuite/ChangeLog

[Bug ipa/68057] [6 Regression] 450.soplex in SPEC CPU 2006 failed to build

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

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

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

[Bug ipa/67056] [5 regression] Wrong code generated

[hubicka at gcc dot gnu.org]

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

Bug 68057 Summary: [6 Regression] 450.soplex in SPEC CPU 2006 failed to build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68057

   What|Removed |Added

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

[Bug ipa/68220] [5 Regression] Devirtualization ICE in record_target_from_binfo, at ipa-devirt.c:2389

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

Summary|[5/6 Regression]|[5 Regression]
   |Devirtualization ICE in |Devirtualization ICE in
   |record_target_from_binfo,   |record_target_from_binfo,
   |at ipa-devirt.c:2389|at ipa-devirt.c:2389

--- Comment #7 from Jan Hubicka  ---
Fixed on trunk so far.

[Bug tree-optimization/65419] incorrect sibcalls to libgomp functions

[vries at gcc dot gnu.org]

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

--- Comment #17 from vries at gcc dot gnu.org ---
Author: vries
Date: Fri Nov  6 11:48:06 2015
New Revision: 229843

URL: https://gcc.gnu.org/viewcvs?rev=229843=gcc=rev
Log:
Revert "Add IFN_GOACC_DATA_END_WITH_ARG"

2015-11-06  Tom de Vries  

revert:
2015-05-28  Tom de Vries  

PR tree-optimization/65419
* cfgexpand.c (pass_data_expand): Add PROP_gimple_lompifn to
properties_required field.
* gimplify.c (gimplify_omp_workshare): Use IFN_GOACC_DATA_END_WITH_ARG
instead of BUILT_IN_GOACC_DATA_END.  Clear PROP_gimple_lompifn in
curr_properties.
(gimplify_function_tree): Tentatively set PROP_gimple_lompifn in
curr_properties.
* internal-fn.c (expand_GOACC_DATA_END_WITH_ARG): New dummy function.
* internal-fn.def (GOACC_DATA_END_WITH_ARG): New DEF_INTERNAL_FN.
* omp-low.c (lower_omp_target): Set argument of
GOACC_DATA_END_WITH_ARG.
(pass_data_late_lower_omp): New pass_data.
(pass_late_lower_omp): New pass.
(pass_late_lower_omp::gate, pass_late_lower_omp::execute)
(make_pass_late_lower_omp): New function.
* passes.def: Add pass_late_lower_omp.
* tree-inline.c (expand_call_inline): Handle PROP_gimple_lompifn.
* tree-pass.h (PROP_gimple_lompifn): Add define.

* testsuite/libgomp.oacc-c-c++-common/goacc-data-end.c: New test.

Removed:
   
branches/gomp-4_0-branch/libgomp/testsuite/libgomp.oacc-c-c++-common/goacc-data-end.c
Modified:
branches/gomp-4_0-branch/gcc/ChangeLog.gomp
branches/gomp-4_0-branch/gcc/cfgexpand.c
branches/gomp-4_0-branch/gcc/gimplify.c
branches/gomp-4_0-branch/gcc/internal-fn.c
branches/gomp-4_0-branch/gcc/internal-fn.def
branches/gomp-4_0-branch/gcc/omp-low.c
branches/gomp-4_0-branch/gcc/passes.def
branches/gomp-4_0-branch/gcc/tree-inline.c
branches/gomp-4_0-branch/gcc/tree-pass.h
branches/gomp-4_0-branch/libgomp/ChangeLog.gomp

[Bug fortran/37513] Misleading error for (invalid) protected_pointer => unprotected_pointer

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #3 from Dominique d'Humieres  ---
Since version 4.6.4, the error is

   protected_pointer => unprotected_pointer
  1
Error: Variable 'protected_pointer' is PROTECTED and can not appear in a
pointer association context (pointer assignment) at (1)

This is tested by gfortran.dg/protected_8.f90 (r165883, pr46122). Closing as
FIXED.

[Bug tree-optimization/68145] [6 Regression] ICE: in vectorizable_store, at tree-vect-stmts.c:5684

[ienkovich at gcc dot gnu.org]

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

--- Comment #3 from Ilya Enkovich  ---
Author: ienkovich
Date: Fri Nov  6 13:31:51 2015
New Revision: 229848

URL: https://gcc.gnu.org/viewcvs?rev=229848=gcc=rev
Log:
gcc/

PR tree-optimization/68145
* tree-vect-stmts.c (vectorizable_operation): Fix
determination for booleans.

gcc/testsuite/

PR tree-optimization/68145
* g++.dg/vect/pr68145.cc: New test.

Added:
trunk/gcc/testsuite/g++.dg/vect/pr68145.cc
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vect-stmts.c

[Bug rtl-optimization/68106] c-c++-common/torture/builtin-arith-overflow-11.c FAILs with -flra-remat @ aarch64

[vmakarov at gcc dot gnu.org]

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

--- Comment #4 from Vladimir Makarov  ---
Author: vmakarov
Date: Fri Nov  6 17:33:01 2015
New Revision: 229868

URL: https://gcc.gnu.org/viewcvs?rev=229868=gcc=rev
Log:
2015-11-06  Vladimir Makarov  

PR rtl-optimization/68106
* lra-remat.c (input_regno_present_p): Process hard regs
explicitly present in machine description insns.
(call_used_input_regno_present_p): Ditto.
(calculate_gen_cands): Ditto.
(do_remat): Ditto.

2015-11-06  Vladimir Makarov  

PR rtl-optimization/68106
* testsuite/gcc.target/aarch64/pr68106.c: New.


Added:
branches/gcc-5-branch/gcc/testsuite/gcc.target/aarch64/pr68106.c
Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/lra-remat.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug lto/67709] ICE: in estimate_function_body_sizes, at ipa-inline-analysis.c:2489 on x86_64-apple-darwin*

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-11-06
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
See also https://gcc.gnu.org/ml/gcc-testresults/2015-11/msg00521.html.

[Bug target/68236] New: [6 Regression] selective scheduling with --param=sched-autopref-queue-depth=10 ICEs a lot @ aarch64

[zsojka at seznam dot cz]

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

Bug ID: 68236
   Summary: [6 Regression] selective scheduling with
--param=sched-autopref-queue-depth=10 ICEs a lot @
aarch64
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---

Created attachment 36662
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36662=edit
testcase

Compiler output:
$ cc1 930506-2.c -Os -fselective-scheduling2
--param=sched-autopref-queue-depth=10
 f1 ___
930506-2.c: In function '___':
930506-2.c:4:17: warning: implicit declaration of function 'foo'
[-Wimplicit-function-declaration]
   { int ___() { foo(1); } bar(___); }
 ^
930506-2.c: In function 'f1':
930506-2.c:4:27: warning: implicit declaration of function 'bar'
[-Wimplicit-function-declaration]
   { int ___() { foo(1); } bar(___); }
   ^
 ___ f2 ___ ___
Analyzing compilation unit
Performing interprocedural optimizations
 <*free_lang_data>   
 

Assembling functions:
  ___ ___ ___ ___ f1 f2
930506-2.c: In function 'f2':
930506-2.c:12:1: internal compiler error: RTL check: expected elt 0 type 'e' or
'u', have '1' (rtx fA}) in insn, at rtl.h:1352
 }
 ^
0xa97126 rtl_check_failed_type2(rtx_def const*, int, int, int, char const*,
int, char const*)
/repo/gcc-trunk/gcc/rtl.c:802
0x562fb1 rtx_insn_list::insn() const
/repo/gcc-trunk/gcc/rtl.h:1352
0x111707c rtx_insn_list::insn() const
/repo/gcc-trunk/gcc/rtl.h:1352
0x111707c autopref_multipass_dfa_lookahead_guard(rtx_insn*, int)
/repo/gcc-trunk/gcc/haifa-sched.c:5879
0xad7afa invoke_dfa_lookahead_guard
/repo/gcc-trunk/gcc/sel-sched.c:4175
0xad7afa find_best_expr
/repo/gcc-trunk/gcc/sel-sched.c:4378
0xad7afa fill_insns
/repo/gcc-trunk/gcc/sel-sched.c:5523
0xad889d schedule_on_fences
/repo/gcc-trunk/gcc/sel-sched.c:7342
0xad889d sel_sched_region_2
/repo/gcc-trunk/gcc/sel-sched.c:7480
0xad9b3b sel_sched_region_1
/repo/gcc-trunk/gcc/sel-sched.c:7522
0xad9b3b sel_sched_region(int)
/repo/gcc-trunk/gcc/sel-sched.c:7623
0xadb049 run_selective_scheduling()
/repo/gcc-trunk/gcc/sel-sched.c:7699
0xab4865 rest_of_handle_sched2
/repo/gcc-trunk/gcc/sched-rgn.c:3625
0xab4865 execute
/repo/gcc-trunk/gcc/sched-rgn.c:3769
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.


$ xgcc -v
Using built-in specs.
COLLECT_GCC=/repo/build-trunk-229712-checking-yes-rtl-df-nographite-aarch64/gcc/xgcc
Target: aarch64-unknown-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-checking=yes,rtl,df --without-cloog --without-ppl --without-isl
--build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
--target=aarch64-unknown-linux-gnu
--with-ld=/usr/bin/aarch64-unknown-linux-gnu-ld
--with-as=/usr/bin/aarch64-unknown-linux-gnu-as --with-sysroot=/chroot/aarch64
--disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-229712-checking-yes-rtl-df-nographite-aarch64
Thread model: posix
gcc version 6.0.0 20151103 (experimental) (GCC) 


Running the whole (C and C++ testsuite) with:
make -k check
RUNTESTFLAGS="--target_board=unix/-fselective-scheduling/-fselective-scheduling2/--param=sched-autopref-queue-depth=10"
results in many ICEs:

$ find . -name '*.log' | grep -v 'config[.]log' | xargs grep '[Ii]nternal
compiler error:' | grep -v ':FAIL:' | grep -v /pch/ | tr -d '\r' | cut -f5- -d:
| sort | uniq -c | sort -n
  2  internal compiler error: RTL check: expected elt 0 type 'e' or 'u',
have 'A' (rtx [¸) in insn, at rtl.h:1352
  2  internal compiler error: RTL check: expected elt 0 type 'e' or 'u',
have 'L' (rtx 1ÀéÁïÿÿLL$`MøLáLòHÞHïèðÅ) in insn, at rtl.h:1352
  3  internal compiler error: RTL check: expected elt 0 type 'e' or 'u',
have 'w' (rtx const_int) in insn, at rtl.h:1352
  3  internal compiler error: Segmentation fault
  3  internal compiler error: RTL check: access of elt 0 of 'return' with
last elt -1 in insn, at rtl.h:1352
  3  internal compiler error: RTL check: access of elt 1 of 'use' with last
elt 0 in next, at rtl.h:1346
  3  internal compiler error: RTL check: expected elt 0 type 'e' or 'u',
have '1' (rtx J¯§) in insn, at rtl.h:1352
  3  internal compiler error: RTL check: expected elt 0 type 'e' or 'u',
have 'H' (rtx ¸h) in insn, at rtl.h:1352
  3  internal compiler error: RTL check: expected elt 0 type 'e' or 'u',
have '¸' (rtx ¸6) in insn, at rtl.h:1352
  6  internal compiler error: in safe_as_a, at is-a.h:205
  6  internal compiler error: RTL check: expected elt 0 type 'e' or 'u',
have '0' (rtx value) in 

[Bug bootstrap/68231] [6 Regression] bootstrap failure after placement new

[uweigand at gcc dot gnu.org]

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

Ulrich Weigand  changed:

   What|Removed |Added

 CC||uweigand at gcc dot gnu.org

--- Comment #5 from Ulrich Weigand  ---
Same on spu-elf.

[Bug debug/66728] [5/6 Regression] CONST_WIDE_INT causes corrupted DWARF debug info

[mrs at gcc dot gnu.org]

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

--- Comment #8 from mrs at gcc dot gnu.org  ---
Author: mrs
Date: Fri Nov  6 20:16:06 2015
New Revision: 229885

URL: https://gcc.gnu.org/viewcvs?rev=229885=gcc=rev
Log:
PR debug/66728
* dwarf2out.c (get_full_len): Return a value based upon the actual
precision needed for the value.
(add_const_value_attribute): Use a maximal wide-int for
CONST_WIDE_INTs, not VOIDmode.
(output_die): Don't ever output NULL with printf.

* rtl.h (get_precision of rtx_mode_t): Ensure we never process
BLKmode nor VOIDmode values.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/dwarf2out.c
trunk/gcc/rtl.h

[Bug tree-optimization/68240] New: compilation hangs on valid code at -O1 and above on x86_64-linux-gnu

[su at cs dot ucdavis.edu]

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

Bug ID: 68240
   Summary: compilation hangs on valid code at -O1 and above on
x86_64-linux-gnu
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

The following code causes the current gcc trunk to hang at -O1 and above on
x86_64-linux-gnu in both 32-bit and 64-bit modes. 

This is a regression from 5.2.x. 


$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/6.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --prefix=/usr/local/gcc-trunk
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 6.0.0 20151105 (experimental) [trunk revision 229809] (GCC) 
$ 
$ gcc-trunk -O0 -c small.c
$ gcc-5.2 -O1 -c small.c
$ 
$ timeout -s 9 60 gcc-trunk -O1 -c small.c
Killed
$ 


-


int a, b, f;

void
fn1 ()
{
  int c = 1, d, e = 1;
  a = 1; 
  for (; f;)
b = (c && (d = (e && a)));
}

[Bug other/68239] New: libbacktrace allocation is sometimes very slow

[wtt6 at cornell dot edu]

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

Bug ID: 68239
   Summary: libbacktrace allocation is sometimes very slow
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wtt6 at cornell dot edu
  Target Milestone: ---

From https://github.com/rust-lang/rust/issues/29293

In the Rust project, we are encountering cases where libbacktrace spends about
a second performing the actual work of generating a backtrace and about a
minute managing its memory allocator (absolute times are machine-dependent,
obviously).  The problem appears to be that the linked list of freed
allocations available for reuse ends up containing tens of thousands of entries
that are all too small to satisfy most (all?) allocation requests, and the
allocator loops over and tests all of them before deciding to mmap more memory.

[Bug target/63304] Aarch64 pc-relative load offset out of range

[ramana at gcc dot gnu.org]

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

--- Comment #31 from Ramana Radhakrishnan  ---
(In reply to Evandro from comment #30)
> The performance impact of always referring to constants as if they were far
> away is significant on targets which do not fuse ADRP and LDR together. 

What happens if you split them up and schedule them appropriately ? I didn't
see any significant impact in my benchmarking on implementations that did not
implement such fusion. Where people want performance in these cases they can
well use -mpc-relative-literal-loads or -mcmodel=tiny - it's in there already.

> What's the status of the solution that evaluates the function size? 

I am not working on that follow-up as I didn't see the real need for it in the
benchmarking results I was looking at. You are welcome to investigate.

> Should
> this be optionally enabled only?  

It is enabled by default for -mcmodel=small and -mcmodel=large. 

And no because it has been done after quite a lot of complaints from the
general user community that people are unable to build large software bases
with the compiler.

> Could the assembler be left to address this issue by
> relaxing such loads? :-P  

No...

[Bug target/63304] Aarch64 pc-relative load offset out of range

[wdijkstr at arm dot com]

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

--- Comment #33 from Wilco  ---
(In reply to Evandro from comment #32)
> (In reply to Ramana Radhakrishnan from comment #31)
> > (In reply to Evandro from comment #30)
> > > The performance impact of always referring to constants as if they were 
> > > far
> > > away is significant on targets which do not fuse ADRP and LDR together. 
> > 
> > What happens if you split them up and schedule them appropriately ? I didn't
> > see any significant impact in my benchmarking on implementations that did
> > not implement such fusion. Where people want performance in these cases they
> > can well use -mpc-relative-literal-loads or -mcmodel=tiny - it's in there
> > already.
> 
> Because of side effects of the Haiffa scheduler, the loads now pile up, and
> the ADRPs may affect the load issue rate rather badly if not fused.  At leas
> on our processor.  

ADRP latency to load-address should be zero on any OoO core - ADRP is basically
a move-immediate, so can execute early and hide any latency.

> Which brings another point, shouldn't there be just one ADRP per BB or,
> ideally, per function?  Or am I missing something?

That's not possible in this case as the section is mergeable. An alternative
implementation using anchors may be feasible, but GCC is extremely bad at using
anchors efficiently - functions using several global variables also end up with
a large number of ADRPs when you'd expect a single ADRP.

[Bug target/63304] Aarch64 pc-relative load offset out of range

[e.menezes at samsung dot com]

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

--- Comment #32 from Evandro  ---
(In reply to Ramana Radhakrishnan from comment #31)
> (In reply to Evandro from comment #30)
> > The performance impact of always referring to constants as if they were far
> > away is significant on targets which do not fuse ADRP and LDR together. 
> 
> What happens if you split them up and schedule them appropriately ? I didn't
> see any significant impact in my benchmarking on implementations that did
> not implement such fusion. Where people want performance in these cases they
> can well use -mpc-relative-literal-loads or -mcmodel=tiny - it's in there
> already.

Because of side effects of the Haiffa scheduler, the loads now pile up, and the
ADRPs may affect the load issue rate rather badly if not fused.  At leas on our
processor.  

Which brings another point, shouldn't there be just one ADRP per BB or,
ideally, per function?  Or am I missing something?

> > What's the status of the solution that evaluates the function size? 
> 
> I am not working on that follow-up as I didn't see the real need for it in
> the benchmarking results I was looking at. You are welcome to investigate.

OK

[Bug target/68088] [6 Regression] ICE: RTL check: expected code 'reg', have 'subreg' in rhs_regno, at rtl.h:1782 @ aarch64

[ktkachov at gcc dot gnu.org]

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

--- Comment #4 from ktkachov at gcc dot gnu.org ---
Author: ktkachov
Date: Fri Nov  6 12:04:15 2015
New Revision: 229845

URL: https://gcc.gnu.org/viewcvs?rev=229845=gcc=rev
Log:
[ARM/AArch64] PR 68088: Fix RTL checking ICE due to subregs inside accumulator
forwarding check

PR target/68088
* config/arm/aarch-common.c (aarch_accumulator_forwarding): Strip
subregs from accumulator and make sure it's a register.

* gcc.dg/pr68088_1.c: New test.


Added:
trunk/gcc/testsuite/gcc.dg/pr68088_1.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/arm/aarch-common.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/44491] Diagnostic just shows "" instead of a locus

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #4 from Dominique d'Humieres  ---
Compiling the test in comment 0 with 5.2.0 or trunk gives an ICE

in gfc_format_decoder, at fortran/error.c:936

Internal compiler error: Error reporting routines re-entered.

or

(null):0: confused by earlier errors, bailing out

for builds configure with --enable-checking=release.

The change occurred between revisions r218570 (2014-12-10, error) and r218658
(2014-12-12, ICE), likely the changes for pr44054.

[Bug rtl-optimization/67753] [6 Regression] FAIL: cxg1005, cxg2002, cxg2006, cxg2007, cxg2008, cxg2018, cxg2019 and cxg2020

[aoliva at gcc dot gnu.org]

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

Alexandre Oliva  changed:

   What|Removed |Added

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

--- Comment #7 from Alexandre Oliva  ---
Assuming fixed.  Please reopen otherwise.

[Bug rtl-optimization/64164] [4.9/5/6 Regression] one more stack slot used due to one less inlining level

[aoliva at gcc dot gnu.org]

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

Bug 67753 Summary: [6 Regression] FAIL: cxg1005, cxg2002, cxg2006, cxg2007, 
cxg2008, cxg2018, cxg2019 and cxg2020
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67753

   What|Removed |Added

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

[Bug target/68088] [6 Regression] ICE: RTL check: expected code 'reg', have 'subreg' in rhs_regno, at rtl.h:1782 @ aarch64

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 CC||ktkachov at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #5 from ktkachov at gcc dot gnu.org ---
Fixed on trunk.

[Bug fortran/55099] Surprising but valid 'PROCEDURE attribute conflicts with INTENT attribute' error

[Joost.VandeVondele at mat dot ethz.ch]

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

--- Comment #5 from Joost VandeVondele  
---
(In reply to Dominique d'Humieres from comment #4)
> Improving the message will be quite trivial once an agreement is found about
> the improvement. Would the addition of "This name has not been declared as
> an array or a function." be OK? Can someone find a better one?

 ‘num_proc_2d’ has not been declared as an array or a function.

would indeed be close to what ifort provides, and I think is an improvement.

[Bug middle-end/68221] libgomp reduction-11/12 failures

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
I don't have any testcase that would exhibit a problem with variable low-bound,
but that is not a proof there isn't a problem.

Trying:
typedef __UINTPTR_TYPE__ uintptr_t;
void bar (unsigned short *, unsigned short *);

int
foo (int x, int y, int z)
{
  unsigned short a[10], b[10];
  bar (a, b);
  uintptr_t ai = (uintptr_t) a;
  uintptr_t bi = (uintptr_t) b;
  ai -= 16;
  bi -= x;
  unsigned short *ap = (unsigned short *) ai;
  unsigned short *bp = (unsigned short *) bi;
  return ap[19] + bp[19] + ap[y] + bp[z];
}
reveals that we don't fold this and therefore it isn't a problem.  So perhaps I
just should go through that way internally on the omp-low.c side.

[Bug fortran/31560] improve error message for using components of later decl. variables in specification expressions

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|NEW |WAITING

--- Comment #10 from Dominique d'Humieres  ---
The error for the test in comment 8 is now (from 4.8 up to trunk 6.0)

pr31560_1.f90:6:29:

   integer, dimension(dataset%maxsiz) :: nobs
 1
Error: Symbol 'dataset' at (1) has no IMPLICIT type

Is there any hope to emit an error of the kind "used before it is defined"? or
should this PR closed as FIXED?

[Bug target/68236] [6 Regression] selective scheduling with --param=sched-autopref-queue-depth=10 ICEs a lot @ aarch64

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-11-06
 CC||ktkachov at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from ktkachov at gcc dot gnu.org ---
Confirmed

[Bug target/63304] Aarch64 pc-relative load offset out of range

[e.menezes at samsung dot com]

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

--- Comment #34 from Evandro  ---
(In reply to Wilco from comment #33)
> (In reply to Evandro from comment #32)
> ADRP latency to load-address should be zero on any OoO core - ADRP is
> basically a move-immediate, so can execute early and hide any latency.

In an ideal world, yes.  In the actual world, they compete for limited
resources that could be used by other insns.

> > Which brings another point, shouldn't there be just one ADRP per BB or,
> > ideally, per function?  Or am I missing something?
> 
> That's not possible in this case as the section is mergeable. An alternative
> implementation using anchors may be feasible, but GCC is extremely bad at
> using anchors efficiently - functions using several global variables also
> end up with a large number of ADRPs when you'd expect a single ADRP.

I see.  

I'll investigate placing the constant after the function, as before, if the
estimated function size allows for it.  I think that eliminating the ADRPs
could potentially be more beneficial to code size than merging constants in a
common literal pool (v. http://bit.ly/1Ptc8nh).

Thank you.

[Bug debug/66728] [5/6 Regression] CONST_WIDE_INT causes corrupted DWARF debug info

[mrs at gcc dot gnu.org]

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

mrs at gcc dot gnu.org  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 CC||mrs at gcc dot gnu.org
  Known to work||6.0
 Resolution|--- |FIXED

--- Comment #9 from mrs at gcc dot gnu.org  ---
Fixed.

[Bug fortran/54224] Warn for unused internal procedures

[dominiq at gcc dot gnu.org]

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

--- Comment #31 from dominiq at gcc dot gnu.org ---
Author: dominiq
Date: Fri Nov  6 21:49:18 2015
New Revision: 229894

URL: https://gcc.gnu.org/viewcvs?rev=229894=gcc=rev
Log:
2015-11-06  Dominique d'Humieres 

PR fortran/54224
* gfortran.dg/warn_unused_function_2.f90: Add two new 
"defined but not used" subroutines.


Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/warn_unused_function_2.f90

[Bug fortran/54224] Warn for unused internal procedures

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #32 from Dominique d'Humieres  ---
Patch committed and column position tracked by pr63327. Closing as FIXED.

[Bug fortran/54221] [4.8/4.9 Regression] Explicit private access specifier signals "unexpected defined but not used [-Wunused-function]" warning

[dominiq at lps dot ens.fr]

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

Bug 54224 Summary: Warn for unused internal procedures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54224

   What|Removed |Added

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

[Bug fortran/68241] New: [meta-bug] Deferred-length character

[dominiq at lps dot ens.fr]

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

Bug ID: 68241
   Summary: [meta-bug] Deferred-length character
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dominiq at lps dot ens.fr
  Target Milestone: ---

This meta-bug is opened to track deferred-length character issues.

[Bug target/63304] Aarch64 pc-relative load offset out of range

[ramana at gcc dot gnu.org]

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

--- Comment #35 from Ramana Radhakrishnan  ---
(In reply to Evandro from comment #32)
> (In reply to Ramana Radhakrishnan from comment #31)
> > (In reply to Evandro from comment #30)
> > > The performance impact of always referring to constants as if they were 
> > > far
> > > away is significant on targets which do not fuse ADRP and LDR together. 
> > 
> > What happens if you split them up and schedule them appropriately ? I didn't
> > see any significant impact in my benchmarking on implementations that did
> > not implement such fusion. Where people want performance in these cases they
> > can well use -mpc-relative-literal-loads or -mcmodel=tiny - it's in there
> > already.
> 
> Because of side effects of the Haiffa scheduler, the loads now pile up, and
> the ADRPs may affect the load issue rate rather badly if not fused.  At leas
> on our processor.  

In straight line code I can imagine this happening - In loopy code I would have
expected the constants to be hoisted - atleast that's what I remember seeing in
my analysis. You have seen -mcprelative-literal-loads haven't you ? 

> 
> Which brings another point, shouldn't there be just one ADRP per BB or,
> ideally, per function?  Or am I missing something?

That isn't really how this thing works. Well the constants are shared across
the program now as you say down thread. 

> 
> I'll investigate placing the constant after the function, as before, if the
> estimated function size allows for it.  I think that eliminating the ADRPs
> could potentially be more beneficial to code size than merging constants in
> a common literal pool (v. http://bit.ly/1Ptc8nh).

I was actually surprised by the amount of constant sharing that was happening
in what I looked at. 


Thanks,
Ramana

[Bug fortran/68241] [meta-bug] Deferred-length character

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-11-06
 Ever confirmed|0   |1