[Bug c++/80290] [6/7/8 Regression] g++ uses unreasonable amount of memory compiling nested string maps

[aoliva at gcc dot gnu.org]

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

--- Comment #21 from Alexandre Oliva  ---
Author: aoliva
Date: Wed Apr 18 05:17:26 2018
New Revision: 259457

URL: https://gcc.gnu.org/viewcvs?rev=259457=gcc=rev
Log:
[PR c++/80290] recycle tinst garbage sooner

tinst_level objects are created during template instantiation, and
they're most often quite short-lived, but since there's no intervening
garbage collection, they accumulate throughout the pass while most by
far could be recycled after a short while.  The original testcase in
PR80290, for example, creates almost 55 million tinst_level objects,
all but 10 thousand of them without intervening GC, but we don't need
more than 284 of them live at a time.

Furthermore, in many cases, TREE_LIST objects are created to stand for
the decl in tinst_level.  In most cases, those can be recycled as soon
as the tinst_level object is recycled; in some relatively common
cases, they are modified and reused in up to 3 tinst_level objects.
In the same testcase, TREE_LISTs are used in all but 3 thousand of the
tinst_level objects, and we don't need more than 89 tinst_level
objects with TREE_LISTs live at a time.  Furthermore, all but 2
thousand of those are created without intervening GC.

This patch arranges for tinst_level objects to be refcounted (I've
seen as many as 20 live references to a single tinst_level object in
my testing), and for pending_template, tinst_level and TREE_LIST
objects that can be recycled to be added to freelists; that's much
faster than ggc_free()ing them and reallocating them shortly
thereafter.  In fact, the introduction of such freelists is what makes
this entire patch lighter-weight, when it comes to memory use, and
faster.  With refcounting alone, the total memory footprint was still
about the same, and we spent more time.

In order to further reduce memory use, I've arranged for us to create
TREE_LISTs lazily, only at points that really need them (when printing
error messages).  This grows tinst_level by an additional pointer, but
since a TREE_LIST holds a lot more than an extra pointer, and
tinst_levels with TREE_LISTs used to be allocated tens of thousands of
times more often than plain decl ones, we still save memory overall.

I was still not quite happy about growing memory use in cases that
used template classes but not template overload resolution, so I
changed the type of the errors field to unsigned short, from int.
With that change, in_system_header_p and refcount move into the same
word or half-word that used to hold errors, releasing a full word,
bringing tinst_level back to its original size, now without any
padding.

The errors field is only used to test whether we've had any errors
since the expansion of some template, to skip the expansion of further
templates.  If we get 2^16 errors or more, it is probably reasonable
to refrain from expanding further templates, even if we would expand
them before this change.

With these changes, compile time for the original testcase at -O0,
with default checking enabled, is cut down by some 3.7%, total GCable
memory allocation is cut down by almost 20%, and total memory use (as
reported by GNU time as maxresident) is cut down by slightly over 15%.


for  gcc/cp/ChangeLog

PR c++/80290
* cp-tree.h (struct tinst_level): Split decl into tldcl and
targs.  Add private split_list_p, tree_list_p, and not_list_p
inline const predicates; to_list private member function
declaration; free public member function declaration; list_p,
get_node and maybe_get_node accessors, and refcount data
member.  Narrow errors to unsigned short.
* error.c (print_instantiation_full_context): Use new
accessors.
(print_instantiation_partial_context_line): Likewise.  Drop
const from tinst_level-typed parameter.
* mangle.c (mangle_decl_string): Likewise.
* pt.c (freelist): New template class.
(tree_list_freelist_head): New var.
(tree_list_freelist): New fn, along with specializations.
(tinst_level_freelist_head): New var.
(pending_template_freelist_head): Likewise.
(tinst_level_freelist, pending_template_freelist): New fns.
(tinst_level::to_list, tinst_level::free): Define.
(inc_refcount_use, dec_refcount_use): New fns for tinst_level.
(set_refcount_ptr): New template fn.
(add_pending_template): Adjust for refcounting, freelists and
new accessors.
(neglectable_inst_p): Take a NULL d as a non-DECL.
(limit_bad_template_recursion): Use new accessors.
(push_tinst_level): New overload to create the list.
(push_tinst_level_loc): Make it static, split decl into two
args, adjust tests and initialization to cope with split
lists, use freelist, adjust for refcounting.
(push_tinst_level_loc): New wrapper with the old interface.
(pop_tinst_level): Adjust for refcounting.

[Bug target/35363] Missing bit field coalescing optimization

[pinskia at gcc dot gnu.org]

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

--- Comment #8 from Andrew Pinski  ---
There are two issues here, one is SLOW_BYTE_ACCESS and the second is the
lowering of bit-fields.  I am going to fix the lower part for GCC 9.  The
SLOW_BTYE_ACCESS was being looked at by someone else in the recent past but I
can't find the email about it.

[Bug c++/85437] [8 Regression] member pointer static upcast rejected in a constexpr context

[aoliva at gcc dot gnu.org]

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

Alexandre Oliva  changed:

   What|Removed |Added

 CC||aoliva at gcc dot gnu.org

--- Comment #6 from Alexandre Oliva  ---
FTR, there's a patch with various caveats at
https://gcc.gnu.org/ml/gcc-patches/2018-04/msg00852.html

[Bug bootstrap/82037] Debian 8.8 powerpc64-unknown-linux-gnu bootstrap breaks in stage1 with gcc/liblto_plugin.so: wrong ELF class: ELFCLASS64

[dclarke at blastwave dot org]

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

--- Comment #10 from Dennis Clarke  ---
Can we close this as a non-issue?

[Bug web/82686] Debian sid powerpc64-unknown-linux-gnu 4.13.0-1-powerpc64 bootstrap breaks in stage3 with unexpected requirement for bdw-gc

[dclarke at blastwave dot org]

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

--- Comment #16 from Dennis Clarke  ---
Can we close this as a non-issue?

[Bug libquadmath/85440] libquadmath and quadmath.h do not exist on ppc64

[dclarke at blastwave dot org]

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

--- Comment #2 from Dennis Clarke  ---
Thank you very much Sir! 

So then .. where is this gcc 8 that you speak of ?  Still just a
nightly test release or is there an actual tarball hidden away?

[Bug libstdc++/84442] FAIL: 30_threads/thread/cons/terminate.cc (test for excess errors)

[dave.anglin at bell dot net]

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

--- Comment #5 from dave.anglin at bell dot net ---
On 2018-04-17 10:21 AM, redi at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84442
>
> --- Comment #4 from Jonathan Wakely  ---
> Dave, does the patch in comment 3 fix the FAIL?
>
Yes, it fixes the fail.

Thanks,
Dave

[Bug c++/85444] asm specifier on typedef silently ignored

[whh8b at virginia dot edu]

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

--- Comment #1 from Will Hawkins  ---
Created attachment 43971
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43971=edit
Example that triggers the newly added warning when compiled with -Wpedantic

Example that triggers the newly added warning when compiled with -Wpedantic

[Bug c++/85444] New: asm specifier on typedef silently ignored

[whh8b at virginia dot edu]

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

Bug ID: 85444
   Summary: asm specifier on typedef silently ignored
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: whh8b at virginia dot edu
  Target Milestone: ---

Created attachment 43970
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43970=edit
Patch to add warning for ignored asm specifiers.

In a declaration like

typedef struct {} x asm ("X");

the asm label is properly ignored but the user is not alerted to this. 

I am attaching a patch that will add a warning at -Wpedantic to alert the user
in a case such as this. 

This is the first time that I am submitting a patch to GCC and I am really
nervous about making sure that I followed the proper protocol. I am sure that
there are plenty of things that I am missing but I look forward to cleaning it
up and learning the process.

Thanks for your patience!

[Bug go/85429] Several gotools tests FAIL with Solaris as

[ian at airs dot com]

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

--- Comment #1 from Ian Lance Taylor  ---
Does the SPARC Solaris assembler support a syntax like

.section ".go.buildid",#exclude

?  That's what gas seems to support for compatibility.

Does that syntax work for x86?

[Bug libstdc++/85442] [8 Regression] cxx11-ios_failure.lo build fails for microblaze

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
Created attachment 43969
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43969=edit
gcc8-pr85442.patch

Perhaps we want to assemble with -g0, because either the .s file already
contains debug info from the compiler and then we don't want to add one from
the assembler, or the user doesn't want debug info at all.

Completely untested though.

[Bug libquadmath/85440] libquadmath and quadmath.h do not exist on ppc64

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
If you want libquadmath with powerpc* support, you need GCC 8 or later.

[Bug c/85443] New: internal compiler error: Segmentation fault

[xvl5190 at psu dot edu]

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

Bug ID: 85443
   Summary: internal compiler error: Segmentation fault
   Product: gcc
   Version: 5.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: xvl5190 at psu dot edu
  Target Milestone: ---

This is the code that triggers the crash:

char acDummy[0xf0] __attribute__ ((__BELOW100__));
unsigned short B100 __attribute__ ((__BELOW100__));
unsigned short *p = 

unsigned short wData = 0x1234;
_Atomic int i = 3; 
int a1 = sizeof (i + 1); 

void
Do (void)
{
  B100 = wData;
}

int
main (void)
{
  *p = 0x9876;
  Do ();
  return (*p == 0x1234) ? 0 : 1;
}

[Bug debug/84637] gcc/dbxout.c:684:14: runtime error: negation of -9223372036854775808 cannot be represented in type 'long int'; cast to an unsigned type to negate this value to itself

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug other/63426] [meta-bug] Issues found with -fsanitize=undefined

[jakub at gcc dot gnu.org]

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

Bug 84637 Summary: gcc/dbxout.c:684:14: runtime error: negation of 
-9223372036854775808 cannot be represented in type 'long int'; cast to an 
unsigned type to negate this value to itself
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84637

   What|Removed |Added

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

[Bug debug/84637] gcc/dbxout.c:684:14: runtime error: negation of -9223372036854775808 cannot be represented in type 'long int'; cast to an unsigned type to negate this value to itself

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Tue Apr 17 22:18:47 2018
New Revision: 259451

URL: https://gcc.gnu.org/viewcvs?rev=259451=gcc=rev
Log:
PR debug/84637
* dbxout.c (dbxout_int): Perform negation in unsigned int type.
(stabstr_D): Change type of unum from unsigned int to
unsigned HOST_WIDE_INT.  Perform negation in unsigned HOST_WIDE_INT
type.

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

[Bug sanitizer/85394] [8 Regression] Unable to run sanitized executables on ppc64le Ubuntu and SLES

[seurer at gcc dot gnu.org]

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

seurer at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #3 from seurer at gcc dot gnu.org ---
I tested the patch Jakub shows and it works fine on powerpc64 with kernels
ranging from 2.6 to 4.13.

[Bug bootstrap/84856] Bootstrap failure on riscv: comparison of integer expressions of different signedness

[wilson at gcc dot gnu.org]

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

--- Comment #10 from Jim Wilson  ---
Author: wilson
Date: Tue Apr 17 21:41:07 2018
New Revision: 259449

URL: https://gcc.gnu.org/viewcvs?rev=259449=gcc=rev
Log:
RISC-V: Fix 32-bit stack pointer alignment problem.

gcc/
PR 84856
* config/riscv/riscv.c (riscv_compute_frame_info): Add calls to
RISCV_STACK_ALIGN when using outgoing_args_size and pretend_args_size.
Set arg_pointer_offset after using pretend_args_size.

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

[Bug rtl-optimization/85431] UBSAN: ../../gcc/dse.c:303:15: runtime error: shift exponent 64 is too large for 64-bit type 'long unsigned int'

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Author: jakub
Date: Tue Apr 17 21:38:45 2018
New Revision: 259448

URL: https://gcc.gnu.org/viewcvs?rev=259448=gcc=rev
Log:
PR rtl-optimization/85431
* dse.c (record_store): Ignore zero width stores.

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

[Bug rtl-optimization/85431] UBSAN: ../../gcc/dse.c:303:15: runtime error: shift exponent 64 is too large for 64-bit type 'long unsigned int'

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug other/63426] [meta-bug] Issues found with -fsanitize=undefined

[jakub at gcc dot gnu.org]

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

Bug 85431 Summary: UBSAN: ../../gcc/dse.c:303:15: runtime error: shift exponent 
64 is too large for 64-bit type 'long unsigned int'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85431

   What|Removed |Added

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

[Bug libstdc++/85442] New: [8 Regression] cxx11-ios_failure.lo build fails for microblaze

[jsm28 at gcc dot gnu.org]

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

Bug ID: 85442
   Summary: [8 Regression] cxx11-ios_failure.lo build fails for
microblaze
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jsm28 at gcc dot gnu.org
CC: redi at gcc dot gnu.org
  Target Milestone: ---
Target: microblaze-linux-gnu

My glibc bot building with build-many-glibcs.py shows the libstdc++ build
failing for microblaze:

https://sourceware.org/ml/libc-testresults/2018-q2/msg00051.html

cxx11-ios_failure-lt.s: Assembler messages:
cxx11-ios_failure-lt.s: Fatal error: duplicate .debug_line sections
Makefile:766: recipe for target 'cxx11-ios_failure.lo' failed
make[6]: *** [cxx11-ios_failure.lo] Error 1

Introduced by r259281.  I don't know whether this is a bug in the microblaze
compiler or in the special makefile code that generates this .s file.

[Bug fortran/84640] gcc/fortran/simplify.c:2587:9: runtime error: pointer index expression with base 0x0000090de160 overflowed to 0xffffffffc0632960

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||tkoenig at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |tkoenig at gcc dot 
gnu.org
   Target Milestone|--- |9.0
   Severity|normal  |enhancement

--- Comment #3 from Thomas Koenig  ---
(In reply to Martin Liška from comment #2)

> So rptr points to an invalid memory. Question is whether a store/load from
> the address can happen?

No; rptr never stores to anywhere afterwards.

However, I concur that it would be a good idea to clean up the
logic for this part so that invalid pointers are never
even generated.

Something to look at for gcc 9.

[Bug target/85434] Address of stack protector guard spilled to stack on ARM

[wilco at gcc dot gnu.org]

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

Wilco  changed:

   What|Removed |Added

 CC||wilco at gcc dot gnu.org

--- Comment #4 from Wilco  ---

Clearly rematerialization isn't working correctly. Immediates and constant
addresses like this should never be spilled (using MOV/MOVK could increase
codesize, but with -Os you should use the literal pool anyway). Check
legitimate_constant_p returns true, see
https://gcc.gnu.org/ml/gcc-patches/2017-08/msg00052.html for how it's done on
AArch64.

[Bug testsuite/85326] `make check` fails with `--disable-bootstrap` and `--enable-languages=c`

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  ---
Author: jakub
Date: Tue Apr 17 20:43:49 2018
New Revision: 259447

URL: https://gcc.gnu.org/viewcvs?rev=259447=gcc=rev
Log:
PR testsuite/85326
* g++.dg/other/pr81422.C: Require effective target tls and c++11.
* g++.dg/other/pr60675.C: Likewise.  Remove -std=c++11 from dg-options.
* g++.dg/other/sve_tls_2.C: Require effective target tls.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/other/pr60675.C
trunk/gcc/testsuite/g++.dg/other/pr81422.C
trunk/gcc/testsuite/g++.dg/other/sve_tls_2.C

[Bug target/85436] [7 Regression] ICE compiling go code with -mcpu=power9

[bergner at gcc dot gnu.org]

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

Peter Bergner  changed:

   What|Removed |Added

  Attachment #43964|0   |1
is obsolete||
  Attachment #43966|0   |1
is obsolete||

--- Comment #2 from Peter Bergner  ---
Created attachment 43968
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43968=edit
An even smaller test case

This is a one function test case which helps reading the rtl dumps

[Bug sanitizer/85230] asan: false positives in kernel on allocas

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-04-17
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #23 from Jakub Jelinek  ---
Fixed for 8+ so far, backports will come later.

[Bug sanitizer/85230] asan: false positives in kernel on allocas

[jakub at gcc dot gnu.org]

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

--- Comment #22 from Jakub Jelinek  ---
Author: jakub
Date: Tue Apr 17 20:22:50 2018
New Revision: 259446

URL: https://gcc.gnu.org/viewcvs?rev=259446=gcc=rev
Log:
PR sanitizer/85230
* asan.c (handle_builtin_stack_restore): Adjust comment.  Emit
__asan_allocas_unpoison call and last_alloca_addr = new_sp before
__builtin_stack_restore rather than after it.
* builtins.c (expand_asan_emit_allocas_unpoison): Pass
arg1 + (virtual_dynamic_stack_rtx - stack_pointer_rtx) as second
argument instead of virtual_dynamic_stack_rtx.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/asan.c
trunk/gcc/builtins.c

[Bug go/84948] [8 regression] ICE in set_from, at go/gofrontend/types.cc:2660

[ian at airs dot com]

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

--- Comment #1 from Ian Lance Taylor  ---
That is just the start of the problem.  The garbage collector assumes that all
pointers are aligned to their natural boundary.  That is, it expects that on a
system with four byte pointers, they are always aligned to a four byte boundary
when stored in memory.  The garbage collector's data structures are designed
around that assumption.  That will be hard to change.

[Bug c++/84630] [6/7/8 Regression] ICE: TYPE_NAME() used on error_mark_node in tsubst_lambda_expr, at cp/pt.c:17141

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |paolo.carlini at oracle 
dot com

--- Comment #3 from Paolo Carlini  ---
Seems easy.

[Bug target/85430] [7/8 Regression] ICE: SIGSEGV in memory_operand at recog.c:1358 with -O2 -fno-tree-ccp -fno-tree-fre

[zsojka at seznam dot cz]

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

--- Comment #4 from Zdenek Sojka  ---
Observation about generated code:
$ x86_64-pc-linux-gnu-gcc -O2 -fno-tree-ccp -fno-tree-fre testcase.c -S -o-
...
foo:
movl%edi, %eax
addb%al, %al
ret
...

which looks superior to code generated by -O1/-O2/-O3/-Os/-Og :
...
foo:
movsbl  %dil, %edx
addl%edx, %edx
movl%edi, %eax
movb%dl, %al
ret
...

[Bug c++/85441] Empty loops not optimised away

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||compile-time-hog,
   ||memory-hog
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-04-17
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
You didn't use any optimization flags, so nothing is optimized away.

But it should be possible to skip evaluation of empty loops inside constant
expression evaluation.

[Bug target/85424] The __builtin_packlongdouble function might have issues with the output overlapping the inputs

[meissner at gcc dot gnu.org]

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

--- Comment #1 from Michael Meissner  ---
Author: meissner
Date: Tue Apr 17 18:22:08 2018
New Revision: 259441

URL: https://gcc.gnu.org/viewcvs?rev=259441=gcc=rev
Log:
2018-04-17  Michael Meissner  

PR target/85424
* config/rs6000/rs6000.md (pack): Do not try handle a pack
where the inputs overlap with the output.


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

[Bug web/82686] Debian sid powerpc64-unknown-linux-gnu 4.13.0-1-powerpc64 bootstrap breaks in stage3 with unexpected requirement for bdw-gc

[dclarke at blastwave dot org]

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

--- Comment #15 from Dennis Clarke  ---
The real issue here is libquadmath which seems to be based 
on sources from Sun Microsystems software implementation of
the 128-bit floating point operations. 

see 85440

[Bug rtl-optimization/84842] [7/8 Regression] ICE in verify_target_availability, at sel-sched.c:1569

[amonakov at gcc dot gnu.org]

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

Alexander Monakov  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-04-17
 Ever confirmed|0   |1

--- Comment #11 from Alexander Monakov  ---
Thanks, I managed to reproduce it. The unusual thing here is hardreg 63 being
considered call-clobbered in its reg_raw_mode=TImode but not narrower modes. We
have

(insn 97 29 98 4 (set (reg:DI 63 31 [160])
(unspec:DI [
(reg:SI 29 29)
] UNSPEC_LFIWAX)) "pr84842.i":5 344 {lfiwax}
 (expr_list:REG_DEAD (reg:SI 29 29)
(nil)))

and sched-deps noting a REG_DEP_OUTPUT dependence on regno 63 against a
preceding call insn according to rs6000_hard_regno_call_part_clobbered
(regno=63, mode=E_TImode). I assume what the backend in conveying there is that
only the low part of the register will be preserved by callees.

However, when we move up the instruction we don't have a dependence. The LHS is
DImode, so that seems correct as well: sched-deps had a more conservative
answer because its dependence lists are not separated per mode.

Andrey, does the above make sense? Can the assert be relaxed?

[Bug c++/85441] New: Empty loops not optimised away

[sebastian321123 at interia dot pl]

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

Bug ID: 85441
   Summary: Empty loops not optimised away
   Product: gcc
   Version: 7.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sebastian321123 at interia dot pl
  Target Milestone: ---

This code compiles for a long time and has high memory usage (roughly 2GiB). I
suspect that empty loops are not removed.

Code:

constexpr double foo(const unsigned int N) {
for (unsigned int i = 0; i != N; ++i) {
for (unsigned int i = 0; i != N; ++i) {
}
}
return 7;
}

int main() {
return foo(4393u);
}

Command line:

$ time env g++ -v --std=c++14 foo.cpp -o foo
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/7.3.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib
--libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared
--enable-threads=posix --enable-libmpx --with-system-zlib --with-isl
--enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu
--disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object
--enable-linker-build-id --enable-lto --enable-plugin
--enable-install-libiberty --with-linker-hash-style=gnu
--enable-gnu-indirect-function --enable-multilib --disable-werror
--enable-checking=release --enable-default-pie --enable-default-ssp
Thread model: posix
gcc version 7.3.1 20180312 (GCC) 
COLLECT_GCC_OPTIONS='-v' '-std=c++14' '-o' 'foo' '-shared-libgcc'
'-mtune=generic' '-march=x86-64'
 /usr/lib/gcc/x86_64-pc-linux-gnu/7.3.1/cc1plus -quiet -v -D_GNU_SOURCE foo.cpp
-quiet -dumpbase foo.cpp -mtune=generic -march=x86-64 -auxbase foo -std=c++14
-version -o /tmp/cc3hVZ3b.s
GNU C++14 (GCC) version 7.3.1 20180312 (x86_64-pc-linux-gnu)
compiled by GNU C version 7.3.1 20180312, GMP version 6.1.2, MPFR
version 4.0.1, MPC version 1.1.0, isl version isl-0.18-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-pc-linux-gnu/7.3.1/../../../../x86_64-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/x86_64-pc-linux-gnu/7.3.1/../../../../include/c++/7.3.1

/usr/lib/gcc/x86_64-pc-linux-gnu/7.3.1/../../../../include/c++/7.3.1/x86_64-pc-linux-gnu
 /usr/lib/gcc/x86_64-pc-linux-gnu/7.3.1/../../../../include/c++/7.3.1/backward
 /usr/lib/gcc/x86_64-pc-linux-gnu/7.3.1/include
 /usr/local/include
 /usr/lib/gcc/x86_64-pc-linux-gnu/7.3.1/include-fixed
 /usr/include
End of search list.
GNU C++14 (GCC) version 7.3.1 20180312 (x86_64-pc-linux-gnu)
compiled by GNU C version 7.3.1 20180312, GMP version 6.1.2, MPFR
version 4.0.1, MPC version 1.1.0, isl version isl-0.18-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 3fb60f63f2e4dccab1b015b716b8b627
COLLECT_GCC_OPTIONS='-v' '-std=c++14' '-o' 'foo' '-shared-libgcc'
'-mtune=generic' '-march=x86-64'
 as -v --64 -o /tmp/ccO93I4M.o /tmp/cc3hVZ3b.s
GNU assembler version 2.29.1 (x86_64-pc-linux-gnu) using BFD version (GNU
Binutils) 2.29.1
COMPILER_PATH=/usr/lib/gcc/x86_64-pc-linux-gnu/7.3.1/:/usr/lib/gcc/x86_64-pc-linux-gnu/7.3.1/:/usr/lib/gcc/x86_64-pc-linux-gnu/:/usr/lib/gcc/x86_64-pc-linux-gnu/7.3.1/:/usr/lib/gcc/x86_64-pc-linux-gnu/
LIBRARY_PATH=/usr/lib/gcc/x86_64-pc-linux-gnu/7.3.1/:/usr/lib/gcc/x86_64-pc-linux-gnu/7.3.1/../../../../lib/:/lib/../lib/:/usr/lib/../lib/:/usr/lib/gcc/x86_64-pc-linux-gnu/7.3.1/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-std=c++14' '-o' 'foo' '-shared-libgcc'
'-mtune=generic' '-march=x86-64'
 /usr/lib/gcc/x86_64-pc-linux-gnu/7.3.1/collect2 -plugin
/usr/lib/gcc/x86_64-pc-linux-gnu/7.3.1/liblto_plugin.so
-plugin-opt=/usr/lib/gcc/x86_64-pc-linux-gnu/7.3.1/lto-wrapper
-plugin-opt=-fresolution=/tmp/cckfgL6n.res -plugin-opt=-pass-through=-lgcc_s
-plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lc
-plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lgcc --build-id
--eh-frame-hdr --hash-style=gnu -m elf_x86_64 -dynamic-linker
/lib64/ld-linux-x86-64.so.2 -pie -o foo
/usr/lib/gcc/x86_64-pc-linux-gnu/7.3.1/../../../../lib/Scrt1.o
/usr/lib/gcc/x86_64-pc-linux-gnu/7.3.1/../../../../lib/crti.o
/usr/lib/gcc/x86_64-pc-linux-gnu/7.3.1/crtbeginS.o
-L/usr/lib/gcc/x86_64-pc-linux-gnu/7.3.1
-L/usr/lib/gcc/x86_64-pc-linux-gnu/7.3.1/../../../../lib -L/lib/../lib
-L/usr/lib/../lib -L/usr/lib/gcc/x86_64-pc-linux-gnu/7.3.1/../../..
/tmp/ccO93I4M.o -lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc
/usr/lib/gcc/x86_64-pc-linux-gnu/7.3.1/crtendS.o
/usr/lib/gcc/x86_64-pc-linux-gnu/7.3.1/../../../../lib/crtn.o

[Bug lto/85422] [openacc] ICE at cfgloop.c:468: segfault in flow_loops_find

[vries at gcc dot gnu.org]

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

Tom de Vries  changed:

   What|Removed |Added

  Known to fail||6.4.0, 7.3.0

--- Comment #2 from Tom de Vries  ---
Reproduces with gcc-6-branch and gcc-7-branch.

[Bug target/85434] Address of stack protector guard spilled to stack on ARM

[thopre01 at gcc dot gnu.org]

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

--- Comment #3 from Thomas Preud'homme  ---
(In reply to Thomas Preud'homme from comment #2)
> (In reply to Thomas Preud'homme from comment #1)
> > This is caused by missing stack_protect_set and stack_protect_test pattern
> > in ARM backend. It would be nice though if the address could be marked such
> > that it doesn't go on the stack to have the default implementation a bit
> > more robust. It might be worth having a warning if the override is not done
> > as well.
> 
> Nope sorry, the address is put in a register before the test pattern is
> called.

This happens when expanding the tree that holds the guard's address. It's a
symbol_ref for which the default expand code of loading into a register is
used. This happens also for AArch64 and I suspect for x86 as well.

What makes it worse on ARM is that cse_local sees 2 SET instructions computing
the address of the guard and reuse the register being set in the first
instruction instead of recomputing again. Because of the distance between that
first SET and the comparison between guard and canari the chances of getting
the address spilled are higher. This does not happen for AArch64 because the
mov of symbol_ref generates an UNSPEC of a memory address whereas ARM generates
a MEM of an UNSPEC symbol_ref. However I suppose with scheduling it's possible
for the set of guard address and following test of guard against canari to be
moved apart and spill to happen in theory.

My feeling is that the target patterns should also do the address computation,
ie stack_protect_set and stack_protect_test would take that MEM of symbol_ref
instead of expanding it first.

Thoughts?

[Bug libquadmath/85440] New: libquadmath and quadmath.h do not exist on ppc64

[dclarke at blastwave dot org]

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

Bug ID: 85440
   Summary: libquadmath and quadmath.h do not exist on ppc64
   Product: gcc
   Version: 7.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libquadmath
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dclarke at blastwave dot org
  Target Milestone: ---

Seems fairly clear that while the info file does get installed 
into share/info/libquadmath.info the actual lib and header do
not exist. 

Could be bug 55821 here again. 

You can see the testsuite report at : 

https://gcc.gnu.org/ml/gcc-testresults/2018-04/msg01351.html


The ramifications here seem to be that one can not compile much of 
anything that uses the new 128-bit IEEE 754-2008 datatypes on this
platform and any attempt to do so results in : 

foo.c:3:10: fatal error: quadmath.h: No such file or directory
 #include 
  ^~~~
compilation terminated.


Any attempt to use the -mabi=ieeelongdouble option results in horrific
results that are no where even remotely close to correct : 

nix$ cat ld.c 

#define _XOPEN_SOURCE 600

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

int j;
/* correct 128 bit big endian hex representation of pi is 
 *   0x40 00 92 1f b5 44 42 d1 84 69 89 8c c5 17 01 b8 */
long double pi = 3.14159265358979323846264338327950288419716939937510L;

printf("\nstack address of variable \"pi\" is %p\n",  );
printf("\ncontents : 0x" );
for ( j=0; j

[Bug testsuite/85326] `make check` fails with `--disable-bootstrap` and `--enable-languages=c`

[ktkachov at gcc dot gnu.org]

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

--- Comment #7 from ktkachov at gcc dot gnu.org ---
Author: ktkachov
Date: Tue Apr 17 17:06:36 2018
New Revision: 259437

URL: https://gcc.gnu.org/viewcvs?rev=259437=gcc=rev
Log:
PR testsuite/85326

Commit missing hunk from r259435.


Added:
trunk/gcc/testsuite/gcc.target/aarch64/sve/vcond_1.c
  - copied unchanged from r259435,
trunk/gcc/testsuite/gcc.target/aarch64/sve/vcond_1.C
trunk/gcc/testsuite/gcc.target/aarch64/sve/vcond_1_run.c
  - copied unchanged from r259435,
trunk/gcc/testsuite/gcc.target/aarch64/sve/vcond_1_run.C
Removed:
trunk/gcc/testsuite/gcc.target/aarch64/sve/vcond_1.C
trunk/gcc/testsuite/gcc.target/aarch64/sve/vcond_1_run.C

[Bug target/85430] [7/8 Regression] ICE: SIGSEGV in memory_operand at recog.c:1358 with -O2 -fno-tree-ccp -fno-tree-fre

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Tue Apr 17 17:01:31 2018
New Revision: 259436

URL: https://gcc.gnu.org/viewcvs?rev=259436=gcc=rev
Log:
PR target/85430
* config/i386/i386.md (*ashlqi3_1_slp): Use alu1 type instead of alu.

* gcc.dg/pr85430.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr85430.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.md
trunk/gcc/testsuite/ChangeLog

[Bug testsuite/85326] `make check` fails with `--disable-bootstrap` and `--enable-languages=c`

[ktkachov at gcc dot gnu.org]

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

--- Comment #6 from ktkachov at gcc dot gnu.org ---
Author: ktkachov
Date: Tue Apr 17 16:34:56 2018
New Revision: 259435

URL: https://gcc.gnu.org/viewcvs?rev=259435=gcc=rev
Log:
[AArch64/arm] PR testsuite/85326 Avoid C++ tests when C++ compiler not present

PR testsuite/85326
* gcc.target/arm/pr54300.C: Move to...
* g++.dg/other/pr54300.C: ... Here.  Add target directives.
* gcc.target/arm/pr55073.C: Move to...
* g++.dg/other/pr55073.C: ... Here.  Add target directives.
* gcc.target/arm/pr56184.C: Move to...
* g++.dg/other/pr56184.C: ... Here.  Add target directives.
* gcc.target/arm/pr59985.C: Move to...
* g++.dg/other/pr59985.C: ... Here.  Add target directives.
* gcc.target/aarch64/pr60675.C: Move to...
* g++.dg/other/pr60675.C: ... Here.  Add target directives.
* gcc.target/aarch64/pr81422.C: Move to...
* g++.dg/other/pr81422.C: ... Here.  Add target directives.
* gcc.target/aarch64/sve/const_pred_1.C: Move to...
* g++.dg/other/sve_const_pred_1.C: ... Here.  Add target directives.
* gcc.target/aarch64/sve/const_pred_2.C: Move to...
* g++.dg/other/sve_const_pred_2.C: ... Here.  Add target directives.
* gcc.target/aarch64/sve/const_pred_3.C: Move to...
* g++.dg/other/sve_const_pred_3.C: ... Here.  Add target directives.
* gcc.target/aarch64/sve/const_pred_4.C: Move to...
* g++.dg/other/sve_const_pred_4.C: ... Here.  Add target directives.
* gcc.target/aarch64/sve/tls_2.C: Move to...
* g++.dg/other/sve_tls_2.C: ... Here.  Add target directives.
* gcc.target/aarch64/pr81414.C: Rename to...
* gcc.target/aarch64/pr81414.c: ... This.
* gcc.target/aarch64/simd/pr67896.C: Rename to...
* gcc.target/aarch64/simd/pr67896.c: ... This.  Update error expected
messages.
* gcc.target/aarch64/sve/vcond_1.C: Rename to...
* gcc.target/aarch64/sve/vcond_1.c: ... This.  Avoid use of stdint.h.
* gcc.target/aarch64/sve/vcond_1_run.C: Rename to...
* gcc.target/aarch64/sve/vcond_1_run.c: ... This.  Update include
file name.


Added:
trunk/gcc/testsuite/g++.dg/other/pr54300.C
  - copied, changed from r259434,
trunk/gcc/testsuite/gcc.target/arm/pr54300.C
trunk/gcc/testsuite/g++.dg/other/pr55073.C
  - copied, changed from r259434,
trunk/gcc/testsuite/gcc.target/arm/pr55073.C
trunk/gcc/testsuite/g++.dg/other/pr56184.C
  - copied, changed from r259434,
trunk/gcc/testsuite/gcc.target/arm/pr56184.C
trunk/gcc/testsuite/g++.dg/other/pr59985.C
  - copied, changed from r259434,
trunk/gcc/testsuite/gcc.target/arm/pr59985.C
trunk/gcc/testsuite/g++.dg/other/pr60675.C
  - copied, changed from r259434,
trunk/gcc/testsuite/gcc.target/aarch64/pr60675.C
trunk/gcc/testsuite/g++.dg/other/pr81422.C
  - copied unchanged from r259434,
trunk/gcc/testsuite/gcc.target/aarch64/pr81422.C
trunk/gcc/testsuite/g++.dg/other/sve_const_pred_1.C
  - copied, changed from r259434,
trunk/gcc/testsuite/gcc.target/aarch64/sve/const_pred_1.C
trunk/gcc/testsuite/g++.dg/other/sve_const_pred_2.C
  - copied, changed from r259434,
trunk/gcc/testsuite/gcc.target/aarch64/sve/const_pred_2.C
trunk/gcc/testsuite/g++.dg/other/sve_const_pred_3.C
  - copied, changed from r259434,
trunk/gcc/testsuite/gcc.target/aarch64/sve/const_pred_3.C
trunk/gcc/testsuite/g++.dg/other/sve_const_pred_4.C
  - copied, changed from r259434,
trunk/gcc/testsuite/gcc.target/aarch64/sve/const_pred_4.C
trunk/gcc/testsuite/g++.dg/other/sve_tls_2.C
  - copied, changed from r259434,
trunk/gcc/testsuite/gcc.target/aarch64/sve/tls_2.C
trunk/gcc/testsuite/gcc.target/aarch64/pr81414.c
  - copied unchanged from r259434,
trunk/gcc/testsuite/gcc.target/aarch64/pr81414.C
trunk/gcc/testsuite/gcc.target/aarch64/simd/pr67896.c
Removed:
trunk/gcc/testsuite/gcc.target/aarch64/pr60675.C
trunk/gcc/testsuite/gcc.target/aarch64/pr81414.C
trunk/gcc/testsuite/gcc.target/aarch64/pr81422.C
trunk/gcc/testsuite/gcc.target/aarch64/simd/pr67896.C
trunk/gcc/testsuite/gcc.target/aarch64/sve/const_pred_1.C
trunk/gcc/testsuite/gcc.target/aarch64/sve/const_pred_2.C
trunk/gcc/testsuite/gcc.target/aarch64/sve/const_pred_3.C
trunk/gcc/testsuite/gcc.target/aarch64/sve/const_pred_4.C
trunk/gcc/testsuite/gcc.target/aarch64/sve/tls_2.C
trunk/gcc/testsuite/gcc.target/arm/pr54300.C
trunk/gcc/testsuite/gcc.target/arm/pr55073.C
trunk/gcc/testsuite/gcc.target/arm/pr56184.C
trunk/gcc/testsuite/gcc.target/arm/pr59985.C
Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/aarch64/sve/vcond_1.C
trunk/gcc/testsuite/gcc.target/aarch64/sve/vcond_1_run.C

[Bug libstdc++/85439] New: mt19937_64 producing unexpected result only in certain configuration

[foddex at foddex dot net]

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

Bug ID: 85439
   Summary: mt19937_64 producing unexpected result only in certain
configuration
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: foddex at foddex dot net
  Target Milestone: ---

Created attachment 43967
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43967=edit
Code mentioned in report

My sincere apologies if this doesn't belong here, I'm not a regular.

In my tests to establish STL's mersenne twister's reproducability, I have found
an interesting problem that I think is a bug in the libstdc++ runtime in Linux,
but I may be wrong.

I ran the attached code on the various platforms and compiler combinations:
LINUX:
- g++ version 7.3.1 20180130 (Red Hat 7.3.1-2) on Fedora 26 4.12.14-300
- clang++ version 4.0.1 (tags/RELEASE_401/final) on Fedora 26 4.12.14-300
- clang++ version 6.0.0 (tags/RELEASE_600/final) on Arch Linux 4.15.13-1
OSX:
- clang++ 9.1.0 Apple LLVM on High Sierra
WINDOWS:
- MSVC2017 15.6.6 on Windows 10

For g++ and clang++ the compilations options are identical on all platforms:
main.cpp -std=c++11

On MSVC a default solution was used.

The output on Linux is as follows:
32 bits gen, uint32_t: 3499211612
32 bits gen, uint64_t: 15028999435905310454
64 bits gen, uint32_t: 3379370269
64 bits gen, uint64_t: 14514284786278117030
32 bits gen, float: 0.814724
64 bits gen, float: 0.786821
32 bits gen, double: 0.135477
64 bits gen, double: 0.786821

The output of the clang++ on OS X and MSVC applications is as follows:
32 bits gen, uint32_t: 3499211612
32 bits gen, uint64_t: 15028999435905310454
64 bits gen, uint32_t: 4143361702
64 bits gen, uint64_t: 14514284786278117030
32 bits gen, float: 0.814724
64 bits gen, float: 0.786821
32 bits gen, double: 0.135477
64 bits gen, double: 0.786821

Note that the output only differs on the 3rd line. 

Since MSVC and clang agree on all tests, and their implementations are
independent, I came to the conclusion it must be a bug in libstd++ on Linux.

[Bug libstdc++/85435] undefined behaviour in std::char_traits::move

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
The library will never call it with a null pointer, but users could do. Not
many people use char_traits directly though. Probably even fewer use the
primary template, because there are specializations for char, wchar_t, char16_t
and char32_t which were already fixed for PR 65049.

[Bug target/85436] [7 Regression] ICE compiling go code with -mcpu=power9

[acsawdey at gcc dot gnu.org]

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

--- Comment #1 from acsawdey at gcc dot gnu.org ---
Created attachment 43966
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43966=edit
shorter reduced test case

I've further reduced the test case and now it's only 38 lines so so should be
easier to work with.

[Bug rtl-optimization/85431] UBSAN: ../../gcc/dse.c:303:15: runtime error: shift exponent 64 is too large for 64-bit type 'long unsigned int'

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-04-17
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Created attachment 43965
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43965=edit
gcc8-pr85421.patch

Untested fix.

[Bug target/85434] Address of stack protector guard spilled to stack on ARM

[thopre01 at gcc dot gnu.org]

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

--- Comment #2 from Thomas Preud'homme  ---
(In reply to Thomas Preud'homme from comment #1)
> This is caused by missing stack_protect_set and stack_protect_test pattern
> in ARM backend. It would be nice though if the address could be marked such
> that it doesn't go on the stack to have the default implementation a bit
> more robust. It might be worth having a warning if the override is not done
> as well.

Nope sorry, the address is put in a register before the test pattern is called.

[Bug ada/85380] gnatbind fails with small executable & restricted runtime

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu.org,
   ||ramana at gcc dot gnu.org

--- Comment #1 from Ramana Radhakrishnan  ---
Adding Eric to the CC list as someone who could comment on this ?

[Bug target/85203] cmse_nonsecure_caller intrinsic returns incorrect results

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||ramana at gcc dot gnu.org
 Resolution|--- |FIXED
   Target Milestone|--- |7.4

--- Comment #4 from Ramana Radhakrishnan  ---
Fixed I'm assuming ?

[Bug lto/82229] GCC7's LTO underperforms compared to GCC6

[krzysio.kurek at wp dot pl]

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

--- Comment #22 from krzysio.kurek at wp dot pl ---
I'm sorry but profiling doesn't seem to be well documented, what tools should I
use to generate a profiling log?

[Bug libstdc++/85435] undefined behaviour in std::char_traits::move

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
This isn't important to fix just because ubsan will be happy, but the
optimizers actively derive non-NULL range for the pointers from the memmove
call and so could optimize away say comparisons against NULL of those pointers
etc.
So, if it is valid for the move method on char_traits to be called with NULL,
the fix is very important.

[Bug c++/85437] [8 Regression] member pointer static upcast rejected in a constexpr context

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org
   Target Milestone|--- |8.0

--- Comment #5 from Jakub Jelinek  ---
(gdb) p debug_tree (type)
 
unit-size 
align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7fffefc625e8 precision:32 min  max

pointer_to_this >
DI
size  constant 64>
unit-size  constant 8>
align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7fffefd9d150 basetype >
$4 = void
(gdb) p debug_tree (op->typed.type)
 
unit-size 
align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7fffefc625e8 precision:32 min  max

pointer_to_this >
DI
size  constant 64>
unit-size  constant 8>
align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7fffefd9d3f0 basetype >

Ah, one has basetype A, the other B, and both:
4600if (same_type_ignoring_top_level_qualifiers_p (type,
4601   TREE_TYPE
(op))
4602|| can_convert_qual (type, op))
tests fail in this case.

[Bug c++/85437] [8 Regression] member pointer static upcast rejected in a constexpr context

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
convert_ptrmem here creates a NOP_EXPR around the PTRMEM_CST, even when it is
for a static cast rather than reinterpret_cast.  The OFFSET_TYPEs are
different, but they have the same TREE_TYPE etc.
Then constexpr.c doesn't consider that cast to be usable in constant
expressions and because it is called with allow_non_constant, it wraps the new
PTRMEM_CST with another NOP_EXPR and that is where following constexpr.c call
errors on.

[Bug c++/85438] [8 Regression] invalid "a reinterpret_cast is not a constant expression" diagnostics since r249088

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  ---
There is one NOP_EXPR created by

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

[Bug c++/55004] [meta-bug] constexpr issues

[jakub at gcc dot gnu.org]

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

Bug 85438 Summary: [8 Regression] invalid "a reinterpret_cast is not a constant 
expression" diagnostics since r249088
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85438

   What|Removed |Added

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

[Bug c++/85437] [8 Regression] member pointer static upcast rejected in a constexpr context

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
*** Bug 85438 has been marked as a duplicate of this bug. ***

[Bug c++/85437] [8 Regression] member pointer static upcast rejected in a constexpr context

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-04-17
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Marek Polacek  ---
Confirmed.

[Bug c++/85438] [8 Regression] invalid "a reinterpret_cast is not a constant expression" diagnostics since r249088

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Keywords|accepts-invalid |rejects-valid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-04-17
   Target Milestone|--- |8.0
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
clang++ and older g++ accept it.

[Bug c++/85437] [8 Regression] member pointer static upcast rejected in a constexpr context

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||rejects-valid

--- Comment #1 from Martin Sebor  ---
The first revision to reject the test case is r249088:

Overhaul pointer-to-member conversion and template argument handling.

* call.c (standard_conversion): Avoid creating ck_pmem when the
class type is the same.
* cvt.c (can_convert_qual): Split from
perform_qualification_conversions.
* constexpr.c (cxx_eval_constant_expression): Check it.
* typeck.c (convert_ptrmem): Only cplus_expand_constant if
adjustment is necessary.
* pt.c (check_valid_ptrmem_cst_expr): Compare class types.
(convert_nontype_argument): Avoid redundant error.

[Bug c++/70248] constexpr initialization with unspecified equality expression accepted

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=85437

--- Comment #6 from Martin Sebor  ---
I raised bug 85437 for the regression.

[Bug c++/85438] New: [8 Regression] invalid "a reinterpret_cast is not a constant expression" diagnostics since r249088

[jakub at gcc dot gnu.org]

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

Bug ID: 85438
   Summary: [8 Regression] invalid "a reinterpret_cast is not a
constant expression" diagnostics since r249088
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: accepts-invalid
  Severity: minor
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
CC: daniel.kruegler at googlemail dot com, jakub at gcc dot 
gnu.org,
jason at gcc dot gnu.org, msebor at gcc dot gnu.org,
unassigned at gcc dot gnu.org, webrown.cpp at gmail dot com
Depends on: 70248
Blocks: 55004
  Target Milestone: ---

+++ This bug was initially created as a clone of Bug #70248 +++

struct A {};
struct B : A { int x; };
constexpr int A::*bx = (int(A::*))::x;

is rejected since r249088 with:
pr70248-2.C:3:24: error: a reinterpret_cast is not a constant expression
 constexpr int A::*bx = (int(A::*))::x;
^


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55004
[Bug 55004] [meta-bug] constexpr issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70248
[Bug 70248] constexpr initialization with unspecified equality expression
accepted

[Bug c++/85437] New: [8 Regression] member pointer static upcast rejected in a constexpr context

[msebor at gcc dot gnu.org]

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

Bug ID: 85437
   Summary: [8 Regression] member pointer static upcast rejected
in a constexpr context
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

The following valid test case (extracted from bug 70248) is accepted by GCC 7
(and Clang and ICC) but rejected by GCC 8:

$ cat pr70248.C && gcc -S -Wall pr70248.C
struct A {};
struct B : A { int x; };
constexpr int A::*bx = static_cast(::x);

pr70248.C:4:24: error: a reinterpret_cast is not a constant expression
 constexpr int A::*bx = static_cast(::x);
^

[Bug c++/70248] constexpr initialization with unspecified equality expression accepted

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org

--- Comment #5 from Jakub Jelinek  ---
That started with r249088.

[Bug c++/70248] constexpr initialization with unspecified equality expression accepted

[msebor at gcc dot gnu.org]

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

--- Comment #4 from Martin Sebor  ---
Rejecting the test case because of the initialization is a regression.  The
cast is not a reinterpret cast.  GCC gives the same error with a static cast
too:

$ gcc -S -Wall pr70248.C 
pr70248.C:4:24: error: a reinterpret_cast is not a constant expression
 constexpr int A::*bx = static_cast(::x);
^
pr70248.C:5:24: error: a reinterpret_cast is not a constant expression
 constexpr int A::*cx = static_cast(::x);
^

[Bug target/85436] New: [7 Regression] ICE compiling go code with -mcpu=power9

[acsawdey at gcc dot gnu.org]

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

Bug ID: 85436
   Summary: [7 Regression] ICE compiling go code with -mcpu=power9
   Product: gcc
   Version: 7.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: acsawdey at gcc dot gnu.org
CC: bergner at gcc dot gnu.org, segher at gcc dot gnu.org,
wschmidt at gcc dot gnu.org
  Target Milestone: ---
Target: powerpc64le-linux-gnu

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

To reproduce:

Build gcc-7-branch using:

configure --disable-bootstrap --enable-languages=c,c++,go
--with-long-double-128 --enable-secureplt --disable-multilib --without-ppl
--without-cloog --without-libelf

gcc/gccgo -Bgcc -O3 -Lpowerpc64le-linux-gnu/libgo -S bug_reduced.go
-mcpu=power9

This affects 259009 through the head of the gcc-7-branch.

[Bug debug/84637] gcc/dbxout.c:684:14: runtime error: negation of -9223372036854775808 cannot be represented in type 'long int'; cast to an unsigned type to negate this value to itself

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
Created attachment 43963
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43963=edit
gcc8-pr84637.patch

I think in this case the fix is rather obvious (though, untested so far and not
proposing it for GCC8).

[Bug libstdc++/84442] FAIL: 30_threads/thread/cons/terminate.cc (test for excess errors)

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
Dave, does the patch in comment 3 fix the FAIL?

[Bug libstdc++/85435] undefined behaviour in std::char_traits::move

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-04-17
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=65049
 Ever confirmed|0   |1

[Bug libstdc++/85435] New: undefined behaviour in std::char_traits::move

[redi at gcc dot gnu.org]

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

Bug ID: 85435
   Summary: undefined behaviour in std::char_traits::move
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

#include 

int main()
{
  std::char_traits::move(nullptr, nullptr, 0);
}

Compiled with UBsan shows:

/home/jwakely/gcc/8/include/c++/8.0.1/bits/char_traits.h:188:52: runtime error:
null pointer passed as argument 1, which is declared to never be null
/home/jwakely/gcc/8/include/c++/8.0.1/bits/char_traits.h:188:52: runtime error:
null pointer passed as argument 2, which is declared to never be null

The move member for the primary template needs this fix:

--- a/libstdc++-v3/include/bits/char_traits.h
+++ b/libstdc++-v3/include/bits/char_traits.h
@@ -185,6 +185,8 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 char_traits<_CharT>::
 move(char_type* __s1, const char_type* __s2, std::size_t __n)
 {
+  if (__n == 0)
+   return __s1;
   return static_cast<_CharT*>(__builtin_memmove(__s1, __s2,
__n * sizeof(char_type)));
 }

[Bug libstdc++/83077] sso-string @ gnu-versioned-namespace.

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|8.0 |9.0

[Bug target/85434] Address of stack protector guard spilled to stack on ARM

[thopre01 at gcc dot gnu.org]

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

Thomas Preud'homme  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-04-17
 Ever confirmed|0   |1

--- Comment #1 from Thomas Preud'homme  ---
This is caused by missing stack_protect_set and stack_protect_test pattern in
ARM backend. It would be nice though if the address could be marked such that
it doesn't go on the stack to have the default implementation a bit more
robust. It might be worth having a warning if the override is not done as well.

[Bug target/85434] New: Address of stack protector guard spilled to stack on ARM

[thopre01 at gcc dot gnu.org]

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

Bug ID: 85434
   Summary: Address of stack protector guard spilled to stack on
ARM
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: target
  Assignee: thopre01 at gcc dot gnu.org
  Reporter: thopre01 at gcc dot gnu.org
  Target Milestone: ---
Target: arm-linux-gnueabihf

Created attachment 43962
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43962=edit
Testcase for stack protector spilling guard address

When compiling the attached file with -mcpu=cortex-a57 -std=c99 -Os -fpic
-fstack-protector-strong the address to the stack gets spilled on the stack
where an attacker using buffer overflow could overwrite it and thus control
what is the canari checked against:

ldr r3, [sp]  <--- accessing spilled address of guard from stack
mov r0, r4
ldr r2, [sp, #228]
ldr r3, [r3]
cmp r2, r3
beq .L18
bl  __stack_chk_fail(PLT)

I can reproduce this on GCC 7 and trunk at least.

[Bug libstdc++/71960] __glibcxx_assert and Debug Mode checks can't be used in constexpr functions

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-04-17
 Ever confirmed|0   |1

--- Comment #3 from Jonathan Wakely  ---
See patch and discussion at
https://gcc.gnu.org/ml/libstdc++/2018-03/msg00032.html and
https://gcc.gnu.org/ml/libstdc++/2018-03/msg00033.html

[Bug tree-optimization/85416] Massive performance regression when switching on "-march=native"

[amonakov at gcc dot gnu.org]

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

Alexander Monakov  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |INVALID

--- Comment #14 from Alexander Monakov  ---
Ah, the linked report actually says very clearly that fixes landed in Glibc
2.25, so I'll close this bug: nothing to do on GCC side about this.

[Bug c/85433] -fdiagnostics-color=auto doesn't work properly with LTO

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
If you use -save-temps -v and rerun the lto1 invocation printed in there, it is
colored.
The way -fdiagnostics-color=auto works is it verifies TERM is not dumb and that
isatty (2).
The problem with LTO is that the latter is not the case, collect2 creates a
file
instead lderrout = make_temp_file (".le"); and uses that as stderr of the
linker which is what becomes stderr of lto1 too.
Dunno why we need to use files for there, if that is the case, perhaps either
collect2 or gcc driver should for -flto linking and -fdiagnostics-color=auto
(or if that is the default, for lack of -fdiagnostics-color too) check whether
the stderr is a terminal and if yes, pass -fdiagnostics-color=always instead.

[Bug tree-optimization/85416] Massive performance regression when switching on "-march=native"

[amonakov at gcc dot gnu.org]

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

--- Comment #13 from Alexander Monakov  ---
This is most likely a variant of 

  https://bugzilla.redhat.com/show_bug.cgi?id=1421121

so hitting this bug requires a specific CPU model.

It looks as if SSE-AVX transition penalties appear when switching between
pure-SSE sinf code and VEX-prefixed SSE code in the main program after the
ld.so runtime resolver affects AVX state tracking in the CPU.

I'm not sure if any patches have landed on Glibc side to avoid this, but in any
case this should be re-reported against Glibc if needed, GCC cannot improve the
situation.

An easy workaround would be to pass -Wl,-z,now when linking.

[Bug tree-optimization/85416] Massive performance regression when switching on "-march=native"

[mar...@mpa-garching.mpg.de]

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

--- Comment #12 from Martin Reinecke  ---
Created attachment 43961
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43961=edit
perf annotate output with -march=native

[Bug tree-optimization/85416] Massive performance regression when switching on "-march=native"

[mar...@mpa-garching.mpg.de]

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

--- Comment #11 from Martin Reinecke  ---
Created attachment 43960
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43960=edit
perf annotate output without -march=native

[Bug target/85381] [og7, nvptx, openacc] parallel-loop-1.c fails with default vector length 128

[vries at gcc dot gnu.org]

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

--- Comment #5 from Tom de Vries  ---
(In reply to Tom de Vries from comment #4)
> This looks like a JIT bug, but with this tentative patch:
...
> no barriers are generated, and the minimized testcase passes.

And the original test-case passes.

[Bug target/85381] [og7, nvptx, openacc] parallel-loop-1.c fails with default vector length 128

[vries at gcc dot gnu.org]

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

--- Comment #4 from Tom de Vries  ---
This looks like a JIT bug, but with this tentative patch:
...
diff --git a/gcc/config/nvptx/nvptx.c b/gcc/config/nvptx/nvptx.c
index 8c478c874bd..ac394ee1ae6 100644
--- a/gcc/config/nvptx/nvptx.c
+++ b/gcc/config/nvptx/nvptx.c
@@ -4479,7 +4479,7 @@ nvptx_process_pars (parallel *par)
  threads = nvptx_mach_vector_length ();
}

-  if (!empty || !is_call)
+  if (!(empty || is_call))
{
  /* Insert begin and end synchronizations.  */
  emit_insn_before (nvptx_cta_sync (barrier, threads),
...
no barriers are generated, and the minimized testcase passes.

[Bug tree-optimization/85416] Massive performance regression when switching on "-march=native"

[marxin at gcc dot gnu.org]

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

--- Comment #10 from Martin Liška  ---
And please rebuild the binaries with -g and attach perf annotate output.
Thanks.

[Bug tree-optimization/85416] Massive performance regression when switching on "-march=native"

[mar...@mpa-garching.mpg.de]

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

--- Comment #9 from Martin Reinecke  ---
Sure!

martin@martin-Latitude-E7450 ~/tmp $ gcc -O3 testcase2.c -lm
martin@martin-Latitude-E7450 ~/tmp $ perf stat ./a.out

 Performance counter stats for './a.out':

   1109,985866  task-clock (msec) #0,999 CPUs utilized  
 2  context-switches  #0,002 K/sec  
 0  cpu-migrations#0,000 K/sec  
 2.000  page-faults   #0,002 M/sec  
 3.155.388.780  cycles#2,843 GHz
 6.717.336.961  instructions  #2,13  insn per cycle 
   979.526.022  branches  #  882,467 M/sec  
38.112  branch-misses #0,00% of all branches

   1,110639187 seconds time elapsed

martin@martin-Latitude-E7450 ~/tmp $ gcc -O3 testcase2.c -march=native -lm
martin@martin-Latitude-E7450 ~/tmp $ perf stat ./a.out

 Performance counter stats for './a.out':

   7724,004864  task-clock (msec) #1,000 CPUs utilized  
86  context-switches  #0,011 K/sec  
 1  cpu-migrations#0,000 K/sec  
 2.004  page-faults   #0,259 K/sec  
22.129.645.853  cycles#2,865 GHz
 6.723.657.441  instructions  #0,30  insn per cycle 
   980.761.202  branches  #  126,976 M/sec  
   171.813  branch-misses #0,02% of all branches

   7,726058359 seconds time elapsed

[Bug tree-optimization/85416] Massive performance regression when switching on "-march=native"

[amonakov at gcc dot gnu.org]

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

Alexander Monakov  changed:

   What|Removed |Added

 CC||amonakov at gcc dot gnu.org

--- Comment #8 from Alexander Monakov  ---
Can you also run the tests under 'perf stat'?

[Bug c++/70248] constexpr initialization with unspecified equality expression accepted

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
GCC trunk (8.0.1 20180410) now rejects comment 0 with:

c0.cc:4:24: error: a reinterpret_cast is not a constant expression
 constexpr int A::*bx = (int(A::*))::x;
^
c0.cc:5:24: error: a reinterpret_cast is not a constant expression
 constexpr int A::*cx = (int(A::*))::x;
^

[Bug c/85433] New: -fdiagnostics-color=auto doesn't work properly with LTO

[marxin at gcc dot gnu.org]

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

Bug ID: 85433
   Summary: -fdiagnostics-color=auto doesn't work properly with
LTO
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: dmalcolm at gcc dot gnu.org
  Target Milestone: ---

Running:

$ cat 1.c
struct A
{
  int a;
  double b;
};

extern void foo (struct A *);

int main()
{
  struct A a;
  foo ();

  return a.a;
}

$ cat 2.c
struct A
{
  int a;
};

$ gcc *.c -fdiagnostics-color=auto -flto
1.c:7:13: warning: type of ‘foo’ does not match original declaration
[-Wlto-type-mismatch]
 extern void foo (struct A *);
 ^
2.c:7:6: note: ‘foo’ was previously declared here
 void foo (struct A *a)
  ^
2.c:7:6: note: code may be misoptimized unless -fno-strict-aliasing is used

Does not produce color output, while:

$ gcc *.c -fdiagnostics-color=always -flto

does. David is it a known issue?

[Bug c++/85428] constexpr pointer equality comparison not considered constant expression

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||rejects-valid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-04-17
 Ever confirmed|0   |1

[Bug lto/85432] Wodr can be more verbose for C code

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

Version|unknown |8.0.1
   Severity|normal  |enhancement

[Bug lto/85432] New: Wodr can be more verbose for C code

[marxin at gcc dot gnu.org]

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

Bug ID: 85432
   Summary: Wodr can be more verbose for C code
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: hubicka at gcc dot gnu.org, marxin at gcc dot gnu.org
  Target Milestone: ---

Let's consider:

$ cat 1.c
struct A
{
  int a;
  double b;
};

extern void foo (struct A *);

int main()
{
  struct A a;
  foo ();

  return a.a;
}

$ cat 2.c
struct A
{
  int a;
};


void foo (struct A *a)
{
  a->a = 123;
}

$ gcc *.c -flto
1.c:7:13: warning: type of ‘foo’ does not match original declaration
[-Wlto-type-mismatch]
 extern void foo (struct A *);
 ^
2.c:7:6: note: ‘foo’ was previously declared here
 void foo (struct A *a)
  ^
2.c:7:6: note: code may be misoptimized unless -fno-strict-aliasing is used

C++ FE is more verbose:

g++ *.c -flto
1.c:1:8: warning: type ‘struct A’ violates the C++ One Definition Rule [-Wodr]
 struct A
^
2.c:1:8: note: a different type is defined in another translation unit
 struct A
^
1.c:4:10: note: the first difference of corresponding definitions is field ‘b’
   double b;
  ^
2.c:1:8: note: a type with different number of fields is defined in another
translation unit
 struct A
^
1.c:7:13: warning: ‘foo’ violates the C++ One Definition Rule  [-Wodr]
 extern void foo (struct A *);
 ^
2.c:7:6: note: type mismatch in parameter 1
 void foo (struct A *a)
  ^
2.c:1:8: note: type ‘struct A’ itself violates the C++ One Definition Rule
 struct A
^
1.c:1:8: note: the incompatible type is defined here
 struct A
^
2.c:7:6: note: ‘foo’ was previously declared here
 void foo (struct A *a)
  ^
2.c:7:6: note: code may be misoptimized unless -fno-strict-aliasing is used

[Bug target/85417] -fcf-protection should provide CET protection on x86

[hjl.tools at gmail dot com]

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

--- Comment #5 from H.J. Lu  ---
(In reply to Uroš Bizjak from comment #4)
> (In reply to H.J. Lu from comment #2)
> > I am working to enable CET on Linux with a single binary. -fcf-protection
> > should provide CET protection on x86 by default.  We can add a command-line
> > option if we want a different implementation.
> 
> This should remain an opt-in feature, not opt-out. We can have
> --with-fcf-protection configure option to override the default.

-fcf-protection -mcet can't be used with IFUNC features, like symbol
multiversioning or target clone since IBT/SHSTK are applied to the
whole program and they may be disabled in some functions.  But
-fcf-protection can be implemented with the NOP portion of IBT/SHSTK,
which is compatible with all functions.  Without this, IFUNC can't
be used on Linux when -fcf-protection is enabled by default.

[Bug lto/85391] [8 Regression] ICE in add_type_duplicate, at ipa-devirt.c:1887

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Assignee|marxin at gcc dot gnu.org  |hubicka at gcc dot 
gnu.org

--- Comment #16 from Martin Liška  ---
(In reply to Jan Hubicka from comment #14)
> Created attachment 43947 [details]
> Proposed fix
> 
> We looked into this with Maritn todday. There are two bugs: one is the fact
> that lto.c forgets to register the type in case it was within strongly
> connected component after its outer type. The order depends on hash values
> and is not well determined. We do not want to test TYPE_CANONICAL being
> non-NULL. Martin is testing it.
> 
> Other is the fact that Eric's last change make odr types compatible when one
> of them is incomplete. This is not necessarily the case. The patch should
> fix the ordering issue by going the slow path in case type already in
> hashtable is incomplete. In this case it won't take long to compare it with
> the other type anyway.

Unfortunately with the suggested patch I see the same ICE for same types as
seen in: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85391#c1

Minimal test-case this time is 12 files, would take a really long time to
reduce.

[Bug target/85381] [og7, nvptx, openacc] parallel-loop-1.c fails with default vector length 128

[vries at gcc dot gnu.org]

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

--- Comment #3 from Tom de Vries  ---
(In reply to Tom de Vries from comment #2)
> I minimized this failure, and ran into PR 80035/81069, so I've backported
> the fix from trunk: https://gcc.gnu.org/ml/gcc-patches/2018-04/msg00774.html

With that fixed, I run into another failure. Minimized:
...
int
main (void)
{
  long long v1;
#pragma acc parallel num_gangs (640) num_workers(1) vector_length (128)
#pragma acc loop
  for (v1 = 0; v1 < 20; v1 += 2)
;

  return 0;
}
...

With ptx:
...
// BEGIN PREAMBLE   
.version 3.1
.target sm_30
.address_size 64
// END PREAMBLE 

// BEGIN FUNCTION DECL: main$_omp_fn$0  
.entry main$_omp_fn$0;

// BEGIN FUNCTION DEF: main$_omp_fn$0   
.entry main$_omp_fn$0
{
  .reg .u64 %r23;
  .reg .u64 %r24;
  // fork 4;
  bar.sync 0;
  // forked 4;  
  // joining 4; 
  bar.sync 0;
  // join 4;
  ret;
}
//:FUNC_MAP "main$_omp_fn$0", 0x280, 0x1, 0x80  
^@
...

Intriguing detail about this example: passes with GOMP_NVPTX_JIT=-O0, hangs
with GOMP_NVPTX_JIT=-O1, but seemingly the same SASS is generated:
...
//- .text.main$_omp_fn$0  --
.section.text.main$_omp_fn$0,"ax",@progbits
.sectionflags   @"SHF_BARRIERS=1"
.sectioninfo@"SHI_REGISTERS=2"
.align  32
.text.main$_omp_fn$0:
.type   main$_omp_fn$0,@function
.size   main$_omp_fn$0,(.L_8 - main$_omp_fn$0)
.other  main$_omp_fn$0,@"STO_CUDA_ENTRY STV_DEFAULT"
main$_omp_fn$0:
/*0008*/   MOV R1, c[0x0][0x20];
/*0010*/   BAR.SYNC 0x0;
/*0018*/   BAR.SYNC 0x0;
/*0028*/   EXIT;
.L_1:
/*0030*/   BRA `(.L_1);
.L_8:
...

The only difference is at 0020, but that's only visible with cuobjdump:
...
/*0010*/   BAR.SYNC 0x0;  /* 0xf0a81b87 */
/*0018*/   BAR.SYNC 0x0;  /* 0xf0a81b87 */
  /* 0x001f8000ffe01fef */
/*0028*/   EXIT;  /* 0xe307000f */
...
vs
...
/*0010*/   BAR.SYNC 0x0;  /* 0xf0a81b87 */
/*0018*/   BAR.SYNC 0x0;  /* 0xf0a81b87 */
  /* 0x001f8000ffe007ff */
/*0028*/   EXIT;  /* 0xe307000f */
...

[Bug debug/84637] gcc/dbxout.c:684:14: runtime error: negation of -9223372036854775808 cannot be represented in type 'long int'; cast to an unsigned type to negate this value to itself

[marxin at gcc dot gnu.org]

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

--- Comment #2 from Martin Liška  ---
Thanks for explanation. Do you plan to remove it in the future from GCC or will
you leave it there unmaintained?

[Bug fortran/84640] gcc/fortran/simplify.c:2587:9: runtime error: pointer index expression with base 0x0000090de160 overflowed to 0xffffffffc0632960

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #2 from Martin Liška  ---
Can be easily seen with:

diff --git a/gcc/fortran/simplify.c b/gcc/fortran/simplify.c
index a970e017c90..66d9450d457 100644
--- a/gcc/fortran/simplify.c
+++ b/gcc/fortran/simplify.c
@@ -2171,7 +2171,9 @@ gfc_simplify_cshift (gfc_expr *array, gfc_expr *shift,
gfc_expr *dim)
   while (count[n] == extent[n])
{
  count[n] = 0;
+ fprintf (stderr, "p: %p, ss_ex[n]: %ld\n", rptr, ss_ex[n]);
  rptr -= ss_ex[n];
+ fprintf (stderr, "p2: %p\n", rptr);
  sptr -= ss_ex[n];
  if (shiftvec)
hptr -= hs_ex[n];

Then:

$ ./gcc/xgcc -Bgcc
/home/marxin/Programming/gcc/gcc/testsuite/gfortran.dg/simplify_cshift_1.f90 -c
-O
p: 0x7824c48, ss_ex[n]: 433791696997
p2: 0xfcd807824920
p: 0x40780db40, ss_ex[n]: 433791696997
p2: 0x3fcd80780d818
p: 0x4078170e0, ss_ex[n]: 433791696997
p2: 0x3fcd807816db8
p: 0x407818be0, ss_ex[n]: 12
p2: 0x407818b80
p: 0x80781f5d0, ss_ex[n]: 126035584
p2: 0x7cb68c1d0
p: 0x10078216b0, ss_ex[n]: -1008
p2: 0x1007823630
p: 0x784b9a8, ss_ex[n]: 8589921888
p2: 0xfff0078646a8

So rptr points to an invalid memory. Question is whether a store/load from the
address can happen?

[Bug rtl-optimization/85431] UBSAN: ../../gcc/dse.c:303:15: runtime error: shift exponent 64 is too large for 64-bit type 'long unsigned int'

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

Version|unknown |8.0.1
 Blocks||63426
   Target Milestone|--- |8.0


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63426
[Bug 63426] [meta-bug] Issues found with -fsanitize=undefined

[Bug rtl-optimization/85431] New: UBSAN: ../../gcc/dse.c:303:15: runtime error: shift exponent 64 is too large for 64-bit type 'long unsigned int'

[marxin at gcc dot gnu.org]

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

Bug ID: 85431
   Summary: UBSAN: ../../gcc/dse.c:303:15: runtime error: shift
exponent 64 is too large for 64-bit type 'long
unsigned int'
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: rsandifo at gcc dot gnu.org
  Target Milestone: ---

Following causes UBSAN:

$ UBSAN_OPTIONS="print_stacktrace=1" ./xgcc -B.
/home/marxin/Programming/gcc/gcc/testsuite/c-c++-common/torture/pr85022.c -c -O
../../gcc/dse.c:303:15: runtime error: shift exponent 64 is too large for
64-bit type 'long unsigned int'
#0 0x2ecd348 in lowpart_bitmask ../../gcc/dse.c:303
#1 0x2ed2512 in record_store ../../gcc/dse.c:1649
#2 0x2ed89d4 in scan_insn ../../gcc/dse.c:2542
#3 0x2ed9251 in dse_step1 ../../gcc/dse.c:2657
#4 0x2eded20 in rest_of_handle_dse ../../gcc/dse.c:3574
#5 0x2edef5c in execute ../../gcc/dse.c:3632
#6 0x15a1a8b in execute_one_pass(opt_pass*) ../../gcc/passes.c:2497
#7 0x15a2255 in execute_pass_list_1 ../../gcc/passes.c:2586
#8 0x15a22cc in execute_pass_list_1 ../../gcc/passes.c:2587
#9 0x15a234c in execute_pass_list(function*, opt_pass*)
../../gcc/passes.c:2597
#10 0xc44bc3 in cgraph_node::expand() ../../gcc/cgraphunit.c:2139
#11 0xc45ad0 in expand_all_functions ../../gcc/cgraphunit.c:2275
#12 0xc47448 in symbol_table::compile() ../../gcc/cgraphunit.c:2624
#13 0xc479c9 in symbol_table::finalize_compilation_unit()
../../gcc/cgraphunit.c:2717
#14 0x18b1667 in compile_file ../../gcc/toplev.c:480
#15 0x18b5448 in do_compile ../../gcc/toplev.c:2132
#16 0x18b592c in toplev::main(int, char**) ../../gcc/toplev.c:2267
#17 0x320b531 in main ../../gcc/main.c:39
#18 0x75ca9a86 in __libc_start_main (/lib64/libc.so.6+0x21a86)
#19 0x8210c9 in _start
(/home/marxin/Programming/gcc/objdir2/gcc/cc1+0x8210c9)

[Bug target/85430] [7/8 Regression] ICE: SIGSEGV in memory_operand at recog.c:1358 with -O2 -fno-tree-ccp -fno-tree-fre

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  ---
This fixes it.  Let me look for other similar issues.

--- gcc/config/i386/i386.md.jj  2018-04-05 20:34:31.989020754 +0200
+++ gcc/config/i386/i386.md 2018-04-17 12:14:19.550691464 +0200
@@ -10713,7 +10713,7 @@ (define_insn "*ashlqi3_1_slp"
 {
   switch (get_attr_type (insn))
 {
-case TYPE_ALU:
+case TYPE_ALU1:
   gcc_assert (operands[1] == const1_rtx);
   return "add{b}\t%0, %0";

@@ -10729,12 +10729,12 @@ (define_insn "*ashlqi3_1_slp"
  (cond [(and (and (match_test "TARGET_DOUBLE_WITH_ADD")
  (match_operand 0 "register_operand"))
 (match_operand 1 "const1_operand"))
- (const_string "alu")
+ (const_string "alu1")
   ]
   (const_string "ishift1")))
(set (attr "length_immediate")
  (if_then_else
-   (ior (eq_attr "type" "alu")
+   (ior (eq_attr "type" "alu1")
(and (eq_attr "type" "ishift1")
 (and (match_operand 1 "const1_operand")
  (ior (match_test "TARGET_SHIFT1")

[Bug target/85430] [7/8 Regression] ICE: SIGSEGV in memory_operand at recog.c:1358 with -O2 -fno-tree-ccp -fno-tree-fre

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P2
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-04-17
 CC||jakub at gcc dot gnu.org
   Target Milestone|--- |7.4
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Started with r240006.

[Bug target/85430] New: [7/8 Regression] ICE: SIGSEGV in memory_operand at recog.c:1358 with -O2 -fno-tree-ccp -fno-tree-fre

[zsojka at seznam dot cz]

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

Bug ID: 85430
   Summary: [7/8 Regression] ICE: SIGSEGV in memory_operand at
recog.c:1358 with -O2 -fno-tree-ccp -fno-tree-fre
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu

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

This happens even with PR85193 fixed.

Compiler output:
$ x86_64-pc-linux-gnu-gcc -O2 -fno-tree-ccp -fno-tree-fre testcase.c
during RTL pass: sched2
testcase.c: In function 'foo':
testcase.c:8:1: internal compiler error: Segmentation fault
 }
 ^
0xd6732f crash_signal
/repo/gcc-trunk/gcc/toplev.c:325
0xc8d044 memory_operand(rtx_def*, machine_mode)
/repo/gcc-trunk/gcc/recog.c:1358
0x12daa03 get_attr_memory(rtx_insn*)
/repo/gcc-trunk/gcc/config/i386/i386.md:2473
0x14f2310 insn_default_latency_generic(rtx_insn*)
/repo/gcc-trunk/gcc/config/i386/i386.md:16407
0x16fbbe1 insn_sched_cost(rtx_insn*)
/repo/gcc-trunk/gcc/haifa-sched.c:1420
0x17012e6 dep_cost_1(_dep*, unsigned int)
/repo/gcc-trunk/gcc/haifa-sched.c:1473
0x17032e9 dep_cost(_dep*)
/repo/gcc-trunk/gcc/haifa-sched.c:1509
0x17032e9 priority
/repo/gcc-trunk/gcc/haifa-sched.c:1660
0x17033de set_priorities(rtx_insn*, rtx_insn*)
/repo/gcc-trunk/gcc/haifa-sched.c:7122
0xcf85bd compute_priorities()
/repo/gcc-trunk/gcc/sched-rgn.c:3023
0xcfb995 schedule_region
/repo/gcc-trunk/gcc/sched-rgn.c:3116
0xcfb995 schedule_insns()
/repo/gcc-trunk/gcc/sched-rgn.c:3516
0xcfc1ed schedule_insns()
/repo/gcc-trunk/gcc/sched-rgn.c:3501
0xcfc1ed rest_of_handle_sched2
/repo/gcc-trunk/gcc/sched-rgn.c:3740
0xcfc1ed execute
/repo/gcc-trunk/gcc/sched-rgn.c:3876
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.


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

[Bug ipa/85421] [8 regression] internal compiler error: in ipa_propagate_frequency, at ipa-profile.c:405

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 CC||jakub at gcc dot gnu.org
 Resolution|--- |FIXED

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

[Bug c++/63579] New attribute for empty member optimization

[glisse at gcc dot gnu.org]

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

--- Comment #4 from Marc Glisse  ---
The following was adopted for C++20
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0840r2.html

ABI description (not merged yet)
https://github.com/itanium-cxx-abi/cxx-abi/pull/50