[Bug c++/77465] New: rejected C-style cast involving casting away constness from result of conversion operator

[bbi5291 at gmail dot com]

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

Bug ID: 77465
   Summary: rejected C-style cast involving casting away constness
from result of conversion operator
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bbi5291 at gmail dot com
  Target Milestone: ---

The following code should compile, but does not. The Standard says that a
C-style cast can perform the conversion performed by a static_cast followed by
a const_cast. In this code, a static_cast followed by a const_cast is
well-formed, but the C-style cast is rejected. See also
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_closed.html#909

struct S {
typedef const int* P;
operator P() { return nullptr; }
};
int main() {
int* p1 = const_cast(static_cast(S{}));
int* p2 = (int*)(S{});
}

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.9/lto-wrapper
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)

[Bug c/77464] gcc -no-pie breaks -shared

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
You need -fPIC to create shared libraries.

[Bug c/77464] New: gcc -no-pie breaks -shared

[balint at balintreczey dot hu]

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

Bug ID: 77464
   Summary: gcc -no-pie breaks -shared
   Product: gcc
   Version: 6.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: balint at balintreczey dot hu
  Target Milestone: ---

Compiling shared libraries is broken with -no-pie, which should be a noop in
this case.

Test:
# echo "int bar(void) {return 0;}" > foo.c
# gcc -shared foo.c
# gcc -shared -no-pie foo.c
/usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/crt1.o: In function
`_start':
(.text+0x20): undefined reference to `main'
collect2: error: ld returned 1 exit status

This prevents enabling --enable-default-pie in Debian because when PIE is
disabled for a package -no-pie is added to LDFLAGS. 

One failure due to this bug:
https://people.debian.org/~lucas/logs/2016/08/30/pie-bindnow-20160830/with-pie-bindnow/afterstep_2.2.12-8_unstable_pie-bindnow.log.gz

Some background on enabling PIE by default on Debian:
https://lists.debian.org/debian-devel/2016/08/msg00620.html

[Bug target/77405] SIGBUS from gnatmake in stage 3 (gcc 7.0)

[gnugcc at marino dot st]

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

--- Comment #29 from John Marino  ---
 The DFly malloc returned an 8-byte aligned chunk because the requested
structural size was not 16-byte aligned.  However, we agree that any allocation
>= 16 bytes should probably be 16-byte aligned.

I tested a patch that aligns 15 and few bytes at 8 and everything else at 16. 
With that patch, gcc-7 with Ada front-end builds successfully.  We'll push that
patch to the master branch and the current release.

[Bug c++/62052] function parameter has wrong address in lambda converted to pointer-to-function

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  ---
N.B. Only the gcc-5 branch is still open for changes.

[Bug libfortran/77393] [7 Regression] Revision r237735 changed the behavior of F0.0

[dominiq at lps dot ens.fr]

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

--- Comment #9 from Dominique d'Humieres  ---
> Can you test by changing the define in write.c line 1349:
>
> #define BUF_STACK_SZ 256

On x86_64-apple-darwin15 the threshold (minimal value without SIGSEGV) is 385
with -m64 and 596 with -m32.

[Bug c++/77434] warn about suspicious precedence of ternary operator (?:)

[bernd.edlinger at hotmail dot de]

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

--- Comment #10 from Bernd Edlinger  ---
(In reply to Manuel López-Ibáñez from comment #9)
> It seems to me that they are two different warnings that could be triggered
> on similar code. The one warned by the patch would also warn about:
> 
> if (a ? 1 : 2)
> 
> but not about 
> 
>gcc_assert (die_offset > 0
>  && die_offset <= (loc->dw_loc_opc == DW_OP_call2)
>   ? 0
>   : 0x);
> 
> nor:
> 
>gcc_assert (die_offset > 0
>  && die_offset <= (loc->dw_loc_opc == DW_OP_call2)
>   ? n
>   : 0x);
> 
> This is what clang emits for a similar case (for which GCC does not warn):
> 
> prog.cc:3:26: warning: operator '?:' has lower precedence than '<<'; '<<'
> will be evaluated first [-Wparentheses]
>int n = a << (a == b) ? 1 :2;
>~ ^
> prog.cc:3:26: note: place parentheses around the '<<' expression to silence
> this warning
>int n = a << (a == b) ? 1 :2;
>  ^
>()
> prog.cc:3:26: note: place parentheses around the '?:' expression to evaluate
> it first
>int n = a << (a == b) ? 1 :2;
>  ^
> (  )
> 
> 
> Perhaps a middle-ground would be something like:
> 
> warning: operator '?:' has lower precedence than '=='; '==' will be
> evaluated first and '?:' will evaluate to integers in boolean context
> [-Wparentheses]
> if (a == b ? 1 : 2)
> ~~ ^
> note: place parentheses around the '==' expression to silence this warning
> if (a == b ? 1 : 2)
> ~~
> (a == b)
> note: place parentheses around the '?:' expression to evaluate it first
> if (a == b ? 1 : 2)
>  ~
>  (b ? 1 : 2)

I think normal C code like:

int x = a == b ? 1 : 2;

should not trigger a -Wall warning.

Maybe -Wextra, but even -Wextra
does not enable everything we have.
Probably because of too much false
positives?

But the warning on << at LHS of ?:
will rarely have false positives.
I mean << makes really no sense
in a truth value context.

For instance assume a is int;
then, I can show that:

"if (a << b)" would be the same as
"if (a)", because << has undefined
behaviour on overflow.  If the
user writes "<< b" then that should
not be undefined nor redundant.
The same logic that's behind my patch.
"if (a ? 1 : 2)" evaluates to "if (1)"
and that's something that can't
be right, as an assertion that is
written with 4 lines of ?: expression,
but it's evaluated to "if (0)" by the FE.

[Bug c++/77462] Error message prints source from wrong file after #line

[d.frey at gmx dot de]

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

--- Comment #2 from Daniel Frey  ---
(In reply to Manuel López-Ibáñez from comment #1)

Indeed, this is even worse than I thought.

FWIW, here's a reduced example for my code:

  static_assert( 2 + 2 == 4, "oops" );
  #line 1
  static_assert( 2 + 2 == 5, "oops" );

Leading to the same wrong error message, no explicit setting of the file is
necessary to confuse the compiler.

[Bug target/77267] MPX does not work in a presence of "-Wl,-as-needed" option (Ubuntu default)

[peter at lekensteyn dot nl]

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

Peter Wu  changed:

   What|Removed |Added

 CC||peter at lekensteyn dot nl

--- Comment #2 from Peter Wu  ---
Building Wireshark on Arch Linux with the -Wl,--as-needed linker option also
results in issues.

Example output during the linker stage (with -mmpx -fcheck-pointer-bounds):
/usr/lib/gcc/x86_64-pc-linux-gnu/6.2.1/../../../../lib/libmpxwrappers.so:
undefined reference to `get_bd'
collect2: error: ld returned 1 exit status

$ readelf -s /usr/lib/libmpxwrappers.so.2.0.0 | grep get_bd
 8:  0 NOTYPE  GLOBAL DEFAULT  UND get_bd
72:  0 NOTYPE  GLOBAL DEFAULT  UND get_bd
$ readelf -s /usr/lib/libmpx.so.2.0.0 | grep get_bd
38: 1720 8 FUNCGLOBAL DEFAULT   13 get_bd@@LIBMPX_2.0
   115: 1720 8 FUNCGLOBAL DEFAULT   13 get_bd

What helped here was explicitly adding -lmpxwrappers -lmpx to the linker flags.

[Bug c++/77462] Error message prints source from wrong file after #line

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

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

--- Comment #1 from Manuel López-Ibáñez  ---
I'm pretty sure there was an open bug already about this but I cannot find it.

What is even worse is that, even without #line, we cannot display the caret
line if the file is preprocessed and the original files cannot be found:

# 1 "filenotavailable.cc"
# 1 ""
# 1 ""
# 1 "/usr/include/stdc-predef.h" 1 3 4
# 1 "" 2
# 1 "filenotavailable.cc"
int main()
{
  static_assert( 2 + 2 == 5, "oops" );
}

$ g++ filenotavailable.ii -std=c++11
filenotavailable.cc: In function ‘int main()’:
filenotavailable.cc:3:3: error: static assertion failed: oops

[Bug c++/77427] [6/7 Regression] ice when canonical types differ for identical types

[vries at gcc dot gnu.org]

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

--- Comment #9 from Tom de Vries  ---
(In reply to Tom de Vries from comment #8)
> Created attachment 39537 [details]
> tentative patch
> 
> currently doing bootstrap and reg-test

succeeded

[Bug c/77463] New: internal compiler error: in output_move_qimode, at config/m68k/m68k.c:3160

[matthias.r...@hu-berlin.de]

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

Bug ID: 77463
   Summary: internal compiler error: in output_move_qimode, at
config/m68k/m68k.c:3160
   Product: gcc
   Version: 4.6.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: matthias.r...@hu-berlin.de
  Target Milestone: ---

Created attachment 39542
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39542=edit
File to reproduce the bug

When using the -Os switch, I get the following error:

In file included from libc/inet/inet_ntoa.c:8:0:
libc/inet/addr.c: In function 'inet_ntoa_r':
libc/inet/addr.c:135:1: internal compiler error: in output_move_qimode, at
config/m68k/m68k.c:3160

The error disappears without the mentioned switch.

Command line and output:

/home/matze/atari/gcc-4.6.3-nolibc/m68k-linux/bin/gcc -v -c inet_ntoa.i -Os 
-m68000
Using built-in specs.
COLLECT_GCC=/home/matze/atari/gcc-4.6.3-nolibc/m68k-linux/bin/gcc
COLLECT_LTO_WRAPPER=/home/matze/atari/gcc-4.6.3-nolibc/m68k-linux/bin/../libexec/gcc/m68k-linux/4.6.3/lto-wrapper
Target: m68k-linux
Configured with: /home/tony/buildall/src/gcc/configure --target=m68k-linux
--host=x86_64-linux-gnu --build=x86_64-linux-gnu --enable-targets=all
--prefix=/opt/cross/gcc-4.6.3-nolibc/m68k-linux/ --enable-languages=c
--with-newlib --without-headers --enable-sjlj-exceptions
--with-system-libunwind --disable-nls --disable-threads --disable-shared
--disable-libmudflap --disable-libssp --disable-libgomp --disable-decimal-float
--enable-checking=release --with-mpfr=/home/tony/buildall/src/sys-x86_64
--with-gmp=/home/tony/buildall/src/sys-x86_64 --disable-bootstrap
--disable-libquadmath
Thread model: single
gcc version 4.6.3 (GCC) 
COLLECT_GCC_OPTIONS='-v' '-c' '-Os' '-m68000'

/home/matze/atari/gcc-4.6.3-nolibc/m68k-linux/bin/../libexec/gcc/m68k-linux/4.6.3/cc1
-fpreprocessed inet_ntoa.i -quiet -dumpbase inet_ntoa.i -m68000 -auxbase
inet_ntoa -Os -version -o /tmp/ccBJ8k10.s
GNU C (GCC) version 4.6.3 (m68k-linux)
compiled by GNU C version 4.3.2, GMP version 4.3.2, MPFR version 2.4.2,
MPC version 0.8.2
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C (GCC) version 4.6.3 (m68k-linux)
compiled by GNU C version 4.3.2, GMP version 4.3.2, MPFR version 2.4.2,
MPC version 0.8.2
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 16d5cdc94766d56994b51e72043cc603
In file included from libc/inet/inet_ntoa.c:8:0:
libc/inet/addr.c: In function 'inet_ntoa_r':
libc/inet/addr.c:135:1: internal compiler error: in output_move_qimode, at
config/m68k/m68k.c:3160
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug middle-end/68270] [MPX] Common pattern for variable sized data clashes with MPX bound checks

[peter at lekensteyn dot nl]

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

Peter Wu  changed:

   What|Removed |Added

 CC||peter at lekensteyn dot nl

--- Comment #2 from Peter Wu  ---
GCC 6.2.1 is still affected by this. In C99 we can get away with flexible array
members, but this feature is unfortunately not defined in the C++
specification.

The idiom with an array of length 1 is quite common, is it possible to detect
that situation and relax the boundaries?

[Bug c++/77434] warn about suspicious precedence of ternary operator (?:)

[manu at gcc dot gnu.org]

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

--- Comment #9 from Manuel López-Ibáñez  ---
(In reply to Eric Gallager from comment #8)
> As a user, I'd prefer warning about the missing parentheses instead of the
> boolean context thing, the missing parentheses make a lot more sense to me
> and it'd be easier for me to understand how to fix it, whereas the boolean
> context one is a bit more confusing.

It seems to me that they are two different warnings that could be triggered on
similar code. The one warned by the patch would also warn about:

if (a ? 1 : 2)

but not about 

   gcc_assert (die_offset > 0
 && die_offset <= (loc->dw_loc_opc == DW_OP_call2)
  ? 0
  : 0x);

nor:

   gcc_assert (die_offset > 0
 && die_offset <= (loc->dw_loc_opc == DW_OP_call2)
  ? n
  : 0x);

This is what clang emits for a similar case (for which GCC does not warn):

prog.cc:3:26: warning: operator '?:' has lower precedence than '<<'; '<<' will
be evaluated first [-Wparentheses]
   int n = a << (a == b) ? 1 :2;
   ~ ^
prog.cc:3:26: note: place parentheses around the '<<' expression to silence
this warning
   int n = a << (a == b) ? 1 :2;
 ^
   ()
prog.cc:3:26: note: place parentheses around the '?:' expression to evaluate it
first
   int n = a << (a == b) ? 1 :2;
 ^
(  )


Perhaps a middle-ground would be something like:

warning: operator '?:' has lower precedence than '=='; '==' will be evaluated
first and '?:' will evaluate to integers in boolean context [-Wparentheses]
if (a == b ? 1 : 2)
~~ ^
note: place parentheses around the '==' expression to silence this warning
if (a == b ? 1 : 2)
~~
(a == b)
note: place parentheses around the '?:' expression to evaluate it first
if (a == b ? 1 : 2)
 ~
 (b ? 1 : 2)

[Bug c++/77462] New: Error message prints source from wrong file after #line

[d.frey at gmx dot de]

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

Bug ID: 77462
   Summary: Error message prints source from wrong file after
#line
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: d.frey at gmx dot de
  Target Milestone: ---

When I use #line, I can make the compiler print a source line from another file
when it encounters an error. This is totally misleading.

Consider two files, first fool.cc:

  #include "liar.hh"

  int main()
  {
static_assert( 2 + 2 == 4, "oops" );
  }

and a second file liar.hh:

  #line 5 "fool.cc"
static_assert( 2 + 2 == 5, "oops" );

If I now compile with GCC, I get:

frey@vbox::~/work/test/lie_to_me$ g++-6 -std=c++11 fool.cc 
In file included from fool.cc:1:0:
fool.cc:5:3: error: static assertion failed: oops
   static_assert( 2 + 2 == 4, "oops" );
   ^

Note the line says "2 + 2 == 4", which is the line from "fool.cc", not the one
where the error *actually* occurs, namely the one saying "2 + 2 == 5" from
"liar.hh". Clang gets it right:

frey@vbox:1:~/work/test/lie_to_me$ clang++-3.9 -std=c++11 fool.cc 
In file included from fool.cc:1:
fool.cc:5:3: error: static_assert failed "oops"
  static_assert( 2 + 2 == 5, "oops" );
  ^  ~~
1 error generated.

Yes, #line leads to "fool.cc:5:3", but that is fine and what is intended by
#line is AFAICT *not* to read the source line for the error message from that
file and line.

[Bug c++/62052] function parameter has wrong address in lambda converted to pointer-to-function

[mail+gnu at tzik dot jp]

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

Taiju Tsuiki  changed:

   What|Removed |Added

 CC||mail+gnu at tzik dot jp

--- Comment #5 from Taiju Tsuiki  ---
Looks like r233733 itself is the fix of this issue. It's cleanly applicable to
older branches and fixes the crash.

json: Could you cherry-pick r233733 to other release branches?

[Bug target/77405] SIGBUS from gnatmake in stage 3 (gcc 7.0)

[gnugcc at marino dot st]

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

--- Comment #28 from John Marino  ---
i can try.  we're actually discussing modifying how malloc works right now.

[Bug target/72827] [7 Regression] gnat bootstrap broken on powerpc64le-linux-gnu

[wschmidt at gcc dot gnu.org]

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

--- Comment #28 from Bill Schmidt  ---
Just recording that, as expected, this patch had neutral performance on
SPECcpu2006.

[Bug target/77405] SIGBUS from gnatmake in stage 3 (gcc 7.0)

[ebotcazou at gcc dot gnu.org]

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

--- Comment #27 from Eric Botcazou  ---
Does it help if you define MALLOC_OBSERVABLE_ALIGNMENT to 64 in
i386/dragonfly.h?

[Bug fortran/77461] SUM intrinsic passed array of HUGE values triggers ICE

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #1 from Dominique d'Humieres  ---
Duplicate of pr77460. A patch has been proposed in the comment.

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

[Bug fortran/77460] ICE when summing an overflowing array

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 CC||lkrupp at gcc dot gnu.org

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

[Bug fortran/77461] New: SUM intrinsic passed array of HUGE values triggers ICE

[lkrupp at gcc dot gnu.org]

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

Bug ID: 77461
   Summary: SUM intrinsic passed array of HUGE values triggers ICE
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lkrupp at gcc dot gnu.org
  Target Milestone: ---

As seen on comp.lang.fortran, this file:

double precision, parameter :: x = huge(1d0)
print*, sum((/x,-x/))
print*, sum((/x,x,-x,-x/))
print*, sum((/x,-x,1d0/))
print*, sum((/1d0,x,-x/))
end

triggers this ICE:

Error: Arithmetic overflow at (1)
f951: internal compiler error: Segmentation fault
0xba326f crash_signal
../../gcc_trunk/gcc/toplev.c:336
0x5de47b gfc_zero_size_array
../../gcc_trunk/gcc/fortran/arith.c:1657
0x5de47b reduce_binary0
../../gcc_trunk/gcc/fortran/arith.c:1671
0x5de47b eval_intrinsic_f3
../../gcc_trunk/gcc/fortran/arith.c:1720
0x6815eb simplify_transformation_to_scalar
../../gcc_trunk/gcc/fortran/simplify.c:491
0x61d2b1 do_simplify
../../gcc_trunk/gcc/fortran/intrinsic.c:4268
0x626f0b gfc_intrinsic_func_interface(gfc_expr*, int)
../../gcc_trunk/gcc/fortran/intrinsic.c:4617
0x66d72f resolve_unknown_f
../../gcc_trunk/gcc/fortran/resolve.c:2718
0x66d72f resolve_function
../../gcc_trunk/gcc/fortran/resolve.c:3020
0x66d72f gfc_resolve_expr(gfc_expr*)
../../gcc_trunk/gcc/fortran/resolve.c:6356
0x67217d gfc_resolve_code(gfc_code*, gfc_namespace*)
../../gcc_trunk/gcc/fortran/resolve.c:10543
0x671ca3 gfc_resolve_blocks(gfc_code*, gfc_namespace*)
../../gcc_trunk/gcc/fortran/resolve.c:9594
0x672356 gfc_resolve_code(gfc_code*, gfc_namespace*)
../../gcc_trunk/gcc/fortran/resolve.c:10533
0x6746e7 resolve_codes
../../gcc_trunk/gcc/fortran/resolve.c:15681
0x6747ae gfc_resolve(gfc_namespace*)
../../gcc_trunk/gcc/fortran/resolve.c:15716
0x65f754 resolve_all_program_units
../../gcc_trunk/gcc/fortran/parse.c:5875
0x65f754 gfc_parse_file()
../../gcc_trunk/gcc/fortran/parse.c:6127
0x6a1632 gfc_be_parse_file
../../gcc_trunk/gcc/fortran/f95-lang.c:198
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.

gfortran -v reports:

Target: x86_64-pc-linux-gnu
Configured with: ../gcc_trunk/configure --disable-multilib \
  --enable-languages=fortran
Thread model: posix
gcc version 7.0.0 20160902 (experimental) (GCC)

[Bug c++/77449] False ambiguity for variadic function with non-deduced template parameter

[rbock at eudoxos dot de]

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

--- Comment #2 from Roland B  ---
(In reply to Eric Gallager from comment #1)
> As a human reader who doesn't know C++ very well I'd consider it to be
> ambiguous, too... maybe as a compromise the error could be downgraded to a
> warning?

"int" is more specified than "typename Check", see also
http://stackoverflow.com/a/39295906/2173029

g++ agrees to this under pretty much all circumstances, except this one with a
parameter pack.

[Bug c++/77434] warn about suspicious precedence of ternary operator (?:)

[egall at gwmail dot gwu.edu]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egall at gwmail dot gwu.edu

--- Comment #8 from Eric Gallager  ---
As a user, I'd prefer warning about the missing parentheses instead of the
boolean context thing, the missing parentheses make a lot more sense to me and
it'd be easier for me to understand how to fix it, whereas the boolean context
one is a bit more confusing.

[Bug fortran/77460] ICE when summing an overflowing array

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

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

[Bug fortran/77460] New: ICE when summing an overflowing array

[kargl at gcc dot gnu.org]

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

Bug ID: 77460
   Summary: ICE when summing an overflowing array
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kargl at gcc dot gnu.org
  Target Milestone: ---

See in c.l.f.


double precision, parameter :: x = huge(1d0)
print*, sum((/x,-x/))
print*, sum((/x,x,-x,-x/))
print*, sum((/x,-x,1d0/))
print*, sum((/1d0,x,-x/))
end


With gfortran 4.6.3 I get:

print*, sum((/x,x,-x,-x/))
1
Error: Arithmetic overflow at (1)
f951: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

I have a patch

Index: simplify.c
===
--- simplify.c  (revision 239797)
+++ simplify.c  (working copy)
@@ -489,6 +489,8 @@ simplify_transformation_to_scalar (gfc_e
}

   result = op (result, gfc_copy_expr (a));
+  if (!result)
+   return result;
 }

   return result;

[Bug c/65467] [libgomp] sorry, unimplemented: '_Atomic' with OpenMP

[jakub at gcc dot gnu.org]

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

--- Comment #14 from Jakub Jelinek  ---
Author: jakub
Date: Fri Sep  2 18:38:07 2016
New Revision: 239964

URL: https://gcc.gnu.org/viewcvs?rev=239964=gcc=rev
Log:
PR c/65467
* gimplify.c (gimplify_adjust_omp_clauses_1): Diagnose implicit
map and firstprivate clauses on target construct for _Atomic
qualified decls.
(gimplify_adjust_omp_clauses): Diagnose explicit firstprivate clauses
on target construct for _Atomic qualified decls.
* omp-low.c (use_pointer_for_field): Return true for _Atomic qualified
decls.
* omp-simd-clone.c (simd_clone_clauses_extract): Warn and give up for
_Atomic qualified arguments not mentioned in uniform clause.
c/
* c-parser.c (c_parser_declspecs): Don't sorry about _Atomic if
flag_openmp.
(c_parser_omp_variable_list): Use convert_lvalue_to_rvalue
instead of mark_exp_read on low_bound/length expression.
(c_parser_omp_clause_num_gangs, c_parser_omp_clause_num_threads,
c_parser_omp_clause_num_tasks, c_parser_omp_clause_grainsize,
c_parser_omp_clause_priority, c_parser_omp_clause_hint,
c_parser_omp_clause_num_workers, c_parser_oacc_shape_clause,
c_parser_oacc_clause_tile, c_parser_omp_clause_schedule,
c_parser_omp_clause_vector_length, c_parser_omp_clause_num_teams,
c_parser_omp_clause_thread_limit, c_parser_omp_clause_aligned,
c_parser_omp_clause_linear, c_parser_omp_clause_safelen,
c_parser_omp_clause_simdlen, c_parser_omp_clause_device,
c_parser_omp_clause_dist_schedule): Use convert_lvalue_to_rvalue
instead of mark_expr_read.
(c_parser_omp_declare_reduction): Reject _Atomic qualified types.
* c-objc-common.h (LANG_HOOKS_OMP_CLAUSE_COPY_CTOR,
LANG_HOOKS_OMP_CLAUSE_ASSIGN_OP): Redefine.
* c-tree.h (c_omp_clause_copy_ctor): New prototype.
* c-typeck.c (handle_omp_array_sections_1): Diagnose _Atomic qualified
array section bases outside of depend clause, for depend clause
use convert_lvalue_to_rvalue on the base.
(c_finish_omp_clauses): Reject _Atomic qualified vars in reduction,
linear, aligned, map, to and from clauses.
(c_omp_clause_copy_ctor): New function.
c-family/
* c-omp.c (c_finish_omp_atomic): Reject _Atomic qualified expressions.
(c_finish_omp_for): Reject _Atomic qualified iterators.
testsuite/
* gcc.dg/gomp/_Atomic-1.c: New test.
* gcc.dg/gomp/_Atomic-2.c: New test.
* gcc.dg/gomp/_Atomic-3.c: New test.
* gcc.dg/gomp/_Atomic-4.c: New test.
* gcc.dg/gomp/_Atomic-5.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/gomp/_Atomic-1.c
trunk/gcc/testsuite/gcc.dg/gomp/_Atomic-2.c
trunk/gcc/testsuite/gcc.dg/gomp/_Atomic-3.c
trunk/gcc/testsuite/gcc.dg/gomp/_Atomic-4.c
trunk/gcc/testsuite/gcc.dg/gomp/_Atomic-5.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-omp.c
trunk/gcc/c/ChangeLog
trunk/gcc/c/c-objc-common.h
trunk/gcc/c/c-parser.c
trunk/gcc/c/c-tree.h
trunk/gcc/c/c-typeck.c
trunk/gcc/gimplify.c
trunk/gcc/omp-low.c
trunk/gcc/omp-simd-clone.c
trunk/gcc/testsuite/ChangeLog

[Bug libstdc++/77459] New: undefined reference to `snprintf' when building mingw-w64 cross-compiler

[gk at torproject dot org]

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

Bug ID: 77459
   Summary: undefined reference to `snprintf' when building
mingw-w64 cross-compiler
   Product: gcc
   Version: 6.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gk at torproject dot org
  Target Milestone: ---

When switching GCC to 6.2.0 I get the following compiler error while trying to
build the mingw-w64 cross-compiler:

/bin/bash ../libtool --tag CXX   --mode=link
/home/ubuntu/build/gcc/./gcc/xgcc -shared-libgcc -B/home/ubuntu/build/gcc/./gcc
-nostdinc++ -L/home/ubuntu/build/gcc/i686-w64-mingw32/libstdc++-v3/src
-L/home/ubuntu/build/gcc/i686-w64-mingw32/libstdc++-v3/src/.libs
-L/home/ubuntu/build/gcc/i686-w64-mingw32/libstdc++-v3/libsupc++/.libs
-L/home/ubuntu/install/mingw-w64/i686-w64-mingw32/lib
-L/home/ubuntu/install/mingw-w64/mingw/lib -isystem
/home/ubuntu/install/mingw-w64/i686-w64-mingw32/include -isystem
/home/ubuntu/install/mingw-w64/mingw/include
-B/home/ubuntu/install/mingw-w64/i686-w64-mingw32/bin/
-B/home/ubuntu/install/mingw-w64/i686-w64-mingw32/lib/ -isystem
/home/ubuntu/install/mingw-w64/i686-w64-mingw32/include -isystem
/home/ubuntu/install/mingw-w64/i686-w64-mingw32/sys-include -Wl,-O1 
-no-undefined -bindir
"/home/ubuntu/install/mingw-w64/i686-w64-mingw32/lib/../lib" -Wl,--gc-sections 
-std=gnu++98 -DDLL_EXPORT -DPIC -fno-implicit-templates  -Wall -Wextra
-Wwrite-strings -Wcast-qual -Wabi  -fdiagnostics-show-location=once  
-ffunction-sections -fdata-sections  -frandom-seed=libstdc++.la  -o
libstdc++.la -version-info 6:22:0 -Wl,--version-script=libstdc++-symbols.ver
-lm -rpath /home/ubuntu/install/mingw-w64/i686-w64-mingw32/lib/../lib
compatibility.lo compatibility-debug_list.lo compatibility-debug_list-2.lo 
compatibility-c++0x.lo compatibility-atomic-c++0x.lo
compatibility-thread-c++0x.lo compatibility-chrono.lo compatibility-condvar.lo 
../libsupc++/libsupc++convenience.la ../src/c++98/libc++98convenience.la
../src/c++11/libc++11convenience.la
libtool: link:  /home/ubuntu/build/gcc/./gcc/xgcc -shared-libgcc
-B/home/ubuntu/build/gcc/./gcc -nostdinc++
-L/home/ubuntu/build/gcc/i686-w64-mingw32/libstdc++-v3/src
-L/home/ubuntu/build/gcc/i686-w64-mingw32/libstdc++-v3/src/.libs
-L/home/ubuntu/build/gcc/i686-w64-mingw32/libstdc++-v3/libsupc++/.libs
-L/home/ubuntu/install/mingw-w64/i686-w64-mingw32/lib
-L/home/ubuntu/install/mingw-w64/mingw/lib -isystem
/home/ubuntu/install/mingw-w64/i686-w64-mingw32/include -isystem
/home/ubuntu/install/mingw-w64/mingw/include
-B/home/ubuntu/install/mingw-w64/i686-w64-mingw32/bin/
-B/home/ubuntu/install/mingw-w64/i686-w64-mingw32/lib/ -isystem
/home/ubuntu/install/mingw-w64/i686-w64-mingw32/include -isystem
/home/ubuntu/install/mingw-w64/i686-w64-mingw32/sys-include-shared
-nostdlib /home/ubuntu/install/mingw-w64/i686-w64-mingw32/lib/dllcrt2.o
/home/ubuntu/build/gcc/./gcc/crtbegin.o  .libs/compatibility.o
.libs/compatibility-debug_list.o .libs/compatibility-debug_list-2.o
.libs/compatibility-c++0x.o .libs/compatibility-atomic-c++0x.o
.libs/compatibility-thread-c++0x.o .libs/compatibility-chrono.o
.libs/compatibility-condvar.o  -Wl,--whole-archive
../libsupc++/.libs/libsupc++convenience.a
../src/c++98/.libs/libc++98convenience.a
../src/c++11/.libs/libc++11convenience.a -Wl,--no-whole-archive 
-L/home/ubuntu/build/gcc/i686-w64-mingw32/libstdc++-v3/libsupc++/.libs
-L/home/ubuntu/build/gcc/i686-w64-mingw32/libstdc++-v3/src
-L/home/ubuntu/build/gcc/i686-w64-mingw32/libstdc++-v3/src/.libs
-L/home/ubuntu/install/mingw-w64/i686-w64-mingw32/lib
-L/home/ubuntu/install/mingw-w64/mingw/lib -L/home/ubuntu/build/gcc/./gcc
-L/home/ubuntu/install/mingw-w64/i686-w64-mingw32/bin -lmingw32 -lgcc_s -lgcc
-lmoldname -lmingwex -lmsvcr100 -ladvapi32 -lshell32 -luser32 -lkernel32
-lmingw32 -lgcc_s -lgcc -lmoldname -lmingwex -lmsvcr100
/home/ubuntu/build/gcc/./gcc/crtend.o  -Wl,-O1 -Wl,--gc-sections
-Wl,--version-script=libstdc++-symbols.ver   -o .libs/libstdc++-6.dll
-Wl,--enable-auto-image-base -Xlinker --out-implib -Xlinker
.libs/libstdc++.dll.a
../src/c++11/.libs/libc++11convenience.a(debug.o): In function
`format_word':
   
/home/ubuntu/build/gcc/i686-w64-mingw32/libstdc++-v3/src/c++11/../../../../gcc-6.2.0/libstdc++-v3/src/c++11/debug.cc:535:
undefined reference to `snprintf'
   
/home/ubuntu/build/gcc/i686-w64-mingw32/libstdc++-v3/src/c++11/../../../../gcc-6.2.0/libstdc++-v3/src/c++11/debug.cc:535:
undefined reference to `snprintf'
   
/home/ubuntu/build/gcc/i686-w64-mingw32/libstdc++-v3/src/c++11/../../../../gcc-6.2.0/libstdc++-v3/src/c++11/debug.cc:535:
undefined reference to `snprintf'
collect2: error: ld returned 1 exit status 

Using GCC 5.1.0 works as expected.

[Bug target/77405] SIGBUS from gnatmake in stage 3 (gcc 7.0)

[hjl.tools at gmail dot com]

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

--- Comment #26 from H.J. Lu  ---
(In reply to John Marino from comment #25)
> I'm being told (one source) that that 16-byte alignment is not a x86-64 abi
> requirement.  I don't know either way.  Do you have an iron-clad reference
> about this requirement?
> 
> (Yes I know __gnat_malloc is libc malloc)

On Linux, "man malloc" shows

RETURN VALUE
   The malloc() and calloc() functions return a pointer to  the  allocated
   memory,  which  is  suitably  aligned for any built-in type.  On error,
   ^

Since __int128 and long double require 16 byte alignment, malloc should
return memory aligned to 16 bytes.

   these functions return NULL.  NULL may also be returned by a successful
   call  to  malloc() with a size of zero, or by a successful call to cal‐
   loc() with nmemb or size equal to zero.

[Bug target/77405] SIGBUS from gnatmake in stage 3 (gcc 7.0)

[gnugcc at marino dot st]

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

--- Comment #25 from John Marino  ---
I'm being told (one source) that that 16-byte alignment is not a x86-64 abi
requirement.  I don't know either way.  Do you have an iron-clad reference
about this requirement?

(Yes I know __gnat_malloc is libc malloc)

[Bug target/77405] SIGBUS from gnatmake in stage 3 (gcc 7.0)

[ebotcazou at gcc dot gnu.org]

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

--- Comment #24 from Eric Botcazou  ---
> Your __gnat_malloc doesn't return memory aligned to 16 bytes.  This
> violates x86-64 psABI.

To be exhaustive, __gnat_malloc is just a wrapper around the system malloc.

[Bug fortran/74600] [openacc] duplicate data map error

[tschwinge at gcc dot gnu.org]

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

Thomas Schwinge  changed:

   What|Removed |Added

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

[Bug tree-optimization/77444] Bogus assignments in cand_value_at

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek  ---
Author: jakub
Date: Fri Sep  2 17:12:27 2016
New Revision: 239962

URL: https://gcc.gnu.org/viewcvs?rev=239962=gcc=rev
Log:
PR tree-optimization/77444
* tree-ssa-loop-ivopts.c (cand_value_at): For pointers use sizetype
as steptype, remove redundant initialization.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-ssa-loop-ivopts.c

[Bug sanitizer/77396] address sanitizer crashes if all static global variables are optimized

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Author: jakub
Date: Fri Sep  2 17:11:42 2016
New Revision: 239961

URL: https://gcc.gnu.org/viewcvs?rev=239961=gcc=rev
Log:
PR sanitizer/77396
* sanopt.c: Include gimple-ssa.h, tree-phinodes.h and ssa-iterators.h.
(sanopt_optimize_walker): Optimize away
__asan_before_dynamic_init (...) followed by
__asan_after_dynamic_init () without intervening memory loads/stores.
* ipa-pure-const.c (special_builtin_state): Handle
BUILT_IN_ASAN_BEFORE_DYNAMIC_INIT and
BUILT_IN_ASAN_AFTER_DYNAMIC_INIT.

* decl2.c (do_static_initialization_or_destruction): Only
call asan_dynamic_init_call if INITP is true.

* g++.dg/asan/pr77396.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/asan/pr77396.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl2.c
trunk/gcc/ipa-pure-const.c
trunk/gcc/sanopt.c
trunk/gcc/testsuite/ChangeLog

[Bug target/77405] SIGBUS from gnatmake in stage 3 (gcc 7.0)

[hjl.tools at gmail dot com]

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

--- Comment #23 from H.J. Lu  ---
(In reply to John Marino from comment #22)
> (gdb) p/x $rax
> $1 = 0x800af0748

Your __gnat_malloc doesn't return memory aligned to 16 bytes.  This
violates x86-64 psABI.

[Bug target/77405] SIGBUS from gnatmake in stage 3 (gcc 7.0)

[gnugcc at marino dot st]

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

--- Comment #22 from John Marino  ---
(gdb) p/x $rax
$1 = 0x800af0748

[Bug target/77405] SIGBUS from gnatmake in stage 3 (gcc 7.0)

[hjl.tools at gmail dot com]

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

--- Comment #21 from H.J. Lu  ---
(In reply to John Marino from comment #20)
> Dump of assembler code for function osint__file_name_hash_table__setX:

>0x004cbb5a <+122>:   callq  0x60dc40 <__gnat_malloc>
>0x004cbb5f <+127>:   movdqa 0x0(%rbp),%xmm0
>0x004cbb64 <+132>:   mov0x84fd80(,%r12,8),%rdx
>0x004cbb6c <+140>:   mov%ebx,(%rax)
> => 0x004cbb6e <+142>:   movaps %xmm0,0x10(%rax)

Please show us:

(gdb) p/x $rax

[Bug c/77453] No builtin version of cbrtf

[amonakov at gcc dot gnu.org]

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

Alexander Monakov  changed:

   What|Removed |Added

 CC||amonakov at gcc dot gnu.org

--- Comment #5 from Alexander Monakov  ---
You won't gain much speed-wise from inlining scalar evaluation of cbrtf.
However, if the structure of your code allows that, you can get good speedup
from vectorized evaluation of cbrtf for 4 arguments at once. GCC can emit
vectorized cbrtf calls with -O3 -funsafe-math-optimizations -mveclibabi=svml.

[Bug other/77421] Bugs found in GCC with the help of PVS-Studio

[jakub at gcc dot gnu.org]

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

--- Comment #13 from Jakub Jelinek  ---
Author: jakub
Date: Fri Sep  2 16:18:35 2016
New Revision: 239959

URL: https://gcc.gnu.org/viewcvs?rev=239959=gcc=rev
Log:
PR other/77421
* config/i386/i386.c (ix86_expanded_args_builtin): Remove redundant
assignment added in r216794.

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

[Bug libfortran/77393] [7 Regression] Revision r237735 changed the behavior of F0.0

[jvdelisle at gcc dot gnu.org]

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

--- Comment #8 from Jerry DeLisle  ---
(In reply to Dominique d'Humieres from comment #7)
> > Works for me here!
> 
> Are you sure that you have tested
> 
> print "(f8.0)", huge(1.0)
> print "(f18.0)", huge(1.0_8)
> print "(f20.0)", huge(1.0_10)
> print "(f40.0)", huge(1.0_16)
> end
> 
> ?
$ cat pr77393-b.f90 
print "(f8.0)", huge(1.0)
print "(f18.0)", huge(1.0_8)
print "(f20.0)", huge(1.0_10)
print "(f40.0)", huge(1.0_16)
end
$ gfc pr77393-b.f90 
$ ./a.out 

**


$ gfc -v
Using built-in specs.
COLLECT_GCC=gfc
COLLECT_LTO_WRAPPER=/home/jerry/dev/usr/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../trunk/configure --prefix=/home/jerry/dev/usr
--enable-languages=c,c++,fortran --disable-libmudflap --enable-libgomp
--disable-bootstrap
Thread model: posix
gcc version 7.0.0 20160831 (experimental) (GCC) 

Yes, as posted. I suspect, assuming you are on Darwin, that the implementation
of snprintf emits a larger number of bytes. I found on the system here that it
emits the number of characters I used in the routine with the adders.

Can you test by changing the define in write.c line 1349:

#define BUF_STACK_SZ 256

to something absurd like 6000.

Then run this and see how large the strings are:

program testbigf0 ! Can enormous numbers be printed with F0.0 format?
  implicit none
  character(1) :: str

  write(str,"(f0.0)") -huge(1.0)
  print *, len(trim(str))
  write(str,"(f0.0)") -huge(1.0_8)
  print *, len(trim(str))
  write(str,"(f0.0)") -huge(1.0_10)
  print *, len(trim(str))
  write(str,"(f0.0)") -huge(1.0_16)
  print *, len(trim(str))
end program testbigf0

Also using gdb can you see where the segfault occurs with the pr77393-b.f90 
version above.

[Bug target/77405] SIGBUS from gnatmake in stage 3 (gcc 7.0)

[gnugcc at marino dot st]

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

--- Comment #20 from John Marino  ---
Dump of assembler code for function osint__file_name_hash_table__setX:
   0x004cbae0 <+0>: mov%edi,%eax
   0x004cbae2 <+2>: mov$0x80604837,%edx
   0x004cbae7 <+7>: push   %r12
   0x004cbae9 <+9>: imul   %edx
   0x004cbaeb <+11>:mov%edi,%r12d
   0x004cbaee <+14>:push   %rbp
   0x004cbaef <+15>:push   %rbx
   0x004cbaf0 <+16>:lea(%rdx,%rdi,1),%eax
   0x004cbaf3 <+19>:mov%edi,%edx
   0x004cbaf5 <+21>:sar$0x1f,%edx
   0x004cbaf8 <+24>:sar$0x9,%eax
   0x004cbafb <+27>:sub%edx,%eax
   0x004cbafd <+29>:imul   $0x3fd,%eax,%eax
   0x004cbb03 <+35>:sub%eax,%r12d
   0x004cbb06 <+38>:movslq %r12d,%r12
   0x004cbb09 <+41>:mov0x84fd80(,%r12,8),%rax
   0x004cbb11 <+49>:test   %rax,%rax
   0x004cbb14 <+52>:jne0x4cbb29

   0x004cbb16 <+54>:jmp0x4cbb50

   0x004cbb18 <+56>:nopl   0x0(%rax,%rax,1)
   0x004cbb20 <+64>:mov0x40(%rax),%rax
   0x004cbb24 <+68>:test   %rax,%rax
   0x004cbb27 <+71>:je 0x4cbb50

   0x004cbb29 <+73>:cmp(%rax),%edi
   0x004cbb2b <+75>:jne0x4cbb20

   0x004cbb2d <+77>:movdqa (%rsi),%xmm0
   0x004cbb31 <+81>:movaps %xmm0,0x10(%rax)
   0x004cbb35 <+85>:movdqa 0x10(%rsi),%xmm0
   0x004cbb3a <+90>:movaps %xmm0,0x20(%rax)
   0x004cbb3e <+94>:movdqa 0x20(%rsi),%xmm0
   0x004cbb43 <+99>:movaps %xmm0,0x30(%rax)
   0x004cbb47 <+103>:   pop%rbx
   0x004cbb48 <+104>:   pop%rbp
   0x004cbb49 <+105>:   pop%r12
   0x004cbb4b <+107>:   retq
   0x004cbb4c <+108>:   nopl   0x0(%rax)
   0x004cbb50 <+112>:   mov%rsi,%rbp
   0x004cbb53 <+115>:   mov%edi,%ebx
   0x004cbb55 <+117>:   mov$0x50,%edi
   0x004cbb5a <+122>:   callq  0x60dc40 <__gnat_malloc>
   0x004cbb5f <+127>:   movdqa 0x0(%rbp),%xmm0
   0x004cbb64 <+132>:   mov0x84fd80(,%r12,8),%rdx
   0x004cbb6c <+140>:   mov%ebx,(%rax)
=> 0x004cbb6e <+142>:   movaps %xmm0,0x10(%rax)
   0x004cbb72 <+146>:   movdqa 0x10(%rbp),%xmm0
   0x004cbb77 <+151>:   mov%rdx,0x40(%rax)
   0x004cbb7b <+155>:   movaps %xmm0,0x20(%rax)
   0x004cbb7f <+159>:   movdqa 0x20(%rbp),%xmm0
   0x004cbb84 <+164>:   mov%rax,0x84fd80(,%r12,8)
   0x004cbb8c <+172>:   movaps %xmm0,0x30(%rax)
   0x004cbb90 <+176>:   pop%rbx
   0x004cbb91 <+177>:   pop%rbp
   0x004cbb92 <+178>:   pop%r12
   0x004cbb94 <+180>:   retq
End of assembler dump.

[Bug target/77405] SIGBUS from gnatmake in stage 3 (gcc 7.0)

[hjl.tools at gmail dot com]

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

--- Comment #19 from H.J. Lu  ---
(In reply to John Marino from comment #18)
> does this help?
> 

Please show the output of

(gdb) disass

[Bug target/77405] SIGBUS from gnatmake in stage 3 (gcc 7.0)

[gnugcc at marino dot st]

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

--- Comment #18 from John Marino  ---
does this help?

Program received signal SIGBUS, Bus error.
0x004cbb6e in osint.file_name_hash_table.set (k=k@entry=31291,
e=...) at ../rts/s-htable.adb:381
381 Tab.Set (new Element_Wrapper'(K, E, null));
(gdb) bt
#0  0x004cbb6e in osint.file_name_hash_table.set (k=k@entry=31291,
e=...) at ../rts/s-htable.adb:381
#1  0x004cbc44 in osint.smart_find_file (n=31291, t=t@entry=source,
attr=...)
at
/home/marino/iterate-gcc-test/scratch/gcc-trunk-source/gcc/ada/osint.adb:2839
#2  0x004cf4d5 in osint.smart_find_file (t=source, n=)
at
/home/marino/iterate-gcc-test/scratch/gcc-trunk-source/gcc/ada/osint.adb:2814
#3  osint.full_source_name (n=) at
/home/marino/iterate-gcc-test/scratch/gcc-trunk-source/gcc/ada/osint.adb:1382
#4  osint.next_main_file () at
/home/marino/iterate-gcc-test/scratch/gcc-trunk-source/gcc/ada/osint.adb:2017
#5  0x004d1ca5 in osint.m.next_main_source () at
/home/marino/iterate-gcc-test/scratch/gcc-trunk-source/gcc/ada/osint-m.adb:49
#6  0x004929a8 in make.gnatmake () at
/home/marino/iterate-gcc-test/scratch/gcc-trunk-source/gcc/ada/make.adb:5847
#7  0x0045d015 in gnatmake () at
/home/marino/iterate-gcc-test/scratch/gcc-trunk-source/gcc/ada/gnatmake.adb:38
#8  0x00403067 in main (argc=argc@entry=26,
argv=argv@entry=0x7fffeec8, envp=envp@entry=0x7fffefa0) at
b_gnatm.adb:554
#9  0x004032be in _start (ap=0x7fffeec0, cleanup=)
at /usr/src/lib/csu/x86_64/crt1.c:90

[Bug target/77405] SIGBUS from gnatmake in stage 3 (gcc 7.0)

[gnugcc at marino dot st]

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

--- Comment #17 from John Marino  ---
that's easier said than done.  The command is over 1600 characters long 

i'll try to script it but ...

[Bug target/77405] SIGBUS from gnatmake in stage 3 (gcc 7.0)

[hjl.tools at gmail dot com]

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

--- Comment #16 from H.J. Lu  ---
(In reply to John Marino from comment #15)
> There's a complete log showing where in the build the SIGBUG occurs but as
> far as the assembly code that causes it, I have no idea.  If you provide me
> some instructions on how, maybe I can get some useful information for you.

Run the failed command under gdb. Then you can get backtrace and disassemble
the failed function.  It will show where the problem is.

[Bug target/77405] SIGBUS from gnatmake in stage 3 (gcc 7.0)

[gnugcc at marino dot st]

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

--- Comment #15 from John Marino  ---
to all:
I built August 28 snapshot of gcc7 with Ada frontend on FreeBSD 11.0-RC2, there
was no SIGBUS and it completed the build successfully.  (Not good news for DF I
guess)

to H.J.Lu:
There's a complete log showing where in the build the SIGBUG occurs but as far
as the assembly code that causes it, I have no idea.  If you provide me some
instructions on how, maybe I can get some useful information for you.

[Bug lto/77458] New: nvptx offloading ICEs after "Implement C _FloatN, _FloatNx types"

[tschwinge at gcc dot gnu.org]

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

Bug ID: 77458
   Summary: nvptx offloading ICEs after "Implement C _FloatN,
_FloatNx types"
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: openacc
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: tschwinge at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: jakub at gcc dot gnu.org, jsm28 at gcc dot gnu.org
  Target Milestone: ---

As of the PR32187 commit r239625 "Implement C _FloatN, _FloatNx types", nvptx
offloading is broken, ICEs in LTO stream-in.  Probably some kind of data-type
mismatch that is not visible with Intel MIC offloading (using the same data
types) but explodes with nvptx.  I'm having a look.

[Bug target/77405] SIGBUS from gnatmake in stage 3 (gcc 7.0)

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|NEW |WAITING
 CC|hjl at gcc dot gnu.org |hjl.tools at gmail dot 
com

--- Comment #14 from H.J. Lu  ---
(In reply to Eric Botcazou from comment #11)
> > * config/i386/i386.h (MOVE_MAX_PIECES): Use TImode in 64-bit
> > mode if unaligned SSE load and store are optimal.
> 
> Then the SIGBUS is trigged by an SSE intruction operating on unaligned
> memory and I presume that the kernel doesn't patch things up, unlike on
> Linux?

Linux x86 kernel doesn't patch unaligned load/store.  GCC should generate
unaligned load/store instructions when memory is misaligned.  Why does
GCC think memory is aligned when it is not.  Is this misaligned memory
on stack?  Please show the instruction where SIGBUS happened.

[Bug target/77457] New: Print intended value of constants in assembly output

[b7.10110111 at gmail dot com]

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

Bug ID: 77457
   Summary: Print intended value of constants in assembly output
   Product: gcc
   Version: 6.1.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: b7.10110111 at gmail dot com
  Target Milestone: ---

Consider the following simple program:

void f()
{
volatile double x=0.352;
}

I compile it with `gcc test.c -S -masm=intel -fverbose-asm` and get the
following for the value of `x`:

.LC0:
.long   34359738
.long   1071023915
.ident  "GCC: (Ubuntu 5.3.0-3ubuntu1~14.04) 5.3.0 20151204"

To decypher it while reading the listing one has to manually concatenate
hexadecimal forms of these two numbers, and then transform to floating-point
form. Not too handy.

For comparison, this is what I get from clang:

.LCPI0_0:
.quad   4600012688193243578 # double 0.35198
<...skipped some code...>
.ident  "Ubuntu clang version 3.8.0-svn257311-1~exp1 (trunk) (based on
LLVM 3.8.0)"


It would be really useful if GCC also printed the intended values of the
constants it emits. Namely, this should be done for float, double and long
double.

[Bug target/77457] Print intended value of constants in assembly output

[b7.10110111 at gmail dot com]

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

--- Comment #1 from Ruslan  ---
Same for version "GCC: (Ubuntu 6.1.1-3ubuntu11~14.04.1) 6.1.1 20160511"

[Bug c/77453] No builtin version of cbrtf

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

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

Andreas Schwab  changed:

   What|Removed |Added

 Resolution|FIXED   |INVALID

--- Comment #4 from Andreas Schwab  ---
About 90 inline assembler instructions (not counting the necessary inline
constant data) surely won't be faster than a function call.

[Bug c++/77456] New: Suboptimal code when returning a string generated with a constexpr fn at compile time

[petschy at gmail dot com]

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

Bug ID: 77456
   Summary: Suboptimal code when returning a string generated with
a constexpr fn at compile time
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: petschy at gmail dot com
  Target Milestone: ---

Created attachment 39541
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39541=edit
C++ source

I ran into this when converting expression trees to strings at compile time.
Though it's surely a rare application, the fix might have positive impact on a
wider range of scenarios.

The attached code converts the integers [0..N] to a string at compile time.
There are several conversions with differing N's. Also, some conversions
calculate the exact size of the resulting strings, others just use a large
enough buffer.

Platform is is Debian Jessie, x86-64. Tested w/ 6.x and 7.0. To compile:
g++ -std=c++14 -Wall -Wextra -O3 20160831-constexpr.cpp

Please be patient, this takes almost 30 secs on my machine (AMD FX 8150 @
4GHz), due to lots of compile-time constexpr work.

foo(): [0..13] w/ a 200 byte buffer. It seems that the initial zero fill of the
buffer is not considered in dead-store elimination, so the 200 bytes are rep
stos'd, then the actual characters are copied via xmm0 and bytewise literal
stores:

Dump of assembler code for function _Z3foov:
   0x00400620 <+0>: mov%rdi,%rdx
   0x00400623 <+3>: movq   $0x0,0xc0(%rdi)
   0x0040062e <+14>:lea0x8(%rdi),%rdi
   0x00400632 <+18>:mov%rdx,%rcx
   0x00400635 <+21>:movdqa 0x27033(%rip),%xmm0# 0x427670
   0x0040063d <+29>:and$0xfff8,%rdi
   0x00400641 <+33>:xor%eax,%eax
   0x00400643 <+35>:sub%rdi,%rcx
   0x00400646 <+38>:add$0xc8,%ecx
   0x0040064c <+44>:shr$0x3,%ecx
   0x0040064f <+47>:rep stos %rax,%es:(%rdi)
   0x00400652 <+50>:movups %xmm0,(%rdx)
   0x00400655 <+53>:movb   $0x38,0x10(%rdx)
   0x00400659 <+57>:movb   $0x20,0x11(%rdx)
   0x0040065d <+61>:mov%rdx,%rax
   0x00400660 <+64>:movb   $0x39,0x12(%rdx)
   0x00400664 <+68>:movb   $0x20,0x13(%rdx)
   0x00400668 <+72>:movb   $0x31,0x14(%rdx)
   0x0040066c <+76>:movb   $0x30,0x15(%rdx)
   0x00400670 <+80>:movb   $0x20,0x16(%rdx)
   0x00400674 <+84>:movb   $0x31,0x17(%rdx)
   0x00400678 <+88>:movb   $0x31,0x18(%rdx)
   0x0040067c <+92>:movb   $0x20,0x19(%rdx)
   0x00400680 <+96>:movb   $0x31,0x1a(%rdx)
   0x00400684 <+100>:   movb   $0x32,0x1b(%rdx)
   0x00400688 <+104>:   movb   $0x20,0x1c(%rdx)
   0x0040068c <+108>:   movb   $0x31,0x1d(%rdx)
   0x00400690 <+112>:   movb   $0x33,0x1e(%rdx)
   0x00400694 <+116>:   retq   

Since the buffer is larger, all the movb's could have been converted to another
xmm0 load+store. Though an explicit zero byte is written in the C++ code after
the last digit, this is missing in the disassembly above, so there is no "movb
$0x00, 0x1f(%rdx)" at the end, meaning that the compiler eliminated this store,
instead of merging all the 16 byte stores into a single xmm0 operation, and
skipping the first 32 bytes in the rep stos.

foo_sized() generates the same string, but first it calculates the needed size.
There is no zero fill here in the asm, so it was successfully eliminated, and
the characters are initialized via two xmm0 loads/stores, as expected:

Dump of assembler code for function _Z9foo_sizedv:
   0x004006a0 <+0>: movdqa 0x26fc8(%rip),%xmm0# 0x427670
   0x004006a8 <+8>: mov%rdi,%rax
   0x004006ab <+11>:movups %xmm0,(%rdi)
   0x004006ae <+14>:movdqa 0x26fca(%rip),%xmm0# 0x427680
   0x004006b6 <+22>:movups %xmm0,0x10(%rdi)
   0x004006ba <+26>:retq   

bar/bar_sized/bar_static/bar_sized_static(): the same as foo, but the range is
[0..42], and the static versions use a static constexpr, and return the buffer
pointer, not the buffer by value. 

bar() zero fills and then copies over with xmm0 and byte literals. bar_sized()
lacks the zero fill, but initializes the characters the same way. The static
versions just return a pointer as expected.

baz_sized() works as expected: since the memory to copy is large, it calls
memcpy instead of doing the above xmm0 + literal bytes stuff.

The problem is with baz(). The range is much larger, [0..4200]. There is no DSE
here either, so the buffer is first zeroed with memset, but then ALL the
characters are initialized via bytewise literal stores, resulting in very large
function, around 138K. Why 

[Bug c++/77449] False ambiguity for variadic function with non-deduced template parameter

[egall at gwmail dot gwu.edu]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egall at gwmail dot gwu.edu

--- Comment #1 from Eric Gallager  ---
The full error message is:

$ /usr/local/bin/g++ -c -Wall -Wextra pr77449.cc
pr77449.cc: In function ‘int main()’:
pr77449.cc:11:17: error: call of overloaded ‘bar(int, const char [1])’ is
ambiguous
  bar(7, ""); // ambiguous according to gcc
 ^
pr77449.cc:4:6: note: candidate: void bar(Check, T ...) [with X = void; Check =
int; T = {const char*}]
 auto bar(Check, T...) -> void;
  ^~~
pr77449.cc:7:6: note: candidate: void bar(int, T ...) [with X = void; T =
{const char*}]
 auto bar(int, T...) -> void;
  ^~~

As a human reader who doesn't know C++ very well I'd consider it to be
ambiguous, too... maybe as a compromise the error could be downgraded to a
warning?

[Bug c/77453] No builtin version of cbrtf

[matthieu.schaller at durham dot ac.uk]

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

Matthieu Schaller  changed:

   What|Removed |Added

 Resolution|WONTFIX |FIXED

--- Comment #3 from Matthieu Schaller  
---
(In reply to Richard Biener from comment #2)
> Adding an inline variant is unlikely a win.  As noted by Joseph a "builtin"
> is not what you expect.  No CPU I am aware of has a cbrt operation
> implemented in hardware.

Agreed that there are no chip-level instructions but surely an inlined set of
assembly instructions in the code will be faster than a function call to this
same set of assembly instructions within the libm, no?

[Bug tree-optimization/77450] [5/6/7 Regression] ICE: in verify_ssa, at tree-ssa.c:1016 on very simple code with vectors

[joseph at codesourcery dot com]

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

--- Comment #2 from joseph at codesourcery dot com  ---
On Fri, 2 Sep 2016, rguenth at gcc dot gnu.org wrote:

> so it looks like COMPOUND_LITERAL_EXPR is an lvalue?  Do we need to

Yes.  Compound literals are lvalues; they represent anonymous variables 
with a given initializer (and the same lifetime as a named variable 
declared at that point).

[Bug rtl-optimization/71956] [7 Regression] 176.gcc fails on 32 bits when compiled with -march=core-avx2

[ysrumyan at gmail dot com]

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

--- Comment #5 from Yuri Rumyantsev  ---
This bug is fixed by
Author: ppalka
Date: Sat Aug 27 22:00:17 2016
New Revision: 239798

URL: https://gcc.gnu.org/viewcvs?rev=239798=gcc=rev
Log:
Fix folding of VECTOR_CST comparisons

gcc/ChangeLog:

PR tree-optimization/71077
PR tree-optimization/68542
* fold-const.c (fold_relational_const): Fix folding of
VECTOR_CST comparisons that have a scalar boolean result type.
(selftest::test_vector_folding): New static function.
(selftest::fold_const_c_tests): Call it.

gcc/testsuite/ChangeLog:

PR tree-optimization/71077
* gcc.target/i386/pr71077.c: New test.


Added:
trunk/gcc/testsuite/gcc.target/i386/pr71077.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/fold-const.c
trunk/gcc/testsuite/ChangeLog

So this bug must be closed.

[Bug tree-optimization/77450] [5/6/7 Regression] ICE: in verify_ssa, at tree-ssa.c:1016 on very simple code with vectors

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords|ice-on-valid-code   |ice-on-invalid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-09-02
 CC||jsm28 at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org
   Target Milestone|--- |5.5
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
The FE creates (on trunk)

  VIEW_CONVERT_EXPR(<<< Unknown tree: compound_literal_expr
V D.1794 = { 0 }; >>>)[0] = 0;

which is gimplified to

foo ()
{
  V D.1794;

  D.1794 = { 0 };
  BIT_FIELD_REF  = 0;

the issue is that D.1794 is marked as DECL_GIMPLE_REG_P but that is bougs
(and shows after into-SSA).

I believe the testcase is invalid and ought to be rejected - you can't
write to {}.

Breakpoint 5, convert_vector_to_array_for_subscript (loc=180896, 
vecp=0x7fffcef0, index=)
at /space/rguenther/src/svn/trunk/gcc/c-family/c-common.c:12711
(gdb) p debug_generic_expr (*vecp)
<<< Unknown tree: compound_literal_expr
V D.1794 = { 0 }; >>>
$1 = void
(gdb) n
12712 ret = !lvalue_p (*vecp);
(gdb) 
12714 if (TREE_CODE (index) == INTEGER_CST)
(gdb) p ret
$2 = false


so it looks like COMPOUND_LITERAL_EXPR is an lvalue?  Do we need to
handle COMPOUND_LITERAL_EXPR by emitting a COMPOUND_EXPR with the
second stmt operating on DECL_EXPR_DECL (COMPOUND_LITERAL_EXPR_DECL_EXPR
(*vecp))?  Or is the error on the gimplification side (in setting
DECL_GIMPLE_REG_P)?  Which would mean that eventually
c_common_mark_addressable_vec doesn't handle COMPOUND_LITERAL_EXPR correctly.

[Bug target/77405] SIGBUS from gnatmake in stage 3 (gcc 7.0)

[gnugcc at marino dot st]

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

--- Comment #13 from John Marino  ---
I just want to remind that gcc 7 builds fine on DF when the Ada frontend is
excluded from the build.  That's partially why it took so long to see this
regression.

[Bug c/77453] No builtin version of cbrtf

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #2 from Richard Biener  ---
Adding an inline variant is unlikely a win.  As noted by Joseph a "builtin" is
not what you expect.  No CPU I am aware of has a cbrt operation implemented in
hardware.

[Bug target/77452] [7 Regression] ICE: in plus_constant, at explow.c:87 with -fno-split-wide-types -mavx512f --param=max-combine-insns=2

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |7.0

[Bug tree-optimization/77454] [7 Regression] IMM ERROR w/ -O2 and above

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-09-02
   Target Milestone|--- |7.0
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed on native x86_64.

#15 0x00d809d8 in execute_one_pass (pass=
)
at /space/rguenther/src/svn/trunk/gcc/passes.c:2383
2383

thus triggered by DOM.

[Bug target/77405] SIGBUS from gnatmake in stage 3 (gcc 7.0)

[gnugcc at marino dot st]

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

--- Comment #12 from John Marino  ---
I don't know.  If you have a specific question or a test case that illustrates
it, I can bring up the topic to the DF developers.

I don't know if we are pointing fingers at the OS or GCC though, only that this
commit introduces a regression.

[Bug target/77405] SIGBUS from gnatmake in stage 3 (gcc 7.0)

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|WAITING |NEW
 CC||hjl at gcc dot gnu.org
  Component|ada |target

--- Comment #11 from Eric Botcazou  ---
>   * config/i386/i386.h (MOVE_MAX_PIECES): Use TImode in 64-bit
>   mode if unaligned SSE load and store are optimal.

Then the SIGBUS is trigged by an SSE intruction operating on unaligned memory
and I presume that the kernel doesn't patch things up, unlike on Linux?

[Bug c/77453] No builtin version of cbrtf

[joseph at codesourcery dot com]

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

--- Comment #1 from joseph at codesourcery dot com  ---
Most built-in versions of libm functions just optimize them for constant 
arguments.

[Bug target/77455] [AArch64] eh_return implementation fails

[wdijkstr at arm dot com]

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

Wilco  changed:

   What|Removed |Added

 Target||AArch64
  Known to fail||4.8.4

--- Comment #1 from Wilco  ---
See https://gcc.gnu.org/ml/gcc-patches/2016-09/msg00077.html for more details,
a simpler reimplementation and a testcase.

[Bug target/77455] New: [AArch64] eh_return implementation fails

[wdijkstr at arm dot com]

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

Bug ID: 77455
   Summary: [AArch64] eh_return implementation fails
   Product: gcc
   Version: 4.8.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wdijkstr at arm dot com
  Target Milestone: ---

The __builtin_eh_return implementation on AArch64 generates incorrect code for
many cases due to using an incorrect offset/pointer when writing the new return
address to the stack. Also optimizations may remove the write due to a missing
scheduling barrier. As a result in most cases eh_return does not work properly.

[Bug tree-optimization/77454] New: [7 Regression] IMM ERROR w/ -O2 and above

[asolokha at gmx dot com]

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

Bug ID: 77454
   Summary: [7 Regression] IMM ERROR w/ -O2 and above
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

gcc-7.0.0-alpha20160828 prints out IMM error when compiling the following
reduced snippet:

void
oo (unsigned char co, char fc)
{
  while (co != 0)
{
  unsigned char *z4 = 
  int q3;

  if (fc != 0)
z4 = (unsigned char *)
  else if (fc + 1 != 0)
z4 = (unsigned char *)
  for (co = 0; co < 1; ++co)
q3 = 0;
  for (fc = 0; fc < 3; ++fc)
{
  fc = !!fc;
  if (fc != 0)
co = fc;
}
  if ((q3 != 0 ? -1 : *z4) < (fc = q3))
q3 = 1;
}
}

% x86_64-pc-linux-gnu-gcc-7.0.0-alpha20160828 -O2 -c lzfl5bs8.c 
 IMM ERROR : (use_p : tree - 0x39cdca962b8:0x39cdca91440)0

Despite this error, it compiles the snippet successfully and generates correct
code.

I get this error from time to time w/ different targets for the last several
weeks at least. However, it's the first file that I got which is way smaller
then 100 kB.

[Bug c/77453] New: No builtin version of cbrtf

[matthieu.schaller at durham dot ac.uk]

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

Bug ID: 77453
   Summary: No builtin version of cbrtf
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: matthieu.schaller at durham dot ac.uk
  Target Milestone: ---

More of a feature request than a bug. 

System: Any Linux platform
GCC version : Any

I have a piece of software that relies heavily on the math cube root function
'cbrtf()'. According to the GCC documentation this function can be replaced by
builtins. However, this does not seem to be the case.

Compiling with `-O3 -std=gnu11 -ffast-math`, the following snippet

float pow_gamma(float x) {

  const float cbrt = cbrtf(x); /* x^(1/3) */
  return cbrt * cbrt  * x;  /* x^(5/3) */
}  

leads to the following assembly:

pow_gamma(float):
subq$24, %rsp
movss   %xmm0, 12(%rsp)
callcbrtf
mulss   %xmm0, %xmm0
movss   12(%rsp), %xmm1
addq$24, %rsp
mulss   %xmm1, %xmm0
ret

with a clear call to a function rather than a builtin. 

Note that when repeating the exercise with a sqrt rather than cbrt, GCC
replaces the call to the function by the sqrt assembly instruction, as
expected.

Could a builtin version of `cbrtf` be added ?

[Bug target/77452] [7 Regression] ICE: in plus_constant, at explow.c:87 with -fno-split-wide-types -mavx512f --param=max-combine-insns=2

[zsojka at seznam dot cz]

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

--- Comment #1 from Zdenek Sojka  ---
(gdb) p mode
$4 = SImode
(gdb) p *x  
$6 = {code = CONST_VECTOR, mode = V2SImode, ...

[Bug c/65467] [libgomp] sorry, unimplemented: '_Atomic' with OpenMP

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

  Attachment #39524|0   |1
is obsolete||
 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org

--- Comment #13 from Jakub Jelinek  ---
Created attachment 39540
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39540=edit
gcc7-pr65467.patch

Untested updated patch I'm going to bootstrap/regtest.

[Bug target/77452] New: [7 Regression] ICE: in plus_constant, at explow.c:87 with -fno-split-wide-types -mavx512f --param=max-combine-insns=2

[zsojka at seznam dot cz]

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

Bug ID: 77452
   Summary: [7 Regression] ICE: in plus_constant, at explow.c:87
with -fno-split-wide-types -mavx512f
--param=max-combine-insns=2
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu
 Build: x86_64-pc-linux-gnu

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

Compiler output:
$ x86_64-pc-linux-gnu-gcc -O -fno-split-wide-types -mavx512f
--param=max-combine-insns=2 testcase.c 
testcase.c: In function 'foo':
testcase.c:10:1: internal compiler error: in plus_constant, at explow.c:87
 }
 ^
0x8377af plus_constant(machine_mode, rtx_def*, long, bool)
/repo/gcc-trunk/gcc/explow.c:87
0x83756d plus_constant(machine_mode, rtx_def*, long, bool)
/repo/gcc-trunk/gcc/explow.c:109
0x6ed9bd init_alias_analysis()
/repo/gcc-trunk/gcc/alias.c:3359
0x9cba44 ira
/repo/gcc-trunk/gcc/ira.c:5174
0x9cba44 execute
/repo/gcc-trunk/gcc/ira.c:5526
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-239934-checking-yes-rtl-df-extra-nographite-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--without-cloog --without-ppl --without-isl --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu
--with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-239934-checking-yes-rtl-df-extra-nographite-amd64
Thread model: posix
gcc version 7.0.0 20160901 (experimental) (GCC) 

Tested revisions:
trunk r239934 - ICE
6-branch r239849 - OK

[Bug ada/77405] SIGBUS from gnatmake in stage 3 (gcc 7.0)

[gnugcc at marino dot st]

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

--- Comment #10 from John Marino  ---
Okay, I bisected this.

SVN r239376 (August 11) is the last commit that works

I confirmed that r239378, the next commit on the TRUNK, fails to build,
resulting with the SIGBUS error.


The log for that commit is:
Use TImode for piecewise move in 64-bit mode.  We should use TImode in
32-bit mode and use OImode or XImode if they are available.  But since
by_pieces_ninsns determines the widest mode with MAX_FIXED_MODE_SIZE,
we can only use TImode in 64-bit mode.

gcc/

* config/i386/i386.h (MOVE_MAX_PIECES): Use TImode in 64-bit
mode if unaligned SSE load and store are optimal.

[Bug c++/77451] New: Cannot convert lambda [](auto&&...){} to std::function<void()>

[gnu-9fbaow at upsuper dot org]

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

Bug ID: 77451
   Summary: Cannot convert lambda [](auto&&...){} to
std::function
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gnu-9fbaow at upsuper dot org
  Target Milestone: ---

Test code:
> #include 
> 
> int main()
> {
>   std::function f = [](auto&&...) {};
>   return 0;
> }
with
> g++-6 -std=c++14 test.cpp

The compiler outputs
> test.cpp:5:44: error: conversion from 'main()::' to 
> non-scalar type 'std::function' requested
>std::function f = [](auto&&...) {};

[Bug tree-optimization/77450] New: [5/6/7 Regression] ICE: in verify_ssa, at tree-ssa.c:1016 on very simple code with vectors

[zsojka at seznam dot cz]

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

Bug ID: 77450
   Summary: [5/6/7 Regression] ICE: in verify_ssa, at
tree-ssa.c:1016 on very simple code with vectors
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu
 Build: x86_64-pc-linux-gnu

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

Compiler output:
$ x86_64-pc-linux-gnu-gcc testcase.c
testcase.c: In function 'foo':
testcase.c:7:1: internal compiler error: in verify_ssa, at tree-ssa.c:1016
 }
 ^
0xde3139 verify_ssa(bool, bool)
/repo/gcc-trunk/gcc/tree-ssa.c:1016
0xac5e25 execute_function_todo
/repo/gcc-trunk/gcc/passes.c:1971
0xac6c8f do_per_function
/repo/gcc-trunk/gcc/passes.c:1655
0xac6d06 execute_todo
/repo/gcc-trunk/gcc/passes.c:2014
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

$ x86_64-pc-linux-gnu-gcc testcase.c -W
testcase.c: In function 'foo':
testcase.c:7:1: internal compiler error: in execute_todo, at passes.c:2009
 }
 ^
0xac6dda execute_todo
/repo/gcc-trunk/gcc/passes.c:2009
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

$ x86_64-pc-linux-gnu-gcc -v   
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-239934-checking-yes-rtl-df-extra-nographite-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--without-cloog --without-ppl --without-isl --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu
--with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-239934-checking-yes-rtl-df-extra-nographite-amd64
Thread model: posix
gcc version 7.0.0 20160901 (experimental) (GCC) 

Tested revisions:
r239934 - ICE
6-branch r239849 - ICE
5-branch r239848 - ICE
4_9-branch r239063 - ICE
4_8-branch r224828 - ICE
4_7-branch r211571 - OK

[Bug target/77439] [6/7 regression] wrong code for sibcall with longcall, APCS frame and VFP

[rearnsha at gcc dot gnu.org]

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

Richard Earnshaw  changed:

   What|Removed |Added

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

--- Comment #2 from Richard Earnshaw  ---
I'm not sure why the epilogue generates this sequence.  For this particular
instance we could generate

sub sp, fp, #36
vldmsp!, {d8}
ldmfd   sp, {r4, r5, r6, r7, fp, sp, lr}
bx  ip

And save an instruction as well as keeping IP clear, but I've not looked to see
if there are other complications that prevent this in the more general case.

Note that
 ldmfd   sp, {r4, r5, r6, r7, fp, sp, lr}

has been deprecated in the ARM Architecture and so -mapcs-frame is consequently
also deprecated.

[Bug fortran/72832] [6/7 Regression] [OOP] ALLOCATE with SOURCE fails to allocate requested dimensions

[vehre at gcc dot gnu.org]

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

--- Comment #8 from vehre at gcc dot gnu.org ---
Patch available at:

https://gcc.gnu.org/ml/fortran/2016-09/msg7.html

Awaiting comments/review.

[Bug c++/77427] [6/7 Regression] ice when canonical types differ for identical types

[vries at gcc dot gnu.org]

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

--- Comment #8 from Tom de Vries  ---
Created attachment 39537
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39537=edit
tentative patch

currently doing bootstrap and reg-test

[Bug c++/77449] New: False ambiguity for variadic function with non-deduced template parameter

[rbock at eudoxos dot de]

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

Bug ID: 77449
   Summary: False ambiguity for variadic function with non-deduced
template parameter
   Product: gcc
   Version: 6.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rbock at eudoxos dot de
  Target Milestone: ---

g++ considers the following code ambiguous:

template 
auto bar(Check, T...) -> void;

template 
auto bar(int, T...) -> void;

int main()
{
  bar(7, ""); // ambiguous according to gcc
  bar(7); // just fine
}


clang, msvc and icc agree that `auto bar(int, T...) -> void;` is more specific.
They therefore consider the code non-ambiguous.

Hint: The ambiguity is not seen by g++ if 
  - parameter T is non-variadic or
  - parameter X is removed

[Bug c++/77427] [6/7 Regression] ice when canonical types differ for identical types

[vries at gcc dot gnu.org]

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

--- Comment #7 from Tom de Vries  ---
(In reply to Tom de Vries from comment #4)
> This fixes the ICE:
> ...
> diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
> index 4531647..f13790f 100644
> --- a/gcc/config/i386/i386.c
> +++ b/gcc/config/i386/i386.c
> @@ -10551,6 +10551,8 @@ ix86_build_builtin_va_list_64 (void)
>TYPE_ATTRIBUTES (record) = tree_cons (get_identifier ("sysv_abi va_list"),
> NULL_TREE, TYPE_ATTRIBUTES (record));
>  
> +  SET_TYPE_STRUCTURAL_EQUALITY (record);
> +
>/* The correct type is an array type of one element.  */
>return build_array_type (record, build_index_type (size_zero_node));
>  }
> ...

But causes regressions in bootstrap and reg-test:
...
+./gcc/testsuite/g++/g++.sum:FAIL: g++.dg/other/vararg-4.C  -std=c++11 (test
for excess errors)
+./gcc/testsuite/g++/g++.sum:FAIL: g++.dg/other/vararg-4.C  -std=c++14 (test
for excess errors)
+./gcc/testsuite/g++/g++.sum:FAIL: g++.dg/other/vararg-4.C  -std=c++98 (test
for excess errors)
+./gcc/testsuite/g++/g++.sum:FAIL: g++.dg/warn/Wunused-parm-3.C  -std=gnu++11
(test for excess errors)
+./gcc/testsuite/g++/g++.sum:FAIL: g++.dg/warn/Wunused-parm-3.C  -std=gnu++14
(test for excess errors)
+./gcc/testsuite/g++/g++.sum:FAIL: g++.dg/warn/Wunused-parm-3.C  -std=gnu++98
(test for excess errors)
...

Minimal version of Wunused-parm-3.C failure:
...
template 
int
fn7 (T ap)
{
  return __builtin_va_arg(ap, int);
}

int
fn8 (__builtin_va_list ap)
{
  return fn7<__builtin_va_list> (ap);
}
...

The test fails because there's an additional warning:
...
Wunused-parm-3.C: In function ‘int fn8(__va_list_tag*)’:
Wunused-parm-3.C:11:36: warning: ignoring attributes applied to ‘__va_list_tag’
after definition [-Wattributes]
   return fn7<__builtin_va_list> (ap);
...

Adding a main:
...
#ifdef MAIN
int
fn9 (int dummy, ...)
{
  __builtin_va_list ap;
  __builtin_va_start (ap, dummy);
  int res = fn8 (ap);
  __builtin_va_end (ap);
  return res;
}

int
main (void)
{
  int res = fn9 (0, 3);

  return !(res == 3);
}
#endif
...

shows that generated code is still ok:
...
$ g++ Wunused-parm-3.C -DMAIN && (./a.out ; echo $? )
Wunused-parm-3.C: In function ‘int fn8(__va_list_tag*)’:
Wunused-parm-3.C:11:36: warning: ignoring attributes applied to ‘__va_list_tag’
after definition [-Wattributes]
   return fn7<__builtin_va_list> (ap);
^
0
...

The warning is there because canonicalize_type_argument tries to build a copy
of va_list without the attribute (which it tries to do because the condition
arg == TYPE_CANONICAL (arg) no longer holds):