[Bug c++/69901] Iniitializing non-const global array variable from runtime const global variable does not copy all values properly

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|FIXED   |DUPLICATE

--- Comment #5 from Andrew Pinski  ---
And yes it is a dup of bug 67550.

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

[Bug c++/67550] [5/6 regression] Initialization of local struct array with elements of global array yields zeros instead of initializer values

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||piotrwn1 at gmail dot com

--- Comment #13 from Andrew Pinski  ---
*** Bug 69901 has been marked as a duplicate of this bug. ***

[Bug c++/69901] Iniitializing non-const global array variable from runtime const global variable does not copy all values properly

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
r231777 aka PR67550 fixed that.

[Bug fortran/69930] fortran address sanitizer does not work with optimization

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  ---
That is intentional.  The address sanitization is performed quite late and is
testing violations after many optimizations have done its job.  In this case,
the cddce1 pass turned the endless loop into an empty endless loop, which is a
valid transformation in that case.
If you want to catch violations that are closer to what you have in the source
code, use -O0 instead with -fsanitize=address.

[Bug c++/69901] Iniitializing non-const global array variable from runtime const global variable does not copy all values properly

[trippels at gcc dot gnu.org]

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

--- Comment #3 from Markus Trippelsdorf  ---
(In reply to Piotr Nycz from comment #2)
> How to get information in which version it is fixed?
> What we discover ourselves:
> 4.9.1 - work
> 4.9.2 - fail
> 4.9.4 - work
> 5.2 - fail
> 6.0 (experimental) - work
> 
> I need to know the newest stable version where it is fixed. How can I get
> this knowledge?

You can run an inverse "git bisect" on the source tree for example.

[Bug fortran/65996] [5/6 Regression] gfortran ICE with -dH

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

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

--- Comment #14 from Jerry DeLisle  ---
Fixed, Closing

[Bug fortran/65996] [5/6 Regression] gfortran ICE with -dH

[jvdelisle at gcc dot gnu.org]

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

--- Comment #13 from Jerry DeLisle  ---
Author: jvdelisle
Date: Wed Feb 24 06:45:41 2016
New Revision: 233653

URL: https://gcc.gnu.org/viewcvs?rev=233653=gcc=rev
Log:
2016-02-23  Jerry DeLisle  

Backported from mainline
PR fortran/65996
* error.c (gfc_error): Save the state of abort_on_error and set
it to false for buffered errors to allow normal processing.
Restore the state before leaving.

PR fortran/65996
* gfortran.dg/pr65996.f90: New test.

Added:
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/pr65996.f90
Modified:
branches/gcc-5-branch/gcc/fortran/ChangeLog
branches/gcc-5-branch/gcc/fortran/error.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug c++/69564] [5/6 Regression] lto and/or C++ make scimark2 LU slower

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #9 from Jason Merrill  ---
(In reply to Jason Merrill from comment #7)
> But if I add loop inversion back into the C++ front end
> so that the .optimized output is indistinguishable, that resolves the
> difference without LTO

Actually, no, the loop inversion patch in comment 8 doesn't improve
performance; even though the .optimized dump is the same between C and C++, the
C++ build is still slower by roughly the same amount.  I guess the RTL
optimizers must be doing something different?  Mysterious.  Unassigning myself.

[Bug c++/69912] [6 regression] ICE in build_ctor_subob_ref initializing a flexible array member

[msebor at gcc dot gnu.org]

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

--- Comment #1 from Martin Sebor  ---
Patch posted for review:
https://gcc.gnu.org/ml/gcc-patches/2016-02/msg01614.html

[Bug tree-optimization/69935] load not hoisted out of linked-list traversal loop

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|load not skinked out of |load not hoisted out of
   |linked-list traversal loop  |linked-list traversal loop

--- Comment #2 from Andrew Pinski  ---
Full testcase (not needing the link; just in case it goes down):

struct foo {
  struct foo *n;
  int a;
};
struct foo_head {
  struct foo*h;
};


int traverse(struct foo_head *ph)
{
  int a = -1;
  struct foo *p, *pprev;
  pprev = p = ph->h;
  while (p) {
pprev = p;
p = p->n;
  }
  if (pprev)
a = pprev->a;
  return a;
}

int traverse_loadloop(struct foo_head *ph)
{
  int a = -1;
  struct foo *p = ph->h;
  while (p) {
a = p->a;
p = p->n;
  }
  return a;
}

[Bug tree-optimization/69935] load not skinked out of linked-list traversal loop

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|load not hoisted out of |load not skinked out of
   |linked-list traversal loop  |linked-list traversal loop

--- Comment #1 from Andrew Pinski  ---
This is not about hoisting rather sinking.

[Bug tree-optimization/69935] New: load not hoisted out of linked-list traversal loop

[peter at cordes dot ca]

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

Bug ID: 69935
   Summary: load not hoisted out of linked-list traversal loop
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: peter at cordes dot ca
  Target Milestone: ---

(please check the component.  I guessed tree-optimization since it's
cross-architecture.)

gcc doesn't hoist the p->a load out of the loop in this linked-list function

int traverse_loadloop(struct foo_head *ph)
{
  int a = -1;
  struct foo *p = ph->h;
  while (p) {
a = p->a;
p = p->n;
  }
  return a;
}

I checked on godbolt with gcc 4.8 on ARM/PPC/ARM64, and gcc 4.5.3 for AVR.
For x86, gcc 5.3.0 -O3 on godbolt (http://goo.gl/r8vb5L) does this:

movq(%rdi), %rdx
movl$-1, %eax
testq   %rdx, %rdx
je  .L10
.L11:
movl8(%rdx), %eax ; load p->a inside the loop, not hoisted
movq(%rdx), %rdx
testq   %rdx, %rdx
jne .L11
.L10:
rep ret

This is nice and compact, but less hyperthreading-friendly than it could be. 
(The mov reg,reg alternative doesn't even take an execution unit on recent
CPUs).

The load of p->a every time through the loop might also delay the p->n load by
a cycle on CPUs with only one load port, or when there's a cache-bank conflict.
 This might take the loop from one iteration per 4c to one per 5c (if L1
load-use latency is 4c).

Clang hoists the load out of the loop, producing identical asm output for this
function and one with the load hoisted in the C source.  (The godbolt link has
both versions.  Also see bug 69933 which I just reported, since gcc showed a
separate branch-layout issue for the source-level hoisting version.)

[Bug rtl-optimization/69933] New: non-ideal branch layout for an early-out return

[peter at cordes dot ca]

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

Bug ID: 69933
   Summary: non-ideal branch layout for an early-out return
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: peter at cordes dot ca
  Target Milestone: ---

(just guessing about this being an RTL bug, please reassign if it's
target-specific or something else).

This simple linked-list traversal compiles to slightly bulkier code than it
needs to:

int traverse(struct foo_head *ph)
{
  int a = -1;
  struct foo *p, *pprev;
  pprev = p = ph->h;
  while (p != NULL) {
pprev = p;
p = p->n;
  }
  if (pprev)
a = pprev->a;
  return a;
}

 (gcc 5.3.0 -O3 on godbolt: http://goo.gl/r8vb5L)

movq(%rdi), %rdx
movl$-1, %eax   ; only needs to happen in the early-out case
testq   %rdx, %rdx
jne .L3 ; jne/ret or je / fall through would be better
jmp .L9
.L5:
movq%rax, %rdx
.L3:
movq(%rdx), %rax
testq   %rax, %rax
jne .L5
movl8(%rdx), %eax
ret
.L9:
   ; ARM / PPC gcc 4.8.2 put the a=-1 down here
ret ; this is a rep ret without -mtune=intel


Clang 3.7 chooses a better layout with a je .early_out instead the jne / jmp. 
It arranges the loop so it can enter at the top.  It actually look pretty
optimal:

movq(%rdi), %rcx
movl$-1, %eax
testq   %rcx, %rcx
je  .LBB0_3
.LBB0_1:# %.lr.ph
movq%rcx, %rax
movq(%rax), %rcx
testq   %rcx, %rcx
jne .LBB0_1
movl8(%rax), %eax
.LBB0_3:# %._crit_edge.thread
retq

Getting the mov $-1 out of the common case would require a separate mov/ret
block after the normal ret, so it's a code-size tradeoff which isn't worth it,
because a mov-immediate is dirt cheap.

Anyway, there are a couple different ways to lay out the branches and the mov
$-1, %eax, but gcc's choice is in no way optimal. :(

[Bug rtl-optimization/60818] ICE in validate_condition_mode on powerpc*-linux-gnu*

[segher at gcc dot gnu.org]

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

--- Comment #7 from Segher Boessenkool  ---
Not a regression, postponed to GCC 7, last patch is at
https://gcc.gnu.org/ml/gcc-patches/2016-02/msg01303.html .

[Bug plugins/69758] [6 Regression] Plugins can't include params.h (missing params.list)

[pageexec at gmail dot com]

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

PaX Team  changed:

   What|Removed |Added

 CC||pageexec at gmail dot com

--- Comment #4 from PaX Team  ---
just for the record, this was also reported at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61176#c20

[Bug plugins/61176] plugin builds including gimple.h not building

[pageexec at gmail dot com]

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

--- Comment #21 from PaX Team  ---
(In reply to PaX Team from comment #20)
> update for gcc-6: /gcc/params.list is also needed now as it gets
> included by params.h.

PR69758 fixes it.

[Bug fortran/60126] Internal compiler error with code using pointer reshaping (gfortran 4.8.2)

[mfvalin at gmail dot com]

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

--- Comment #3 from Michel Valin  ---
for what it's worth, the bug is not present in 4.9.1 nor 5.3

Michel Valin
analyste de l'informatique

On 16-02-23 05:30 PM, anlauf at gmx dot de wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60126
>
> Harald Anlauf  changed:
>
>What|Removed |Added
> 
>  CC||anlauf at gmx dot de
>
> --- Comment #2 from Harald Anlauf  ---
> (In reply to Dominique d'Humieres from comment #1)
>> Confirmed with 4.7 and 4.8. It seems fixed on trunk between r201266
>> (2013-07-26, ICE) and r201631 (2013-08-09, OK). There are several commits in
>> this range without obvious suspect.
> If it's fixed - I do not see an ICE with 4.9/5/6 trunk - this
> bug should be closed.  Maybe we should add the testcase from
> comment #0 to the testsuite.
>

[Bug tree-optimization/69932] New: gcc ICE at -O1 and above on valid code on x86_64-linux-gnu with “seg fault”

[helloqirun at gmail dot com]

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

Bug ID: 69932
   Summary: gcc ICE at -O1 and above on valid code on
x86_64-linux-gnu with “seg fault”
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: helloqirun at gmail dot com
  Target Milestone: ---

The following valid code causes an ICE when compiled with the current gcc trunk
at -O1 and above on x86_64-linux-gnu in both 32-bit and 64-bit modes.


$ gcc-trunk  -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/home/absozero/trunk/root-gcc/libexec/gcc/x86_64-pc-linux-gnu/6.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --prefix=/home/absozero/trunk/root-gcc
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 6.0.0 20160223 (experimental) [trunk revision 233632] (GCC) 



$ gcc-trunk abc.c -c -O3
abc.c: In function ‘fn1’:
abc.c:8:1: internal compiler error: Segmentation fault
 }
 ^
0xb5ea1f crash_signal
../../gcc/gcc/toplev.c:335
0xbacab3 get_ref_base_and_extent(tree_node*, long*, long*, long*, bool*)
../../gcc/gcc/tree-dfa.c:392
0xc442da get_access_for_expr
../../gcc/gcc/tree-sra.c:2903
0xc4a97b sra_modify_assign
../../gcc/gcc/tree-sra.c:3314
0xc4a97b sra_modify_function_body
../../gcc/gcc/tree-sra.c:3621
0xc4a97b perform_intra_sra
../../gcc/gcc/tree-sra.c:3731
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.


$ cat abc.c
int a;
void fn1() {
  int b = 4;
  short c[4];
  c[b] = c[a];
  if (c[2]) {}

}

[Bug fortran/69930] fortran address sanitizer does not work with optimization

[dominiq at lps dot ens.fr]

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

--- Comment #1 from Dominique d'Humieres  ---
*** Bug 69931 has been marked as a duplicate of this bug. ***

[Bug fortran/69931] fortran address sanitizer does not work with optimization

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #1 from Dominique d'Humieres  ---
Dup.

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

[Bug c++/69901] Iniitializing non-const global array variable from runtime const global variable does not copy all values properly

[piotrwn1 at gmail dot com]

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

--- Comment #2 from Piotr Nycz  ---
How to get information in which version it is fixed?
What we discover ourselves:
4.9.1 - work
4.9.2 - fail
4.9.4 - work
5.2 - fail
6.0 (experimental) - work

I need to know the newest stable version where it is fixed. How can I get this
knowledge?

[Bug fortran/69931] New: fortran address sanitizer does not work with optimization

[physiker at toast2 dot net]

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

Bug ID: 69931
   Summary: fortran address sanitizer does not work with
optimization
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: physiker at toast2 dot net
  Target Milestone: ---

When the code bnd11.f90, included in polyhedrons linux fortran testsuite, is
compiled without optimization the address sanitizer catches the error. With
optimization turned on, the address sanitizer does not spot the error. The
execution of the program is not stopped by the sanitizer.

bash-3.2$ gfortran-6 -v -W -Wall bnd11.f90 -fsanitize=address -o bnd11
Driving: gfortran-6 -v -W -Wall bnd11.f90 -fsanitize=address -o bnd11
-mmacosx-version-min=10.9.4 -l gfortran -shared-libgcc
Using built-in specs.
COLLECT_GCC=gfortran-6
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-apple-darwin13.4.0/6.0.0/lto-wrapper
Target: x86_64-apple-darwin13.4.0
Configured with: ../gcc/configure --enable-languages=c,c++,fortran,lto
--with-gmp=/sw --with-libiconv-prefix=/sw --with-isl=/sw --with-mpc=/sw
--with-system-zlib --program-suffix=-6
Thread model: posix
gcc version 6.0.0 20160213 (experimental) (GCC) 
COLLECT_GCC_OPTIONS='-v' '-Wextra' '-Wall' '-fsanitize=address' '-o' 'bnd11'
'-mmacosx-version-min=10.9.4' '-shared-libgcc' '-mtune=core2'
 /usr/local/libexec/gcc/x86_64-apple-darwin13.4.0/6.0.0/f951 bnd11.f90 -fPIC
-quiet -dumpbase bnd11.f90 -mmacosx-version-min=10.9.4 -mtune=core2 -auxbase
bnd11 -Wextra -Wall -version -fsanitize=address -fintrinsic-modules-path
/usr/local/lib/gcc/x86_64-apple-darwin13.4.0/6.0.0/finclude -o
/var/folders/97/4qnhjhtn25s86s9hkz0h37_mgn/T//ccqDq0Sb.s
GNU Fortran (GCC) version 6.0.0 20160213 (experimental)
(x86_64-apple-darwin13.4.0)
compiled by GNU C version 6.0.0 20160213 (experimental), GMP version
6.1.0, MPFR version 3.1.3, MPC version 1.0.3, isl version 0.14 or 0.13
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU Fortran2008 (GCC) version 6.0.0 20160213 (experimental)
(x86_64-apple-darwin13.4.0)
compiled by GNU C version 6.0.0 20160213 (experimental), GMP version
6.1.0, MPFR version 3.1.3, MPC version 1.0.3, isl version 0.14 or 0.13
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
COLLECT_GCC_OPTIONS='-v' '-Wextra' '-Wall' '-fsanitize=address' '-o' 'bnd11'
'-mmacosx-version-min=10.9.4' '-shared-libgcc' '-mtune=core2'
 as -arch x86_64 -force_cpusubtype_ALL -o
/var/folders/97/4qnhjhtn25s86s9hkz0h37_mgn/T//ccSUHTPj.o
/var/folders/97/4qnhjhtn25s86s9hkz0h37_mgn/T//ccqDq0Sb.s
Reading specs from
/usr/local/lib/gcc/x86_64-apple-darwin13.4.0/6.0.0/../../../libgfortran.spec
rename spec lib to liborig
COLLECT_GCC_OPTIONS='-v' '-Wextra' '-Wall' '-fsanitize=address' '-o' 'bnd11'
'-mmacosx-version-min=10.9.4' '-shared-libgcc' '-mtune=core2'
COMPILER_PATH=/usr/local/libexec/gcc/x86_64-apple-darwin13.4.0/6.0.0/:/usr/local/libexec/gcc/x86_64-apple-darwin13.4.0/6.0.0/:/usr/local/libexec/gcc/x86_64-apple-darwin13.4.0/:/usr/local/lib/gcc/x86_64-apple-darwin13.4.0/6.0.0/:/usr/local/lib/gcc/x86_64-apple-darwin13.4.0/
LIBRARY_PATH=/usr/local/lib/gcc/x86_64-apple-darwin13.4.0/6.0.0/:/usr/local/lib/gcc/x86_64-apple-darwin13.4.0/6.0.0/../../../
COLLECT_GCC_OPTIONS='-v' '-Wextra' '-Wall' '-fsanitize=address' '-o' 'bnd11'
'-mmacosx-version-min=10.9.4' '-shared-libgcc' '-mtune=core2'
 /usr/local/libexec/gcc/x86_64-apple-darwin13.4.0/6.0.0/collect2 -dynamic -arch
x86_64 -macosx_version_min 10.9.4 -weak_reference_mismatches non-weak -o bnd11
-L/usr/local/lib/gcc/x86_64-apple-darwin13.4.0/6.0.0
-L/usr/local/lib/gcc/x86_64-apple-darwin13.4.0/6.0.0/../../..
/var/folders/97/4qnhjhtn25s86s9hkz0h37_mgn/T//ccSUHTPj.o -lgfortran -lasan
-no_compact_unwind -lSystem -lgcc_ext.10.5 -lgcc -lquadmath -lm -lgcc_ext.10.5
-lgcc -lSystem -v
collect2 version 6.0.0 20160213 (experimental)
/usr/bin/ld -dynamic -arch x86_64 -macosx_version_min 10.9.4
-weak_reference_mismatches non-weak -o bnd11
-L/usr/local/lib/gcc/x86_64-apple-darwin13.4.0/6.0.0
-L/usr/local/lib/gcc/x86_64-apple-darwin13.4.0/6.0.0/../../..
/var/folders/97/4qnhjhtn25s86s9hkz0h37_mgn/T//ccSUHTPj.o -lgfortran -lasan
-no_compact_unwind -lSystem -lgcc_ext.10.5 -lgcc -lquadmath -lm -lgcc_ext.10.5
-lgcc -lSystem -v
@(#)PROGRAM:ld  PROJECT:ld64-241.9
configured to support archs: armv6 armv7 armv7s arm64 i386 x86_64 x86_64h
armv6m armv7m armv7em
Library search paths:
/usr/local/lib/gcc/x86_64-apple-darwin13.4.0/6.0.0
/usr/local/lib
/usr/lib
/usr/local/lib
Framework search paths:
/Library/Frameworks/
/System/Library/Frameworks/
 /usr/bin/nm -n /var/folders/97/4qnhjhtn25s86s9hkz0h37_mgn/T//ccSUHTPj.o
bash-3.2$ ./bnd11
=
==643==ERROR: 

[Bug fortran/69930] New: fortran address sanitizer does not work with optimization

[physiker at toast2 dot net]

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

Bug ID: 69930
   Summary: fortran address sanitizer does not work with
optimization
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: physiker at toast2 dot net
  Target Milestone: ---

Created attachment 37776
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37776=edit
Source code

When the code bnd11.f90, included in polyhedrons linux fortran testsuite, is
compiled without optimization the address sanitizer catches the error. With
optimization turned on, the address sanitizer does not spot the error. The
execution of the program is not stopped by the sanitizer.
bash-3.2$ gfortran -v -W -Wall bnd11.f90 -fsanitize=address -o bnd11
Driving: gfortran -mmacosx-version-min=10.9.4 -v -W -Wall bnd11.f90
-fsanitize=address -o bnd11 -l gfortran -shared-libgcc
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/sw/lib/gcc5/libexec/gcc/x86_64-apple-darwin13.4.0/5.3.0/lto-wrapper
Target: x86_64-apple-darwin13.4.0
Configured with: ../gcc-5.3.0/configure --prefix=/sw --prefix=/sw/lib/gcc5
--mandir=/sw/share/man --infodir=/sw/lib/gcc5/info
--enable-languages=c,c++,fortran,lto,objc,obj-c++,java --with-gmp=/sw
--with-libiconv-prefix=/sw --with-isl=/sw --with-mpc=/sw --with-system-zlib
--program-suffix=-fsf-5
Thread model: posix
gcc version 5.3.0 (GCC) 
COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.9.4' '-v' '-Wextra' '-Wall'
'-fsanitize=address' '-o' 'bnd11' '-shared-libgcc' '-mtune=core2'
 /sw/lib/gcc5/libexec/gcc/x86_64-apple-darwin13.4.0/5.3.0/f951 bnd11.f90 -fPIC
-quiet -dumpbase bnd11.f90 -mmacosx-version-min=10.9.4 -mtune=core2 -auxbase
bnd11 -Wextra -Wall -version -fsanitize=address -fintrinsic-modules-path
/sw/lib/gcc5/lib/gcc/x86_64-apple-darwin13.4.0/5.3.0/finclude -o
/var/folders/97/4qnhjhtn25s86s9hkz0h37_mgn/T//ccqRKgpk.s
GNU Fortran (GCC) version 5.3.0 (x86_64-apple-darwin13.4.0)
compiled by GNU C version 5.3.0, GMP version 6.0.0, MPFR version 3.1.3,
MPC version 1.0.3
warning: GMP header version 6.0.0 differs from library version 6.1.0.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU Fortran2008 (GCC) version 5.3.0 (x86_64-apple-darwin13.4.0)
compiled by GNU C version 5.3.0, GMP version 6.0.0, MPFR version 3.1.3,
MPC version 1.0.3
warning: GMP header version 6.0.0 differs from library version 6.1.0.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.9.4' '-v' '-Wextra' '-Wall'
'-fsanitize=address' '-o' 'bnd11' '-shared-libgcc' '-mtune=core2'
 as -arch x86_64 -force_cpusubtype_ALL -o
/var/folders/97/4qnhjhtn25s86s9hkz0h37_mgn/T//ccmU9RIS.o
/var/folders/97/4qnhjhtn25s86s9hkz0h37_mgn/T//ccqRKgpk.s
Reading specs from
/sw/lib/gcc5/lib/gcc/x86_64-apple-darwin13.4.0/5.3.0/../../../libgfortran.spec
rename spec lib to liborig
COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.9.4' '-v' '-Wextra' '-Wall'
'-fsanitize=address' '-o' 'bnd11' '-shared-libgcc' '-mtune=core2'
COMPILER_PATH=/sw/lib/gcc5/libexec/gcc/x86_64-apple-darwin13.4.0/5.3.0/:/sw/lib/gcc5/libexec/gcc/x86_64-apple-darwin13.4.0/5.3.0/:/sw/lib/gcc5/libexec/gcc/x86_64-apple-darwin13.4.0/:/sw/lib/gcc5/lib/gcc/x86_64-apple-darwin13.4.0/5.3.0/:/sw/lib/gcc5/lib/gcc/x86_64-apple-darwin13.4.0/
LIBRARY_PATH=/sw/lib/gcc5/lib/gcc/x86_64-apple-darwin13.4.0/5.3.0/:/sw/lib/gcc5/lib/gcc/x86_64-apple-darwin13.4.0/5.3.0/../../../:/usr/lib/
COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.9.4' '-v' '-Wextra' '-Wall'
'-fsanitize=address' '-o' 'bnd11' '-shared-libgcc' '-mtune=core2'
 /sw/lib/gcc5/libexec/gcc/x86_64-apple-darwin13.4.0/5.3.0/collect2 -dynamic
-arch x86_64 -macosx_version_min 10.9.4 -weak_reference_mismatches non-weak -o
bnd11 -L/sw/lib/gcc5/lib/gcc/x86_64-apple-darwin13.4.0/5.3.0
-L/sw/lib/gcc5/lib/gcc/x86_64-apple-darwin13.4.0/5.3.0/../../..
/var/folders/97/4qnhjhtn25s86s9hkz0h37_mgn/T//ccmU9RIS.o -lgfortran -lasan
-no_compact_unwind -lSystem -lgcc_ext.10.5 -lgcc -lquadmath -lm -lgcc_ext.10.5
-lgcc -lSystem -v
collect2 version 5.3.0
/usr/bin/ld -dynamic -arch x86_64 -macosx_version_min 10.9.4
-weak_reference_mismatches non-weak -o bnd11
-L/sw/lib/gcc5/lib/gcc/x86_64-apple-darwin13.4.0/5.3.0
-L/sw/lib/gcc5/lib/gcc/x86_64-apple-darwin13.4.0/5.3.0/../../..
/var/folders/97/4qnhjhtn25s86s9hkz0h37_mgn/T//ccmU9RIS.o -lgfortran -lasan
-no_compact_unwind -lSystem -lgcc_ext.10.5 -lgcc -lquadmath -lm -lgcc_ext.10.5
-lgcc -lSystem -v
@(#)PROGRAM:ld  PROJECT:ld64-241.9
configured to support archs: armv6 armv7 armv7s arm64 i386 x86_64 x86_64h
armv6m armv7m armv7em
Library search paths:
/sw/lib/gcc5/lib/gcc/x86_64-apple-darwin13.4.0/5.3.0
/sw/lib/gcc5/lib
/usr/lib
/usr/local/lib
Framework search paths:
/Library/Frameworks/

[Bug fortran/61156] [4.9/5/6 Regression] Internal compiler error for Fortran files when specifying a file instead of an include directory with -I

[jvdelisle at gcc dot gnu.org]

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

--- Comment #10 from Jerry DeLisle  ---
Fixed on trunk, back port in a few days.

[Bug fortran/61156] [4.9/5/6 Regression] Internal compiler error for Fortran files when specifying a file instead of an include directory with -I

[jvdelisle at gcc dot gnu.org]

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

--- Comment #9 from Jerry DeLisle  ---
Author: jvdelisle
Date: Tue Feb 23 22:53:31 2016
New Revision: 233649

URL: https://gcc.gnu.org/viewcvs?rev=233649=gcc=rev
Log:
2016-02-23  Jerry DeLisle  

PR fortran/61156
* scanner.c (add_path_to_list): If include path is not a directory,
issue a fatal error.

PR fortran/61156
* gfortran.dg/include_6.f90: Update test.

Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/scanner.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/include_6.f90

[Bug fortran/69929] New: Internal compiler error GCC$ ATTRIBUTES STDCALL

[physiker at toast2 dot net]

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

Bug ID: 69929
   Summary: Internal compiler error GCC$ ATTRIBUTES STDCALL
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: physiker at toast2 dot net
  Target Milestone: ---

Created attachment 37775
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37775=edit
Source code

Compiling the file win_gnu_dynlib.f90 causes an internal compiler error.The 
GCC$ ATTRIBUTES STDCALL lines (for windows) are causing the crash.

gfortran-6 -c -v win_gnu_dynlib.f90 
Using built-in specs.
COLLECT_GCC=gfortran-6
Target: x86_64-apple-darwin13.4.0
Configured with: ../gcc/configure --enable-languages=c,c++,fortran,lto
--with-gmp=/sw --with-libiconv-prefix=/sw --with-isl=/sw --with-mpc=/sw
--with-system-zlib --program-suffix=-6
Thread model: posix
gcc version 6.0.0 20160213 (experimental) (GCC) 
COLLECT_GCC_OPTIONS='-c' '-v' '-mmacosx-version-min=10.9.4' '-mtune=core2'
 /usr/local/libexec/gcc/x86_64-apple-darwin13.4.0/6.0.0/f951 win_gnu_dynlib.f90
-fPIC -quiet -dumpbase win_gnu_dynlib.f90 -mmacosx-version-min=10.9.4
-mtune=core2 -auxbase win_gnu_dynlib -version -fintrinsic-modules-path
/usr/local/lib/gcc/x86_64-apple-darwin13.4.0/6.0.0/finclude -o
/var/folders/97/4qnhjhtn25s86s9hkz0h37_mgn/T//ccVTJ6eT.s
GNU Fortran (GCC) version 6.0.0 20160213 (experimental)
(x86_64-apple-darwin13.4.0)
compiled by GNU C version 6.0.0 20160213 (experimental), GMP version
6.1.0, MPFR version 3.1.3, MPC version 1.0.3, isl version 0.14 or 0.13
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU Fortran2008 (GCC) version 6.0.0 20160213 (experimental)
(x86_64-apple-darwin13.4.0)
compiled by GNU C version 6.0.0 20160213 (experimental), GMP version
6.1.0, MPFR version 3.1.3, MPC version 1.0.3, isl version 0.14 or 0.13
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
'
win_gnu_dynlib.f90:76:0:

 cproc = c_get_procedure( handle, cname )

in pp_format, at pretty-print.c:635

Internal compiler error: Error reporting routines re-entered.
gfortran-6: internal compiler error: Abort trap: 6 (program f951)
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug fortran/60126] Internal compiler error with code using pointer reshaping (gfortran 4.8.2)

[anlauf at gmx dot de]

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

Harald Anlauf  changed:

   What|Removed |Added

 CC||anlauf at gmx dot de

--- Comment #2 from Harald Anlauf  ---
(In reply to Dominique d'Humieres from comment #1)
> Confirmed with 4.7 and 4.8. It seems fixed on trunk between r201266
> (2013-07-26, ICE) and r201631 (2013-08-09, OK). There are several commits in
> this range without obvious suspect.

If it's fixed - I do not see an ICE with 4.9/5/6 trunk - this
bug should be closed.  Maybe we should add the testcase from
comment #0 to the testsuite.

[Bug target/69810] PowerPC64: unrecognizable insn

[dje at gcc dot gnu.org]

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

--- Comment #8 from David Edelsohn  ---
Author: dje
Date: Tue Feb 23 22:28:23 2016
New Revision: 233648

URL: https://gcc.gnu.org/viewcvs?rev=233648=gcc=rev
Log:
PR target/69810
* config/rs6000/rs6000.md (zero_extendqi2_dot): Convert from
define_insn_and_split to define_insn.
(zero_extendqi2_dot2): Same.
(extendqi2_dot): Same.
(extendqi2_dot2): Same.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/rs6000.md

[Bug libstdc++/69893] [6 Regression] Conflicting declarations in and

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #5 from Jonathan Wakely  ---
Fixed

[Bug c++/69925] No warning for uninitialized char * passing to function as const char *

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||manu at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #3 from Manuel López-Ibáñez  ---
Dup of PR10138, but probably need to fix PR33086 first.

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

[Bug middle-end/10138] warn for uninitialized arrays passed as const* arguments

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||developm...@faf-ltd.com

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

[Bug c++/69925] No warning for uninitialized char * passing to function as const char *

[developm...@faf-ltd.com]

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

--- Comment #2 from Peter VARGA  ---
I expected honestly this answer but then almost every compiler warning can be
"overruled" by a bad programmer.

By the way I found out this behavior because I used it in STL and there is
almost every parameter const when it makes sense.

[Bug web/69928] incorrect reference to gcc-plugin.h in plugin documentation

[petensotium at gmail dot com]

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

petensotium at gmail dot com changed:

   What|Removed |Added

   Severity|normal  |minor

[Bug web/69928] New: incorrect reference to gcc-plugin.h in plugin documentation

[petensotium at gmail dot com]

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

Bug ID: 69928
   Summary: incorrect reference to gcc-plugin.h in plugin
documentation
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: web
  Assignee: unassigned at gcc dot gnu.org
  Reporter: petensotium at gmail dot com
  Target Milestone: ---

On the page "https://gcc.gnu.org/onlinedocs/gccint/Plugin-API.html#Plugin-API;,
the first sentence says "Plugins are activated by the compiler at specific
events as defined in gcc-plugin.h."  However, I was only able to find a list of
#includes in this file, with the even definitions being in "plugin.def".

[Bug c++/69564] [5/6 Regression] lto and/or C++ make scimark2 LU slower

[jason at gcc dot gnu.org]

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

--- Comment #8 from Jason Merrill  ---
Created attachment 37774
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37774=edit
loop inversion sketch

This patch does loop inversion sufficient for scimark.  It will break
constexpr, but might be useful for looking at the LTO issue.

[Bug c++/69564] [5/6 Regression] lto and/or C++ make scimark2 LU slower

[jason at gcc dot gnu.org]

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

--- Comment #7 from Jason Merrill  ---
(In reply to Richard Biener from comment #4)
> Yeah, didn't try to figure out whether the C vs. C++ thing is a 
> regression.  But I suspect the change to the C++ loop lowering.

Yes, the relatively small difference between C and C++ without LTO seems to be
due to the loop inversion that the C front end still does, and the C++ front
end doesn't.  But if I add loop inversion back into the C++ front end so that
the .optimized output is indistinguishable, that resolves the difference
without LTO, but LTO still makes the C++ output much slower.

[Bug c/69927] New: Internal compiler error (Segmentation fault) when compiling FFmpeg 3.0

[jb999 at gmx dot de]

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

Bug ID: 69927
   Summary: Internal compiler error (Segmentation fault) when
compiling FFmpeg 3.0
   Product: gcc
   Version: 4.9.3
Status: UNCONFIRMED
  Severity: critical
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jb999 at gmx dot de
  Target Milestone: ---

Created attachment 37773
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37773=edit
preprocessed file

Compiling FFmpeg 3.0 being configured with ./configure --prefix=/usr
--pkgconfigdir=/var/state/pkgconfig --enable-gpl --enable-version3
--enable-shared --disable-static --disable-runtime-cpudetect --disable-ffserver
fails with

libavfilter/vf_dejudder.c: In function 'filter_frame':
libavfilter/vf_dejudder.c:158:1: internal compiler error: Segmentation fault
 }
 ^

System is Linux SMP i686 GNU/Linux (Linux From Scratch).

gcc -v:
Using built-in specs.
COLLECT_GCC=gcc
Target: i686-pc-linux-gnu
Configured with: /tmp/gcc-4.9.3//configure --prefix=/usr --sysconfdir=/etc
--sharedstatedir=/var/state --localstatedir=/var/state --enable-shared
--disable-static --disable-nls --enable-languages=c,c++ --enable-__cxa_atexit
--with-arch=haswell --with-gxx-include-dir=/usr/include/c++ --with-system-zlib
--disable-multilib --disable-bootstrap --disable-plugin --disable-lto
Thread model: posix
gcc version 4.9.3 (GCC)

Command line (from FFmpeg Makefile):
gcc -I. -I./ -D_ISOC99_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE
-D_POSIX_C_SOURCE=200112 -D_XOPEN_SOURCE=600 -DZLIB_CONST -DHAVE_AV_CONFIG_H
-std=c99 -fomit-frame-pointer -pthread  -g -Wdeclaration-after-statement -Wall
-Wdisabled-optimization -Wpointer-arith -Wredundant-decls -Wwrite-strings
-Wtype-limits -Wundef -Wmissing-prototypes -Wno-pointer-to-int-cast
-Wstrict-prototypes -Wempty-body -Wno-parentheses -Wno-switch
-Wno-format-zero-length -Wno-pointer-sign -O3 -fno-math-errno -fno-signed-zeros
-Werror=format-security -Werror=implicit-function-declaration
-Werror=missing-prototypes -Werror=return-type -Werror=vla -Wformat
-fdiagnostics-color=auto -Wno-maybe-uninitialized  -MMD -MF
libavfilter/vf_dejudder.d -MT libavfilter/vf_dejudder.o -c -save-temps -o
libavfilter/vf_dejudder.o libavfilter/vf_dejudder.c

The preprocessed file is attached.

[Bug c++/69564] [5/6 Regression] lto and/or C++ make scimark2 LU slower

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug objc/69844] [6 Regression] Possibly bogus error: unknown type name in ObjC code

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #5 from Jakub Jelinek  ---
Fixed.

[Bug libstdc++/69893] [6 Regression] Conflicting declarations in and

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
Author: redi
Date: Tue Feb 23 19:49:31 2016
New Revision: 233644

URL: https://gcc.gnu.org/viewcvs?rev=233644=gcc=rev
Log:
libstdc++/69893 make  work with C++11

PR libstdc++/69893
* include/tr1/cmath (acosh, asinh, atanh, cbrt, copysign, erf, erfc,
exp2, expm1, fdim, fma, fmax, fmin, hypot, ilogb, lgamma, llrint,
llround, log1p, log2, logb, lrint, lround, nan, nearbyint, nextafter,
nexttoward, remainder, remquo, rint, round, scalbln, scalbn, tgamma,
trunc) [__cplusplus >= 201103L]: Import from namespace std.
(fabs) [__cplusplus < 201103L]: Import from namespace std.
* include/tr1/complex (acosh, asinh, atanh) [__cplusplus >= 201103L]:
Likewise.
* testsuite/tr1/headers/c++200x/complex.cc: Add std::fabs to global
namespace before including TR1 headers.
* testsuite/tr1/headers/c++200x/math.cc: New test.

Added:
trunk/libstdc++-v3/testsuite/tr1/headers/c++200x/math.cc
  - copied, changed from r233640,
trunk/libstdc++-v3/testsuite/tr1/headers/c++200x/complex.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/tr1/cmath
trunk/libstdc++-v3/include/tr1/complex
trunk/libstdc++-v3/testsuite/tr1/headers/c++200x/complex.cc

[Bug objc/69844] [6 Regression] Possibly bogus error: unknown type name in ObjC code

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Tue Feb 23 19:47:24 2016
New Revision: 233643

URL: https://gcc.gnu.org/viewcvs?rev=233643=gcc=rev
Log:
PR objc/69844
* c-parser.c (c_parser_for_statement): Properly handle ObjC classes
in id_kind reclassification.

* objc.dg/pr69844.m: New test.

Added:
trunk/gcc/testsuite/objc.dg/pr69844.m
Modified:
trunk/gcc/c/ChangeLog
trunk/gcc/c/c-parser.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/69368] [6 Regression] spec2006 test case 416.gamess fails with the g++ 6.0 compiler starting with r232508

[rguenther at suse dot de]

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

--- Comment #81 from rguenther at suse dot de  ---
On February 23, 2016 4:20:48 PM GMT+01:00, "alalaw01 at gcc dot gnu.org"
 wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69368
>
>--- Comment #79 from alalaw01 at gcc dot gnu.org ---
>(In reply to rguent...@suse.de from comment #78)
>>
>> That would pessimize it too much IMHO.
>
>I'm not sure how to evaluate the pessimization, given it's thought to
>be a
>widespread pseudo-FORTRAN construct; so I probably have to defer to
>your
>judgement here. However...
>
>Given maxsize of an array as two elements, say, would the compiler not
>be
>entitled to optimize an index selection down to, say, computing only
>the LSBit
>of the actual index?  Whereas 'unknown' means, well, exactly what is
>the case.
>So I fear this is storing problems up for the future.

It doesn't do that.

>Is the concern that we can't hide this behind an option, as that would
>"drive
>people away from gfortran" ? If that's the case, can we hide it behind
>an
>option that defaults to pessimization (?? at least for fortran)??

I don't think it's necessary to hide it behind an option.

[Bug ada/69926] GNAT bug detected -- Storage_Error stack overflow or erroneous memory access

[keith at aquilonis dot net]

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

--- Comment #3 from Keith Godfrey  ---
Error seems to be caused by using an incorrect attribute (I used 'range when I
meant 'last). 

This is not a priority to fix. I only reported it because it induced an
internal error in the compiler

[Bug ada/69926] GNAT bug detected -- Storage_Error stack overflow or erroneous memory access

[keith at aquilonis dot net]

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

--- Comment #2 from Keith Godfrey  ---
Source code attached. Here is code as a comment:

 muscles.ads
package Muscles is
   type stretch is digits 5 range 0.0 .. 1.0;

   type spindle_t is
  record
 center: stretch := 0.0;
  end record;

   type spindle_array is array(1 .. 40) of spindle_t;

   procedure foo(spindles: in out spindle_array);
end Muscles;

 muscles.adb
package body Muscles is
   -- 
   procedure foo(spindles: in out spindle_array) is
  pos: stretch;
   begin
  for i in spindles'range loop
 pos := stretch(float(i - 1) / float(spindles'range - 1)):
 spindles(i).center := pos;
  end loop;
   end foo;
end Muscles;

[Bug ada/69926] New: GNAT bug detected -- Storage_Error stack overflow or erroneous memory access

[keith at aquilonis dot net]

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

Bug ID: 69926
   Summary: GNAT bug detected -- Storage_Error stack overflow or
erroneous memory access
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: keith at aquilonis dot net
  Target Milestone: ---

Created attachment 37771
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37771=edit
source file to reproduce error

Internal error detected in GNAT



$ gcc -v -save-temps -c muscles.adb
Using built-in specs.
COLLECT_GCC=gcc
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.9.2-10'
--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-vtable-verify
--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-amd64/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.9-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --with-arch-32=i586 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.9.2 (Debian 4.9.2-10) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-c' '-mtune=generic' '-march=x86-64'
 /usr/lib/gcc/x86_64-linux-gnu/4.9/gnat1 -quiet -dumpbase muscles.adb -auxbase
muscles -mtune=generic -march=x86-64 muscles.adb -o muscles.s
+===GNAT BUG DETECTED==+
| 4.9.2 (x86_64-linux-gnu) Storage_Error stack overflow or erroneous memory
access|
| Error detected at muscles.adb:8:17   |
| Please submit a bug report; see http://gcc.gnu.org/bugs.html.|
| Use a subject line meaningful to you and us to track the bug.|
| Include the entire contents of this bug box in the report.   |
| Include the exact gcc-4.9 or gnatmake command that you entered.  |
| Also include sources listed below in gnatchop format |
| (concatenated together with no headers between files).   |
+==+

Please include these source files with error report
Note that list may not be accurate in some cases,
so please double check that the problem can still
be reproduced with the set of files listed.
Consider also -gnatd.n switch (see debug.adb).

muscles.adb
muscles.ads

:8:60: missing ")"
compilation abandoned

[Bug ada/69926] GNAT bug detected -- Storage_Error stack overflow or erroneous memory access

[keith at aquilonis dot net]

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

--- Comment #1 from Keith Godfrey  ---
Created attachment 37772
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37772=edit
specification source file

[Bug c++/69924] gcc5.2 compile Error: std::basic_istream: no match for 'operator>>', while gcc 4.8 works

[derrick at ca dot ibm.com]

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

derrick at ca dot ibm.com changed:

   What|Removed |Added

 Resolution|INVALID |FIXED

--- Comment #3 from derrick at ca dot ibm.com ---
"I assume you're compiling as C++11?"
- Oh, yes, with -std=c++11 flag:
  $g++ -std=c++11 ./_222d00_s.cpp -o test

"This is not valid C++11 code, there is no implicit conversion from streams to
void* or bool in C++11."

- But after I add static_cast, it still has the error. It looks like  
"loc" has some problem. If you think the code is invalid under C++11, could you
point out how I could modify the code to make it pass. Thanks.


#include 
#include 

inline int operator<<(void*,   const std::locale&) { return 1; }
inline int operator>>(void*,   const std::locale&) { return 1; }
inline int operator<<(bool,const std::locale&) { return 2; }
inline int operator>>(bool,const std::locale&) { return 2; }

int main(int argc, char *argv[])
{

  std::locale loc;
  if(static_cast(std::cin  >> loc)!=1)
 return 1;
  if(static_cast(std::cout << loc)!=1);
 return 1;

  return 0;
}

error: no match for 'operator>>' (operand types are 'std::istream {aka
std::basic_istream}' and 'std::locale')
if(static_cast(std::cin  >> loc)!=1)
 error: cannot bind 'std::istream {aka std::basic_istream}' lvalue to
'std::basic_istream&&'
if(static_cast(std::cin  >> loc)!=1)

[Bug fortran/61156] [4.9/5/6 Regression] Internal compiler error for Fortran files when specifying a file instead of an include directory with -I

[jvdelisle at gcc dot gnu.org]

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

--- Comment #8 from Jerry DeLisle  ---
(In reply to Dominique d'Humieres from comment #7)
> With the patch in comment 6 the test gfortran.dg/include_6.f90 has to be
> updated to
> 
> --- ../_clean/gcc/testsuite/gfortran.dg/include_6.f90 2012-08-02
> 01:26:03.0 +0200
> +++ gcc/testsuite/gfortran.dg/include_6.f90   2016-02-23 16:32:18.0
> +0100
> @@ -1,5 +1,5 @@
>  ! { dg-do compile }
>  ! { dg-options "-I gfortran.log" }
> -! { dg-warning "is not a directory" "" { target *-*-* } 0 }
> +! { dg-error "is not a directory" "" { target *-*-* } 0 }
>  end 
> -
> +! { dg-prune-output "compilation terminated." }

I did not think about trying prune, I did try dg-excess_error. I will try your
idea first.

[Bug fortran/69456] Namelist value with trailing sign is ignored without error

[jvdelisle at gcc dot gnu.org]

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

--- Comment #8 from Jerry DeLisle  ---
Fixed on trunk. Will leave open for a bit to see if there is any fallout.

[Bug fortran/69910] ICE with NEWUNIT

[jvdelisle at gcc dot gnu.org]

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

--- Comment #5 from Jerry DeLisle  ---
Patch tested.  It will be committed soon. Just need to go through the approval
process

[Bug fortran/69456] Namelist value with trailing sign is ignored without error

[jvdelisle at gcc dot gnu.org]

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

--- Comment #7 from Jerry DeLisle  ---
Author: jvdelisle
Date: Tue Feb 23 18:38:31 2016
New Revision: 233641

URL: https://gcc.gnu.org/viewcvs?rev=233641=gcc=rev
Log:
2016-02-23  Jerry DeLisle  

PR libgfortran/69456
* io/list_read.c (read_real): If digit is missing from exponent issue
an error. (parse_real): Likewise and adjusted error message to clarify
it is part of a complex number.
(nml_read_obj): Bump item count and add comment that this is used to
identify which item in a namelist read has a problem.

PR libgfortran/69456
* gfortran.dg/namelist_89.f90: New test.
* gfortran.dg/pr59700.f90: Update test..

Added:
trunk/gcc/testsuite/gfortran.dg/namelist_89.f90
Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/pr59700.f90
trunk/libgfortran/ChangeLog
trunk/libgfortran/io/list_read.c

[Bug c/69759] __builtin_alloca and __builtin_alloca_with_align undocumented

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Depends on|69780   |
 Resolution|--- |FIXED

--- Comment #7 from Martin Sebor  ---
Fixed by r233640.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69780
[Bug 69780] [4.9/5/6 Regression] ICE on  __builtin_alloca_with_align with small
alignment

[Bug c/69759] __builtin_alloca and __builtin_alloca_with_align undocumented

[msebor at gcc dot gnu.org]

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

Bug 69780 Summary: [4.9/5/6 Regression] ICE on  __builtin_alloca_with_align 
with small alignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69780

   What|Removed |Added

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

[Bug middle-end/69780] [4.9/5/6 Regression] ICE on __builtin_alloca_with_align with small alignment

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Blocks||69759
 Resolution|--- |FIXED

--- Comment #6 from Martin Sebor  ---
Fixed in r233640.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69759
[Bug 69759] __builtin_alloca and __builtin_alloca_with_align undocumented

[Bug middle-end/69780] [4.9/5/6 Regression] ICE on __builtin_alloca_with_align with small alignment

[msebor at gcc dot gnu.org]

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

--- Comment #5 from Martin Sebor  ---
Author: msebor
Date: Tue Feb 23 18:09:37 2016
New Revision: 233640

URL: https://gcc.gnu.org/viewcvs?rev=233640=gcc=rev
Log:
PR middle-end/69780 - [4.9/5/6 Regression] ICE on __builtin_alloca_with_align
with small alignment
PR c/69759 - __builtin_alloca and __builtin_alloca_with_align undocumented

gcc/c-family/ChangeLog:
* c-common.c (check_builtin_function_arguments): Validate and reject
invalid arguments to __builtin_alloca_with_align.

gcc/ChangeLog:
* doc/extend.texi (Other Builtins): Document __builtin_alloca and
__builtin_alloca_with_align.

gcc/testsuite/ChangeLog:
* g++.dg/ext/builtin_alloca.C: New test.
* gcc.dg/builtins-68.c: New test.

Added:
trunk/gcc/testsuite/g++.dg/ext/builtin_alloca.C
trunk/gcc/testsuite/gcc.dg/builtins-68.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-common.c
trunk/gcc/doc/extend.texi
trunk/gcc/testsuite/ChangeLog

[Bug c/69759] __builtin_alloca and __builtin_alloca_with_align undocumented

[msebor at gcc dot gnu.org]

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

--- Comment #6 from Martin Sebor  ---
Author: msebor
Date: Tue Feb 23 18:09:37 2016
New Revision: 233640

URL: https://gcc.gnu.org/viewcvs?rev=233640=gcc=rev
Log:
PR middle-end/69780 - [4.9/5/6 Regression] ICE on __builtin_alloca_with_align
with small alignment
PR c/69759 - __builtin_alloca and __builtin_alloca_with_align undocumented

gcc/c-family/ChangeLog:
* c-common.c (check_builtin_function_arguments): Validate and reject
invalid arguments to __builtin_alloca_with_align.

gcc/ChangeLog:
* doc/extend.texi (Other Builtins): Document __builtin_alloca and
__builtin_alloca_with_align.

gcc/testsuite/ChangeLog:
* g++.dg/ext/builtin_alloca.C: New test.
* gcc.dg/builtins-68.c: New test.

Added:
trunk/gcc/testsuite/g++.dg/ext/builtin_alloca.C
trunk/gcc/testsuite/gcc.dg/builtins-68.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-common.c
trunk/gcc/doc/extend.texi
trunk/gcc/testsuite/ChangeLog

[Bug preprocessor/69126] [6 regression] _Pragma does not apply if part of a macro

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #30 from David Malcolm  ---
The issue reported in comment #18 should be fixed as of r233638; marking this
one as resolved again.

[Bug preprocessor/69543] [6/7 Regression] _Pragma does not apply within macro

[dmalcolm at gcc dot gnu.org]

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

--- Comment #6 from David Malcolm  ---
Author: dmalcolm
Date: Tue Feb 23 17:44:28 2016
New Revision: 233638

URL: https://gcc.gnu.org/viewcvs?rev=233638=gcc=rev
Log:
PR preprocessor/69126: avoid comparing ad-hoc and non-ad-hoc locations

gcc/testsuite/ChangeLog:
PR preprocessor/69126
PR preprocessor/69543
* c-c++-common/pr69126-2-long.c: New test.
* c-c++-common/pr69126-2-short.c: New test.
* c-c++-common/pr69543-1.c: Remove xfail.

libcpp/ChangeLog:
PR preprocessor/69126
PR preprocessor/69543
* line-map.c (linemap_compare_locations): At the function top,
replace inlined bodies of get_location_from_adhoc_loc with calls
to get_location_from_adhoc_loc.  Add a pair of calls to
get_location_from_adhoc_loc at the bottom of the function, to
avoid meaningless comparisons of ad-hoc and non-ad-hoc locations.


Added:
trunk/gcc/testsuite/c-c++-common/pr69126-2-long.c
trunk/gcc/testsuite/c-c++-common/pr69126-2-short.c
Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/c-c++-common/pr69543-1.c
trunk/libcpp/ChangeLog
trunk/libcpp/line-map.c

[Bug preprocessor/69126] [6 regression] _Pragma does not apply if part of a macro

[dmalcolm at gcc dot gnu.org]

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

--- Comment #29 from David Malcolm  ---
Author: dmalcolm
Date: Tue Feb 23 17:44:28 2016
New Revision: 233638

URL: https://gcc.gnu.org/viewcvs?rev=233638=gcc=rev
Log:
PR preprocessor/69126: avoid comparing ad-hoc and non-ad-hoc locations

gcc/testsuite/ChangeLog:
PR preprocessor/69126
PR preprocessor/69543
* c-c++-common/pr69126-2-long.c: New test.
* c-c++-common/pr69126-2-short.c: New test.
* c-c++-common/pr69543-1.c: Remove xfail.

libcpp/ChangeLog:
PR preprocessor/69126
PR preprocessor/69543
* line-map.c (linemap_compare_locations): At the function top,
replace inlined bodies of get_location_from_adhoc_loc with calls
to get_location_from_adhoc_loc.  Add a pair of calls to
get_location_from_adhoc_loc at the bottom of the function, to
avoid meaningless comparisons of ad-hoc and non-ad-hoc locations.


Added:
trunk/gcc/testsuite/c-c++-common/pr69126-2-long.c
trunk/gcc/testsuite/c-c++-common/pr69126-2-short.c
Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/c-c++-common/pr69543-1.c
trunk/libcpp/ChangeLog
trunk/libcpp/line-map.c

[Bug c/69918] [6 regression] gcc.dg/torture/builtin-integral-1.c FAILs

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-02-23
 CC||jakub at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
So, what seems to be going on is that Solaris is the only target that adds
-std=c99 in add_options_for_c99_runtime, and -std=c99 (as opposed to
-std=gnu99) enables -fexcess-precision=standard, which on Solaris (but also on
i386-linux) 
means there is more code.
With -fexcess-precision=fast we e.g. get:
  _388 = (double) i1_63(D);
  _389 = (double) i2_335(D);
  _390 = _388 * _389;
  _391 = (long double) _390;
  _392 = __builtin_ceill (_391);
while with -fexcess-precision=standard we get corresponding:
  _398 = (double) i1_63(D);
  _399 = (long double) _398;
  _400 = (double) i2_335(D);
  _401 = (long double) _400;
  _402 = _399 * _401;
  _403 = __builtin_ceill (_402);
GCC is actually able to optimize even the latter, but only with --param
max-ssa-name-query-depth=3 or higher (default is 2).

Thus, for testsuite only fix for this PR, one possibility is add
-fexcess-precision=fast
to dg-options, another one is to add
-param max-ssa-name-query-depth=3
to dg-options.

Or, perhaps we could bump the max-ssa-name-query-depth default from 2 to 3. 
I'll bootstrap/regtest this last option on x86_64-linux and i686-linux, to see
if it doesn't break anything.

Richard, any preferences?

[Bug preprocessor/69543] [6/7 Regression] _Pragma does not apply within macro

[dmalcolm at gcc dot gnu.org]

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

--- Comment #5 from David Malcolm  ---
Author: dmalcolm
Date: Tue Feb 23 17:39:16 2016
New Revision: 233637

URL: https://gcc.gnu.org/viewcvs?rev=233637=gcc=rev
Log:
Add test coverage for _Pragma (PR preprocessor 69126, 69543, 69558)

We had some regressions in the ability for _Pragma to disable a warning
(PR preprocessor/69126, PR preprocessor/69543, PR preprocessor/69558).

This patch attempts to add more test coverage for this, for the
various combinations of:
  - various warnings:
-Wunused-variable
-Wuninitialized
-Wdeprecated-declarations
  - various combinations of location of _Pragma relative to location of
the warning:
 - _Pragma is in a macro, warning isn't a macro
 - neither is in a macro
 - _Pragma isnt't in a macro, warning is in a macro
 - in different macros
 - both in the same macro
  - C vs C++ frontend.

It adds some XFAILs:
  - pr69543-1.c for C++ (fixed in the followup patch)
  - pr69543-3.c for both C and C++
  - pr69543-4.c for both C and C++
  - pr69558.c for C++ (moving it from gcc.dg to c-c++-common,
marking it as xfail for C++ for now)

gcc/testsuite/ChangeLog:
PR preprocessor/69126
PR preprocessor/69543
PR preprocessor/69558
* c-c++-common/pr69126.c (MACRO_1, test_1): New.
(f): Rename to...
(test_2): ...this, and add leading comment.
(MACRO_3, test_3): New.
(MACRO_4A, MACRO_4B, test_4): New.
(MACRO): Rename to...
(MACRO_5): ...this.
(g): Rename to...
(test_5): ...this, updating for renaming of MACRO, and
add leading comment.
* c-c++-common/pr69543-1.c: New.
* c-c++-common/pr69543-2.c: New.
* c-c++-common/pr69543-3.c: New.
* c-c++-common/pr69543-4.c: New.
* c-c++-common/pr69558-1.c: New.
* c-c++-common/pr69558-2.c: New.
* c-c++-common/pr69558-3.c: New.
* c-c++-common/pr69558-4.c: New.
* gcc.dg/pr69558.c: Move to...
* c-c++-common/pr69558.c: ...here.  Add dg-bogus directives, with
xfail for c++.


Added:
trunk/gcc/testsuite/c-c++-common/pr69543-1.c
trunk/gcc/testsuite/c-c++-common/pr69543-2.c
trunk/gcc/testsuite/c-c++-common/pr69543-3.c
trunk/gcc/testsuite/c-c++-common/pr69543-4.c
trunk/gcc/testsuite/c-c++-common/pr69558-1.c
trunk/gcc/testsuite/c-c++-common/pr69558-2.c
trunk/gcc/testsuite/c-c++-common/pr69558-3.c
trunk/gcc/testsuite/c-c++-common/pr69558-4.c
trunk/gcc/testsuite/c-c++-common/pr69558.c
  - copied, changed from r233636, trunk/gcc/testsuite/gcc.dg/pr69558.c
Removed:
trunk/gcc/testsuite/gcc.dg/pr69558.c
Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/c-c++-common/pr69126.c

[Bug c/69558] [6/7 Regression] glib2 warning pragmas stopped working

[dmalcolm at gcc dot gnu.org]

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

--- Comment #14 from David Malcolm  ---
Author: dmalcolm
Date: Tue Feb 23 17:39:16 2016
New Revision: 233637

URL: https://gcc.gnu.org/viewcvs?rev=233637=gcc=rev
Log:
Add test coverage for _Pragma (PR preprocessor 69126, 69543, 69558)

We had some regressions in the ability for _Pragma to disable a warning
(PR preprocessor/69126, PR preprocessor/69543, PR preprocessor/69558).

This patch attempts to add more test coverage for this, for the
various combinations of:
  - various warnings:
-Wunused-variable
-Wuninitialized
-Wdeprecated-declarations
  - various combinations of location of _Pragma relative to location of
the warning:
 - _Pragma is in a macro, warning isn't a macro
 - neither is in a macro
 - _Pragma isnt't in a macro, warning is in a macro
 - in different macros
 - both in the same macro
  - C vs C++ frontend.

It adds some XFAILs:
  - pr69543-1.c for C++ (fixed in the followup patch)
  - pr69543-3.c for both C and C++
  - pr69543-4.c for both C and C++
  - pr69558.c for C++ (moving it from gcc.dg to c-c++-common,
marking it as xfail for C++ for now)

gcc/testsuite/ChangeLog:
PR preprocessor/69126
PR preprocessor/69543
PR preprocessor/69558
* c-c++-common/pr69126.c (MACRO_1, test_1): New.
(f): Rename to...
(test_2): ...this, and add leading comment.
(MACRO_3, test_3): New.
(MACRO_4A, MACRO_4B, test_4): New.
(MACRO): Rename to...
(MACRO_5): ...this.
(g): Rename to...
(test_5): ...this, updating for renaming of MACRO, and
add leading comment.
* c-c++-common/pr69543-1.c: New.
* c-c++-common/pr69543-2.c: New.
* c-c++-common/pr69543-3.c: New.
* c-c++-common/pr69543-4.c: New.
* c-c++-common/pr69558-1.c: New.
* c-c++-common/pr69558-2.c: New.
* c-c++-common/pr69558-3.c: New.
* c-c++-common/pr69558-4.c: New.
* gcc.dg/pr69558.c: Move to...
* c-c++-common/pr69558.c: ...here.  Add dg-bogus directives, with
xfail for c++.


Added:
trunk/gcc/testsuite/c-c++-common/pr69543-1.c
trunk/gcc/testsuite/c-c++-common/pr69543-2.c
trunk/gcc/testsuite/c-c++-common/pr69543-3.c
trunk/gcc/testsuite/c-c++-common/pr69543-4.c
trunk/gcc/testsuite/c-c++-common/pr69558-1.c
trunk/gcc/testsuite/c-c++-common/pr69558-2.c
trunk/gcc/testsuite/c-c++-common/pr69558-3.c
trunk/gcc/testsuite/c-c++-common/pr69558-4.c
trunk/gcc/testsuite/c-c++-common/pr69558.c
  - copied, changed from r233636, trunk/gcc/testsuite/gcc.dg/pr69558.c
Removed:
trunk/gcc/testsuite/gcc.dg/pr69558.c
Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/c-c++-common/pr69126.c

[Bug preprocessor/69126] [6 regression] _Pragma does not apply if part of a macro

[dmalcolm at gcc dot gnu.org]

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

--- Comment #28 from David Malcolm  ---
Author: dmalcolm
Date: Tue Feb 23 17:39:16 2016
New Revision: 233637

URL: https://gcc.gnu.org/viewcvs?rev=233637=gcc=rev
Log:
Add test coverage for _Pragma (PR preprocessor 69126, 69543, 69558)

We had some regressions in the ability for _Pragma to disable a warning
(PR preprocessor/69126, PR preprocessor/69543, PR preprocessor/69558).

This patch attempts to add more test coverage for this, for the
various combinations of:
  - various warnings:
-Wunused-variable
-Wuninitialized
-Wdeprecated-declarations
  - various combinations of location of _Pragma relative to location of
the warning:
 - _Pragma is in a macro, warning isn't a macro
 - neither is in a macro
 - _Pragma isnt't in a macro, warning is in a macro
 - in different macros
 - both in the same macro
  - C vs C++ frontend.

It adds some XFAILs:
  - pr69543-1.c for C++ (fixed in the followup patch)
  - pr69543-3.c for both C and C++
  - pr69543-4.c for both C and C++
  - pr69558.c for C++ (moving it from gcc.dg to c-c++-common,
marking it as xfail for C++ for now)

gcc/testsuite/ChangeLog:
PR preprocessor/69126
PR preprocessor/69543
PR preprocessor/69558
* c-c++-common/pr69126.c (MACRO_1, test_1): New.
(f): Rename to...
(test_2): ...this, and add leading comment.
(MACRO_3, test_3): New.
(MACRO_4A, MACRO_4B, test_4): New.
(MACRO): Rename to...
(MACRO_5): ...this.
(g): Rename to...
(test_5): ...this, updating for renaming of MACRO, and
add leading comment.
* c-c++-common/pr69543-1.c: New.
* c-c++-common/pr69543-2.c: New.
* c-c++-common/pr69543-3.c: New.
* c-c++-common/pr69543-4.c: New.
* c-c++-common/pr69558-1.c: New.
* c-c++-common/pr69558-2.c: New.
* c-c++-common/pr69558-3.c: New.
* c-c++-common/pr69558-4.c: New.
* gcc.dg/pr69558.c: Move to...
* c-c++-common/pr69558.c: ...here.  Add dg-bogus directives, with
xfail for c++.


Added:
trunk/gcc/testsuite/c-c++-common/pr69543-1.c
trunk/gcc/testsuite/c-c++-common/pr69543-2.c
trunk/gcc/testsuite/c-c++-common/pr69543-3.c
trunk/gcc/testsuite/c-c++-common/pr69543-4.c
trunk/gcc/testsuite/c-c++-common/pr69558-1.c
trunk/gcc/testsuite/c-c++-common/pr69558-2.c
trunk/gcc/testsuite/c-c++-common/pr69558-3.c
trunk/gcc/testsuite/c-c++-common/pr69558-4.c
trunk/gcc/testsuite/c-c++-common/pr69558.c
  - copied, changed from r233636, trunk/gcc/testsuite/gcc.dg/pr69558.c
Removed:
trunk/gcc/testsuite/gcc.dg/pr69558.c
Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/c-c++-common/pr69126.c

[Bug fortran/69368] [6 Regression] spec2006 test case 416.gamess fails with the g++ 6.0 compiler starting with r232508

[tkoenig at gcc dot gnu.org]

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

--- Comment #80 from Thomas Koenig  ---
(In reply to alalaw01 from comment #79)

> Is the concern that we can't hide this behind an option, as that would
> "drive people away from gfortran" ? If that's the case, can we hide it
> behind an option that defaults to pessimization (?? at least for fortran)??

The concern would be if we did not provide a reasonable way around this.

I am not in favor of pessimizing valid code by default :-)

My preference would be to hide it behind an option, include this
option in -std=legacy, and warn from the gfortran front end (with -Wall)
if the construct in question (or questionable construct) is encountered.
The warning could tell the user which option to select in this case.

A one-element array trailing a common block is legal, but its normal
use should be quite rare, because it can be replaced without problems
with a scalar variable, so I doubt we will generate many false positives.
And even if we do, we now have the nice feature of displaying the
option which issued the warning, so people should have no problem
turning it off.

[Bug c++/69924] gcc5.2 compile Error: std::basic_istream: no match for 'operator>>', while gcc 4.8 works

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #2 from Jonathan Wakely  ---
Ah yes, or you wouldn't get the rvalue overload.

Please makes sure you state the relevant compiler flags so we don't have to
guess.

This is not valid C++11 code, there is no implicit conversion from streams to
void* or bool in C++11.

[Bug c++/69924] gcc5.2 compile Error: std::basic_istream: no match for 'operator>>', while gcc 4.8 works

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
I assume you're compiling as C++11?

[Bug c++/69925] No warning for uninitialized char * passing to function as const char *

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
There is another bug about this specific thing already.  But note someone can
do a const_cast and remove the const part and start assigning values to the
array so it is not always considered as unitialized.

[Bug c++/69925] New: No warning for uninitialized char * passing to function as const char *

[developm...@faf-ltd.com]

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

Bug ID: 69925
   Summary: No warning for uninitialized char * passing to
function as const char *
   Product: gcc
   Version: 4.9.3
Status: UNCONFIRMED
  Severity: trivial
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: developm...@faf-ltd.com
  Target Milestone: ---

auto foo( const char * ) -> void;

int main()
{
char bar [100];

foo( bar );
}

In my opinion gcc should warn that bar is uninitialized used due to the fact it
is used as const in foo().

g++ -Wall -Wextra -Werror -c foo.cpp

I have to admit that I could not find any compiler which warns about this:
https://goo.gl/0d6KU4

[Bug c++/69922] [6 Regression] Bogus -Wnonnull-compare for: ... ? static_cast<T*>(this) : nullptr

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||diagnostic
   Target Milestone|--- |6.0
Summary|Bogus -Wnonnull-compare |[6 Regression] Bogus
   |for: ... ?  |-Wnonnull-compare for: ...
   |static_cast(this) : |? static_cast(this) :
   |nullptr |nullptr

--- Comment #3 from Andrew Pinski  ---
Most likely it is due to multiple inheritance which causes GCC internally to
emit a comparison and GCC decides to warn about that comparison when it should
not.

[Bug c++/69924] New: gcc5.2 compile Error: std::basic_istream: no match for 'operator>>', while gcc 4.8 works

[derrick at ca dot ibm.com]

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

Bug ID: 69924
   Summary: gcc5.2 compile Error: std::basic_istream: no match for
'operator>>', while gcc 4.8 works
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: derrick at ca dot ibm.com
  Target Milestone: ---

For the following code, it compiles successfully on gcc 4.8, but fails on gcc
5.2

#include 
#include 

inline int operator<<(void*,   const std::locale&) { return 1; }
inline int operator>>(void*,   const std::locale&) { return 1; }
inline int operator<<(bool,const std::locale&) { return 2; }
inline int operator>>(bool,const std::locale&) { return 2; }

int main(int argc, char *argv[])
{

  std::locale loc;
  if((std::cin  >> loc)!=1)
 return 1;
  if((std::cout << loc)!=1);
 return 1;

  return 0;
}

error: no match for 'operator>>' (operand types are 'std::istream {aka
std::basic_istream}' and 'std::locale')
if((std::cin  >> loc)!=1)
error: cannot bind 'std::istream {aka std::basic_istream}' lvalue to
'std::basic_istream&&'
if((std::cin  >> loc)!=1)

[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

alalaw01 at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #5 from alalaw01 at gcc dot gnu.org ---
Can I class this as fixed?

[Bug middle-end/66877] [6 Regression] FAIL: gcc.dg/vect/vect-over-widen-3-big-array.c -flto -ffat-lto-objects scan-tree-dump-times vect "vect_recog_over_widening_pattern: detected" 2

[alalaw01 at gcc dot gnu.org]

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

alalaw01 at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #8 from alalaw01 at gcc dot gnu.org ---
Fix committed r232720.

[Bug bootstrap/69709] [6 Regression] profiled bootstrap error on s390x-linux-gnu with r233194

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
FYI, profiledbootstrap works for me including Ada,
see
http://s390.koji.fedoraproject.org/packages/gcc/6.0.0/0.12.fc24/data/logs/s390x/build.log

[Bug c++/69889] [6 Regression] ICE: in assign_temp, at function.c:961

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
This looks like a C++ FE bug to me, the operator() method is called with
TREE_ADDRESSABLE argument by value, rather than by reference.
Normally, when the C++ FE goes through build_over_call, convert_for_arg_passing
(or earlier code) should change those arguments to reference passing.
On this testcase the call is generated from simplify_aggr_init_expr, and is
passed by value instead.  I don't know the FE enough to know if it should be
already aggr_init_expr AGGR_INIT_EXPR_ARGP argument to be actually the
reference, or if it is a simplify_aggr_init_expr bug.
Jason, can you please have a look?

[Bug rtl-optimization/69891] wrong code with -mstringop-strategy=libcall @ i686

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu.org,
   ||law at redhat dot com

--- Comment #2 from Uroš Bizjak  ---
Adding some CCs for RTL-opt problems.

[Bug c/69923] [6 regression] internal compiler error in cgraphunit.c when using -Wall

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||trippels at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #2 from Markus Trippelsdorf  ---
dup.

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

[Bug c/69911] [6 Regression] Massive test failures on ia32

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||daniel at fahlgren dot se

--- Comment #6 from Markus Trippelsdorf  ---
*** Bug 69923 has been marked as a duplicate of this bug. ***

[Bug libstdc++/69881] with gcc-6 of today building gcc-4.9 fails

[bernd.edlinger at hotmail dot de]

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

Bernd Edlinger  changed:

   What|Removed |Added

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

--- Comment #24 from Bernd Edlinger  ---
fixed.

[Bug c/69923] [6 regression] internal compiler error in cgraphunit.c when using -Wall

[daniel at fahlgren dot se]

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

--- Comment #1 from Daniel Fahlgren  ---
Created attachment 37770
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37770=edit
Pre-processed test case

[Bug c/69923] New: [6 regression] internal compiler error in cgraphunit.c when using -Wall

[daniel at fahlgren dot se]

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

Bug ID: 69923
   Summary: [6 regression] internal compiler error in cgraphunit.c
when using -Wall
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: daniel at fahlgren dot se
  Target Milestone: ---

Created attachment 37769
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37769=edit
Simple test case

When compiling with -Wall cc1 gets an internal compiler error. The the command
line used is: gcc-6.0 -Wall bug.c

cc1: internal compiler error: Segmentation fault
0xb2493f crash_signal
  ../.././gcc/toplev.c:335
0x75067d check_global_declaration
  ../.././gcc/cgraphunit.c:947
0x75067d analyze_functions
  ../.././gcc/cgraphunit.c:1168
0x750f58 symbol_table::finalize_compilation_unit()
  ../.././gcc/cgraphunit.c:2537
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

This is with gcc trunk, Revision: 233620

When compiling without -Wall the compiler does not crash. Attached is a
reproduced test case as well as the preprocessed file. The test case was
created with creduce.

[Bug c++/69922] Bogus -Wnonnull-compare for: ... ? static_cast<T*>(this) : nullptr

[trippels at gcc dot gnu.org]

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

--- Comment #2 from Markus Trippelsdorf  ---
(In reply to Stephan Bergmann from comment #0)
> With trunk@233631:
> 
> > $ cat test.cc
> > struct S2 { virtual ~S2(); };
> > struct S1 {
> > virtual ~S1();
> > S2 * f(bool);
> > };
> > struct S3: S1, S2 {};
> > S2 * S1::f(bool b) { return b ? static_cast(this) : nullptr; }
> 
> > $ g++ -Werror -Wnonnull-compare -c test.cc
> > test.cc: In member function ‘S2* S1::f(bool)’:
> > test.cc:7:59: error: nonnull argument ‘this’ compared to NULL 
> > [-Werror=nonnull-compare]
> >  S2 * S1::f(bool b) { return b ? static_cast(this) : nullptr; }
> >^~~
> > cc1plus: all warnings being treated as errors

BTW, this style of posting (quoting the code) makes copy it
unnecessary hard. Please avoid it in the future.

[Bug libstdc++/69881] with gcc-6 of today building gcc-4.9 fails

[edlinger at gcc dot gnu.org]

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

--- Comment #23 from Bernd Edlinger  ---
Author: edlinger
Date: Tue Feb 23 15:57:09 2016
New Revision: 233636

URL: https://gcc.gnu.org/viewcvs?rev=233636=gcc=rev
Log:
2016-02-23  Bernd Edlinger  

PR libstdc++/69881
* include/c_global/cstdarg: Undefine __need___va_list.
* include/c_global/cstddef: Undefine all kinds of __need_*.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/c_global/cstdarg
trunk/libstdc++-v3/include/c_global/cstddef

[Bug c++/69922] Bogus -Wnonnull-compare for: ... ? static_cast<T*>(this) : nullptr

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||trippels at gcc dot gnu.org

--- Comment #1 from Markus Trippelsdorf  ---
Jakub, can you please check all the different C++ casts for similar issues?

dynamic_cast (should be fine now)
reinterpret_cast
static_cast
const_cast

[Bug tree-optimization/68963] [4.9/5/6 Regression] O3 vs. O2 discards part of loop and terminates early

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
Hmm, I think it's rather discover_iteration_bound_by_body_walk that merges the
two estimates of 3 iterations from both arms even though those are not based
off the same IV.  OTOH the estimates itself assume we are talking about the
first N iterations not any N iterations.  So it might be fundamentally flawed.

Testsuite fallout from the patch which shows recording those upper bounds was
intended:

FAIL: gcc.dg/tree-ssa/cunroll-10.c scan-tree-dump-times cunroll "Forced
statemen
t unreachable" 2
FAIL: gcc.dg/tree-ssa/cunroll-11.c scan-tree-dump cunroll "Loop 1 iterates at
mo
st 3 times"
FAIL: gcc.dg/tree-ssa/cunroll-9.c scan-tree-dump-times cunrolli "Removed
pointle
ss exit:" 1
FAIL: gcc.dg/tree-ssa/loop-38.c scan-tree-dump cunrolli "Loop 1 iterates at
most
 11 times"

Honza?

[Bug fortran/61156] [4.9/5/6 Regression] Internal compiler error for Fortran files when specifying a file instead of an include directory with -I

[dominiq at lps dot ens.fr]

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

--- Comment #7 from Dominique d'Humieres  ---
With the patch in comment 6 the test gfortran.dg/include_6.f90 has to be
updated to

--- ../_clean/gcc/testsuite/gfortran.dg/include_6.f90   2012-08-02
01:26:03.0 +0200
+++ gcc/testsuite/gfortran.dg/include_6.f90 2016-02-23 16:32:18.0
+0100
@@ -1,5 +1,5 @@
 ! { dg-do compile }
 ! { dg-options "-I gfortran.log" }
-! { dg-warning "is not a directory" "" { target *-*-* } 0 }
+! { dg-error "is not a directory" "" { target *-*-* } 0 }
 end 
-
+! { dg-prune-output "compilation terminated." }

[Bug c++/69922] New: Bogus -Wnonnull-compare for: ... ? static_cast<T*>(this) : nullptr

[sbergman at redhat dot com]

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

Bug ID: 69922
   Summary: Bogus -Wnonnull-compare for: ... ?
static_cast(this) : nullptr
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sbergman at redhat dot com
  Target Milestone: ---

With trunk@233631:

> $ cat test.cc
> struct S2 { virtual ~S2(); };
> struct S1 {
> virtual ~S1();
> S2 * f(bool);
> };
> struct S3: S1, S2 {};
> S2 * S1::f(bool b) { return b ? static_cast(this) : nullptr; }

> $ g++ -Werror -Wnonnull-compare -c test.cc
> test.cc: In member function ‘S2* S1::f(bool)’:
> test.cc:7:59: error: nonnull argument ‘this’ compared to NULL 
> [-Werror=nonnull-compare]
>  S2 * S1::f(bool b) { return b ? static_cast(this) : nullptr; }
>^~~
> cc1plus: all warnings being treated as errors

[Bug fortran/69368] [6 Regression] spec2006 test case 416.gamess fails with the g++ 6.0 compiler starting with r232508

[alalaw01 at gcc dot gnu.org]

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

--- Comment #79 from alalaw01 at gcc dot gnu.org ---
(In reply to rguent...@suse.de from comment #78)
>
> That would pessimize it too much IMHO.

I'm not sure how to evaluate the pessimization, given it's thought to be a
widespread pseudo-FORTRAN construct; so I probably have to defer to your
judgement here. However...

Given maxsize of an array as two elements, say, would the compiler not be
entitled to optimize an index selection down to, say, computing only the LSBit
of the actual index?  Whereas 'unknown' means, well, exactly what is the case.
So I fear this is storing problems up for the future.

Is the concern that we can't hide this behind an option, as that would "drive
people away from gfortran" ? If that's the case, can we hide it behind an
option that defaults to pessimization (?? at least for fortran)??

[Bug middle-end/69920] [6 Regression] FAIL: g++.dg/torture/pr42704.C -O2 -flto -fno-use-linker-plugin -flto-partition=none (internal compiler error)

[jamborm at gcc dot gnu.org]

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

Martin Jambor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-02-23
   Assignee|unassigned at gcc dot gnu.org  |jamborm at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #3 from Martin Jambor  ---
Ah, I missed the "x86" part (when the target field is not filled in, I
always tend to think it's x86_64).  I can reproduce the failure now
and will take care of it.

[Bug middle-end/69920] [6 Regression] FAIL: g++.dg/torture/pr42704.C -O2 -flto -fno-use-linker-plugin -flto-partition=none (internal compiler error)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target||i?86-*-*
   Priority|P3  |P1
   Target Milestone|--- |6.0

[Bug fortran/69368] [6 Regression] spec2006 test case 416.gamess fails with the g++ 6.0 compiler starting with r232508

[rguenther at suse dot de]

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

--- Comment #78 from rguenther at suse dot de  ---
On Tue, 23 Feb 2016, alalaw01 at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69368
> 
> --- Comment #77 from alalaw01 at gcc dot gnu.org ---
> (In reply to rguent...@suse.de from comment #72)
> > 
> > Patch as posted passed bootstrap & regtest.  Adjusted according to 
> > comments but not tested otherwise - please somebody throw at
> > unpatched 416.gamess.
> 
> Still miscompares on aarch64, I'm afraid. (Both with and without
> -fno-aggressive-loop-optimizations.)
> 
> Also where Jakub wrote:
> > If you want to go this way, I'd at least key it off DECL_COMMON on the decl.
> > And instead of multiplying max_size by 2 perhaps just add BITS_PER_UNIT?
> 
> I wonder why you prefer setting such an arbitrary guess at max_size rather 
> than
> going with -1 which is defined as "unknown" ?

That would pessimize it too much IMHO.

[Bug middle-end/69921] New: Switch OpenACC kernels number of gangs from "decide at run time" to "decide at compile time"

[tschwinge at gcc dot gnu.org]

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

Bug ID: 69921
   Summary: Switch OpenACC kernels number of gangs from "decide at
run time" to "decide at compile time"
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Keywords: openacc
  Severity: minor
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: nathan at gcc dot gnu.org, vries at gcc dot gnu.org
  Target Milestone: ---

Follow-up to r233634.  See
.

For OpenACC kernels, gcc/tree-parloops.c:create_parallel_loop currently sets:

OMP_CLAUSE_NUM_GANGS_EXPR (clause) = n_threads;

..., so to zero ("decide at run time").

| Originally, I want to use:
| 
| OMP_CLAUSE_NUM_GANGS_EXPR (clause) = build_int_cst (integer_type_node,
n_threads == 0 ? -1 : n_threads);
| 
| ... to store -1 "have the compiler decidew" (instead of now 0 "have the
| run-time decide", which might prevent some code optimizations, as I
| understand it) for the n_threads == 0 case, but it seems that for an
| offloaded OpenACC kernels region, gcc/omp-low.c:oacc_validate_dims is
| called with the parameter "used" set to 0 instead of "gang", and then the
| "Default anything left to 1 or a partitioned default" logic will default
| dims["gang"] to oacc_min_dims["gang"] (that is, 1) instead of the
| oacc_default_dims["gang"] (that is, 32).  Nathan, does that smell like a
| bug (and could you look into that)?

[Bug middle-end/69919] pool allocator and mem-stat race at program exit

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
Or maybe simply making mem_alloc_description::~mem_alloc_description () empty.

[Bug middle-end/69920] [6 Regression] FAIL: g++.dg/torture/pr42704.C -O2 -flto -fno-use-linker-plugin -flto-partition=none (internal compiler error)

[jamborm at gcc dot gnu.org]

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

--- Comment #2 from Martin Jambor  ---
(In reply to H.J. Lu from comment #1)
> It may be caused by r233626.

What do you mean by "may be?"  I have just double checked that if I
apply the patch to r233489 and run the test, it passes here on my
x86_64-linux.

Anyway, once I move to a newer trunk (in a day or three), I'll check
again by reverting the change... unless someone finds a different
culprit in the meantime.

[Bug middle-end/69915] [6 Regression] ICE: SIGSEGV with -O -ftracer with broken backtrace

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Created attachment 37768
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37768=edit
gcc6-pr69915.patch

Untested fix.

[Bug c++/69736] [4.9/5/6 Regression] "error: too few arguments to function" in c++14 but not c++11

[ppalka at gcc dot gnu.org]

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

Patrick Palka  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-02-23
   Assignee|unassigned at gcc dot gnu.org  |ppalka at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #7 from Patrick Palka  ---
A patch is posted at: https://gcc.gnu.org/ml/gcc-patches/2016-02/msg01587.html

[Bug fortran/69368] [6 Regression] spec2006 test case 416.gamess fails with the g++ 6.0 compiler starting with r232508

[alalaw01 at gcc dot gnu.org]

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

--- Comment #77 from alalaw01 at gcc dot gnu.org ---
(In reply to rguent...@suse.de from comment #72)
> 
> Patch as posted passed bootstrap & regtest.  Adjusted according to 
> comments but not tested otherwise - please somebody throw at
> unpatched 416.gamess.

Still miscompares on aarch64, I'm afraid. (Both with and without
-fno-aggressive-loop-optimizations.)

Also where Jakub wrote:
> If you want to go this way, I'd at least key it off DECL_COMMON on the decl.
> And instead of multiplying max_size by 2 perhaps just add BITS_PER_UNIT?

I wonder why you prefer setting such an arbitrary guess at max_size rather than
going with -1 which is defined as "unknown" ?

[Bug middle-end/69915] [6 Regression] ICE: SIGSEGV with -O -ftracer with broken backtrace

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #3 from Jakub Jelinek  ---
Mine.

[Bug middle-end/69919] pool allocator and mem-stat race at program exit

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||mliska at suse dot cz

--- Comment #1 from Richard Biener  ---
Too much C++ here I guess?

==16301==by 0x14DCE52:
mem_alloc_description::~mem_alloc_description() (mem-stats.h:559)

vs.

==16301==by 0x8427C4: base_pool_allocator::release()
(alloc-pool.h:311)
==16301==by 0x84299D:
base_pool_allocator::~base_pool_allocator()
(alloc-pool.h:335)
==16301==by 0x8E25D3: object_allocator::~object_allocator()
(alloc-pool.h:474)

where the latter calls release_instance_overhead.

extern mem_alloc_description pool_allocator_usage;

comes from alloc-pool.c.  Looks like when linking LTO we get the bad destructor
order (by luck?).

Leaking pool_allocator_usage will fix this (making it a reference).  A very
bit ugly though.

Index: gcc/alloc-pool.c
===
--- gcc/alloc-pool.c(revision 233633)
+++ gcc/alloc-pool.c(working copy)
@@ -24,7 +24,7 @@ along with GCC; see the file COPYING3.
 #include "alloc-pool.h"

 ALLOC_POOL_ID_TYPE last_id;
-mem_alloc_description pool_allocator_usage;
+mem_alloc_description _allocator_usage = *(new
mem_alloc_description);

 /* Output per-alloc_pool memory usage statistics.  */
 void
Index: gcc/alloc-pool.h
===
--- gcc/alloc-pool.h(revision 233633)
+++ gcc/alloc-pool.h(working copy)
@@ -95,7 +95,7 @@ struct pool_usage: public mem_usage
   const char *m_pool_name;
 };

-extern mem_alloc_description pool_allocator_usage;
+extern mem_alloc_description _allocator_usage;

 #if 0
 /* If a pool with custom block size is needed, one might use the following

[Bug middle-end/69916] [openacc] ICE in single_succ_edge called from oacc_loop_xform_loop

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

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

[Bug middle-end/69916] [openacc] ICE in single_succ_edge called from oacc_loop_xform_loop

[tschwinge at gcc dot gnu.org]

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

Thomas Schwinge  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-02-23
 CC||nathan at gcc dot gnu.org
  Component|libgomp |middle-end
 Ever confirmed|0   |1

--- Comment #2 from Thomas Schwinge  ---
Confirmed.  Well, j has an undefined value, but that shouldn't cause an ICE.

Without having looked at any dump files, I guess that GCC optimizes away the
unused increment of j, optimizes away the whole for loop, and is left with an
"empty" OMP_FOR (OACC_LOOP) construct, which possibly confuses the OpenACC loop
partitioning code.  Nathan, do you want to have a look?