[Bug other/90403] New: __target_clones__ should directly call other __target_clones__ functions, as appropiate

[slandden at gmail dot com]

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

Bug ID: 90403
   Summary: __target_clones__ should directly call other
__target_clones__ functions, as appropiate
   Product: gcc
   Version: 8.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: slandden at gmail dot com
  Target Milestone: ---

If I define two functions that both use the target_clones attribute, and list
the same architectures, when they call each other they still call each other
through the resolver, and the symbol table. This is unnecessary. They should
instead call the version that matches the caller.

[Bug tree-optimization/90402] New: [9/10 Regression] ICE in slpeel_duplicate_current_defs_from_edges

[asolokha at gmx dot com]

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

Bug ID: 90402
   Summary: [9/10 Regression] ICE in
slpeel_duplicate_current_defs_from_edges
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---
Target: x86_64-unknown-linux-gnu-gcc

1.

gcc-10.0.0-alpha20190505 snapshot (r270883) ICEs when compiling the following
testcase w/ -mavx -O3:

int kn, ha;

int
c7 (void)
{
}

void
ul (int w3)
{
  kn = c7 ();

  while (w3 < 1)
{
  ha += !!kn ? 1 : w3;

  for (kn = 0; kn < 2; ++kn)
{
}

  ++w3;
}
}

% x86_64-unknown-linux-gnu-gcc-10.0.0-alpha20190505 -mavx -O3 -c mmoxyagz.c
during GIMPLE pass: vect
mmoxyagz.c: In function 'ul':
mmoxyagz.c:9:1: internal compiler error: in
slpeel_duplicate_current_defs_from_edges, at tree-vect-loop-manip.c:979
9 | ul (int w3)
  | ^~
0x6d slpeel_duplicate_current_defs_from_edges
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190505/work/gcc-10-20190505/gcc/tree-vect-loop-manip.c:979
0xf70004 slpeel_tree_duplicate_loop_to_edge_cfg(loop*, loop*, edge_def*)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190505/work/gcc-10-20190505/gcc/tree-vect-loop-manip.c:1077
0xf73d4b vect_do_peeling(_loop_vec_info*, tree_node*, tree_node*, tree_node**,
tree_node**, tree_node**, int, bool, bool)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190505/work/gcc-10-20190505/gcc/tree-vect-loop-manip.c:2609
0xf5952b vect_transform_loop(_loop_vec_info*)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190505/work/gcc-10-20190505/gcc/tree-vect-loop.c:8370
0xf8668b try_vectorize_loop_1
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190505/work/gcc-10-20190505/gcc/tree-vectorizer.c:979
0xf870dd vectorize_loops()
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190505/work/gcc-10-20190505/gcc/tree-vectorizer.c:

2.

When compiling the following testcase w/ -O3 -fopenmp -fno-code-hoisting
-fno-tree-copy-prop -fno-tree-dce -fno-tree-pre, gcc ICEs at
tree-vect-loop-manip.c:985 instead:

struct fq {
  int cg;
};

struct fq jr;

int
p8 (struct fq *yo, struct fq *ab)
{
  return !!yo->cg || !!ab->cg;
}

void
k6 (void)
{
  int py;
  int v3[6];

  for (py = 0; py < 6; ++py)
v3[py] = (py % 3 != 1) + 1;

#pragma omp declare reduction (* : struct fq : p8 (_out, _in))
#pragma omp parallel reduction (task, * : jr)
  if (!!py)
{
}
}

[Bug preprocessor/90400] _Pragma not always expanded in the right location within macros

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #1 from Eric Gallager  ---
I think there's another bug like this; forget its number right now though...

[Bug middle-end/78998] missing -Wnonnull for an unconditional call to strlen with a null argument

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||dmalcolm at gcc dot gnu.org,
   ||dodji at gcc dot gnu.org

--- Comment #3 from Eric Gallager  ---
cc-ing diagnostics maintainers

[Bug c++/80684] poor error message and fix-it hint for a function with an argument of undeclared type

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||dodji at gcc dot gnu.org

--- Comment #2 from Eric Gallager  ---
cc-ing other diagnostics maintainer

[Bug ipa/90401] New: Missed propagation of by-ref constant argument to callee function

[fxue at os dot amperecomputing.com]

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

Bug ID: 90401
   Summary: Missed propagation of by-ref constant argument to
callee function
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fxue at os dot amperecomputing.com
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

Created attachment 46318
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46318=edit
The case that ipa_cp is failed on by_ref constant argument

IPA-cp can not identify a constant by-ref argument to a function, if value
definition of the argument is not in same basic block where the callsite lies
in. In Fortran, this is very common that a constant function argument is placed
in a local variable instead of literal constant.

The following is a C++ case, compiling option is "-O3 -fno-inline", here using
"-fno-inline" to give a change for ipa-cp on small function.

If we move the statement "int a = 1" from inside conditional block to begin of
function, ipa-cp fails to do function versioning on "callee()".

int data;

int callee(int )
{
if (v < 2) {
return 0;
} else {
data = v;
return 1;
}
}

int caller(int c, int )
{
// int a = 1;   <.   /* ipa-cp on callee(), failed */  
 |
if (c) { |
//  int a = 1;  -'   /* ipa-cp on callee(), ok */ 

return callee(a);
} else {
r = 1;
return callee(r);
}
}

[Bug tree-optimization/57534] [7/8/9/10 Regression]: Performance regression versus 4.7.3, 4.8.1 is ~15% slower

[amker at gcc dot gnu.org]

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

--- Comment #34 from bin cheng  ---
So we could have three different addressing modes here.
  1. What we have now:
leaq0(,%rbp,8), %rax
movsd   8(%rbx,%rax), %xmm0
addsd   (%rbx,%rbp,8), %xmm0
addq$8, %rbp
addsd   16(%rbx,%rax), %xmm0
addsd   24(%rbx,%rax), %xmm0
addsd   %xmm0, %xmm1
movsd   32(%rbx,%rax), %xmm0
addsd   40(%rbx,%rax), %xmm0
addsd   48(%rbx,%rax), %xmm0
addsd   56(%rbx,%rax), %xmm0
addsd   %xmm0, %xmm2
cmpq%rsi, %rbp
  2. GCC-4.7:
fldl   (%esi,%ebx,8)
lea0x8(%ebx),%eax
faddl  0x8(%esi,%ebx,8)
cmp%eax,%edi
faddl  0x10(%esi,%ebx,8)
faddl  0x18(%esi,%ebx,8)
faddp  %st,%st(2)
fldl   0x20(%esi,%ebx,8)
faddl  0x28(%esi,%ebx,8)
faddl  0x30(%esi,%ebx,8)
faddl  0x38(%esi,%ebx,8)
faddp  %st,%st(1)
  3. With slsr change:
leaq0(%rbp,%rbx,8), %rax
addq$8, %rbx
movsd   (%rax), %xmm0
addsd   8(%rax), %xmm0
addsd   16(%rax), %xmm0
addsd   24(%rax), %xmm0
addsd   %xmm0, %xmm1
movsd   32(%rax), %xmm0
addsd   40(%rax), %xmm0
addsd   48(%rax), %xmm0
addsd   56(%rax), %xmm0
addsd   %xmm0, %xmm2
cmpq%rsi, %rbx

This was reported that 2. is better than 1.  Also Jeff recommended 3.

What I don't understand are:
A) why 2. is better than 1.?  It seems to have more computations in address.
B) Is 3. the best one?  It has the simplest addressing mode, but does require
one additional lea because of strength reduction.

Thanks.

[Bug c++/87847] spec_hasher::hash does not match with spec_hasher::equal

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek  ---
An idea would be to hash TEMPLATE_TEMPLATE_PARMs differently in
iterative_hash_template_arg: hash its TEMPLATE_TYPE_PARM_INDEX and
TEMPLATE_TEMPLATE_PARM_TEMPLATE_DECL, so that when they compare equal, they
hash equal.

[Bug target/89271] [9/10 Regression] gcc.target/powerpc/vsx-simode2.c stopped working in GCC 9

[amodra at gmail dot com]

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

Alan Modra  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|9.2 |10.0

--- Comment #24 from Alan Modra  ---
Fixed for gcc-10.

[Bug c++/90349] missing return with turned on 03 causes infinite loop

[pinskia at gcc dot gnu.org]

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

--- Comment #4 from Andrew Pinski  ---
(In reply to Darryl Okahata from comment #3)
> If it weren't for the false positives, I'd suggest making this an error when
> optimization is used.  

In C/C++ requires no diagnostic on runtime undefined code 
as it might not be executed.

[Bug driver/90392] [9/10 Regression] Assertion failure in ldlang.c:6868 when compiling with -flto

[ohaiziejohwahkeezuoz at xff dot cz]

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

--- Comment #4 from ohaiziejohwahkeezuoz at xff dot cz ---
Without -save-temps, generated name is random. So while there's some issue
there, too, because '-ldl.res' doesn't make much sense as an output for %u.res,
it is not the cause of the assertion failure in ldlang.c:6868:

void
ldlang_add_file (lang_input_statement_type *entry)
{
  lang_statement_append (_chain,
 (lang_statement_union_type *) entry,
 >next);

  /* The BFD linker needs to have a list of all input BFDs involved in
 a link.  */
  ASSERT (entry->the_bfd->link.next == NULL);  <- line 6868
  ASSERT (entry->the_bfd != link_info.output_bfd);


I've added this code prior to the asserts:

  info_msg ("A:%pI\n", entry);
  info_msg ("B:%pB\n", entry->the_bfd);
  if (entry->the_bfd->link.next)
info_msg ("C:%pB\n", entry->the_bfd->link.next);

This results in this output (I also have -Wl,--trace enabled here):

.snip

A:/workspace/megous.com/apps-c/static-deps/toolchains/aarch64-linux-musl/lib/gcc/aarch64-linux-musl/9.0.1/crtend.o
B:/workspace/megous.com/apps-c/static-deps/toolchains/aarch64-linux-musl/lib/gcc/aarch64-linux-musl/9.0.1/crtend.o
attempt to open
/workspace/megous.com/apps-c/static-deps/toolchains/aarch64-linux-musl/lib/gcc/aarch64-linux-musl/9.0.1/../../../../aarch64-linux-musl/lib/crtn.o
succeeded
/workspace/megous.com/apps-c/static-deps/toolchains/aarch64-linux-musl/lib/gcc/aarch64-linux-musl/9.0.1/../../../../aarch64-linux-musl/lib/crtn.o
A:/workspace/megous.com/apps-c/static-deps/toolchains/aarch64-linux-musl/lib/gcc/aarch64-linux-musl/9.0.1/../../../../aarch64-linux-musl/lib/crtn.o
B:/workspace/megous.com/apps-c/static-deps/toolchains/aarch64-linux-musl/lib/gcc/aarch64-linux-musl/9.0.1/../../../../aarch64-linux-musl/lib/crtn.o
apps/libapps.a
./libssl.a
./libcrypto.a
A:armcap.o
B:armcap.o (symbol from plugin)
C:a_bitstr.o (symbol from plugin)
/workspace/megous.com/apps-c/static-deps/toolchains/aarch64-linux-musl/lib/gcc/aarch64-linux-musl/9.0.1/../../../../aarch64-linux-musl/bin/ld:
internal error
/workspace/megous.com/apps-c/static-deps/toolchains/sources/binutils-gdb/ld/ldlang.c
6873

That is, as soon as libcrypto.a starts being linked, ldlang_add_file() gets
called from here:

  /* We don't call ldlang_add_file for an archive.  Instead, the
 add_symbols entry point will call ldlang_add_file, via the
 add_archive_element callback, for each element of the archive
 which is used.  */
  switch (bfd_get_format (entry->the_bfd))
{
default:
  break;

case bfd_object:
  if (!entry->flags.reload)
ldlang_add_file (entry);
  break;

but it receives something it doesn't expect in entry->the_bfd->link.next.

[Bug c++/90349] missing return with turned on 03 causes infinite loop

[darryl_okahata at keysight dot com]

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

Darryl Okahata  changed:

   What|Removed |Added

 CC||darryl_okahata at keysight dot 
com

--- Comment #3 from Darryl Okahata  ---
The warning really should be turned on by default, with perhaps just the
slightest hint that stunningly awesome unexpected optimized code might be
generated.

If it weren't for the false positives, I'd suggest making this an error when
optimization is used.  For those of us who merely use compilers (as opposed to
those of you who develop them), this appears to be such a POLA violation.  Yes,
it's a bug in our code, and the code must really be fixed, but you really need
to slap us in the face, punch us in the stomach, and kick us in the rear to
emphasize just how big a problem this is.

Otherwise, "Meh, it's just a warning".

[Bug target/89271] [9/10 Regression] gcc.target/powerpc/vsx-simode2.c stopped working in GCC 9

[amodra at gcc dot gnu.org]

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

--- Comment #23 from Alan Modra  ---
Author: amodra
Date: Wed May  8 23:07:26 2019
New Revision: 271022

URL: https://gcc.gnu.org/viewcvs?rev=271022=gcc=rev
Log:
[RS6000] PR89271, gcc.target/powerpc/vsx-simode2.c

This patch makes a number of corrections to rs6000_register_move_cost,
adds a new register union class, GEN_OR_VSX_REGS, and adjusts insn
alternative costs to suit.

The patch initially just corrected register move cost when direct
moves are available, but that resulted in regressions.  Inspection of
those regressions showed ALL_REGS being used as the register allocno
class, which isn't ideal.  gcc/doc/tm.texi says: "You should define a
class for the union of two classes whenever some instruction allows
both classes".  Thus, define GEN_OR_VSX_REGS for the register
allocator.  (IRA wants to use the union of two register classes when
the costs of the classes are below memory cost, which happens more
often with the low direct move cost.)

As per https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89271#c11 we ought
to be returning the minimal cost for union classes.  That can be done
by rs6000_register_move_cost testing for vsx first, where the number
of regs for a given mode might be smaller than the same mode in gprs,
and changing the LINK_OR_CTR_REGS case to exclude SPEC_OR_GEN_REGS and
NON_FLOAT_REGS.

I removed the VECTOR_MEM_VSX_P test since that leads to silly results
for scalar mode moves between altivec and float when TARGET_VSX.  eg.
rs6000_register_move_cost:, ret=2, mode=DF, from=FLOAT_REGS, to=FLOAT_REGS
rs6000_register_move_cost:, ret=16, mode=DF, from=FLOAT_REGS, to=ALTIVEC_REGS
rs6000_register_move_cost:, ret=2, mode=DF, from=FLOAT_REGS, to=VSX_REGS

The patch also fixes wrong results for moves within and between any of
the non-gpr, non-vsx special reg classes.  The comment about "moving
between two similar registers is just one instruction" is false.  We
can't move lr to ctr directly, for example.  I believe the intent of
the "reg_classes_intersect_p (to, from)" was to cover moves within
float or altivec, so I moved that test inside the code handling vsx,
and made sure the intersection wasn't anything besides vsx by masking
off everything else.  Masking isn't strictly necessary at the moment,
but would be if we create a GEN_OR_ALTIVEC_REGS class some time in the
future.

TARGET_IRA_CHANGE_PSEUDO_ALLOCNO_CLASS is needed for rs6000 in order
to fix the 20% cactus_adm spec regression when using GEN_OR_VSX_REGS
as an allocno class.  It is similar to the aarch64 version but without
any selection by regno mode if the best class is a union class.

PR target/89271
* config/rs6000/rs6000.h (enum reg_class, REG_CLASS_NAMES),
(REG_CLASS_CONTENTS): Add GEN_OR_VSX_REGS class.
* config/rs6000/rs6000.c (rs6000_register_move_cost): Correct
cost for general <-> vsx when direct moves are available.
Cost union classes at minimal cost for any reg in the class.
Correct calculation for moves between vsx, float, and altivec.
Don't return a low cost for moves between special regs.  Don't
use hard coded register numbers.
(TARGET_IRA_CHANGE_PSEUDO_ALLOCNO_CLASS): Define.
(rs6000_ira_change_pseudo_allocno_class): New function.
* config/rs6000/rs6000.md (movsi_internal1, mov_internal),
(movdi_internal32, movdi_internal64): Remove '*' from vsx register
alternatives.
(movsi_internal1): Don't disparage vector alternatives.
(mov_internal): Likewise, excepting alternative that
will be split.
* config/rs6000/vsx.md (vsx_splat__reg): Don't disparage
we <- b alternative.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/rs6000.c
trunk/gcc/config/rs6000/rs6000.h
trunk/gcc/config/rs6000/rs6000.md
trunk/gcc/config/rs6000/vsx.md

[Bug target/89424] __builtin_vec_ext_v1ti (v, i) results in ICE with variable i (RS6000)

[kelvin at gcc dot gnu.org]

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

--- Comment #3 from kelvin at gcc dot gnu.org ---
Author: kelvin
Date: Wed May  8 22:23:11 2019
New Revision: 271020

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

2019-05-08  Kelvin Nilsen  

Backport from mainline.
2019-05-06  Kelvin Nilsen  

PR target/89424
* config/rs6000/rs6000.c (rs6000_expand_vector_extract): Add
handling of V1TImode.

gcc/testsuite/ChangeLog:

2019-05-08  Kelvin Nilsen  

Backport from mainline.
2019-05-06  Kelvin Nilsen  

PR target/89424
* gcc.target/powerpc/pr89424-0.c: New test.
* gcc.target/powerpc/vsx-builtin-13a.c: Define macro PR89424 to
enable testing of newly patched capability.
* gcc.target/powerpc/vsx-builtin-13b.c: Likewise.
* gcc.target/powerpc/vsx-builtin-20a.c: Likewise.
* gcc.target/powerpc/vsx-builtin-20b.c: Likewise.


Added:
branches/gcc-8-branch/gcc/testsuite/gcc.target/powerpc/pr89424-0.c
Modified:
branches/gcc-8-branch/gcc/ChangeLog
branches/gcc-8-branch/gcc/config/rs6000/rs6000.c
branches/gcc-8-branch/gcc/testsuite/ChangeLog
branches/gcc-8-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-13a.c
branches/gcc-8-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-13b.c
branches/gcc-8-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-20a.c
branches/gcc-8-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-20b.c

[Bug tree-optimization/90394] [10 Regression] ICE in is_value_included_in, at tree-ssa-uninit.c:1055

[dcb314 at hotmail dot com]

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

--- Comment #1 from David Binderman  ---
Bug seems to start someplace between revision 270600 and 270750.

[Bug fortran/90329] Incompatibility between gfortran and C lapack calls

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

   See Also||https://github.com/Referenc
   ||e-LAPACK/lapack/issues/339

--- Comment #23 from Thomas Koenig  ---
On trunk, it is now possible to generate C prototypes from
Fortran source code for external procedures.  Applying
this to dlapack.f in the R source tree yields something like
this (just grabbing a few lines)

$ gfortran -fsyntax-only -fc-prototypes-external dlapack.f 

[...]

void dtpqrt2_ (int *m, int *n, int *l, double *a, int *lda, double *b, int
*ldb, double *t, int *ldt, int *info);
void dlarfg_ (int *n, double *alpha, double *x, int *incx, double *tau);
void dlatps_ (char *uplo, char *trans, char *diag, char *normin, int *n, double
*ap, double *x, double *scale, double *cnorm, int *info, size_t uplo_len,
size_t trans_len, size_t diag_len, size_t normin_len);
double dlantp_ (char *norm, char *uplo, char *diag, int *n, double *ap, double
*work, size_t norm_len, size_t uplo_len, size_t diag_len);
void dlatbs_ (char *uplo, char *trans, char *diag, char *normin, int *n, int
*kd, double *ab, int *ldab, double *x, double *scale, double *cnorm, int *info,
size_t uplo_len, size_t trans_len, size_t diag_len, size_t normin_len);
double dlantb_ (char *norm, char *uplo, char *diag, int *n, int *k, double *ab,
int *ldab, double *work, size_t norm_len, size_t uplo_len, size_t diag_len);

Looking for _len yields 236 lines, that is probably the number of
subroutines and functions which would need to be adapted.

[Bug fortran/90351] -fc-prototypes does not dump prototypes for external procedures

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

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

--- Comment #2 from Thomas Koenig  ---
Fixed, closing.

[Bug preprocessor/90400] New: _Pragma not always expanded in the right location within macros

[remi at machet dot us]

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

Bug ID: 90400
   Summary: _Pragma not always expanded in the right location
within macros
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: preprocessor
  Assignee: unassigned at gcc dot gnu.org
  Reporter: remi at machet dot us
  Target Milestone: ---

When the preprocessor does not understand the pragma inside _Pragma it calls
cb_def_pragma to print it (converting it to '#pragma'). Unfortunately that
function uses puts() to print the pragma directly to file.

If we are within a macro being expanded inside another macro then this will
results in all pragma within that macro being expanded at the top instead of at
their original location within the macro.

For example I would expect the following test to pass:
/* { dg-do assemble }
 * { dg-additional-options "-save-temps -Wall" }
 */


extern int b;

#define OUTPUT(stmt) \
  stmt

#define WITH_PRAGMA() \
  _Pragma("GCC diagnostic push"); \
  _Pragma("GCC diagnostic ignored \"-Wmaybe-uninitialized\""); \
  a--; \
  _Pragma("GCC diagnostic pop")


int main()
{
  int a;

  if (b) {
b++;
  }
  OUTPUT( else {
b--;
WITH_PRAGMA();
  } )
}

Instead with trunk gcc I get:
test.c: In function 'main':
test.c:28:3: error: 'else' without a previous 'if'

Because the pragma statements are printed right at the beginning of output
instead of where WITH_PRAGMA is.

[Bug fortran/90329] Incompatibility between gfortran and C lapack calls

[tkoenig at gcc dot gnu.org]

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

--- Comment #22 from Thomas Koenig  ---
Author: tkoenig
Date: Wed May  8 21:55:13 2019
New Revision: 271018

URL: https://gcc.gnu.org/viewcvs?rev=271018=gcc=rev
Log:
2019-05-08  Thomas Koenig  

PR fortran/90351
PR fortran/90329
* gfortran.dg/dump-parse-tree.c: Include version.h.
(gfc_dump_external_c_prototypes): New function.
(get_c_type_name): Select "char" as a name for a simple char.
Adjust to handling external functions. Also handle complex.
(write_decl): Add argument bind_c. Adjust for dumping of external
procedures.
(write_proc): Likewise.
(write_interop_decl): Add bind_c argument to call of write_proc.
* gfortran.h: Add prototype for gfc_dump_external_c_prototypes.
* lang.opt: Add -fc-prototypes-external flag.
* parse.c (gfc_parse_file): Move dumping of BIND(C) prototypes.
Call gfc_dump_external_c_prototypes if option is set.
* invoke.texi: Document -fc-prototypes-external.


Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/dump-parse-tree.c
trunk/gcc/fortran/gfortran.h
trunk/gcc/fortran/invoke.texi
trunk/gcc/fortran/lang.opt
trunk/gcc/fortran/parse.c

[Bug fortran/90351] -fc-prototypes does not dump prototypes for external procedures

[tkoenig at gcc dot gnu.org]

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

--- Comment #1 from Thomas Koenig  ---
Author: tkoenig
Date: Wed May  8 21:55:13 2019
New Revision: 271018

URL: https://gcc.gnu.org/viewcvs?rev=271018=gcc=rev
Log:
2019-05-08  Thomas Koenig  

PR fortran/90351
PR fortran/90329
* gfortran.dg/dump-parse-tree.c: Include version.h.
(gfc_dump_external_c_prototypes): New function.
(get_c_type_name): Select "char" as a name for a simple char.
Adjust to handling external functions. Also handle complex.
(write_decl): Add argument bind_c. Adjust for dumping of external
procedures.
(write_proc): Likewise.
(write_interop_decl): Add bind_c argument to call of write_proc.
* gfortran.h: Add prototype for gfc_dump_external_c_prototypes.
* lang.opt: Add -fc-prototypes-external flag.
* parse.c (gfc_parse_file): Move dumping of BIND(C) prototypes.
Call gfc_dump_external_c_prototypes if option is set.
* invoke.texi: Document -fc-prototypes-external.


Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/dump-parse-tree.c
trunk/gcc/fortran/gfortran.h
trunk/gcc/fortran/invoke.texi
trunk/gcc/fortran/lang.opt
trunk/gcc/fortran/parse.c

[Bug libgcc/90399] split-stack + shared library + static object construction (C++)

[mkarsten at uwaterloo dot ca]

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

--- Comment #2 from Martin Karsten  ---
I single-stepped through the call

   0x77fc71f5 <+107>: callq  0x77fc7040
<__splitstack_makecontext@plt>

and via indirect rip-relative addressing, it ends up at the (executable)
__splitstack_makecontext() instance at 0x6379.

That at least explains my initial confusion related to gdb output.

It still leaves open the broader question about the two copies of split-stack
code/variables not playing nicely with each other.

[Bug libstdc++/90397] Incompatibility with clang-tidy on std::variant

[philip.salvaggio at mac dot com]

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

--- Comment #3 from philip.salvaggio at mac dot com ---
Yep! I added the noexcept on there on my local version and that also resolved
the issue.

[Bug libgcc/90399] split-stack + shared library + static object construction (C++)

[mkarsten at uwaterloo dot ca]

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

--- Comment #1 from Martin Karsten  ---
Sorry, I accidentally included a version of the Makefile that I had used for
testing and that contains the flag '-nodefaultlibs' when building the library.
This leads to other problems. The correct Makefile is:

CXXFLAGS=-fPIC -fsplit-stack

main: main.o libtest.so
  g++ $< -o $@ -L. -ltest

works: main.o test.o
  g++ $^ -o $@

libtest.so: test.o
  g++ -shared $^ -o $@

clean:
  rm -f main works main.o test.o libtest.so

[Bug target/90379] Gcc 9.1 fails "make check" on linux due to missing MacOS-specific header file

[iains at gcc dot gnu.org]

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

--- Comment #7 from Iain Sandoe  ---
Created attachment 46317
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46317=edit
Don't provide test_text for wrap fixes.

The problem here is that the version I applied still had "test_text" set to a
non-empty string, which isn't going to work.  Unfortunately, this wasn't
noticed on either Darwin or Linux before 9.1 released (the fixincludes tests
don't show in test summaries).

This update works for me on Linux and Darwin

[Bug tree-optimization/89060] Improve tail call optimization

[bugdal at aerifal dot cx]

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

--- Comment #8 from Rich Felker  ---
With the above commit, should this problem be fixed?

[Bug libgcc/90399] New: split-stack + shared library + static object construction (C++)

[mkarsten at uwaterloo dot ca]

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

Bug ID: 90399
   Summary: split-stack + shared library + static object
construction (C++)
   Product: gcc
   Version: 8.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgcc
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mkarsten at uwaterloo dot ca
  Target Milestone: ---

Created attachment 46316
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46316=edit
example code and gdb output

I am building a shared library that internally uses split-stack and calls
__splitstack_makecontext() during construction of a static object. At runtime,
there seem to be two copies of split-stack code/variables (from libgcc.a) in
play - one that is added to the shared libray and another one that is added to
the executable. When the program is started, the following seems to happen:

- shared library copy of '__morestack_load_mmap()' initializes its copy of
'static_pagesize'

- however, the first call to '__splitstack_makecontext()' ends up in the other
instance where 'static_pagesize' is not initialized, thus 0, thus the
allocation fails and the program terminates with:

  unable to allocate additional stack space: errno 22

Interestingly, gdb disassembly claims that the correct version of
__splitstack_makecontext() should be called. The stack backtrace shows that the
(executable) version

#3  0x6379 in __splitstack_makecontext ()

is called, despite the disassembly output claiming that the (shared library)
version would be called:

   0x77fc71f5 <+107>: callq  0x77fc7040
<__splitstack_makecontext@plt>

I am attaching a small example with Makefile and gdb output from triggering the
error. The bug can only be reproduced with multiple files, so I am attaching a
tgz archive. The same code works fine when avoiding the shared library (see
'make works' target in Makefile).

I have seen this with various versions of gcc on various Linux platforms
(Ubuntu and Arch). My most recent testing is with the packaged gcc 8.3.0 on
Arch Linux:

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/8.3.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gConfigured 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
--enable-cet=autocc/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
--enable-cet=auto
Thread model: posix
gcc version 8.3.0 (GCC) 

Please let me know, if you need further information.

[Bug c++/90397] Incompatibility with clang-tidy on std::variant

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
   Target Milestone|--- |9.2

[Bug c++/90397] Incompatibility with clang-tidy on std::variant

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-05-08
 Ever confirmed|0   |1

--- Comment #2 from Jonathan Wakely  ---
No, it should be added to the friend declaration. I missed the friend
declaration when I added 'noexcept' elsewhere in r270501.

[Bug c++/90397] Incompatibility with clang-tidy on std::variant

[philip.salvaggio at mac dot com]

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

--- Comment #1 from philip.salvaggio at mac dot com ---
I was able to rectify the issue by removing the noexcept in  on line
263. I assume, that would imply that the noexcept's on the other overloads
would also need to be removed.

[Bug c++/90398] New: Segmentation fault when using [[assert]] and -fno-exception

[moussu.robin at pm dot me]

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

Bug ID: 90398
   Summary: Segmentation fault when using [[assert]] and
-fno-exception
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: moussu.robin at pm dot me
  Target Milestone: ---

Reproduce error with https://godbolt.org/z/cjlS79
gcc version: 9.0.1 (concept branch)

The following code, when compiled with
-std=c++2a -O3 -fno-exceptions
has a segmentation fault

```
void foo() {
[[assert: true]] // same thing with false, and if using a variable
}
```

: In function 'void foo()':
:3:17: internal compiler error: Segmentation fault
3 | [[assert: true]]
  |^

Note: it may be related with that bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90396

[Bug c++/90397] New: Incompatibility with clang-tidy on std::variant

[philip.salvaggio at mac dot com]

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

Bug ID: 90397
   Summary: Incompatibility with clang-tidy on std::variant
   Product: gcc
   Version: 9.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: philip.salvaggio at mac dot com
  Target Milestone: ---

Created attachment 46315
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46315=edit
Minimal example

Since upgrading to GCC 9.1.1, I am getting the following errors when running
clang-tidy (8.0.0) on this minimal example. Not sure whether this is a bug in
the libstdc++ headers or in clang, but it seems to be related to the noexcept
specifier on __get(). The code compiles fine with g++.


#include 

int main() {
  std::variant v;
  v = 5;

  int i = std::get(v);
  return 0;
}

In order to reproduce from the zipped folder:

mkdir build && cd build
cmake ..
make
clang-tidy ../example.cpp

give the following errors for me.


[build]$ clang-tidy ../example.cpp
6 errors generated.
Error while processing /home/fedora/example/build/../example.cpp.
/usr/lib/gcc/x86_64-redhat-linux/9/../../../../include/c++/9/variant:266:10:
error: cannot cast 'const std::variant' to its private base class
'std::__detail::__variant::_Variant_storage'
[clang-diagnostic-error]
  std::forward<_Variant>(__v)._M_u);
  ^
/usr/lib/gcc/x86_64-redhat-linux/9/../../../../include/c++/9/variant:1610:35:
note: in instantiation of function template specialization
'std::__detail::__variant::__get<0, const std::variant &>'
requested here
  return __detail::__variant::__get<_Np>(__v);
  ^
/usr/lib/gcc/x86_64-redhat-linux/9/../../../../include/c++/9/variant:1359:11:
note: in instantiation of function template specialization 'std::get<0, int,
double>' requested here
std::get<__index>(*this) = std::forward<_Tp>(__rhs);
 ^
/home/fedora/example/example.cpp:5:5: note: in instantiation of function
template specialization 'std::variant::operator=' requested
here
  v = 5;
^
/usr/lib/gcc/x86_64-redhat-linux/9/../../../../include/c++/9/variant:1220:7:
note: constrained by private inheritance here
: private __detail::__variant::_Variant_base<_Types...>,
  ^
/usr/lib/gcc/x86_64-redhat-linux/9/../../../../include/c++/9/variant:266:10:
error: cannot cast 'std::variant' to its private base class
'std::__detail::__variant::_Variant_storage'
[clang-diagnostic-error]
  std::forward<_Variant>(__v)._M_u);
  ^
/usr/lib/gcc/x86_64-redhat-linux/9/../../../../include/c++/9/variant:1588:35:
note: in instantiation of function template specialization
'std::__detail::__variant::__get<0, std::variant &>' requested
here
  return __detail::__variant::__get<_Np>(__v);
  ^
/usr/lib/gcc/x86_64-redhat-linux/9/../../../../include/c++/9/variant:1061:19:
note: in instantiation of function template specialization 'std::get<0, int,
double>' requested here
  return std::get<__detail::__variant::__index_of_v<_Tp, _Types...>>(__v);
  ^
/home/fedora/example/example.cpp:7:16: note: in instantiation of function
template specialization 'std::get' requested here
  int i = std::get(v);
   ^
/usr/lib/gcc/x86_64-redhat-linux/9/../../../../include/c++/9/variant:1220:7:
note: constrained by private inheritance here
: private __detail::__variant::_Variant_base<_Types...>,
  ^
/usr/lib/gcc/x86_64-redhat-linux/9/../../../../include/c++/9/variant:266:38:
error: '_M_u' is a private member of
'std::__detail::__variant::_Variant_storage'
[clang-diagnostic-error]
  std::forward<_Variant>(__v)._M_u);
  ^
/usr/lib/gcc/x86_64-redhat-linux/9/../../../../include/c++/9/variant:1220:7:
note: constrained by private inheritance here
: private __detail::__variant::_Variant_base<_Types...>,
  ^
/usr/lib/gcc/x86_64-redhat-linux/9/../../../../include/c++/9/variant:453:34:
note: member is declared here
  _Variadic_union<_Types...> _M_u;
 ^
/usr/lib/gcc/x86_64-redhat-linux/9/../../../../include/c++/9/variant:1359:31:
error: cannot assign to return value because function 'get<0, int, double>'
returns a const value [clang-diagnostic-error]
std::get<__index>(*this) = std::forward<_Tp>(__rhs);
 ^
/home/fedora/example/example.cpp:5:5: note: in instantiation of function
template specialization 'std::variant::operator=' requested
here
  v = 5;
^
/usr/lib/gcc/x86_64-redhat-linux/9/../../../../include/c++/9/variant:134:15:
note: function 'get<0, int, double>' which returns const-qualified type 'const
variant_alternative_t<0UL, variant > &' (aka 'const int &')
declared 

[Bug c++/90396] New: error while using sizeof in [[assert]]: internal compiler error: in gimplify_expr, at gimplify.c:13199

[moussu.robin at pm dot me]

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

Bug ID: 90396
   Summary: error while using sizeof in [[assert]]: internal
compiler error: in gimplify_expr, at gimplify.c:13199
   Product: gcc
   Version: 9.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: moussu.robin at pm dot me
  Target Milestone: ---

Test it directly on https://godbolt.org/z/IsXG2E

Version of the compiler: 9.0.1 (contracts branch)

The following line doesn't compile:
```
[[assert: sizeof(decltype([]{})) == sizeof(nullptr)]];
```

:5:15: internal compiler error: in gimplify_expr, at gimplify.c:13199
5 | [[assert: sizeof(decltype([]{})) == sizeof(nullptr)]];
  |   ^~

[Bug libstdc++/90370] Does 0 correspond to a POSIX errno value for std::system_category?

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
The issue is basically that the C++ Standard Library defines two categories for
error numbers known to the implementation: "generic" and "system", where the
former is for the POSIX errno values, and the latter is for other error numbers
used by the OS for other kinds of errors that aren't covered by a POSIX errno
macro (which might be other non-standard EBLAH macros that the OS adds to the
POSIX ones, or some totally different error numbers used by the OS, e.g.
Windows has its own error numbers unrelated to errno). The question is which
category zero belongs to.

I think there's a case to be made that although zero isn't an errno value, it's
also not an error code used by the OS to mean something different. At least for
posix-ish systems, no system API is going to use 0 for something like
EPRINTERONFIRE, because that would interfere with normal errno handling in
application code.

So although zero isn't a POSIX errno value, POSIX does "reserve" the value zero
and give it special meaning (it's the value that won't get set to report an
error). No posix-ish OS is going to give it a different meaning that clashes
with that.

I don't think the fact that glibc sometimes sets errno=0 changes that argument,
because it's not using 0 for errors, it's still using it to mean "not an
error". So although glibc shouldn't set it to zero, it doesn't change the
meaning of zero, and it can still be said to be reserved by POSIX, and so
belong to the "generic" category.

Does that make sense?

On the other hand, glibc seeing errno=0 could be considered to be an example of
"other error numbers used by the OS" outside of what POSIX says, and so it
belongs to "system". So I'm no closer to a decision!

[Bug target/90379] Gcc 9.1 fails "make check" on linux due to missing MacOS-specific header file

[iains at gcc dot gnu.org]

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

--- Comment #6 from Iain Sandoe  ---
(In reply to Jürgen Reuter from comment #5)
> I am seeing the same issue on Darwin 18.5.0 (macOSX 10.4.4) with XCode 10.2.

Yeah, likewise, I'm looking at my Darwin18 system right now.

[Bug libstdc++/90370] Does 0 correspond to a POSIX errno value for std::system_category?

[fw at gcc dot gnu.org]

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

Florian Weimer  changed:

   What|Removed |Added

 CC||fw at gcc dot gnu.org

--- Comment #2 from Florian Weimer  ---
POSIX does not say anything about value zero, except that none of its functions
sets errno to zero.  This can be used to detect errors for interfaces where
in-band signaling using the return value does not work.  ptrace with
PTRACE_PEEKUSER is a very simple example (but it's not in POSIX).

glibc sets errno to zero in certain functions:

  https://sourceware.org/bugzilla/show_bug.cgi?id=21898

Unfortunately, based on the description here I cannot tell whether the
libstdc++ choice interferes with the use of errno for these cases.  I'm happy
to discuss this further.

[Bug target/90379] Gcc 9.1 fails "make check" on linux due to missing MacOS-specific header file

[juergen.reuter at desy dot de]

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

--- Comment #5 from Jürgen Reuter  ---
I am seeing the same issue on Darwin 18.5.0 (macOSX 10.4.4) with XCode 10.2.

[Bug target/90379] Gcc 9.1 fails "make check" on linux due to missing MacOS-specific header file

[iains at gcc dot gnu.org]

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

--- Comment #4 from Iain Sandoe  ---
(In reply to Marius Maraloi from comment #2)
> (In reply to Richard Biener from comment #1)
> > You need to do 'make -k check' since some tests are always expected to fail.

> I ran 'make -k check', it produces the same result as without '-k':

'make -k check' will not alter that the fixincludes test fails, but it will
allow the check process to continue with testing other parts of the toolchain
(and is generally required as Richi says, since testing is expect to contain
some, small number, of fails usually).

[Bug gcov-profile/90380] gcov issue: gets stuck (infinite loop?) while analyzing coverage on Fortran project

[Melven.Roehrig-Zoellner at DLR dot de]

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

Melven.Roehrig-Zoellner at DLR dot de changed:

   What|Removed |Added

 CC||Melven.Roehrig-Zoellner@DLR
   ||.de

--- Comment #4 from Melven.Roehrig-Zoellner at DLR dot de ---
Hi

I have a similar problem with GCC 9.1.0, GCC 7.2.0 works fine.
(I also had problems with GCC 8.1.0 but I did not check that this is actually
the same problem).

Backtrace obtained with gdb:

zoel_ml@SC-030083L:/home_local/zoel_ml/VAST_playground_clean (gcc9_fixes)> gdb
--args gcov
/localdata2/zoel_ml/VAST_playground_clean/build/extras/Freewake-prefix/src/Freewake-build/CMakeFiles/objpostproc.dir/source/postproc/fw_postproc_module.f90.gcda
--branch-counts --branch-probabilities --preserve-paths --object-directory
/localdata2/zoel_ml/VAST_playground_clean/build/extras/Freewake-prefix/src/Freewake-build/CMakeFiles/objpostproc.dir/source/postproc
GNU gdb (GDB) 8.2.1
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-pc-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from gcov...done.
(gdb) run
Starting program:
/tools/modulesystem/tools/gcc/gcc-9.1.0/install/sled12.x86_64.gcc-4.8.5.release.combinedTree/bin/gcov
/localdata2/zoel_ml/VAST_playground_clean/build/extras/Freewake-prefix/src/Freewake-build/CMakeFiles/objpostproc.dir/source/postproc/fw_postproc_module.f90.gcda
--branch-counts --branch-probabilities --preserve-paths --object-directory
/localdata2/zoel_ml/VAST_playground_clean/build/extras/Freewake-prefix/src/Freewake-build/CMakeFiles/objpostproc.dir/source/postproc
^C
Program received signal SIGINT, Interrupt.
std::__find_if<__gnu_cxx::__normal_iterator > >,
__gnu_cxx::__ops::_Iter_equals_val > (__pred=...,
__last=..., __first=...) at
/tools/modulesystem/tools/gcc/gcc-9.1.0/build/sled12.x86_64.gcc-4.8.5.release.combinedTree/prev-x86_64-pc-linux-gnu/libstdc++-v3/include/bits/predefined_ops.h:240
240 operator()(_Iterator __it)
(gdb) bt
#0  std::__find_if<__gnu_cxx::__normal_iterator > >,
__gnu_cxx::__ops::_Iter_equals_val > (
__pred=..., __last=..., __first=...) at
/tools/modulesystem/tools/gcc/gcc-9.1.0/build/sled12.x86_64.gcc-4.8.5.release.combinedTree/prev-x86_64-pc-linux-gnu/libstdc++-v3/include/bits/predefined_ops.h:240
#1  std::__find_if<__gnu_cxx::__normal_iterator > >,
__gnu_cxx::__ops::_Iter_equals_val > (
__pred=..., __last=..., __first=...) at
/tools/modulesystem/tools/gcc/gcc-9.1.0/build/sled12.x86_64.gcc-4.8.5.release.combinedTree/prev-x86_64-pc-linux-gnu/libstdc++-v3/include/bits/stl_algo.h:161
#2  std::find<__gnu_cxx::__normal_iterator > >,
block_info const*> (__val=: 0x4d3a48, __last=...,
__first=...) at
/tools/modulesystem/tools/gcc/gcc-9.1.0/build/sled12.x86_64.gcc-4.8.5.release.combinedTree/prev-x86_64-pc-linux-gnu/libstdc++-v3/include/bits/stl_algo.h:3889
#3  unblock (u=0x4d3a48, blocked=..., block_lists=...) at
/tools/modulesystem/tools/gcc/gcc-9.1.0/src/gcc/gcov.c:725
#4  0x00405dc7 in circuit (v=, path=...,
start=start@entry=0x4cfe28, blocked=..., block_lists=..., linfo=...,
count=@0x7fffb088: 0)
at /tools/modulesystem/tools/gcc/gcc-9.1.0/src/gcc/gcov.c:775
#5  0x00405d94 in circuit (v=, path=...,
start=start@entry=0x4cfe28, blocked=..., block_lists=..., linfo=...,
count=@0x7fffb088: 0)
at /tools/modulesystem/tools/gcc/gcc-9.1.0/src/gcc/gcov.c:769
#6  0x00405d94 in circuit (v=, path=...,
start=start@entry=0x4cfe28, blocked=..., block_lists=..., linfo=...,
count=@0x7fffb088: 0)

... same line repeated ...

at /tools/modulesystem/tools/gcc/gcc-9.1.0/src/gcc/gcov.c:769
#94 0x00405d94 in circuit (v=, path=...,
start=start@entry=0x4cfe28, blocked=..., block_lists=..., linfo=...,
count=@0x7fffb088: 0)
at /tools/modulesystem/tools/gcc/gcc-9.1.0/src/gcc/gcov.c:769
#95 0x00405d94 in circuit (v=, path=...,
start=start@entry=0x4cfe28, blocked=..., block_lists=..., linfo=...,
count=@0x7fffb088: 0)
at /tools/modulesystem/tools/gcc/gcc-9.1.0/src/gcc/gcov.c:769
#96 0x00405d94 in circuit (v=, path=..., start=0x4cfe28,
blocked=..., block_lists=..., linfo=..., count=@0x7fffb088: 0) at
/tools/modulesystem/tools/gcc/gcc-9.1.0/src/gcc/gcov.c:769
#97 

[Bug tree-optimization/90395] New: [10 Regression] ICE: verify_flow_info failed (error: BB 2 cannot throw but has an EH edge)

[asolokha at gmx dot com]

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

Bug ID: 90395
   Summary: [10 Regression] ICE: verify_flow_info failed (error:
BB 2 cannot throw but has an EH edge)
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: EH, ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---
Target: x86_64-unknown-linux-gnu

gcc-10.0.0-alpha20190505 snapshot (r270883) ICEs when compiling the following
testcase at any optimization level and w/ -fexceptions -fnon-call-exceptions:

typedef int v16si __attribute__ ((__vector_size__ (64)));

void
rl (int uq)
{
  v16si qw[1];

  qw[uq] = (v16si) { uq };
}

% x86_64-unknown-linux-gnu-gcc-10.0.0-alpha20190505 -O1 -fexceptions
-fnon-call-exceptions -c u2wph7yd.c
u2wph7yd.c: In function 'rl':
u2wph7yd.c:9:1: error: BB 2 cannot throw but has an EH edge
9 | }
  | ^
during GIMPLE pass: forwprop
u2wph7yd.c:9:1: internal compiler error: verify_flow_info failed
0x902efe verify_flow_info()
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190505/work/gcc-10-20190505/gcc/cfghooks.c:265
0xc43a6c execute_function_todo
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190505/work/gcc-10-20190505/gcc/passes.c:1975
0xc44801 execute_todo
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190505/work/gcc-10-20190505/gcc/passes.c:2017

[Bug c++/90383] [9/10 Regression] GCC generates invalid constexpr copy/move assignment operators for types with trailing padding. (Again)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-05-08
 CC||jakub at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Jakub Jelinek  ---
Started with my r269078 change (but it is only rejected with -O1 and higher, at
-O0 it is accepted).  Guess because always_true isn't evaluated in constexpr
context.

[Bug tree-optimization/90394] New: [10 Regression] ICE in is_value_included_in, at tree-ssa-uninit.c:1055

[asolokha at gmx dot com]

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

Bug ID: 90394
   Summary: [10 Regression] ICE in is_value_included_in, at
tree-ssa-uninit.c:1055
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

gcc-10.0.0-alpha20190505 snapshot (r270883) ICEs when compiling the following
testcase w/ -O1 -fno-tree-fre -Wuninitialized:

int pz;
unsigned int zi;

void
uk (void)
{
  int th = 1;
  int *gw = 

  for (zi = 0; zi < 2; ++zi)
{
  int a2 = 0;

  for (zi = 0; zi < 1; ++zi)
{
  th = a2 * 2;

 og:
  for (pz = 0; pz < 1; ++pz)
{
}
}

  pz = !!*gw ? *gw : pz;
  pz = (!!th ? (pz & 1) : 0);
  if (pz == 0)
++a2;
}

  goto og;
}

% gcc-10.0.0-alpha20190505 -O1 -fno-tree-fre -Wuninitialized -c lzuj3nav.c
during GIMPLE pass: uninit
lzuj3nav.c: In function 'uk':
lzuj3nav.c:5:1: internal compiler error: in is_value_included_in, at
tree-ssa-uninit.c:1055
5 | uk (void)
  | ^~
0x6dbc8d is_value_included_in
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190505/work/gcc-10-20190505/gcc/tree-ssa-uninit.c:1055
0x6dbc8d is_value_included_in
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190505/work/gcc-10-20190505/gcc/tree-ssa-uninit.c:1017
0xf12e1c is_pred_expr_subset_of
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190505/work/gcc-10-20190505/gcc/tree-ssa-uninit.c:1494
0xf12e1c is_pred_chain_subset_of
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190505/work/gcc-10-20190505/gcc/tree-ssa-uninit.c:1527
0xf12e1c is_included_in
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190505/work/gcc-10-20190505/gcc/tree-ssa-uninit.c:1556
0xf12e1c is_superset_of
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190505/work/gcc-10-20190505/gcc/tree-ssa-uninit.c:1587
0xf12e1c is_use_properly_guarded
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190505/work/gcc-10-20190505/gcc/tree-ssa-uninit.c:2490
0xf13dba find_uninit_use
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190505/work/gcc-10-20190505/gcc/tree-ssa-uninit.c:2534
0xf13dba warn_uninitialized_phi
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190505/work/gcc-10-20190505/gcc/tree-ssa-uninit.c:2603
0xf13dba execute
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190505/work/gcc-10-20190505/gcc/tree-ssa-uninit.c:2712

[Bug c++/90393] [9/10 Regression] ICE in return statement with a conditional operator, one of the second and third arguments is throw, and the other is a const variable of a class with a nontrivial co

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Target Milestone|--- |9.2

[Bug c++/90393] [9/10 Regression] ICE in return statement with a conditional operator, one of the second and third arguments is throw, and the other is a const variable of a class with a nontrivial co

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
Without const:

struct S {
S() = default;
S(const S&) {}
};

S f() {
S m;
return true ? m : throw 0;
}

int main() {}

I see a different ICE:

90393.C: In function ‘S f()’:
90393.C:8:29: internal compiler error: in gimplify_return_expr, at
gimplify.c:1542
8 | return true ? m : throw 0;
  | ^
0xf8cf19 gimplify_return_expr
/home/mpolacek/src/gcc/gcc/gimplify.c:1542
0xfbce53 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/home/mpolacek/src/gcc/gcc/gimplify.c:12725
0xf9e8de gimplify_stmt(tree_node**, gimple**)
/home/mpolacek/src/gcc/gcc/gimplify.c:6709
0xf9de25 gimplify_cleanup_point_expr
/home/mpolacek/src/gcc/gcc/gimplify.c:6452
0xfbd63e gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/home/mpolacek/src/gcc/gcc/gimplify.c:12841
0xf9e8de gimplify_stmt(tree_node**, gimple**)
/home/mpolacek/src/gcc/gcc/gimplify.c:6709
0xf8deb3 gimplify_statement_list
/home/mpolacek/src/gcc/gcc/gimplify.c:1788
0xfbd9eb gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/home/mpolacek/src/gcc/gcc/gimplify.c:12893
0xf9e8de gimplify_stmt(tree_node**, gimple**)
/home/mpolacek/src/gcc/gcc/gimplify.c:6709
0xf8c5c5 gimplify_bind_expr
/home/mpolacek/src/gcc/gcc/gimplify.c:1356
0xfbca9b gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/home/mpolacek/src/gcc/gcc/gimplify.c:12665
0xf9e8de gimplify_stmt(tree_node**, gimple**)
/home/mpolacek/src/gcc/gcc/gimplify.c:6709
0xfc0419 gimplify_body(tree_node*, bool)
/home/mpolacek/src/gcc/gcc/gimplify.c:13673
0xfc0c0a gimplify_function_tree(tree_node*)
/home/mpolacek/src/gcc/gcc/gimplify.c:13817
0xd2b04f cgraph_node::analyze()
/home/mpolacek/src/gcc/gcc/cgraphunit.c:667
0xd2c9a2 analyze_functions
/home/mpolacek/src/gcc/gcc/cgraphunit.c:1126
0xd31a87 symbol_table::finalize_compilation_unit()
/home/mpolacek/src/gcc/gcc/cgraphunit.c:2837
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++/59813] tail-call elimination didn't fire for left-shift of char to cout

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  ---
Author: jakub
Date: Wed May  8 17:06:46 2019
New Revision: 271013

URL: https://gcc.gnu.org/viewcvs?rev=271013=gcc=rev
Log:
PR c++/59813
PR tree-optimization/89060
* tree-ssa-live.h (live_vars_map): New typedef.
(compute_live_vars, live_vars_at_stmt, destroy_live_vars): Declare.
* tree-ssa-live.c: Include gimple-walk.h and cfganal.h.
(struct compute_live_vars_data): New type.
(compute_live_vars_visit, compute_live_vars_1, compute_live_vars,
live_vars_at_stmt, destroy_live_vars): New functions.
* tree-tailcall.c: Include tree-ssa-live.h.
(live_vars, live_vars_vec): New global variables.
(find_tail_calls): Perform variable life analysis before punting.
(tree_optimize_tail_calls_1): Clean up live_vars and live_vars_vec.
* tree-inline.h (struct copy_body_data): Add eh_landing_pad_dest
member.
* tree-inline.c (add_clobbers_to_eh_landing_pad): Remove BB argument.
Perform variable life analysis to select variables that really need
clobbers added.
(copy_edges_for_bb): Don't call add_clobbers_to_eh_landing_pad here,
instead set id->eh_landing_pad_dest and assert it is the same.
(copy_cfg_body): Call it here if id->eh_landing_pad_dest is non-NULL.

* gcc.dg/tree-ssa/pr89060.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr89060.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-inline.c
trunk/gcc/tree-inline.h
trunk/gcc/tree-ssa-live.c
trunk/gcc/tree-ssa-live.h
trunk/gcc/tree-tailcall.c

[Bug tree-optimization/89060] Improve tail call optimization

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
Author: jakub
Date: Wed May  8 17:06:46 2019
New Revision: 271013

URL: https://gcc.gnu.org/viewcvs?rev=271013=gcc=rev
Log:
PR c++/59813
PR tree-optimization/89060
* tree-ssa-live.h (live_vars_map): New typedef.
(compute_live_vars, live_vars_at_stmt, destroy_live_vars): Declare.
* tree-ssa-live.c: Include gimple-walk.h and cfganal.h.
(struct compute_live_vars_data): New type.
(compute_live_vars_visit, compute_live_vars_1, compute_live_vars,
live_vars_at_stmt, destroy_live_vars): New functions.
* tree-tailcall.c: Include tree-ssa-live.h.
(live_vars, live_vars_vec): New global variables.
(find_tail_calls): Perform variable life analysis before punting.
(tree_optimize_tail_calls_1): Clean up live_vars and live_vars_vec.
* tree-inline.h (struct copy_body_data): Add eh_landing_pad_dest
member.
* tree-inline.c (add_clobbers_to_eh_landing_pad): Remove BB argument.
Perform variable life analysis to select variables that really need
clobbers added.
(copy_edges_for_bb): Don't call add_clobbers_to_eh_landing_pad here,
instead set id->eh_landing_pad_dest and assert it is the same.
(copy_cfg_body): Call it here if id->eh_landing_pad_dest is non-NULL.

* gcc.dg/tree-ssa/pr89060.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr89060.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-inline.c
trunk/gcc/tree-inline.h
trunk/gcc/tree-ssa-live.c
trunk/gcc/tree-ssa-live.h
trunk/gcc/tree-tailcall.c

[Bug target/90379] Gcc 9.1 fails "make check" on linux due to missing MacOS-specific header file

[iains at gcc dot gnu.org]

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

Iain Sandoe  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-05-08
 Ever confirmed|0   |1

--- Comment #3 from Iain Sandoe  ---
I can repeat this on gcc122, but it's not clear what's different about this
darwin-specific case that doesn't fire on others.

It's reasonable that a linux host should apply darwin-specific fixes for a
darwin cross, when the sysroot/SDK is darwin.  What seems surprising is that
the fixes are attempted when the target is not Darwin and the "sysroot" is /.

However, not sure what the behaviour is supposed to be, officially.

[Bug c++/90393] [9 Regression] ICE in return statement with a conditional operator, one of the second and third arguments is throw, and the other is a const variable of a class with a nontrivial copy

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-05-08
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Started with r260272.

[Bug driver/90392] [9/10 Regression] Assertion failure in ldlang.c:6868 when compiling with -flto

[ohaiziejohwahkeezuoz at xff dot cz]

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

--- Comment #3 from ohaiziejohwahkeezuoz at xff dot cz ---
Here it is:

${LDCMD:-aarch64-linux-musl-gcc} -pthread -Wa,--noexecstack -Wall -O3 -g0 -Os
-fomit-frame-pointer -Wno-implicit-fallthrough -flto -g0 -Os
-fomit-frame-pointer -Wno-implicit-fallthrough -flto -save-temps -L. 
-L/workspace/megous.com/apps-c/static-deps/output/arm64-lto/sys/usr/lib
-Wl,--start-group -static -Wl,-debug \
-o apps/openssl apps/asn1pars.o apps/ca.o apps/ciphers.o apps/cms.o
apps/crl.o apps/crl2p7.o apps/dgst.o apps/dhparam.o apps/dsa.o apps/dsaparam.o
apps/ec.o apps/ecparam.o apps/enc.o apps/engine.o apps/errstr.o apps/gendsa.o
apps/genpkey.o apps/genrsa.o apps/nseq.o apps/ocsp.o apps/openssl.o
apps/passwd.o apps/pkcs12.o apps/pkcs7.o apps/pkcs8.o apps/pkey.o
apps/pkeyparam.o apps/pkeyutl.o apps/prime.o apps/rand.o apps/rehash.o
apps/req.o apps/rsa.o apps/rsautl.o apps/s_client.o apps/s_server.o
apps/s_time.o apps/sess_id.o apps/smime.o apps/speed.o apps/spkac.o apps/srp.o
apps/storeut
l.o apps/ts.o apps/verify.o apps/version.o apps/x509.o \
 apps/libapps.a -lssl -lcrypto -ldl -pthread

[Bug libstdc++/90277] Debug Mode test failures

[fdumont at gcc dot gnu.org]

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

François Dumont  changed:

   What|Removed |Added

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

--- Comment #6 from François Dumont  ---
Tests adapted to be implementation independant

[Bug c++/90393] New: [9 Regression] ICE in return statement with a conditional operator, one of the second and third arguments is throw, and the other is a const variable of a class with a nontrivial

[jostaberry.jam at gmail dot com]

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

Bug ID: 90393
   Summary: [9 Regression] ICE in return statement with a
conditional operator, one of the second and third
arguments is throw, and the other is a const variable
of a class with a nontrivial copy constructor.
   Product: gcc
   Version: 9.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jostaberry.jam at gmail dot com
  Target Milestone: ---

This ICE occurred if the return statement is a conditional operator, one of the
second and third operands is throw, and the other is a const variable of a
class with a non-trivial copy constructor.

=== code: prog.cc ===
struct S {
S() = default;
S(const S&) {}
};

S f() {
const S m;
return true ? m : throw 0;
}

int main() {}
=== end code ===

=== command 
$ g++ ./prog.cpp
=== end command 

=== compiler output ===
prog.cc: In function 'S f()':
prog.cc:8:29: internal compiler error: in ocp_convert, at cp/cvt.c:766
8 | return true ? m : throw 0;
  | ^
0x588de1 ocp_convert(tree_node*, tree_node*, int, int, int)
../../gcc-9.1.0/gcc/cp/cvt.c:766
0x7195b2 check_return_expr(tree_node*, bool*)
../../gcc-9.1.0/gcc/cp/typeck.c:9799
0x6e87ff finish_return_stmt(tree_node*)
../../gcc-9.1.0/gcc/cp/semantics.c:894
0x68dd2d cp_parser_jump_statement
../../gcc-9.1.0/gcc/cp/parser.c:12919
0x68dd2d cp_parser_statement
../../gcc-9.1.0/gcc/cp/parser.c:11191
0x68e398 cp_parser_statement_seq_opt
../../gcc-9.1.0/gcc/cp/parser.c:11657
0x68e450 cp_parser_compound_statement
../../gcc-9.1.0/gcc/cp/parser.c:11611
0x6a49d0 cp_parser_function_body
../../gcc-9.1.0/gcc/cp/parser.c:22660
0x6a49d0 cp_parser_ctor_initializer_opt_and_function_body
../../gcc-9.1.0/gcc/cp/parser.c:22711
0x6a51b1 cp_parser_function_definition_after_declarator
../../gcc-9.1.0/gcc/cp/parser.c:27802
0x6a5e7b cp_parser_function_definition_from_specifiers_and_declarator
../../gcc-9.1.0/gcc/cp/parser.c:27718
0x6a5e7b cp_parser_init_declarator
../../gcc-9.1.0/gcc/cp/parser.c:20297
0x68b02e cp_parser_simple_declaration
../../gcc-9.1.0/gcc/cp/parser.c:13541
0x6ab1a0 cp_parser_declaration
../../gcc-9.1.0/gcc/cp/parser.c:13238
0x6ab8c9 cp_parser_translation_unit
../../gcc-9.1.0/gcc/cp/parser.c:4701
0x6ab8c9 c_parse_file()
../../gcc-9.1.0/gcc/cp/parser.c:41181
0x76605b c_common_parse_file()
../../gcc-9.1.0/gcc/c-family/c-opts.c:1156
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
=== end compiler output ===

[Bug driver/90392] [9/10 Regression] Assertion failure in ldlang.c:6868 when compiling with -flto

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||lto
  Component|lto |driver
   Target Milestone|--- |9.2
Summary|Assertion failure in|[9/10 Regression] Assertion
   |ldlang.c:6868 when  |failure in ldlang.c:6868
   |compiling with -flto|when compiling with -flto

[Bug lto/90392] Assertion failure in ldlang.c:6868 when compiling with -flto

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
It indeed should choose a temporary file name.  Can you quote the full
orginal gcc commandline?

[Bug c/56113] out of memory when compiling a function with many goto labels (50k > )

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|NEW
  Component|middle-end  |c
   Assignee|rguenth at gcc dot gnu.org |unassigned at gcc dot 
gnu.org

--- Comment #34 from Richard Biener  ---
GCC 8 takes 400MB and 11s at -O1 for 6000 and 3.5GB and 899ss for 6
where it first runs into the mentioned C parser issue (update_label_decls).

Time variable   usr   sys  wall
  GGC
 phase parsing  : 733.99 ( 82%)   5.93 ( 60%) 739.94 ( 81%)
 273812 kB ( 10%)
 phase opt and generate : 165.08 ( 18%)   3.98 ( 40%) 169.07 ( 19%)
2576743 kB ( 90%)
 parser function body   : 726.43 ( 81%)   5.44 ( 55%) 732.53 ( 81%)
 191868 kB (  7%)
 alias stmt walking :  17.95 (  2%)   1.12 ( 11%)  19.28 (  2%)
   1875 kB (  0%)
 tree PTA   :  14.61 (  2%)   0.10 (  1%)  14.73 (  2%)
   4219 kB (  0%)
 TOTAL  : 899.07  9.94909.03   
2851811 kB
899.07user 10.04system 15:09.13elapsed 99%CPU (0avgtext+0avgdata
3579512maxresident)k
0inputs+39984outputs (0major+1276027minor)pagefaults 0swaps

Re-categorizing.

[Bug libstdc++/68792] Review doxygen output and don't install useless things

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #2)
> This config setting would be a good start:
> 
> EXCLUDE_SYMBOLS= std::_[A-Z]*

Hmm, I forgot about that setting. I've been adding @cond and @endcond around
impl details to suppress them instead.

[Bug lto/90392] Assertion failure in ldlang.c:6868 when compiling with -flto

[ohaiziejohwahkeezuoz at xff dot cz]

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

--- Comment #1 from ohaiziejohwahkeezuoz at xff dot cz ---
Also, the issue did not happen with 8.3.0 and the same binutils. An I also get
this assertion when building with i686-musl-linux cross-compiler, but
interestingly, when building a differnt package (gnutls). -ffresolution=%u.res
expansion is also wrong in that case, though I'm not sure it's what causes the
assertion failure.

[Bug lto/90392] New: Assertion failure in ldlang.c:6868 when compiling with -flto

[ohaiziejohwahkeezuoz at xff dot cz]

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

Bug ID: 90392
   Summary: Assertion failure in ldlang.c:6868 when compiling with
-flto
   Product: gcc
   Version: 9.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ohaiziejohwahkeezuoz at xff dot cz
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

Hello,

I'm getting an assertion failure in ld when compiling with -flto.

The compiler is built with the exact same flags as in this bug:
  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89260

The assertion that fails is in ldlang.c:6868:

The only thing I've noticed that seems weird is that in gcc.c there is this
(notice -fresolution=%u.res):

#define LINK_PLUGIN_SPEC \
"%{" PLUGIN_COND": \
-plugin %(linker_plugin_file) \
-plugin-opt=%(lto_wrapper) \
-plugin-opt=-fresolution=%u.res \
%{flinker-output=*:-plugin-opt=-linker-output-known} \
%{!nostdlib:%{!nodefaultlibs:%:pass-through-libs(%(link_gcc_c_sequence))}}
\
}" PLUGIN_COND_CLOSE

But gcc produces this for me:

   -plugin-opt=-fresolution=-ldl.res

This seems intuitively wrong, and looks like some memory
corruption/mishandling.  %u should produce some randomly named temporary file,
instead it seems to generate output using some other part of the command line.
In this case it takes the value from the '-ldl' argument. The wrong value is
stable across multiple invocations.

It also causes issues in parallel builds because multiple parallel invocations
of gcc link step will overwrite and try to re-use the same -ldl.res file.


Full output of the compilation of openssl, where this hapens for me:

Convert string
'/workspace/megous.com/apps-c/static-deps/toolchains/aarch64-linux-musl/libexec/gcc/aarch64-linux-musl/9.0.1/:/workspace/megous.com/apps-c/static-deps/toolchains/aarch64-linux-musl/lib
exec/gcc/aarch64-linux-musl/9.0.1/:/workspace/megous.com/apps-c/static-deps/toolchains/aarch64-linux-musl/libexec/gcc/aarch64-linux-musl/:/workspace/megous.com/apps-c/static-deps/toolchains/aarch64-l
inux-musl/lib/gcc/aarch64-linux-musl/9.0.1/:/workspace/megous.com/apps-c/static-deps/toolchains/aarch64-linux-musl/lib/gcc/aarch64-linux-musl/:/workspace/megous.com/apps-c/static-deps/toolchains/aarc
h64-linux-musl/lib/gcc/aarch64-linux-musl/9.0.1/../../../../aarch64-linux-musl/bin/'
into prefixes, separator = ':'
  - add prefix:
/workspace/megous.com/apps-c/static-deps/toolchains/aarch64-linux-musl/libexec/gcc/aarch64-linux-musl/9.0.1/
  - add prefix:
/workspace/megous.com/apps-c/static-deps/toolchains/aarch64-linux-musl/libexec/gcc/aarch64-linux-musl/9.0.1/
  - add prefix:
/workspace/megous.com/apps-c/static-deps/toolchains/aarch64-linux-musl/libexec/gcc/aarch64-linux-musl/
  - add prefix:
/workspace/megous.com/apps-c/static-deps/toolchains/aarch64-linux-musl/lib/gcc/aarch64-linux-musl/9.0.1/
  - add prefix:
/workspace/megous.com/apps-c/static-deps/toolchains/aarch64-linux-musl/lib/gcc/aarch64-linux-musl/
  - add prefix:
/workspace/megous.com/apps-c/static-deps/toolchains/aarch64-linux-musl/lib/gcc/aarch64-linux-musl/9.0.1/../../../../aarch64-linux-musl/bin/
Convert string
'/workspace/megous.com/apps-c/static-deps/toolchains/aarch64-linux-musl/bin:/bin'
into prefixes, separator = ':'
  - add prefix:
/workspace/megous.com/apps-c/static-deps/toolchains/aarch64-linux-musl/bin/
  - add prefix: /bin/ 
Looking for 'real-ld' 
Looking for 'collect-ld'  
Looking for 'ld'  
Looking for 'gnm' 
Looking for 'aarch64-linux-musl-gnm'  
Looking for 'nm'  
Looking for 'gstrip'  
Looking for 'aarch64-linux-musl-gstrip'   
Looking for 'strip'   
Looking for 'aarch64-linux-musl-gcc'  
Looking for 'aarch64-linux-musl-gcc'
collect2 version 9.0.1 20190430 (prerelease)
ld_file_name=
/workspace/megous.com/apps-c/static-deps/toolchains/aarch64-linux-musl/lib/gcc/aarch64-linux-musl/9.0.1/../../../../aarch64-linux-musl/bin/ld
c_file_name =
/workspace/megous.com/apps-c/static-deps/toolchains/aarch64-linux-musl/bin/aarch64-linux-musl-gcc
nm_file_name=
/workspace/megous.com/apps-c/static-deps/toolchains/aarch64-linux-musl/lib/gcc/aarch64-linux-musl/9.0.1/../../../../aarch64-linux-musl/bin/nm
strip_file_name =
/workspace/megous.com/apps-c/static-deps/toolchains/aarch64-linux-musl/lib/gcc/aarch64-linux-musl/9.0.1/../../../../aarch64-linux-musl/bin/strip
c_file

[Bug libstdc++/90384] parallel std::transform fails to apply to all elements

[mfdeakin at cs dot unc.edu]

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

Michael Deakin  changed:

   What|Removed |Added

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

--- Comment #1 from Michael Deakin  ---
I did not realize that vector was not thread safe, so closing

[Bug c++/90391] New: nonconforming value initialization when type T has a base class with a user-defined default constructor

[mikedlui+gccbugzilla at gmail dot com]

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

Bug ID: 90391
   Summary: nonconforming value initialization when type T has a
base class with a user-defined default constructor
   Product: gcc
   Version: 9.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mikedlui+gccbugzilla at gmail dot com
  Target Milestone: ---

This is probably a low priority due to its edge-case nature, but here it is:

https://stackoverflow.com/q/54028846/1371191

#include 
struct A {
A(){}
int i;
};
struct B : public A {
int j;
};
int main() {
B b = {};
std::cout << b.i << b.j << std::endl;
}

Compiling:

$ g++ -std=c++11 -Wuninitialized -O2 a.cpp
a.cpp: In function ‘int main()’:
a.cpp:25:25: warning: ‘b.B::.A::i’ is used uninitialized in this
function [-Wuninitialized]
 std::cout << b.i << " " << b.j << std::endl


`b.B::.A::i` should be zero initialized (along with all of `b`) for
C++11, but it looks like it's getting initialized by A's default constructor
instead. This is the case for both C++11 and C++14.

As others mention in the stack overflow responses, this behavior is expected in
only expected in C++17/C++20, but for different reasons.

[Bug libstdc++/90389] std::deque::emplace tries to call wrong overload internally

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||rejects-valid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-05-08
 Ever confirmed|0   |1

[Bug rtl-optimization/59890] var-tracking.c:val_reset segfaults

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |INVALID

--- Comment #7 from Richard Biener  ---
RPO is correct for forward dataflow.

[Bug boehm-gc/90390] New: incorrect list initialization behavior for references

[mikedlui+gccbugzilla at gmail dot com]

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

Bug ID: 90390
   Summary: incorrect list initialization behavior for references
   Product: gcc
   Version: 9.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: boehm-gc
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mikedlui+gccbugzilla at gmail dot com
  Target Milestone: ---

https://stackoverflow.com/a/54120116/1371191

Example from the link:

int g_i = 10;
struct S {
operator int&(){ return g_i; }
};

int main() {
S s;
int& iref1 = s; // implicit conversion

int& iref2 = {s}; // clang++ error, g++ compiles fine:
  // `s` is converted
  // to a temporary int and binds with
  // lvalue reference

int&& iref3 = {s}; // clang++ compiles, g++ error:
   // cannot bind rvalue reference
   // to lvalue
}


Because `s` of type `S` is not reference-related to `int`, a temporary of type
`int` should be created during list initialization. Instead, it seems that the
user-defined conversion occurs first.

[Bug libstdc++/90389] New: std::deque::emplace tries to call wrong overload internally

[mikedlui+gccbugzilla at gmail dot com]

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

Bug ID: 90389
   Summary: std::deque::emplace tries to call wrong overload
internally
   Product: gcc
   Version: 9.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mikedlui+gccbugzilla at gmail dot com
  Target Milestone: ---

Example: 

#include 
#include 

struct Foo {};
struct Bar {
Bar(Foo f1, Foo f2, size_t c) {}
};

int main() {
std::deque deq;
deq.emplace(deq.cbegin(), Foo{}, Foo{}, size_t{});
}

https://godbolt.org/z/Bqw5Qv

It looks like when instantiating `std::deque::emplace`, an incorrect overload
to:

 template 
template 
  void
  deque<_Tp, _Alloc>::
  _M_insert_aux(iterator __pos,
_ForwardIterator __first, _ForwardIterator __last,
size_type __n);

is chosen instead of the expected:

 template
  typename deque<_Tp, _Alloc>::iterator
  deque<_Tp, _Alloc>::
  _M_insert_aux(iterator __pos, _Args&&... __args);

[Bug target/88167] [ARM] Function __builtin_return_address returns invalid address

[rearnsha at gcc dot gnu.org]

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

Richard Earnshaw  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |10.0

--- Comment #2 from Richard Earnshaw  ---
Fixed on trunk.

[Bug target/88167] [ARM] Function __builtin_return_address returns invalid address

[rearnsha at gcc dot gnu.org]

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

--- Comment #1 from Richard Earnshaw  ---
Author: rearnsha
Date: Wed May  8 14:36:15 2019
New Revision: 271012

URL: https://gcc.gnu.org/viewcvs?rev=271012=gcc=rev
Log:
[arm][PR88167] Fix __builtin_return_address returns invalid address

This patch fixes a problem with the thumb1 prologue code where the link
register could be unconditionally used as a scratch register even if the
return value was still live at the end of the prologue.

Additionally, the patch improves the code generated when we are not
using many low call-saved registers to make use of any unused call
clobbered registers to help with the saving of high registers that
cannot be pushed directly (quite rare in normal code as the register
allocator correctly prefers low registers).

2019-05-08  Mihail Ionescu  
Richard Earnshaw  

gcc:

PR target/88167
* config/arm/arm.c (thumb1_prologue_unused_call_clobbered_lo_regs): New
function.
(thumb1_epilogue_unused_call_clobbered_lo_regs): New function.
(thumb1_compute_save_core_reg_mask): Don't force a spare work
register if both the epilogue and prologue can use call-clobbered
regs.
(thumb1_unexpanded_epilogue): Use
thumb1_epilogue_unused_call_clobbered_lo_regs.  Reverse the logic for
picking temporaries for restoring high regs to match that of the
prologue where possible.
(thumb1_expand_prologue): Add any usable call-clobbered low registers
to
the list of work registers.  Detect if the return address is still live
at the end of the prologue and avoid using it for a work register if
so.
If the return address is not live, add LR to the list of pushable regs
after the first pass.

gcc/testsuite:

PR target/88167
* gcc.target/arm/pr88167-1.c: New test.
* gcc.target/arm/pr88167-2.c: New test.


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

[Bug target/90379] Gcc 9.1 fails "make check" on linux due to missing MacOS-specific header file

[make_distclean at yahoo dot com]

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

--- Comment #2 from Marius Maraloi  ---
(In reply to Richard Biener from comment #1)
> You need to do 'make -k check' since some tests are always expected to fail.


I ran 'make -k check', it produces the same result as without '-k':
--- snip ---
# make -k check
autogen -T ../../fixincludes/check.tpl ../../fixincludes/inclhack.def
/bin/sh ./check.sh ../../fixincludes/tests/base
Fixed:  testing.h
...
Fixed:  Xm/Traversal.h
Newly fixed header:  sys/ucred.h

There were fixinclude test FAILURES
make[2]: *** [Makefile;177: check] Error 1
--- snip ---

This makes sense, since 'fixincludes' is not one of the gcc tests per se but a
prerequisite to get to run those tests. So it cannot be an XFAIL.

[Bug tree-optimization/90387] [9 Regression] __builtin_constant_p and -Warray-bounds warnings

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-05-08
 CC||rguenth at gcc dot gnu.org
  Component|c   |tree-optimization
 Blocks||56456
   Target Milestone|--- |9.2
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
GCC indeed considers the __builtin_constant_p case here since it has not
finally committed to an answer at the point we warn for array-bound violations.

So it works as designed, even if maybe surprising.

We only commit to a final answer to __builtin_constant_p (false here)
"late" during optimization (first DOM pass which comes after the first VRP
pass).  IMHO VRP itself could do this (IIRC I pasted a patch for this
in another bug).


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456
[Bug 56456] [meta-bug] bogus/missing -Warray-bounds

[Bug libstdc++/90388] Disabled hash specialization should not be invocable

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
Alternative patch:

 operator>=(nullptr_t, const unique_ptr<_Tp, _Dp>& __x)
 { return !(nullptr < __x); }

-  /// std::hash specialization for unique_ptr.
-  template
-struct hash>
-: public __hash_base>,
-private __poison_hash::pointer>
+  template::__enable_hash_call>
+struct __uniq_ptr_hash
 {
   size_t
-  operator()(const unique_ptr<_Tp, _Dp>& __u) const noexcept
+  operator()(const _Up& __u) const
+  noexcept(noexcept(std::declval&>()(std::declval<_Ptr>(
   {
-   typedef unique_ptr<_Tp, _Dp> _UP;
-   return std::hash()(__u.get());
+   return hash<_Ptr>()(__u.get());
   }
 };

+  template
+struct __uniq_ptr_hash<_Up, _Ptr, false>
+: private __poison_hash<_Ptr>
+{ };
+
+  /// std::hash specialization for unique_ptr.
+  template
+struct hash>
+: public __hash_base>,
+  public __uniq_ptr_hash>
+{ };
+
 #if __cplusplus > 201103L

 #define __cpp_lib_make_unique 201304

[Bug libstdc++/90388] Disabled hash specialization should not be invocable

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
Patch for both issues:

@@ -830,14 +847,23 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   template
 struct hash>
 : public __hash_base>,
-private __poison_hash::pointer>
+  private __poison_hash::pointer>
 {
-  size_t
-  operator()(const unique_ptr<_Tp, _Dp>& __u) const noexcept
-  {
-   typedef unique_ptr<_Tp, _Dp> _UP;
-   return std::hash()(__u.get());
-  }
+private:
+  using __poison_base
+   = __poison_hash::pointer>;
+  template
+   using __enabled
+ = __and_>,
+  __bool_constant<__poison_base::__enable_hash_call>>;
+
+public:
+  template
+   typename enable_if<__enabled<_Up>::value, size_t>::type
+   operator()(const _Up& __u) const
+   {
+ return std::hash()(__u.get());
+   }
 };

 #if __cplusplus > 201103L

[Bug libstdc++/90388] Disabled hash specialization should not be invocable

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-05-08
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #0)
> Also, hash::operator() should not be unconditionally noexcept, because
> (if it is enabled) hash::operator() might throw
> ([util.smartptr.hash] p1).

Here's a testcase for that part, which should exit normally but calls
std::terminate():

#include 

struct D {
  struct pointer { };
  void operator()(pointer) const noexcept { }
};

bool operator==(D::pointer, std::nullptr_t) { return false; }
bool operator!=(D::pointer, std::nullptr_t) { return true; }

namespace std {
  template<> struct hash {
size_t operator()(D::pointer) const { throw 1; }
  };
}

int main()
{
  using UP = std::unique_ptr;
  UP p;
  std::hash h;
  try {
h(p);
  } catch (int) {
  }
}

[Bug libstdc++/90388] New: Disabled hash specialization should not be invocable

[redi at gcc dot gnu.org]

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

Bug ID: 90388
   Summary: Disabled hash specialization should not be invocable
   Product: gcc
   Version: 10.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: ---

[unord.hash] p4 says "Disabled specializations of hash are not function object
types" but we fail to follow that:

#include 

struct D {
  struct pointer { pointer(int*) { } };
  void operator()(pointer) const noexcept { }
};

int main()
{
  static_assert( !std::is_invocable_v&, D::pointer> );

  using UP = std::unique_ptr;
  static_assert( !std::is_invocable_v&, UP> );
}

h.cc: In function 'int main()':
h.cc:13:18: error: static assertion failed
   13 |   static_assert( !std::is_invocable_v&, UP> );
  |  ^~~~


Also, hash::operator() should not be unconditionally noexcept, because (if
it is enabled) hash::operator() might throw ([util.smartptr.hash]
p1).

[Bug libstdc++/90277] Debug Mode test failures

[fdumont at gcc dot gnu.org]

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

--- Comment #5 from François Dumont  ---
Author: fdumont
Date: Wed May  8 13:03:32 2019
New Revision: 271011

URL: https://gcc.gnu.org/viewcvs?rev=271011=gcc=rev
Log:
2019-05-08  François Dumont  

PR libstdc++/90277
* testsuite/23_containers/unordered_multiset/insert/24061-multiset.cc
(test01): Reserve for number of insertions to avoid rehash during test.
* testsuite/23_containers/unordered_multimap/insert/24061-multimap.cc
(test01): Likewise.
* testsuite/23_containers/unordered_multimap/insert/24061-multimap.cc
(test01): Likewise.
(test02): Likewise.
(test03): Likewise.

Modified:
trunk/libstdc++-v3/ChangeLog
   
trunk/libstdc++-v3/testsuite/23_containers/unordered_multimap/insert/24061-multimap.cc
   
trunk/libstdc++-v3/testsuite/23_containers/unordered_multimap/insert/hint.cc
   
trunk/libstdc++-v3/testsuite/23_containers/unordered_multiset/insert/24061-multiset.cc

[Bug c/90387] New: [9 Regression] __builtin_constant_p and -Warray-bounds warnings

[b.buschinski at googlemail dot com]

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

Bug ID: 90387
   Summary: [9 Regression] __builtin_constant_p and -Warray-bounds
warnings
   Product: gcc
   Version: 9.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: b.buschinski at googlemail dot com
  Target Milestone: ---

Created attachment 46314
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46314=edit
gcc9_constant_array_bounds_bug.c

The attached example does not compile with GCC 9.1.0.
It gives an Warray-bounds warning, which I think is invalid, as the code path
should not be triggered as the given length parameter is not compile time
const.

It worked fine with GCC 8.3.



$ gcc-8.3.0 -O2 -Wall -Werror -c gcc9_constant_array_bounds_bug.c
$ echo $?
0

$ gcc-9.1.0 -O2 -Wall -Werror -c gcc9_constant_array_bounds_bug.c 
gcc9_constant_array_bounds_bug.c: In function 'foo':
gcc9_constant_array_bounds_bug.c:6:58: error: array subscript [6, 9] is outside
array bounds of 'const char[5]' [-Werror=array-bounds]
6 | ((unsigned char*)src)[6] == ((unsigned char*)pat)[6] \
  | ~^~~
gcc9_constant_array_bounds_bug.c:22:9: note: in expansion of macro 'MY_MEMCMP'
   22 | MY_MEMCMP(p, pattern + state, p_len) == 0) {
  | ^
gcc9_constant_array_bounds_bug.c:11:23: note: while referencing 'pattern'
   11 | static char const pattern[] = "abcd";
  |   ^~~
cc1: all warnings being treated as errors
$ echo $?
1



The code also works fine if I change the "#if 1" to "#if 0", which confuses me
greatly.

It seems that (with the #if 1) GCC 9.1 treats "p_len" as compile-time constant,
which it is clearly not, as this is a function parameter. Or does
-Warray-bounds always check all paths? Regardless if they are impossible?

And yes, the warning would be correct if "p_len" would be compile-time const.

NOTE: I reduced the code from ~500+ lines to this, but I guess you can reduce
it further :)

[Bug libstdc++/89629] std::hash segfault for long strings

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |7.5

--- Comment #6 from Jonathan Wakely  ---
Fixed in 9.1, and will be fixed in 8.4 and 7.5 when they get released.

[Bug libstdc++/90105] std::forward_list::sort() is not "stable"

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |7.5

--- Comment #8 from Jonathan Wakely  ---
Fixed in 9.1, and will be fixed in 8.4 and 7.5 when they get released.

[Bug libstdc++/89629] std::hash segfault for long strings

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  ---
Author: redi
Date: Wed May  8 12:17:20 2019
New Revision: 271009

URL: https://gcc.gnu.org/viewcvs?rev=271009=gcc=rev
Log:
PR libstdc++/89629 fix _Hash_bytes for lengths > INT_MAX

Backport from mainline
2019-03-11  Jonathan Wakely  

PR libstdc++/89629
* libsupc++/hash_bytes.cc [__SIZEOF_SIZE_T__ == 8] (_Hash_bytes):
Use correct type for len_aligned.
* testsuite/20_util/hash/89629.cc: New test.

Added:
branches/gcc-7-branch/libstdc++-v3/testsuite/20_util/hash/89629.cc
Modified:
branches/gcc-7-branch/libstdc++-v3/ChangeLog
branches/gcc-7-branch/libstdc++-v3/libsupc++/hash_bytes.cc

[Bug libstdc++/90105] std::forward_list::sort() is not "stable"

[redi at gcc dot gnu.org]

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

--- Comment #7 from Jonathan Wakely  ---
Author: redi
Date: Wed May  8 12:17:26 2019
New Revision: 271010

URL: https://gcc.gnu.org/viewcvs?rev=271010=gcc=rev
Log:
PR libstdc++/90105 make forward_list::sort stable

While testing the fix I also discovered that operator== assumes the
elements are comparable with operator!= which is not required.

Backport from mainline
2019-04-17  Jonathan Wakely  

PR libstdc++/90105
* include/bits/forward_list.tcc (operator==): Do not use operator!= to
compare elements.
(forward_list::sort(Comp)): When elements are equal take the one
earlier in the list, so that sort is stable.
* testsuite/23_containers/forward_list/operations/90105.cc: New test.
* testsuite/23_containers/forward_list/comparable.cc: Test with
types that meet the minimum EqualityComparable and LessThanComparable
requirements. Remove irrelevant comment.

Added:
   
branches/gcc-7-branch/libstdc++-v3/testsuite/23_containers/forward_list/operations/90105.cc
  - copied, changed from r271009,
branches/gcc-7-branch/libstdc++-v3/testsuite/23_containers/forward_list/comparable.cc
Modified:
branches/gcc-7-branch/libstdc++-v3/ChangeLog
branches/gcc-7-branch/libstdc++-v3/include/bits/forward_list.tcc
   
branches/gcc-7-branch/libstdc++-v3/testsuite/23_containers/forward_list/comparable.cc

[Bug d/90261] FAIL: libphobos.phobos/std/file.d on CentOS 5.11, Linux 2.6.18

[ubizjak at gmail dot com]

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

--- Comment #1 from Uroš Bizjak  ---
Patch at [1].

[1] https://gcc.gnu.org/ml/gcc-patches/2019-05/msg00356.html

[Bug tree-optimization/90078] [7/8 Regression] ICE with deep templates caused by overflow

[amker at gcc dot gnu.org]

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

--- Comment #14 from bin cheng  ---
Author: amker
Date: Wed May  8 11:37:45 2019
New Revision: 271008

URL: https://gcc.gnu.org/viewcvs?rev=271008=gcc=rev
Log:
PR tree-optimization/90078
* tree-ssa-loop-ivopts.c (INFTY): Increase value for infinite cost.
(struct comp_cost): Promote type of members to int64_t.
(infinite_cost): Don't set complexity in initialization.
(comp_cost::operator +,-,+=,-+,/=,*=): Assert when cost computation
overflows to infinite_cost.
(adjust_setup_cost): Promote type of parameter and cost computation
to int64_t.
(struct ainc_cost_data, struct iv_ca): Promote type of member to
int64_t.
(get_scaled_computation_cost_at, determine_iv_cost): Promote type of
cost computation to int64_t.
(determine_group_iv_costs, iv_ca_dump, find_optimal_iv_set): Use
int64_t's format specifier in dump.

gcc/testsuite
* g++.dg/tree-ssa/pr90078.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/tree-ssa/pr90078.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-loop-ivopts.c

[Bug tree-optimization/90240] [10 Regression] ICE in try_improve_iv_set, at tree-ssa-loop-ivopts.c:6694

[amker at gcc dot gnu.org]

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

--- Comment #10 from bin cheng  ---
Author: amker
Date: Wed May  8 11:24:38 2019
New Revision: 271007

URL: https://gcc.gnu.org/viewcvs?rev=271007=gcc=rev
Log:
PR tree-optimization/90240
* tree-ssa-loop-ivopts.c (get_scaled_computation_cost_at): Scale cost
with respect to scaling factor pre-computed for each basic block.
(try_improve_iv_set): Return bool if best_cost equals to iv_ca cost.
(find_optimal_iv_set_1): Free iv_ca set if it has infinite_cost.
(COST_SCALING_FACTOR_BOUND, determine_scaling_factor): New.
(tree_ssa_iv_optimize_loop): Call determine_scaling_factor.  Extend
live range for array of loop's basic blocks.  Cleanup aux field of
loop's basic blocks.

gcc/testsuite
* gfortran.dg/graphite/pr90240.f: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/graphite/pr90240.f
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-loop-ivopts.c

[Bug target/87835] nvptx offloading: libgomp.oacc-c-c++-common/asyncwait-1.c execution test intermittently fails at -O2

[tschwinge at gcc dot gnu.org]

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

--- Comment #8 from Thomas Schwinge  ---
Author: tschwinge
Date: Wed May  8 10:03:04 2019
New Revision: 271005

URL: https://gcc.gnu.org/viewcvs?rev=271005=gcc=rev
Log:
Address compiler diagnostics in libgomp.oacc-c-c++-common/pr87835.c

source-gcc/libgomp/testsuite/libgomp.oacc-c-c++-common/pr87835.c: In
function 'main':
source-gcc/libgomp/testsuite/libgomp.oacc-c-c++-common/pr87835.c:45:
warning: ignoring #pragma loop gang [-Wunknown-pragmas]
   45 | #pragma loop gang
  |
source-gcc/libgomp/testsuite/libgomp.oacc-c-c++-common/pr87835.c:19:7:
warning: unused variable 'b' [-Wunused-variable]
   19 |   int b[n];
  |   ^

libgomp/
PR target/87835
* testsuite/libgomp.oacc-c-c++-common/pr87835.c: Update.

trunk r271004

Modified:
branches/gcc-9-branch/libgomp/ChangeLog
branches/gcc-9-branch/libgomp/testsuite/libgomp.oacc-c-c++-common/pr87835.c

[Bug fortran/90351] -fc-prototypes does not dump prototypes for external procedures

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

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

[Bug target/87835] nvptx offloading: libgomp.oacc-c-c++-common/asyncwait-1.c execution test intermittently fails at -O2

[tschwinge at gcc dot gnu.org]

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

--- Comment #7 from Thomas Schwinge  ---
Author: tschwinge
Date: Wed May  8 10:01:30 2019
New Revision: 271004

URL: https://gcc.gnu.org/viewcvs?rev=271004=gcc=rev
Log:
Address compiler diagnostics in libgomp.oacc-c-c++-common/pr87835.c

source-gcc/libgomp/testsuite/libgomp.oacc-c-c++-common/pr87835.c: In
function 'main':
source-gcc/libgomp/testsuite/libgomp.oacc-c-c++-common/pr87835.c:45:
warning: ignoring #pragma loop gang [-Wunknown-pragmas]
   45 | #pragma loop gang
  |
source-gcc/libgomp/testsuite/libgomp.oacc-c-c++-common/pr87835.c:19:7:
warning: unused variable 'b' [-Wunused-variable]
   19 |   int b[n];
  |   ^

libgomp/
PR target/87835
* testsuite/libgomp.oacc-c-c++-common/pr87835.c: Update.

Modified:
trunk/libgomp/ChangeLog
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/pr87835.c

[Bug fortran/90351] -fc-prototypes does not dump prototypes for external procedures

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-05-08
 Ever confirmed|0   |1

[Bug fortran/90350] ubound ICE on assumed size array even though explicit bound is specified

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-05-08
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Confirmed from at least 4.4 up to trunk (10.0). This is caused by the line

   write(*,*)'UPPER=',ubound(arr(:n))

Work around: use

integer,intent(in) :: n
integer,intent(in) :: arr(n)

[Bug tree-optimization/57534] [7/8/9/10 Regression]: Performance regression versus 4.7.3, 4.8.1 is ~15% slower

[amker at gcc dot gnu.org]

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

bin cheng  changed:

   What|Removed |Added

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

--- Comment #33 from bin cheng  ---
Came back to this one.


void timer_stop();

volatile long keepgoing = 0;
double hand_benchmark_cache_ronly( double *x, long limit, long *oloops, double
*ous) {
long index = 0, loops = 0;
double sum = (double)0;
double sum2 = (double)0;
again:   sum += x[index] + x[index+1] + x[index+2] + x[index+3];
sum2 += x[index+4] + x[index+5] + x[index+6] + x[index+7];
if ((index += 8) < limit) goto again;
else if (keepgoing) {
index = 0;
goto again;
}
timer_stop();
x[0] = (double)sum + (double)sum2;
x[1] = (double)index;
}

The idea fix to above test would be identifying the first goto as a loop, so
IVOPTs can do strength reduction on address ivs.

While for below case:
int ind;
int cond(void);

double hand_benchmark_cache_ronly( double *x) {
double sum=0.0;
while (cond())
sum += x[ind] + x[ind+1] + x[ind+2] + x[ind+3];
return sum;
}

It's hard to handle in IVOPTs, because neither niter nor scev analysis
succeeds.  The IVOPTs implementation is centralized to induction variable.  It
would non-trivial change to support such case.

However, I wondered why we missed slsr in previous analysis?  It's designed to
strength reduce such code.  Quoting from its comment:

   Specifically, we are interested in references for which 
   get_inner_reference returns a base address, offset, and bitpos as
   follows:

 base:MEM_REF (T1, C1)
 offset:  MULT_EXPR (PLUS_EXPR (T2, C2), C3)
 bitpos:  C4 * BITS_PER_UNIT

   Here T1 and T2 are arbitrary trees, and C1, C2, C3, C4 are 
   arbitrary integer constants.  Note that C2 may be zero, in which
   case the offset will be MULT_EXPR (T2, C3).

   When this pattern is recognized, the original memory reference
   can be replaced with:

 MEM_REF (POINTER_PLUS_EXPR (T1, MULT_EXPR (T2, C3)),
  C1 + (C2 * C3) + C4)

It explicitly states that addresses here should be tracked, associated and
reduced as we wanted:  (X + index * 8) + const_offset_x.

I think it's a missed address slsr optimization, i.e, clearly it failed to
identify CAND_REF candidate for memory reference.  After looking into the code,
I think the problem is in slsr_process_ref and restructure_reference.

Trying if I can fix this...

[Bug target/48429] ARM __attribute__((interrupt("FIQ"))) not optimizing register allocation

[rearnsha at gcc dot gnu.org]

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

Richard Earnshaw  changed:

   What|Removed |Added

   Priority|P3  |P4
   Severity|normal  |enhancement

--- Comment #3 from Richard Earnshaw  ---
This is a missed optimization, not a bug.  Given that we have many more
pressing issues it is unlikely to be addressed soon.

Of course, patches are always welcome...

[Bug driver/90386] New: Offloading: libgfortran, libm dependencies

[tschwinge at gcc dot gnu.org]

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

Bug ID: 90386
   Summary: Offloading: libgfortran, libm dependencies
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: openacc, openmp
  Severity: normal
  Priority: P3
 Component: driver
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
  Target Milestone: ---

Offloading code generation may depend on libgfortran, or libm, for example,
when compiling Fortran code, or when OMP regions use math functions.  Currently
you manually have to specify 'gfortran -foffload=-lgfortran' (implicit
'-lgfortran', but not implicit '-foffload=-lgfortran' for offloading code
generation), or have to specify '-lm -foffload=-lm' ('-lm' alone should be
sufficient?).

See  for some more
details, from a few years ago.

[Bug fortran/90329] Incompatibility between gfortran and C lapack calls

[jb at gcc dot gnu.org]

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

--- Comment #21 from Janne Blomqvist  ---
I filed https://github.com/Reference-LAPACK/lapack/issues/339 to start a
discussion about fixing CBLAS and LAPACKE in upstream LAPACK.

[Bug other/90381] New test case gcc.dg/tree-ssa/pr88676-2.c fails with its introduction in r270934

[helijia at gcc dot gnu.org]

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

--- Comment #3 from Li Jia He  ---
Author: helijia
Date: Wed May  8 07:52:26 2019
New Revision: 271002

URL: https://gcc.gnu.org/viewcvs?rev=271002=gcc=rev
Log:
PR other/90381
* gcc.dg/tree-ssa/pr88676-2.c: Add 'target le' option to limit the
test case to run on the little endian machine.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr88676-2.c

[Bug middle-end/90248] [8/9/10 Regression] larger than 0 compare fails with -ffinite-math-only -funsafe-math-optimizations

[rguenth at gcc dot gnu.org]

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

--- Comment #8 from Richard Biener  ---
(In reply to Andrew Pinski from comment #7)
> Yes it does look like I messed up.  I copied an optimization from LLVM so I
> think they also mess up a similar way (though differently).

Andrew - can you please fix?

[Bug rtl-optimization/90378] [9/10 regression] -Os -flto miscompiles 454.calculix after r266385 on Arm

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code
 Target||arm
 Blocks||26163
   Target Milestone|--- |9.2
Summary|[9 regression] -Os -flto|[9/10 regression] -Os -flto
   |miscompiles 454.calculix|miscompiles 454.calculix
   |after r266385 on Arm|after r266385 on Arm


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
[Bug 26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)

[Bug tree-optimization/90356] Missed optimization for variables initialized to 0.0

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
Author: jakub
Date: Wed May  8 07:21:48 2019
New Revision: 271001

URL: https://gcc.gnu.org/viewcvs?rev=271001=gcc=rev
Log:
PR tree-optimization/90356
* match.pd ((X +/- 0.0) +/- 0.0): Optimize into X +/- 0.0 if possible.

* gcc.dg/tree-ssa/pr90356-1.c: New test.
* gcc.dg/tree-ssa/pr90356-2.c: New test.
* gcc.dg/tree-ssa/pr90356-3.c: New test.
* gcc.dg/tree-ssa/pr90356-4.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr90356-1.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr90356-2.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr90356-3.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr90356-4.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/match.pd
trunk/gcc/testsuite/ChangeLog

[Bug testsuite/90379] Gcc 9.1 fails "make check" on linux due to missing MacOS-specific header file

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Biener  ---
You need to do 'make -k check' since some tests are always expected to fail.

[Bug other/90381] New test case gcc.dg/tree-ssa/pr88676-2.c fails with its introduction in r270934

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
you can use the be or le target specifiers.

[Bug c++/90383] [9/10 Regression] GCC generates invalid constexpr copy/move assignment operators for types with trailing padding. (Again)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |9.2
Summary|[9 Regression] GCC  |[9/10 Regression] GCC
   |generates invalid constexpr |generates invalid constexpr
   |copy/move assignment|copy/move assignment
   |operators for types with|operators for types with
   |trailing padding. (Again)   |trailing padding. (Again)

[Bug tree-optimization/90385] [9/10 Regression] ICE: tree check: expected ssa_name, have real_cst in transform_to_exit_first_loop_alt, at tree-parloops.c:1772

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-05-08
   Target Milestone|--- |9.2
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed, not really a regression.  parloops is confused by exit PHIs with
constants.  Not to be expected w/o all these disabling options.

[Bug tree-optimization/90316] [8/9 Regression] large compile time increase in opt / alias stmt walking for Go example

[rguenth at gcc dot gnu.org]

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

--- Comment #21 from Richard Biener  ---
It also looks the hash_table hash function is weak judging
from the time spent in the equality routine.

Index: gcc/tree-ssa-pre.c
===
--- gcc/tree-ssa-pre.c  (revision 271000)
+++ gcc/tree-ssa-pre.c  (working copy)
@@ -4118,6 +4118,12 @@ fini_pre ()
   bitmap_obstack_release (_bitmap_obstack);
   bitmap_set_pool.release ();
   pre_expr_pool.release ();
+  if (dump_file && (dump_flags & TDF_DETAILS))
+fprintf (dump_file, "phi-translate cache statistics: "
+"size %ld, %ld elements, %f collisions\n",
+(long) phi_translate_table->size (),
+(long) phi_translate_table->elements (),
+phi_translate_table->collisions ());
   delete phi_translate_table;
   phi_translate_table = NULL;
   delete expression_to_id;

should help verify that if you then do a -fdump-tree-pre-details and look
into the respective generated dump file.

Similar for get_expr_value_id?  But that one should be cheap so I am a bit
confused about this profile graph.

[Bug tree-optimization/90316] [8/9 Regression] large compile time increase in opt / alias stmt walking for Go example

[rguenth at gcc dot gnu.org]

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

--- Comment #20 from Richard Biener  ---
(In reply to Than McIntosh from comment #19)
> Created attachment 46313 [details]
> SVG graph from profiling run

Do I read this correctly in that all the time spent in PRE is via
do_pre_regular_insertion?  Or is the profiling imperfect in that
the times on get_continuation_for_phi show all invocations of it,
not just those via the graph edges coming ultimatively from
do_pre_regular_insertion?

It looks like we are doing a disproportionally big number of insert
iterations here - if you compile with -fdump-statistics-stats
you'll get a .statistics dump file showing lines with
"insert iterations", can you quote those?  (maybe attach this
statistics file)

On the testcases attached here we do not insert anything btw.  I guess
you can't really share the original testcase?

[Bug other/90381] New test case gcc.dg/tree-ssa/pr88676-2.c fails with its introduction in r270934

[helijia at gcc dot gnu.org]

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

--- Comment #1 from Li Jia He  ---
Thanks for pointing this out.
I used the following code:

struct foo1 {
  int i:1;
};

int test1 (struct foo1 *x)
{
  if (x->i == 0)
return 1;
  else if (x->i == 1)
return 1;
  return 0;
}

to dumped the pass output in front of phiopt1
on be machine:

test1 (struct foo1 * x)
{
  unsigned char _1;
  int _3;
  signed char _6;

   :
  _1 = BIT_FIELD_REF <*x_5(D), 8, 0>;
  _6 = (signed char) _1;
  if (_6 >= 0)
goto ; [INV]
  else
goto ; [INV]

   :
  // predicted unlikely by early return (on trees) predictor.

   :
  # _3 = PHI <1(3), 0(2)>
  return _3;

}

but, on le machine:

test1 (struct foo1 * x)
{
  unsigned char _1;
  unsigned char _2;
  int _3;

   :
  _1 = BIT_FIELD_REF <*x_5(D), 8, 0>;
  _2 = _1 & 1;
  if (_2 == 0)
goto ; [INV]
  else
goto ; [INV]

   :
  // predicted unlikely by early return (on trees) predictor.

   :
  # _3 = PHI <1(3), 0(2)>
  return _3;

}
‘’’
The difference is the comparison code in the if statement, however
two_value_replacement will only optimize for EQ_EXPR or NE_EXPR.
Can we limit this test case to the le machine ? Thanks.