[Bug tree-optimization/88030] New: ICE in calc_dfs_tree, at dominance.c:458

[marxin at gcc dot gnu.org]

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

Bug ID: 88030
   Summary: ICE in calc_dfs_tree, at dominance.c:458
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
  Target Milestone: ---

Following is causing an ICE:

$ gcc gcc/testsuite/gcc.dg/vect/no-tree-sra-bb-slp-pr50730.c
-fnon-call-exceptions -fsanitize=thread -fexceptions
during GIMPLE pass: cplxlower0
gcc/testsuite/gcc.dg/vect/no-tree-sra-bb-slp-pr50730.c: In function ‘sum’:
gcc/testsuite/gcc.dg/vect/no-tree-sra-bb-slp-pr50730.c:9:3: internal compiler
error: in calc_dfs_tree, at dominance.c:458
9 | A sum(A a,A b)
  |   ^~~
0x614cd5 calc_dfs_tree
/home/marxin/Programming/gcc/gcc/dominance.c:458
0x954175 calculate_dominance_info(cdi_direction)
/home/marxin/Programming/gcc/gcc/dominance.c:734
0xd96ea3 update_ssa(unsigned int)
/home/marxin/Programming/gcc/gcc/tree-into-ssa.c:3356
0xc2a0f7 execute_function_todo
/home/marxin/Programming/gcc/gcc/passes.c:1910
0xc2af6e execute_todo
/home/marxin/Programming/gcc/gcc/passes.c:1996

[Bug tree-optimization/88030] ICE in calc_dfs_tree, at dominance.c:458

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Target Milestone|--- |9.0

[Bug tree-optimization/88029] [9 Regression] ICE in execute_todo, at passes.c:1974

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-11-15
 CC||marxin at gcc dot gnu.org,
   ||msebor at gcc dot gnu.org
  Known to work||8.2.0
   Target Milestone|--- |9.0
 Ever confirmed|0   |1
  Known to fail||9.0

--- Comment #1 from Martin Liška  ---
Confirmed, started with r262596.

[Bug c++/88028] internal compiler error: in reshape_init_r, at cp/decl.c:6159

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-11-15
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #3 from Martin Liška  ---
Confirmed.

[Bug c++/88026] Explicit deduction guide fails for move-only type

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-11-15
 Ever confirmed|0   |1

[Bug tree-optimization/87917] ICE in initialize_matrix_A at gcc/tree-data-ref.c:3150

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
Author: rguenth
Date: Thu Nov 15 08:16:22 2018
New Revision: 266173

URL: https://gcc.gnu.org/viewcvs?rev=266173&root=gcc&view=rev
Log:
2018-11-15  Richard Biener  

PR middle-end/87917
* tree-data-ref.c (analyze_miv_subscript): Guard calls to
analyze_subscript_affine_affine properly.

* gcc.dg/tree-ssa/pr87917.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr87917.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-data-ref.c

[Bug tree-optimization/87917] ICE in initialize_matrix_A at gcc/tree-data-ref.c:3150

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||9.0

--- Comment #5 from Richard Biener  ---
Fixed on trunk.

[Bug debug/87462] [7/8 Regression] undefined reference error occurs when -g, -fdebug-types-section and -O2 are used at the same time

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|RESOLVED|NEW
  Known to work||9.0
 Resolution|FIXED   |---
Summary|[7/8/9 Regression]  |[7/8 Regression] undefined
   |undefined reference error   |reference error occurs when
   |occurs when -g, |-g, -fdebug-types-section
   |-fdebug-types-section and   |and -O2 are used at the
   |-O2 are used at the same|same time
   |time|
  Known to fail|9.0 |

--- Comment #5 from Richard Biener  ---
On trunk sofar.

[Bug lto/55102] The options -flto and -On do not behave as described in GCC docs

[rguenther at suse dot de]

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

--- Comment #7 from rguenther at suse dot de  ---
On Thu, 15 Nov 2018, sandra at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55102
> 
> sandra at gcc dot gnu.org changed:
> 
>What|Removed |Added
> 
>  CC||sandra at gcc dot gnu.org
> 
> --- Comment #6 from sandra at gcc dot gnu.org ---
> I've checked in a patch on trunk to replace the bad example with the
> explanation in Comment 1, suitably translated into user-speak.  However, in
> subsequent comments this issue wandered off into discussion of enabling IPA
> automatically with -flto and other related code changes.  Is the issue
> adequately resolved just by the documentation change, or do we want to keep it
> open to track the requested code changes?

Let's close it.

[Bug c++/87269] [9 Regression] ICE in tsubst_copy, at cp/pt.c:15475 starting from r261802

[marxin at gcc dot gnu.org]

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

--- Comment #7 from Martin Liška  ---
Nathan?

[Bug c/88031] New: ice in vectorizable_reduction, at tree-vect-loop.c:6953

[dcb314 at hotmail dot com]

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

Bug ID: 88031
   Summary: ice in vectorizable_reduction, at
tree-vect-loop.c:6953
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

For this C code:

int a[512];
int b;
void d() {
  unsigned char c;
  for (; b; b++) {
c = 1;
for (; c; c <<= 1) {
  a[b] <<= 8;
  if (b & c)
a[b] = 1;
}
  }
}

compiled with recent gcc trunk and compiler flag -O3, does this:

bug478.c:3:6: internal compiler error: in vectorizable_reduction, at
tree-vect-loop.c:6953
3 | void d() {
  |  ^
0x2d4e1ee vectorizable_reduction(_stmt_vec_info*, gimple_stmt_iterator*,
_stmt_vec_info**, _slp_tree*, _slp_instance*, vec*)
../../trunk/gcc/tree-vect-loop.c:6953

gcc was fine at revision 265907, but had gone wrong by 265980

[Bug bootstrap/84402] [meta] GCC build system: parallelism bottleneck

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Target Milestone|9.0 |10.0

[Bug ipa/87706] Inlined functions trigger invalid -Wmissing-profile warning

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Target Milestone|--- |9.0

[Bug sanitizer/87875] Address sanitizer doen't work with nested functions with enabled stack-use-after-return check

[marxin at gcc dot gnu.org]

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

--- Comment #10 from Martin Liška  ---
(In reply to Martin Liška from comment #9)
> (In reply to Jakub Jelinek from comment #7)
> > Not also sure what happens if the executable and libraries don't need
> > executable stack and you later dlopen some shared library that needs it
> > (e.g. uses nested functions).  Don't remember if ld.so mprotects the main
> > stack as well as all others.
> 
> Uff, looks complicated. I've just attached patch that greps for '[stack]'
> and reads execute flags..

One possible solution would be to have a global option that will enable
executable flag on all stack allocations? Then we can provide a hint from
run-time to users.
Jakub?

[Bug rtl-optimization/88018] [8/9 Regression] ICE in insert_insn_on_edge at cfgrtl.c:1952 since r255066

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Thu Nov 15 08:47:21 2018
New Revision: 266174

URL: https://gcc.gnu.org/viewcvs?rev=266174&root=gcc&view=rev
Log:
PR rtl-optimization/88018
* cfgrtl.c (fixup_abnormal_edges): Guard moving insns to fallthru edge
on the presence of fallthru edge, rather than if it is a USE or not.

* g++.dg/tsan/pr88018.C: New test.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/cfgrtl.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/88030] ICE in calc_dfs_tree, at dominance.c:458

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-11-15
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
complex lowering fails to cleanup the CFG in case it removed EH edges or
alternatively at -O0 it lacks dominator info so gimple_purge_dead_eh_edges
doesn't remove unreachable blocks.

[Bug driver/88024] At -O0 and -Og, GCC should warn if you explicitly try to enable an option that is ignored

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-11-15
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Hmm, this will be somewhat difficult to implement given it mixes option
processing and pass list processing.  Consider also

-O2 -fno-tree-loop-optimize -ftree-loop-vectorize

where -ftree-loop-vectorize has no effect because vectorization sits in
a pass group that is guarded by -ftree-loop-optimize.

That said it would indeed be nice to have flag "dependences" recorded
somewhere but without duplication in two places (passes.def and elsewhere).
Because that will very likely bitrot.

So I don't like to see the "obvious" fix of adding sth to common.opt like

ftree-pre
Common Report Var(flag_tree_pre) Optimization NotO0 NotOg
Enable SSA-PRE optimization on trees.


Similar it would eventually be nice to diagnose

-O3 -ftree-loop-vectorize -Woptions
note: -ftree-loop-vectorize is already enabled by -O3
-O2 -fno-tree-loop-vectorize -Woptions
note: -ftree-loop-vectorize was not enabled

(not by default)

Just to note what kind of meta-info is missing.

[Bug tree-optimization/88029] [9 Regression] ICE in execute_todo, at passes.c:1974

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #2 from Richard Biener  ---
So somehow we not fail to set the const attribute on sin/cos, but fp gets the
const attribute.  In FRE we make the c = fp (a) call direct but fail to
update SSA form because the call now should get a virtual use (well,
technically we should preserve the constness on the call stmt itself like
we do for nothrow/noreturn ...).

So a testcase that exhibits the same issue would be to not use builtins
but instead random other pure functions.

double foo (double) __attribute__ ((pure));
double (*fp) (double) __attribute__ ((const));
double f(double a)
{
  fp = foo;
  return fp (a);
}

which ICEs since GCC 5 with -O.  The ssa-pre-13.c issue now runs into it
because of r262596 ignoring the const attribute.

[Bug tree-optimization/88031] ice in vectorizable_reduction, at tree-vect-loop.c:6953

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-11-15
  Component|c   |tree-optimization
Version|8.0 |9.0
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Mine.  Thanks for testing GCC 9!

[Bug tree-optimization/88031] [9 Regression] ICE in vectorizable_reduction, at tree-vect-loop.c:6953

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |9.0
Summary|ice in  |[9 Regression] ICE in
   |vectorizable_reduction, at  |vectorizable_reduction, at
   |tree-vect-loop.c:6953   |tree-vect-loop.c:6953

[Bug debug/87039] [8/9 Regression] DW_OP_fbreg used without a frame base on a C++ code w/ -fopenmp

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #3 from Jakub Jelinek  ---
Created attachment 45006
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45006&action=edit
gcc9-pr87039.patch

Untested fix.  As mentioned on IRC, starting with r253335 we set DECL_CONTEXT
that the r241023 code then uses to make sure we emit early debug info of main
before main.omp_fn.0.  But it is undesirable to emit early debug info before
actually outlining the regions.  So, by reverting the omp-expand.c part of
r244892 the pr78363-*.C testcases still work and:
$ ./cc1plus.vanilla -quiet -g -O2 -fopenmp pr87039.C ; g++ -c -fopenmp -o
pr87039{.o,.s}; readelf -wi pr87039.o | grep without; echo ==
<13a>   DW_AT_location: 2 byte block: 91 68 (DW_OP_fbreg: -24) [without
DW_AT_frame_base]
<157>   DW_AT_GNU_call_site_value: 2 byte block: 91 68 (DW_OP_fbreg: -24)
[without DW_AT_frame_base]
==
$ ./cc1plus -quiet -g -O2 -fopenmp pr87039.C ; g++ -c -fopenmp -o
pr87039{.o,.s}; readelf -wi pr87039.o | grep without; echo ==
==

No testcase in this patch, we don't have the guality infrastructure in libgomp
testing.

[Bug middle-end/86827] [8/9 Regression] -Warray-bounds produces negative indicies

[aoliva at gcc dot gnu.org]

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

Alexandre Oliva  changed:

   What|Removed |Added

 CC||aoliva at gcc dot gnu.org

--- Comment #3 from Alexandre Oliva  ---
builtin_memref::offset_out_of_bounds has code to handle such anti-ranges, that
would avoid this warning, but it's only active when base has an array type, not
a compound type containing an array type.  Can't we just activate that code
more often?
--- a/gcc/gimple-ssa-warn-restrict.c
+++ b/gcc/gimple-ssa-warn-restrict.c
@@ -479,7 +479,7 @@ builtin_memref::offset_out_of_bounds (int strict,
offset_int ooboff[2]) const
   /* A temporary, possibly adjusted, copy of the offset range.  */
   offset_int offrng[2] = { offrange[0], offrange[1] };

-  if (DECL_P (base) && TREE_CODE (TREE_TYPE (base)) == ARRAY_TYPE)
+  if (true)
 {
   /* Check for offset in an anti-range with a negative lower bound.
 For such a range, consider only the non-negative subrange.  */

Re: Investigating a stack state mismatch in Linux kernel

[Florian Weimer]

* Alexander Popov:

> Of course, there is a naive solution for this issue -- just skip stackleak
> instrumentation for acpi_duplicate_processor_id(). But it would be great to 
> find
> out the reasons behind this compiler behavior. It might help to create a 
> better
> solution.

Please show us the RTL dumps with both compilers, both before and after
the plugin pass.

Thanks,
Florian

[Bug middle-end/86827] [8/9 Regression] -Warray-bounds produces negative indicies

[aoliva at gcc dot gnu.org]

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

--- Comment #4 from Alexandre Oliva  ---
Erhm, but even that doesn't handle all anti-ranges properly; right below, we
state:

  /* The bounds need not be ordered.  Set HIB to use as the index
 of the larger of the bounds and LOB as the opposite.  */

which "corrects" the anti-range into the complementary range whenever we
haven't taken the correction above, e.g., when given an anti-range with
nonnegative boundaries.

[Bug tree-optimization/88030] ICE in calc_dfs_tree, at dominance.c:458

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work||9.0
 Resolution|--- |FIXED
   Target Milestone|9.0 |---

--- Comment #2 from Richard Biener  ---
Fixed.

[Bug tree-optimization/88030] ICE in calc_dfs_tree, at dominance.c:458

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
Author: rguenth
Date: Thu Nov 15 10:42:15 2018
New Revision: 266175

URL: https://gcc.gnu.org/viewcvs?rev=266175&root=gcc&view=rev
Log:
2018-11-15  Richard Biener  

PR tree-optimization/88030
* tree-complex.c (need_eh_cleanup): New global.
(update_complex_assignment): Mark blocks that need EH update.
(expand_complex_comparison): Likewise.
(tree_lower_complex): Allocate and deallocate need_eh_cleanup,
perform EH cleanup and schedule CFG cleanup if that did anything.

* gcc.dg/tsan/pr88030.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/tsan/pr88030.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-complex.c

[Bug middle-end/88032] [9 Regression] ICE in operand_subword_force, at emit-rtl.c:1793

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target||x86_64-*-*
   Target Milestone|--- |9.0

[Bug middle-end/88032] New: [9 Regression] ICE in operand_subword_force, at emit-rtl.c:1793

[rguenth at gcc dot gnu.org]

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

Bug ID: 88032
   Summary: [9 Regression] ICE in operand_subword_force, at
emit-rtl.c:1793
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

gcc.target/i386/pr80173.c started ICEing for me:

/home/abuild/rguenther/obj-slpcost-g/gcc/xgcc
-B/home/abuild/rguenther/obj-slpcost-g/gcc/
/space/rguenther/src/gcc-slpcost/gcc/testsuite/gcc.target/i386/pr80173.c
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never -O2 -ffixed-xmm7 -S -o pr80173.s
during RTL pass: expand^M
/space/rguenther/src/gcc-slpcost/gcc/testsuite/gcc.target/i386/pr80173.c: In
function 'foo':^M
/space/rguenther/src/gcc-slpcost/gcc/testsuite/gcc.target/i386/pr80173.c:12:21:
internal compiler error: in operand_subword_force, at emit-rtl.c:1793^M
0xba6065 operand_subword_force(rtx_def*, poly_int<1u, unsigned long>,
machine_mode)^M
/space/rguenther/src/gcc-slpcost/gcc/emit-rtl.c:1793^M
0xf8e1ea expand_binop(machine_mode, optab_tag, rtx_def*, rtx_def*, rtx_def*,
int, optab_methods)^M
/space/rguenther/src/gcc-slpcost/gcc/optabs.c:1388^M
0xbdc326 store_fixed_bit_field_1^M
/space/rguenther/src/gcc-slpcost/gcc/expmed.c:1289^M
0xbdbdf7 store_fixed_bit_field^M
/space/rguenther/src/gcc-slpcost/gcc/expmed.c:1207^M
0xbdb27a store_integral_bit_field^M
/space/rguenther/src/gcc-slpcost/gcc/expmed.c:1067^M
0xbda3f1 store_bit_field_1^M

[Bug c++/87015] [8/9 Regression] miscompilation of template heavy Boost Spirit code

[aoliva at gcc dot gnu.org]

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

Alexandre Oliva  changed:

   What|Removed |Added

 CC||aoliva at gcc dot gnu.org

--- Comment #6 from Alexandre Oliva  ---
Daniel, since you stated that recompiling with -Og or -O1 did not change the
behavior, presumably you could also add -save-temps to the command line.  That
will produce the preprocessed testcases we need.  Getting the command line and
the expected output or exit status might be more challenging, and require
knowledge of the testsuite at hand, perhaps developers of the library would be
willing to help you get the bug report submitted?

[Bug rtl-optimization/88018] [8 Regression] ICE in insert_insn_on_edge at cfgrtl.c:1952 since r255066

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[8/9 Regression] ICE in |[8 Regression] ICE in
   |insert_insn_on_edge at  |insert_insn_on_edge at
   |cfgrtl.c:1952 since r255066 |cfgrtl.c:1952 since r255066

--- Comment #4 from Jakub Jelinek  ---
Fixed on the trunk so far.

[Bug ipa/87843] [9 Regression] SPEC miscompilation of 403.gcc and 502.gcc_r benchmarks

[marxin at gcc dot gnu.org]

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

--- Comment #16 from Martin Liška  ---
I don't see the miscompilation any longer, may I close it?

[Bug debug/87462] [7/8 Regression] undefined reference error occurs when -g, -fdebug-types-section and -O2 are used at the same time

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

[Bug ipa/87843] [9 Regression] SPEC miscompilation of 403.gcc and 502.gcc_r benchmarks

[hubicka at ucw dot cz]

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

--- Comment #17 from Jan Hubicka  ---
> I don't see the miscompilation any longer, may I close it?
Yes, it was fixed by 

* tree.c (fld_type_variant): Copy canonical type.   
(fld_incomplete_type_of): Check that canonical types looks sane;
copy canonical type.
(verify_type): Accept when incomplete type has complete canonical type.

[Bug ipa/85103] [8/9 Regression] Performance regressions on SPEC with r257582

[rdapp at linux dot ibm.com]

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

rdapp at linux dot ibm.com changed:

   What|Removed |Added

 CC||rdapp at linux dot ibm.com

--- Comment #13 from rdapp at linux dot ibm.com ---
Also confirmed on s390x (checked on z13 and z14). We see a 10% slowdown for
458.sjeng which first occurred with this patch. Any plans on how to continue
with this?

[Bug middle-end/87854] [9 Regression] gcc.c-torture/compile/pr46534.c ICE for 16-bit size_t

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
I wonder if we shouldn't change the c/, cp/ and c-family/ dirs to use
c_build_string instead of build_string, where c_build_string would error if the
length of the string literal is larger than TYPE_MAX_VALUE of
c_common_signed_type (sizetype) and truncate the string literals to that
length, similarly how we reject too large arrays:
  error_at (loc, "size of array %qE is too large",
name);
so size of string literal is too large or something similar.
Or add such checking later on.  Disadvantage of doing it in build_string
wrapper is that we don't have a location_t in that spot.  So perhaps
lex_string/cp_parser_string_literal instead and have some helper function that
will do the checking and truncate the already created STRING_CST?

[Bug middle-end/31377] wrap_help error

[nickc at gcc dot gnu.org]

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

--- Comment #3 from Nick Clifton  ---
Hi George,

(In reply to George Ellery from comment #0)

>   room = columns - 3 - MAX (col_width, item_width);
>   if (room > columns)

>   room = columns - 3 - MAX (col_width, item_width);
>   if (room < 0)

Doh!  Yes this was my mistake.  I do not have approval rights
to this code, but personally I would consider your fix as "obvious"
and so hope that it can be committed without much fuss.

Cheers
  Nick

[Bug middle-end/26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)

[rguenth at gcc dot gnu.org]

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

Bug 87843 Summary: [9 Regression] SPEC miscompilation of 403.gcc and 502.gcc_r 
benchmarks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87843

   What|Removed |Added

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

[Bug ipa/87843] [9 Regression] SPEC miscompilation of 403.gcc and 502.gcc_r benchmarks

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #18 from Richard Biener  ---
Fixed.

[Bug ipa/85103] [8/9 Regression] Performance regressions on SPEC with r257582

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

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

--- Comment #14 from Jan Hubicka  ---
I will take a look.  These decisions are bit fragile because inliner typically
does not know what of the two inline decisions is more profitable and one
excludes the other.

[Bug rtl-optimization/88033] New: ICE on valid code at -O2 and -O3 on x86-64-linux-gnu: in remove_some_program_points_and_update_live_ranges, at lra-lives.c:1179

[su at cs dot ucdavis.edu]

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

Bug ID: 88033
   Summary: ICE on valid code at -O2 and -O3 on x86-64-linux-gnu:
in remove_some_program_points_and_update_live_ranges,
at lra-lives.c:1179
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

$ gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/home/su/software/tmp/gcc/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/9.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/home/su/software/tmp/gcc/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 9.0.0 20181115 (experimental) [trunk revision 266173] (GCC)
$
$ gcctk -Os small.c
$
$ gcctk -O2 small.c
during RTL pass: reload
small.c: In function ‘main’:
small.c:17:1: internal compiler error: in
remove_some_program_points_and_update_live_ranges, at lra-lives.c:1179
   17 | }
  | ^
0xc1e8ef remove_some_program_points_and_update_live_ranges
../../gcc-source-trunk/gcc/lra-lives.c:1179
0xc1e8ef compress_live_ranges
../../gcc-source-trunk/gcc/lra-lives.c:1308
0xc1e8ef lra_create_live_ranges_1
../../gcc-source-trunk/gcc/lra-lives.c:1461
0xc1eb5f lra_create_live_ranges(bool, bool)
../../gcc-source-trunk/gcc/lra-lives.c:1473
0xbfffe0 lra(_IO_FILE*)
../../gcc-source-trunk/gcc/lra.c:2483
0xbb27f9 do_reload
../../gcc-source-trunk/gcc/ira.c:5469
0xbb27f9 execute
../../gcc-source-trunk/gcc/ira.c:5653
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
$


---


long a, b, c;

long f (long e)
{ 
  return (e & ~30) < 0 ? a : a - e;
}

int main ()
{ 
  if (!c)
return 0;
  int g;
  b = f (g);
  while (1)
;
  return 0;
}

[Bug debug/88006] -fdebug-types-section gives undefined reference

[nathan at gcc dot gnu.org]

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

--- Comment #3 from Nathan Sidwell  ---
Author: nathan
Date: Thu Nov 15 13:23:23 2018
New Revision: 266181

URL: https://gcc.gnu.org/viewcvs?rev=266181&root=gcc&view=rev
Log:
[debug/88006] -fdebug-types-section gives undefined ref

https://gcc.gnu.org/ml/gcc-patches/2018-11/msg01280.html
PR debug/88006
PR debug/87462
* dwarf2out.c (dwarf2out_finish): Apply resolve_addr to comdat
type list.

* g++.dg/debug/dwarf2/pr87462.C: New.
* g++.dg/debug/dwarf2/pr88006.C: New.

Added:
branches/gcc-8-branch/gcc/testsuite/g++.dg/debug/dwarf2/pr87462.C
branches/gcc-8-branch/gcc/testsuite/g++.dg/debug/dwarf2/pr88006.C
Modified:
branches/gcc-8-branch/gcc/ChangeLog
branches/gcc-8-branch/gcc/dwarf2out.c
branches/gcc-8-branch/gcc/testsuite/ChangeLog

[Bug debug/87462] [7/8 Regression] undefined reference error occurs when -g, -fdebug-types-section and -O2 are used at the same time

[nathan at gcc dot gnu.org]

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

--- Comment #6 from Nathan Sidwell  ---
Fixed on gcc-8, r266181.

[Bug debug/87462] [7/8 Regression] undefined reference error occurs when -g, -fdebug-types-section and -O2 are used at the same time

[nathan at gcc dot gnu.org]

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

--- Comment #7 from Nathan Sidwell  ---
Author: nathan
Date: Thu Nov 15 13:23:23 2018
New Revision: 266181

URL: https://gcc.gnu.org/viewcvs?rev=266181&root=gcc&view=rev
Log:
[debug/88006] -fdebug-types-section gives undefined ref

https://gcc.gnu.org/ml/gcc-patches/2018-11/msg01280.html
PR debug/88006
PR debug/87462
* dwarf2out.c (dwarf2out_finish): Apply resolve_addr to comdat
type list.

* g++.dg/debug/dwarf2/pr87462.C: New.
* g++.dg/debug/dwarf2/pr88006.C: New.

Added:
branches/gcc-8-branch/gcc/testsuite/g++.dg/debug/dwarf2/pr87462.C
branches/gcc-8-branch/gcc/testsuite/g++.dg/debug/dwarf2/pr88006.C
Modified:
branches/gcc-8-branch/gcc/ChangeLog
branches/gcc-8-branch/gcc/dwarf2out.c
branches/gcc-8-branch/gcc/testsuite/ChangeLog

[Bug ipa/85103] [8/9 Regression] Performance regressions on SPEC with r257582

[rguenth at gcc dot gnu.org]

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

--- Comment #15 from Richard Biener  ---
(In reply to Pat Haugen from comment #3)
> (In reply to Jan Hubicka from comment #1)
> > Pat, can you try to figure out what value of min-speedup is neeed to recover
> > from this regression?
> 
> Using r257582, either of the following options restores the behavior of not
> inlining the mainGtU call and eliminates the performance regression.
> 
> --param inline-min-speedup=18
> 
> --param max-inline-insns-auto=24

Note that both are odd - they are changes in exactly the same direction as
the revision that caused the regression which did 8->15 for inline-min-speedup
and 40->30 for max-inline-insns-auto.

That means inlining even less will restore performance?

So somehow the issue is inlining the whole of mainGtU but only after
inlining of the split part?  And that only happens when other inlining
is changed.

Do you observe the same slowdown if you restore either of the params to
the value before the r257582 change?

Also it looks like we are inlining mainGtU.part back into mainGtU and
inlining the result (the inline clone!) into mainSimpleSort.  That's
against the intent of function splitting I think which would always
first inline the header and then eventually the tail?

That is:

IPA function summary for mainGtU.part.0/48 inlinable
  global time: 240.00
  self size:   243

IPA function summary for mainGtU/37 inlinable
  global time: 29.125000
  self size:   36

 Inlined mainGtU.part.0 into mainGtU which now has time 56.75 and size 267,
net change of -12.

Considering mainGtU/37 with 267 size<===
 to be inlined into mainSimpleSort/39 in blocksort.c:561
 Estimated badness is -0.01, frequency 7718.74.
Badness calculation for mainSimpleSort/39 -> mainGtU/37
  size growth 256, time 54.75 unspec 56.75  big_speedup
  -0.01: guessed profile. frequency 7718.740543, count -1 caller count
-1 time w/o inlining 827687.848633, time with inlining 681031.777832 overall
growth 501 (current) 39 (original) 1521 (compensated)
  Adjusted by hints -0.01
Accounting size:215.00, time:307784.78 on predicate exec:(true)
Accounting size:12.00, time:31839.80 on predicate exec:(true)
Accounting size:12.00, time:31839.80 on predicate exec:(true)
Accounting size:12.00, time:25085.91 on predicate exec:(true)
Accounting size:12.00, time:25085.91 on predicate exec:(true)
Accounting size:1.00, time:964.84 on predicate exec:(true)
Processing frequency mainGtU
  Called by mainSimpleSort that is normal or hot
Processing frequency mainGtU.part.0
  Called by mainGtU that is normal or hot
  not inlinable: mainSimpleSort/39 -> mainGtU/37, --param max-inline-insns-auto
limit reached
  not inlinable: mainSimpleSort/39 -> mainGtU/37, --param max-inline-insns-auto
limit reached
 Inlined mainGtU into mainSimpleSort which now has time 10651.946587 and size
113, net change of +256.

I'm not sure why the estimates work out the way they do but maybe sth
bogus happens with the predicates when inlining back the split part into
the header.

Btw, we didn't tune max-inline-insns-single for a long time which is
way larger than the -auto limit (400!) now.  Dumping that down to 250
would solve the regression as well I guess.  OTOH in the past I argued
this limit should not exist.

But what needs to be investigated is why we assume such big speedup
here for one call but not the others (827687.848633 to 681031.777832).

In the prev. revision the mainGtU header provided similar speedup,
756418.501953 to 617717.608398.

The interesting thing is that the inlined back tail has much lower time
than the tail itself which looks inconsistent.  Honza?

[Bug tree-optimization/88031] [9 Regression] ICE in vectorizable_reduction, at tree-vect-loop.c:6953

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
Author: rguenth
Date: Thu Nov 15 13:42:13 2018
New Revision: 266182

URL: https://gcc.gnu.org/viewcvs?rev=266182&root=gcc&view=rev
Log:
2018-11-15  Richard Biener  

PR tree-optimization/88031
* tree-vect-loop.c (vectorizable_reduction): Move check
for multiple types earlier so we get the expected dump.
Simplify calls to vectorizable_condition.
* tree-vect-stmts.h (vectorizable_condition): Update prototype.
* tree-vect-stmts.c (vectorizable_condition): Instead of
reduc_def and reduc_index take just a flag.  Simplify
code-generation now that we can rely on the defs being set up.
(vectorizable_comparison): Remove unused argument.

* gcc.dg/pr88031.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/pr88031.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vect-loop.c
trunk/gcc/tree-vect-stmts.c
trunk/gcc/tree-vectorizer.h

[Bug tree-optimization/88031] [9 Regression] ICE in vectorizable_reduction, at tree-vect-loop.c:6953

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #3 from Richard Biener  ---
Fixed.

[Bug tree-optimization/88029] [9 Regression] ICE in execute_todo, at passes.c:1974

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #3 from Richard Biener  ---
Fixed.

[Bug tree-optimization/88029] [9 Regression] ICE in execute_todo, at passes.c:1974

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #3 from Richard Biener  ---
Fixed.

--- Comment #4 from Richard Biener  ---
Author: rguenth
Date: Thu Nov 15 13:44:34 2018
New Revision: 266183

URL: https://gcc.gnu.org/viewcvs?rev=266183&root=gcc&view=rev
Log:
2018-11-15  Richard Biener  

PR middle-end/88029
* gimple.c (gimple_call_flags): Union flags from decl, type
and call fntype.
* trans-mem.c (is_tm_pure_call): Simplify.

* gcc.dg/tree-ssa/pr88029.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr88029.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/trans-mem.c

[Bug tree-optimization/88011] [9 regression] r266028 causes a bunch of go failures

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
Hmpf.  Somehow cut&pasting the GCD library part into the testcase doesn't work:

gcdbug.go:18:7: error: may not define methods on non-local type
 func (z *Int) mYlehmerGCD(x, y, a, b *Int) *Int {
   ^
gcdbug.go:129:7: error: may not define methods on non-local type
 func (z *Int) mYGCD(x, y, a, b *Int) *Int {
   ^
gcdbug.go:39:6: error: reference to unexported field or method ‘abs’
  if A.abs.cmp(B.abs) < 0 {
  ^
gcdbug.go:39:16: error: reference to unexported field or method ‘abs’
  if A.abs.cmp(B.abs) < 0 {
^

I guess the errors about abs() are spurious.  How can I fixup

func (z *Int) mYlehmerGCD(x, y, a, b *Int) *Int {
var A, B, Ua, Ub *Int


to not be "method on non-local type"?  Like a simple function?  And how to
adjust callers?  I've also cut&pasted

func (z *Int) mYGCD(x, y, a, b *Int) *Int {
if a.Sign() <= 0 || b.Sign() <= 0 {
...

with similar issues.

[Bug tree-optimization/88015] [9 Regression] ICE in dump_printf_loc, at dumpfile.c:1287

[dmalcolm at gcc dot gnu.org]

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

--- Comment #5 from David Malcolm  ---
Author: dmalcolm
Date: Thu Nov 15 14:01:29 2018
New Revision: 266184

URL: https://gcc.gnu.org/viewcvs?rev=266184&root=gcc&view=rev
Log:
graphite: add missing dump_enabled_p checks (PR tree-optimization/88015)

gcc/ChangeLog:
PR tree-optimization/88015
* graphite-isl-ast-to-gimple.c
(translate_isl_ast_to_gimple::scop_to_isl_ast): Add missing check
for dump_enabled_p.
* graphite-sese-to-poly.c (build_poly_scop): Likewise.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/graphite-isl-ast-to-gimple.c
trunk/gcc/graphite-sese-to-poly.c

[Bug libstdc++/88034] New: std::ws doesn't set failbit when the stream is already at EOF

[vz-gcc at zeitlins dot org]

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

Bug ID: 88034
   Summary: std::ws doesn't set failbit when the stream is already
at EOF
   Product: gcc
   Version: 8.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vz-gcc at zeitlins dot org
  Target Milestone: ---

Consider the following test program:

% cat -n stream_ws.cpp
 1  #include 
 2  #include 
 3
 4  int main()
 5  {
 6  std::istringstream is("123");
 7
 8  std::cout << "eof/fail/bad bit values: "
 9  << is.eofbit << ", "
10  << is.failbit << ", "
11  << is.badbit << "\n";
12
13  std::cout << "Initial state: " << is.rdstate() << "\n";
14
15  int n = -1;
16  is >> n;
17  std::cout << "After reading \"" << n << "\": " << is.rdstate() <<
"\n";
18
19  is >> std::ws;
20  std::cout << "After ws: " << is.rdstate() << "\n";
21  }

With g++ 8.2.0 (Debian 8.2.0-9) the output is:

eof/fail/bad bit values: 2, 4, 1
Initial state: 0
After reading "123": 2
After ws: 2

I.e. calling ws() for the stream which is already at EOF does _not_ set the
failbit at line 19. When the same program is compiled with MSVS 15.9, the
output is:

eof/fail/bad bit values: 1, 2, 4
Initial state: 0
After reading "123": 1
After ws: 3

i.e. it does turn failbit on.

I had originally thought that MSVS behaviour was wrong, but Microsoft engineer
Billy Robert O'Neal III has convincingly explained that it is correct in this
reply to

   
https://developercommunity.visualstudio.com/content/problem/382896/regression-stdws-incorrectly-sets-failbit-when-the.html

In case this URL is not accessible without Microsoft account, let me quote his
reply here:

--- start quoted reply ---
The current std::ws behavior is correct, and the old behavior was incorrect. If
you look at N4762 (the current C++ working paper) [istream.manip]/2 it says
that ws:


1. Behaves as an unformatted input function.

2. If it stops because it encounters the end, sets eofbit but not failbit.


In particular, the unformatted input function processing happens before
anything about this specific unformatted input operation is applied. The
unformatted input rules are described in [istream.unformatted]/1, starting
with:


> Each unformatted input function begins execution by constructing an object of 
> class sentry with the default argument noskipws (second) argument true


The behavior of constructing a sentry is described in [istream::sentry]/2,
which begins with:


> Effects: If is.good() is false, calls is.setstate(failbit)


This ordering is more directly supported by ws' specific wording in
[istream.manip]/2 which says (emphasis mine):


> *After constructing a sentry object* extracts characters as long as the next 
> available character c is whitespace or until there are no more characters in 
> the sequence.

--- end quoted reply ---

So it looks like ws() is indeed supposed to set failbit here and it's a bug in
libstdc++ that it doesn't. Note that if the stream were not already at EOF
(e.g. if there were a trailing space after "123" in the line 6 of the example
above), then failbit should not, and is not, correctly, being set by both
libstdc++ and MSVS.

[Bug tree-optimization/88015] [9 Regression] ICE in dump_printf_loc, at dumpfile.c:1287

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 Status|ASSIGNED|WAITING

--- Comment #6 from David Malcolm  ---
I attempted to reproduce using the issues described in comment #0, comment #3
and comment #4 (using r266145, fwiw).

The only one I was able to reproduce was the final one in comment #4, for which
I saw a different backtrace to the ones in comment #0 and comment #3.

The patch in comment #5 should address the two backtraces; see:
  https://gcc.gnu.org/ml/gcc-patches/2018-11/msg01380.html
for more notes on it.

Does it fix things for you, or are you still seeing assertion failures inside
the dump API?

[Bug c++/87012] [7/8/9 Regression] ICE in verify_unstripped_args_1

[aoliva at gcc dot gnu.org]

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

Alexandre Oliva  changed:

   What|Removed |Added

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

--- Comment #3 from Alexandre Oliva  ---
Created attachment 45007
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45007&action=edit
combination of two potential fixes

The problem is that tsubst creates a new type variant of reference type for the
template instantiation, and passes it for convert_nontype_argument to create
the indirect_ref(nop_expr(var_decl)) using the reference type for the nop_expr,
but later on, strip_typedefs replaces the canonical reference type in the
nop_expr within the indirect_ref and verify_unstripped_args_1 doesn't like
that.

The attached patchlet fixes both spots, because I can't decide which change is
better.  Canonicalizing the type would save strip_typedefs some effort, but
preserving symbolic typedef names might give us better messages at a later
time.  Thoughts?

[Bug middle-end/87854] [9 Regression] gcc.c-torture/compile/pr46534.c ICE for 16-bit size_t

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #3 from Jakub Jelinek  ---
Created attachment 45008
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45008&action=edit
gcc9-pr87854.patch

Untested fix.

[Bug libstdc++/88034] std::ws doesn't set failbit when the stream is already at EOF

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-11-15
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
Confirmed. Libc++ agrees with the latest MSVC.

[Bug debug/59474] Invalid binaries produced when making win32 EXEs with -gsplit-dwarf

[matteo at mitalia dot net]

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

Matteo Italia  changed:

   What|Removed |Added

 CC||matteo at mitalia dot net

--- Comment #3 from Matteo Italia  ---
Still broken in 7.1.1.

[Bug debug/88006] -fdebug-types-section gives undefined reference

[nathan at gcc dot gnu.org]

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

--- Comment #4 from Nathan Sidwell  ---
Author: nathan
Date: Thu Nov 15 14:31:35 2018
New Revision: 266185

URL: https://gcc.gnu.org/viewcvs?rev=266185&root=gcc&view=rev
Log:
[debug/88006] -fdebug-types-section gives undefined ref

https://gcc.gnu.org/ml/gcc-patches/2018-11/msg01280.html
PR debug/88006
PR debug/87462
* dwarf2out.c (dwarf2out_finish): Apply resolve_addr to comdat
type list.

* g++.dg/debug/dwarf2/pr87462.C: New.
* g++.dg/debug/dwarf2/pr88006.C: New.

Added:
branches/gcc-7-branch/gcc/testsuite/g++.dg/debug/dwarf2/pr87462.C
branches/gcc-7-branch/gcc/testsuite/g++.dg/debug/dwarf2/pr88006.C
Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/dwarf2out.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug middle-end/88032] [9 Regression] ICE in operand_subword_force, at emit-rtl.c:1793

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-11-15
 CC||iii at gcc dot gnu.org,
   ||jakub at gcc dot gnu.org,
   ||law at gcc dot gnu.org
 Ever confirmed|0   |1

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

[Bug debug/87462] [7/8 Regression] undefined reference error occurs when -g, -fdebug-types-section and -O2 are used at the same time

[nathan at gcc dot gnu.org]

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

--- Comment #9 from Nathan Sidwell  ---
Author: nathan
Date: Thu Nov 15 14:31:35 2018
New Revision: 266185

URL: https://gcc.gnu.org/viewcvs?rev=266185&root=gcc&view=rev
Log:
[debug/88006] -fdebug-types-section gives undefined ref

https://gcc.gnu.org/ml/gcc-patches/2018-11/msg01280.html
PR debug/88006
PR debug/87462
* dwarf2out.c (dwarf2out_finish): Apply resolve_addr to comdat
type list.

* g++.dg/debug/dwarf2/pr87462.C: New.
* g++.dg/debug/dwarf2/pr88006.C: New.

Added:
branches/gcc-7-branch/gcc/testsuite/g++.dg/debug/dwarf2/pr87462.C
branches/gcc-7-branch/gcc/testsuite/g++.dg/debug/dwarf2/pr88006.C
Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/dwarf2out.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug debug/87462] [7/8 Regression] undefined reference error occurs when -g, -fdebug-types-section and -O2 are used at the same time

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

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

--- Comment #8 from Nathan Sidwell  ---
Fixed gcc-7 r266185.

[Bug other/19165] (Natural) language independent error / warning classification

[dmalcolm at gcc dot gnu.org]

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

--- Comment #25 from David Malcolm  ---
Author: dmalcolm
Date: Thu Nov 15 14:32:41 2018
New Revision: 266186

URL: https://gcc.gnu.org/viewcvs?rev=266186&root=gcc&view=rev
Log:
Machine-readable diagnostic output (PR other/19165)

This patch implements a -fdiagnostics-format=json option which
converts the diagnostics to be output to stderr in a JSON format;
see the documentation in invoke.texi.

Logically-related diagnostics are nested at the JSON level, using
the auto_diagnostic_group mechanism.

gcc/ChangeLog:
PR other/19165
* Makefile.in (OBJS): Move json.o to...
(OBJS-libcommon): ...here and add diagnostic-format-json.o.
* common.opt (fdiagnostics-format=): New option.
(diagnostics_output_format): New enum.
* diagnostic-format-json.cc: New file.
* diagnostic.c (default_diagnostic_final_cb): New function, taken
from start of diagnostic_finish.
(diagnostic_initialize): Initialize final_cb to
default_diagnostic_final_cb.
(diagnostic_finish): Move "being treated as errors" messages to
default_diagnostic_final_cb.  Call any final_cb.
(default_diagnostic_finalizer): Add diagnostic_t param.
(diagnostic_report_diagnostic): Pass "orig_diag_kind" to
diagnostic_finalizer callback.
* diagnostic.h (enum diagnostics_output_format): New enum.
(diagnostic_finalizer_fn): Reimplement, adding diagnostic_t param.
(struct diagnostic_context): Add "final_cb".
(default_diagnostic_finalizer): Add diagnostic_t param.
(diagnostic_output_format_init): New decl.
* doc/invoke.texi (-fdiagnostics-format): New option.
* dwarf2out.c (gen_producer_string): Ignore
OPT_fdiagnostics_format_.
* gcc.c (driver_handle_option): Handle OPT_fdiagnostics_format_.
* lto-wrapper.c (append_diag_options): Ignore it.
* opts.c (common_handle_option): Handle it.

gcc/c-family/ChangeLog:
PR other/19165
* c-opts.c (c_diagnostic_finalizer): Add diagnostic_t param.

gcc/fortran/ChangeLog:
PR other/19165
* error.c (gfc_diagnostic_finalizer): Add diagnostic_t param.

gcc/jit/ChangeLog:
PR other/19165
* dummy-frontend.c (jit_begin_diagnostic): Add diagnostic_t param.

gcc/testsuite/ChangeLog:
PR other/19165
* c-c++-common/diagnostic-format-json-1.c: New test.
* c-c++-common/diagnostic-format-json-2.c: New test.
* c-c++-common/diagnostic-format-json-3.c: New test.
* c-c++-common/diagnostic-format-json-4.c: New test.
* c-c++-common/diagnostic-format-json-5.c: New test.
* gcc.dg/plugin/diagnostic_plugin_test_show_locus.c
(custom_diagnostic_finalizer): Add diagnostic_t param.
* gcc.dg/plugin/location_overflow_plugin.c
(verify_unpacked_ranges): Likewise.
(verify_no_columns): Likewise.
* gfortran.dg/diagnostic-format-json-1.F90: New test.
* gfortran.dg/diagnostic-format-json-2.F90: New test.
* gfortran.dg/diagnostic-format-json-3.F90: New test.


Added:
trunk/gcc/diagnostic-format-json.cc
trunk/gcc/testsuite/c-c++-common/diagnostic-format-json-1.c
trunk/gcc/testsuite/c-c++-common/diagnostic-format-json-2.c
trunk/gcc/testsuite/c-c++-common/diagnostic-format-json-3.c
trunk/gcc/testsuite/c-c++-common/diagnostic-format-json-4.c
trunk/gcc/testsuite/c-c++-common/diagnostic-format-json-5.c
trunk/gcc/testsuite/gfortran.dg/diagnostic-format-json-1.F90
trunk/gcc/testsuite/gfortran.dg/diagnostic-format-json-2.F90
trunk/gcc/testsuite/gfortran.dg/diagnostic-format-json-3.F90
Modified:
trunk/gcc/ChangeLog
trunk/gcc/Makefile.in
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-opts.c
trunk/gcc/common.opt
trunk/gcc/diagnostic.c
trunk/gcc/diagnostic.h
trunk/gcc/doc/invoke.texi
trunk/gcc/dwarf2out.c
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/error.c
trunk/gcc/gcc.c
trunk/gcc/jit/ChangeLog
trunk/gcc/jit/dummy-frontend.c
trunk/gcc/lto-wrapper.c
trunk/gcc/opts.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/plugin/diagnostic_plugin_test_show_locus.c
trunk/gcc/testsuite/gcc.dg/plugin/location_overflow_plugin.c

[Bug lto/55102] The options -flto and -On do not behave as described in GCC docs

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||egallager at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #8 from Eric Gallager  ---
(In reply to rguent...@suse.de from comment #7)
> On Thu, 15 Nov 2018, sandra at gcc dot gnu.org wrote:
> 
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55102
> > 
> > sandra at gcc dot gnu.org changed:
> > 
> >What|Removed |Added
> > 
> >  CC||sandra at gcc dot gnu.org
> > 
> > --- Comment #6 from sandra at gcc dot gnu.org ---
> > I've checked in a patch on trunk to replace the bad example with the
> > explanation in Comment 1, suitably translated into user-speak.  However, in
> > subsequent comments this issue wandered off into discussion of enabling IPA
> > automatically with -flto and other related code changes.  Is the issue
> > adequately resolved just by the documentation change, or do we want to keep 
> > it
> > open to track the requested code changes?
> 
> Let's close it.

OK.

[Bug fortran/87751] ICE in gfc_trans_assignment_1, at fortran/trans-expr.c:10255

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-11-15
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
> Down to version 5 at least, with an invalid function reference
> and together with option -fcheck=all or -fcheck=mem :

The test compiles with 4.9.3.

[Bug target/88035] New: missing _mm512_reduce_round_pd() et al

[jbeulich at novell dot com]

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

Bug ID: 88035
   Summary: missing _mm512_reduce_round_pd() et al
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jbeulich at novell dot com
  Target Milestone: ---

Without them there's no way to invoke the SAE forms of VREDUCE{P,S}{D,S}.

See
https://software.intel.com/sites/landingpage/IntrinsicsGuide/#text=reduce&techs=AVX_512.

[Bug middle-end/87854] [9 Regression] gcc.c-torture/compile/pr46534.c ICE for 16-bit size_t

[jozef.l at mittosystems dot com]

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

--- Comment #4 from Jozef Lawrynowicz  ---
Thanks, the patch fixes the ICE on msp430-elf and the test now outputs:

> gcc.c-torture/compile/pr46534.c:17:3: error: size of string literal is too 
> large

[Bug fortran/87939] [F18] Support STAT= and ERRMSG= specifiers to CRITICAL and TEAM statements

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-11-15
 Blocks||83700
Summary|Support STAT= and ERRMSG=   |[F18] Support STAT= and
   |specifiers to CRITICAL and  |ERRMSG= specifiers to
   |TEAM statements |CRITICAL and TEAM
   ||statements
 Ever confirmed|0   |1


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83700
[Bug 83700] [Meta-bug] Fortran Coarray issues

[Bug middle-end/87854] [9 Regression] gcc.c-torture/compile/pr46534.c ICE for 16-bit size_t

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Yeah, that is the goal.  And you should either add msp430-*-* to dg-skip-if, or
do we have some effective targets for all targets with 16-bit size_t (or
perhaps < 32-bit), so that we could skip them all at once?

[Bug fortran/87326] [F18] Support the NEW_INDEX= specifier in the FORM TEAM statement

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2018-11-15
 Blocks||83700
Summary|Support the NEW_INDEX=  |[F18] Support the
   |specifier in the FORM TEAM  |NEW_INDEX= specifier in the
   |statement   |FORM TEAM statement
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Could not this PR be merged with pr87939?


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83700
[Bug 83700] [Meta-bug] Fortran Coarray issues

[Bug middle-end/88032] [9 Regression] ICE in operand_subword_force, at emit-rtl.c:1793

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  ---
Created attachment 45009
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45009&action=edit
gcc9-pr88032.patch

Untested fix.  The problem as I see is that while operand_subword will for mode
== VOIDmode just pick the mode from the operand's mode, so it is important to
pass it only if the operand has VOIDmode, operand_subword_force actually with
VOIDmode argument acts just as operand_subword that asserts the result is
non-NULL.  That is something we don't want in this case, e.g. because op is a
hard register that we need to force into a pseudo to be able to create a subreg
out of it.

[Bug c++/88036] New: bogus "was not declared in this scope; did you mean ...?" fix-it when the declaration was ill-formed

[redi at gcc dot gnu.org]

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

Bug ID: 88036
   Summary: bogus "was not declared in this scope; did you mean
...?" fix-it when the declaration was ill-formed
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: enhancement
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
CC: dmalcolm at gcc dot gnu.org
  Target Milestone: ---

void* f()
{
  undeclared_type fool;
  __attribute__((unused)) int food = 0;

  return &fool;
}

This produces:

dym.cc: In function 'void* f()':
dym.cc:3:3: error: 'undeclared_type' was not declared in this scope
3 |   undeclared_type fool;
  |   ^~~
dym.cc:6:11: error: 'fool' was not declared in this scope; did you mean 'food'?
6 |   return &fool;
  |   ^~~~
  |   food


Obviously the first error is correct, but the second one is unhelpful. It *was*
declared, but the declaration produced an error.

That second error would be ignorable if it didn't add the "did you mean ...?"
prompt and show a fix-it that comprises 50% of the output. No, I didn't mean
"food", and I don't want to fix it.

Could we maybe keep a list of erroneous declarations, and ignore uses of them
later? Or at least suppress the fix-it?

[Bug c++/88036] bogus "was not declared in this scope; did you mean ...?" fix-it when the declaration was ill-formed

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
I realise this is non-trivial, because the erroneous declaration may not even
have been parsed as a declaration.

[Bug c++/88036] bogus "was not declared in this scope; did you mean ...?" fix-it when the declaration was ill-formed

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
Slightly simpler testcase, that doesn't need the attribute to avoid the
-Wunused-variable warning:

int food = 0;

void* f()
{
  undeclared_type fool;
  return &fool;
}

[Bug libstdc++/88037] New: std::string pretty printer causes "virtual memory exhausted" when used on uninitialized data

[walther at indel dot ch]

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

Bug ID: 88037
   Summary: std::string pretty printer causes "virtual memory
exhausted" when used on uninitialized data
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: walther at indel dot ch
  Target Milestone: ---

The Python pretty printer for std::string places no limit on the printed string
length, which means that when looking at uninitialized memory that happens to
have a huge value where the length field is expected, GDB dies trying to
allocate memory to fetch the lazy string:

../../gdb/utils.c:1053: internal-error: virtual memory exhausted: can't
allocate 208096 bytes.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) [answered Y; input not from terminal]
../../gdb/utils.c:1053: internal-error: virtual memory exhausted: can't
allocate 208096 bytes.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Create a core file of GDB? (y or n) [answered Y; input not from terminal]

In my case, this happened when stopped on a breakpoint at the beginning of a
function where further down a local std::string variable is declared and
initialized, and my GUI frontend issued MI command -stack-list-locals. The
returned list already included this local variable, even though it was not
initialized yet. Of course, corrupted or uninitialized variables can occur for
any number of other reasons when analyzing a faulty program.

I suggest adding something along the lines of

diff --git a/libstdc++-v3/python/libstdcxx/v6/printers.py
b/libstdc++-v3/python/libstdcxx/v6/printers.py
index 827c87b70..ba3606e3b 100644
--- a/libstdc++-v3/python/libstdcxx/v6/printers.py
+++ b/libstdc++-v3/python/libstdcxx/v6/printers.py
@@ -830,6 +830,10 @@ class StdStringPrinter:
 reptype = gdb.lookup_type (str (realtype) + '::_Rep').pointer ()
 header = ptr.cast(reptype) - 1
 length = header.dereference ()['_M_length']
+if length > 1:
+# We may be looking at uninitialized memory and trying to print a
+# multigigabyte string would run GDB out of memory.
+return ptr.string(length = 100) + ('... (length: %d)' % length)
 if hasattr(ptr, "lazy_string"):
 return ptr.lazy_string (length = length)
 return ptr.string (length = length)

[Bug middle-end/87854] [9 Regression] gcc.c-torture/compile/pr46534.c ICE for 16-bit size_t

[jozef.l at mittosystems dot com]

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

--- Comment #6 from Jozef Lawrynowicz  ---
(In reply to Jakub Jelinek from comment #5)
> Yeah, that is the goal.  And you should either add msp430-*-* to dg-skip-if,
> or do we have some effective targets for all targets with 16-bit size_t (or
> perhaps < 32-bit), so that we could skip them all at once?

Effective target "size32plus" checks if an array with 24-bit size compiles
successfully so would cover this test.

I wonder if it would be better to add a dg-error directive (which references
this PR) for these targets rather than skipping the test?

[Bug tree-optimization/88011] [9 regression] r266028 causes a bunch of go failures

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-11-15
 CC|rguenther at suse dot de   |
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Ever confirmed|0   |1

[Bug middle-end/87854] [9 Regression] gcc.c-torture/compile/pr46534.c ICE for 16-bit size_t

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
For some yes.  I assume not e.g. for nvptx as it has 64-bit size_t but can't
compile it for other reasons.

[Bug libstdc++/88037] std::string pretty printer causes "virtual memory exhausted" when used on uninitialized data

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-11-15
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
We might want some user control to allow overriding the safety check. It's
possible somebody really wants to print the whole of their huge string (and has
the memory to make it work).

This seems related to Bug 59170 (although not exactly the same, as printing
strings automatically is desirable, unlike printing iterators).

[Bug middle-end/88038] New: ICE: in check, at tree-vrp.c:155: recipe for target 'all-stage3-isl' failed

[ibuclaw at gdcproject dot org]

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

Bug ID: 88038
   Summary: ICE: in check, at tree-vrp.c:155: recipe for target
'all-stage3-isl' failed
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ibuclaw at gdcproject dot org
  Target Milestone: ---

Seen when bootstrapping.

/buildkite/ubuntu-cross1/gcc/isl/isl_tab_pip.c: In function
'isl_tab_basic_set_non_trivial_lexmin':
/buildkite/ubuntu-cross1/gcc/isl/isl_tab_pip.c:5075:21: internal compiler
error: in check, at tree-vrp.c:155
 5075 | __isl_give isl_vec *isl_tab_basic_set_non_trivial_lexmin(
  | ^~~~
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
Makefile:1397: recipe for target 'isl_tab_pip.lo' failed
make[5]: *** [isl_tab_pip.lo] Error 1
make[5]: *** Waiting for unfinished jobs
make[3]: Entering directory '/buildkite/ubuntu-cross1/gcc/build/mpfr'
Making all in doc
Making all in src
make[5]: Leaving directory '/buildkite/ubuntu-cross1/gcc/build/isl'
Makefile:1505: recipe for target 'all-recursive' failed
make[4]: *** [all-recursive] Error 1
make[4]: Leaving directory '/buildkite/ubuntu-cross1/gcc/build/isl'
Makefile:1110: recipe for target 'all' failed
make[3]: *** [all] Error 2
make[3]: Leaving directory '/buildkite/ubuntu-cross1/gcc/build/isl'
Makefile:8853: recipe for target 'all-stage3-isl' failed
make[2]: *** [all-stage3-isl] Error 2
make[2]: *** Waiting for unfinished jobs

[Bug tree-optimization/88038] ICE: in check, at tree-vrp.c:155: recipe for target 'all-stage3-isl' failed

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org
  Component|middle-end  |tree-optimization

--- Comment #1 from Richard Biener  ---
There is no assert in that place..?!  So, what revision are we talking about?

Can you provide preprocessed source, flags, etc.?  I assume x86_64-linux?

[Bug d/88039] New: gdc.test/compilable/ddoc12.d FAILs

[ro at gcc dot gnu.org]

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

Bug ID: 88039
   Summary: gdc.test/compilable/ddoc12.d FAILs
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: ro at gcc dot gnu.org
  Target Milestone: ---
Target: *-*-solaris2.*

The gdc.test/compilable/ddoc12.d test FAILs when using Solaris as:

FAIL: compilable/ddoc12.d   output-exists ddoc12.o

On sparc, one sees

/usr/ccs/bin/as: "/var/tmp//ccg60S0d.s", line 10: error: invalid character
(0xc3)
/usr/ccs/bin/as: "/var/tmp//ccg60S0d.s", line 10: error: invalid character
(0xbc)
/usr/ccs/bin/as: "/var/tmp//ccg60S0d.s", line 10: error: statement syntax
/usr/ccs/bin/as: "/var/tmp//ccg60S0d.s", line 12: error: invalid character
(0xc3)
/usr/ccs/bin/as: "/var/tmp//ccg60S0d.s", line 12: error: invalid character
(0xbc)
/usr/ccs/bin/as: "/var/tmp//ccg60S0d.s", line 12: error: invalid number of
operands
/usr/ccs/bin/as: "/var/tmp//ccg60S0d.s", line 12: error: statement syntax
/usr/ccs/bin/as: "/var/tmp//ccg60S0d.s", line 13: error: invalid character
(0xc3)
/usr/ccs/bin/as: "/var/tmp//ccg60S0d.s", line 13: error: invalid character
(0xbc)
/usr/ccs/bin/as: "/var/tmp//ccg60S0d.s", line 13: error: invalid number of
operands
/usr/ccs/bin/as: "/var/tmp//ccg60S0d.s", line 13: error: statement syntax
/usr/ccs/bin/as: "/var/tmp//ccg60S0d.s", line 14: error: unknown opcode
"_D6ddoc127r"
/usr/ccs/bin/as: "/var/tmp//ccg60S0d.s", line 14: error: invalid character
(0xc3)
/usr/ccs/bin/as: "/var/tmp//ccg60S0d.s", line 14: error: invalid character
(0xbc)
/usr/ccs/bin/as: "/var/tmp//ccg60S0d.s", line 14: error: statement syntax
compiler exited with status 1
PASS: gdc.test/compilable/ddoc12.d   (test for excess errors)
FAIL: gdc.test/compilable/ddoc12.d   output-exists ddoc12.o

while on i386 I get:

Assembler: ddoc12.d
"/var/tmp//ccyEVXoa.s", line 10 : Syntax error
Near line: ".globl  _D6ddoc127rühredi"
"/var/tmp//ccyEVXoa.s", line 10 : Syntax error
Near line: ".globl  _D6ddoc127rühredi"
"/var/tmp//ccyEVXoa.s", line 10 : Syntax error
Near line: ".globl  _D6ddoc127rühredi"
"/var/tmp//ccyEVXoa.s", line 12 : Syntax error
Near line: ".type   _D6ddoc127rühredi, @tls_obj"
"/var/tmp//ccyEVXoa.s", line 12 : Syntax error
Near line: ".type   _D6ddoc127rühredi, @tls_obj"
"/var/tmp//ccyEVXoa.s", line 12 : Syntax error
Near line: ".type   _D6ddoc127rühredi, @tls_obj"
"/var/tmp//ccyEVXoa.s", line 13 : Syntax error
Near line: ".size   _D6ddoc127rühredi, 4"
"/var/tmp//ccyEVXoa.s", line 13 : Syntax error
Near line: ".size   _D6ddoc127rühredi, 4"
"/var/tmp//ccyEVXoa.s", line 13 : Syntax error
Near line: ".size   _D6ddoc127rühredi, 4"
"/var/tmp//ccyEVXoa.s", line 14 : Syntax error
Near line: "_D6ddoc127rühredi:"
"/var/tmp//ccyEVXoa.s", line 14 : Syntax error
Near line: "_D6ddoc127rühredi:"
"/var/tmp//ccyEVXoa.s", line 14 : Illegal mnemonic
Near line: "_D6ddoc127rühredi:"
"/var/tmp//ccyEVXoa.s", line 14 : Syntax error
Near line: "_D6ddoc127rühredi:"
"/var/tmp//ccyEVXoa.s", line 14 : Syntax error
Near line: "_D6ddoc127rühredi:"
compiler exited with status 1
PASS: compilable/ddoc12.d   (test for excess errors)
FAIL: compilable/ddoc12.d   output-exists ddoc12.o

The problem obviously is that the native assemblers don't support UTF-8 in
identifiers (and I bet there are other non-gas assemblers that don't either).

Besides, we again see the obnoxious effect of gdc-test.exp's 

// { dg-prune-output .* }

which effectively masks all errors, letting the test for excess errors wrongly
PASS.

[Bug d/88040] New: gdc silently ignores -ffile-prefix-map

[ro at gcc dot gnu.org]

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

Bug ID: 88040
   Summary: gdc silently ignores -ffile-prefix-map
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: ro at gcc dot gnu.org
  Target Milestone: ---

While working on a patch to include the gdc.test prefix in those test names,
I noticed that gdc silently ignores the -ffile-prefix-map option.  I could
certainly use it for reproducible builds and to solve one remaining issue in
a patch for the gdc.test prefix issue (to be submitted shortly).

Part of the implementation of that option for C family languages lives in
libcpp
and is this not appropriate for D, but the language has __FILE__ and
__FILE_FULL_PATH__ which could use similar treatment.

[Bug libstdc++/88037] std::string pretty printer causes "virtual memory exhausted" when used on uninitialized data

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
(In reply to Christian Walther from comment #0)
> +# multigigabyte string would run GDB out of memory.
> +return ptr.string(length = 100) + ('... (length: %d)' % length)

Instead of 100 here we should use gdb.parameter("print elements")

[Bug tree-optimization/88038] ICE: in check, at tree-vrp.c:155: recipe for target 'all-stage3-isl' failed

[ibuclaw at gdcproject dot org]

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

--- Comment #2 from Iain Buclaw  ---
Build log is when testing r265361 from a couple weeks back.

Looking at recent history, the assert has been removed from the function since
then.

I'll trigger a rebuild to see if its still happening.

[Bug testsuite/88041] New: gdc.test tests should include that prefix in test names

[ro at gcc dot gnu.org]

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

Bug ID: 88041
   Summary: gdc.test tests should include that prefix in test
names
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
CC: ibuclaw at gcc dot gnu.org
Depends on: 88040
  Target Milestone: ---

Created attachment 45010
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45010&action=edit
proposed patch

The gdc.test tests currently omit that prefix from the test names and are thus
not in line with GCC and DejaGnu conventions.

I've started working on this.  In a first attempt, I tried to fix gdc-test.exp,
generating the preprocessed tests in a gdc.test subdir.  However, that turned
out to be pretty intrusive and finally fell apart when I noticed that several
of the tests assume the current names due to something like

// REQUIRED_ARGS: -lib -Icompilable/imports

Of course, I could also insert gdc.test/ there during preprocessing, but this
seems like a loosing battle.

Instead, I took a different route: simply create a symlink from gdc.test to .
so both the prefixed and unprefixed names work.

The resulting patch is almost trivial and works with just two exceptions:

dc.test/compilable/line.d:17:5: error: static assert 
("gdc.test/compilable/line.d" == "compilable/line.d") is false
compiler exited with status 1
PASS: gdc.test/compilable/line.d   (test for excess errors)
FAIL: gdc.test/compilable/line.d   output-exists line.o

gdc.test/runnable/testkeyword.d:9:1: error: static assert  (getCalleeFile() ==
"runnable/imports/testkwd_file.d") is false
compiler exited with status 1
PASS: gdc.test/runnable/testkeyword.d   (test for excess errors)
UNRESOLVED: gdc.test/runnable/testkeyword.d   compilation failed to produce
executable

This is where gdc support for -ffile-prefix-map (PR d/88040) would come in
quite handy.

I'm attaching the current patch, which also contains two minor issues I 
discovered during the first implementation of the patch: two files have
EXTRA_SOURCES: lines with absolute pathnames, which cannot be right.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88040
[Bug 88040] gdc silently ignores -ffile-prefix-map

[Bug tree-optimization/88031] [9 Regression] ICE in vectorizable_reduction, at tree-vect-loop.c:6953

[dcb314 at hotmail dot com]

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

--- Comment #4 from David Binderman  ---
(In reply to Richard Biener from comment #1)
> Thanks for testing GCC 9!

You are welcome.

Just an amateur project. I could get more serious about this,
given enough encouragement. 

For example all of Fedora compiled with -O3 on ARM hardware,
or all of Debian with -O3 on X86 and ARM are future projects.

[Bug rtl-optimization/87475] [8/9 Regression] ICE in patch_jump_insn, at cfgrtl.c:1275

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
Doesn't seem to.  The cfg layout cleanup code simply tries to redirect a
CROSSING_JUMP_P, which apparently on aarch64 looks like:
(insn 119 80 120 5 (set (reg:DI 110)
(high:DI (label_ref:DI 19))) -1
 (insn_list:REG_LABEL_OPERAND 19 (nil)))
(insn 120 119 121 5 (set (reg:DI 109)
(lo_sum:DI (reg:DI 110)
(label_ref:DI 19))) -1
 (insn_list:REG_LABEL_OPERAND 19 (expr_list:REG_EQUAL (label_ref:DI 19)
(nil
(jump_insn/j 121 120 19 5 (set (pc)
(reg:DI 109)) -1
 (nil)
 -> 19)
and fails to adjust that, because the insn doesn't have the label directly in
the insn, it is like a computed jump, but not recognized as such because it has
non-NULL JUMP_LABEL.

[Bug middle-end/87836] ICE in cc1 for gcc-6.5.0 with SPARC hardware

[gary_mills at fastmail dot fm]

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

--- Comment #11 from Gary Mills  ---
Well, I got the same ICE when the compiler was built with -O0.  It always seems
to happen during the configure tests, always this one:

configure:3662: checking for suffix of object files
configure:3684:
/export/home/mills/Downloads/code/oi-userland/components/developer/gcc-7/build/sparcv7/./gcc/xgcc
-B/export/home/mills/Downloads/code/oi-userland/components/developer/gcc-7/build/sparcv7/./gcc/
-B/usr/gcc/7/sparc-sun-solaris2.11/bin/ -B/usr/gcc/7/sparc-sun-solaris2.11/lib/
-isystem /usr/gcc/7/sparc-sun-solaris2.11/include -isystem
/usr/gcc/7/sparc-sun-solaris2.11/sys-include-c -O2 -g -O0  conftest.c >&5
conftest.c: In function 'main':
conftest.c:11:1: internal compiler error: Segmentation Fault

Here's some information on the intermediate compiler:

$ build/sparcv7/./gcc/xgcc -v   
Using built-in specs.
COLLECT_GCC=build/sparcv7/./gcc/xgcc
Target: sparc-sun-solaris2.11
Configured with:
/export/home/mills/Downloads/code/oi-userland/components/developer/gcc-7/gcc-7.3.0/configure
CC=/usr/gcc/4.9/bin/gcc CXX=/usr/gcc/4.9/bin/g++ F77=/usr/gcc/4.9/bin/gfortran
FC=/usr/gcc/4.9/bin/gfortran CFLAGS='-g -O0' CXXFLAGS=' ' FFLAGS=' ' FCFLAGS=
LDFLAGS=-m32 PKG_CONFIG_PATH=/usr/lib/pkgconfig --prefix=/usr/gcc/7
--mandir=/usr/gcc/7/share/man --bindir=/usr/gcc/7/bin --libdir=/usr/gcc/7/lib
--sbindir=/usr/gcc/7/sbin --sbindir=/usr/gcc/7/bin --libdir=/usr/gcc/7/lib
--libexecdir=/usr/gcc/7/lib --host sparc-sun-solaris2.11 --build
sparc-sun-solaris2.11 --target sparc-sun-solaris2.11
--with-pkgversion='OpenIndiana 7.3.0-OI-0'
--with-bugurl=https://bugs.openindiana.org --enable-plugins --enable-objc-gc
--enable-initfini-array --enable-languages=c,c++,fortran,lto,objc
--without-gnu-ld --with-ld=/usr/bin/ld
--with-build-time-tools=/usr/gnu/sparc-sun-solaris2.11/bin --disable-libitm
--without-gnu-as --with-as=/usr/bin/as LDFLAGS=-R/usr/gcc/7/lib
Thread model: posix
gcc version 7.3.0 (OpenIndiana 7.3.0-OI-0)

[Bug ada/88042] New: ICE in output_operand: invalid address mode, with -mabi=ilp32

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

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

Bug ID: 88042
   Summary: ICE in output_operand: invalid address mode, with
-mabi=ilp32
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sch...@linux-m68k.org
  Target Milestone: ---
Target: aarch64-*-*

$ ./gnat1 -I ../../gcc/testsuite/gnat.dg/ -I - -quiet -dumpbase rt_signals.adb
-auxbase rt_signals -fdiagnostics-color=never
-fRTS=../aarch64-suse-linux/ilp32/libada -mabi=ilp32
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers -mlittle-endian
../../gcc/testsuite/gnat.dg/rt_signals.adb
+===GNAT BUG DETECTED==+
| 9.0.0 20181115 (experimental) [trunk revision 266169] (aarch64-suse-linux)
GCC error:|
| output_operand: invalid address mode |
| Error detected around
/opt/gcc/gcc-20181115/gcc/testsuite/gnat.dg/rt_signals.adb:14:5|

This is the offending insn:

(insn 13 11 14 (set (mem/c:SI (reg:SI 0 x0 [102]) [0  S4 A8])
(reg:SI 1 x1 [104])) "../../gcc/testsuite/gnat.dg/rt_signals.adb":5:1
46 {*movsi_aarch64}
 (nil))

[Bug c++/87989] [8/9 Regression] Calling operator T() invokes wrong conversion operator overload

[kretz at kde dot org]

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

--- Comment #4 from Matthias Kretz  ---
Yes, looks like a duplicate of 86246.

[Bug rtl-optimization/87475] [8/9 Regression] ICE in patch_jump_insn, at cfgrtl.c:1275

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #4 from Jakub Jelinek  ---
Created attachment 45011
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45011&action=edit
gcc9-pr87475.patch

Untested fix.  Though, not really sure about it.

[Bug libstdc++/88037] std::string pretty printer causes "virtual memory exhausted" when used on uninitialized data

[walther at indel dot ch]

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

--- Comment #3 from Christian Walther  ---
> It's possible somebody really wants to print the whole of their huge string
> (and has the memory to make it work).

Fair point. I figured that someone wanting to read a legitimately huge string
would rather use memory examination commands than pretty-printing.

> Instead of 100 here we should use gdb.parameter("print elements")

Ah, that’s what I was looking for – I gave up after finding that the relevant
options->print_max was not passed on to Python, but it didn’t occur to me that
it could be queried that way.

However, I just discovered that from GDB 7.7 on
(https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commitdiff;h=f380848e84613364a17008f04e91bfef09eaf158)
(I was using 7.6), fetching lazy strings automatically observes the print_max,
so it should no longer run out of memory. So the whole point may be moot. All
that my solution adds in this case is the display of the actual length.

[Bug fortran/88043] New: Runtime Error when calling deferred member function

[zjibben at gmail dot com]

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

Bug ID: 88043
   Summary: Runtime Error when calling deferred member function
   Product: gcc
   Version: 8.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zjibben at gmail dot com
CC: neil.n.carlson at gmail dot com
  Target Milestone: ---

A call to a deferred member procedure ends up calling a different procedure
instead. It looks like the virtual function table is incorrect when passing
between two source files. I have a small example (~100 lines) in two source
files here:

https://github.com/nncarlson/fortran-compiler-tests/blob/master/gfortran-bugs/gfortran-20181114-main.f90

https://github.com/nncarlson/fortran-compiler-tests/blob/master/gfortran-bugs/gfortran-20181114.f90

In this case, the routine never_call1 is called recursively, despite there
being no real calls to that function. With -fcheck=all this is caught,
otherwise it will consume your entire stack. Compiled using gfortran 8.2.1
20180831:

$ gfortran -g -fcheck=all gfortran-20181114.f90 gfortran-20181114-main.f90
$ ./a.out
At line 39 of file gfortran-20181114.f90
Fortran runtime error: Recursive call to nonrecursive procedure 'never_call1'

Error termination. Backtrace:
#0  0x55b1599cd19d in __foo_class_MOD_never_call1
at .../gfortran-20181114.f90:39
#1  0x55b1599cd1bc in __foo_class_MOD_never_call1
at .../gfortran-20181114.f90:42
#2  0x55b1599cd220 in __foo_class_MOD_call_me
at .../gfortran-20181114.f90:34
#3  0x55b1599cd449 in test
at .../gfortran-20181114-main.f90:42
#4  0x55b1599cd49f in main
at .../gfortran-20181114-main.f90:32

[Bug tree-optimization/88044] New: [9 regression] gfortran.dg/transfer_intrinsic_3.f90 hangs after r266171

[seurer at gcc dot gnu.org]

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

Bug ID: 88044
   Summary: [9 regression] gfortran.dg/transfer_intrinsic_3.f90
hangs after r266171
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

After r266171 this test case is hanging on powerpc64 both be and le when
compiled with -O3.  If I run it via make check

make -k check-fortran RUNTESTFLAGS=dg.exp=gfortran.dg/transfer_intrinsic_3.f90

it normally finishes in a few minutes but with the run I started a bit ago the
executable has been running over 25 minutes:

 43548 pts/1R+25:34 ./transfer_intrinsic_3.exe


Executing on host:
/home/seurer/gcc/build/gcc-test2/gcc/testsuite/gfortran/../../gfortran
-B/home/seurer/gcc/build/gcc-test2/gcc/testsuite/gfortran/../../
-B/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libgfortran/
/home/seurer/gcc/gcc-test2/gcc/testsuite/gfortran.dg/transfer_intrinsic_3.f90  
 -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never-O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions   -pedantic-errors 
-B/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libgfortran/.libs
-L/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libgfortran/.libs
-L/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libgfortran/.libs
-L/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libatomic/.libs
-B/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libquadmath/.libs
-L/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libquadmath/.libs
-L/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libquadmath/.libs
 -lm  -o ./transfer_intrinsic_3.exe(timeout = 300)
spawn -ignore SIGHUP
/home/seurer/gcc/build/gcc-test2/gcc/testsuite/gfortran/../../gfortran
-B/home/seurer/gcc/build/gcc-test2/gcc/testsuite/gfortran/../../
-B/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libgfortran/
/home/seurer/gcc/gcc-test2/gcc/testsuite/gfortran.dg/transfer_intrinsic_3.f90
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops
-ftracer -finline-functions -pedantic-errors
-B/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libgfortran/.libs
-L/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libgfortran/.libs
-L/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libgfortran/.libs
-L/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libatomic/.libs
-B/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libquadmath/.libs
-L/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libquadmath/.libs
-L/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libquadmath/.libs
-lm -o ./transfer_intrinsic_3.exe
PASS: gfortran.dg/transfer_intrinsic_3.f90   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  (test for excess
errors)
Setting LD_LIBRARY_PATH to
.:/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libgfortran/.libs:/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libgfortran/.libs:/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libatomic/.libs:/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libquadmath/.libs:/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libquadmath/.libs:/home/seurer/gcc/build/gcc-test2/gcc:.:/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libgfortran/.libs:/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libgfortran/.libs:/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libatomic/.libs:/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libquadmath/.libs:/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libquadmath/.libs:/home/seurer/gcc/build/gcc-test2/gcc:/home/seurer/gcc/build/gcc-test2/./gmp/.libs:/home/seurer/gcc/build/gcc-test2/./prev-gmp/.libs:/home/seurer/gcc/build/gcc-test2/./mpfr/src/.libs:/home/seurer/gcc/build/gcc-test2/./prev-mpfr/src/.libs:/home/seurer/gcc/build/gcc-test2/./mpc/src/.libs:/home/seurer/gcc/build/gcc-test2/./prev-mpc/src/.libs:/home/seurer/gcc/build/gcc-test2/./isl/.libs:/home/seurer/gcc/build/gcc-test2/./prev-isl/.libs:.:/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libgomp/.libs:/home/seurer/gcc/build/gcc-test2/gcc:.:/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libgomp/.libs:/home/seurer/gcc/build/gcc-test2/gcc:/home/seurer/gcc/build/gcc-test2/./gmp/.libs:/home/seurer/gcc/build/gcc-test2/./prev-gmp/.libs:/home/seurer/gcc/build/gcc-test2/./mpfr/src/.libs:/home/seurer/gcc/build/gcc-test2/./prev-mpfr/

[Bug c++/87476] [9 Regression] char-array initialized from wide-string

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #3 from Jakub Jelinek  ---
I see two options out of this.
Either don't call braced_list_to_string when processing_template_decl, defer
that only until instantiation time, like:
--- gcc/cp/typeck2.c.jj 2018-09-25 15:14:43.961258143 +0200
+++ gcc/cp/typeck2.c2018-11-15 17:38:17.471479857 +0100
@@ -807,7 +807,8 @@ store_init_value (tree decl, tree init,
 /* Digest the specified initializer into an expression.  */
 value = digest_init_flags (type, init, flags, tf_warning_or_error);

-  if (TREE_CODE (type) == ARRAY_TYPE
+  if (!processing_template_decl
+  && TREE_CODE (type) == ARRAY_TYPE
   && TYPE_STRING_FLAG (TREE_TYPE (type))
   && TREE_CODE (value) == CONSTRUCTOR)
 value = braced_list_to_string (type, value);
The question is if there is a guarantee that store_init_value will be called
again during instantiation.

Or revert the:
@@ -1058,9 +1063,7 @@

  if (TYPE_PRECISION (typ1) == BITS_PER_UNIT)
{
- if (char_type != char_type_node
- && char_type != signed_char_type_node
- && char_type != unsigned_char_type_node)
+ if (char_type != char_type_node)
{
  if (complain & tf_error)
error_at (loc, "char-array initialized from wide string");
hunk of the commit, I don't really see rationale for that change.  If as in
this testcase the STRING_CST has unsigned_char_type_node as element type, it
still isn't a wide string.  One can also wonder if that
if (char_type == char_type_node)
a few lines later shouldn't be || char_type == signed_char_type_node ||
char_type == unsigned_char_type_node.

[Bug gcov-profile/88045] New: Call to std::accumulate causes gcov to crash

[loximann at gmail dot com]

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

Bug ID: 88045
   Summary: Call to std::accumulate causes gcov to crash
   Product: gcc
   Version: 8.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: gcov-profile
  Assignee: unassigned at gcc dot gnu.org
  Reporter: loximann at gmail dot com
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

Created attachment 45012
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45012&action=edit
Minimum reproducible example

gcov 8.2.1 segfaults for a certain file.

terminate called after throwing an instance of 'std::bad_alloc'
  what():  std::bad_alloc
zsh: abort (core dumped)  gcov main.gcda

The stack trace looks like this:

#0  0x77c9153f in raise () from /lib64/libc.so.6
#1  0x77c7b895 in abort () from /lib64/libc.so.6
#2  0x00438f27 in __gnu_cxx::__verbose_terminate_handler() [clone
.cold.1] ()
#3  0x0046833c in __cxxabiv1::__terminate(void (*)()) ()
#4  0x00468397 in std::terminate() ()
#5  0x004692b8 in __cxa_throw ()
#6  0x004675b4 in operator new(unsigned long) ()
#7  0x00454fa4 in std::vector
>::_M_default_append(unsigned long) ()
#8  0x0043b542 in main ()

The minimal reproducible example I managed to produce:

###
#include 
#include 

struct Foo {
size_t size() const { return n; };
const size_t n;
explicit Foo(size_t a_n) : n{a_n} {};
};

template class C, typename Head, typename... Tail>
struct make_with_tail {
using type = C;
};

template class C, typename T, typename Head, typename...
Tail>
struct make_with_tail_1 {
using type = C;
};

template
struct head {
using type = Head;
};
template
struct Tree {
using root_type = typename head::type;
using branch_type = typename make_with_tail::type;
Tree(root_type a_root, std::vector a_branches) :
root{std::move(a_root)},
branches{std::move(a_branches)}
{
}

explicit Tree(root_type a_root) : root{std::move(a_root)},
branches{root.size()}
{
}

root_typeroot;
std::vector branches;
};

template<>
struct Tree<> {
};

template
size_t size(const Tree& tree)
{
return std::accumulate(
tree.branches.begin(),
tree.branches.end(),
0,
[](const size_t& count, const typename make_with_tail::type& branch) {
return count + size(branch);
});
}

template<>
inline size_t size(const Tree<>& /* empty tree */)
{
return 1;
}

int main(int argc, char *argv[])
{
size(Tree{Foo{4}, {Tree{Foo{2},
{Tree{Foo{205}},
 
Tree{Foo{261,
  Tree{Foo{4},
{Tree{Foo{875}},
 
Tree{Foo{492}},
 
Tree{Foo{398}},
 
Tree{Foo{302,
  Tree{Foo{6},
{Tree{Foo{111}},
 
Tree{Foo{436}},
 
Tree{Foo{388}},
 
Tree{Foo{879}},
 
Tree{Foo{783}},
 
Tree{Foo{735,
  Tree{Foo{3},
{Tree{Foo{791}},
  Tree{Foo{ 
5}},
 
Tree{Foo{841}});

return 0;
}
###

Replacing the call to std::accumulate with a loop fixes the issue.

[Bug middle-end/87854] [9 Regression] gcc.c-torture/compile/pr46534.c ICE for 16-bit size_t

[jozef.l at mittosystems dot com]

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

--- Comment #8 from Jozef Lawrynowicz  ---
(In reply to Jakub Jelinek from comment #7)
> For some yes.  I assume not e.g. for nvptx as it has 64-bit size_t but can't
> compile it for other reasons.

Ok, I'll make sure to check that.

The new error catches gcc.dg/concat2.c and g++.dg/parse/concat1.C which
previously passed for msp430-elf. In these tests it is a 16-bit string (10^5)
which is rightly too large for this target, but there is a note in the test:

> The fact that the string isn't actually used in the resulting program
> should allow this to compile for any target.

So just want to make sure that it is ok that this assumption can no longer be
made.

I'll then add the relevant dg-error directives for these tests and pr46534.

[Bug c/61727] #pragma simd is undocumented

[andi-gcc at firstfloor dot org]

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

--- Comment #4 from Andi Kleen  ---
This was originally about the #pragma simd in CIlk+, which has been removed.
But it lives on in #pragma omp simd

[Bug c++/79393] [7/8/9 Regression] cc1plus rejects valid code with noexcept

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

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

--- Comment #12 from Nathan Sidwell  ---
Fixed r266188.
[C++ DR 2336] virtual dtors, exception specs & abstract classes

https://gcc.gnu.org/ml/gcc-patches/2018-11/msg01389.html
DR 2336
* cp-tree.h (enum special_function_kind): Add sfk_virtual_destructor.
* method.c (type_has_trivial_fn): Add it.
(SFK_DTOR_P): Likewise.
(synthesized_method_base_walk): Don't check access of vbases of
abstract classes when sfk_virtual_destructor.
(synthesized_method_walk): Skip vbases of abstract classes except
when sfk_virtual_destructor.
(get_defaulted_eh_spec): Set sfk_virtual_destructor as needed.

* g++.dg/cpp1y/pr79393-3.C: New.

[Bug c++/86246] [8/9 Regression] Template dispatching error inside a template function

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

 CC||kretz at kde dot org

--- Comment #7 from Nathan Sidwell  ---
*** Bug 87989 has been marked as a duplicate of this bug. ***

[Bug c++/87989] [8/9 Regression] Calling operator T() invokes wrong conversion operator overload

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

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

--- Comment #5 from Nathan Sidwell  ---
Yes, it's the same bug

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