[Bug other/81334] New: -Wmisleading-indentation

[mick.pearson at wildblue dot net]

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

Bug ID: 81334
   Summary: -Wmisleading-indentation
   Product: gcc
   Version: 6.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mick.pearson at wildblue dot net
  Target Milestone: ---

"note: -Wmisleading-indentation is disabled from this point onwards, since
column-tracking was disabled due to the size of the code/headers
if(Min<0) Min = 0; if(Max

[Bug middle-end/80775] [8 Regression] -O3 produces ice in group_case_labels_stmt

[bergner at gcc dot gnu.org]

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

Peter Bergner  changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

--- Comment #17 from Peter Bergner  ---
(In reply to David Binderman from comment #16)
> (In reply to Peter Bergner from comment #15)
> > Doesn't fail for me on x86_64 either, so I'll need target/configure options
> > as well as full compile options.
> 
> Seems fixed somewhere between revision 249638 and 249861.

It could be fixed by either richi's:

https://gcc.gnu.org/ml/gcc-patches/2017-06/msg02237.html

or my fix to:

https://gcc.gnu.org/PR81194

I'm going to close this again, since it's not reproducible anymore.

[Bug target/81333] Bad alignment of global variables on Alpha

[mikulas at artax dot karlin.mff.cuni.cz]

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

--- Comment #3 from mikulas at artax dot karlin.mff.cuni.cz ---
> Only C11 and above.  C99 and C98 does not have any requirements like that :)

Accessing any variable with the char pointer is allowed in C89 and newer
standards. Threading is not covered at all in C89 and C99.

See this quote from C89:
A.6.2 Undefined behavior:
* An object has its stored value accessed by an lvalue that does not have one
of the following types: the declared type of the object, a qualified version of
the declared type of the object, the signed or unsigned type corresponding to
the declared type of the object, the signed or unsigned type corresponding to a
qualified version of the declared type of the object, an aggregate or union
type that (recursively) includes one of the aforementioned types among its
members, or a character type ($3.3).

[Bug target/81333] Bad alignment of global variables on Alpha

[mikulas at artax dot karlin.mff.cuni.cz]

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

--- Comment #2 from mikulas at artax dot karlin.mff.cuni.cz ---
Created attachment 41691
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41691=edit
another testcase

Another testcase - note that even if we have two static variables in two
separate functions, the variables end up being located in the same 8-byte area
and when they are accessed concurrently, data corruption happens.

[Bug target/81333] Bad alignment of global variables on Alpha

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||wrong-code

--- Comment #1 from Andrew Pinski  ---
>Note that according to the C standard any variable

Only C11 and above.  C99 and C98 does not have any requirements like that :).

[Bug target/81333] New: Bad alignment of global variables on Alpha

[mikulas at artax dot karlin.mff.cuni.cz]

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

Bug ID: 81333
   Summary: Bad alignment of global variables on Alpha
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mikulas at artax dot karlin.mff.cuni.cz
  Target Milestone: ---
  Host: alpha-linux-gnu
Target: alpha-linux-gnu
 Build: alpha-linux-gnu

Created attachment 41690
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41690=edit
A testcase that triggers the bug

The first version of the Alpha architecture doesn't have instructions that can
read or write 1-byte or 2-byte values in memory. When we need to write 1-byte
or 2-byte value, the compiler generates code that reads 8 bytes, modifies a
single byte or two bytes and writes 8 bytes.

GCC packs multiple global byte variables into the same 8-byte area. When we
spawn multiple threads and each thread modifies its own variable, the threads
may end up reading and writing the same 8-byte area, resulting in race
condition and data corruption.

Note that according to the C standard any variable can be accessed through a
char * pointer, thus, to avoid the race condition, all global and static
variables should be aligned on 8-byte boundary.

[Bug rtl-optimization/81332] New: GCC crash during "RTL pass: expand" - verify_flow_info: REG_BR_PROB does not match cfg

[babokin at gmail dot com]

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

Bug ID: 81332
   Summary: GCC crash during "RTL pass: expand" -
verify_flow_info: REG_BR_PROB does not match cfg
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: babokin at gmail dot com
  Target Milestone: ---

gcc rev250008, x86_64.

> cat f.cpp
extern int var_8, var_18, var_29, var_1365;
long a;
int b;
bool c;
void foo() {
  if (c + 7 << bool(var_8) - 1)
b = 1;
  if (var_29 | b)
var_1365 = a && b && var_18;
}

> g++ -O2 -c f.cpp
f.cpp: In function ‘void foo()’:
f.cpp:10:1: error: verify_flow_info: REG_BR_PROB does not match cfg 3750 7500
 }
 ^
during RTL pass: expand
f.cpp:10:1: internal compiler error: verify_flow_info failed
0xab17ba verify_flow_info()
../../gcc_svn_intel/gcc/cfghooks.c:259
0x1541f26 checking_verify_flow_info
../../gcc_svn_intel/gcc/cfghooks.h:198
0x1541f26 try_optimize_cfg
../../gcc_svn_intel/gcc/cfgcleanup.c:3040
0x1541f26 cleanup_cfg(int)
../../gcc_svn_intel/gcc/cfgcleanup.c:3204
0xaaf38e execute
../../gcc_svn_intel/gcc/cfgexpand.c:6486
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug regression/81331] New: [8 Regression] FAIL: 21_strings/basic_string/modifiers/insert/char/1.cc execution test

[redi at gcc dot gnu.org]

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

Bug ID: 81331
   Summary: [8 Regression] FAIL:
21_strings/basic_string/modifiers/insert/char/1.cc
execution test
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: regression
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
CC: hubicka at gcc dot gnu.org
  Target Milestone: ---

This appeared at r249966 although some testresults show it at earlier revisions
e.g.  https://gcc.gnu.org/ml/gcc-testresults/2017-07/msg00396.html has the
failure at 249963

[Bug tree-optimization/81330] New: missing strlen optimization with intervening memcpy

[msebor at gcc dot gnu.org]

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

Bug ID: 81330
   Summary: missing strlen optimization with intervening memcpy
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

GCC eliminates redundant calls to strlen() with intervening calls to strcpy but
it misses an opportunity to do the same when the intervening call is to memcpy
instead.  In the test case below, since both strcpy and memcpy require that the
copies do not overlap, it's safe to assume that neither call modifies any part
of the source string, including the terminating nul, and so the second strlen
call can be replaced with the result of the first in both functions, not just
in f().  The strlen dump shows that GCC doesn't take advantage of this
guarantee in the memcpy case.

(The second strlen call in g is replaced with the result of the first in g when
memcpy is passed n0 + 1 as the size but I don't see why that should make a
difference.)

$ cat a.c && gcc -O2 -S -Wall -fdump-tree-strlen=/dev/stdout a.c
void f (char* d, const char* s)
{
  __SIZE_TYPE__ n0 = __builtin_strlen (s);

  __builtin_strcpy (d, s);

  __SIZE_TYPE__ n1 = __builtin_strlen (s);

  if (n0 != n1)
__builtin_abort ();   // optimized
}

void g (char* d, const char* s)
{
  __SIZE_TYPE__ n0 = __builtin_strlen (s);

  __builtin_memcpy (d, s, n0);

  __SIZE_TYPE__ n1 = __builtin_strlen (s);

  if (n0 != n1)
__builtin_abort ();   // not optimized
}


;; Function f (f, funcdef_no=0, decl_uid=1816, cgraph_uid=0, symbol_order=0)

f (char * d, const char * s)
{
  long unsigned int n1;
  long unsigned int n0;
  long unsigned int _8;

   [100.00%] [count: INV]:
  n0_3 = __builtin_strlen (s_2(D));
  _8 = n0_3 + 1;
  __builtin_memcpy (d_4(D), s_2(D), _8);
  n1_6 = n0_3;
  if (n0_3 != n1_6)
goto ; [0.04%] [count: 0]
  else
goto ; [99.96%] [count: INV]

   [0.04%] [count: 0]:
  __builtin_abort ();

   [99.96%] [count: INV]:
  return;

}



;; Function g (g, funcdef_no=1, decl_uid=1822, cgraph_uid=1, symbol_order=1)

g (char * d, const char * s)
{
  long unsigned int n1;
  long unsigned int n0;

   [100.00%] [count: INV]:
  n0_3 = __builtin_strlen (s_2(D));
  __builtin_memcpy (d_4(D), s_2(D), n0_3);
  n1_6 = __builtin_strlen (s_2(D));
  if (n0_3 != n1_6)
goto ; [0.04%] [count: 0]
  else
goto ; [99.96%] [count: INV]

   [0.04%] [count: 0]:
  __builtin_abort ();

   [99.96%] [count: INV]:
  return;

}

[Bug middle-end/81329] Missing -Wmaybe-uninitialized warning

[tudorb at gmail dot com]

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

--- Comment #2 from Tudor Bosman  ---
(In reply to Andrew Pinski from comment #1)
> There are a few duplicates of this bug floating around.

I figured, but I don't know anything about gcc internals to tell which of these
duplicates are the same bug and which are different (same symptom, different
internal cause).

[Bug middle-end/81329] Missing -Wmaybe-uninitialized warning

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|c   |middle-end

--- Comment #1 from Andrew Pinski  ---
There are a few duplicates of this bug floating around.

[Bug c/81329] New: Missing -Wmaybe-uninitialized warning

[tudorb at gmail dot com]

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

Bug ID: 81329
   Summary: Missing -Wmaybe-uninitialized warning
   Product: gcc
   Version: 7.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tudorb at gmail dot com
  Target Milestone: ---

Created attachment 41689
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41689=edit
Missed maybe-uninitialized warning: test case

The attached test case should warn, as foo is used uninitialized if the
"atoi(argv[1]) != 0" branch isn't taken. There are no warnings, even with
"-Wall -Wextra".

Tested with gcc 7.1, both with -O0 and with -O3, see
https://godbolt.org/g/J5wRSM

[Bug c++/81147] [avr] C++ for -mmcu=atmega2560 doesn't do NRVO or RVO when class inherits from empty base

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

 Status|WAITING |UNCONFIRMED
 Ever confirmed|1   |0

[Bug target/80103] ICE in output_1144, at config/rs6000/vsx.md:2298

[kelvin at gcc dot gnu.org]

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

--- Comment #4 from kelvin at gcc dot gnu.org ---
Author: kelvin
Date: Wed Jul  5 20:51:37 2017
New Revision: 250008

URL: https://gcc.gnu.org/viewcvs?rev=250008=gcc=rev
Log:
gcc/testsuite/ChangeLog:

2017-07-05  Kelvin Nilsen  

PR target/80103
* gcc.target/powerpc/pr80103-1.c (void b): Correct spelling of
__attribute__.



Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/powerpc/pr80103-1.c

[Bug fortran/50402] ICE in gfc_conv_expr_descriptor

[zeccav at gmail dot com]

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

--- Comment #8 from Vittorio Zecca  ---
1) Sometimes error reports slip through the cracks, it happened to me,
and I found it's good
to remind that the bug is still around. Sometimes it happened the
contrary, the bug silently
disappears but the error report is still open.
There are more things in heaven and earth, Horatio, Than are
dreamt of in your philosophy.

2)  At least I got an answer from you, that an error would be better
than an ICE,
 this is obvious to me but not to everybody, it also influences
the credibility
 of a product, a crashing product is less credible than a product
issuing error messages.

[Bug ada/81328] New: Wrong order of error messages

[porton at narod dot ru]

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

Bug ID: 81328
   Summary: Wrong order of error messages
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: porton at narod dot ru
  Target Milestone: ---

Created attachment 41688
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41688=edit
A source with a deliberate error

GNAT provides an error list for my erroneous input in wrong order.

I sent a minimized code where this is not a problem, but I got this GNAT
behavior in real code, what lead me to try to first fix the first error (which
in reality was caused by the second error), but it was unexpected that to fix
the first error I first need to fix the second error.

The output order of compilation errors should be such that the programmer would
be able to fix the errors in the order of compiler output, rather than to make
the programmer to guess that he needs first look into the next error.

Here is compilation of my erroneous source (the error is missing `with
Auxiliary;` in www.ads file):

$ gnatgcc -c www.adb
www.adb:6:14: "From_Handle" is not visible
www.adb:6:14: non-visible declaration at limited_handled_record.ads:7
www.ads:6:61: "Auxiliary" is undefined
www.ads:6:70: instantiation abandoned
www.ads:8:28: "WWW_Handled_Record" is undefined (more references follow)

To make From_Handle visible, I need first note that the problem is caused by
Auxiliary being undefined. The message that it is not visible is confusing,
because it is not just not visible but in reality undefined.

$ gnatgcc -v
Using built-in specs.
COLLECT_GCC=gnatgcc
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='Debian 7.1.0-7'
--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 --enable-default-pie
--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 (Debian 7.1.0-7)

[Bug target/79202] On Power8, consider using vupkhsw/xxpermdi to sign extend an int in a vector register instead of mfvsrwz/mtvsrwa

[meissner at gcc dot gnu.org]

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

Michael Meissner  changed:

   What|Removed |Added

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

--- Comment #8 from Michael Meissner  ---
Fixed in trunk and gcc 7.x.

[Bug target/79799] Improve vec_insert of float on Power9

[meissner at gcc dot gnu.org]

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

Michael Meissner  changed:

   What|Removed |Added

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

--- Comment #4 from Michael Meissner  ---
Fixed in trunk and GCC 7.x.

[Bug target/80510] Optimize Power7/power8 Altivec load/stores

[meissner at gcc dot gnu.org]

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

Michael Meissner  changed:

   What|Removed |Added

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

--- Comment #11 from Michael Meissner  ---
Fixed in trunk, gcc 7.x, and gcc 6.x

[Bug target/79203] Update PowerPC double->int conversions to know about -mvsx-small-integer

[meissner at gcc dot gnu.org]

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

Michael Meissner  changed:

   What|Removed |Added

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

--- Comment #4 from Michael Meissner  ---
Fixed in trunk and gcc 7.x

[Bug c++/81147] [avr] C++ for -mmcu=atmega2560 doesn't do NRVO or RVO when class inherits from empty base

[felipe at expertisesolutions dot com.br]

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

Felipe Magno de Almeida  changed:

   What|Removed |Added

  Attachment #41594|0   |1
is obsolete||

--- Comment #4 from Felipe Magno de Almeida  ---
Created attachment 41687
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41687=edit
Same source file without unnecessary #includes

[Bug c++/81147] [avr] C++ for -mmcu=atmega2560 doesn't do NRVO or RVO when class inherits from empty base

[felipe at expertisesolutions dot com.br]

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

--- Comment #3 from Felipe Magno de Almeida  ---
It actually compiles for me because I have enabled libstdc++v3 for avr target.
But I'm attaching a new one without the unnecessary includes.
Line command to compile:

avr-g++ -std=c++14 -fno-exceptions -fno-rtti -Wno-unused-local-typedefs
-fno-use-cxa-atexit -save-temps -fverbose-asm -dap -fdump-tree-all-all -Wall
-mmcu=atmega2560 -fno-strict-aliasing -DAUTO_CRC_PADDING=2 -Os
-ffunction-sections -fdata-sections -MMD -c test.cpp -o test.o

Regards,

[Bug fortran/68649] [6/7/8 Regression] note: code may be misoptimized unless -fno-strict-aliasing is used

[egall at gwmail dot gwu.edu]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egall at gwmail dot gwu.edu

--- Comment #21 from Eric Gallager  ---
Bug 80379 is related

[Bug other/81326] gcc-ar: Cannot find plugin 'liblto_plugin.so' Mac Sierra Xcode 8.3.3

[malcolm2190 at att dot net]

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

--- Comment #4 from mwindham  ---
See Bug 63758

[Bug target/80266] ICE in store_pairsi condition with -mabi=ilp32

[wilco at gcc dot gnu.org]

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

--- Comment #2 from Wilco  ---
Fixing aarch64_classify_address means we now reject incorrect addresses,
however GCC midend generates a lot of 32-bit pointers which are not correctly
changed into addresses, resulting in even more assertions. So there is no easy
fix until the mid-end understands the difference between pointers and
addresses...

[Bug other/81326] gcc-ar: Cannot find plugin 'liblto_plugin.so' Mac Sierra Xcode 8.3.3

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-07-05
 Ever confirmed|0   |1

--- Comment #3 from Dominique d'Humieres  ---
> This was fixed once upon a time but is in a build of 7.1.0.

I see gcc-ar, gcc-nm, and gcc-ranlib on my builds from 4.8 up to trunk (8.0)
and they all fail with "Cannot find plugin 'liblto_plugin.so'" when run with
-v.

Unless someone wants to work on this issue, I propose to close it as WONTFIX.

[Bug c++/81327] New: cast to void* does not suppress -Wclass-memaccess

[msebor at gcc dot gnu.org]

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

Bug ID: 81327
   Summary: cast to void* does not suppress -Wclass-memaccess
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

In cases where the -Wclass-memaccess warning (new in GCC 8) points out benign
code the warning can be suppressed by casting a pointer to the class object to
char*.   In Clang that implements a similar warning
(-Wdynamic-class-memaccess), the warning can also be suppressed by casting the
pointer to void* but the same doesn't work in GCC.  It's been suggested that it
might be nice if GCC also recognized a void* cast as a suppression mechanism. 
(Unfortunately, where the warning is implemented in the GCC C++ front end an
explicit void* cast is indistinguishable from the implicit conversion to the
void* argument to the raw memory function.)

$ cat t.C && gcc -S -Wall t.C
struct S { virtual ~S (); };

void f (struct S *s)
{
  __builtin_memset (s, 0, sizeof *s);
}

void g (struct S *s)
{
  __builtin_memset ((void*)s, 0, sizeof *s);
}

void h (struct S *s)
{
  __builtin_memset ((char*)s, 0, sizeof *s);
}

t.C: In function ‘void f(S*)’:
t.C:5:36: warning: ‘void* __builtin_memset(void*, int, long unsigned int)’
clearing an object of type ‘struct S’ with no trivial copy-assignment; use
assignment or value-initialization instead [-Wclass-memaccess]
   __builtin_memset (s, 0, sizeof *s);
^
t.C:1:8: note: ‘struct S’ declared here
 struct S { virtual ~S (); };
^
t.C: In function ‘void g(S*)’:
t.C:10:43: warning: ‘void* __builtin_memset(void*, int, long unsigned int)’
clearing an object of type ‘struct S’ with no trivial copy-assignment; use
assignment or value-initialization instead [-Wclass-memaccess]
   __builtin_memset ((void*)s, 0, sizeof *s);
   ^
t.C:1:8: note: ‘struct S’ declared here
 struct S { virtual ~S (); };
^

Clang output for the same test case:

$ clang -S -Wall t.C
t.C:5:21: warning: destination for this '__builtin_memset' call is a pointer to
  dynamic class 'S'; vtable pointer will be overwritten
  [-Wdynamic-class-memaccess]
  __builtin_memset (s, 0, sizeof *s);
    ^
t.C:5:21: note: explicitly cast the pointer to silence this warning
  __builtin_memset (s, 0, sizeof *s);
^
(void*)
1 warning generated.

[Bug bootstrap/81033] [8 Regression] Revision r249019 breaks bootstrap on darwin

[egall at gwmail dot gwu.edu]

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

--- Comment #18 from Eric Gallager  ---
(In reply to Dominique d'Humieres from comment #10)
> The last patch in comment 8 exposes another problem: buf[128] is too small.
> 
> The following patch which uses the trick proposed in IRC by Richi to split
> assemble_name_raw seems to work
> 
> --- ../_clean/gcc/config/darwin.c 2017-01-01 17:39:06.0 +0100
> +++ gcc/config/darwin.c   2017-07-03 14:21:19.0 +0200
> @@ -3683,11 +3683,9 @@ default_function_sections:
>  void
>  darwin_function_switched_text_sections (FILE *fp, tree decl, bool
> new_is_cold)
>  {
> -  char buf[128];
> -  snprintf (buf, 128, "%s%s",new_is_cold?"__cold_sect_of_":"__hot_sect_of_",
> - IDENTIFIER_POINTER (DECL_NAME (decl)));
>/* Make sure we pick up all the relevant quotes etc.  */
> -  assemble_name_raw (fp, (const char *) buf);
> +  assemble_name_raw (fp, new_is_cold?"__cold_sect_of_":"__hot_sect_of_");
> +  assemble_name_raw (fp, IDENTIFIER_POINTER (DECL_ASSEMBLER_NAME (decl)));
>fputs (":\n", fp);
>  }

I successfully bootstrapped with this patch; the test results produced by it
can be found here: https://gcc.gnu.org/ml/gcc-testresults/2017-07/msg00365.html

[Bug fortran/50402] ICE in gfc_conv_expr_descriptor

[dominiq at lps dot ens.fr]

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

--- Comment #7 from Dominique d'Humieres  ---
> This is still in trunk 249883

Did you fixed it? If no, the only relevant information would be to report that
it has been fixed.

> The test case may be wrong, but
>
> 1) gfortran should never crash but deliver an error message instead
>
> 2) on this test case gfortran is giving no error message
>   so how do I know it is wrong?

Although it happens that compilers ICE on valid codes, most of the time ICEs
are the signature of invalid codes. Indeed an error would be better than an
ICE.

[Bug other/81326] gcc-ar: Cannot find plugin 'liblto_plugin.so' Mac Sierra Xcode 8.3.3

[malcolm2190 at att dot net]

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

--- Comment #2 from mwindham  ---
See https://solarianprogrammer.com/2017/05/21/compiling-gcc-macos/ in comment 

Vincent Le Bourlot  • 15 days ago

Trying to get gcc working on my mac Sierra, I tried your tuto, but using the
newly compiled gcc-ar, I still get "gcc/gcc-ar: Cannot find plugin
'liblto_plugin.so'". Any way you managed to get this working?

which is my result after a successful build.

[Bug other/81326] gcc-ar: Cannot find plugin 'liblto_plugin.so' Mac Sierra Xcode 8.3.3

[malcolm2190 at att dot net]

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

--- Comment #1 from mwindham  ---
See https://solarianprogrammer.com/2017/05/21/compiling-gcc-macos/ in comment 

Vincent Le Bourlot  • 15 days ago

Trying to get gcc working on my mac Sierra, I tried your tuto, but using the
newly compiled gcc-ar, I still get "gcc/gcc-ar: Cannot find plugin
'liblto_plugin.so'". Any way you managed to get this working?

which is my result after a successful build.

[Bug other/81326] New: gcc-ar: Cannot find plugin 'liblto_plugin.so' Mac Sierra Xcode 8.3.3

[malcolm2190 at att dot net]

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

Bug ID: 81326
   Summary: gcc-ar: Cannot find plugin 'liblto_plugin.so' Mac
Sierra Xcode 8.3.3
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: malcolm2190 at att dot net
  Target Milestone: ---

This was fixed once upon a time but is in a build of 7.1.0. Something about a
call to environment on OSX.

[Bug c/46742] -Wparentheses unexpectedly misses some cases

[egall at gwmail dot gwu.edu]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egall at gwmail dot gwu.edu

--- Comment #2 from Eric Gallager  ---
(In reply to Mikael Pettersson from comment #0)
> 
> Side note, shouldn't there be a "diagnostic" component in bugzilla?  For now
> I chose "C frontend", which may or may not be appropriate.

You can put "diagnostic" under "keywords" instead

[Bug fortran/50402] ICE in gfc_conv_expr_descriptor

[zeccav at gmail dot com]

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

Vittorio Zecca  changed:

   What|Removed |Added

Version|4.8.0   |8.0

--- Comment #6 from Vittorio Zecca  ---
This is still in trunk 249883

The test case may be wrong, but

1) gfortran should never crash but deliver an error message instead

2) on this test case gfortran is giving no error message
   so how do I know it is wrong?

[Bug rtl-optimization/80818] LRA clobbers live hard reg clobbered during rematerialization

[vmakarov at gcc dot gnu.org]

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

--- Comment #6 from Vladimir Makarov  ---
Hi, Andreas.

Could you check the patch I attached on your bigger test case.  If it works, I
will commit it.

[Bug rtl-optimization/80818] LRA clobbers live hard reg clobbered during rematerialization

[vmakarov at gcc dot gnu.org]

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

--- Comment #5 from Vladimir Makarov  ---
Created attachment 41686
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41686=edit
A proposed patch

[Bug bootstrap/80838] PGO/LTO bootstrapped compiler 5% slower than pure PGO bootstrapped one

[trippels at gcc dot gnu.org]

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

--- Comment #6 from Markus Trippelsdorf  ---
Nice! I now get a ~2% improvement on the tramp3d testcase with PGO/LTO.

[Bug target/81072] [avr] Support some XMEGA devices with flash seen in RAM address space.

[gjl at gcc dot gnu.org]

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

--- Comment #4 from Georg-Johann Lay  ---
Author: gjl
Date: Wed Jul  5 13:57:28 2017
New Revision: 25

URL: https://gcc.gnu.org/viewcvs?rev=25=gcc=rev
Log:
gcc/
Graceful degrade if Binutils PR21472 is not available.
PR target/81072
* configure.ac [target=avr]: WARN instead of ERROR if avrxmega3
.rodata in flash test fails.
(HAVE_LD_AVR_AVRXMEGA3_RODATA_IN_FLASH): Define it if test passes.
* confgure: Regenerate.
* config.in: Regenerate.
* config/avr/avr.c (avr_asm_named_section)
[HAVE_LD_AVR_AVRXMEGA3_RODATA_IN_FLASH]: Only trigger
__do_copy_data for stuff in .rodata if flash_pm_offset = 0.
(avr_asm_init_sections): Same.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config.in
trunk/gcc/config/avr/avr.c
trunk/gcc/configure
trunk/gcc/configure.ac

[Bug target/81325] New: -fcompare-debug failure on ppc64le

[trippels at gcc dot gnu.org]

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

Bug ID: 81325
   Summary: -fcompare-debug failure on ppc64le
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: trippels at gcc dot gnu.org
CC: segher at gcc dot gnu.org
  Target Milestone: ---

trippels@gcc2-power8 llvm_build % cat test.ii
struct A {
  A(char *, const int & = 0);
};
template  struct B;
template  struct C {
  int _M_i;
  void m_fn1() { __atomic_fetch_add(&_M_i, 0, 0); }
};
struct D {
  int *Data;
  long Length = 0;
  D(int) : Data() {}
};
template <> struct B : C {};
struct F {
  B RefCount;
  void m_fn2() { RefCount.m_fn1(); }
};
struct G {
  F *Obj;
  G(const G ) : Obj(p1.Obj) {
if (Obj) {
  F *a = 0;
  a->m_fn2();
}
  }
};
struct H {
  int CPlusPlus : 1;
};
struct I {
  enum {} KindId;
};
template  struct J {
  void operator()();
  ResultT operator()(ArgT) {}
};
struct K {
  int AllowBind;
  I SupportedKind;
  I RestrictKind;
  G Implementation;
};
struct L {
  L(int) : Implementation(Implementation) {}
  K Implementation;
};
struct M {
  int Param1;
};
struct N {
  N(int, L ) : Param2(p2) {}
  L Param2;
};
struct O {
  L m_fn3();
};
L ignoringImpCasts(L);
J b;
L hasName(const A &);
M hasOverloadedOperatorName(D);
J c;
struct P {
  void m_fn4(L, int);
};
struct Q {
  void m_fn5(P *);
};
H d;
void Q::m_fn5(P *p1) {
  if (!d.CPlusPlus) {
c();
L e = 0, f = ignoringImpCasts(e);
b(ignoringImpCasts(f)).m_fn3();
  }
  hasOverloadedOperatorName(0);
  hasName("");
  L g = 0;
  N(0, g);
  L h(0);
  p1->m_fn4(h, 0);
}

trippels@gcc2-power8 llvm_build % g++ --save-temps -c -O2 -fcompare-debug
test.ii
test.ii: In member function ‘void Q::m_fn5(P*)’:
test.ii:77:13: warning: ISO C++ forbids converting a string constant to ‘char*’
[-Wwrite-strings]
   hasName("");
 ^
g++: error: test.ii: -fcompare-debug failure

trippels@gcc2-power8 llvm_build % diff -u test.gkd test.gk.gkd
--- test.gkd2017-07-05 13:49:05.946937825 +
+++ test.gk.gkd 2017-07-05 13:49:06.076940789 +
@@ -131,7 +131,7 @@
 (int_list:REG_BR_PROB 3300 (nil)))
  -> 30)
 (note # 0 0 [bb 3] NOTE_INSN_BASIC_BLOCK)
-(insn:TI # 0 0 (set (reg/f:DI 31 31 [205])
+(insn:TI # 0 0 (set (reg/f:DI 31 31 [206])
 (plus:DI (reg/f:DI 1 1)
 (const_int 32 [0x20])))# {*adddi3}
  (expr_list:REG_EQUAL (plus:DI (reg/f:DI 111 sfp)
@@ -143,7 +143,7 @@
  (expr_list:REG_EQUAL (plus:DI (reg/f:DI 111 sfp)
 (const_int 56 [0x38]))
 (nil)))
-(insn # 0 0 (set (reg/f:DI 30 30 [206])
+(insn # 0 0 (set (reg/f:DI 30 30 [205])
 (plus:DI (reg/f:DI 1 1)
 (const_int 80 [0x50])))# {*adddi3}
  (expr_list:REG_EQUAL (plus:DI (reg/f:DI 111 sfp)
@@ -198,7 +198,7 @@
  (expr_list:REG_EQUAL (symbol_ref/f:DI ("*.LC0") [flags 0x82]  )
 (nil)))
 (insn # 0 0 (set (reg:DI 3 3)
-(reg/f:DI 30 30 [206])) "test.ii":77# {*movdi_internal64}
+(reg/f:DI 30 30 [205])) "test.ii":77# {*movdi_internal64}
  (expr_list:REG_EQUAL (plus:DI (reg/f:DI 111 sfp)
 (const_int 80 [0x50]))
 (nil)))
@@ -223,13 +223,13 @@
 (expr_list:DI (use (reg:DI 5 5))
 (nil))
 (insn # 0 0 (set (reg:DI 4 4)
-(reg/f:DI 30 30 [206])) "test.ii":77# {*movdi_internal64}
- (expr_list:REG_DEAD (reg/f:DI 30 30 [206])
+(reg/f:DI 30 30 [205])) "test.ii":77# {*movdi_internal64}
+ (expr_list:REG_DEAD (reg/f:DI 30 30 [205])
 (expr_list:REG_EQUAL (plus:DI (reg/f:DI 111 sfp)
 (const_int 80 [0x50]))
 (nil
 (insn # 0 0 (set (reg:DI 3 3)
-(reg/f:DI 31 31 [205])) "test.ii":77# {*movdi_internal64}
+(reg/f:DI 31 31 [206])) "test.ii":77# {*movdi_internal64}
  (expr_list:REG_EQUAL (plus:DI (reg/f:DI 111 sfp)
 (const_int 32 [0x20]))
 (nil)))
@@ -267,8 +267,8 @@
  (expr_list:REG_EQUIV (const_int 0 [0])
 (nil)))
 (insn # 0 0 (set (reg:DI 4 4)
-(reg/f:DI 31 31 [205])) "test.ii":81# {*movdi_internal64}
- (expr_list:REG_DEAD (reg/f:DI 31 31 [205])
+(reg/f:DI 31 31 [206])) "test.ii":81# {*movdi_internal64}
+ (expr_list:REG_DEAD (reg/f:DI 31 31 [206])
 (expr_list:REG_EQUAL (plus:DI (reg/f:DI 111 sfp)
 (const_int 32 [0x20]))
 (nil
@@ -369,7 +369,7 @@
  (expr_list:REG_EQUAL (const:DI (plus:DI (symbol_ref:DI ("*.LANCHOR0")
[flags 0x182])
 (const_int 4 [0x4])))
 (nil)))
-(insn # 0 0 (set (reg/f:DI 31 31 [205])
+(insn # 0 0 (set (reg/f:DI 31 31 [206])

It looks like an ancient issue, because even it fails even with gcc-4.8.5.

[Bug target/81305] [avr] avrtiny uses LDS for SREG in ISR routines which is out of range of LDS.

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
Version|unknown |6.3.1
 Resolution|--- |FIXED
   Target Milestone|--- |7.2

--- Comment #4 from Georg-Johann Lay  ---
Fixed in 7.2

[Bug bootstrap/80838] PGO/LTO bootstrapped compiler 5% slower than pure PGO bootstrapped one

[hubicka at gcc dot gnu.org]

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

--- Comment #5 from Jan Hubicka  ---
OK, found the problem.  LTO binary is built with -fPIC because of the way we
merge options.  I saw the same problem previously on Firefox. It is easy
mistake to do.  I think we should
 1) warn in this case
 2) downgrade options,  i.e. linking non-PIC onject to PIC leads to non-PIC
binary.

I don't think it makes sense to support mixed binaries because I see no benefit
in that.

With hack to lto-wrapper:
Index: lto-wrapper.c
===
--- lto-wrapper.c   (revision 249928)
+++ lto-wrapper.c   (working copy)
@@ -238,10 +238,12 @@ merge_and_complain (struct cl_decoded_op
case OPT_fdiagnostics_show_option:
case OPT_fdiagnostics_show_location_:
case OPT_fshow_column:
+#if 0
case OPT_fPIC:
case OPT_fpic:
case OPT_fPIE:
case OPT_fpie:
+#endif
case OPT_fcommon:
case OPT_fexceptions:
case OPT_fnon_call_exceptions:
@@ -501,10 +503,12 @@ append_compiler_options (obstack *argv_o
case OPT_fdiagnostics_show_option:
case OPT_fdiagnostics_show_location_:
case OPT_fshow_column:
+#if 0
case OPT_fPIC:
case OPT_fpic:
case OPT_fPIE:
case OPT_fpie:
+#endif
case OPT_fcommon:
case OPT_fexceptions:
case OPT_fnon_call_exceptions:


I now get:
$ perf_4.3 stat ./xgcc -B ./ -O2 -S ~/combine.ii

 Performance counter stats for './xgcc -B ./ -O2 -S /aux/hubicka/combine.ii':

   5664.950671  task-clock (msec) #0.998 CPUs utilized
   581  context-switches  #0.103 K/sec
 5  cpu-migrations#0.001 K/sec
45,008  page-faults   #0.008 M/sec
16,882,004,890  cycles#2.980 GHz
 2,818,057,410  stalled-cycles-frontend   #   16.69% frontend cycles
idle
 5,462,286,464  stalled-cycles-backend#   32.36% backend  cycles
idle
13,279,784,844  instructions  #0.79  insns per cycle
  #0.41  stalled cycles per
insn
 2,919,823,112  branches  #  515.419 M/sec
   141,311,318  branch-misses #4.84% of all branches

   5.674328322 seconds time elapsed

Which is nice improvement over non-LTO binary.

[Bug c/46742] -Wparentheses unexpectedly misses some cases

[sirl at gcc dot gnu.org]

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

Franz Sirl  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-07-05
 CC||sirl at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Franz Sirl  ---
Still happens with 7.1.1 and trunk. clang catches both with the
-Wlogical-not-parentheses option.

[Bug bootstrap/81298] [7 Regression] Bootstrapping trunk fails during stage1-bubble on x86_64-pc-linux-gnu with --enable-maintainer-mode

[egall at gwmail dot gwu.edu]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egall at gwmail dot gwu.edu

--- Comment #9 from Eric Gallager  ---
(In reply to tkoe...@netcologne.de from comment #8)
> 
> I understand that desire, but autoconf 2.69 has been around since 2012.
> It is hardly a fast-moving target.
> 
> I think it would be better to make a change towards 2.69.  The fewer
> versions of extra software we have to use to compile gcc, the better.

Seconded; I have local versions of override.m4 patched to say 2.69 instead of
2.64 for this reason

[Bug target/81305] [avr] avrtiny uses LDS for SREG in ISR routines which is out of range of LDS.

[gjl at gcc dot gnu.org]

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

--- Comment #3 from Georg-Johann Lay  ---
Author: gjl
Date: Wed Jul  5 12:49:08 2017
New Revision: 249998

URL: https://gcc.gnu.org/viewcvs?rev=249998=gcc=rev
Log:
gcc/
Backport from 2017-07-05 trunk r249995.
PR target/81305
* config/avr/avr.c (avr_out_movhi_mr_r_xmega) [CONSTANT_ADDRESS_P]:
Don't depend on "optimize > 0".
(out_movhi_r_mr, out_movqi_mr_r): Same.
(out_movhi_mr_r, out_movqi_r_mr): Same.
(avr_address_cost) [CONSTANT_ADDRESS_P]: Don't depend cost for
io_address_operand on "optimize > 0".
gcc/testsuite/
Backport from 2017-07-05 trunk r249995, r249996.
PR target/81305
* gcc.target/avr/isr-test.h: New file.
* gcc.target/avr/torture/isr-01-simple.c: New test.
* gcc.target/avr/torture/isr-02-call.c: New test.
* gcc.target/avr/torture/isr-03-fixed.c: New test.

Added:
branches/gcc-7-branch/gcc/testsuite/gcc.target/avr/isr-test.h
branches/gcc-7-branch/gcc/testsuite/gcc.target/avr/torture/isr-01-simple.c
branches/gcc-7-branch/gcc/testsuite/gcc.target/avr/torture/isr-02-call.c
branches/gcc-7-branch/gcc/testsuite/gcc.target/avr/torture/isr-03-fixed.c
Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/config/avr/avr.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug target/81305] [avr] avrtiny uses LDS for SREG in ISR routines which is out of range of LDS.

[gjl at gcc dot gnu.org]

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

--- Comment #2 from Georg-Johann Lay  ---
Author: gjl
Date: Wed Jul  5 12:34:36 2017
New Revision: 249996

URL: https://gcc.gnu.org/viewcvs?rev=249996=gcc=rev
Log:
gcc/
PR target/81305
* testsuite/gcc.target/avr/isr-test.h: New file.

Added:
trunk/gcc/testsuite/gcc.target/avr/isr-test.h
Modified:
trunk/gcc/ChangeLog

[Bug target/81305] [avr] avrtiny uses LDS for SREG in ISR routines which is out of range of LDS.

[gjl at gcc dot gnu.org]

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

--- Comment #1 from Georg-Johann Lay  ---
Author: gjl
Date: Wed Jul  5 12:28:19 2017
New Revision: 249995

URL: https://gcc.gnu.org/viewcvs?rev=249995=gcc=rev
Log:
gcc/
PR target/81305
* config/avr/avr.c (avr_out_movhi_mr_r_xmega) [CONSTANT_ADDRESS_P]:
Don't depend on "optimize > 0".
(out_movhi_r_mr, out_movqi_mr_r): Same.
(out_movhi_mr_r, out_movqi_r_mr): Same.
(avr_address_cost) [CONSTANT_ADDRESS_P]: Don't depend cost for
io_address_operand on "optimize > 0".
* testsuite/gcc.target/avr/torture/isr-01-simple.c: New test.
* testsuite/gcc.target/avr/torture/isr-02-call.c: New test.
* testsuite/gcc.target/avr/torture/isr-03-fixed.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/avr/torture/isr-01-simple.c
trunk/gcc/testsuite/gcc.target/avr/torture/isr-02-call.c
trunk/gcc/testsuite/gcc.target/avr/torture/isr-03-fixed.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/avr/avr.c

[Bug c++/58796] throw nullptr not caught by catch(type*)

[redi at gcc dot gnu.org]

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

--- Comment #21 from Jonathan Wakely  ---
I think this can be backported safely, maybe to gcc-5-branch too.

[Bug c++/81321] Segmentation fault - va_list boost_any - gcc5.4.0 - gcc-snapshot

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-07-05
 Ever confirmed|0   |1

--- Comment #3 from Jonathan Wakely  ---
I not sure this is valid, but GCC still shouldn't crash.

[Bug lto/68384] LTO error for global register variables in PHP 7 compiling on powerpc64le

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

   Last reconfirmed|2016-01-21 00:00:00 |2017-7-5
 CC||gjl at gcc dot gnu.org

--- Comment #11 from Georg-Johann Lay  ---
I am also seeing this on current trunk, even with -fno-toplevel-reorder.  Bit
annoying as this also comes up when testing GCC itself, at least if -flto is
part of the torture-options.

[Bug go/81324] New: libgo does not build with glibc 2.18

[segher at gcc dot gnu.org]

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

Bug ID: 81324
   Summary: libgo does not build with glibc 2.18
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: go
  Assignee: ian at airs dot com
  Reporter: segher at gcc dot gnu.org
CC: cmang at google dot com
  Target Milestone: ---

Since quite a while GCC fails building libgo:

In file included from /home/segher/src/gcc/libgo/sysinfo.c:109:0:
/usr/include/linux/ptrace.h:58:8: error: redefinition of 'struct
ptrace_peeksiginfo_args'
 struct ptrace_peeksiginfo_args {
^~~
In file included from /home/segher/src/gcc/libgo/sysinfo.c:66:0:
/usr/include/sys/ptrace.h:161:8: note: originally defined here
 struct ptrace_peeksiginfo_args
^~~
make[4]: *** No rule to make target `s-gen-sysinfo', needed by
`gen-sysinfo.go'.  Stop.

This is with glibc 2.18, on a powerpc64-linux system.

I disabled the include of  (it isn't needed) to
get further, since there was work on that same problem for ia64
(which I cannot find currently, sigh); but unfortunately the patch
that was committed is for ia64 only.

[Bug tree-optimization/49857] Put constant switch-tables into flash

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

  Component|target  |tree-optimization

--- Comment #14 from Georg-Johann Lay  ---
Please, this is (not only) a target issue.

As already mentioned, in order for the target to be able to generate correct
code, this needs a new target hook, hence byond "target".  Just putting the
tables in flash won't adjust the address spaces which is needed for correct
accesses.

[Bug bootstrap/80838] PGO/LTO bootstrapped compiler 5% slower than pure PGO bootstrapped one

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-07-05
 CC||hubicka at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #4 from Jan Hubicka  ---
The same slowdown is seen when compiling combine.ii, too, so it is not caused
by tramp3d not being representative.  With LTO:

 Performance counter stats for './xgcc -B ./ /aux/hubicka/combine.ii -O2 -S':

   6078.849031  task-clock (msec) #0.998 CPUs utilized
   616  context-switches  #0.101 K/sec
 2  cpu-migrations#0.000 K/sec
44,730  page-faults   #0.007 M/sec
18,048,640,894  cycles#2.969 GHz
 3,077,757,657  stalled-cycles-frontend   #   17.05% frontend cycles
idle
 5,647,264,874  stalled-cycles-backend#   31.29% backend  cycles
idle
14,751,268,913  instructions  #0.82  insns per cycle
  #0.38  stalled cycles per
insn
 3,221,027,271  branches  #  529.875 M/sec
   146,203,951  branch-misses #4.54% of all branches

   6.088293716 seconds time elapsed

Without LTO:

 Performance counter stats for './xgcc -B ./ /aux/hubicka/combine.ii -O2 -S':

   5815.257284  task-clock (msec) #0.998 CPUs utilized
   594  context-switches  #0.102 K/sec
 3  cpu-migrations#0.001 K/sec
44,736  page-faults   #0.008 M/sec
17,305,115,662  cycles#2.976 GHz
 2,736,627,618  stalled-cycles-frontend   #   15.81% frontend cycles
idle
 5,580,251,004  stalled-cycles-backend#   32.25% backend  cycles
idle
13,952,236,872  instructions  #0.81  insns per cycle
  #0.40  stalled cycles per
insn
 3,147,743,704  branches  #  541.291 M/sec
   145,597,831  branch-misses #4.63% of all branches

   5.824996172 seconds time elapsed


Sadly profile seems sufficiently flat to make it hard to work out what is going
on.  With LTO:
Samples: 24K of event 'cycles', Event count (approx.): 18314340157  
   2.67%  cc1plus  cc1plus[.] bitmap_set_bit
   1.53%  cc1plus  libc-2.19.so   [.] _int_malloc
   1.19%  cc1plus  cc1plus[.] df_worklist_dataflow
   1.07%  cc1plus  cc1plus[.] get_ref_base_and_extent
   1.05%  cc1plus  cc1plus[.] ggc_internal_alloc
   1.04%  cc1plus  cc1plus[.] bitmap_ior_into
   1.01%  cc1plus  cc1plus[.] pre_and_rev_post_order_compute_fn
   0.92%  cc1plus  cc1plus[.] lra_create_live_ranges_1
   0.86%  cc1plus  cc1plus[.] record_reg_classes
   0.82%  cc1plus  cc1plus[.] df_note_compute
   0.79%  cc1plus  cc1plus[.] bitmap_clear_bit
   0.65%  cc1plus  cc1plus[.] walk_tree_1
   0.63%  cc1plus  libc-2.19.so   [.] _int_free
   0.58%  cc1plus  cc1plus[.] fsm_find_thread_path
   0.57%  cc1plus  cc1plus[.] flags_from_decl_or_type
   0.56%  cc1plus  cc1plus[.] cleanup_cfg
   0.55%  cc1plus  cc1plus[.] wide_int_to_tree
   0.55%  cc1plus  cc1plus[.] df_live_bb_local_compute
   0.54%  cc1plus  cc1plus[.] et_set_father
   0.54%  cc1plus  cc1plus[.] bitmap_bit_p
   0.53%  cc1plus  cc1plus[.] bitmap_copy
   0.53%  cc1plus  cc1plus[.] operand_equal_p
   0.52%  cc1plus  cc1plus[.] sched_analyze_insn
   0.52%  cc1plus  cc1plus[.] reload_cse_simplify_operands
   0.51%  cc1plus  cc1plus[.] (anonymous
namespace)::dom_info::calc_idoms
   0.50%  cc1plus  cc1plus[.] cse_insn
   0.47%  cc1plus  [kernel.kallsyms]  [k] clear_page

Without LTO:

Samples: 23K of event 'cycles', Event count (approx.): 17586270321  
Overhead  Command  Shared Object  Symbol
   2.88%  cc1plus  cc1plus[.] bitmap_set_bit
   1.72%  cc1plus  libc-2.19.so   [.] _int_malloc
   1.05%  cc1plus  cc1plus[.] ggc_internal_alloc
   1.04%  cc1plus  cc1plus[.] get_ref_base_and_extent
   1.03%  cc1plus  cc1plus[.] pre_and_rev_post_order_compute_fn
   0.98%  cc1plus  cc1plus[.] lra_create_live_ranges_1
   0.97%  cc1plus  cc1plus[.] bitmap_ior_into
   0.88%  cc1plus  cc1plus[.] record_operand_costs
   0.82%  

[Bug target/80266] ICE in store_pairsi condition with -mabi=ilp32

[wilco at gcc dot gnu.org]

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

Wilco  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-07-05
 CC||wilco at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Wilco  ---
Confirmed. This is the same issue as:
https://gcc.gnu.org/ml/gcc-patches/2017-06/msg02422.html

Ada somehow generates SImode addresses for local variables which isn't correct.
This happens early on in Expand, eg for
testsuite/gnat.dg/abstract_with_anonymous_result.adb:

(insn 9 8 10 2 (set (reg:DI 403)
(plus:DI (reg/f:DI 68 virtual-stack-vars)
(const_int -368 [0xfe90]))) 
 (nil))
(insn 10 9 11 2 (set (reg:SI 404)
(plus:SI (subreg:SI (reg:DI 403) 0)
(const_int 56 [0x38]))) 
 (nil))
(insn 11 10 12 2 (set (reg:DI 405)
(plus:DI (reg/f:DI 68 virtual-stack-vars)
(const_int -368 [0xfe90]))) 
 (nil))
(insn 12 11 13 2 (set (reg:SI 406)
(subreg:SI (reg:DI 405) 0)) 
 (nil))
(insn 13 12 14 2 (set (mem/c:SI (reg:SI 404) [0  S4 A8])
(reg:SI 406)) 
 (nil))

[Bug ipa/81323] New: IPA-VRP doesn't handle return values

[jakub at gcc dot gnu.org]

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

Bug ID: 81323
   Summary: IPA-VRP doesn't handle return values
   Product: gcc
   Version: 7.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

__attribute__((noinline)) int foo (void)
{
  __builtin_printf ("foo\n");
  return 3;
}

int
bar (void)
{
  int x = foo ();
  return x >= 2 && x <= 4;
}

Shouldn't we be able to optimize bar to foo (); return 1; with -fipa-vrp or
-fipa-cp, at least when foo binds to the current definition (-fno-pic)?
If we have a constant or a value range for the return value, can't we use that
in the callers?

[Bug sanitizer/81322] New: -fsanitize=address ICE in prepare_function_start, at function.c

[zeccav at gmail dot com]

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

Bug ID: 81322
   Summary: -fsanitize=address ICE in prepare_function_start, at
function.c
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zeccav at gmail dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at 
gcc dot gnu.org
  Target Milestone: ---

/* from times-two.c.before-df.c */
/* in trunk 249883 */
/* must be compiled with option -fsanitize=address */
/* ICE in prepare_function_start, at function.c */
int __RTL (startwith ("rtl-dfinit")) times_two (int i)
{
(function "times_two"
  (insn-chain
(block 2
  (edge-from entry (flags "FALLTHRU"))
  (cnote 4 [bb 2] NOTE_INSN_BASIC_BLOCK)
  (edge-to exit (flags "FALLTHRU"))
) ;; block 2
  ) ;; insn-chain
) ;; function "times_two"
}
/* In function ‘_GLOBAL__sub_I_00099_0_times_two’:
 internal compiler error: in prepare_function_start, at function.c:4974
 }
 ^
0x5dd409 prepare_function_start
../../gcc-249883/gcc/function.c:4974
0x9bdded init_function_start(tree_node*)
../../gcc-249883/gcc/function.c:5050
0x89661b cgraph_node::expand()
../../gcc-249883/gcc/cgraphunit.c:2036
0x896c47 cgraph_node::add_new_function(tree_node*, bool)
../../gcc-249883/gcc/cgraphunit.c:586
0xaa06dd cgraph_build_static_cdtor_1
../../gcc-249883/gcc/ipa.c:936
0xc7a3b6 asan_finish_file()
../../gcc-249883/gcc/asan.c:2727
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
*/

[Bug target/81295] bootstrap broken on powerpc-linux-gnu with --enable-default-pie

[doko at gcc dot gnu.org]

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

Matthias Klose  changed:

   What|Removed |Added

Summary|[7 Regression] bootstrap|bootstrap broken on
   |broken on powerpc-linux-gnu |powerpc-linux-gnu with
   |with --enable-default-pie   |--enable-default-pie

--- Comment #10 from Matthias Klose  ---
also seen on the trunk, and because --enable-default-pie is new, not a
regression.

[Bug tree-optimization/81309] [8 regression] gcc.dg/vect/pr79347.c FAILs

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

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

--- Comment #2 from Rainer Orth  ---
(In reply to rguent...@suse.de from comment #1)

> I think Honza fixed this with
> 
> 2017-07-03  Jan Hubicka  
> 
> * tree-vect-loop-manip.c (vect_do_peeling): Fix scaling up.

Indeed, I missed that.  Sorry for the noise.

  Rainer

[Bug target/81295] [7 Regression] bootstrap broken on powerpc-linux-gnu with --enable-default-pie

[doko at gcc dot gnu.org]

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

Matthias Klose  changed:

   What|Removed |Added

 CC||amodra at gcc dot gnu.org
Summary|[7 Regression] bootstrap|[7 Regression] bootstrap
   |broken on powerpc-linux-gnu |broken on powerpc-linux-gnu
   ||with --enable-default-pie

--- Comment #9 from Matthias Klose  ---
looks like --enable-default-pie is the option triggering the build failure. Can
also be seen on the gcc-6-branch (with a backported option).  Applying the
patch proposed for PR80044 [1] lets the bootstrap succeed with
--enable-default-pie.

[1] https://gcc.gnu.org/ml/gcc-patches/2017-06/msg01678.html

[Bug target/79636] [5/6/7/8 Regression] ICE in assign_by_spills, at lra-assigns.c:1457

[zeccav at gmail dot com]

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

Vittorio Zecca  changed:

   What|Removed |Added

 CC||zeccav at gmail dot com

--- Comment #3 from Vittorio Zecca  ---
Still in trunk 249883:

/* from pr65693.c */
/* in trunk 249883 */
/* internal compiler error: in assign_by_spills, at lra-assigns.c */
void
foo (int (*fn) (int, int, int), unsigned int b)
{
  unsigned long *c = (unsigned long *) __builtin_alloca (b);
  register int d asm ("edx") = fn (0, 0, d);
}
/*
 * p.c: In function ‘foo’:
error: unable to find a register to spill
 }
 ^
error: this is the insn:
(insn 11 31 12 2 (parallel [
(set (reg:DI 94)
(udiv:DI (reg:DI 92)
(reg:DI 103)))
(set (reg:DI 104 [95])
(umod:DI (reg:DI 92)
(reg:DI 103)))
(clobber (reg:CC 17 flags))
]) "p.c":7 370 {*udivmoddi4}
 (expr_list:REG_UNUSED (reg:DI 104 [95])
(expr_list:REG_DEAD (reg:DI 103)
(expr_list:REG_DEAD (reg:DI 92)
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil))
during RTL pass: reload
internal compiler error: in assign_by_spills, at lra-assigns.c:1476
0x6216cc _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../gcc-249883/gcc/rtl-error.c:108
0xaf2f5e assign_by_spills
../../gcc-249883/gcc/lra-assigns.c:1476
0xaf4276 lra_assign()
../../gcc-249883/gcc/lra-assigns.c:1670
0xaef29c lra(_IO_FILE*)
../../gcc-249883/gcc/lra.c:2451
0xaa7281 do_reload
../../gcc-249883/gcc/ira.c:5440
0xaa7281 execute
../../gcc-249883/gcc/ira.c:5624
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
*/

[Bug c++/81321] Segmentation fault - va_list boost_any - gcc5.4.0 - gcc-snapshot

[rmx12133 at gmail dot com]

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

--- Comment #2 from Stephan Heinrich  ---
Created attachment 41685
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41685=edit
preprocessed

[Bug c++/81321] Segmentation fault - va_list boost_any - gcc5.4.0 - gcc-snapshot

[rmx12133 at gmail dot com]

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

--- Comment #1 from Stephan Heinrich  ---
Created attachment 41684
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41684=edit
source code

[Bug c++/81321] New: Segmentation fault - va_list boost_any - gcc5.4.0 - gcc-snapshot

[rmx12133 at gmail dot com]

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

Bug ID: 81321
   Summary: Segmentation fault - va_list boost_any - gcc5.4.0 -
gcc-snapshot
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rmx12133 at gmail dot com
  Target Milestone: ---

Created attachment 41683
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41683=edit
preprocessed (-save-temps)

Hello,
I tried multiple gcc versions (gcc-snapshot, gcc4, gcc5) with the same result.
gcc prints "internal compiler error: Segmentation fault" when i try to compile
this code:

/*###*/
#include 
#include 

void callb(const boost::any& value1) {}

void calla(std::va_list l) {
callb(l);
}
/*###*/

by this command: gcc -v -save-temps input.cpp

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
5.4.0-6ubuntu1~16.04.4' --with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs
--enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-5 --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
--disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-amd64/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686
--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 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-mtune=generic' '-march=x86-64'
 /usr/lib/gcc/x86_64-linux-gnu/5/cc1plus -E -quiet -v -imultiarch
x86_64-linux-gnu -D_GNU_SOURCE input.cpp -mtune=generic -march=x86-64
-fpch-preprocess -fstack-protector-strong -Wformat -Wformat-security -o
input.ii
ignoring duplicate directory "/usr/include/x86_64-linux-gnu/c++/5"
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-linux-gnu/5/../../../../x86_64-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/include/c++/5
 /usr/include/x86_64-linux-gnu/c++/5
 /usr/include/c++/5/backward
 /usr/lib/gcc/x86_64-linux-gnu/5/include
 /usr/local/include
 /usr/lib/gcc/x86_64-linux-gnu/5/include-fixed
 /usr/include/x86_64-linux-gnu
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-mtune=generic' '-march=x86-64'
 /usr/lib/gcc/x86_64-linux-gnu/5/cc1plus -fpreprocessed input.ii -quiet
-dumpbase input.cpp -mtune=generic -march=x86-64 -auxbase input -version
-fstack-protector-strong -Wformat -Wformat-security -o input.s
GNU C++ (Ubuntu 5.4.0-6ubuntu1~16.04.4) version 5.4.0 20160609
(x86_64-linux-gnu)
compiled by GNU C version 5.4.0 20160609, GMP version 6.1.0, MPFR
version 3.1.4, MPC version 1.0.3
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++ (Ubuntu 5.4.0-6ubuntu1~16.04.4) version 5.4.0 20160609
(x86_64-linux-gnu)
compiled by GNU C version 5.4.0 20160609, GMP version 6.1.0, MPFR
version 3.1.4, MPC version 1.0.3
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: c3fdb80f2154421ceaf9e22c85325a8d
input.cpp:14:1: internal compiler error: Segmentation fault
 }
 ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug middle-end/81320] New: [7/8] -Wlogical-op diagnostic depends on comparison' order

[dimhen at gmail dot com]

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

Bug ID: 81320
   Summary: [7/8] -Wlogical-op diagnostic depends on comparison'
order
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dimhen at gmail dot com
  Target Milestone: ---

r247015 FAIL
r249982 FAIL

$ cat x.c
int f1(int i)
{
if( i == 0 ||
i == 0 || /* PRESENT warning */
i == 1  )
return 0;
else
return 1;
}

int f2(int i)
{
if( i == 0 ||
i == 1 ||
i == 0)   /* MISS warning */
return 0;
else
return 1;
}

$ /usr/local/gcc_current/bin/gcc -Wall -Wextra -O -Wlogical-op -c x.c
x.c: In function ‘f1’:
x.c:3:16: warning: logical ‘or’ of equal expressions [-Wlogical-op]
 if( i == 0 ||
^~
$ /usr/local/gcc_current/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/usr/local/gcc_current/bin/gcc
COLLECT_LTO_WRAPPER=/usr/local/gcc_current/libexec/gcc/x86_64-pc-linux-gnu/8.0.0/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
Target: x86_64-pc-linux-gnu
Configured with: /home/dimhen/src/gcc_current/configure
--prefix=/usr/local/gcc_current --enable-checking=yes,df,fold,rtl
--enable-languages=c,c++,lto --disable-multilib --enable-shared
--enable-threads=posix --enable-__cxa_atexit --disable-libunwind-exceptions
--enable-gnu-unique-object --enable-linker-build-id
--with-linker-hash-style=gnu --enable-plugin --enable-initfini-array --with-isl
--enable-libmpx --enable-offload-targets=nvptx-none --without-cuda-driver
--enable-gnu-indirect-function --with-tune=generic
Thread model: posix
gcc version 8.0.0 20170705 (experimental) [trunk revision 249982] (GCC)

[Bug c/81319] New: ICE in output_operand_lossage at final.c

[zeccav at gmail dot com]

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

Bug ID: 81319
   Summary: ICE in output_operand_lossage at final.c
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zeccav at gmail dot com
  Target Milestone: ---

/* from shrink-wrap-separate-0.c */
/* in trunk 249883 */
/* ICE in output_operand_lossage at final.c */
void f(int x)
{
register int r20 asm("20") = x;
}
/*
 * In function ‘f’:
error: frame cannot be used in asm here
 }
 ^
during RTL pass: final
internal compiler error: output_operand: invalid use of register 'frame'
0x975982 output_operand_lossage(char const*, ...)
../../gcc-249883/gcc/final.c:3459
0xf9a37c ix86_print_operand(_IO_FILE*, rtx_def*, int)
../../gcc-249883/gcc/config/i386/i386.c:19181
0x975c71 output_operand(rtx_def*, int)
../../gcc-249883/gcc/final.c:3893
0x97670f output_asm_insn(char const*, rtx_def**)
../../gcc-249883/gcc/final.c:3809
0x9777d7 final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*)
../../gcc-249883/gcc/final.c:3060
0x978cca final(rtx_insn*, _IO_FILE*, int)
../../gcc-249883/gcc/final.c:2053
0x979099 rest_of_handle_final
../../gcc-249883/gcc/final.c:4494
0x979099 execute
../../gcc-249883/gcc/final.c:4567
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug middle-end/81318] New: [8 regression] ICE in to_reg_br_prob_base, at profile-count.h:189

[dimhen at gmail dot com]

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

Bug ID: 81318
   Summary: [8 regression] ICE in to_reg_br_prob_base, at
profile-count.h:189
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dimhen at gmail dot com
  Target Milestone: ---

r249892 PASS
r249961 (?) FAIL / sadly, I rm this version from HDD & cant double-check
r249982 FAIL

$ cat x.i
__attribute__((__cold__)) int a();
inline int b() { a(); }
int c() { b(); }

$ /usr/local/gcc_current/bin/gcc -fpreprocessed -O -c x.i
during GIMPLE pass: profile_estimate
x.i: In function ‘c’:
x.i:3:1: internal compiler error: in to_reg_br_prob_base, at
profile-count.h:189
 int c() { b(); }
 ^~~
0x69298d profile_probability::to_reg_br_prob_base() const
/home/dimhen/src/gcc_current/gcc/profile-count.h:189
0x69298d estimate_bb_frequencies(bool)
/home/dimhen/src/gcc_current/gcc/predict.c:3559
0xdb373f tree_estimate_probability(bool)
/home/dimhen/src/gcc_current/gcc/predict.c:2828
0xdb3a93 execute
/home/dimhen/src/gcc_current/gcc/predict.c:3701
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

$ /usr/local/gcc_current/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/usr/local/gcc_current/bin/gcc
COLLECT_LTO_WRAPPER=/usr/local/gcc_current/libexec/gcc/x86_64-pc-linux-gnu/8.0.0/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
Target: x86_64-pc-linux-gnu
Configured with: /home/dimhen/src/gcc_current/configure
--prefix=/usr/local/gcc_current --enable-checking=yes,df,fold,rtl
--enable-languages=c,c++,lto --disable-multilib --enable-shared
--enable-threads=posix --enable-__cxa_atexit --disable-libunwind-exceptions
--enable-gnu-unique-object --enable-linker-build-id
--with-linker-hash-style=gnu --enable-plugin --enable-initfini-array --with-isl
--enable-libmpx --enable-offload-targets=nvptx-none --without-cuda-driver
--enable-gnu-indirect-function --with-tune=generic
Thread model: posix
gcc version 8.0.0 20170705 (experimental) [trunk revision 249982] (GCC)

[Bug middle-end/80328] With -ffloat-store std::array operator[] no longer cost-free

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||documentation
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-07-05
 Ever confirmed|0   |1
   Severity|normal  |enhancement

--- Comment #4 from Andrew Pinski  ---
Maybe the documentation for -ffloat-store could be clearer that a return value
is considered a variable here.