[Bug target/93376] New: [10 Regression] ICE: in immed_wide_int_const_1, at emit-rtl.c:660 with -Og -finline-functions-called-once

[zsojka at seznam dot cz]

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

Bug ID: 93376
   Summary: [10 Regression] ICE: in immed_wide_int_const_1, at
emit-rtl.c:660 with -Og -finline-functions-called-once
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu

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

Compiler output:
$ x86_64-pc-linux-gnu-gcc -Og -finline-functions-called-once testcase.c
during RTL pass: combine
testcase.c: In function 'foo':
testcase.c:16:1: internal compiler error: in immed_wide_int_const_1, at
emit-rtl.c:660
   16 | }
  | ^
0x6428bb immed_wide_int_const_1
/repo/gcc-trunk/gcc/emit-rtl.c:660
0x106b714 simplify_const_binary_operation(rtx_code, machine_mode, rtx_def*,
rtx_def*)
/repo/gcc-trunk/gcc/simplify-rtx.c:4560
0x106a7c3 simplify_binary_operation(rtx_code, machine_mode, rtx_def*, rtx_def*)
/repo/gcc-trunk/gcc/simplify-rtx.c:2282
0x106ddc2 simplify_const_relational_operation(rtx_code, machine_mode, rtx_def*,
rtx_def*)
/repo/gcc-trunk/gcc/simplify-rtx.c:5456
0x106e3ca simplify_relational_operation(rtx_code, machine_mode, machine_mode,
rtx_def*, rtx_def*)
/repo/gcc-trunk/gcc/simplify-rtx.c:5005
0x1a6cbd3 combine_simplify_rtx
/repo/gcc-trunk/gcc/combine.c:5792
0x1a6f757 subst
/repo/gcc-trunk/gcc/combine.c:5720
0x1a6f8be subst
/repo/gcc-trunk/gcc/combine.c:5653
0x1a6f4f8 subst
/repo/gcc-trunk/gcc/combine.c:5582
0x1a71789 try_combine
/repo/gcc-trunk/gcc/combine.c:3412
0x1a79aa3 combine_instructions
/repo/gcc-trunk/gcc/combine.c:1303
0x1a79aa3 rest_of_handle_combine
/repo/gcc-trunk/gcc/combine.c:15059
0x1a79aa3 execute
/repo/gcc-trunk/gcc/combine.c:15104
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

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

[Bug analyzer/93375] New: ICE in gimple_call_arg, at gimple.h:3258

[asolokha at gmx dot com]

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

Bug ID: 93375
   Summary: ICE in gimple_call_arg, at gimple.h:3258
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: ice-on-invalid-code
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

gcc-10.0.0-alpha20200119 snapshot (g:3684bbb022cd75da55e1457673f269980aa12cdf)
ICEs when compiling the following testcase w/ -fanalyzer:

void
en (jm)
{
}

void
p2 ()
{
  char *rl = 0;

  en ();
  __builtin_memcpy (rl, 0, sizeof (0));
}

% gcc-10.0.0-alpha20200119 -fanalyzer -w -c qm3eevtp.c
during IPA pass: analyzer
cc1: internal compiler error: in gimple_call_arg, at gimple.h:3258
0x71c0a7 gimple_call_arg
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/gimple.h:3258
0x71c0a7 gimple_call_arg
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/gimple.h:3256
0x71c0a7 callgraph_superedge::get_parm_for_arg(tree_node*, callsite_expr*)
const
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/analyzer/supergraph.cc:912
0x1116931 callgraph_superedge::map_expr_from_caller_to_callee(tree_node*,
callsite_expr*) const
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/analyzer/supergraph.cc:934
0x17acac4 diagnostic_manager::prune_for_sm_diagnostic(checker_path*,
state_machine const*, tree_node*, unsigned int) const
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/analyzer/diagnostic-manager.cc:1143
0x17acf0e diagnostic_manager::prune_path(checker_path*, state_machine const*,
tree_node*, unsigned int) const
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/analyzer/diagnostic-manager.cc:936
0x17ad0be diagnostic_manager::emit_saved_diagnostic(exploded_graph const&,
saved_diagnostic const&, exploded_path const&, gimple const*, int)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/analyzer/diagnostic-manager.cc:477
0x17aef9d dedupe_winners::emit_best(diagnostic_manager*, exploded_graph const&)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/analyzer/diagnostic-manager.cc:408
0x17ad442 diagnostic_manager::emit_saved_diagnostics(exploded_graph const&)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/analyzer/diagnostic-manager.cc:451
0x10e305e impl_run_checkers(logger*)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/analyzer/engine.cc:3584
0x10e3ad3 run_checkers()
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/analyzer/engine.cc:3624
0x10d9558 execute
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/analyzer/analyzer-pass.cc:84

[Bug analyzer/93374] New: ICE in validate, at analyzer/region-model.cc:182

[asolokha at gmx dot com]

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

Bug ID: 93374
   Summary: ICE in validate, at analyzer/region-model.cc:182
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

gcc-10.0.0-alpha20200119 snapshot (g:3684bbb022cd75da55e1457673f269980aa12cdf)
ICEs when compiling gcc/testsuite/gcc.c-torture/execute/pr27073.c w/ -O1
-fanalyzer:

% gcc-10.0.0-alpha20200119 -O1 -fanalyzer -w -c
gcc/testsuite/gcc.c-torture/execute/pr27073.c
during IPA pass: analyzer
gcc/testsuite/gcc.c-torture/execute/pr27073.c: In function 'foo':
gcc/testsuite/gcc.c-torture/execute/pr27073.c:8:12: internal compiler error: in
validate, at analyzer/region-model.cc:182
8 |   *p++ = s1;
  |   ~^~~~
0x719ef1 svalue_id::validate(region_model const&) const
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/analyzer/region-model.cc:182
0x719ef1 svalue_id::validate(region_model const&) const
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/analyzer/region-model.cc:180
0x10ee99e state_change::sm_change::validate(program_state const&) const
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/analyzer/program-state.cc:1034
0x10ee99e state_change::validate(program_state const&) const
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/analyzer/program-state.cc:1149
0x10dc0f3 exploded_edge::exploded_edge(exploded_node*, exploded_node*,
superedge const*, state_change const&, exploded_edge::custom_info_t*)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/analyzer/engine.cc:1385
0x10dc0f3 exploded_graph::add_edge(exploded_node*, exploded_node*, superedge
const*, state_change const&, exploded_edge::custom_info_t*)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/analyzer/engine.cc:1987
0x10e2204 exploded_graph::process_node(exploded_node*)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/analyzer/engine.cc:2453
0x10e29b2 exploded_graph::process_worklist()
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/analyzer/engine.cc:2253
0x10e3039 impl_run_checkers(logger*)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/analyzer/engine.cc:3570
0x10e3ad3 run_checkers()
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/analyzer/engine.cc:3624
0x10d9558 execute
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/analyzer/analyzer-pass.cc:84

[Bug analyzer/93373] New: ICE: Segmentation fault (in tree_class_check)

[asolokha at gmx dot com]

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

Bug ID: 93373
   Summary: ICE: Segmentation fault (in tree_class_check)
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

gcc-10.0.0-alpha20200119 snapshot (g:3684bbb022cd75da55e1457673f269980aa12cdf)
ICEs when compiling gcc/testsuite/gcc.dg/Warray-bounds-41.c w/ -O2 -fanalyzer:

% gcc-10.0.0-alpha20200119 -O2 -fanalyzer -c
gcc/testsuite/gcc.dg/Warray-bounds-41.c
during IPA pass: analyzer   
gcc/testsuite/gcc.dg/Warray-bounds-41.c: In function 'test_vptr_arith_vla_cst':
gcc/testsuite/gcc.dg/Warray-bounds-41.c:14:1: internal compiler error:
Segmentation fault
   14 | {
  | ^
0xd8568f crash_signal
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/toplev.c:328
0xa8fde3 tree_class_check(tree_node*, tree_code_class, char const*, int, char
const*)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/tree.h:3400
0xa8fde3 useless_type_conversion_p(tree_node*, tree_node*)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/gimple-expr.c:88
0x1100801 region_model::get_lvalue(path_var, region_model_context*)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/analyzer/region-model.cc:4713
0x1101c1c region_model::get_rvalue_1(path_var, region_model_context*)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/analyzer/region-model.cc:4755
0x1101d93 region_model::get_rvalue(path_var, region_model_context*)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/analyzer/region-model.cc:4792
0x10eee72 sm_state_map::purge_for_unknown_fncall(exploded_graph const&,
state_machine const&, gcall const*, tree_node*, region_model*)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/analyzer/program-state.cc:367
0x10e1b42 exploded_node::on_stmt(exploded_graph&, supernode const*, gimple
const*, program_state*, state_change*) const
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/analyzer/engine.cc:1033
0x10e24d1 exploded_graph::process_node(exploded_node*)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/analyzer/engine.cc:2433
0x10e29b2 exploded_graph::process_worklist()
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/analyzer/engine.cc:2253
0x10e3039 impl_run_checkers(logger*)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/analyzer/engine.cc:3570
0x10e3ad3 run_checkers()
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/analyzer/engine.cc:3624
0x10d9558 execute
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20200119/work/gcc-10-20200119/gcc/analyzer/analyzer-pass.cc:84

[Bug target/93372] cris performance regressions due to de-cc0 work

[hp at gcc dot gnu.org]

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

Hans-Peter Nilsson  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2020-01-22
   Assignee|unassigned at gcc dot gnu.org  |hp at gcc dot gnu.org
   Target Milestone|--- |11.0
 Ever confirmed|0   |1

[Bug target/93372] New: cris performance regressions due to de-cc0 work

[hp at gcc dot gnu.org]

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

Bug ID: 93372
   Summary: cris performance regressions due to de-cc0 work
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hp at gcc dot gnu.org
  Target Milestone: ---
Target: cris-elf

This is a placeholder tracking all cris-specific performance-regressions
related to work of getting rid of "cc0" in the CRIS port.  The initial
regressions are just incidental pruning of various instruction-matching
patterns due to simplifications of the port, but findings due to generic parts
of gcc, is also on topic.

[Bug middle-end/46555] [8/9/10 Regression] PHI RTL expansion leads to CSiBE regression

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #10 from Andrew Pinski  ---
not working on this.

[Bug libstdc++/80331] unused const std::string not optimized away

[egallager at gcc dot gnu.org]

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

Bug 23383 Summary: builtin array operator new is not marked with malloc 
attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=23383

   What|Removed |Added

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

[Bug c++/23383] builtin array operator new is not marked with malloc attribute

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #30 from Eric Gallager  ---
(In reply to Jason Merrill from comment #29)
> Fixed for GCC 10.

I'm closing as such then (since I don't see any mentions of backports needed)

[Bug analyzer/93367] FAIL: gcc.dg/analyzer/abort.c (test for warnings, line 71)

[dmalcolm at gcc dot gnu.org]

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

--- Comment #1 from David Malcolm  ---
Thanks for filing this.

The failing test is a:

  __analyzer_eval (i < 10);

after a:

  assert (i < 10);

which expects TRUE, but is emitting UNKNOWN.

What's the definition of assert for this system?

The test is assuming that the assertion handler has __attribute__
((__noreturn__)), which I'm guessing isn't the case here.

I guess I could rewrite the test to use a custom assert macro, or skip the test
on certain targets, etc.

[Bug analyzer/93368] FAIL: gcc.dg/analyzer/data-model-1.c (test for excess errors)

[dmalcolm at gcc dot gnu.org]

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

--- Comment #2 from David Malcolm  ---
Thanks for filing this.  I think these are all dups of PR 93316, for which I'm
working on a fix.

[Bug analyzer/93288] ICE in supergraph.cc:180

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 Status|ASSIGNED|SUSPENDED
   Target Milestone|--- |11.0

--- Comment #3 from David Malcolm  ---
Marking status as SUSPENDED for now and setting Target Milestone to 11 (in the
hope of adding c++ support to the analyzer in gcc 11).

[Bug c++/92907] noexcept does not consider "const" in member functions

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #5 from Marek Polacek  ---
https://gcc.gnu.org/ml/gcc-patches/2020-01/msg01404.html

[Bug libstdc++/70129] [6 Regression] stdlib.h: No such file or directory when using -isystem /usr/include

[maxim.cournoyer at gmail dot com]

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

--- Comment #11 from Maxim Cournoyer  ---
(In reply to Jonathan Wakely from comment #10)
> (In reply to Maxim Cournoyer from comment #9)
> > About not using it: sure, this works, but now how can a project enable
> > warnings just for their own headers and not those of the whole system?  This
> > seems to be a valid use case.
> 
> This works, but is tedious to do for every warning:
> 
> #pragma GCC diagnostic push
> #pragma GCC diagnostic ignored "-Wdeprecated-declarations"
> #pragma GCC diagnostic ignored "-Wunused-local-typedefs"
> #include 
> #pragma GCC diagnostic pop

Thanks for the trick.  Agreed that it is tedious, but still good to know. 
About my previous comment saying that the workaround of not including any GCC
standard include directory in -isystem (or CPLUS_INCLUDE_PATH), the problem was
that I had set CPLUS_INCLUDE_PATH but not C_INCLUDE_PATH, and Inkscape goes on
to build bundled libraries which are C, not C++.  Hence, the Linux kernel
headers really were not present in any include search path for a C program. 
Apologies for the noise.

[Bug c++/40752] -Wconversion generates false warnings for operands not larger than target type

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #33 from Jason Merrill  ---
Fixed for GCC 10.

[Bug c++/93345] [10 Regression] ICE in nothrow_spec_p, at cp/except.c:1247

[raj.khem at gmail dot com]

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

Khem Raj  changed:

   What|Removed |Added

 CC||raj.khem at gmail dot com

--- Comment #2 from Khem Raj  ---
I started to seeing this as well when building geany on arm

[Bug target/93119] [ICE] The traditional TLS support of aarch64-ilp32 target may be not perfect while enable fPIC

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #11 from Andrew Pinski  ---
Fixed.

[Bug target/93119] [ICE] The traditional TLS support of aarch64-ilp32 target may be not perfect while enable fPIC

[cvs-commit at gcc dot gnu.org]

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

--- Comment #10 from CVS Commits  ---
The master branch has been updated by Andrew Pinski :

https://gcc.gnu.org/g:87ca615aa6f400c64d0bf13088c0ffdd14e22830

commit r10-6130-g87ca615aa6f400c64d0bf13088c0ffdd14e22830
Author: Andrew Pinski 
Date:   Fri Jan 17 06:54:53 2020 +

Fix target/93119 (aarch64): ICE with traditional TLS support on ILP32

The problem here was g:23b88fda665d2f995c was not a complete fix
for supporting tranditional TLS on ILP32.

So the problem here is a couple of things, first __tls_get_addr
call will return a C pointer value so we need to use ptr_mode
when we are creating the call.  Then we need to convert
back that register to the correct mode, either zero extending
it or just creating a move instruction.
Also symbol_ref can either be in SImode or DImode.  So we need to
allow both modes.

Built and tested on aarch64-linux-gnu with no regressions.
Also built a full toolchain (including glibc) defaulting to traditional
TLS that targets ilp32 and lp64.

ChangeLog:
PR target/93119
* config/aarch64/aarch64.md (tlsgd_small_): Have operand 0
as PTR mode. Have operand 1 as being modeless, it can be P mode.
(*tlsgd_small_): Likewise.
* config/aarch64/aarch64.c (aarch64_load_symref_appropriately)
: Call gen_tlsgd_small_* with a ptr_mode
register.  Convert that register back to dest using convert_mode.

[Bug c/93348] [8/9/10 Regression] ICE in gimplify_expr, at gimplify.c:14378

[cvs-commit at gcc dot gnu.org]

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Joseph Myers :

https://gcc.gnu.org/g:ac68e287fc2e939ae6b45ba7ff04e493982b7f62

commit r10-6129-gac68e287fc2e939ae6b45ba7ff04e493982b7f62
Author: Joseph Myers 
Date:   Wed Jan 22 01:23:42 2020 +

Fix ICE with cast of division by zero (PR c/93348).

Bug 93348 reports an ICE on certain cases of casts of expressions that
may appear only in unevaluated parts of integer constant expressions,
arising from the generation of nested C_MAYBE_CONST_EXPRs.  This patch
fixes it by adding a call to remove_c_maybe_const_expr in the
integer-operands case, as is done in other similar cases.

Bootstrapped with no regressions for x86_64-pc-linux-gnu.

PR c/93348
gcc/c:
* c-typeck.c (build_c_cast): Call remove_c_maybe_const_expr on
argument with integer operands.

gcc/testsuite:
* gcc.c-torture/compile/pr93348-1.c: New test.

[Bug driver/93371] New: -ffile-prefix-map ignored with assembly files

[comexk at gmail dot com]

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

Bug ID: 93371
   Summary: -ffile-prefix-map ignored with assembly files
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: driver
  Assignee: unassigned at gcc dot gnu.org
  Reporter: comexk at gmail dot com
  Target Milestone: ---

When using the GCC frontend to invoke GNU as, GCC passes through
-fdebug-prefix-map (as --debug-prefix-map), but ignores -ffile-prefix-map. 
-ffile-prefix-map is supposed to be "equivalent to specifying all the
individual -f*-prefix-map options."

Most likely, GCC should be changed to pass --debug-prefix-map to as when the
driver is passed -ffile-prefix-map (specifically in the definition of ASM_MAP
in gcc/gcc.c).  An alternative might be to add a --file-prefix-map option to
GNU as and pass that instead; however, the only other type of prefix map is
-fmacro-prefix-map, and that doesn't apply to raw as.

[Bug fortran/93365] ICE in match_data_constant, at fortran/decl.c:426

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-01-22
 CC||kargl at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from kargl at gcc dot gnu.org ---
This stops the ICE, but does not fix  mishandling of
of the kind inquiry.  Watch copy-n-paster whitespace
issues.

Index: /usr/home/sgk/gcc/gccx/gcc/fortran/decl.c
===
--- /usr/home/sgk/gcc/gccx/gcc/fortran/decl.c   (revision 280157)
+++ /usr/home/sgk/gcc/gccx/gcc/fortran/decl.c   (working copy)
@@ -423,7 +423,8 @@ match_data_constant (gfc_expr **result)
 data-pointer-initialization compatible (7.5.4.6) with the initial
 data target; the data statement object is initially associated
 with the target.  */
-  if ((*result)->symtree->n.sym->attr.save
+  if ((*result)->symtree != NULL
+ && (*result)->symtree->n.sym->attr.save
  && (*result)->symtree->n.sym->attr.target)
return m;
   gfc_free_expr (*result);

[Bug target/93370] New: Aarch64 accepts but ignores target("+sm4") unless ARMv8.2-A is enabled

[lloyd at randombit dot net]

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

Bug ID: 93370
   Summary: Aarch64 accepts but ignores target("+sm4") unless
ARMv8.2-A is enabled
   Product: gcc
   Version: 9.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lloyd at randombit dot net
  Target Milestone: ---

Aarch64 8.2-A has an optional extension for SM4. This is a Chinese
cryptographic algorithm analogous to AES. GCC supports these via intrinsic.

The confusion came about because GCC accepts `__attribute__((target("+sm4")))`
but unless ARMv8.2-A is also enabled (eg via -march=armv8.2-a command line
flag) then it complains about a target specific option mismatch, which is the
usual error when trying to use an intrinsic for an extension that is not
enabled when compiling that function or file. In contrast if you pass something
GCC doesn't know about to target() then it errors with a clear message "pragma
or attribute 'target("+foo")' is not valid".

Example:

$ aarch64-linux-gnu-gcc -v   
Using built-in specs.
COLLECT_GCC=aarch64-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/aarch64-linux-gnu/9.2.0/lto-wrapper
Target: aarch64-linux-gnu
Configured with: /build/aarch64-linux-gnu-gcc/src/gcc-9.2.0/configure
--prefix=/usr --program-prefix=aarch64-linux-gnu-
--with-local-prefix=/usr/aarch64-linux-gnu
--with-sysroot=/usr/aarch64-linux-gnu
--with-build-sysroot=/usr/aarch64-linux-gnu
--with-native-system-header-dir=/include --libdir=/usr/lib
--libexecdir=/usr/lib --target=aarch64-linux-gnu --host=x86_64-pc-linux-gnu
--build=x86_64-pc-linux-gnu --disable-nls --enable-languages=c,c++,fortran
--enable-shared --enable-threads=posix --with-system-zlib --with-isl
--enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu
--disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object
--enable-linker-build-id --enable-lto --enable-plugin
--enable-install-libiberty --with-linker-hash-style=gnu
--enable-gnu-indirect-function --disable-multilib --disable-werror
--enable-checking=release
Thread model: posix
gcc version 9.2.0 (GCC)
$ cat sm4.c
#include 

#if WORKS
 #define TARGET "arch=armv8.2-a+sm4"
#else
 #define TARGET "+sm4"
#endif

void __attribute__((target(TARGET))) enc(uint32_t b[4])
   {
   uint32x4_t B = vld1q_u32(b);
   vsm4eq_u32(B, B); // from SM4 extension
   vst1q_u32(b, B);
   }
$ aarch64-linux-gnu-gcc -DWORKS=1 -Wall -Wextra -c sm4.c -o sm4.o
$ aarch64-linux-gnu-gcc -DWORKS=0 -march=armv8.2-a -Wall -Wextra -c sm4.c -o
sm4.o
$ aarch64-linux-gnu-gcc -DWORKS=0 -Wall -Wextra -c sm4.c -o sm4.o   
In file included from sm4.c:1:
/usr/lib/gcc/aarch64-linux-gnu/9.2.0/include/arm_neon.h: In function 'void
enc(uint32_t*)':
/usr/lib/gcc/aarch64-linux-gnu/9.2.0/include/arm_neon.h:33125:1: error:
inlining failed in call to always_inline 'uint32x4_t vsm4eq_u32(uint32x4_t,
uint32x4_t)': target specific option mismatch
33125 | vsm4eq_u32 (uint32x4_t __a, uint32x4_t __b)
  | ^~
sm4.c:12:14: note: called from here
   12 |vsm4eq_u32(B, B);
  |~~^~
In file included from sm4.c:1:
/usr/lib/gcc/aarch64-linux-gnu/9.2.0/include/arm_neon.h:33125:1: error:
inlining failed in call to always_inline 'uint32x4_t vsm4eq_u32(uint32x4_t,
uint32x4_t)': target specific option mismatch
33125 | vsm4eq_u32 (uint32x4_t __a, uint32x4_t __b)
  | ^~
sm4.c:12:14: note: called from here
   12 |vsm4eq_u32(B, B);
  |~~^~

This is not a huge bug but it would be nice if GCC gave a more obvious error to
hint at the problem, since it accepts +sm4 but does not actually respect it
unless ARMv8.2-A is separately enabled. I imagine this situation holds true for
some of the other Aarch64 extensions but have not checked this.

[Bug middle-end/82407] [meta-bug] qsort_chk fallout tracking

[dmalcolm at gcc dot gnu.org]

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

Bug 93352 Summary: ICE: qsort checking failed (error: qsort comparator not 
anti-symmetric: -2147483648, -2147483648)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93352

   What|Removed |Added

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

[Bug analyzer/93352] ICE: qsort checking failed (error: qsort comparator not anti-symmetric: -2147483648, -2147483648)

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #2 from David Malcolm  ---
Should be fixed by above commit.

[Bug analyzer/93352] ICE: qsort checking failed (error: qsort comparator not anti-symmetric: -2147483648, -2147483648)

[cvs-commit at gcc dot gnu.org]

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by David Malcolm :

https://gcc.gnu.org/g:4f01e5778689977c9569477947b8062d8d87

commit r10-6127-g4f01e5778689977c9569477947b8062d8d87
Author: David Malcolm 
Date:   Tue Jan 21 12:42:36 2020 -0500

analyzer: fix qsort issue with array_region keys (PR 93352)

PR analyzer/93352 reports a qsort failure
  "comparator not anti-symmetric: -2147483648, -2147483648)"
within the analyzer on code involving an array access of [0x7fff + 1].

The issue is that array_region (which uses int for keys into known
values in the array) uses subtraction to implement int_cmp for sorting
the keys, which isn't going to work for boundary values.

Potentially a wider type should be used, but for now this patch fixes
the ICE by using explicit comparisons rather than subtraction to
implement the qsort callback.

gcc/analyzer/ChangeLog:
PR analyzer/93352
* region-model.cc (int_cmp): Rename to...
(array_region::key_cmp): ...this, using key_t rather than int.
Rewrite in terms of comparisons rather than subtraction to
ensure qsort is anti-symmetric when handling extreme values.
(array_region::walk_for_canonicalization): Update for above
renaming.
* region-model.h (array_region::key_cmp): New decl.

gcc/testsuite/ChangeLog:
PR analyzer/93352
* gcc.dg/analyzer/pr93352.c: New test.

[Bug c++/40752] -Wconversion generates false warnings for operands not larger than target type

[cvs-commit at gcc dot gnu.org]

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

--- Comment #32 from CVS Commits  ---
The master branch has been updated by Jason Merrill :

https://gcc.gnu.org/g:c77074d05691053ee7347d9e44ab89b3adb23fb1

commit r10-6126-gc77074d05691053ee7347d9e44ab89b3adb23fb1
Author: Jason Merrill 
Date:   Tue Jan 7 12:20:26 2020 -0500

PR c++/40752 - useless -Wconversion with short +=.

This is a longstanding issue with lots of duplicates; people are not
interested in a -Wconversion warning about mychar += 1.  So now that
warning
depends on -Warith-conversion; otherwise we only warn if operands of the
arithmetic have conversion issues.

* c.opt (-Warith-conversion): New.
* c-warn.c (conversion_warning): Recurse for operands of
operators.  Only warn about the whole expression with
-Warith-conversion.

[Bug fortran/93234] INQUIRE on pre-assigned files of ROUND and SIGN properties fails

[cvs-commit at gcc dot gnu.org]

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

--- Comment #6 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Jerry DeLisle
:

https://gcc.gnu.org/g:ae403e0d4e06656159387e6cacbe545f1c368eda

commit r9-8152-gae403e0d4e06656159387e6cacbe545f1c368eda
Author: Jerry DeLisle 
Date:   Tue Jan 21 15:35:42 2020 -0800

Bug 93234 - INQUIRE on pre-assigned files of ROUND and SIGN properties
fails

2020-01-21  Jerry DeLisle  

Backport from mainline
PR libfortran/93234
* io/unit.c (set_internal_unit): Set round and sign flags
correctly.

* gfortran.dg/inquire_pre.f90: New test.

[Bug analyzer/93350] ICE in make_region_for_type, at analyzer/region-model.cc:5975, or in get_lvalue_1, at analyzer/region-model.cc:4609

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
Looks like make_region_for_type does not support VECTOR_TYPE at all.

[Bug target/93304] RISC-V: Function with interrupt attribute use register without save/restore at prologue/epilogue

[wilson at gcc dot gnu.org]

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

Jim Wilson  changed:

   What|Removed |Added

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

--- Comment #4 from Jim Wilson  ---
Fixed on mainline.

[Bug target/93333] ICE: RTL check: expected code 'const_int', have 'and' in riscv_rtx_costs, at config/riscv/riscv.c:1645

[wilson at gcc dot gnu.org]

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

Jim Wilson  changed:

   What|Removed |Added

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

--- Comment #7 from Jim Wilson  ---
Fixed on mainline.

[Bug target/13515] `asm' operand requires impossible reload

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #4 from John Paul Adrian Glaubitz  ---
(In reply to Jason Duerstock from comment #3)
> For giggles, I just tried the test case on ia64, and it compiled
> successfully with GCC 7.2.

On the other hand, the issues occurs when building cgal on ia64:

/<>/include/CGAL/FPU.h:198:32: error: ‘asm’ operand requires
impossible reload
  198 |   asm volatile ("" : "+gf"(x) );
  |^

Full log:
https://buildd.debian.org/status/fetch.php?pkg=cgal=ia64=5.0-5=1575734711=0

cgal has the following defined for ia64:

# elif defined __ia64
  // Itanium
  asm volatile ("" : "+gf"(x) );
# else

From: https://sources.debian.org/src/cgal/5.0-5/include/CGAL/FPU.h/#L198

[Bug target/93319] -mtls-dialect=gnu2 doesn't work for x32

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #5 from H.J. Lu  ---
Fixed for GCC 10.

[Bug target/93319] -mtls-dialect=gnu2 doesn't work for x32

[cvs-commit at gcc dot gnu.org]

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by H.J. Lu :

https://gcc.gnu.org/g:8e0efc10335bf9bb447f2188254609dcfad7de8a

commit r10-6122-g8e0efc10335bf9bb447f2188254609dcfad7de8a
Author: H.J. Lu 
Date:   Tue Jan 21 14:09:53 2020 -0800

i386: Do GNU2 TLS address computation in ptr_mode

Since GNU2 TLS address from glibc run-time is in ptr_mode, we should do
GNU2 TLS address computation in ptr_mode and zero-extend result to Pmode.

gcc/

PR target/93319
* config/i386/i386.c (ix86_tls_module_base): Replace Pmode
with ptr_mode.
(legitimize_tls_address): Do GNU2 TLS address computation in
ptr_mode and zero-extend result to Pmode.
*  config/i386/i386.md (@tls_dynamic_gnu2_64_): Replace
:P with :PTR and Pmode with ptr_mode.
(*tls_dynamic_gnu2_lea_64_): Likewise.
(*tls_dynamic_gnu2_call_64_): Likewise.
(*tls_dynamic_gnu2_combine_64_): Likewise.

gcc/testsuite/

PR target/93319
* gcc.target/i386/pr93319-1a.c: Don't include .
(test1): Replace printf with __builtin_printf.

[Bug other/93369] New: [10 regression] g++.dg/lto/pr64076 fails

[seurer at gcc dot gnu.org]

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

Bug ID: 93369
   Summary: [10 regression] g++.dg/lto/pr64076 fails
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

THIS STARTED WITH COMMIT 28307164dfed294855bf3d55bed357de560f083b

spawn -ignore SIGHUP
/home/seurer/gcc/git/build/gcc-trunk/gcc/testsuite/g++1/../../xg++
-B/home/seurer/gcc/git/build/gcc-trunk/gcc/testsuite/g++1/../../
cp_lto_pr64076_0.o cp_lto_pr64076_1.o -fno-diagnostics-show-caret
-fno-diagnostics-show-line-numbers -fdiagnostics-color=never
-fdiagnostics-urls=never -nostdinc++
-I/home/seurer/gcc/git/build/gcc-trunk/powerpc64-unknown-linux-gnu/libstdc++-v3/include/powerpc64-unknown-linux-gnu
-I/home/seurer/gcc/git/build/gcc-trunk/powerpc64-unknown-linux-gnu/libstdc++-v3/include
-I/home/seurer/gcc/git/gcc-trunk/libstdc++-v3/libsupc++
-I/home/seurer/gcc/git/gcc-trunk/libstdc++-v3/include/backward
-I/home/seurer/gcc/git/gcc-trunk/libstdc++-v3/testsuite/util -fmessage-length=0
-O0 -flto -flto-partition=none -fuse-linker-plugin
-L/home/seurer/gcc/git/build/gcc-trunk/powerpc64-unknown-linux-gnu/./libstdc++-v3/src/.libs
-B/home/seurer/gcc/git/build/gcc-trunk/powerpc64-unknown-linux-gnu/./libstdc++-v3/src/.libs
-L/home/seurer/gcc/git/build/gcc-trunk/powerpc64-unknown-linux-gnu/./libstdc++-v3/src/.libs
-B/home/seurer/gcc/git/build/gcc-trunk/powerpc64-unknown-linux-gnu/./libitm/
-L/home/seurer/gcc/git/build/gcc-trunk/powerpc64-unknown-linux-gnu/./libitm/.libs
-o g++-dg-lto-pr64076-01.exe
g++-dg-lto-pr64076-01.exe.lto.o:(.rodata+0x58): undefined reference to
`non-virtual thunk to S::f()'
collect2: error: ld returned 1 exit status
compiler exited with status 1
FAIL: g++.dg/lto/pr64076 cp_lto_pr64076_0.o-cp_lto_pr64076_1.o link, -O0 -flto
-flto-partition=none -fuse-linker-plugin

[Bug c++/60855] ICE provoked by a lambda using the sizeof a captured VLA

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #5 from Jason Merrill  ---
Fixed for GCC 10.

[Bug c++/16994] [meta-bug] VLA and C++

[jason at gcc dot gnu.org]

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

Bug 60855 Summary: ICE provoked by a lambda using the sizeof a captured VLA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60855

   What|Removed |Added

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

[Bug c++/90732] [9 Regression] ICE with std::apply after variable length array

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

  Known to work||10.0
Summary|[9/10 Regression] ICE with  |[9 Regression] ICE with
   |std::apply after variable   |std::apply after variable
   |length array|length array
  Known to fail|10.0|

--- Comment #7 from Jason Merrill  ---
Fixed on trunk so far.  Is this important to fix in GCC 9?

[Bug c++/60855] ICE provoked by a lambda using the sizeof a captured VLA

[cvs-commit at gcc dot gnu.org]

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Jason Merrill :

https://gcc.gnu.org/g:ad09440a09597c34e0b93498aad9d6ef0b8ca9ae

commit r10-6121-gad09440a09597c34e0b93498aad9d6ef0b8ca9ae
Author: Jason Merrill 
Date:   Tue Jan 21 14:21:49 2020 -0500

PR c++/60855 - ICE with sizeof VLA capture.

For normal captures we usually look through them within unevaluated
context,
but that doesn't work here; trying to take the sizeof of the array in the
enclosing scope tries and fails to evaluate a SAVE_EXPR from the enclosing
scope.

* lambda.c (is_lambda_ignored_entity): Don't look past VLA capture.

[Bug c++/90732] [9/10 Regression] ICE with std::apply after variable length array

[cvs-commit at gcc dot gnu.org]

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

--- Comment #6 from CVS Commits  ---
The master branch has been updated by Jason Merrill :

https://gcc.gnu.org/g:276265195a4e7362b34ac512f3bc0ad5a974dcff

commit r10-6120-g276265195a4e7362b34ac512f3bc0ad5a974dcff
Author: Jason Merrill 
Date:   Tue Jan 21 13:22:35 2020 -0500

PR c++/90732 - ICE with VLA capture and generic lambda.

We were failing to handle VLA capture in tsubst_lambda_expr; initially
building a DECLTYPE_TYPE for the capture and then tsubsting it doesn't give
the special VLA handling.  So with this patch we call add_capture again for
VLAs.

* pt.c (tsubst_lambda_expr): Repeat add_capture for VLAs.

[Bug c++/92907] noexcept does not consider "const" in member functions

[mpolacek at gcc dot gnu.org]

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

--- Comment #4 from Marek Polacek  ---
I think I see the problem -- in cp_parser_noexcept_specification_opt we inject
'this', but always without any qualifiers:
25737   if (current_class_type)
25738 inject_this_parameter (current_class_type, TYPE_UNQUALIFIED);
so I think we need to pass the constness of the function here, then this ought
to work as expected.

[Bug c++/60855] ICE provoked by a lambda using the sizeof a captured VLA

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug target/93333] ICE: RTL check: expected code 'const_int', have 'and' in riscv_rtx_costs, at config/riscv/riscv.c:1645

[cvs-commit at gcc dot gnu.org]

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

--- Comment #6 from CVS Commits  ---
The master branch has been updated by Jakub Jelinek :

https://gcc.gnu.org/g:bd0a3e244d94ad4a5e41f01ebf285f0861cb4a03

commit r10-6118-gbd0a3e244d94ad4a5e41f01ebf285f0861cb4a03
Author: Jakub Jelinek 
Date:   Tue Jan 21 21:43:03 2020 +0100

riscv: Fix up riscv_rtx_costs for RTL checking (PR target/9)

As mentioned in the PR, during combine rtx_costs can be called sometimes
even on RTL that has not been validated yet and so can contain even
operands
that aren't valid in any instruction.

2020-01-21  Jakub Jelinek  

PR target/9
* config/riscv/riscv.c (riscv_rtx_costs) : Verify
the last two operands are CONST_INT_P before using them as such.

* gcc.c-torture/compile/pr9.c: New test.

[Bug target/93178] PPC: inefficient 64-bit constant generation if msb is off in low 16 bit

[segher at gcc dot gnu.org]

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

--- Comment #2 from Segher Boessenkool  ---
(In reply to Martin Liška from comment #1)
> @Segher: Can you please take a look?

Yes, tomorrow, when I am back from vacation :-)

Confirmed, btw.

[Bug c++/92721] ICE: canonical types differ for identical types 'int(void*, void*)' and 'int(void*, void*)'

[msebor at gcc dot gnu.org]

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

--- Comment #6 from Martin Sebor  ---
I suspect the ICE is caused by handle_access_attribute() modifying the
attributes of the passed-in function type.  This is done because the attribute
is internally represented in a condensed form to speed up processing.  I can't
think of a way to avoid it except to revert the internal representation to the
original (uncondensed) form.

[Bug target/93346] gcc does not generate BZHI

[pinskia at gcc dot gnu.org]

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

--- Comment #4 from Andrew Pinski  ---
(In reply to andi from comment #3)
> > The bzhi patterns all match some odd if_then_else only to guard against
> > inx & 255 == 0:
> 
> Is that guard needed? At least clang doesn't seem to care about it.

The guard is needed for the semantics of zero_extract yes, zero_extract with a
zero size is not well defined in GCC RTL.

We used to define it to be based on the what is expected below but see PR
65368.

[Bug target/93346] gcc does not generate BZHI

[andi at firstfloor dot org]

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

--- Comment #3 from andi at firstfloor dot org ---
> The bzhi patterns all match some odd if_then_else only to guard against
> inx & 255 == 0:

Is that guard needed? At least clang doesn't seem to care about it.

[Bug c/68687] C compiler options to ignore all const qualifiers

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
Also const & can bind to a rvalue.

I think you are misunderstanding why the const qualifier applies to types
rather than to the values.

[Bug fortran/93366] ICE: Invalid expression in gfc_element_size

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-01-21
 Ever confirmed|0   |1

[Bug tree-optimization/67413] Complex NOP expanded to several operations

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|rtl-optimization|tree-optimization

--- Comment #2 from Andrew Pinski  ---
At the tree level we get:
  _1 = REALPART_EXPR ;
  _2 = (unsigned int) _1;
  _3 = IMAGPART_EXPR ;
  _4 = (unsigned int) _3;
  _6 = COMPLEX_EXPR <_2, _4>;


But I suspect we could use VCE instead ...


> long f(long x){
>   long y = x >> 32;
>   y <<= 32;
>   int z = x;
>   return z | y;
> }

You have a sign extend in there.  That is the top bit of z (or the 32nd bit of
x) could done for the top 32bits of the return.  So this is not exactly the
same.
We do however optimize:
unsigned long f(unsigned long x){
  long y = x >> 32;
  y <<= 32;
  unsigned z = x;
  return z | y;
}

Now.

[Bug target/93335] [9/10 Regression] ICE: in extract_insn, at recog.c:2310 with __builtin_sub_overflow_p() on aarch64

[jakub at gcc dot gnu.org]

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

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 47690
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47690=edit
gcc10-pr93335.patch

Untested fix.

[Bug c++/16994] [meta-bug] VLA and C++

[jason at gcc dot gnu.org]

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

Bug 86432 Summary: ICE on capture VLA by reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86432

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

[Bug middle-end/60855] ICE provoked by a lambda using the sizeof a captured VLA

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 CC||tomilovanatoliy at yandex dot 
ru

--- Comment #3 from Jason Merrill  ---
*** Bug 86432 has been marked as a duplicate of this bug. ***

[Bug c++/86432] ICE on capture VLA by reference

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||jason at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #2 from Jason Merrill  ---
Yes, duplicate.

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

[Bug fortran/93366] ICE: Invalid expression in gfc_element_size

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4
 CC||kargl at gcc dot gnu.org

--- Comment #2 from kargl at gcc dot gnu.org ---
patch against last SVN revision.

Index: gcc/fortran/check.c
===
--- gcc/fortran/check.c (revision 280157)
+++ gcc/fortran/check.c (working copy)
@@ -1426,6 +1426,18 @@ gfc_check_x_yd (gfc_expr *x, gfc_expr *y)
   return true;
 }

+static bool
+invalid_null_arg (gfc_expr *x)
+{
+  if (x->expr_type == EXPR_NULL)
+{
+  gfc_error ("NULL pointer at %L is not permitted as actual argument "
+"of %qs intrinsic function", >where,
+gfc_current_intrinsic);
+  return true;
+}
+  return false;
+}

 bool
 gfc_check_associated (gfc_expr *pointer, gfc_expr *target)
@@ -1433,13 +1445,10 @@ gfc_check_associated (gfc_expr *pointer, gfc_expr *tar
   symbol_attribute attr1, attr2;
   int i;
   bool t;
-  locus *where;

-  where = >where;
+  if (invalid_null_arg (pointer))
+return false;

-  if (pointer->expr_type == EXPR_NULL)
-goto null_arg;
-
   attr1 = gfc_expr_attr (pointer);

   if (!attr1.pointer && !attr1.proc_pointer)
@@ -1463,9 +1472,8 @@ gfc_check_associated (gfc_expr *pointer, gfc_expr *tar
   if (target == NULL)
 return true;

-  where = >where;
-  if (target->expr_type == EXPR_NULL)
-goto null_arg;
+  if (invalid_null_arg (target))
+return false;

   if (target->expr_type == EXPR_VARIABLE || target->expr_type ==
EXPR_FUNCTION)
 attr2 = gfc_expr_attr (target);
@@ -1513,13 +1521,6 @@ gfc_check_associated (gfc_expr *pointer, gfc_expr *tar
  }
 }
   return t;
-
-null_arg:
-
-  gfc_error ("NULL pointer at %L is not permitted as actual argument "
-"of %qs intrinsic function", where, gfc_current_intrinsic);
-  return false;
-
 }


@@ -5124,6 +5125,9 @@ gfc_check_size (gfc_expr *array, gfc_expr *dim, gfc_ex
 bool
 gfc_check_sizeof (gfc_expr *arg)
 {
+  if (invalid_null_arg (arg))
+return false;
+
   if (arg->ts.type == BT_PROCEDURE)
 {
   gfc_error ("%qs argument of %qs intrinsic at %L shall not be a
procedure",
@@ -6139,6 +6143,9 @@ gfc_check_transfer (gfc_expr *source, gfc_expr *mold, 
   size_t source_size;
   size_t result_size;

+  if (invalid_null_arg (source))
+return false;
+
   /* SOURCE shall be a scalar or array of any type.  */
   if (source->ts.type == BT_PROCEDURE
   && source->symtree->n.sym->attr.subroutine == 1)
@@ -6153,6 +6160,9 @@ gfc_check_transfer (gfc_expr *source, gfc_expr *mold, 
 return false;

   if (mold->ts.type == BT_BOZ && illegal_boz_arg (mold))
+return false;
+
+  if (invalid_null_arg (mold))
 return false;

   /* MOLD shall be a scalar or array of any type.  */

[Bug lto/91627] FAIL: gcc.dg/lto/20081201-2 c_lto_20081201-2_0.o-c_lto_20081201-2_1.o execute -O3 -flto -flto-partition=1to1

[danglin at gcc dot gnu.org]

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

--- Comment #2 from John David Anglin  ---
As can be seen foo() is not inlined.

(gdb) disass 0x40002d34
Dump of assembler code for function foo:
   0x40002d30 <+0>: copy rp,ret0
   0x40002d34 <+4>: std rp,-10(sp)
   0x40002d38 <+8>: ldd -10(sp),rp
   0x40002d3c <+12>:bve,n (rp)
End of assembler dump.

Why is it okay to inline foo?

[Bug c/93357] Misleading diagnostic for complex type

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|Misleading diagnostic for   |Misleading diagnostic for
   |complex int |complex type

--- Comment #1 from Andrew Pinski  ---
I thought I had saw this bug report before but I cannot find it.
float has the same issue really.

[Bug c++/90732] [9/10 Regression] ICE with std::apply after variable length array

[jason at gcc dot gnu.org]

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

--- Comment #5 from Jason Merrill  ---
*** Bug 90740 has been marked as a duplicate of this bug. ***

[Bug c++/70555] lambda capture of multi-dimensional VLA

[jason at gcc dot gnu.org]

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

Bug 90740 Summary: [9/10 Regression] VLA with lamba causes an incorrect 
unitialized in this function warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90740

   What|Removed |Added

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

[Bug c/89448] Failure to generate diagnostic for "complex int" (OK for "_Complex int")

[Keith.S.Thompson at gmail dot com]

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

--- Comment #6 from Keith Thompson  ---
Since Bug 91980 has been closed as a duplicate of this one, I'll
mention explicitly that another symptom of the bug is that this:

#include 
complex x;
// _Complex y;

produces no diagnostic.

[Bug c++/90740] [9/10 Regression] VLA with lamba causes an incorrect unitialized in this function warning

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||jason at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #6 from Jason Merrill  ---
Same as 90732.

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

[Bug c++/16994] [meta-bug] VLA and C++

[jason at gcc dot gnu.org]

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

Bug 90740 Summary: [9/10 Regression] VLA with lamba causes an incorrect 
unitialized in this function warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90740

   What|Removed |Added

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

[Bug c/89448] Failure to generate diagnostic for "complex int" (OK for "_Complex int")

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||Keith.S.Thompson at gmail dot 
com

--- Comment #5 from Andrew Pinski  ---
*** Bug 91980 has been marked as a duplicate of this bug. ***

[Bug c/91980] No diagnostic for type "complex"

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #4 from Andrew Pinski  ---
Dup of bug 89448.

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

[Bug analyzer/93316] Several gcc.dg/analyzer tests FAIL

[danglin at gcc dot gnu.org]

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

John David Anglin  changed:

   What|Removed |Added

 CC||danglin at gcc dot gnu.org

--- Comment #2 from John David Anglin  ---
Seeing these on hppa64-*-hpux* as well.

[Bug analyzer/93368] FAIL: gcc.dg/analyzer/data-model-1.c (test for excess errors)

[danglin at gcc dot gnu.org]

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

--- Comment #1 from John David Anglin  ---
Similar fails:

FAIL: gcc.dg/analyzer/malloc-1.c (test for excess errors)
Excess errors:
/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/analyzer/malloc-1.c:274:15: warning:
implicit declaration of function 'alloca' [-Wimplicit-function-declaration]
/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/analyzer/malloc-1.c:274:15: warning:
incompatible implicit declaration of built-in function 'alloca'

spawn /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/
/test/gnu/gcc/gc
c/gcc/testsuite/gcc.dg/analyzer/malloc-callbacks.c -fno-diagnostics-show-caret
-
fno-diagnostics-show-line-numbers -fdiagnostics-color=never
-fdiagnostics-urls=n
ever -fanalyzer -fdiagnostics-path-format=separate-events
-Wanalyzer-too-complex
 -fanalyzer-call-summaries -S -o malloc-callbacks.s
/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/analyzer/malloc-callbacks.c: In function
'get_alloca':
/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/analyzer/malloc-callbacks.c:15:10:
error:
 'alloca' undeclared (first use in this function); did you mean 'valloc'?
/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/analyzer/malloc-callbacks.c:15:10: note:
each undeclared identifier is reported only once for each function it appears
in
compiler exited with status 1
output is:
/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/analyzer/malloc-callbacks.c: In function
'get_alloca':
/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/analyzer/malloc-callbacks.c:15:10:
error:
 'alloca' undeclared (first use in this function); did you mean 'valloc'?
/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/analyzer/malloc-callbacks.c:15:10: note:
each undeclared identifier is reported only once for each function it appears
in

FAIL: gcc.dg/analyzer/malloc-callbacks.c  (test for warnings, line 27)
FAIL: gcc.dg/analyzer/malloc-callbacks.c  (test for warnings, line 28)
FAIL: gcc.dg/analyzer/malloc-callbacks.c  (test for warnings, line 34)
FAIL: gcc.dg/analyzer/malloc-callbacks.c  (test for warnings, line 35)
FAIL: gcc.dg/analyzer/malloc-callbacks.c  (test for warnings, line 41)
FAIL: gcc.dg/analyzer/malloc-callbacks.c  (test for warnings, line 53)
FAIL: gcc.dg/analyzer/malloc-callbacks.c  (test for warnings, line 54)
FAIL: gcc.dg/analyzer/malloc-callbacks.c  (test for warnings, line 62)
FAIL: gcc.dg/analyzer/malloc-callbacks.c  (test for warnings, line 64)
XFAIL: gcc.dg/analyzer/malloc-callbacks.c  (test for warnings, line 70)
FAIL: gcc.dg/analyzer/malloc-callbacks.c (test for excess errors)
Excess errors:
/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/analyzer/malloc-callbacks.c:15:10:
error: 'alloca' undeclared (first use in this function); did you mean 'valloc'?

FAIL: gcc.dg/analyzer/malloc-paths-8.c (test for excess errors)
Excess errors:
/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/analyzer/malloc-paths-8.c:16:11:
warning: implicit declaration of function 'alloca'
[-Wimplicit-function-declaration]
/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/analyzer/malloc-paths-8.c:16:11:
warning: incompatible implicit declaration of built-in function 'alloca'
/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/analyzer/malloc-paths-8.c:28:11:
warning: incompatible implicit declaration of built-in function 'alloca'
/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/analyzer/malloc-paths-8.c:42:11:
warning: incompatible implicit declaration of built-in function 'alloca'

[Bug lto/93358] [10 Regression] 447.dealII regresses by 15% after r10-6025-gf5b25e15165adde1356af42e9066ab75c5b37a19

[tnfchris at gcc dot gnu.org]

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

Tamar Christina  changed:

   What|Removed |Added

 CC||tnfchris at gcc dot gnu.org

--- Comment #1 from Tamar Christina  ---
This also caused a regression in perlbench, at least on AArch64 it seems to
have made the compiler a lot more sensitive to alignment.

[Bug analyzer/93368] New: FAIL: gcc.dg/analyzer/data-model-1.c (test for excess errors)

[danglin at gcc dot gnu.org]

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

Bug ID: 93368
   Summary: FAIL: gcc.dg/analyzer/data-model-1.c (test for excess
errors)
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: danglin at gcc dot gnu.org
  Target Milestone: ---
  Host: hppa64-hp-hpux11.11
Target: hppa64-hp-hpux11.11
 Build: hppa64-hp-hpux11.11

Executing on host: /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/
/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/analyzer/data-model-1.c 
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never  -fdiagnostics-urls=never   -fanalyzer
-fdiagnostics-path-format=separate-events -Wanalyzer-too-complex
-fanalyzer-call-summaries -S   -o data-model-1.s(timeout = 300)
spawn /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/
/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/analyzer/data-model-1.c
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never -fdiagnostics-urls=never -fanalyzer
-fdiagnostics-path-format=separate-events -Wanalyzer-too-complex
-fanalyzer-call-summaries -S -o data-model-1.s
/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/analyzer/data-model-1.c: In function
'test_12':
/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/analyzer/data-model-1.c:140:13: warning:
implicit declaration of function 'alloca' [-Wimplicit-function-declaration]
/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/analyzer/data-model-1.c:140:13: warning:
incompatible implicit declaration of built-in function 'alloca'

FAIL: gcc.dg/analyzer/data-model-1.c  (test for warnings, line 144)
FAIL: gcc.dg/analyzer/data-model-1.c (test for excess errors)
Excess errors:
/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/analyzer/data-model-1.c:140:13: warning:
implicit declaration of function 'alloca' [-Wimplicit-function-declaration]
/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/analyzer/data-model-1.c:140:13: warning:
incompatible implicit declaration of built-in function 'alloca'
/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/analyzer/data-model-1.c:144:3: warning:
UNKNOWN

[Bug analyzer/93367] New: FAIL: gcc.dg/analyzer/abort.c (test for warnings, line 71)

[danglin at gcc dot gnu.org]

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

Bug ID: 93367
   Summary: FAIL: gcc.dg/analyzer/abort.c  (test for warnings,
line 71)
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: danglin at gcc dot gnu.org
  Target Milestone: ---
  Host: hppa64-hp-hpux11.11
Target: hppa64-hp-hpux11.11
 Build: hppa64-hp-hpux11.11

spawn /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/
/test/gnu/gcc/gc
c/gcc/testsuite/gcc.dg/analyzer/abort.c -fno-diagnostics-show-caret
-fno-diagnos
tics-show-line-numbers -fdiagnostics-color=never -fdiagnostics-urls=never
-fanal
yzer -fdiagnostics-path-format=separate-events -Wanalyzer-too-complex
-fanalyzer
-call-summaries -S -o abort.s
/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/analyzer/abort.c: In function 'test_1':
/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/analyzer/abort.c:14:3: warning: TRUE
/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/analyzer/abort.c: In function 'test_2':
/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/analyzer/abort.c:31:3: warning: TRUE
/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/analyzer/abort.c: In function 'test_3':
/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/analyzer/abort.c:47:3: warning: TRUE
/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/analyzer/abort.c: In function 'test_4':
/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/analyzer/abort.c:60:3: warning: TRUE
/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/analyzer/abort.c: In function 'test_5':
/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/analyzer/abort.c:71:3: warning: UNKNOWN
output is:
/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/analyzer/abort.c: In function 'test_1':
/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/analyzer/abort.c:14:3: warning: TRUE
/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/analyzer/abort.c: In function 'test_2':
/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/analyzer/abort.c:31:3: warning: TRUE
/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/analyzer/abort.c: In function 'test_3':
/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/analyzer/abort.c:47:3: warning: TRUE
/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/analyzer/abort.c: In function 'test_4':
/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/analyzer/abort.c:60:3: warning: TRUE
/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/analyzer/abort.c: In function 'test_5':
/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/analyzer/abort.c:71:3: warning: UNKNOWN

PASS: gcc.dg/analyzer/abort.c  (test for warnings, line 14)
PASS: gcc.dg/analyzer/abort.c  (test for warnings, line 31)
PASS: gcc.dg/analyzer/abort.c  (test for warnings, line 47)
PASS: gcc.dg/analyzer/abort.c  (test for warnings, line 60)
FAIL: gcc.dg/analyzer/abort.c  (test for warnings, line 71)
FAIL: gcc.dg/analyzer/abort.c (test for excess errors)
Excess errors:
/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/analyzer/abort.c:71:3: warning: UNKNOWN

[Bug fortran/93366] ICE: Invalid expression in gfc_element_size

[gs...@t-online.de]

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

G. Steinmetz  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code

--- Comment #1 from G. Steinmetz  ---


Similar :


$ cat z2.f90
program p
   print *, transfer(1, null())
   print *, transfer([1], null())
end


$ cat z3.f90
program p
   print *, transfer (null(), 1)
   print *, transfer (null(), [1])
end


$ cat z4.f90
program p
   print *, transfer(null(), null())
end


$ gfortran-10-20200119 -c z3.f90
f951: internal compiler error: Invalid expression in gfc_element_size.
0x647599 gfc_report_diagnostic
../../gcc/fortran/error.c:782
0x648cba gfc_internal_error(char const*, ...)
../../gcc/fortran/error.c:1402
0x6e4582 gfc_element_size(gfc_expr*, unsigned long*)
../../gcc/fortran/target-memory.c:137
0x6e45e3 gfc_target_expr_size(gfc_expr*, unsigned long*)
../../gcc/fortran/target-memory.c:166
0x623a6a gfc_calculate_transfer_sizes(gfc_expr*, gfc_expr*, gfc_expr*, unsigned
long*, unsigned long*, unsigned long*)
../../gcc/fortran/check.c:6083
0x6d971d gfc_simplify_transfer(gfc_expr*, gfc_expr*, gfc_expr*)
../../gcc/fortran/simplify.c:7926
0x65ca07 do_simplify
../../gcc/fortran/intrinsic.c:4617
0x66721a gfc_intrinsic_func_interface(gfc_expr*, int)
../../gcc/fortran/intrinsic.c:4996
0x6bea5e resolve_unknown_f
../../gcc/fortran/resolve.c:2894
0x6bea5e resolve_function
../../gcc/fortran/resolve.c:3238
0x6bea5e gfc_resolve_expr(gfc_expr*)
../../gcc/fortran/resolve.c:7000
0x6b5dec gfc_resolve_expr(gfc_expr*)
../../gcc/fortran/resolve.c:6967
0x6b5dec gfc_resolve_code(gfc_code*, gfc_namespace*)
../../gcc/fortran/resolve.c:11688
0x6c4cdf gfc_resolve_blocks(gfc_code*, gfc_namespace*)
../../gcc/fortran/resolve.c:10715
0x6b4b18 gfc_resolve_code(gfc_code*, gfc_namespace*)
../../gcc/fortran/resolve.c:11678
0x6b7397 resolve_codes
../../gcc/fortran/resolve.c:17205
0x6b745e gfc_resolve(gfc_namespace*)
../../gcc/fortran/resolve.c:17240
0x6a57bc resolve_all_program_units
../../gcc/fortran/parse.c:6241
0x6a57bc gfc_parse_file()
../../gcc/fortran/parse.c:6488
0x6f044f gfc_be_parse_file
../../gcc/fortran/f95-lang.c:210

[Bug fortran/93366] New: ICE: Invalid expression in gfc_element_size

[gs...@t-online.de]

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

Bug ID: 93366
   Summary: ICE: Invalid expression in gfc_element_size
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Affects gfortran down to at least r5; null() is not allowed here :


$ cat z1.f90
program p
   print *, sizeof(null())
end


$ gfortran-10-20200119 -c z1.f90
f951: internal compiler error: Invalid expression in gfc_element_size.
0x647599 gfc_report_diagnostic
../../gcc/fortran/error.c:782
0x648cba gfc_internal_error(char const*, ...)
../../gcc/fortran/error.c:1402
0x6e4582 gfc_element_size(gfc_expr*, unsigned long*)
../../gcc/fortran/target-memory.c:137
0x6e45e3 gfc_target_expr_size(gfc_expr*, unsigned long*)
../../gcc/fortran/target-memory.c:166
0x6d85ab gfc_simplify_sizeof(gfc_expr*)
../../gcc/fortran/simplify.c:7417
0x65c99f do_simplify
../../gcc/fortran/intrinsic.c:4603
0x66721a gfc_intrinsic_func_interface(gfc_expr*, int)
../../gcc/fortran/intrinsic.c:4996
0x6bea5e resolve_unknown_f
../../gcc/fortran/resolve.c:2894
0x6bea5e resolve_function
../../gcc/fortran/resolve.c:3238
0x6bea5e gfc_resolve_expr(gfc_expr*)
../../gcc/fortran/resolve.c:7000
0x6b5dec gfc_resolve_expr(gfc_expr*)
../../gcc/fortran/resolve.c:6967
0x6b5dec gfc_resolve_code(gfc_code*, gfc_namespace*)
../../gcc/fortran/resolve.c:11688
0x6c4cdf gfc_resolve_blocks(gfc_code*, gfc_namespace*)
../../gcc/fortran/resolve.c:10715
0x6b4b18 gfc_resolve_code(gfc_code*, gfc_namespace*)
../../gcc/fortran/resolve.c:11678
0x6b7397 resolve_codes
../../gcc/fortran/resolve.c:17205
0x6b745e gfc_resolve(gfc_namespace*)
../../gcc/fortran/resolve.c:17240
0x6a57bc resolve_all_program_units
../../gcc/fortran/parse.c:6241
0x6a57bc gfc_parse_file()
../../gcc/fortran/parse.c:6488
0x6f044f gfc_be_parse_file
../../gcc/fortran/f95-lang.c:210

[Bug fortran/93365] New: ICE in match_data_constant, at fortran/decl.c:426

[gs...@t-online.de]

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

Bug ID: 93365
   Summary: ICE in match_data_constant, at fortran/decl.c:426
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Follow-up of pr87994, changed between 20181028 and 20181104.
While z0 works, cases with a zero-sized array will not :


$ cat z0.f90
program p
   complex, parameter :: a(1) = 0
   integer :: b
   data b /a%kind/
   print *, b
end

$ gfortran-10-20200119 z0.f90 && ./a.out
   4


$ cat z1.f90
program p
   complex, parameter :: a(0) = 0
   integer :: b
   data b /a%kind/
end


$ cat z2.f90
program p
   character, parameter :: a(0) = '0'
   integer :: b
   data b /a%kind/
end


$ cat z3.f90
program p
   logical, parameter :: a(0) = .true.
   integer :: b
   data b /a%kind/
end


$ cat z4.f90
program p
   real, parameter :: a(0) = 0
   integer :: b
   data b /a%kind/
end


$ gfortran-10-20200119 -c z1.f90
f951: internal compiler error: Segmentation fault
0xbaaaff crash_signal
../../gcc/toplev.c:328
0x631d74 match_data_constant
../../gcc/fortran/decl.c:426
0x631f23 top_val_list
../../gcc/fortran/decl.c:499
0x632232 gfc_match_data()
../../gcc/fortran/decl.c:712
0x69ae71 match_word
../../gcc/fortran/parse.c:65
0x69eece decode_statement
../../gcc/fortran/parse.c:469
0x69fc3a next_free
../../gcc/fortran/parse.c:1279
0x69fc3a next_statement
../../gcc/fortran/parse.c:1511
0x6a128b parse_spec
../../gcc/fortran/parse.c:3922
0x6a405c parse_progunit
../../gcc/fortran/parse.c:5848
0x6a5739 gfc_parse_file()
../../gcc/fortran/parse.c:6388
0x6f044f gfc_be_parse_file
../../gcc/fortran/f95-lang.c:210

[Bug fortran/93364] New: [9/10 Regression] ICE in gfc_set_array_spec, at fortran/array.c:879

[gs...@t-online.de]

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

Bug ID: 93364
   Summary: [9/10 Regression] ICE in gfc_set_array_spec, at
fortran/array.c:879
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Follow-up of pr92897, the other way around.
Was also changed between 20190922 and 20190929 :


$ cat z1.f90
type(t) function f()
   codimension :: t[1,2,1,2,1,2,1,*]
   dimension :: t(1,2,1,2,1,2,1,2)
end


$ gfortran-10-20190922 -c z1.f90 -fcoarray=single
z1.f90:1:7:

1 | type(t) function f()
  |   1
Error: Derived type 't' at (1) has not been declared
z1.f90:1:18:

1 | type(t) function f()
  |  1
Error: The derived type 'f' at (1) is of type 't', which has not been defined


$ gfortran-10-20200119 -c z1.f90 -fcoarray=single
f951: internal compiler error: in gfc_set_array_spec, at fortran/array.c:879
0x617e8d gfc_set_array_spec(gfc_symbol*, gfc_array_spec*, locus*)
../../gcc/fortran/array.c:879
0x630d6b attr_decl1
../../gcc/fortran/decl.c:8554
0x630d6b attr_decl
../../gcc/fortran/decl.c:8606
0x69ae71 match_word
../../gcc/fortran/parse.c:65
0x69eeea decode_statement
../../gcc/fortran/parse.c:470
0x69fc3a next_free
../../gcc/fortran/parse.c:1279
0x69fc3a next_statement
../../gcc/fortran/parse.c:1511
0x6a136d parse_spec
../../gcc/fortran/parse.c:3938
0x6a405c parse_progunit
../../gcc/fortran/parse.c:5848
0x6a5a81 gfc_parse_file()
../../gcc/fortran/parse.c:6402
0x6f044f gfc_be_parse_file
../../gcc/fortran/f95-lang.c:210

[Bug fortran/93363] New: [10 Regression] ICE in gfc_get_class_from_expr, at fortran/trans-expr.c:484

[gs...@t-online.de]

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

Bug ID: 93363
   Summary: [10 Regression] ICE in gfc_get_class_from_expr, at
fortran/trans-expr.c:484
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

This changed between 20190922 and 20190929 :


$ cat z1.f90
program p
   if (f() /= 1) stop
   associate (y => f)
   end associate
contains
   integer function f()
  f = 1
   end
end


$ cat z2.f90
program p
   interface g
  procedure s
   end interface
   associate (y => g)
   end associate
contains
   subroutine s
   end
end


$ gfortran-10-20190922 -c z1.f90
$
$ gfortran-10-20200119 -c z1.f90
z1.f90:3:0:

3 |associate (y => f)
  |
internal compiler error: tree check: expected class 'expression', have
'declaration' (function_decl) in tree_operand_check, at tree.h:3776
0x611182 tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
../../gcc/tree.c:9735
0x76b189 expr_check(tree_node*, char const*, int, char const*)
../../gcc/tree.h:3447
0x76b189 tree_operand_check(tree_node*, int, char const*, int, char const*)
../../gcc/tree.h:3776
0x76b189 gfc_get_class_from_expr(tree_node*)
../../gcc/fortran/trans-expr.c:484
0x7c6ca2 trans_associate_var
../../gcc/fortran/trans-stmt.c:2100
0x7cd539 gfc_trans_block_construct(gfc_code*)
../../gcc/fortran/trans-stmt.c:2283
0x72f3f7 trans_code
../../gcc/fortran/trans.c:1960
0x76678d gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6823
0x6e0546 translate_all_program_units
../../gcc/fortran/parse.c:6302
0x6e0546 gfc_parse_file()
../../gcc/fortran/parse.c:6541
0x72b6ef gfc_be_parse_file
../../gcc/fortran/f95-lang.c:210

[Bug fortran/93363] [10 Regression] ICE in gfc_get_class_from_expr, at fortran/trans-expr.c:484

[gs...@t-online.de]

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

G. Steinmetz  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code

--- Comment #1 from G. Steinmetz  ---

A related case :


$ cat z3.f90
program p
   type t
  integer :: a
   end type
   type(t) :: z
   z = t(1)
   associate (y => t)
   end associate
end

[Bug c++/86761] Code corruption with missing pointer return

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||lucien.gentis at waika9 dot com

--- Comment #9 from Andrew Pinski  ---
*** Bug 91585 has been marked as a duplicate of this bug. ***

[Bug c++/86761] Code corruption with missing pointer return

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||matthijs at stdin dot nl

--- Comment #10 from Andrew Pinski  ---
*** Bug 93359 has been marked as a duplicate of this bug. ***

[Bug c++/91585] segfault when calling a non void function without a return statement

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|INVALID |DUPLICATE

--- Comment #4 from Andrew Pinski  ---


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

[Bug tree-optimization/93359] Miscompile (loop check omitted) in function with missing return statement

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #2 from Andrew Pinski  ---
https://gcc.gnu.org/gcc-8/porting_to.html
G++ now assumes that control never reaches the end of a non-void function (i.e.
without reaching a return statement). This means that you should always pay
attention to -Wreturn-type warnings, as they indicate code that can misbehave
when optimized.

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

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

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|INVALID |DUPLICATE

--- Comment #5 from Andrew Pinski  ---


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

[Bug c++/86761] Code corruption with missing pointer return

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||matszpk at interia dot pl

--- Comment #8 from Andrew Pinski  ---
*** Bug 90516 has been marked as a duplicate of this bug. ***

[Bug c++/90516] Strange behaviour of code if function no return value and code embraced by try..catch with opt flags

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|INVALID |DUPLICATE

--- Comment #2 from Andrew Pinski  ---


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

[Bug c++/86761] Code corruption with missing pointer return

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||volconscious at gmail dot com

--- Comment #7 from Andrew Pinski  ---
*** Bug 90349 has been marked as a duplicate of this bug. ***

[Bug lto/89884] g++.dg/lto/pr89335 FAILs

[danglin at gcc dot gnu.org]

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

John David Anglin  changed:

   What|Removed |Added

 Target|*-*-solaris2.*  |*-*-solaris2.*
   ||hppa64-*-hpux*
 CC||danglin at gcc dot gnu.org

--- Comment #4 from John David Anglin  ---
Also fails on hppa64-hp-hpux11.11.

[Bug lto/93362] New: FAIL: g++.dg/lto/pr70929 cp_lto_pr70929_0.o-cp_lto_pr70929_1.o execute -O3 -flto

[danglin at gcc dot gnu.org]

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

Bug ID: 93362
   Summary: FAIL: g++.dg/lto/pr70929
cp_lto_pr70929_0.o-cp_lto_pr70929_1.o execute -O3
-flto
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: danglin at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
  Target Milestone: ---
  Host: hppa64-hp-hpux11.11
Target: hppa64-hp-hpux11.11
 Build: hppa64-hp-hpux11.11

spawn /test/gnu/gcc/objdir/gcc/testsuite/g++/../../xg++
-B/test/gnu/gcc/objdir/g
cc/testsuite/g++/../../ cp_lto_pr70929_0.o cp_lto_pr70929_1.o
-fno-diagnostics-s
how-caret -fno-diagnostics-show-line-numbers -fdiagnostics-color=never
-fdiagnos
tics-urls=never -nostdinc++
-I/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++
-v3/include/hppa64-hp-hpux11.11
-I/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libst
dc++-v3/include -I/test/gnu/gcc/gcc/libstdc++-v3/libsupc++
-I/test/gnu/gcc/gcc/l
ibstdc++-v3/include/backward -I/test/gnu/gcc/gcc/libstdc++-v3/testsuite/util
-fm
essage-length=0 -O3 -flto
-L/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libstdc++
-v3/src/.libs
-B/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libstdc++-v3/src/.lib
s -L/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libstdc++-v3/src/.libs -o
g++-dg-
lto-pr70929-01.exe
PASS: g++.dg/lto/pr70929 cp_lto_pr70929_0.o-cp_lto_pr70929_1.o link, -O3 -flto
Setting LD_LIBRARY_PATH to
.:/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libstdc+
+-v3/src/.libs:/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libstdc++-v3/src/.libs
:/test/gnu/gcc/objdir/gcc/testsuite/g++/../..:.:/test/gnu/gcc/objdir/hppa64-hp-h
pux11.11/./libstdc++-v3/src/.libs:/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/./lib
stdc++-v3/src/.libs:/test/gnu/gcc/objdir/gcc/testsuite/g++/../..
spawn [open ...]
FAIL: g++.dg/lto/pr70929 cp_lto_pr70929_0.o-cp_lto_pr70929_1.o execute -O3
-flto

[Bug target/93270] [8/9/10 Regression] DSE removes store incorrectly

[matz at gcc dot gnu.org]

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

Michael Matz  changed:

   What|Removed |Added

 CC||matz at gcc dot gnu.org

--- Comment #5 from Michael Matz  ---
(In reply to Richard Biener from comment #2)
> And pasting from my ml analysis:
> 
> So clearly something is wrong:
> 
>   type  size 
> unit-size 
> align:128 warn_if_not_align:0 symtab:0 alias-set 2
> canonical-type 0x7682d3f0 precision:80
> pointer_to_this >
> 
> and thus GET_MODE_SIZE (XFmode) == 16.  The target cannot possibly
> just store 12 bytes here,
> it lies.  Why's XFmode not 12 bytes but with 8/16 byte alignment?
> Does the ABI say sizeof(long double) is 16?

Of course.  sizeof _must_ be a multiple of alignment, but it can contain
padding.  So the target is completely fine with stating that sizeof is 16,
but then only storing 12 bytes.  (That implies that there are 4 bytes of
padding).  The number of bits that are actually relevant for determining the
value of something is supposed to be in precision, though this use of precision
was never explicitly called out, so there might be cases where precision isn't
reliably usable for this purpose.

> That said, a mode-has-padding or whatever should be reflected in
> TYPE_SIZE & friends as well, inconsistencies
> there just make things worse.

No, I don't see any inconsistencies.

What of course needs to be said is that the original testcase simply is
invalid.  It stores .value and then reads from another union member, that's
not allowed.  (You can play these games if the other member would be a char
array, and GCC tries to allow you to do that also with other types, but as you
noticed this allowance has its limits).

So, I think, nothing needs fixing.  The quality of implementation could be
somewhat improved in one dimension by using precision instead of size, but
only at expense of lowering quality in another dimension (namely of not
removing
the memset).

[Bug lto/93361] New: FAIL: g++-dg-lto-devirt-19-01.exe 1 blank line(s) in output

[danglin at gcc dot gnu.org]

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

Bug ID: 93361
   Summary: FAIL: g++-dg-lto-devirt-19-01.exe 1 blank line(s) in
output
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: danglin at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
  Target Milestone: ---
  Host: hppa64-hp-hpux11.11
Target: hppa64-hp-hpux11.11
 Build: hppa64-hp-hpux11.11

spawn /test/gnu/gcc/objdir/gcc/testsuite/g++/../../xg++
-B/test/gnu/gcc/objdir/g
cc/testsuite/g++/../../ cp_lto_devirt-19_0.o -fno-diagnostics-show-caret
-fno-di
agnostics-show-line-numbers -fdiagnostics-color=never -fdiagnostics-urls=never
-
nostdinc++
-I/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/include/hppa6
4-hp-hpux11.11 -I/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/include
-
I/test/gnu/gcc/gcc/libstdc++-v3/libsupc++
-I/test/gnu/gcc/gcc/libstdc++-v3/inclu
de/backward -I/test/gnu/gcc/gcc/libstdc++-v3/testsuite/util -fmessage-length=0
-
O2 -fdump-ipa-cp -fipa-cp-clone -Wno-return-type -flto -r -nostdlib
-flinker-out
put=nolto-rel -flto=auto
-L/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libstdc++-
v3/src/.libs
-B/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libstdc++-v3/src/.libs
 -L/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libstdc++-v3/src/.libs -o
g++-dg-l
to-devirt-19-01.exe
make: the '-j' option requires a positive integer argument
Usage: make [options] [target] ...
Options:
  -b, -m  Ignored for compatibility.
  -B, --always-make   Unconditionally make all targets.
  -C DIRECTORY, --directory=DIRECTORY
  Change to DIRECTORY before doing anything.
  -d  Print lots of debugging information.
  --debug[=FLAGS] Print various types of debugging information.
  -e, --environment-overrides
  Environment variables override makefiles.
  --eval=STRING   Evaluate STRING as a makefile statement.
  -f FILE, --file=FILE, --makefile=FILE
  Read FILE as a makefile.
  -h, --help  Print this message and exit.
  -i, --ignore-errors Ignore errors from recipes.
  -I DIRECTORY, --include-dir=DIRECTORY
  Search DIRECTORY for included makefiles.
  -j [N], --jobs[=N]  Allow N jobs at once; infinite jobs with no arg.
  -k, --keep-goingKeep going when some targets can't be made.
  -l [N], --load-average[=N], --max-load[=N]
  Don't start multiple jobs unless load is below N.
  -L, --check-symlink-times   Use the latest mtime between symlinks and target.
  -n, --just-print, --dry-run, --recon
  Don't actually run any recipe; just print them.
  -o FILE, --old-file=FILE, --assume-old=FILE
  Consider FILE to be very old and don't remake it.
  -O[TYPE], --output-sync[=TYPE]
  Synchronize output of parallel jobs by TYPE.
  -p, --print-data-base   Print make's internal database.
  -q, --question  Run no recipe; exit status says if up to date.
  -r, --no-builtin-rules  Disable the built-in implicit rules.
  -R, --no-builtin-variables  Disable the built-in variable settings.
  -s, --silent, --quiet   Don't echo recipes.
  -S, --no-keep-going, --stop
  Turns off -k.
  -t, --touch Touch targets instead of remaking them.
  --trace Print tracing information.
  -v, --version   Print the version number of make and exit.
  -w, --print-directory   Print the current directory.
  --no-print-directoryTurn off -w, even if it was turned on implicitly.
  -W FILE, --what-if=FILE, --new-file=FILE, --assume-new=FILE
  Consider FILE to be infinitely new.
  --warn-undefined-variables  Warn when an undefined variable is referenced.

This program built for hppa64-hp-hpux11.11
Report bugs to 
lto-wrapper: fatal error: make returned 2 exit status
compilation terminated.
collect2: fatal error: lto-wrapper returned 1 exit status
compilation terminated.
compiler exited with status 1
output is:
make: the '-j' option requires a positive integer argument
Usage: make [options] [target] ...
Options:
  -b, -m  Ignored for compatibility.
  -B, --always-make   Unconditionally make all targets.
  -C DIRECTORY, --directory=DIRECTORY
  Change to DIRECTORY before doing anything.
  -d  Print lots of debugging information.
  --debug[=FLAGS] Print various types of debugging information.
  -e, --environment-overrides
  Environment variables override 

[Bug ipa/90720] g++.dg/lto/alias-1 FAILs

[danglin at gcc dot gnu.org]

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

John David Anglin  changed:

   What|Removed |Added

 Target|*-*-solaris2.11 |*-*-solaris2.11
   ||hppa64-*-hpux*
 CC||danglin at gcc dot gnu.org

--- Comment #5 from John David Anglin  ---
Also fails on hppa64-*-hpux*.

[Bug c++/93360] New: FAIL: g++.dg/cpp0x/std-layout1.C -std=c++2a (test for excess errors)

[danglin at gcc dot gnu.org]

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

Bug ID: 93360
   Summary: FAIL: g++.dg/cpp0x/std-layout1.C  -std=c++2a (test for
excess errors)
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: danglin at gcc dot gnu.org
  Target Milestone: ---
  Host: hppa64-hp-hpux11.11
Target: hppa64-hp-hpux11.11
 Build: hppa64-hp-hpux11.11

spawn /test/gnu/gcc/objdir/gcc/testsuite/g++/../../xg++
-B/test/gnu/gcc/objdir/g
cc/testsuite/g++/../../
/test/gnu/gcc/gcc/gcc/testsuite/g++.dg/cpp0x/std-layout1
.C -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-
color=never -fdiagnostics-urls=never -nostdinc++
-I/test/gnu/gcc/objdir/hppa64-h
p-hpux11.11/libstdc++-v3/include/hppa64-hp-hpux11.11
-I/test/gnu/gcc/objdir/hppa
64-hp-hpux11.11/libstdc++-v3/include -I/test/gnu/gcc/gcc/libstdc++-v3/libsupc++
-I/test/gnu/gcc/gcc/libstdc++-v3/include/backward
-I/test/gnu/gcc/gcc/libstdc++-
v3/testsuite/util -fmessage-length=0 -std=c++2a -pedantic-errors -Wno-long-long
-S -o std-layout1.s
/test/gnu/gcc/gcc/gcc/testsuite/g++.dg/cpp0x/std-layout1.C:29:32: warning:
'temp
late struct std::is_pod' is deprecated [-Wdeprecated-declarations]
/test/gnu/gcc/gcc/gcc/testsuite/g++.dg/cpp0x/std-layout1.C:22:34: note: in
defin
ition of macro 'TRY'
/test/gnu/gcc/gcc/gcc/testsuite/g++.dg/cpp0x/std-layout1.C:44:1: note: in
expans
ion of macro 'NONPOD'
In file included from
/test/gnu/gcc/gcc/gcc/testsuite/g++.dg/cpp0x/std-layout1.C
:20:
/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/include/type_traits:693:5:
 note: declared here
/test/gnu/gcc/gcc/gcc/testsuite/g++.dg/cpp0x/std-layout1.C:30:13: warning:
'temp
late struct std::is_pod' is deprecated [-Wdeprecated-declarations]
/test/gnu/gcc/gcc/gcc/testsuite/g++.dg/cpp0x/std-layout1.C:22:34: note: in
defin
ition of macro 'TRY'
/test/gnu/gcc/gcc/gcc/testsuite/g++.dg/cpp0x/std-layout1.C:44:1: note: in
expans
ion of macro 'NONPOD'
In file included from
/test/gnu/gcc/gcc/gcc/testsuite/g++.dg/cpp0x/std-layout1.C
:20:
/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/include/type_traits:693:5:
 note: declared here
/test/gnu/gcc/gcc/gcc/testsuite/g++.dg/cpp0x/std-layout1.C:31:13: warning:
'temp
late struct std::is_pod' is deprecated [-Wdeprecated-declarations]
/test/gnu/gcc/gcc/gcc/testsuite/g++.dg/cpp0x/std-layout1.C:22:34: note: in
defin
ition of macro 'TRY'
/test/gnu/gcc/gcc/gcc/testsuite/g++.dg/cpp0x/std-layout1.C:44:1: note: in
expans
ion of macro 'NONPOD'
In file included from
/test/gnu/gcc/gcc/gcc/testsuite/g++.dg/cpp0x/std-layout1.C
:20:
/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/include/type_traits:693:5:
 note: declared here
/test/gnu/gcc/gcc/gcc/testsuite/g++.dg/cpp0x/std-layout1.C:29:32: warning:
'temp
late struct std::is_pod' is deprecated [-Wdeprecated-declarations]
/test/gnu/gcc/gcc/gcc/testsuite/g++.dg/cpp0x/std-layout1.C:22:34: note: in
defin
ition of macro 'TRY'
/test/gnu/gcc/gcc/gcc/testsuite/g++.dg/cpp0x/std-layout1.C:47:1: note: in
expans
ion of macro 'NONPOD'
In file included from
/test/gnu/gcc/gcc/gcc/testsuite/g++.dg/cpp0x/std-layout1.C
:20:
/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/include/type_traits:693:5:
 note: declared here
/test/gnu/gcc/gcc/gcc/testsuite/g++.dg/cpp0x/std-layout1.C:30:13: warning:
'temp
late struct std::is_pod' is deprecated [-Wdeprecated-declarations]
/test/gnu/gcc/gcc/gcc/testsuite/g++.dg/cpp0x/std-layout1.C:22:34: note: in
defin
ition of macro 'TRY'
/test/gnu/gcc/gcc/gcc/testsuite/g++.dg/cpp0x/std-layout1.C:47:1: note: in
expansion of macro 'NONPOD'
In file included from
/test/gnu/gcc/gcc/gcc/testsuite/g++.dg/cpp0x/std-layout1.C:20:
/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/include/type_traits:693:5:
note: declared here
/test/gnu/gcc/gcc/gcc/testsuite/g++.dg/cpp0x/std-layout1.C:31:13: warning:
'template struct std::is_pod' is deprecated
[-Wdeprecated-declarations]
/test/gnu/gcc/gcc/gcc/testsuite/g++.dg/cpp0x/std-layout1.C:22:34: note: in
definition of macro 'TRY'
/test/gnu/gcc/gcc/gcc/testsuite/g++.dg/cpp0x/std-layout1.C:47:1: note: in
expansion of macro 'NONPOD'
In file included from
/test/gnu/gcc/gcc/gcc/testsuite/g++.dg/cpp0x/std-layout1.C:20:
/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/include/type_traits:693:5:
note: declared here
output is:
/test/gnu/gcc/gcc/gcc/testsuite/g++.dg/cpp0x/std-layout1.C:29:32: warning:
'template struct std::is_pod' is deprecated
[-Wdeprecated-declarations]
/test/gnu/gcc/gcc/gcc/testsuite/g++.dg/cpp0x/std-layout1.C:22:34: note: in
definition of macro 'TRY'
/test/gnu/gcc/gcc/gcc/testsuite/g++.dg/cpp0x/std-layout1.C:44:1: note: in
expansion of macro 'NONPOD'
In file included from
/test/gnu/gcc/gcc/gcc/testsuite/g++.dg/cpp0x/std-layout1.C:20:

[Bug tree-optimization/93359] Miscompile (loop check omitted) in function with missing return statement

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
In c++, it is undefined behavior if you fall through to the end of a function
without a return if the type is non void.

[Bug ipa/93318] [10 regression] Firefox LTO+FDO ICEs in speculative_call_info

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

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

--- Comment #6 from Jan Hubicka  ---
Firefox builds for me again.

[Bug libstdc++/92895] [libstdc++] stop_token conformance issues

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
(In reply to Lewis Baker from comment #0)
> stop_token::_Stop_cb::_M_callback
> 
>   The function pointer type could be declared noexcept here.
>   This might avoid some extra exception-handling codegen being generated in
>   _M_request_stop() when this function pointer is invoked.

It doesn't hurt to make it noexcept, but it doesn't affect codegen either, at
least not with GCC. Termination is done in the unwind tables, not by adding
extra EH code. It might help Clang though.


> stop_source::operator=(stop_source&& rhs)
> 
>   This implementation just does a swap() which leaves rhs with the previous
> state
>   of *this rather than leaving rhs as an empty state.

Oops, we fixed the same problem for stop_token::operator= but not here.

I suggested defining the assignment operator as defaulted, because the
shared_ptr member already does the right thing here.

[Bug fortran/93340] [8/9/10 Regression] ICE in check_constant_initializer, at fortran/trans-decl.c:5450

[markeggleston at gcc dot gnu.org]

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

markeggleston at gcc dot gnu.org changed:

   What|Removed |Added

 CC||markeggleston at gcc dot 
gnu.org

--- Comment #2 from markeggleston at gcc dot gnu.org ---
Using newer initialisation:

program test
  character :: c(2) = [ 'a', 'b'(1:1) ]
  character :: d(2) = [ 'a', 'bc'(1:1) ]
  write(*,*) c, d
end program test

compiles and runs:

abab

master at https://gcc.gnu.org/g:e82ba180d6641a1e2bad1ac327234fc1cda658ef

Also compiles and runs using the commit indicated in comment 1.

Checking the code for the ICE. In this loop

  for (c = gfc_constructor_first (expr->value.constructor);
   c; c = gfc_constructor_next (c))
{
  if (c->iterator)
return false;
  if (c->expr->expr_type == EXPR_STRUCTURE)
{
  if (!check_constant_initializer (c->expr, ts, false, false))
return false;
}
  else if (c->expr->expr_type != EXPR_CONSTANT)
return false;
}

in check_constant_initializer the value of c->expr on the second iteration is
NULL.

[Bug target/92424] [aarch64] Broken code with -fpatchable-function-entry and BTI

[cvs-commit at gcc dot gnu.org]

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

--- Comment #5 from CVS Commits  ---
The master branch has been updated by Szabolcs Nagy :

https://gcc.gnu.org/g:c292cfe539cd7c060caad826d362ed5e845bfbef

commit r10-6114-gc292cfe539cd7c060caad826d362ed5e845bfbef
Author: Szabolcs Nagy 
Date:   Wed Jan 15 12:23:40 2020 +

[AArch64] PR92424: Fix -fpatchable-function-entry=N,M with BTI

This is a workaround that emits a BTI after the function label if that
is followed by a patch area. We try to remove the BTI that follows the
patch area (this may fail e.g. if the first instruction is a PACIASP).

So before this commit -fpatchable-function-entry=3,1 with bti generates

.section __patchable_function_entries
.8byte .LPFE
.text
  .LPFE:
nop
  foo:
nop
nop
bti c // or paciasp
...

and after this commit

.section __patchable_function_entries
.8byte .LPFE
.text
  .LPFE:
nop
  foo:
bti c
nop
nop
// may be paciasp
...

and with -fpatchable-function-entry=1 (M=0) the code now is

  foo:
bti c
.section __patchable_function_entries
.8byte .LPFE
.text
  .LPFE:
nop
// may be paciasp
...

There is a new bti insn in the middle of the patchable area users need
to be aware of unless M=0 (patch area is after the new bti) or M=N
(patch area is before the label, no new bti). Note: bti is not added to
all functions consistently (it can be turned off per function using a
target attribute or the compiler may detect that the function is never
called indirectly), so if bti is inserted in the middle of a patch area
then user code needs to deal with detecting it.

Tested on aarch64-none-linux-gnu.

gcc/ChangeLog:

PR target/92424
* config/aarch64/aarch64.c (aarch64_declare_function_name): Set
cfun->machine->label_is_assembled.
(aarch64_print_patchable_function_entry): New.
(TARGET_ASM_PRINT_PATCHABLE_FUNCTION_ENTRY): Define.
* config/aarch64/aarch64.h (struct machine_function): New field,
label_is_assembled.

gcc/testsuite/ChangeLog:

PR target/92424
* gcc.target/aarch64/pr92424-1.c: New test.
* gcc.target/aarch64/pr92424-2.c: New test.
* gcc.target/aarch64/pr92424-3.c: New test.

[Bug ipa/93315] ICE in jit testsuite since "Missed function specialization + partial devirtualization" (v8)

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #2 from David Malcolm  ---
Should be fixed by above commit.

[Bug ipa/93315] ICE in jit testsuite since "Missed function specialization + partial devirtualization" (v8)

[cvs-commit at gcc dot gnu.org]

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by David Malcolm :

https://gcc.gnu.org/g:65be83b5ac0410a5e64c648c36aaf4bd10d09bf2

commit r10-6113-g65be83b5ac0410a5e64c648c36aaf4bd10d09bf2
Author: David Malcolm 
Date:   Tue Jan 14 11:32:13 2020 -0500

ipa-profile.c: reset call_sums state within ipa-profile.c (v2; PR 93315)

gcc/ChangeLog:
PR ipa/93315
* ipa-profile.c (ipa_profile): Delete call_sums and set it to
NULL on exit.

[Bug fortran/93329] ICE in omp_code_to_statement, at fortran/openmp.c:5902

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Created attachment 47689
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47689=edit
gcc10-pr93329.patch

Untested fix.

[Bug c++/90732] [9/10 Regression] ICE with std::apply after variable length array

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #4 from Jason Merrill  ---
Reduced further:

int SIZE = 100;

template
void foo(T) {
  char buf[SIZE];
  [](auto){ }(42);
}

int main() { foo(42); }

[Bug ipa/93318] [10 regression] Firefox LTO+FDO ICEs in speculative_call_info

[cvs-commit at gcc dot gnu.org]

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

--- Comment #5 from CVS Commits  ---
The master branch has been updated by Jan Hubicka :

https://gcc.gnu.org/g:28307164dfed294855bf3d55bed357de560f083b

commit r10-6111-g28307164dfed294855bf3d55bed357de560f083b
Author: Jan Hubicka 
Date:   Tue Jan 21 16:33:43 2020 +0100

Fix updating of call_stmt_site_hash

This patch fixes ICE causes by call stmt site hash going out of sync.  For
speculative edges it is assumed to contain a direct call so if we are
removing it hashtable needs to be updated.  I realize that the code is ugly
but I will leave cleanup for next stage1.

Bootstrapped/regtested x86_64-linux. This patch makes it possible to build
Firefox again.

PR lto/93318
* cgraph.c (cgraph_edge::resolve_speculation,
cgraph_edge::redirect_call_stmt_to_callee): Fix update of
call_stmt_site_hash.

[Bug c++/91476] [9/10 Regression] const reference variables sharing the same name in two anonymous namespaces cause a multiple definition error

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #5 from Jason Merrill  ---
Fixed for 9.3/10.

[Bug c++/91476] [9/10 Regression] const reference variables sharing the same name in two anonymous namespaces cause a multiple definition error

[cvs-commit at gcc dot gnu.org]

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

--- Comment #4 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Jason Merrill
:

https://gcc.gnu.org/g:3384aa7af4c4ce193f59d086f507812b88caf113

commit r9-8151-g3384aa7af4c4ce193f59d086f507812b88caf113
Author: Jason Merrill 
Date:   Mon Jan 20 14:09:03 2020 -0500

PR c++/91476 - anon-namespace reference temp clash between TUs.

* call.c (make_temporary_var_for_ref_to_temp): Clear TREE_PUBLIC
if DECL is in the anonymous namespace.