[Bug tree-optimization/83176] New: [8 Regression] [graphite] ICE in set_codegen_error, at graphite-isl-ast-to-gimple.c:206

[asolokha at gmx dot com]

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

Bug ID: 83176
   Summary: [8 Regression] [graphite] ICE in set_codegen_error, at
graphite-isl-ast-to-gimple.c:206
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

gcc-8.0.0-alpha20171126 snapshot (r255155) ICEs when compiling the following
snippet w/ -O2 (-O3, -Ofast) -floop-nest-optimize:

int wx, qi;

void
yj (int gw)
{
  int *ak = 

  while (wx != 0)
{
  int k2 = 
  int **xq = (int **)

 ja:
  *xq = 

  while (qi < 1)
{
  unsigned short int ey;

 be:
  for (ey = 0; ey < 251; ++ey)
{
  for (wx = 0; wx < 2; ++wx)
{
}

  *ak += 8555712;
  k2 += *ak;
}
  ++qi;
}
}

  gw = 1;
  if (gw != 0)
goto ja;
  else
goto be;
}

% gcc-8.0.0-alpha20171126 -O2 -floop-nest-optimize -w -c cpnhvog9.c 
during GIMPLE pass: graphite
cpnhvog9.c: In function 'yj':
cpnhvog9.c:4:1: internal compiler error: in set_codegen_error, at
graphite-isl-ast-to-gimple.c:206
 yj (int gw)
 ^~
0x7e3b40 translate_isl_ast_to_gimple::set_codegen_error()
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20171126/work/gcc-8-20171126/gcc/graphite-isl-ast-to-gimple.c:205
0x7e403c translate_isl_ast_to_gimple::set_codegen_error()
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20171126/work/gcc-8-20171126/gcc/tree.h:3216
0x7e403c translate_isl_ast_to_gimple::get_rename_from_scev(tree_node*,
gimple**, loop*, vec<tree_node*, va_heap, vl_ptr>)
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20171126/work/gcc-8-20171126/gcc/graphite-isl-ast-to-gimple.c:1074
0x7e4245
translate_isl_ast_to_gimple::graphite_copy_stmts_from_block(basic_block_def*,
basic_block_def*, vec<tree_node*, va_heap, vl_ptr>)
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20171126/work/gcc-8-20171126/gcc/graphite-isl-ast-to-gimple.c:1190
0x7e45e6
translate_isl_ast_to_gimple::copy_bb_and_scalar_dependences(basic_block_def*,
edge_def*, vec<tree_node*, va_heap, vl_ptr>)
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20171126/work/gcc-8-20171126/gcc/graphite-isl-ast-to-gimple.c:1239
0x13ee5e1
translate_isl_ast_to_gimple::translate_isl_ast_node_user(isl_ast_node*,
edge_def*, std::map<isl_id*, tree_node*, std::less<isl_id*>,
std::allocator<std::pair<isl_id* const, tree_node*> > >&)
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20171126/work/gcc-8-20171126/gcc/graphite-isl-ast-to-gimple.c:802
0x13ee7b6 translate_isl_ast_to_gimple::translate_isl_ast_for_loop(loop*,
isl_ast_node*, edge_def*, tree_node*, tree_node*, tree_node*, std::map<isl_id*,
tree_node*, std::less<isl_id*>, std::allocator<std::pair<isl_id* const,
tree_node*> > >&)
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20171126/work/gcc-8-20171126/gcc/graphite-isl-ast-to-gimple.c:621
0x13ee9da translate_isl_ast_to_gimple::translate_isl_ast_node_for(loop*,
isl_ast_node*, edge_def*, std::map<isl_id*, tree_node*, std::less<isl_id*>,
std::allocator<std::pair<isl_id* const, tree_node*> > >&)
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20171126/work/gcc-8-20171126/gcc/graphite-isl-ast-to-gimple.c:723
0x13ee7b6 translate_isl_ast_to_gimple::translate_isl_ast_for_loop(loop*,
isl_ast_node*, edge_def*, tree_node*, tree_node*, tree_node*, std::map<isl_id*,
tree_node*, std::less<isl_id*>, std::allocator<std::pair<isl_id* const,
tree_node*> > >&)
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20171126/work/gcc-8-20171126/gcc/graphite-isl-ast-to-gimple.c:621
0x13ee9da translate_isl_ast_to_gimple::translate_isl_ast_node_for(loop*,
isl_ast_node*, edge_def*, std::map<isl_id*, tree_node*, std::less<isl_id*>,
std::allocator<std::pair<isl_id* const, tree_node*> > >&)
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20171126/work/gcc-8-20171126/gcc/graphite-isl-ast-to-gimple.c:723
0x13eeaa4 translate_isl_ast_to_gimple::translate_isl_ast_node_block(loop*,
isl_ast_node*, edge_def*, std::map<isl_id*, tree_node*, std::less<isl_id*>,
std::allocator<std::pair<isl_id* const, tree_node*> > >&)
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20171126/work/gcc-8-20171126/gcc/graphite-isl-ast-to-gimple.c:831
0x13eee9c graphite_regenerate_ast_isl(scop*)
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20171126/work/gcc-8-20171126/gcc/graphite-isl-ast-to-gimple.c:1474
0x13ebb23 graphite_transform_loops()
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20171126/work/gcc-8-20171126/gcc/graphite.c:384
0x13ec4c0 graphite_transforms

[Bug libfortran/83168] FAIL: gfortran.dg/fmt_f0_2.f90 with a sanitized libgfortran

[dominiq at lps dot ens.fr]

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

--- Comment #4 from Dominique d'Humieres  ---
> Try this fix:
> ...

It works! Thanks.

[Bug fortran/83064] DO CONCURRENT inconsistent results

[cfztol at hotmail dot com]

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

--- Comment #14 from Christian Felter  ---
I looked into the working draft of Fortran 2015 (J3/16-007r1). In Note 12.52 it
says:

The above constraints are designed to guarantee that a pure procedure is free
from side effects (modifications of data visible outside the procedure), which
means that it is safe to reference it in constructs such as DO CONCURRENT and
FORALL, where there is no explicit order of evaluation. <...more text
skipped...>

From that I believe that the test program is valid Fortran.

[Bug middle-end/83175] compiler optimizing the code corresponding to double precision operations

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||wrong-code
 Target||Powerpc*-*-*
 Status|UNCONFIRMED |RESOLVED
  Component|c   |middle-end
 Resolution|--- |INVALID

--- Comment #4 from Andrew Pinski  ---
I did not notice this before but you either need to use volatile or a memory
barrier between the writes of unlockAddr1_f64[0].


Something like:
volatile double *unlockAddr1_f64 = (volatile double*)
thisVars(vol)->unlockAddr1;
volatile double *unlockAddr2_f64 = (volatile double*)
thisVars(vol)->unlockAddr2;
cmd.word32[0] = ((command<<16) | command);
cmd.word32[1] = cmd.word32[0];
unlockAddr1_f64[0] = unlock1_cmd.fword64;
unlockAddr2_f64[0] = unlock2_cmd.fword64;
unlockAddr1_f64[0] = cmd.fword64;


Or something like:

unlockAddr1_f64 = (double*) thisVars(vol)->unlockAddr1;
unlockAddr2_f64 = (double*) thisVars(vol)->unlockAddr2;
cmd.word32[0] = ((command<<16) | command);
cmd.word32[1] = cmd.word32[0];
unlockAddr1_f64[0] = unlock1_cmd.fword64;
asm("":::"memory");
unlockAddr2_f64[0] = unlock2_cmd.fword64;
asm("":::"memory");
unlockAddr1_f64[0] = cmd.fword64;

[Bug c/83175] compiler optimizing the code corresponding to double precision operations

[sbansal at ciena dot com]

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

--- Comment #3 from Sumit  ---
(In reply to Andrew Pinski from comment #1)
> Try -fno-strict-aliasing as it looks like the code is violating C/C++
> aliasing rules.

Hi Andrew,

It does not have any effect. Still the same problem.

[Bug c/83175] compiler optimizing the code corresponding to double precision operations

[sbansal at ciena dot com]

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

--- Comment #2 from Sumit  ---
(In reply to Andrew Pinski from comment #1)
> Try -fno-strict-aliasing as it looks like the code is violating C/C++
> aliasing rules.

Thanks for the quick response. I am trying that and will let you know.

[Bug target/81616] Update -mtune=generic for the current Intel and AMD processors

[andrewm.roberts at sky dot com]

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

--- Comment #12 from Andrew Roberts  ---
Ok I've tried again with this weeks snapshot:

gcc version 8.0.0 20171126 (experimental) (GCC) 

Taking combination of -march and -mtune which works well on Ryzen:

/usr/local/gcc/bin/gcc -march=core-avx-i -mtune=nocona -O3 matrix.c -o matrix
./matrix
mult took 131153 clocks

Then switching to -mtune=znver1

/usr/local/gcc/bin/gcc -march=core-avx-i -mtune=znver1 -O3 matrix.c -o matrix
./matrix
 mult took 231309 clocks

Then looking at the differences in the -Q --help=target output for these two
and eliminating each difference at a time, I found that:

gcc -march=core-avx-i -mtune=znver1 -mprefer-vector-width=none -O3 matrix.c -o
matrix
[aroberts@ryzen share]$ ./matrix
mult took 132295 clocks

The default for znver1 is: -mprefer-vector-width=128

So is this option still helping with the latest microcode? Not in this case at
least.

cat /proc/cpuinfo : 
processor   : 0
vendor_id   : AuthenticAMD
cpu family  : 23
model   : 1
model name  : AMD Ryzen 7 1700 Eight-Core Processor
stepping: 1
microcode   : 0x8001129

with -march=znver1 -mtune=znver1
with default of -mprefer-vector-width=128
mult took 386291 clocks

with -march=znver1 -mtune=znver1 -mprefer-vector-width=none
mult took 201455 clocks

[Bug c/83175] compiler optimizing the code corresponding to double precision operations

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
Try -fno-strict-aliasing as it looks like the code is violating C/C++ aliasing
rules.

[Bug c/83175] New: compiler optimizing the code corresponding to double precision operations

[sbansal at ciena dot com]

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

Bug ID: 83175
   Summary: compiler optimizing the code corresponding to double
precision operations
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sbansal at ciena dot com
  Target Milestone: ---

I am migrating my tool chain from 3.4.5 to 4.8.1. 

Migration to 4.8.1 is working great till now but the only problem I am recently
encountering is about code getting optimized when some "double" operations are
done.

Source code :
=
553   unlockAddr1_f64 = (double*) thisVars(vol)->unlockAddr1;
554   unlockAddr2_f64 = (double*) thisVars(vol)->unlockAddr2;
555   cmd.word32[0] = ((command<<16) | command);
556   cmd.word32[1] = cmd.word32[0];
557   unlockAddr1_f64[0] = unlock1_cmd.fword64;
558   unlockAddr2_f64[0] = unlock2_cmd.fword64;
559   unlockAddr1_f64[0] = cmd.fword64;

Corresponding assembly with 3.4.5 (working good)

/vobs/equinox_ne_bsp/kernel/sources/drivers/ffs/amd16x4mtdome.c:553
  13adb0:   81 23 00 18 lwz r9,24(r3)
  13adb4:   81 69 00 00 lwz r11,0(r9)
/vobs/equinox_ne_bsp/kernel/sources/drivers/ffs/amd16x4mtdome.c:554
  13adb8:   81 49 00 04 lwz r10,4(r9)
/vobs/equinox_ne_bsp/kernel/sources/drivers/ffs/amd16x4mtdome.c:555
  13adbc:   54 a0 80 1e rlwinm  r0,r5,16,0,15
  13adc0:   7c 00 2b 78 or  r0,r0,r5
  13adc4:   7c 07 03 78 mr  r7,r0
/vobs/equinox_ne_bsp/kernel/sources/drivers/ffs/amd16x4mtdome.c:556
  13adc8:   7c 08 03 78 mr  r8,r0
/vobs/equinox_ne_bsp/kernel/sources/drivers/ffs/amd16x4mtdome.c:557
  13adcc:   3d 20 00 67 lis r9,103
  13add0:   c8 09 7d 08 lfd f0,32008(r9)
  13add4:   d8 0b 00 00 stfdf0,0(r11)
/vobs/equinox_ne_bsp/kernel/sources/drivers/ffs/amd16x4mtdome.c:558
  13add8:   3d 20 00 67 lis r9,103
  13addc:   c8 09 7d 10 lfd f0,32016(r9)
  13ade0:   d8 0a 00 00 stfdf0,0(r10)
/vobs/equinox_ne_bsp/kernel/sources/drivers/ffs/amd16x4mtdome.c:559
  13ade4:   90 e1 00 08 stw r7,8(r1)
  13ade8:   91 01 00 0c stw r8,12(r1)
  13adec:   c9 a1 00 08 lfd f13,8(r1)
  13adf0:   d9 ab 00 00 stfdf13,0(r11)


Corresponding assembly with 4.8.1 (not working well) :

/vobs/equinox_ne_bsp/kernel/sources/drivers/ffs/amd16x4mtdome.c:554
  138e04:   81 0a 00 04 lwz r8,4(r10)
/vobs/equinox_ne_bsp/kernel/sources/drivers/ffs/amd16x4mtdome.c:555
  138e08:   54 aa 80 1e rlwinm  r10,r5,16,0,15
  138e0c:   7d 45 2b 78 or  r5,r10,r5
/vobs/equinox_ne_bsp/kernel/sources/drivers/ffs/amd16x4mtdome.c:557
  138e10:   3c e0 00 66 lis r7,102
/vobs/equinox_ne_bsp/kernel/sources/drivers/ffs/amd16x4mtdome.c:558
  138e14:   c8 07 01 c8 lfd f0,456(r7)
  138e18:   d8 08 00 00 stfdf0,0(r8)
/vobs/equinox_ne_bsp/kernel/sources/drivers/ffs/amd16x4mtdome.c:559
  138e1c:   90 a9 00 00 stw r5,0(r9)
  138e20:   90 a9 00 04 stw r5,4(r9)


The problem I see is that, no assembly instructions (lfd, stfd) are generated
corresponding to line 557 & 559. It seems compiler is doing some optimization.

Surprisingly, If I add some printf or debug code after line 558, these
instructions are getting generated and code works well.

I know 4.8.1 is no longer supported by GCC, but I would appreciate if you could
give some directions which I can look. Probably some flags etc which I can set.

let me know if you need more information.

Thanks.
Sumit

[Bug rtl-optimization/82488] UBSAN in gcc/expr.c:4098:17: runtime error: signed integer overflow: 0 - -9223372036854775808 cannot be represented in type 'long int'

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

   Target Milestone|--- |8.0

[Bug rtl-optimization/82488] UBSAN in gcc/expr.c:4098:17: runtime error: signed integer overflow: 0 - -9223372036854775808 cannot be represented in type 'long int'

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

--- Comment #4 from Markus Trippelsdorf  ---
Fixed.

[Bug rtl-optimization/82488] UBSAN in gcc/expr.c:4098:17: runtime error: signed integer overflow: 0 - -9223372036854775808 cannot be represented in type 'long int'

[trippels at gcc dot gnu.org]

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

--- Comment #3 from Markus Trippelsdorf  ---
Author: trippels
Date: Mon Nov 27 05:20:43 2017
New Revision: 255159

URL: https://gcc.gnu.org/viewcvs?rev=255159=gcc=rev
Log:
Fix PR82488 - signed integer overflow in expr.c

bootstrap-ubsan shows:
 gcc/expr.c:4103:17: runtime error: signed integer overflow: 0 -
-9223372036854775808 cannot be represented in type 'long int'

Fix by handling the saw_unknown case earlier.

PR rtl-optimization/82488
* expr.c (fixup_args_size_notes): Avoid signed integer overflow.

diff --git a/gcc/expr.c b/gcc/expr.c
index ee07de5aaa44..e9d8555c9452 100644
--- a/gcc/expr.c
+++ b/gcc/expr.c
@@ -4100,10 +4100,13 @@ fixup_args_size_notes (rtx_insn *prev, rtx_insn *last,
int end_args_size)
   if (STACK_GROWS_DOWNWARD)
this_delta = -(unsigned HOST_WIDE_INT) this_delta;

-  args_size -= this_delta;
+  if (saw_unknown)
+   args_size = INT_MIN;
+  else
+   args_size -= this_delta;
 }

-  return saw_unknown ? INT_MIN : args_size;
+  return args_size;
 }

 #ifdef PUSH_ROUNDING
--
Markus

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

[Bug c/83174] New: -Wvla-larger-than reports wrong VLA size in some cases

[hao.hou at utah dot edu]

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

Bug ID: 83174
   Summary: -Wvla-larger-than reports wrong VLA size in some cases
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hao.hou at utah dot edu
  Target Milestone: ---

Created attachment 42725
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42725=edit
The preprocessed source code repoduce the bug

There's some cases that -Wvla-lager-than only warns mistakenly only when the
strlen result is used as allocation size when -O2 or higher is turned on

Example code: 
extern void f(void* ptr);
extern char* s;
void good(void)
{
unsigned long long l = __builtin_strlen(s);
if(l < 4)
{
char b[l&2];
f(b);
}
}

void bad(void)
{
unsigned long long l = __builtin_strlen(s);
if(l < 4)
{
char b[l&3];
f(b);
}
}

Compiler arguments: 
$ gcc-7  -Wvla-larger-than=0x100 -O3 -S -c db.c
db.c: In function ‘bad’:
db.c:18:8: warning: argument to variable-length array may be too large
[-Wvla-larger-than=]
   char b[l&3];
^
db.c:18:8: note: limit is 16777216 bytes, but argument may be as large as
9223372036854775806

It only warns the function uses l&3 as the VLA size. 

Compiler Version:
Using built-in specs.
COLLECT_GCC=gcc-7
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/7/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
7.1.0-10ubuntu1~16.04.york0'
--with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr
--with-gcc-major-version-only --program-suffix=-7
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib
--with-target-system-zlib --enable-objc-gc=auto --enable-multiarch
--disable-werror --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none --without-cuda-driver
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 7.1.0 (Ubuntu 7.1.0-10ubuntu1~16.04.york0)

[Bug preprocessor/83173] New: C preprocessor generates incorrect linemarkers

[mgulick at mathworks dot com]

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

Bug ID: 83173
   Summary: C preprocessor generates incorrect linemarkers
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: preprocessor
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mgulick at mathworks dot com
  Target Milestone: ---

Created attachment 42724
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42724=edit
invalid linemarker reproduction source code

GCC is generating incorrect line markers when processing source files with a
large number of includes (e.g. where the internal line map's source location is
greater than LINE_MAP_MAX_LOCATION_WITH_COLS.  This results in warnings from
gcc when it compiles this previously preprocessed output.  It also results in
gcc generating incorrect line mappings in the debug symbols, as well as
producing compiler warnings and errors that are associated with the wrong file
name and line number.

This invalid line marker is generated for include files that have a '#include'
as the last line in the file.  Simply adding an additional newline after the
last include will eliminate this issue.

This issue only occurs when the preprocessor is run as a separate phase, as
when using -save-temps, -no-integrated-cpp, or -E (as is used by distcc).

See also: https://gcc.gnu.org/ml/gcc-help/2017-11/msg00073.html

I have tested gcc 6.3, 7.2, as well as the latest git master (as of yesterday).
 These all exhibit this bug.  gcc 5.4 does *not* exhibit this bug.

The attached reproducer is able to reproduce this issue on a trivial source
file by using a gcc plugin that artificially increases the line map's starting
location before the preprocessor runs.  See README.txt included in the
reproduction tarball for instructions on running the reproducer.

[mgulick@mgulick2-deb9-64:/local-ssd/mgulick/src/gcc/linemarker_repro] ...
$ make
/local-ssd/mgulick/src/gcc/git/debug/gcc/xgcc -B
/local-ssd/mgulick/src/gcc/git/debug/gcc -E repro.c -o repro.i
-fplugin=./location_overflow_plugin.so
-fplugin-arg-location_overflow_plugin-value=0x6000
setting line_table location offset: 1610612736 was (32)
/local-ssd/mgulick/src/gcc/git/debug/gcc/xgcc -B
/local-ssd/mgulick/src/gcc/git/debug/gcc -c repro.i -o repro.o -Werror
In file included from repro_1.h:3,
 from repro.c:1:
repro_2.h:2:16: error: file "repro.h" linemarker ignored due to incorrect
nesting [-Werror]

^
repro_2.h:3:16: error: file "repro.c" linemarker ignored due to incorrect
nesting [-Werror]
 #define REPRO_2_H
^
cc1: all warnings being treated as errors
Makefile:45: recipe for target 'test_compile' failed
make: *** [test_compile] Error 1

[mgulick@mgulick2-deb9-64:/local-ssd/mgulick/src/gcc/linemarker_repro] ...
$ cat repro.i
# 1 "repro.c"
# 1 ""
# 1 ""
# 1 "/usr/include/stdc-predef.h" 1 3 4
# 1 "" 2
# 1 "repro.c"
# 1 "repro.h" 1
# 1 "repro_1.h" 1

# 2 "repro.h" 2
# 3 "repro_1.h"
# 1 "repro_2.h" 1

# 2 "repro.h" 2
# 2 "repro.c" 2

The line "# 3 repro_1.h" is incorrect and should not appear.

[Bug c/83172] New: -Wstack-size= doesn't detect the correct stack size with VLA or alloca

[hao.hou at utah dot edu]

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

Bug ID: 83172
   Summary: -Wstack-size= doesn't detect the correct stack size
with VLA or alloca
   Product: gcc
   Version: 4.8.5
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hao.hou at utah dot edu
  Target Milestone: ---

Created attachment 42723
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42723=edit
The preprocessed source code repoduce the bug

The -Wstack-usage= doesn't deduce the correct stack size and reports an
unbounded stack size in the following case:
1. The function uses a variable length array
2. The function uses alloca

Even with alloca(constant) or __builtin_unreachable hints the VLA size,
compiler still mark the max stack size unbounded. 

Another related option -Wvla-larger-than= does inferred the maximum VLA size
from the __builtin_unreachable hints. 

The expected behavior should be -Wstack-usage= also follows the hint, at least,
for the alloca(constant) case, it should realize the stack size could not be
unbounded.

GCC Version:
Using built-in specs.
COLLECT_GCC=gcc-7
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/7/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
7.1.0-10ubuntu1~16.04.york0'
--with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr
--with-gcc-major-version-only --program-suffix=-7
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib
--with-target-system-zlib --enable-objc-gc=auto --enable-multiarch
--disable-werror --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none --without-cuda-driver
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 7.1.0 (Ubuntu 7.1.0-10ubuntu1~16.04.york0) 

And the preprocessed file that repo this bug is attached. 

The command used to repo the bug and it's output:

$ gcc-7 -save-temps -Wvla-larger-than=128 -Wstack-usage=102400 -O3 -c t.c 
t.c: In function ‘stack_usage_only’:
t.c:21:5: warning: stack usage might be unbounded [-Wstack-usage=]
 int stack_usage_only(unsigned x)
 ^~~~
t.c: In function ‘alloca_fails_even_with_const’:
t.c:30:5: warning: stack usage might be unbounded [-Wstack-usage=]
 int alloca_fails_even_with_const()
 ^~~~


Expected:
Compiles without any warning.

[Bug middle-end/83169] Optimizer doesn't correctly handle NRVO if -fno-inline-small-functions or function uninlinable

[ibuclaw at gdcproject dot org]

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

--- Comment #6 from Iain Buclaw  ---
(In reply to Andrew Pinski from comment #5)
> (In reply to Iain Buclaw from comment #4)
> > The generated code sets the address of the constructed variable the same the
> > as the return address, yet the condition is assumed false by the optimizer.
> 
> data is not taken as an address except in the equals so it cannot be the
> same as the global variable pointer.  And using ptest after data goes out of
> scope in footest is undefined code.
> 
> So the difference is just based on undefined code.

So setting CALL_EXPR_RETURN_SLOT_OPT is no guarantee that the return slot is
the address of 'data'?  At least from the optimizers POV?

[Bug middle-end/83169] Optimizer doesn't correctly handle NRVO if -fno-inline-small-functions or function uninlinable

[pinskia at gcc dot gnu.org]

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

--- Comment #5 from Andrew Pinski  ---
(In reply to Iain Buclaw from comment #4)
> The generated code sets the address of the constructed variable the same the
> as the return address, yet the condition is assumed false by the optimizer.

data is not taken as an address except in the equals so it cannot be the same
as the global variable pointer.  And using ptest after data goes out of scope
in footest is undefined code.

So the difference is just based on undefined code.

[Bug middle-end/83169] Optimizer doesn't correctly handle NRVO if -fno-inline-small-functions or function uninlinable

[ibuclaw at gdcproject dot org]

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

--- Comment #4 from Iain Buclaw  ---
(In reply to Jakub Jelinek from comment #3)
> NRVO in the middle-end is solely an optimization.  If some FE requires
> something above that, then it needs to do it itself, C++ is an example of a
> FE that does it.

If that's the case, then why the different runtime behaviours?

The generated code sets the address of the constructed variable the same the as
the return address, yet the condition is assumed false by the optimizer.

[Bug tree-optimization/83171] std::bitset::count not inlining __popcountdi2

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug tree-optimization/83171] std::bitset::count not inlining __popcountdi2

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Target|x86_64-linux-gnu|
 Status|UNCONFIRMED |NEW
   Keywords||missed-optimization
   Last reconfirmed||2017-11-26
  Component|c++ |tree-optimization
   Host|x86_64-linux-gnu|
 Ever confirmed|0   |1
  Build|x86_64-linux-gnu|

--- Comment #1 from Andrew Pinski  ---
Works for me with aarch64:
_Z3fooj:
.LFB1136:
.cfi_startproc
and x0, x0, 255
fmovd0, x0
cnt v0.8b, v0.8b
addvb0, v0.8b
umovw0, v0.b[0]
and x0, x0, 255
ret


And works for me with -march=native:
_Z3fooj:
.LFB1162:
.cfi_startproc
movzbl  %dil, %eax
popcntq %rax, %rax
ret

Basically the following is not being optimized:
  int _3;
  long unsigned int _4;
  long long unsigned int _5;
  unsigned int _6;

   [100.00%]:
  _6 = value_1(D) & 255;
  _5 = (long long unsigned int) _6;
  _3 = __builtin_popcountl (_5);
  _4 = (long unsigned int) _3;

To just:

  _6 = value_1(D) & 255;
  _3 = __builtin_popcount (_6);
  _4 = (long unsigned int) _3;

[Bug libfortran/81985] several sanitizer undefined runtime errors in sanitized libgfortran

[dominiq at lps dot ens.fr]

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

--- Comment #2 from Dominique d'Humieres  ---
Along the same line mvbits_2.f90 gives

../../../p_work/libgfortran/intrinsics/mvbits.c:48:30: runtime error: left
shift of negative value -1
../../../p_work/libgfortran/intrinsics/mvbits.c:48:30: runtime error: left
shift of negative value -1

[Bug c++/83171] New: std::bitset::count not inlining __popcountdi2

[lectem at gmail dot com]

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

Bug ID: 83171
   Summary: std::bitset::count not inlining __popcountdi2
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lectem at gmail dot com
  Target Milestone: ---

Even if the size of the std::bitset is smaller than a long long, the compiler
still emits a call to __popcountdi2 to count the number of bits set to 1.

This is unnecessary for example if the size of the bitset is 8. I believe the
issue lies with the fact that __popcountdi2 is not inlined/optimized, even when
using -O3.

Clang (-O2, using libstdc++) and MSVC(/O2, Visual 2017) seem to handle this
correctly. 
Here is a link to the compiler explorer test :

https://godbolt.org/g/QTWgdb

The code used in the test :

//--
#include 
#include 

size_t foo(uint32_t value)
{
  std::bitset<8> bset = value;
  return bset.count();
}
//--

gcc -v
Target: x86_64-linux-gnu
Configured with: ../gcc-7.2.0/configure --prefix /root/staging
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
--disable-multilib --disable-bootstrap --disable-multiarch --with-arch-32=i586
--enable-clocale=gnu --enable-languages=c,c++,go,fortran --enable-ld=yes
--enable-gold=yes --enable-libstdcxx-debug --enable-libstdcxx-time=yes
--enable-linker-build-id --enable-lto --enable-plugins --enable-threads=posix
--with-pkgversion=GCC-Explorer-Build
Thread model: posix
gcc version 7.2.0 (GCC-Explorer-Build)

[Bug c++/83170] ice in verify_use with -O3

[dcb314 at hotmail dot com]

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

--- Comment #1 from David Binderman  ---

Reduced C++ code seems to be:

int a;
enum bk { bm };
enum bn { bo };
enum { bp, bq, br, bs };
class d {
public:
  d();
  char b;
  void bv(char, bn);
  char bw[];
};
d::d() { bv(b, bo); }
short c;
void d::bv(char e, bn f) {
  bw[bp] = e;
  bw[bq] = f;
  bw[br] = c >> 8;
  bw[bs] = c;
}
class g {
  bool cb();
  long cc(bk, const char *, unsigned, char *, unsigned, int, int *);
  void cd(d *, int);
};
bool g::cb() {
  int *cg;
  char ch[1];
  cc(bm, nullptr, 0, ch, sizeof(ch), a, cg);
}
long g::cc(bk e, const char *, unsigned, char *, unsigned, int h, int *) {
  d cl;
  cl.bv(e, bo);
  cd(, h);
}

[Bug c++/83170] New: ice in verify_use with -O3

[dcb314 at hotmail dot com]

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

Bug ID: 83170
   Summary: ice in verify_use with -O3
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

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

The attached C++ code, with recent gcc trunk, does this:

during GIMPLE pass: store-merging
bug399.cc: In member function ‘virtual ssize_t udp::UdpTransport::Read(void*,
si
ze_t)’:
bug399.cc:20661:9: internal compiler error: Segmentation fault
 ssize_t UdpTransport::Read(void* data, size_t length) {
 ^~~~
0xfe790f crash_signal
../../trunk/gcc/toplev.c:325
0x129879c verify_use
../../trunk/gcc/tree-ssa.c:864
0x129879c verify_ssa(bool, bool)
../../trunk/gcc/tree-ssa.c:1141
0xe65907 execute_function_todo
../../trunk/gcc/passes.c:2001

The bug seems to occur between revisions 254924 and 255154.
I'll have a go at reducing the code.

[Bug middle-end/83169] Optimizer doesn't correctly handle NRVO if -fno-inline-small-functions or function uninlinable

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #3 from Jakub Jelinek  ---
NRVO in the middle-end is solely an optimization.  If some FE requires
something above that, then it needs to do it itself, C++ is an example of a FE
that does it.

[Bug tree-optimization/38153] ICE in testcase when compiled with -ftree-parallelize-loops

[reichelt at gcc dot gnu.org]

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

Volker Reichelt  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||jakub at redhat dot com
  Known to work||5.5.0, 6.4.1, 7.2.1, 8.0
 Resolution|--- |FIXED
   Target Milestone|--- |5.5
  Known to fail|6.0 |5.4.0, 6.1.0, 6.4.0, 7.1.0,
   ||7.2.0

--- Comment #6 from Volker Reichelt  ---
This was fixed with Jakub's patch for PR81867 which was applied to trunk and
the GCC 7, GCC 6, and GCC 5 branches:

https://gcc.gnu.org/ml/gcc-cvs/2017-08/msg00266.html

Author: jakub
Date: Thu Aug 10 00:33:20 2017
New Revision: 251019

URL: https://gcc.gnu.org/viewcvs?rev=251019=gcc=rev
Log:
PR c/81687
* omp-low.c (omp_copy_decl): Don't remap FORCED_LABEL or DECL_NONLOCAL
LABEL_DECLs.
* tree-cfg.c (move_stmt_op): Don't adjust DECL_CONTEXT of FORCED_LABEL
or DECL_NONLOCAL labels.
(move_stmt_r) : Adjust DECL_CONTEXT of FORCED_LABEL
or DECL_NONLOCAL labels here.

* testsuite/libgomp.c/pr81687-1.c: New test.
* testsuite/libgomp.c/pr81687-2.c: New test.

Added:
trunk/libgomp/testsuite/libgomp.c/pr81687-1.c
trunk/libgomp/testsuite/libgomp.c/pr81687-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/omp-low.c
trunk/gcc/tree-cfg.c
trunk/libgomp/ChangeLog


Jakub, do you want to add the testcase from comment #1 to the testsuite (which
fails more reliably than the original testcase or the testcase from comment #4 
at least on x86_64-pc-linux-gnu). Or do you think the testcases you added are
sufficient?

[Bug middle-end/83169] Optimizer doesn't correctly handle NRVO if -fno-inline-small-functions or function uninlinable

[ibuclaw at gdcproject dot org]

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

--- Comment #2 from Iain Buclaw  ---
A little bit of consistency?

This was found in another language where NRVO is consistency expected to
happen.  Having a quick look at bug 58055, seems to suggest that front-end
should generate better codegen if the optimizer doesn't understand the intent.

I wonder what Ada does, but I'd like to avoid doing something complex such as
generating a hidden parameter to store the result.

e.g:
---
Stest footest()  // fn type is really: void(Stest *hidden)
{
Stest data = {};  // *hidden = {};
ptest = // ptest = hidden;
return data;  // return;
}

int main()
{
const Stest data = footest();  // Stest data;
   // footest ();
assert(ptest == );
return 0;
}
---

[Bug middle-end/83169] Optimizer doesn't correctly handle NRVO if -fno-inline-small-functions or function uninlinable

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
This code is all undefined so what do you expect?

[Bug middle-end/83169] New: Optimizer doesn't correctly handle NRVO if -fno-inline-small-functions or function uninlinable

[ibuclaw at gdcproject dot org]

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

Bug ID: 83169
   Summary: Optimizer doesn't correctly handle NRVO if
-fno-inline-small-functions or function uninlinable
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ibuclaw at gdcproject dot org
  Target Milestone: ---

Minimal test.
---
#include 

struct Stest
{
  int foo[5];  // Triggers NRVO return on x86_64.
};

void* ptest;

Stest footest()
{
Stest data = {};  //  = {};
ptest = // ptest = &;
return data;  // return 
}

int main()
{
const Stest data = footest();  // data = footest ();
   // [return slot optimization]
assert(ptest == );
return 0;
}
---

And permutation of compile-time switches, "PASSES" indicates that runtime exits
without assertion failure.
---
* g++ -O0 (PASSES)
* g++ -O1 (FAILS)
* g++ -O1 -finline-small-functions(PASSES)
* g++ -O2 (PASSES)
* g++ -O2 -fno-inline-small-functions (FAILS)
* g++ -O2 -fPIC   (FAILS)


Looking at the optimized tree dump, for -O2 the compiler determines (I think
correctly) that ptest and data share the same address, and so removes the
assert.
---
main ()
{
  const struct Stest data;

   [local count: 1]:
  ptest = 
  data ={v} {CLOBBER};
  return 0;

}
---

However for -O2 -fPIC:
---
main ()
{
  static const char __PRETTY_FUNCTION__[11] = "int main()";
  const struct Stest data;

   [local count: 1]:
  data = footest (); [return slot optimization]
  __assert_fail ("ptest == ", "test.cc", 20, &__PRETTY_FUNCTION__);

}
---

And for -O1:
---
main ()
{
  static const char __PRETTY_FUNCTION__[11] = "int main()";
  const struct Stest data;

   [local count: 1]:
  data = {};
  ptest = 
  __assert_fail ("ptest == ", "test.cc", 20, &__PRETTY_FUNCTION__);

}
---

[Bug libfortran/83168] FAIL: gfortran.dg/fmt_f0_2.f90 with a sanitized libgfortran

[jvdelisle at gcc dot gnu.org]

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

--- Comment #3 from Jerry DeLisle  ---
Thanks,

Try this fix:

diff --git a/libgfortran/io/write.c b/libgfortran/io/write.c
index c9aad150..d26358c0 100644
--- a/libgfortran/io/write.c
+++ b/libgfortran/io/write.c
@@ -1552,7 +1552,7 @@ select_string (st_parameter_dt *dtp, const fnode *f, char
*buf, size_t *size,
   int kind)
 {
   char *result;
-  *size = size_from_kind (dtp, f, kind) + f->u.real.d;
+  *size = size_from_kind (dtp, f, kind) + f->u.real.d + 1;
   if (*size > BUF_STACK_SZ)
  result = xmalloc (*size);
   else

[Bug libfortran/83168] FAIL: gfortran.dg/fmt_f0_2.f90 with a sanitized libgfortran

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

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

--- Comment #2 from Andreas Schwab  ---
The first byte just outside the valid range.

[Bug libfortran/83168] FAIL: gfortran.dg/fmt_f0_2.f90 with a sanitized libgfortran

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-11-26
 CC||jvdelisle at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |jvdelisle at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jerry DeLisle  ---
I will look into this. What does this mean:

is located 0 bytes to the right of 311-byte region
[0x612001c0,0x612002f7)

0 bytes?

[Bug libfortran/83168] New: FAIL: gfortran.dg/fmt_f0_2.f90 with a sanitized libgfortran

[dominiq at lps dot ens.fr]

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

Bug ID: 83168
   Summary: FAIL: gfortran.dg/fmt_f0_2.f90 with a sanitized
libgfortran
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libfortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dominiq at lps dot ens.fr
  Target Milestone: ---

The test FAIL: gfortran.dg/fmt_f0_2.f90 fails with a sanitized libgfortran.
Compiling the reduced test

character(1) :: str
  write(str, "(f0.0)") -huge(real(1.0,kind=8))
  print *, len(trim(str))
end

gives

==61211==ERROR: AddressSanitizer: heap-buffer-overflow on address
0x612002f7 at pc 0x00010fb72c53 bp 0x7ffee0ba8e90 sp 0x7ffee0ba8e88
WRITE of size 1 at 0x612002f7 thread T0
#0 0x10fb72c52 in build_float_string write_float.def:665
#1 0x10fb73ff0 in get_float_string write_float.def:1068
#2 0x10fb76bd1 in write_float_0 write.c:1596
#3 0x10fb791c9 in _gfortrani_write_f write.c:1623
#4 0x10fb47d28 in formatted_transfer_scalar_write transfer.c:2041
#5 0x10fb4aae9 in formatted_transfer transfer.c:2279
#6 0x10fb3366e in _gfortran_transfer_real transfer.c:2310
#7 0x10fb336a3 in _gfortran_transfer_real_write transfer.c:2316
#8 0x10f053d9e in MAIN__ (a.out:x86_64+0x10d9e)
#9 0x10f053e98 in main (a.out:x86_64+0x10e98)
#10 0x7fff59553144 in start (libdyld.dylib:x86_64+0x1144)

0x612002f7 is located 0 bytes to the right of 311-byte region
[0x612001c0,0x612002f7)
allocated by thread T0 here:
#0 0x11181de8d in wrap_malloc sanitizer_malloc_mac.inc:135
#1 0x10f05a6e7 in _gfortrani_xmalloc memory.c:42
#2 0x10fb6b522 in select_string write.c:1557
#3 0x10fb76b46 in write_float_0 write.c:1592
#4 0x10fb791c9 in _gfortrani_write_f write.c:1623
#5 0x10fb47d28 in formatted_transfer_scalar_write transfer.c:2041
#6 0x10fb4aae9 in formatted_transfer transfer.c:2279
#7 0x10fb3366e in _gfortran_transfer_real transfer.c:2310
#8 0x10fb336a3 in _gfortran_transfer_real_write transfer.c:2316
#9 0x10f053d9e in MAIN__ (a.out:x86_64+0x10d9e)
#10 0x10f053e98 in main (a.out:x86_64+0x10e98)
#11 0x7fff59553144 in start (libdyld.dylib:x86_64+0x1144)

SUMMARY: AddressSanitizer: heap-buffer-overflow write_float.def:665 in
build_float_string
Shadow bytes around the buggy address:
  0x1c24: fa fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00
  0x1c240010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1c240020: 00 00 00 00 00 00 00 00 00 00 fa fa fa fa fa fa
  0x1c240030: fa fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00
  0x1c240040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x1c240050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00[07]fa
  0x1c240060: fa fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00
  0x1c240070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1c240080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 fa
  0x1c240090: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x1c2400a0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:   00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:   fa
  Freed heap region:   fd
  Stack left redzone:  f1
  Stack mid redzone:   f2
  Stack right redzone: f3
  Stack after return:  f5
  Stack use after scope:   f8
  Global redzone:  f9
  Global init order:   f6
  Poisoned by user:f7
  Container overflow:  fc
  Array cookie:ac
  Intra object redzone:bb
  ASan internal:   fe
  Left alloca redzone: ca
  Right alloca redzone:cb
==61211==ABORTING

The result is the same for the KIND=10 and KIND=16 variants.

[Bug fortran/83154] ICE: associate and coarrays

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 CC||pault at gcc dot gnu.org

--- Comment #2 from Dominique d'Humieres  ---
The change occurred between revisions r252781 (2017-09-15, errors) and r253041
+ one patch (2017-09-20, ICE), likely r253077.

[Bug fortran/83076] [8 Regression] ICE in gfc_deallocate_scalar_with_status, at fortran/trans.c:1598

[dominiq at lps dot ens.fr]

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

--- Comment #5 from Dominique d'Humieres  ---
> Hence, I would say that it is a pre-existing problem that has been exposed
> by the fix for r254427 and is not really a regression.

Still a regression [78 Regression], likely caused by r243021.

[Bug fortran/83076] [8 Regression] ICE in gfc_deallocate_scalar_with_status, at fortran/trans.c:1598

[pault at gcc dot gnu.org]

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

--- Comment #4 from Paul Thomas  ---
(In reply to Paul Thomas from comment #3)
> Yes, indeed it was the main part of my patch. I cannot see at the moment,
> though, why forcing the creation of a vtable is having this effect on caf in
> deallocate.
> 
> The call to gfc_caf_attr at trans-stmt.c:6644 is detecting that the
> component does not have attr.coarray_comp set so that is_coarray_array does
> not get set a few lines later and the wrong branch is taken at line 6661.
> Setting the latter flag in gdb at line 6651 allows the compilation to
> complete successfully.
> 
> Why a call to gfc_find_derived_vtab should have this effect is not evident
> to me at the moment. I'll take it though.
> 
> Thanks for the heads up, Jakub.
> 
> Paul

When I revert the patch for pr81447 (r254427) the testcase here compiles.
However, adding a class declaration triggers the same problem:

module m
   type t
  integer, pointer :: z
   end type
   class(t), allocatable :: c ! <= This triggers the same problem.
contains
   function f(x)
  type(t) :: x[*]
  if ( associated(x%z) ) deallocate(x%z)
   end
end

Hence, I would say that it is a pre-existing problem that has been exposed by
the fix for r254427 and is not really a regression.

Paul

[Bug c++/83160] [8 regression] lvalue required as unary ‘&’ operand

[daniel.kruegler at googlemail dot com]

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

Daniel Krügler  changed:

   What|Removed |Added

 CC||daniel.kruegler@googlemail.
   ||com

--- Comment #1 from Daniel Krügler  ---
The example looks invalid to me according to [expr.prim.lambda.capture] p7 b
(7.1), because the local variable bj is odr-used in the lambda expression

[](int bk) { a::ac(bk, bj); };

This is so, because the called function template

template  void ac(b, const b &);

attempts to bind its second argument by reference.

[Bug fortran/83042] [7/8 regression] ICE on valid code

[pault at gcc dot gnu.org]

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

--- Comment #7 from Paul Thomas  ---
Created attachment 42721
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42721=edit
A fix for this PR and PR83021

A fix for this PR

This fixes the problem and boostraps/regtests OK.

Paul

[Bug fortran/83021] [7/8 Regression] gfortran segfault in polymorphic assignment

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |pault at gcc dot gnu.org

--- Comment #10 from Paul Thomas  ---
Created attachment 42720
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42720=edit
A fix for this PR

This fixes the problem and boostraps/regtests OK.

Paul

[Bug fortran/83021] [7/8 Regression] gfortran segfault in polymorphic assignment

[juergen.reuter at desy dot de]

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

--- Comment #9 from Jürgen Reuter  ---
Does the reproducer in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83042
maybe help to fix this bug? At the moment our usage of the gcc trunk is frozen
as we cannot work around the many cases where it occurs.

[Bug c++/66672] std::is_same wrong result for captured reference value inside a lambda

[deaeod at gmail dot com]

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

Lukas  changed:

   What|Removed |Added

 CC||deaeod at gmail dot com

--- Comment #2 from Lukas  ---
I think gcc's result of 10 is correct, and i believe every other compiler is
wrong.

Consider the following passages:

http://eel.is/c++draft/expr.prim.lambda#capture-11.sentence-3
-- "An id-expression that is not an odr-use refers to the original entity,
never to a member of the closure type."
http://eel.is/c++draft/basic.def.odr#def:potentially_evaluated
-- "An expression is potentially evaluated unless it is an unevaluated
operand or a subexpression thereof."
http://eel.is/c++draft/basic.def.odr#def:odr-used
-- "A variable x whose name appears as a potentially-evaluated expression
ex is odr-used by ex unless [...]"
http://eel.is/c++draft/dcl.type.simple#4.sentence-3
-- "The operand of the decltype specifier is an unevaluated operand."

Combining (1) and (3) means that variable names refer to the original entity,
not the member of the closure, unless that variable name appears in a
potentially evaluated expression.
(2) and (4) combined say that the operand of decltype is not a potentially
evaluated expression.

Thus, variable names inside a decltype expression always refer to the outside
entities.

[Bug c++/83167] New: decltype((x)) inside lambda is considered odr-use if x is not a reference

[deaeod at gmail dot com]

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

Bug ID: 83167
   Summary: decltype((x)) inside lambda is considered odr-use if x
is not a reference
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: deaeod at gmail dot com
  Target Milestone: ---

https://godbolt.org/g/NmA3ZP

#include 

int main() {
int x = 1;
int&& y = static_cast(x);

auto A = []{ static_assert(std::is_same_v); };
auto B = [=]{ static_assert(std::is_same_v); };

auto C = []{ static_assert(std::is_same_v); };
auto D = [=]{ static_assert(std::is_same_v); };
}

I expected this to compile cleanly, but static asserts A and B fail under g++.
A fails because x wasnt captured and B fails because the deduced type is const
int&.

Here is how i would argue for my expectation:
http://eel.is/c++draft/expr.prim.lambda#capture-11.sentence-3
-- "An id-expression that is not an odr-use refers to the original entity,
never to a member of the closure type."
http://eel.is/c++draft/basic.def.odr#def:potentially_evaluated
-- "An expression is potentially evaluated unless it is an unevaluated
operand or a subexpression thereof."
http://eel.is/c++draft/basic.def.odr#def:odr-used
-- "A variable x whose name appears as a potentially-evaluated expression
ex is odr-used by ex unless [...]"
http://eel.is/c++draft/dcl.type.simple#4.sentence-3
-- "The operand of the decltype specifier is an unevaluated operand."

[Bug c++/83145] Ambiguous overload with templates, only GCC7 C++17 mode (regression?)

[l.lunak at centrum dot cz]

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

--- Comment #3 from Luboš Luňák  ---
You are right, it is controlled by the -fnew-ttp-matching option. But while I
admit I have a problem deciphering what the referenced paper says in practice
or how it exactly applies to this case, this still looks broken to me. Consider
the following case, which is the original reduced to just one template argument
instead of 3:

=
template 
class Variant {
};

class BinaryOutputStream {
};

template 
BinaryOutputStream& operator<<(BinaryOutputStream& stream, const
Variant& /*variant*/) {
return stream;
}

template  class TCollection,
  typename T>
BinaryOutputStream& operator<<(BinaryOutputStream& ostream, const
TCollection& /*arr*/) {
return ostream;
}

int main()
{
Variant variant;
BinaryOutputStream stream;
stream << variant;
return 0;
}
=

That still triggers the error. Now remove the use of the variadic template
(i.e. remove those 3 cases of "..."), and now it compiles just fine.

Why should the use of a variadic template make any difference here? To me the
Variant overload looks like an obviously better match in both cases.

[Bug fortran/83152] Possible run time error in derived type i/o

[dominiq at lps dot ens.fr]

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

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

[Bug fortran/83153] Possible run time error in derived type io example - 2

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #2 from Dominique d'Humieres  ---
The code works with the fixes in pr83152 comments 2 and 3. Marking as
duplicate.

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

[Bug fortran/83152] Possible run time error in derived type i/o

[dominiq at lps dot ens.fr]

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

--- Comment #3 from Dominique d'Humieres  ---
> By my count, you are off by one character in one of your field widths.
> Add a space at the end of the lines in the input file or change format to
>
>person_format='(a,2x,i3,2x,f4.2,1x,f3.0)'
>
> 1x, not 2x toward the end. (or maybe add a decimal point at end of lines
> in input file)

The code works if I replace ch3701_input_file.txt with

Zahpod Beeblebrox42  1.85  75.
Ford Prefect 25  1.75  65.
Arthur Dent  30  1.72  68.
Trillian 30  1.65  45.

IMO this PR should be resolved as INVALID.

[Bug target/83143] [SH]: Assembler messages: invalid operands (*UND* and .text sections) for `-'

[segher at gcc dot gnu.org]

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

--- Comment #12 from Segher Boessenkool  ---
Yes I use sh4-linux, but trunk (not 7).  Will try 7 later.

[Bug target/83143] [SH]: Assembler messages: invalid operands (*UND* and .text sections) for `-'

[olegendo at gcc dot gnu.org]

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

--- Comment #11 from Oleg Endo  ---
(In reply to James Clarke from comment #10)
> (In reply to Segher Boessenkool from comment #9)
> > What flags does it need?  I can't get it to fail.
> 
> Just -O2 -fPIC, at least with 7.2.0.

That is, if your default configuration is sh4-linux.  Otherwise you might need
to specify all the parameters.  AFAIR it's -ml -m4 -matomic-model=soft-gusa

[Bug target/83143] [SH]: Assembler messages: invalid operands (*UND* and .text sections) for `-'

[jrtc27 at jrtc27 dot com]

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

--- Comment #10 from James Clarke  ---
(In reply to Segher Boessenkool from comment #9)
> What flags does it need?  I can't get it to fail.

Just -O2 -fPIC, at least with 7.2.0.

[Bug target/83143] [SH]: Assembler messages: invalid operands (*UND* and .text sections) for `-'

[segher at gcc dot gnu.org]

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

--- Comment #9 from Segher Boessenkool  ---
What flags does it need?  I can't get it to fail.

[Bug middle-end/83164] [8 regression] internal compiler error: verify_gimple failed

[gerald at pfeifer dot com]

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

--- Comment #4 from Gerald Pfeifer  ---
(In reply to Marc Glisse from comment #2)
> Does it work if you remove the verification
> 
> || !types_compatible_p (rhs1_type, rhs2_type)
> 
> from tree-cfg.c?

Yes, I just tried this.

[Bug fortran/83076] [8 Regression] ICE in gfc_deallocate_scalar_with_status, at fortran/trans.c:1598

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |pault at gcc dot gnu.org

--- Comment #3 from Paul Thomas  ---
Yes, indeed it was the main part of my patch. I cannot see at the moment,
though, why forcing the creation of a vtable is having this effect on caf in 
deallocate.

The call to gfc_caf_attr at trans-stmt.c:6644 is detecting that the component
does not have attr.coarray_comp set so that is_coarray_array does not get set a
few lines later and the wrong branch is taken at line 6661. Setting the latter
flag in gdb at line 6651 allows the compilation to complete successfully.

Why a call to gfc_find_derived_vtab should have this effect is not evident to
me at the moment. I'll take it though.

Thanks for the heads up, Jakub.

Paul

[Bug target/83143] [SH]: Assembler messages: invalid operands (*UND* and .text sections) for `-'

[jrtc27 at jrtc27 dot com]

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

--- Comment #8 from James Clarke  ---
Created attachment 42719
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42719=edit
Reduced reproduction.

This is a reduced version of the original reproduction. Creduce will happily
make it even smaller if you let it do crazy enum-to-pointer casts and various
other warning-inducing things, but this builds with -Wall -Werror.