[Bug sanitizer/69863] New: no_sanitize_address doesn't disable stack instrumentation

[ryabinin.a.a at gmail dot com]

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

Bug ID: 69863
   Summary: no_sanitize_address doesn't disable stack
instrumentation
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ryabinin.a.a at gmail dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
  Target Milestone: ---

Attribute no_sanitize_address doesn't disable instrumentation completely.

Apparently no_sanitize_address only disables memory access checks, but it 
doesn't have influence on stack redzones. 
Regardless of this attribute gcc creates and poisons/unpoisons stack redzones.

$ cat no_sanitize_stack_test.c 

void g(int *a);

__attribute__((no_sanitize_address))
void func(void)
{
int a;
g(&a);
}

$ gcc -fsanitize=address -c no_sanitize_stack_test.c && objdump -d
no_sanitize_stack_test.o

 :


  4d:   49 c1 ec 03 shr$0x3,%r12
  51:   41 c7 84 24 00 80 ffmovl   $0xf1f1f1f1,0x7fff8000(%r12)
  58:   7f f1 f1 f1 f1 
  5d:   41 c7 84 24 04 80 ffmovl   $0xf4f4f404,0x7fff8004(%r12)
  64:   7f 04 f4 f4 f4 
  69:   41 c7 84 24 08 80 ffmovl   $0xf3f3f3f3,0x7fff8008(%r12)
  70:   7f f3 f3 f3 f3 
  75:   64 48 8b 14 25 28 00mov%fs:0x28,%rdx

[Bug middle-end/69854] [6 regression] ICE: tree check: expected class 'constant', have 'binary' (plus_expr) in generic_simplify_65, at generic-match.c:3110

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug middle-end/69854] [6 regression] ICE: tree check: expected class 'constant', have 'binary' (plus_expr) in generic_simplify_65, at generic-match.c:3110

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Author: rguenth
Date: Thu Feb 18 08:43:58 2016
New Revision: 233516

URL: https://gcc.gnu.org/viewcvs?rev=233516&root=gcc&view=rev
Log:
2016-02-18  Richard Biener  

PR middle-end/69854
* match.pd: Don't use fold_binary or fold_unary for folding
constants.

* gcc.dg/torture/pr69854.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr69854.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/match.pd
trunk/gcc/testsuite/ChangeLog

[Bug c++/67767] -Wsuggest-attribute=noreturn suggests noreturn for function which already has noreturn and cold.

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #3 from Jakub Jelinek  ---
Created attachment 37727
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37727&action=edit
gcc6-pr67767.patch

Untested fix.

[Bug middle-end/37448] cannot compile big function

[rguenth at gcc dot gnu.org]

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

--- Comment #53 from Richard Biener  ---
I have a simple patch :P

[Bug sanitizer/69863] no_sanitize_address doesn't disable stack instrumentation

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek  ---
I think the right fix is to add the
&& !lookup_attribute ("no_sanitize_address", DECL_ATTRIBUTES
(current_function_decl)) check next to the && ASAN_STACK checks (perhaps even
put
(flag_sanitize & SANITIZE_ADDRESS)
&& ASAN_STACK
&& !lookup_attribute ("no_sanitize_address",
  DECL_ATTRIBUTES (current_function_decl))
into a special small inline predicate in that file and use it in the 4 places.

[Bug libstdc++/69862] STL containers not using allocator's definition of pointers

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE
   Severity|blocker |normal

--- Comment #1 from Jonathan Wakely  ---
Please don't set the severity field. "Blocker" would mean we can't release GCC
without fixing it, which is obviously not the case here.

This is PR 57272 which is not even a real bug because it isn't clear the
standard requires it, see http://cplusplus.github.io/LWG/lwg-active.html#2261

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

[Bug libstdc++/57272] node-based containers don't use allocator's pointer type internally

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||philippeb8 at gmail dot com

--- Comment #5 from Jonathan Wakely  ---
*** Bug 69862 has been marked as a duplicate of this bug. ***

[Bug c++/69850] [6 Regression] unnecessary -Wnonnull-compare warning

[trippels at gcc dot gnu.org]

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

--- Comment #6 from Markus Trippelsdorf  ---
Created attachment 37728
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37728&action=edit
unreduced testcase

trippels@gcc2-power8 llvm_build % g++ -Wnonnull-compare -Werror -c 
VariantValue.ii
In file included from
/home/trippels/llvm/tools/clang/include/clang/Basic/DiagnosticIDs.h:19:0,
 from
/home/trippels/llvm/tools/clang/include/clang/Basic/Diagnostic.h:18,
 from
/home/trippels/llvm/tools/clang/include/clang/Basic/PartialDiagnostic.h:19,
 from
/home/trippels/llvm/tools/clang/include/clang/AST/DeclarationName.h:17,
 from
/home/trippels/llvm/tools/clang/include/clang/AST/DeclBase.h:18,
 from
/home/trippels/llvm/tools/clang/include/clang/AST/Decl.h:18,
 from
/home/trippels/llvm/tools/clang/include/clang/AST/ASTTypeTraits.h:20,
 from
/home/trippels/llvm/tools/clang/include/clang/AST/ASTContext.h:18,
 from
/home/trippels/llvm/tools/clang/include/clang/ASTMatchers/ASTMatchers.h:48,
 from
/home/trippels/llvm/tools/clang/include/clang/ASTMatchers/Dynamic/VariantValue.h:20,
 from
/home/trippels/llvm/tools/clang/lib/ASTMatchers/Dynamic/VariantValue.cpp:15:
/home/trippels/llvm/include/llvm/ADT/IntrusiveRefCntPtr.h: In member function
‘void llvm::RefCountedBaseVPTR::Release() const’:
/home/trippels/llvm/include/llvm/ADT/IntrusiveRefCntPtr.h:79:38: error: nonnull
argument ‘this’ compared to NULL [-Werror=nonnull-compare]
   if (--ref_cnt == 0) delete this;
  ^
cc1plus: all warnings being treated as errors

[Bug target/69857] gcc/config/arm/arm.c:15949: return in strange place ?

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||missed-optimization
   Target Milestone|--- |7.0

--- Comment #3 from ktkachov at gcc dot gnu.org ---
Agree that gcc should warn here.
As for the suspicious return itself, from what I can see it has the effect of
overly restricting generation of the LDRD/STRD instructions on arm.
Removing it is probably the right thing to do (and passes a first round of
testing for me).

However, since the code it was blocking has not been tested so far (because it
was never executed) we don't know what bugs (if any) are lurking there, so
removing it should wait for GCC 7 at this point

[Bug target/69857] gcc/config/arm/arm.c:15949: return in strange place ?

[dcb314 at hotmail dot com]

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

--- Comment #4 from David Binderman  ---
(In reply to ktkachov from comment #3)
> Agree that gcc should warn here.
> As for the suspicious return itself, from what I can see it has the effect
> of overly restricting generation of the LDRD/STRD instructions on arm.
> Removing it is probably the right thing to do (and passes a first round of
> testing for me).
> 
> However, since the code it was blocking has not been tested so far (because
> it was never executed) we don't know what bugs (if any) are lurking there,
> so removing it should wait for GCC 7 at this point

What would be enough testing to ensure the change would get into gcc 6 ?

Maybe a gcc bootstrap build or a linux kernel build.
Maybe a full build of all the packages in Fedora / OpenSuse / Debian / Ubuntu.

I don't have ARM here, but this might be enough excuse to get
access to the compile farm or to some other ARM server.

[Bug target/69857] gcc/config/arm/arm.c:15949: return in strange place ?

[ktkachov at gcc dot gnu.org]

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

--- Comment #5 from ktkachov at gcc dot gnu.org ---
We'd need a testcase that shows a regression resulting from this code not being
run i.e. code that became worse after r197530 (or wrong code or an ICE) and is
fixed by removing that "return false;".
Then, a normal bootstrap and test should be enough and the change could go in
as a regression fix at this stage. But finding such a testcase would not be
easy, I suspect.

[Bug c++/55203] No unused warning for variables of non-trivial types

[gcc at bobbyperu dot info]

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

Sergio Martins  changed:

   What|Removed |Added

 CC||gcc at bobbyperu dot info

--- Comment #11 from Sergio Martins  ---
Did the patch for [warn_unused] get in ?

[Bug c++/69864] New: Narrowing conversion

[mgsergio at yandex dot ru]

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

Bug ID: 69864
   Summary: Narrowing conversion
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mgsergio at yandex dot ru
  Target Milestone: ---

#include 
#include 
using namespace std;

template 
inline T narrowing_check(U const u)
{
  // Also gives only warning
  // T t{u};
  // return t;
  return {u};
}

int main() {
  auto a = narrowing_check(3.5);
  cout << a;
  // int b{2.3};
  return 0;
}

gcc emits a waring on narrowing_check although it should be generated instead.
On int b{2.3} gcc correctly rejects the code. 

g++-5 -Wall -Wextra -std=c++11 1.cc
1.cc: In instantiation of 'T narrowing_check(U) [with T = int; U = double]':
1.cc:15:36:   required from here
1.cc:11:12: warning: narrowing conversion of '(double)u' from 'double' to 'int'
inside { } [-Wnarrowing]
   return {u};

clang rejects this code.
1.cc:11:11: error: type 'double' cannot be narrowed to 'int' in initializer
list [-Wc++11-narrowing]
  return {u};
  ^
1.cc:15:12: note: in instantiation of function template specialization
'narrowing_check' requested here
  auto a = narrowing_check(3.5);
   ^
1.cc:11:11: note: insert an explicit cast to silence this issue
  return {u};
  ^
  static_cast( )
1 error generated.

[Bug target/69857] gcc/config/arm/arm.c:15949: return in strange place ?

[dcb314 at hotmail dot com]

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

--- Comment #6 from David Binderman  ---
(In reply to ktkachov from comment #5)
> We'd need a testcase that shows a regression resulting from this code not
> being run i.e. code that became worse after r197530 (or wrong code or an
> ICE) and is fixed by removing that "return false;".
> Then, a normal bootstrap and test should be enough and the change could go
> in as a regression fix at this stage. But finding such a testcase would not
> be easy, I suspect.

A step on the way to finding that test case would be to put a marker
into the code. Something like

   else if (TARGET_ARM)
   {
   // Either this
   fprintf( stderr, "dcb: Got to interesting place\n");
   // or this
   inform (0, "dcb: Got to interesting place");
   return false;

Then compile a lot of code, looking for the "interesting place" comment.
This can be left unattended, so need not consume valuable developer time.
A simple grep through some build logs would do.

Once we've got example code that gets to that place, merely do a before'n'after
with and without the "return false" and see what happens. If there is
a regression, then we are done.

I suspect the "return false;" merely prevents us doing some ARM
specific optimisation, so removing the "return false" is likely IMHO 
to make the code go faster.

Just an idea.

[Bug c++/69864] Narrowing conversion warning instead of an error

[mgsergio at yandex dot ru]

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

--- Comment #1 from mgsergio  ---

*gcc emits a warning on narrowing_check although an error should be generated
instead.

[Bug target/69857] gcc/config/arm/arm.c:15949: return in strange place ?

[ktkachov at gcc dot gnu.org]

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

--- Comment #7 from ktkachov at gcc dot gnu.org ---
Yes, that's an approach that can be taken. Once such a case is found, you could
also try using a reducer program like creduce to create a small testcase
appropriate for the testsuite.

Removing the return there would probably be an optimisation, which is why I
recommended it for GCC 7. GCC 6 is now in a regression fixing stage, so for it
to go in now we would need to find a testcase where we were performing an
optimisation before r197530 and after r197530 (with the bogus return) we
stopped doing. Considering that r197530 was supposed to introduce that
optimisation, it's unlikely that such a case can be found.

[Bug rtl-optimization/69764] [5 Regression] ICE on x86_64-linux-gnu at -O0 (in decompose, at rtl.h:2107)

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

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

--- Comment #11 from Andreas Schwab  ---
/daten/aranym/gcc/gcc-20160218/Build/./gcc/xgcc
-B/daten/aranym/gcc/gcc-20160218/Build/./gcc/
-B/daten/cross/m68k-linux/m68k-linux/bin/
-B/daten/cross/m68k-linux/m68k-linux/lib/ -isystem
/daten/cross/m68k-linux/m68k-linux/include -isystem
/daten/cross/m68k-linux/m68k-linux/sys-include-g -O2 -O2  -g -O2 -DIN_GCC 
-DCROSS_DIRECTORY_STRUCTURE  -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition 
-isystem ./include   -fPIC -g -DIN_LIBGCC2 -fbuilding-libgcc
-fno-stack-protector   -fPIC -I. -I. -I../.././gcc -I../../../libgcc
-I../../../libgcc/. -I../../../libgcc/../gcc -I../../../libgcc/../include 
-DHAVE_CC_TLS  -o _mulvsi3.o -MT _mulvsi3.o -MD -MP -MF _mulvsi3.dep
-DL_mulvsi3 -c ../../../libgcc/libgcc2.c -fvisibility=hidden -DHIDE_EXPORTS
In file included from ../../../libgcc/libgcc2.c:56:0:
../../../libgcc/libgcc2.c: In function ‘__mulvsi3’:
../../../libgcc/libgcc2.h:208:19: internal compiler error: in
maybe_legitimize_operand, at optabs.c:6903
 #define __NW(a,b) __ ## a ## si ## b
   ^

[Bug rtl-optimization/69764] [5 Regression] ICE on x86_64-linux-gnu at -O0 (in decompose, at rtl.h:2107)

[jakub at gcc dot gnu.org]

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

--- Comment #12 from Jakub Jelinek  ---
(In reply to Andreas Schwab from comment #11)
> /daten/aranym/gcc/gcc-20160218/Build/./gcc/xgcc
> -B/daten/aranym/gcc/gcc-20160218/Build/./gcc/
> -B/daten/cross/m68k-linux/m68k-linux/bin/
> -B/daten/cross/m68k-linux/m68k-linux/lib/ -isystem
> /daten/cross/m68k-linux/m68k-linux/include -isystem
> /daten/cross/m68k-linux/m68k-linux/sys-include-g -O2 -O2  -g -O2
> -DIN_GCC  -DCROSS_DIRECTORY_STRUCTURE  -W -Wall -Wno-narrowing
> -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes
> -Wold-style-definition  -isystem ./include   -fPIC -g -DIN_LIBGCC2
> -fbuilding-libgcc -fno-stack-protector   -fPIC -I. -I. -I../.././gcc
> -I../../../libgcc -I../../../libgcc/. -I../../../libgcc/../gcc
> -I../../../libgcc/../include  -DHAVE_CC_TLS  -o _mulvsi3.o -MT _mulvsi3.o
> -MD -MP -MF _mulvsi3.dep -DL_mulvsi3 -c ../../../libgcc/libgcc2.c
> -fvisibility=hidden -DHIDE_EXPORTS
> In file included from ../../../libgcc/libgcc2.c:56:0:
> ../../../libgcc/libgcc2.c: In function ‘__mulvsi3’:
> ../../../libgcc/libgcc2.h:208:19: internal compiler error: in
> maybe_legitimize_operand, at optabs.c:6903
>  #define __NW(a,b) __ ## a ## si ## b
>^

Can you attach preprocessed source for this?

[Bug c++/69864] Narrowing conversion warning instead of an error

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

--- Comment #2 from Markus Trippelsdorf  ---
This is done so intentionally.

Note that you could suppress the error in clang with -Wno-narrowing.

If you need an error in gcc use -Werror=narrowing.

[Bug rtl-optimization/69764] [5 Regression] ICE on x86_64-linux-gnu at -O0 (in decompose, at rtl.h:2107)

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

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

--- Comment #13 from Andreas Schwab  ---
Created attachment 37729
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37729&action=edit
Preprocessed source

[Bug driver/69849] Some spec functions are undocumented in doc/invoke.texi

[vries at gcc dot gnu.org]

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

--- Comment #1 from vries at gcc dot gnu.org ---
In addition, the '%{%:function(args):X}' construct is undocumented, as noted
here: https://gcc.gnu.org/ml/gcc-patches/2016-02/msg01243.html .

[Bug rtl-optimization/69764] [5 Regression] ICE on x86_64-linux-gnu at -O0 (in decompose, at rtl.h:2107)

[jakub at gcc dot gnu.org]

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

--- Comment #14 from Jakub Jelinek  ---
Doesn't ICE for me...
Can you please debug what is going on?

[Bug target/69671] [6 Regression] FAIL: gcc.target/i386/avx512vl-vpmovqb-1.c scan-assembler-times vpmovqb[ \\t]+[^{\n]*%ymm[0-9]+[^\n]*%xmm[0-9]+{%k[1-7]}{z}(?

[kyukhin at gcc dot gnu.org]

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

--- Comment #24 from Kirill Yukhin  ---
(In reply to rguent...@suse.de from comment #23)
> On Wed, 17 Feb 2016, jakub at gcc dot gnu.org wrote:
> 
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69671
> > 
> > --- Comment #22 from Jakub Jelinek  ---
> > Created attachment 37722 [details]
> >   --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37722&action=edit
> > gcc6-pr69671.patch
> > 
> > Actually, on a closer look, I believe the only problem are the patterns that
> > use a vector_move_operand "0C" inside of vec_select with only constants as 
> > the
> > parallel's operands.  Because fwprop is able to propagate constants into
> > instructions (thus undo the CSE effect), but doesn't do anything on these,
> > because it also simplifies them, so instead of the expected say
> > (vec_select:V4QI (const_vector:V16QI [
> > (const_int 0 [0])
> > (const_int 0 [0])
> > (const_int 0 [0])
> > (const_int 0 [0])
> > (const_int 0 [0])
> > (const_int 0 [0])
> > (const_int 0 [0])
> > (const_int 0 [0])
> > (const_int 0 [0])
> > (const_int 0 [0])
> > (const_int 0 [0])
> > (const_int 0 [0])
> > (const_int 0 [0])
> > (const_int 0 [0])
> > (const_int 0 [0])
> > (const_int 0 [0])
> > ])
> > (parallel [
> > (const_int 0 [0])
> > (const_int 1 [0x1])
> > (const_int 2 [0x2])
> > (const_int 3 [0x3])
> > ]))
> > we get in there simplified:
> > (const_vector:V4QI [
> > (const_int 0 [0])
> > (const_int 0 [0])
> > (const_int 0 [0])
> > (const_int 0 [0])
> > ])
> > So, by adding extra patterns for that simplification fwprop is able to do 
> > its
> > job even if CSE did a better job.
> 
> Of course then I wonder why we didn't simplify this in the first place
> when generating RTL and need to wait for forwprop ...
> 
> But yes, sounds like the easiest way to go forward.

Agree.

[Bug target/69671] [6 Regression] FAIL: gcc.target/i386/avx512vl-vpmovqb-1.c scan-assembler-times vpmovqb[ \\t]+[^{\n]*%ymm[0-9]+[^\n]*%xmm[0-9]+{%k[1-7]}{z}(?

[jakub at gcc dot gnu.org]

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

--- Comment #25 from Jakub Jelinek  ---
I've already posted the patch for review:
https://gcc.gnu.org/ml/gcc-patches/2016-02/msg01201.html

[Bug testsuite/68580] FAIL: c-c++-common/tsan/pr65400-1.c -O0 execution test

[vries at gcc dot gnu.org]

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

--- Comment #11 from vries at gcc dot gnu.org ---
Alternative patch proposed by Bernd Edlinger :
https://gcc.gnu.org/ml/gcc-patches/2016-02/msg00976.html .

Patch approved by sanitizer reviewer :
https://gcc.gnu.org/ml/gcc-patches/2016-02/msg00985.html .

[Bug c++/69864] Narrowing conversion warning instead of an error

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
Or use -pedantic-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 #43 from alalaw01 at gcc dot gnu.org ---
Yeah, I plan to add a fortran-specific option for this, it's easy enough, but I
can't run the gfortran testsuite with that, because there are lots of C files
in there too, for which the compiler doesn't accept the option...

I'm having trouble writing a testcase though. My subroutine with

IMPLICIT DOUBLE PRECISION (X)
COMMON /MYCOMMON / X(1)

produces "mycommon.x" a COMPONENT_REF, but with "mycommon" being a MEM_REF,
which requires only the hunk to tree-dfa.c to handle correctly; whereas in
SPEC2006, what looks to me to be equivalent FORTRAN, ends up with "mycommon"
being a VAR_DECL, which requires the much-bigger patch to the fortran FE...

I've very little fortran experience here, any tips?

Thanks, Alan

[Bug c++/69855] Missing diagnostic for overload that only differs by return type

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
Minimal reproducer:

int get();
void f() {
  char get();
}

Slightly sneakier version that defeated my first attempt to fix it (because the
overload set causes us to discard the previous decls):

int get();
char get(int);
void f() {
  char get();
}

[Bug c/69819] [4.9/5/6 Regression] ICE on invalid code on x86_64-linux-gnu in tree check: expected function_type or method_type, have array_type in function_args_iter_init, at tree.h:4536

[mpolacek at gcc dot gnu.org]

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

--- Comment #5 from Marek Polacek  ---
This fixes it but I'd like to think about this some more.

--- gcc/c/c-decl.c
+++ gcc/c/c-decl.c
@@ -4743,7 +4743,7 @@ finish_decl (tree decl, location_t init_loc, tree init,
  struct c_binding *b_ext = I_SYMBOL_BINDING (DECL_NAME (decl));
  while (b_ext && !B_IN_EXTERNAL_SCOPE (b_ext))
b_ext = b_ext->shadowed;
- if (b_ext)
+ if (b_ext && TREE_CODE (decl) == TREE_CODE (b_ext->decl))
{
  if (b_ext->u.type && comptypes (b_ext->u.type, type))
b_ext->u.type = composite_type (b_ext->u.type, type);

[Bug c++/69850] [6 Regression] unnecessary -Wnonnull-compare warning

[trippels at gcc dot gnu.org]

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

--- Comment #7 from Markus Trippelsdorf  ---
(wow, llvm approaches Boost in the complexity of testcases. It takes ages to
reduce them.) 


class RefCountedBaseVPTR {
  virtual ~RefCountedBaseVPTR();
  void Release() const { delete this; }
  template  friend struct A;
};
template  struct A {
  static void release(T *p1) { p1->Release(); }
};
template  class B {
  T Obj;
public:
  void reset() { A::release(&Obj); }
};
class C {
  class Payload : public RefCountedBaseVPTR {
~Payload();
  };
  void reset();
  B Value;
};
void C::reset() { Value.reset(); }

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

[mpolacek at gcc dot gnu.org]

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

--- Comment #1 from Marek Polacek  ---
I think a safe fix would be to just add if (!c_dialect_objc ()) to the change
that caused this.

[Bug c++/69865] New: -trigraphs option broken

[bernd.edlinger at hotmail dot de]

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

Bug ID: 69865
   Summary: -trigraphs option broken
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bernd.edlinger at hotmail dot de
  Target Milestone: ---

Hi,

I know, nobody likes them, but...

cat test.cc
int
main ()
??<
  return 0;
??>

gcc -trigraphs test.cc
test.cc:3:1: warning: trigraph ??< ignored, use -trigraphs to enable
[-Wtrigraphs]
 ??<
 ^
test.cc:5:1: warning: trigraph ??> ignored, use -trigraphs to enable
[-Wtrigraphs]
 ??>
 ^
test.cc:3:1: error: expected initializer before '?' token
 ??<
 ^
test.cc:5:1: error: expected unqualified-id before '?' token
 ??>
 ^

[Bug target/69610] [5/6 Regression] ICE: SIGSEGV in arm_reload_in_hi (arm.c:15446) with -march=armv3

[nickc at gcc dot gnu.org]

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

--- Comment #3 from Nick Clifton  ---
Author: nickc
Date: Thu Feb 18 13:00:07 2016
New Revision: 233518

URL: https://gcc.gnu.org/viewcvs?rev=233518&root=gcc&view=rev
Log:
PR target/62554
PR target/69610
gcc * config/arm/arm.c (arm_option_override_internal): Disable
interworking if the target does not support thumb instructions.
(arm_reload_in_hi): Handle the case where a register to register
move needs reloading because there is no simple pattern to handle
it.
(arm_reload_out_hi): Likewise.

tests   * gcc.target/arm/pr62554.c: New test.
* gcc.target/arm/pr69610-1.c: New test.
* gcc.target/arm/pr69610-2.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/arm/pr62554.c
trunk/gcc/testsuite/gcc.target/arm/pr69610-1.c
trunk/gcc/testsuite/gcc.target/arm/pr69610-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/arm/arm.c
trunk/gcc/testsuite/ChangeLog

[Bug target/62254] [4.9/5/6 Regression] gcc-4.9 ICEs on linux kernel zlib for armv3

[nickc at gcc dot gnu.org]

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

Nick Clifton  changed:

   What|Removed |Added

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

--- Comment #8 from Nick Clifton  ---
I have now checked in the patch.

[Bug c++/69865] -trigraphs option broken

[bernd.edlinger at hotmail dot de]

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

--- Comment #1 from Bernd Edlinger  ---
weird:
If I add -std=c++14 (or any other c++ version, including -ansi)
to the command line, it works.

[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 #44 from Thomas Koenig  ---
I don't have access to SPEC, so I can only guess...

Is there maybe an equivalence involved, something like

  COMMON /FOO/ X(1)
  EQUIVALENCE (X,Y)

?

[Bug c++/69850] [6 Regression] unnecessary -Wnonnull-compare warning

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  ---
Created attachment 37730
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37730&action=edit
gcc6-pr69850.patch

Untested fix.

[Bug c++/69850] [6 Regression] unnecessary -Wnonnull-compare warning

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #9 from Jakub Jelinek  ---
Reopening for the #c7 issue.

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

[jakub at gcc dot gnu.org]

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

--- Comment #45 from Jakub Jelinek  ---
Consider e.g. one source file
  INTEGER FOO
  COMMON /BLK/ K(64)
  DO I=1,64
  K(I)=1
  END DO
  IF (FOO(5,12).NE.51) CALL ABORT
  END
and another one:
  FUNCTION FOO(I, J)
  COMMON /BLK/ K(1)
  FOO = K(I) + K(J) + K(2*I) + K(2*J)
  END FUNCTION
If the second source file is compiled with -O2, it will return "wrong" value,
as if all accesses to K were using the same index (because the only valid index
is 1).  If you compile with -O2 -fno-tree-dominator-opts, then it "works".

[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 #46 from rguenther at suse dot de  ---
On Thu, 18 Feb 2016, jakub at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69368
> 
> --- Comment #45 from Jakub Jelinek  ---
> Consider e.g. one source file
>   INTEGER FOO
>   COMMON /BLK/ K(64)
>   DO I=1,64
>   K(I)=1
>   END DO
>   IF (FOO(5,12).NE.51) CALL ABORT
>   END
> and another one:
>   FUNCTION FOO(I, J)
>   COMMON /BLK/ K(1)
>   FOO = K(I) + K(J) + K(2*I) + K(2*J)
>   END FUNCTION
> If the second source file is compiled with -O2, it will return "wrong" value,
> as if all accesses to K were using the same index (because the only valid 
> index
> is 1).  If you compile with -O2 -fno-tree-dominator-opts, then it "works".

Which is odd since FRE already should optimize it that way.

Richard.

[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 #48 from rguenther at suse dot de  ---
On Thu, 18 Feb 2016, rguenther at suse dot de wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69368
> 
> --- Comment #46 from rguenther at suse dot de  ---
> On Thu, 18 Feb 2016, jakub at gcc dot gnu.org wrote:
> 
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69368
> > 
> > --- Comment #45 from Jakub Jelinek  ---
> > Consider e.g. one source file
> >   INTEGER FOO
> >   COMMON /BLK/ K(64)
> >   DO I=1,64
> >   K(I)=1
> >   END DO
> >   IF (FOO(5,12).NE.51) CALL ABORT
> >   END
> > and another one:
> >   FUNCTION FOO(I, J)
> >   COMMON /BLK/ K(1)
> >   FOO = K(I) + K(J) + K(2*I) + K(2*J)
> >   END FUNCTION
> > If the second source file is compiled with -O2, it will return "wrong" 
> > value,
> > as if all accesses to K were using the same index (because the only valid 
> > index
> > is 1).  If you compile with -O2 -fno-tree-dominator-opts, then it "works".
> 
> Which is odd since FRE already should optimize it that way.

Ok, it does not.  Supposedly more complicated situations are needed to
trigger sth wrong in FRE.

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

[jakub at gcc dot gnu.org]

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

--- Comment #47 from Jakub Jelinek  ---
(In reply to rguent...@suse.de from comment #46)
> Which is odd since FRE already should optimize it that way.

Bet FRE punts on that because it considers it poor man's flexible array member.
But, you know FRE better than me ;)

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

[dominiq at lps dot ens.fr]

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

--- Comment #49 from Dominique d'Humieres  ---
> Yeah, I plan to add a fortran-specific option for this, it's easy enough,

I don't see the point to add yet another option just because "SPEC does not
want to change the invalid Fortran". I think SPEC should be run with the
option(s) causing the problem disabled.

> but I can't run the gfortran testsuite with that, because there are lots
> of C files in there too, for which the compiler doesn't accept the option...

You can use something along the following

--- ../_clean/gcc/testsuite/lib/prune.exp   2016-01-04 19:51:06.0
+0100
+++ gcc/testsuite/lib/prune.exp 2016-01-04 20:30:13.0 +0100
@@ -51,6 +51,9 @@ proc prune_gcc_output { text } {
 regsub -all "(^|\n)\[^\n\]*: Additional NOP may be necessary to workaround
Itanium processor A/B step errata" $text "" text
 regsub -all "(^|\n)\[^\n*\]*: Assembler messages:\[^\n\]*" $text "" text

+# Ignore warning for gfortran options passed to the C compilers.
+regsub -all "(^|\n)cc1(plus)?: warning: command line option .-f\[^\"\]*.
is valid for Fortran but not for C\[^\n\]*" $text "" text
+
 # Ignore harmless VTA note.
 regsub -all "(^|\n)\[^\n\]*: note: variable tracking size limit exceeded
with -fvar-tracking-assignments, retrying without\[^\n\]*" $text "" text

[Bug c++/69850] [6 Regression] unnecessary -Wnonnull-compare warning

[trippels at gcc dot gnu.org]

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

--- Comment #10 from Markus Trippelsdorf  ---
Still happening even with latest patch:

[1763/2142] Building CXX object
tools/clang/lib/StaticAnalyzer/Core/CMakeFiles/clangStaticAnalyzerCore.dir/HTMLDiagnostics.cpp.o
In file included from
/home/trippels/llvm/tools/clang/include/clang/Rewrite/Core/RewriteBuffer.h:15:0,
 from
/home/trippels/llvm/tools/clang/include/clang/Rewrite/Core/Rewriter.h:19,
 from
/home/trippels/llvm/tools/clang/lib/StaticAnalyzer/Core/HTMLDiagnostics.cpp:21:
/home/trippels/llvm/tools/clang/include/clang/Rewrite/Core/RewriteRope.h: In
member function ‘void clang::RopeRefCountString::Release()’:
/home/trippels/llvm/tools/clang/include/clang/Rewrite/Core/RewriteRope.h:43:30:
warning: nonnull argument ‘this’ compared to NULL [-Wnonnull-compare]
 delete [] (char*)this;
  ^

[Bug c++/69865] -trigraphs option broken

[bernd.edlinger at hotmail dot de]

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

--- Comment #2 from Bernd Edlinger  ---
in gcc/c-family/c-opts.c:

following code in line 805:

  /* Set C++ standard to C++14 if not specified on the command line.  */
  if (c_dialect_cxx () && cxx_dialect == cxx_unset)
set_std_cxx14 (/*ISO*/false);

... defeats this in line 667 above:

case OPT_trigraphs:
  cpp_opts->trigraphs = 1;
  break;

[Bug c++/69850] [6 Regression] unnecessary -Wnonnull-compare warning

[jakub at gcc dot gnu.org]

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

--- Comment #11 from Jakub Jelinek  ---
Can you attach it again?

[Bug c++/69850] [6 Regression] unnecessary -Wnonnull-compare warning

[trippels at gcc dot gnu.org]

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

--- Comment #12 from Markus Trippelsdorf  ---
Created attachment 37731
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37731&action=edit
unreduced testcase

[Bug c++/69864] Narrowing conversion warning instead of an error

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org
 Resolution|WONTFIX |DUPLICATE

--- Comment #4 from Manuel López-Ibáñez  ---
(In reply to Jakub Jelinek from comment #3)
> Or use -pedantic-errors.

I find it a bit ironic that Clang does inform the user when something is
accepted as a GNU extension, but *GNU* GCC does not clarify this. Perhaps the
pedwarn below would be clearer with something like?

warning: narrowing conversion of '(double)u' from 'double' to 'int' inside { }
is a GNU extension

Or even something fancier:

warning: narrowing conversion of '(double)u' from 'double' to 'int' inside { }
(error in c++11, allowed by gnu++11)

or

warning: (GNU extension to c++11) narrowing conversion of '(double)u' from
'double' to 'int' inside { }

It would be not too difficult to automatically print the current base standard
and the corresponding gnu standard on every pedwarn.

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

[Bug c++/55783] Warnings instead of compiler errors for narrowing conversions within list-initializations

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||mgsergio at yandex dot ru

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

[Bug c++/55783] Warnings instead of compiler errors for narrowing conversions within list-initializations

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #12 from Manuel López-Ibáñez  ---
Since it seems this has to be explained repeatedly (and I had to read this in
detail to understand why this is a pedwarn enabled by -Wall), I created a FAQ:
https://gcc.gnu.org/wiki/FAQ#Wnarrowing

Jonathan, I used most of your comment #4 verbatim, I hope this is OK. Feel free
to edit it for corrections or further clarification.

[Bug c++/69850] [6 Regression] unnecessary -Wnonnull-compare warning

[trippels at gcc dot gnu.org]

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

--- Comment #13 from Markus Trippelsdorf  ---
template  struct A {
  static void release(T *p1) { p1->Release(); }
};
template  class IntrusiveRefCntPtr {
  T Obj;
public:
  void operator=(IntrusiveRefCntPtr) { A::release(&Obj); }
};
struct RopeRefCountString {
  void Release() { delete[] this; }
};
struct RopePiece {
  IntrusiveRefCntPtr StrData;
};
class RopePieceBTreeNode {
protected:
  enum { WidthFactor };
};
class RopePieceBTreeLeaf : RopePieceBTreeNode {
  RopePiece Pieces[WidthFactor];
  RopePieceBTreeNode *insert(const RopePiece &);
};
int a;
RopePieceBTreeNode *RopePieceBTreeLeaf::insert(const RopePiece &) {
  Pieces[a] = Pieces[1];
}

[Bug middle-end/69553] [6 Regression] Optimizations O1/O2 makes std::array value incorrect when passed to function

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug middle-end/69553] [6 Regression] Optimizations O1/O2 makes std::array value incorrect when passed to function

[rguenth at gcc dot gnu.org]

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

--- Comment #11 from Richard Biener  ---
Author: rguenth
Date: Thu Feb 18 14:34:59 2016
New Revision: 233520

URL: https://gcc.gnu.org/viewcvs?rev=233520&root=gcc&view=rev
Log:
2016-02-18  Richard Biener  

PR middle-end/69553
* fold-const.c (operand_equal_p): Properly compare offsets for
IMAGPART_EXPR and ARRAY_REF.

* g++.dg/torture/pr69553.C: New testcase.

Added:
trunk/gcc/testsuite/g++.dg/torture/pr69553.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/fold-const.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

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 CC||hjl.tools at gmail dot com

--- Comment #50 from H.J. Lu  ---
Has my fix for 416.gamess source been applied when the failure happened?

[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 #51 from rguenther at suse dot de  ---
On Thu, 18 Feb 2016, hjl.tools at gmail dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69368
> 
> H.J. Lu  changed:
> 
>What|Removed |Added
> 
>  CC||hjl.tools at gmail dot com
> 
> --- Comment #50 from H.J. Lu  ---
> Has my fix for 416.gamess source been applied when the failure happened?

No.

[Bug c++/68679] [5/6 Regression] gcc-5.2.1 ICE in C++11 anon union of structs with template fns, OK in gcc <= 4.9.3

[jason at gcc dot gnu.org]

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

--- Comment #4 from Jason Merrill  ---
Author: jason
Date: Thu Feb 18 14:49:16 2016
New Revision: 233521

URL: https://gcc.gnu.org/viewcvs?rev=233521&root=gcc&view=rev
Log:
PR c++/68679
* decl2.c (reset_type_linkage_2): Look through member templates.

Added:
branches/gcc-5-branch/gcc/testsuite/g++.dg/other/anon8.C
Modified:
branches/gcc-5-branch/gcc/cp/ChangeLog
branches/gcc-5-branch/gcc/cp/decl2.c

[Bug c++/68585] [5/6 Regression] c++14 code accepted by 4.9 not accepted by 5 and 6

[jason at gcc dot gnu.org]

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

--- Comment #7 from Jason Merrill  ---
Author: jason
Date: Thu Feb 18 14:49:22 2016
New Revision: 233522

URL: https://gcc.gnu.org/viewcvs?rev=233522&root=gcc&view=rev
Log:
PR c++/68585
* constexpr.c (cxx_eval_bare_aggregate): Fix 'changed' detection.

Added:
branches/gcc-5-branch/gcc/testsuite/g++.dg/cpp0x/constexpr-initlist9.C
Modified:
branches/gcc-5-branch/gcc/cp/ChangeLog
branches/gcc-5-branch/gcc/cp/constexpr.c

[Bug c++/69865] -trigraphs option broken

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

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

--- Comment #3 from Manuel López-Ibáñez  ---
(In reply to Bernd Edlinger from comment #2)
> in gcc/c-family/c-opts.c:
> 
> following code in line 805:
> 
>   /* Set C++ standard to C++14 if not specified on the command line.  */
>   if (c_dialect_cxx () && cxx_dialect == cxx_unset)
> set_std_cxx14 (/*ISO*/false);

The default for C is set in c_common_init_options, which seems more logical.

> 
> case OPT_trigraphs:
>   cpp_opts->trigraphs = 1;
>   break;


If you use CPP(trigraphs) in c.opt, this code is auto-generated (and also the
default of libcpp becomes the default of GCC, unless overriden).

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

[hjl.tools at gmail dot com]

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

--- Comment #52 from H.J. Lu  ---
(In reply to rguent...@suse.de from comment #51)
> > --- Comment #50 from H.J. Lu  ---
> > Has my fix for 416.gamess source been applied when the failure happened?
> 
> No.

So, there is nothing to fix in GCC? Why isn't this bug closed as invalid?

[Bug lto/59000] lto can't merge user-defined weak builtin functions

[dev-zero at gentoo dot org]

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

Tiziano Müller  changed:

   What|Removed |Added

 CC||dev-zero at gentoo dot org

--- Comment #5 from Tiziano Müller  ---
Found my way here via bug #52159. When building Qemu with -flto I get with
gcc-5.3.0:

[...]
lto1: error: two or more sections for .gnu.lto_fprintf.288635079aa9eb60
(null):0: confused by earlier errors, bailing out
lto-wrapper: fatal error:
/usr/x86_64-pc-linux-gnu/gcc-bin/5.3.0/x86_64-pc-linux-gnu-g++ returned 1 exit
status
compilation terminated.
/usr/lib/gcc/x86_64-pc-linux-gnu/5.3.0/../../../../x86_64-pc-linux-gnu/bin/ld:
fatal error: lto-wrapper failed
collect2: error: ld returned 1 exit status

[Bug c++/69850] [6 Regression] unnecessary -Wnonnull-compare warning

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

  Attachment #37730|0   |1
is obsolete||

--- Comment #14 from Jakub Jelinek  ---
Created attachment 37732
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37732&action=edit
gcc6-pr69850.patch

Updated fix.

[Bug target/69648] [5/6 Regression] wrong code with -O -mtune=winchip-c6 -fPIC -fexpensive-optimizations -msse4 @ i686

[bernds at gcc dot gnu.org]

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

--- Comment #14 from Bernd Schmidt  ---
Author: bernds
Date: Thu Feb 18 15:23:11 2016
New Revision: 233523

URL: https://gcc.gnu.org/viewcvs?rev=233523&root=gcc&view=rev
Log:
Backport PR69648 fix from mainline (set of picreg removed during lra).

PR rtl-optimization/69648
* lra-constraints.c (update_ebb_live_info): Don't remove sets of
pic_offset_table_rtx.


Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/lra-constraints.c

[Bug target/69648] [5/6 Regression] wrong code with -O -mtune=winchip-c6 -fPIC -fexpensive-optimizations -msse4 @ i686

[bernds at gcc dot gnu.org]

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

Bernd Schmidt  changed:

   What|Removed |Added

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

--- Comment #15 from Bernd Schmidt  ---
I think 4.9 doesn't use a pseudo pic register on x86, so no big need to
backport to that branch.

[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 #53 from alalaw01 at gcc dot gnu.org ---
(In reply to Thomas Koenig from comment #44)
> I don't have access to SPEC, so I can only guess... Is there maybe an 
> equivalence involved, something like

Turns out the COMMON is accessed via a MEM_REF in a loop, or as a VAR_DECL
inside. Go figure! :)

(In reply to Dominique d'Humieres from comment #49)
> I don't see the point to add yet another option just because "SPEC does not
> want to change the invalid Fortran". I think SPEC should be run with the
> option(s) causing the problem disabled.

Anecdotally I hear from Fortran-using colleagues this may occur in other places
too. Moreover, the list of phases using get_ref_base_and_extent, is long; we
could end up compiling with an ever-growing -fno-this -fno-that as more and
more phases make use of the "bad" analysis results (that is correct by the
language spec after all). In this case, there are a few other equivalences
found due to the tree-ssa-scopedtables.c changes, that we'd lose with
-fno-tree-dominator-opts, too.

(In reply to H.J. Lu from comment #52)
>
>So, there is nothing to fix in GCC? Why isn't this bug closed as invalid?

Not everyone wants to patch SPEC sources.

[Bug c++/69850] [6 Regression] unnecessary -Wnonnull-compare warning

[trippels at gcc dot gnu.org]

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

--- Comment #15 from Markus Trippelsdorf  ---
markus@x4 c++11 % /var/tmp/gcc_build_dir_/./gcc/xgcc -shared-libgcc
-B/var/tmp/gcc_build_dir_/./gcc -nostdinc++
-L/var/tmp/gcc_build_dir_/x86_64-pc-linux-gnu/libstdc++-v3/src
-L/var/tmp/gcc_build_dir_/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs
-L/var/tmp/gcc_build_dir_/x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs
-B/usr/x86_64-pc-linux-gnu/bin/ -B/usr/x86_64-pc-linux-gnu/lib/ -isystem
/usr/x86_64-pc-linux-gnu/include -isystem /usr/x86_64-pc-linux-gnu/sys-include
-I/var/tmp/gcc/libstdc++-v3/../libgcc
-I/var/tmp/gcc_build_dir_/x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu
-I/var/tmp/gcc_build_dir_/x86_64-pc-linux-gnu/libstdc++-v3/include
-I/var/tmp/gcc/libstdc++-v3/libsupc++ -std=gnu++11 -D_GLIBCXX_SHARED
-fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi
-fdiagnostics-show-location=once -ffunction-sections -fdata-sections
-frandom-seed=cow-shim_facets.lo -march=native -O2 -pipe -c -o
cow-shim_facets.lo ../../../../../gcc/libstdc++-v3/src/c++11/cow-shim_facets.cc
In file included from
../../../../../gcc/libstdc++-v3/src/c++11/cow-shim_facets.cc:35:0:
../../../../../gcc/libstdc++-v3/src/c++11/cxx11-shim_facets.cc: In member
function ‘const std::locale::facet* std::locale::facet::_M_cow_shim(const
std::locale::id*) const’:
../../../../../gcc/libstdc++-v3/src/c++11/cxx11-shim_facets.cc:792:19: warning:
nonnull argument ‘this’ compared to NULL [-Wnonnull-compare]
 if (auto* p = dynamic_cast(this))
   ^

[Bug fortran/53086] [4.8 Regression] 416.gamess in SPEC CPU 2006 miscompiled

[hjl.tools at gmail dot com]

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

--- Comment #18 from H.J. Lu  ---
Created attachment 37733
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37733&action=edit
Fix for 416.gamess in SPEC CPU 2006

[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 #2 from Jakub Jelinek  ---
Reduced testcase:
@class D;

void
foo (void)
{
  for (;;)
;
  D *d = (id) 0;
  (void) d;
}

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

[hjl.tools at gmail dot com]

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

--- Comment #54 from H.J. Lu  ---
(In reply to alalaw01 from comment #53)
> >
> >So, there is nothing to fix in GCC? Why isn't this bug closed as invalid?
> 
> Not everyone wants to patch SPEC sources.

If the SPEC source is invalid according to Fortran standard, why should
we change GCC for it?  This isn't the only invalid source in SPEC CPU
2006. There are at least 3.

[Bug tree-optimization/69848] poor vectorization of a loop from SPEC2006 464.h264ref

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

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

--- Comment #4 from Ramana Radhakrishnan  ---
Confirmed.

[Bug target/69663] [ARM] Implement overflow arithmetic standard names {u,}{add,sub,mul}v4

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-02-18
 CC||ramana at gcc dot gnu.org
   Target Milestone|--- |7.0
 Ever confirmed|0   |1

--- Comment #1 from Ramana Radhakrishnan  ---
confirmed.

[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|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-02-18
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #3 from Jakub Jelinek  ---
Created attachment 37734
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37734&action=edit
gcc6-pr69844.patch

Untested fix.

[Bug rtl-optimization/44281] [4.9/5/6 Regression] Global Register variable pessimisation

[bernds at gcc dot gnu.org]

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

Bernd Schmidt  changed:

   What|Removed |Added

   Assignee|vmakarov at redhat dot com |bernds at gcc dot 
gnu.org

--- Comment #23 from Bernd Schmidt  ---
Ok, I know what's causing it - ebx could take part in register allocation since
we seem to have proper lifetime information for it and it dies in some places,
but IRA ignores it since global regs get added to fixed_regs.

[Bug rtl-optimization/56069] [4.9/5/6 Regression] RA pessimization

[bernds at gcc dot gnu.org]

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

Bernd Schmidt  changed:

   What|Removed |Added

   Assignee|vmakarov at redhat dot com |bernds at gcc dot 
gnu.org

--- Comment #13 from Bernd Schmidt  ---
I think I got far enough that I'll just assign myself. Patches in testing.

[Bug sanitizer/69863] no_sanitize_address doesn't disable stack instrumentation

[marxin at gcc dot gnu.org]

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

--- Comment #2 from Martin Liška  ---
Author: marxin
Date: Thu Feb 18 17:15:25 2016
New Revision: 233524

URL: https://gcc.gnu.org/viewcvs?rev=233524&root=gcc&view=rev
Log:
Do not emit red stack zones for a fn with no_sanitize_address

PR sanitizer/69863
* cfgexpand.c (asan_sanitize_stack_p): New function.
(partition_stack_vars): Use the function.
(expand_stack_vars): Likewise.
(defer_stack_allocation): Likewise.
(expand_used_vars): Likewise.

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

[Bug sanitizer/69863] no_sanitize_address doesn't disable stack instrumentation

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #3 from Martin Liška  ---
Fixed.

[Bug c++/69850] [6 Regression] unnecessary -Wnonnull-compare warning

[jakub at gcc dot gnu.org]

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

--- Comment #16 from Jakub Jelinek  ---
Created attachment 37735
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37735&action=edit
gcc6-pr69850-3.patch

Untested incremental fix for the dynamic_cast issue.

[Bug fortran/69859] Non-deterministic ICEs on incomplete character declaration statement

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Keywords||error-recovery,
   ||ice-on-invalid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-02-18
 CC||dmalcolm at gcc dot gnu.org,
   ||manu at gcc dot gnu.org
Summary|ICE on incomplete character |Non-deterministic ICEs on
   |declaration statement   |incomplete character
   ||declaration statement
 Ever confirmed|0   |1

--- Comment #3 from Dominique d'Humieres  ---
I have compiled the tests from 4.8 up to trunk (6.0). While I have seen ICEs,
it happens that sometime they are were not seen:

[Book15] f90/bug% gfortran-fsf-4.8 pr69859_2.f90
pr69859_2.f90:3.19:

  character a ,
   1
Error: Invalid character in name at (1)
...
pr69859_2.f90:8.17:

  character f %
 1
Error: Syntax error in data declaration at (1)
pr69859_2.f90:3.17:

  character a ,
 1
Error: Character length of component 'a' needs to be a constant specification
expression at (1)

[Book15] f90/bug% gfortran-fsf-4.8 pr69859_2.f90
pr69859_2.f90:3.19:

  character a ,
   1
Error: Invalid character in name at (1)
...
pr69859_2.f90:8.17:

  character f %
 1
Error: Syntax error in data declaration at (1)
f951: internal compiler error: Segmentation fault: 11

f951: internal compiler error: Abort trap: 6
gfortran-fsf-4.8: internal compiler error: Abort trap: 6 (program f951)
Abort

[Book15] f90/bug% gfcc pr69859_3.f90
pr69859_3.f90:3:36:

   character, allocatable :: x(:) y(:)
1
Error: Syntax error in data declaration at (1)
pr69859_3.f90:3:36:

   character, allocatable :: x(:) y(:)
1
Error: Character length of component 'x' needs to be a constant specification
expression at (1)
[Book15] f90/bug% gfcc pr69859_3.f90
pr69859_3.f90:3:36:

   character, allocatable :: x(:) y(:)
1
Error: Syntax error in data declaration at (1)
f951: internal compiler error: Segmentation fault: 11

f951: internal compiler error: Abort trap: 6
gfcc: internal compiler error: Abort trap: 6 (program f951)
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

(gfcc: trunk revision 233414).

[Bug fortran/69861] ICE on declaring class parameter array

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-02-18
 Ever confirmed|0   |1

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

[Bug fortran/69860] ICE on missing end apostrophe with character(kind=4)

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-02-18
 Ever confirmed|0   |1

--- Comment #2 from Dominique d'Humieres  ---
Confirmed from 4.4 up to trunk (6.0), except 4.8.5 and 4.8.4 (r217778).

Note that I don't see any ICE for

   character(len=2, kind=4) :: a = 'aa

[Bug fortran/69668] [4.9/5/6 Regression] Error reading namelist opened with DELIM='NONE'

[jvdelisle at gcc dot gnu.org]

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

--- Comment #8 from Jerry DeLisle  ---
Author: jvdelisle
Date: Thu Feb 18 18:23:09 2016
New Revision: 233528

URL: https://gcc.gnu.org/viewcvs?rev=233528&root=gcc&view=rev
Log:
2016-02-18  Jerry DeLisle  

Backport from gcc-5-branch.
PR libgfortran/69668
* io/list_read.c (read_character): Remove code related to DELIM_NONE.
* gfortran.dg/namelist_38.f90: Update test.
* gfortran.dg/namelist_84.f90: Update test.

Modified:
branches/gcc-4_9-branch/gcc/testsuite/ChangeLog
branches/gcc-4_9-branch/gcc/testsuite/gfortran.dg/namelist_38.f90
branches/gcc-4_9-branch/gcc/testsuite/gfortran.dg/namelist_84.f90
branches/gcc-4_9-branch/libgfortran/ChangeLog
branches/gcc-4_9-branch/libgfortran/io/list_read.c

[Bug fortran/69668] [4.9/5/6 Regression] Error reading namelist opened with DELIM='NONE'

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

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

--- Comment #9 from Jerry DeLisle  ---
Fixed on trunk, 5, and 4.9, closing

[Bug c/69866] New: lto1: internal compiler error: in add_symbol_to_partition_1, at lto/lto-partition.c:158

[acrsofter at gmail dot com]

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

Bug ID: 69866
   Summary: lto1: internal compiler error: in
add_symbol_to_partition_1, at lto/lto-partition.c:158
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: acrsofter at gmail dot com
  Target Milestone: ---

lto1: internal compiler error: in add_symbol_to_partition_1, at
lto/lto-partition.c:158
0x58b14d add_symbol_to_partition_1
../../gcc-5.3.0/gcc/lto/lto-partition.c:157
0x58aeb2 add_symbol_to_partition_1
../../gcc-5.3.0/gcc/lto/lto-partition.c:202
0x58c10c lto_balanced_map(int)
../../gcc-5.3.0/gcc/lto/lto-partition.c:550
0x58640d do_whole_program_analysis
../../gcc-5.3.0/gcc/lto/lto.c:3324
0x58640d lto_main()
../../gcc-5.3.0/gcc/lto/lto.c:3485
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
lto-wrapper: fatal error: arm-none-eabi-gcc returned 1 exit status
compilation terminated.
/files/work/acr/wip_elibos/elibos_toolchains/gcc-arm/gcc-arm-none-eabi-5.3.0-a/bin/../lib/gcc/arm-none-eabi/5.3.0/../../../../arm-none-eabi/bin/ld:
error: lto-wrapper failed
collect2: error: ld returned 1 exit status
../../../os/common/ports/ARMCMx/compilers/GCC/rules.mk:238: recipe for target
'build/ch.elf' failed
make: *** [build/ch.elf] Error 1



buildind ChibiOS_16.1.3/demos/STM32/RT-STM32F401RE-NUCLEO

https://sourceforge.net/projects/chibios/files/


./arm-none-eabi-gcc -v
Using built-in specs.
COLLECT_GCC=./arm-none-eabi-gcc
COLLECT_LTO_WRAPPER=/files/work/acr/wip_elibos/elibos_toolchains/gcc-arm/gcc-arm-none-eabi-5.3.0-a/bin/../libexec/gcc/arm-none-eabi/5.3.0/lto-wrapper
Target: arm-none-eabi
Configured with: ../gcc-5.3.0/configure --prefix=/opt/arm_cross
--target=arm-none-eabi --enable-languages=c,c++ --disable-multilib
--with-newlib
Thread model: single
gcc version 5.3.0 (GCC)

[Bug rtl-optimization/69847] Spec 2006 403.gcc slows down with -mlra vs. reload on PowerPC

[vmakarov at gcc dot gnu.org]

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

--- Comment #8 from Vladimir Makarov  ---
(In reply to Michael Meissner from comment #7)
> The following options were used for LRA code generation:
> -DSPEC_CPU -DNDEBUG -I.  -g -mlittle -save-temps=obj -ffast-math -O3
> -mveclibabi=mass -mcpu=power8 -mrecip=rsqrt -fpeel-loops -funroll-loops
> -ftree-vectorize -fvect-cost-model -msave-toc-indirect
> -fno-aggressive-loop-optimizations -mno-pointers-to-nested-functions -mlra 
> -m64 -I/opt/at8.0/include
> -I/opt/at8.0/lib/gcc/powerpc64le-linux-gnu/4.9.4/include -fgnu89-inline 
> -DSPEC_CPU_LP64 -DSPEC_CPU -DSPEC_CPU2006 -DINLINE=
> 
> The following options were used for reload code generation:
> -DSPEC_CPU -DNDEBUG -I.  -g -mlittle -save-temps=obj -ffast-math -O3
> -mveclibabi=mass -mcpu=power8 -mrecip=rsqrt -fpeel-loops -funroll-loops
> -ftree-vectorize -fvect-cost-model -msave-toc-indirect
> -fno-aggressive-loop-optimizations -mno-pointers-to-nested-functions  -m64
> -I/opt/at8.0/include
> -I/opt/at8.0/lib/gcc/powerpc64le-linux-gnu/4.9.4/include -fgnu89-inline 
> -DSPEC_CPU_LP64 -DSPEC_CPU -DSPEC_CPU2006 -DINLINE=

Mike, thanks for a good and detail report.  After spending some time on
comparison of code generated by reload and LRA, at least I found that LRA
generates unnecessary address reloads:

  Creating newreg=225, assigning class BASE_REGS to addr r225
  alt=0,overall=0,losers=0,rld_nregs=0
 Choosing alt 0 in insn 15:  (0) =Y  (1) r {*movdi_internal64}
   15: [r225:DI+low(unspec[`*.LANCHOR0',%2:DI] 47)]=r181:DI
  REG_DEAD r181:DI
  REG_DEAD %2:DI
Inserting insn reload before:
  133: r225:DI=high(unspec[`*.LANCHOR0',%2:DI] 47)

After checking what reload pass do in this situation, I found that reload
transforms the memnory address into sum of hi and low in the insn through
*LEGITIMIZE_RELOAD_ADDRESS* before actual reloading.

LRA does not use LEGITIMIZE_RELOAD_ADDRESS at all as the macro frequently uses
push_reload which is not a part of LRA.

I'll think how to fix it better.  Probably it will need introduction analogous
macro for LRA.

[Bug target/66337] __alignof__(s.d) incorrect for a double member with -malign-power

[dje at gcc dot gnu.org]

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

David Edelsohn  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2016-02-18
 CC||dje at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #4 from David Edelsohn  ---
I don't understand this bug report.  AIX does not use natural alignment because
the AIX ABI was created before "long long" existed and the team chose to not
create a larger alignment only for "double".  When the team realized the
mistake, they retrofitted the ABI to allow stricter alignment where the freedom
still existed -- singleton double and structures where double is the first
element (so the entire structure could transparently be aligned more strictly).

When ELF support was added to the rs6000 port, some customers wanted AIX
compatibility.  Support was added for ELF with and without function descriptors
and with and without AIX alignment.  -malign=power enables AIX-style alignment
for ELF.

The bug seems to be in the output of GCC builtin __alignof__.  How can a single
element member of a structure have weaker alignment, in reality, than the
structure itself?

The rs6000 port bumped the alignment of the structure but GCC still believes
that the element itself has the default alignment.  XLC correctly reports the
stricter interior alignment of the element.

[Bug fortran/69859] Non-deterministic ICEs on incomplete character declaration statement

[dmalcolm at gcc dot gnu.org]

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

--- Comment #4 from David Malcolm  ---
Running under valgrind, it looks like it's a use-after-free error:

$ cat ../../src/z7.f90 
program p
   type t
  character(2), allocatable :: a(*)
  character(*), allocatable :: b(2)
  character(*), allocatable :: c(*)
   end type
end

$ ./gfortran -B. ../../src/z7.f90 -wrapper valgrind
==6758== Memcheck, a memory error detector
==6758== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==6758== Using Valgrind-3.9.0 and LibVEX; rerun with -h for copyright info
==6758== Command: ./f951 ../../src/z7.f90 -quiet -dumpbase z7.f90
-mtune=generic -march=x86-64 -auxbase z7 -fintrinsic-modules-path finclude -o
/tmp/ccdQqEXb.s
==6758== 
../../src/z7.f90:3:39:

   character(2), allocatable :: a(*)
   1
Error: Allocatable component of structure at (1) must have a deferred shape
../../src/z7.f90:4:39:

   character(*), allocatable :: b(2)
   1
Error: Allocatable component of structure at (1) must have a deferred shape
../../src/z7.f90:5:39:

   character(*), allocatable :: c(*)
   1
Error: Allocatable component of structure at (1) must have a deferred shape
==6758== Invalid read of size 8
==6758==at 0x8399CF: resolve_fl_derived0(gfc_symbol*) (resolve.c:13196)
==6758==by 0x83A53D: resolve_fl_derived(gfc_symbol*) (resolve.c:13402)
==6758==by 0x83B161: resolve_symbol(gfc_symbol*) (resolve.c:13676)
==6758==by 0x85DED8: do_traverse_symtree(gfc_symtree*, void
(*)(gfc_symtree*), void (*)(gfc_symbol*)) (symbol.c:3817)
==6758==by 0x85DF93: gfc_traverse_ns(gfc_namespace*, void (*)(gfc_symbol*))
(symbol.c:3842)
==6758==by 0x83F7B0: resolve_types(gfc_namespace*) (resolve.c:15465)
==6758==by 0x83FC39: gfc_resolve(gfc_namespace*) (resolve.c:15575)
==6758==by 0x813CD0: resolve_all_program_units(gfc_namespace*)
(parse.c:5551)
==6758==by 0x814557: gfc_parse_file() (parse.c:5803)
==6758==by 0x868BC5: gfc_be_parse_file() (f95-lang.c:201)
==6758==by 0xF44FE3: compile_file() (toplev.c:465)
==6758==by 0xF47FD2: do_compile() (toplev.c:1988)
==6758==  Address 0x4dba140 is 0 bytes inside a block of size 48 free'd
==6758==at 0x4A07577: free (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==6758==by 0x85DA05: gfc_free_charlen(gfc_charlen*, gfc_charlen*)
(symbol.c:3664)
==6758==by 0x80E7E0: reject_statement() (parse.c:2318)
==6758==by 0x808C52: match_word(char const*, match (*)(), locus*)
(parse.c:70)
==6758==by 0x809888: decode_statement() (parse.c:372)
==6758==by 0x80CE20: next_free() (parse.c:1076)
==6758==by 0x80D481: next_statement() (parse.c:1310)
==6758==by 0x80EF6E: parse_derived() (parse.c:2672)
==6758==by 0x810505: parse_spec(gfc_statement) (parse.c:3368)
==6758==by 0x813252: parse_progunit(gfc_statement) (parse.c:5189)
==6758==by 0x814222: gfc_parse_file() (parse.c:5698)
==6758==by 0x868BC5: gfc_be_parse_file() (f95-lang.c:201)

(this is with r233261)

[Bug fortran/69867] New: ICE on initializing character in type with array of incompatible data

[gerhard.steinmetz.fort...@t-online.de]

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

Bug ID: 69867
   Summary: ICE on initializing character in type with array of
incompatible data
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gerhard.steinmetz.fort...@t-online.de
  Target Milestone: ---

An array on lhs with incompatible data :

$ cat z1.f90
program p
   type t
  character(1) :: c(1) = [1]
   end type
end

$ gfortran-6 z1.f90
f951: internal compiler error: Segmentation fault



More variants :

$ cat z2.f90
program p
   type t
  character(1) :: d(1) = [1.]
  character(1) :: e(1) = [1d1]
  character(1) :: f(1) = [(0.,1.)]
  character(1) :: g(1) = [.true.]
  character(1) :: h(1) = [.false.]
  character(1) :: n(1) = [null()]
   end type
end


rhs needs not to be an array to trigger an ICE :
(incompatible ranks 0 and 1 in assignment)

$ cat z3.f90
program p
   type t
  character(1) :: c = [1]
  character(1) :: d = [1.]
  character(1) :: e = [1d1]
  character(1) :: f = [(0.,1.)]
  character(1) :: g = [.true.]
  character(1) :: h = [.false.]
  character(1) :: n = [null()]
   end type
end

[Bug fortran/69867] ICE on initializing character in type with array of incompatible data

[gerhard.steinmetz.fort...@t-online.de]

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

--- Comment #1 from Gerhard Steinmetz  
---
Detected when lhs is a scalar :

$ cat z4.f90
program p
   type t
  character(1) :: c(1) = 1
   end type
end

$ gfortran-6 z4.f90
z4.f90:3:28:

   character(1) :: c(1) = 1
1
Error: Can't convert INTEGER(4) to CHARACTER(1) at (1)



And detected outside of a type, e.g. :

$ cat z5.f90
program p
   character(1) :: b = [1]
   character(1) :: c(1) = [1]
end

$ gfortran-6 z5.f90
z5.f90:2:20:

character(1) :: b = [1]
1
Error: Incompatible ranks 0 and 1 in assignment at (1)
z5.f90:3:25:

character(1) :: c(1) = [1]
 1
Error: Can't convert INTEGER(4) to CHARACTER(1) at (1)

[Bug fortran/69867] ICE on initializing character in type with array of incompatible data

[gerhard.steinmetz.fort...@t-online.de]

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

--- Comment #3 from Gerhard Steinmetz  
---
These issues are thematically related to pr67804 (... more or less).

[Bug fortran/69867] ICE on initializing character in type with array of incompatible data

[gerhard.steinmetz.fort...@t-online.de]

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

--- Comment #2 from Gerhard Steinmetz  
---
One exception from comment 1 :

$ cat z7.f90
program p
   type t
  character(1) :: b = null()
  character(1) :: c(1) = null()
   end type
end

$ gfortran-6 z7.f90
f951: internal compiler error: Segmentation fault

[Bug rtl-optimization/69847] Spec 2006 403.gcc slows down with -mlra vs. reload on PowerPC

[dje at gcc dot gnu.org]

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

David Edelsohn  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-02-18
 Ever confirmed|0   |1

--- Comment #9 from David Edelsohn  ---
Thanks for investigating, Vlad!

This issue seems likely to occur on all RISC architectures, especially
including ARM and SPARC in addition to PPC.

[Bug bootstrap/68404] [6 Regression] PGO/LTO bootstrap failure on ppc64le

[meissner at gcc dot gnu.org]

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

--- Comment #33 from Michael Meissner  ---
Author: meissner
Date: Thu Feb 18 19:36:39 2016
New Revision: 233532

URL: https://gcc.gnu.org/viewcvs?rev=233532&root=gcc&view=rev
Log:
[gcc]
2016-02-18  Michael Meissner  

PR target/68404
* config/rs6000/predicates.md (fusion_gpr_addis): Revert
2016-02-09 change.

* config/rs6000/rs6000.md (fusion_gpr_load_): Remove
earlyclobber from target.  Use wF constraint for fused memory
address.
(fusion_gpr___load): Likewise.

[gcc/testsuites]
2016-02-18  Michael Meissner  

PR target/68404
* gcc.target/powerpc/fusion.c: Revert the 2016-02-09 change.
* gcc.target/powerpc/fusion3.c: Likewise.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/predicates.md
trunk/gcc/config/rs6000/rs6000.md
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/powerpc/fusion.c
trunk/gcc/testsuite/gcc.target/powerpc/fusion3.c

[Bug bootstrap/68404] [6 Regression] PGO/LTO bootstrap failure on ppc64le

[meissner at gcc dot gnu.org]

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

Michael Meissner  changed:

   What|Removed |Added

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

--- Comment #34 from Michael Meissner  ---
Fixed in subversion id 233532.

[Bug bootstrap/68404] [6 Regression] PGO/LTO bootstrap failure on ppc64le

[meissner at gcc dot gnu.org]

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

--- Comment #35 from Michael Meissner  ---
Author: meissner
Date: Thu Feb 18 19:59:03 2016
New Revision: 233535

URL: https://gcc.gnu.org/viewcvs?rev=233535&root=gcc&view=rev
Log:
Merge in fix for PR 68404

Modified:
branches/ibm/power9/   (props changed)
branches/ibm/power9/gcc/ChangeLog
branches/ibm/power9/gcc/ChangeLog.ibm
branches/ibm/power9/gcc/ChangeLog.meissner
branches/ibm/power9/gcc/REVISION
branches/ibm/power9/gcc/config/rs6000/predicates.md
branches/ibm/power9/gcc/config/rs6000/rs6000.md
branches/ibm/power9/gcc/testsuite/ChangeLog
branches/ibm/power9/gcc/testsuite/ChangeLog.ibm
branches/ibm/power9/gcc/testsuite/gcc.target/powerpc/fusion.c
branches/ibm/power9/gcc/testsuite/gcc.target/powerpc/fusion3.c
branches/ibm/power9/libgcc/ChangeLog.ibm

Propchange: branches/ibm/power9/
('svn:mergeinfo' modified)

Propchange: branches/ibm/power9/
('svnmerge-integrated' modified)

[Bug target/69868] New: vec_perm built-in is not handled by swap optimization on powerpc64le

[wschmidt at gcc dot gnu.org]

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

Bug ID: 69868
   Summary: vec_perm built-in is not handled by swap optimization
on powerpc64le
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: target
  Assignee: wschmidt at gcc dot gnu.org
  Reporter: wschmidt at gcc dot gnu.org
CC: dje.gcc at gmail dot com, uweigand at gcc dot gnu.org
  Target Milestone: ---
Target: powerpc64le-unknown-linux-gnu

The following test case, compiled with --std=c++11 -maltivec -O3 on
powerpc64le-unknown-linux-gnu, produces assembly code from which the endian
swaps have not been removed.  The problem is that swap optimization is not
smart enough to recognize the patterns produced by the vec_perm built-in. 
Although we do recognize a vperm instruction whose permute control vector is
loaded from the constant pool, the vec_perm built-in produces a sequence in
which the PCV is loaded and then complemented, which requires more work to get
right.

This provides an opportunity for further performance improvement, since swap
optimization should be able to perform the complement at compile time, swap the
results, and create this as a new constant to be loaded in the generated code. 
This is something we've wanted to do anyway, and doing it in the context of
swap optimization will catch these opportunities immediately after expand.

Opening this against myself as a reminder to fix this during next stage 1.

Test case:

#include 
#include 

using VecUC = vector unsigned char;
using VecUI = vector unsigned int;

void bar(VecUC *vpInput, VecUI *vpOut)
{
  VecUI v1 = {0,};
  VecUI vMask = { 0xff, 0xff,0xff,0xff};
  VecUI vShift = { 0xf, 0xff,0xff,0xff};
  VecUC vPermControl = { 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15 };

#define FOO(a,b,c)  v1 = (VecUI)vec_perm(vpInput[a], vpInput[b], vPermControl);
\
  v1 = vec_sr(v1, vShift); \
  v1 = vec_and(v1, vMask);  \
  vpOut[c] = v1;

  FOO(0,0,0);
  FOO(0,0,1);
  FOO(0,1,2);
  FOO(0,1,3);
  FOO(1,0,4);
  FOO(1,0,5);
}

[Bug fortran/69867] ICE on initializing character in type with array of incompatible data

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-02-18
 Ever confirmed|0   |1

--- Comment #4 from Dominique d'Humieres  ---
Confirmed from 4.8 up to trunk (6.0). Note that compiling the first test in
comment 1 gives and ICE with gcc 4.9.3, while I get an ICE for the two tests
with gcc 4.8.5.

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

[jvdelisle at gcc dot gnu.org]

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

--- Comment #55 from Jerry DeLisle  ---
(In reply to H.J. Lu from comment #54)
> (In reply to alalaw01 from comment #53)
> > >
> > >So, there is nothing to fix in GCC? Why isn't this bug closed as invalid?
> > 
> > Not everyone wants to patch SPEC sources.
> 
> If the SPEC source is invalid according to Fortran standard, why should
> we change GCC for it?  This isn't the only invalid source in SPEC CPU
> 2006. There are at least 3.

The Fortran code is obviously legacy code. I think handling it behind
-std=legacy is the correct flag.

snip
> > 
> > --- Comment #45 from Jakub Jelinek  ---
> > Consider e.g. one source file
> >   INTEGER FOO
> >   COMMON /BLK/ K(64)
> >   DO I=1,64
> >   K(I)=1!!! typo should be =I
> >   END DO
> >   IF (FOO(5,12).NE.51) CALL ABORT
> >   END
> > and another one:
> >   FUNCTION FOO(I, J)
> >   COMMON /BLK/ K(1)
> >   FOO = K(I) + K(J) + K(2*I) + K(2*J)
> >   END FUNCTION

Note: Typo in the example

The correct solution to me is to detect the unequal sizes and convert the
COMMON /BLK/ K(1) to the larger size, ie K(64).

Currently we accept this code when it is all in one file and give a warning
only.  Playing with the test case in two files I see the problem is only with
K(1), K(2) or anything else gives correct results when optimized -O2, O3 etc.

Based on what I am seeing, I see no need for a flag at all, just a warning and
create the block to the size of the largest specified.

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

[dominiq at lps dot ens.fr]

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

--- Comment #56 from Dominique d'Humieres  ---
> >   FUNCTION FOO(I, J)
> >   COMMON /BLK/ K(1)
> >   FOO = K(I) + K(J) + K(2*I) + K(2*J)
> >   END FUNCTION

This piece of code is also invalid (out of bound access to K): K(I) + K(J) is
valid iff I=J=1, but K(2*I) + K(2*J) is always accessing elements outside the
array K(1).

> The correct solution to me is to detect the unequal sizes and convert
> the COMMON /BLK/ K(1) to the larger size, ie K(64).

This can be done at link time only if the two TU are in different files.

[Bug debug/60812] gcc -g -gpubnames statically linked produces a .debug_pubnames that is wrong or corrupted

[geir at cray dot com]

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

--- Comment #2 from Geir Johansen  ---
(In reply to Jakub Jelinek from comment #1)
> You haven't said which target it is, and we need preprocessed source as well.
> Couldn't reproduce this on x86_64-linux.

Problem does not occur in GCC 4.9.0, so this bug can be closed.

[Bug debug/60812] gcc -g -gpubnames statically linked produces a .debug_pubnames that is wrong or corrupted

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |WORKSFORME