[Bug driver/93796] typo: functoin

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/93780] [10 Regression] ICE in SET_TYPE_VECTOR_SUBPARTS

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r10-6689-gbe7c145ad52e76a1a0fd201dd96bc92e8d3a275d
Author: Jakub Jelinek 
Date:   Tue Feb 18 09:07:15 2020 +0100

tree-ssa: Fix ICE in build_vector_type [PR93780]

The following testcase ICEs, because execute_update_addresses_taken
attempts
to create a VECTOR_TYPE with non-power of 2 number of elts.
Fixed by guarding it with the corresponding predicate.

2020-02-18  Jakub Jelinek  

PR tree-optimization/93780
* tree-ssa.c (non_rewritable_lvalue_p): Check valid_vector_subparts_p
before calling build_vector_type.
(execute_update_addresses_taken): Likewise.

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

[Bug tree-optimization/93780] [10 Regression] ICE in SET_TYPE_VECTOR_SUBPARTS

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug c/93631] [8/9/10 Regression] ICE on an invalid strcmp call in gimple_ca ll_arg, at gimple.h:3258

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
   Target Milestone|--- |8.4

[Bug c/93631] [8/9/10 Regression] ICE on an invalid strcmp call in gimple_ca ll_arg, at gimple.h:3258

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
Just to add as a data point, gimple_builtin_call_types_compatible_p was
originally added to catch indirect calls turned into direct calls of
builtins but with wrongly typed args like from

 void (*fn)(int) = (void (*)(int))&memcpy;
 fn (1);

it was _not_ designed to cope with a function decl that claims to be
BUILT_IN_MEMCPY but whose TYPE_ARG_TYPES are not compatible with what
we'd expect from a memcpy declaration.  It is the frontends business
to make sure the middle-end is not seeing a DECL_FUNCTION_CODE when
the types do not match the canonical function declaration.

The patch from comment#3 is a hack trying to work around FEs brokeness.

But it's the frontends that need fixing.  Finally.  Please.  Iff then
as hackish as comment#3 but please within the FE like in merge_decls
at the end do

if (DECL_FUNCTION_CODE (...)
&& !decls_compatible_p (builtin_decl_explicit (...), ...)))
  DECL_BUILT_IN_CLASS (..) = BUILT_IN_NONE;

and possibly clear the decl from builtin_decl_implicit iff we ever
populated that with user decls.

[Bug fortran/93794] [8/9/10 Regression] ICE in gfc_conv_component_ref, at fortran/trans-expr.c:2497

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-02-18
 CC||marxin at gcc dot gnu.org,
   ||pault at gcc dot gnu.org
  Known to work||7.4.0
   Target Milestone|--- |8.4
 Ever confirmed|0   |1
  Known to fail||10.0, 8.3.0, 9.2.0

--- Comment #1 from Martin Liška  ---
Confirmed, started with r8-3589-g707905d0773e5a8e.

[Bug fortran/93792] [10 Regression] ICE in gfc_code2string, at fortran/misc.c:281

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #3 from Martin Liška  ---
Just for the record, it started with r10-2083-g8dc63166e0b85954.

[Bug fortran/93791] [9/10 Regression] ICE in can_represent_integral_type_p, at real.c:5426

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-02-18
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Martin Liška  ---
It's very old (at least 4.8.0+).

[Bug c++/93788] Segfault caused by infinite loop in cc1plus

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-02-18
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug middle-end/93786] [8/9/10 Regression] gimplifier ICE with statement expression since r8-5526

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-02-18
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug c++/93785] g++ crash/hang on invalid template

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-02-18
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug tree-optimization/93745] [8/9/10 Regression] Redundant store not eliminated with intermediate instruction

[rguenther at suse dot de]

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

--- Comment #9 from rguenther at suse dot de  ---
On Tue, 18 Feb 2020, msebor at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93745
> 
> --- Comment #7 from Martin Sebor  ---
> That's why I asked "What language relies on this?"
> 
> But regardless of what language might have even looser rules than C/C++ in 
> this
> area, it would seem like a rather unfortunate design limitation for GCC not to
> be able to analyze and optimize C/C++ code as well as other compilers can
> because it supports languages others don't (LLVM supports most of the 
> languages
> GCC does).
> 
> What would it take to get GCC to handle this case?  Changing the front-end to
> implicitly declare p restrict?  (That would only work in a small subset of
> cases and would be wrong in many more.)

I guess it would be sth like marking decls with a 
new DECL_FIXED_DYNAMIC_TYPE flag?

Note that TBAA works with a very small set of implementation building 
blocks and often final semantics are the outcome of the need to fulfil
certain properties.

For example before C++17(?) came along there was no real written
consent as to how do struct { int kind; char data[64]; } x;
and new (x.data) T - that's one reason we have the middle-end
semantics we have (code used to do that and we had to make it work).
Now we have TYPE_TYPELESS_STORAGE on the data member (which is
implementation-wise an even bigger hammer!) but only the C++ FE
sets that.  But there's still people doing effectively the same in C
where there's no standards blessed way - QOI tells me we should still
support them.

So effectively the middle-end doesn't know the dynamic type of
an object unless it can derive it by seeing a store to the object
or a load from the object (a load only constraints the dynamic type,
it doesn't fixate it).

The consequences are that we can't optimize some of the "obvious" cases
but as you say yourself it's hard to be conservatively correct but also
most optimal and we can't be wrong in a _single_ case.

We arrived at the current scheme as a result of getting _many_ cases
wrong with a load of hacks in place and no real idea of a middle-end
memory model.  I fixed that back in time and now all stores possibly
change the dynamic type of the underlying object.

[Bug ipa/93799] New: [10 Regression] ice in propagate_vals_across_arith_jfunc, at ipa-cp.c:2039

[gcc-bugs at marehr dot dialup.fu-berlin.de]

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

Bug ID: 93799
   Summary: [10 Regression] ice in
propagate_vals_across_arith_jfunc, at ipa-cp.c:2039
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gcc-bugs at marehr dot dialup.fu-berlin.de
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

The following code ICEs

```c++
struct search_param {
  int total;
};
void search_trivial(search_param error_left) {
  search_trivial(error_left);
  search_param error_left2{error_left};
  error_left2.total--;
  search_trivial(error_left2);
}
void search_algo_uni(search_param error_left) { search_trivial(error_left); }
void search_algo(search_param error_left) { search_algo_uni(error_left); }
int main() { search_algo({}); return 0; }
```

https://godbolt.org/z/aPnCGi

with

```
> g++-git -O3 -c ice.cpp
during IPA pass: cp
ice.cpp:12:41: internal compiler error: in propagate_vals_across_arith_jfunc,
at ipa-cp.c:2039
   12 | int main() { search_algo({}); return 0; }
  | ^
0x639286 propagate_vals_across_arith_jfunc
/home/marehr/Packages/gcc-git/src/gcc/gcc/ipa-cp.c:2039
0x14d5f24 propagate_aggregate_lattice
/home/marehr/Packages/gcc-git/src/gcc/gcc/ipa-cp.c:2690
0x14d5f24 propagate_aggs_across_jump_function
/home/marehr/Packages/gcc-git/src/gcc/gcc/ipa-cp.c:2781
0x14d5f24 propagate_constants_across_call
/home/marehr/Packages/gcc-git/src/gcc/gcc/ipa-cp.c:2875
0x14d62a6 propagate_constants_topo
/home/marehr/Packages/gcc-git/src/gcc/gcc/ipa-cp.c:3794
0x14da490 ipcp_propagate_stage
/home/marehr/Packages/gcc-git/src/gcc/gcc/ipa-cp.c:3910
0x14da490 ipcp_driver
/home/marehr/Packages/gcc-git/src/gcc/gcc/ipa-cp.c:5899
0x14da490 execute
/home/marehr/Packages/gcc-git/src/gcc/gcc/ipa-cp.c:5992
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
```

This might be the same ICE as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93763, but I reported it as a new
issue, because they have different stack-traces.


```
> g++-git -v
Using built-in specs.
COLLECT_GCC=g++-git
COLLECT_LTO_WRAPPER=/opt/gcc/gcc-git/bin/../lib/gcc/x86_64-pc-linux-gnu/10.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /home/marehr/Packages/gcc-git/src/gcc/configure --prefix=/usr
--libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++ --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 --enable-multilib
--disable-werror --enable-checking=release --enable-default-pie
--enable-default-ssp --enable-cet=auto --disable-boostrap
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 10.0.1 20200217 (experimental) (GCC)
```

[Bug tree-optimization/92420] [8/9 Regression] Vectorization miscompilation with negative strides since r238039

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:2d8ea3a0a6095a56b7c59c50b1068d602cde934a

commit r9-8248-g2d8ea3a0a6095a56b7c59c50b1068d602cde934a
Author: Richard Sandiford 
Date:   Mon Nov 11 19:43:52 2019 +

Fix SLP downward group access classification [PR92420]

This PR was caused by the SLP handling in get_group_load_store_type
returning VMAT_CONTIGUOUS rather than VMAT_CONTIGUOUS_REVERSE for
downward groups.

A more elaborate fix would be to try to combine the reverse permutation
into SLP_TREE_LOAD_PERMUTATION for loads, but that's really a follow-on
optimisation and not backport material.  It might also not necessarily
be a win, if the target supports (say) reversing and odd/even swaps
as independent permutes but doesn't recognise the combined form.

2020-02-18  Richard Sandiford  

gcc/
Backport from mainline
2019-11-11  Richard Sandiford  

PR tree-optimization/92420
* tree-vect-stmts.c (get_negative_load_store_type): Move further
up file.
(get_group_load_store_type): Use it for reversed SLP accesses.

gcc/testsuite/
PR tree-optimization/92420
* gcc.dg/vect/pr92420.c: New test.

[Bug tree-optimization/92710] [9 Regression] Vectoriser generates invalid simd call for bool arguments

[cvs-commit at gcc dot gnu.org]

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

--- Comment #5 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Richard Sandiford
:

https://gcc.gnu.org/g:84a465171761faeceb87037a606f7834dab18942

commit r9-8249-g84a465171761faeceb87037a606f7834dab18942
Author: Richard Sandiford 
Date:   Fri Nov 29 13:04:56 2019 +

Don't pass booleans as mask types to simd clones [PR92710]

In this PR we assigned a vector mask type to the result of a comparison
and then tried to pass that mask type to a simd clone, which expected
a normal (non-mask) type instead.

This patch simply punts on call arguments that have a mask type.
A better fix would be to pattern-match the comparison to a COND_EXPR,
like we would if the comparison was stored to memory, but doing that
isn't gcc 9 or 10 material.

Note that this doesn't affect x86_64-linux-gnu because the ABI promotes
bool arguments to ints.

2020-02-18  Richard Sandiford  

gcc/
Backport from mainline
2019-11-29  Richard Sandiford  

PR tree-optimization/92710
* tree-vect-stmts.c (vectorizable_simd_clone_call): Reject
vector mask arguments.

gcc/testsuite/
PR tree-optimization/92710
* gcc.dg/vect/pr92710.c: New test.

[Bug target/90724] ICE with __sync_bool_compare_and_swap with -march=armv8.2-a+sve

[cvs-commit at gcc dot gnu.org]

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

--- Comment #5 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Richard Sandiford
:

https://gcc.gnu.org/g:65709f4b93c74101440ab16bf4bddf6e44672177

commit r9-8247-g65709f4b93c74101440ab16bf4bddf6e44672177
Author: Prathamesh Kulkarni 
Date:   Wed Aug 21 18:34:43 2019 +

re PR target/90724 (ICE with __sync_bool_compare_and_swap with
-march=armv8.2-a+sve)

2020-02-18  Richard Sandiford  

gcc/
Backport from mainline
2019-08-21  Prathamesh Kulkarni  

PR target/90724
* config/aarch64/aarch64.c (aarch64_gen_compare_reg_maybe_ze): Force y
in reg if it fails aarch64_plus_operand predicate.

[Bug tree-optimization/93434] [8/9 Regression] Miscompilation with -O3 starting from 8.1

[cvs-commit at gcc dot gnu.org]

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

--- Comment #8 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Richard Sandiford
:

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

commit r9-8250-ge129cd5283c2e57fc2a86e6981b8e1556b13069c
Author: Richard Sandiford 
Date:   Mon Jan 27 19:37:55 2020 +

predcom: Fix invalid store-store commoning [PR93434]

predcom has the following code to stop one rogue load from
interfering with other store-load opportunities:

  /* If A is read and B write or vice versa and there is unsuitable
 dependence, instead of merging both components into a component
 that will certainly not pass suitable_component_p, just put the
 read into bad component, perhaps at least the write together with
 all the other data refs in it's component will be optimizable.  */

But when store-store commoning was added later, this had the effect
of ignoring loads that occur between two candidate stores.

There is code further up to handle loads and stores with unknown
dependences:

  /* Don't do store elimination if there is any unknown dependence for
 any store data reference.  */
  if ((DR_IS_WRITE (dra) || DR_IS_WRITE (drb))
  && (DDR_ARE_DEPENDENT (ddr) == chrec_dont_know
  || DDR_NUM_DIST_VECTS (ddr) == 0))
eliminate_store_p = false;

But the store-load code above skips loads for *known* dependences
if (a) the load has already been marked "bad" or (b) the data-ref
machinery knows the dependence distance, but determine_offsets
can't handle the combination.

(a) happens to be the problem in the testcase, but a different
sequence could have given (b) instead.  We have writes to individual
fields of a structure and reads from the whole structure.  Since
determine_offsets requires the types to be the same, it returns false
for each such read/write combination.

This patch records which components have had loads removed and
prevents store-store commoning for them.  It's a bit too pessimistic,
since there shouldn't be a problem if a "bad" load dominates all stores
in a component.  But (a) we can't AFAIK use pcom_stmt_dominates_stmt_p
here and (b) the handling for that case would probably need to be
removed again if we handled more exotic cases in future.

2020-02-18  Richard Sandiford  

gcc/
Backport from mainline
2020-01-28  Richard Sandiford  

PR tree-optimization/93434
* tree-predcom.c (split_data_refs_to_components): Record which
components have had aliasing loads removed.  Prevent store-store
commoning for all such components.

gcc/testsuite/
PR tree-optimization/93434
* gcc.c-torture/execute/pr93434.c: New test.

[Bug ipa/93797] typo: speculative_uid

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r10-6690-gda67227bfc407dd1412b3396ed962f30084f9401
Author: Jakub Jelinek 
Date:   Tue Feb 18 09:54:17 2020 +0100

ipa: Various diagnostic fixes [PR93797]

As the patch shows, various messages didn't match the field names they are
talking about.

2020-02-18  Jakub Jelinek  

PR ipa/93797
* cgraph.c (verify_speculative_call): Use speculative_id instead of
speculative_uid in messages.  Remove trailing whitespace from error
message.  Use num_speculative_call_targets instead of
num_speculative_targets in a message.
(cgraph_node::verify_node): Use call_stmt instead of cal_stmt in
edge messages and stmt instead of cal_stmt in reference message.

[Bug ipa/93797] typo: speculative_uid

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug fortran/92587] Compiler is unable to generate finalization wrapper

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #8 from Martin Liška  ---
Ok, there are 2 problems:
1) gfortran -c -g gfc_vector.F90
f951: internal compiler error: Invalid expression in gfc_element_size.
0x77b62e0a __libc_start_main
../csu/libc-start.c:308

this was fixed with r9-6779-g93755deb5c26a821

2) The generate_finalization_wrapper ICE which is still valid on master.
I'm going to reduce that..

[Bug fortran/93791] ICE in can_represent_integral_type_p, at real.c:5426

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Keywords||ice-checking
 CC||jakub at gcc dot gnu.org
Summary|[9/10 Regression] ICE in|ICE in
   |can_represent_integral_type |can_represent_integral_type
   |_p, at real.c:5426  |_p, at real.c:5426

--- Comment #3 from Jakub Jelinek  ---
With s/end/end function/ in the two spots ICEs even with r9 the same
waypr93791.f90: In function ‘f’:
pr93791.f90:5: error: invalid types in conversion to floating point
real(kind=4)
real(kind=4) (*) (void)
__result_f.1 = (real(kind=4)) g;

pr93791.f90:5: internal compiler error: verify_gimple failed
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
so I don't think this is actually a regression.

[Bug target/90724] ICE with __sync_bool_compare_and_swap with -march=armv8.2-a+sve

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

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

--- Comment #6 from rsandifo at gcc dot gnu.org  
---
Also fixed for gcc-9.

[Bug tree-optimization/92710] [9 Regression] Vectoriser generates invalid simd call for bool arguments

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

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

--- Comment #6 from rsandifo at gcc dot gnu.org  
---
Fixed on gcc-9.

[Bug tree-optimization/93434] [8 Regression] Miscompilation with -O3 starting from 8.1

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

Summary|[8/9 Regression]|[8 Regression]
   |Miscompilation with -O3 |Miscompilation with -O3
   |starting from 8.1   |starting from 8.1

--- Comment #9 from rsandifo at gcc dot gnu.org  
---
Fixed on gcc-9.  Will apply to gcc-8 later in the week.

[Bug ipa/93799] [10 Regression] ice in propagate_vals_across_arith_jfunc, at ipa-cp.c:2039

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Priority|P3  |P1
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2020-02-18
  Known to work||9.2.0
   Assignee|unassigned at gcc dot gnu.org  |fxue at gcc dot gnu.org
   Target Milestone|--- |10.0
 Ever confirmed|0   |1
  Known to fail||10.0

--- Comment #1 from Martin Liška  ---
Confirmed, started with r10-5098-g9b14fc3326e08797 where I see probably an
infinite loop.

[Bug middle-end/93786] [8/9/10 Regression] gimplifier ICE with statement expression since r8-5526

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
   Priority|P3  |P2
 CC||rguenth at gcc dot gnu.org

--- Comment #2 from Richard Biener  ---
Hmm, but this destructive modification of something we don't unshare doesn't
work.  Either we have to always wrap statement lists but then we're back to
the compare-debug issue or we somehow fix the destructiveness on the
stmt list node itself - like not setting it's type to void or marking it
as having side-effects (why do we do this anyways, in voidify_wrapper_expr?
is that for debugging?), we'd also need to leave the final value in the
stmt list for a possible second gimplification round...

Maybe the best thing is to kill off the debug stmts when they would cause
a stmt list to appear and revert the previous fix.

[Bug c++/93789] [8/9/10 Regression] internal compiler error: in tree_to_uhwi, at tree.c:7361

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug fortran/93794] [8/9/10 Regression] ICE in gfc_conv_component_ref, at fortran/trans-expr.c:2497

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P4

[Bug middle-end/93786] [8/9/10 Regression] gimplifier ICE with statement expression since r8-5526

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
(In reply to Richard Biener from comment #2)
> Hmm, but this destructive modification of something we don't unshare doesn't
> work.  Either we have to always wrap statement lists but then we're back to
> the compare-debug issue or we somehow fix the destructiveness on the
> stmt list node itself - like not setting it's type to void or marking it
> as having side-effects (why do we do this anyways, in voidify_wrapper_expr?
> is that for debugging?), we'd also need to leave the final value in the
> stmt list for a possible second gimplification round...
> 
> Maybe the best thing is to kill off the debug stmts when they would cause
> a stmt list to appear and revert the previous fix.

We might kill them only in one of the two places (say keep in the argument and
remove from the OBJ_TYPE_REF operand or vice versa), but we'd need some
function that walks the non-TREE_SIDE_EFFECTS tree and looks for such
STATEMENT_LISTs, as they might be wrapped in casts/whatever else that doesn't
have side-effects.
Another possibility would be do that in copy_if_shared_r or so (only handle the
!TREE_SIDE_EFFECTS STATEMENT_EXPR that contain only DEBUG_STMTs + one non-debug
one), but we wouldn't have control over which of the two or more copies gets to
keep the STATEMENT_LIST and which don't (well, it would be whatever we
walk_tree first).

[Bug fortran/27452] gfortran support for non-standard sind,cosd and friends intrinsics

[thenlich at gcc dot gnu.org]

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

Thomas Henlich  changed:

   What|Removed |Added

 CC||thenlich at gcc dot gnu.org
 Resolution|INVALID |FIXED
   Assignee|unassigned at gcc dot gnu.org  |foreese at gcc dot 
gnu.org

--- Comment #13 from Thomas Henlich  ---
Update: these functions have now been implemented:
https://gcc.gnu.org/ml/fortran/2016-09/msg00163.html

[Bug middle-end/93786] [8/9/10 Regression] gimplifier ICE with statement expression since r8-5526

[rguenther at suse dot de]

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

--- Comment #4 from rguenther at suse dot de  ---
On Tue, 18 Feb 2020, jakub at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93786
> 
> --- Comment #3 from Jakub Jelinek  ---
> (In reply to Richard Biener from comment #2)
> > Hmm, but this destructive modification of something we don't unshare doesn't
> > work.  Either we have to always wrap statement lists but then we're back to
> > the compare-debug issue or we somehow fix the destructiveness on the
> > stmt list node itself - like not setting it's type to void or marking it
> > as having side-effects (why do we do this anyways, in voidify_wrapper_expr?
> > is that for debugging?), we'd also need to leave the final value in the
> > stmt list for a possible second gimplification round...
> > 
> > Maybe the best thing is to kill off the debug stmts when they would cause
> > a stmt list to appear and revert the previous fix.
> 
> We might kill them only in one of the two places (say keep in the argument and
> remove from the OBJ_TYPE_REF operand or vice versa), but we'd need some
> function that walks the non-TREE_SIDE_EFFECTS tree and looks for such
> STATEMENT_LISTs, as they might be wrapped in casts/whatever else that doesn't
> have side-effects.
> Another possibility would be do that in copy_if_shared_r or so (only handle 
> the
> !TREE_SIDE_EFFECTS STATEMENT_EXPR that contain only DEBUG_STMTs + one 
> non-debug
> one), but we wouldn't have control over which of the two or more copies gets 
> to
> keep the STATEMENT_LIST and which don't (well, it would be whatever we
> walk_tree first).

Could we make those sepcifc DEBUG_STMTS appear only later (during
gimplification maybe?) and represent them as expression flags in the
FEs?  That would avoid the stmt-list wrapping dependent on -g

[Bug middle-end/93786] [8/9/10 Regression] gimplifier ICE with statement expression since r8-5526

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
(In reply to rguent...@suse.de from comment #4)
> Could we make those sepcifc DEBUG_STMTS appear only later (during
> gimplification maybe?) and represent them as expression flags in the
> FEs?  That would avoid the stmt-list wrapping dependent on -g

A question for Alex I guess.

[Bug fortran/93580] [9/10 Regression] ICE in gfc_validate_kind(): Got bad kind

[cvs-commit at gcc dot gnu.org]

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

--- Comment #5 from CVS Commits  ---
The master branch has been updated by Mark Eggleston
:

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

commit r10-6691-gd4c10c9f4bff616e7ed07e92504fe31a700e2af1
Author: Mark Eggleston 
Date:   Tue Feb 18 10:00:50 2020 +

[fortran] ICE in gfc_validate_kind(): Got bad kind [PR93580]

Caused by using invalid part_refs in kind specifications,
e.g. %re or %im on non-complex expressions and %len on
non character expressions.

Check whether %re, %im and %len are valid when checking
kind specification.

The original patch from Steven G. Kargl   only
checked for %re and %im.

gcc/fortran/ChangeLog:

PR fortran/93580
* primary.c (gfc_match_varspec): If the symbol following %
is re or im and the primary expression type is not BT_COMPLEX
issue an error. If the symbol is len and the primary
expression type is not BT_CHARACTER is an error.

gcc/testsuite/ChangeLog:

PR fortran/93580
* gfortran.dg/dg/pr93580.f90: New test.

[Bug middle-end/93582] [10 Regression] -Warray-bounds gives error: array subscript 0 is outside array bounds of struct E[1]

[rguenther at suse dot de]

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

--- Comment #27 from rguenther at suse dot de  ---
On Mon, 17 Feb 2020, jakub at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93582
> 
> --- Comment #26 from Jakub Jelinek  ---
> Created attachment 47863
>   --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47863&action=edit
> gcc10-pr93582-2-wip.patch
> 
> WIP on the merging from multiple stores.  BIG_ENDIAN still not implemented.

Looks reasonable.  Btw, the shift-and-merge into existing buffer
pieces probably also belong to fold-const.c alongside
native_encode + the shift helpers.  I wonder how much we can
"micro-optimize" there by encoding and shifting in place of the
destination buffer and saving the first/last byte from it to
fixup the bits we have to preserve? (it looks like you already
do parts of that but still have to copy)

As an intermediate step I'd have simply changed the bytes to 
bit quantities and placed the byte-granularity restriction into
push_partial_def.

[Bug c/93800] New: GCC adds unwanted nops to align loops on powerpc 8xx

[christophe.le...@c-s.fr]

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

Bug ID: 93800
   Summary: GCC adds unwanted nops to align loops on powerpc 8xx
   Product: gcc
   Version: 9.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: christophe.le...@c-s.fr
  Target Milestone: ---

GCC 9.2 add nops in front of loops. GCC 8.1 didn't when compiled for powerpc
8xx. On the 8xx, a nop is 1 cycle and alignment of loops provide no benefit, so
this is a waste of cycles.

Reproducer:

volatile int g;
int f(int a, int b)
{
int i;

for (i = 0; i < b; i++)
a += g;
return a;
}

Built with -m32 -mcpu=860 -O2

 :
   0:   2c 04 00 00 cmpwi   r4,0
   4:   4c 81 00 20 blelr   
   8:   3d 40 00 00 lis r10,0
a: R_PPC_ADDR16_HA  g
   c:   7c 89 03 a6 mtctr   r4
  10:   39 4a 00 00 addir10,r10,0
12: R_PPC_ADDR16_LO g
  14:   60 00 00 00 nop
  18:   60 00 00 00 nop
  1c:   60 00 00 00 nop
  20:   81 2a 00 00 lwz r9,0(r10)
  24:   7c 63 4a 14 add r3,r3,r9
  28:   42 00 ff f8 bdnz20 
  2c:   4e 80 00 20 blr



The same with GCC 8.1:

 :
   0:   2c 04 00 00 cmpwi   r4,0
   4:   4c 81 00 20 blelr   
   8:   3d 40 00 00 lis r10,0
a: R_PPC_ADDR16_HA  g
   c:   7c 89 03 a6 mtctr   r4
  10:   39 4a 00 00 addir10,r10,0
12: R_PPC_ADDR16_LO g
  14:   81 2a 00 00 lwz r9,0(r10)
  18:   7c 63 4a 14 add r3,r3,r9
  1c:   42 00 ff f8 bdnz14 
  20:   4e 80 00 20 blr

[Bug target/93800] [9/10 Regression] GCC adds unwanted nops to align loops on powerpc 8xx

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Target||powerpc
  Component|c   |target
   Target Milestone|--- |9.3
Summary|GCC adds unwanted nops to   |[9/10 Regression] GCC adds
   |align loops on powerpc 8xx  |unwanted nops to align
   ||loops on powerpc 8xx

[Bug c++/93801] New: False -Wmismatched-tags upon redundant typename

[sbergman at redhat dot com]

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

Bug ID: 93801
   Summary: False -Wmismatched-tags upon redundant typename
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sbergman at redhat dot com
CC: msebor at gcc dot gnu.org
  Target Milestone: ---

With recent GCC trunk:

> $ cat test.cc
> namespace N { struct S {}; }
> typename N::S s;
> 
> $ g++ -fsyntax-only -Wmismatched-tags test.cc
> test.cc:2:13: warning: ‘N::S’ declared with a mismatched class-key ‘class’ 
> [-Wmismatched-tags]
> 2 | typename N::S s;
>   | ^
> test.cc:2:13: note: remove the class-key or replace it with ‘struct’
> test.cc:1:22: note: ‘N::S’ defined as ‘struct’ here
> 1 | namespace N { struct S {}; }
>   |  ^

[Bug fortran/93580] [9/10 Regression] ICE in gfc_validate_kind(): Got bad kind

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:560139481239e37a1cc878fb90805fa5e94f623c

commit r9-8251-g560139481239e37a1cc878fb90805fa5e94f623c
Author: Mark Eggleston 
Date:   Tue Feb 18 10:56:38 2020 +

[fortran] ICE in gfc_validate_kind(): Got bad kind [PR93580]

Caused by using invalid part_refs in kind specifications,
e.g. %re or %im on non-complex expressions and %len on
non character expressions.

Check whether %re, %im and %len are valid when checking
kind specification.

The original patch from Steven G. Kargl   only
checked for %re and %im.

Backported from mainline
2020-02-18  Mark Eggleston 

PR fortran/93580
* primary.c (gfc_match_varspec): If the symbol following %
is re or im and the primary expression type is not BT_COMPLEX
issue an error. If the symbol is len and the primary
expression type is not BT_CHARACTER is an error.

PR fortran/93580
* gfortran.dg/dg/pr93580.f90: New test.

[Bug fortran/93579] [9/10 Regression] ICE in gfc_conv_substring_expr, at fortran/trans-expr.c:8587

[markeggleston at gcc dot gnu.org]

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

Bug 93580 Summary: [9/10 Regression] ICE in gfc_validate_kind(): Got bad kind
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93580

   What|Removed |Added

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

[Bug fortran/93580] [9/10 Regression] ICE in gfc_validate_kind(): Got bad kind

[markeggleston at gcc dot gnu.org]

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

markeggleston at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #7 from markeggleston at gcc dot gnu.org ---
Committed for master and gcc 9 branch.

[Bug target/93802] New: gcc generates a rlwinm/or pair instead of a single rlwimi (powerpc)

[christophe.le...@c-s.fr]

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

Bug ID: 93802
   Summary: gcc generates a rlwinm/or pair instead of a single
rlwimi (powerpc)
   Product: gcc
   Version: 9.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: christophe.le...@c-s.fr
  Target Milestone: ---

unsigned long f(unsigned short x)
{
return (x << 16) | x;
}



Results in:

 :
   0:   54 69 80 1e rlwinm  r9,r3,16,0,15
   4:   7d 23 1b 78 or  r3,r9,r3
   8:   4e 80 00 20 blr



Should instead be:

rlwimi r3, r3, 16, 0, 15
blr

Problem seen with at least GCC 9.2 and GCC 8.1 and GCC 5.5

[Bug fortran/93603] [10 Regression] ICE in gfc_typenode_for_spec, at fortran/trans-types.c:1201

[cvs-commit at gcc dot gnu.org]

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Mark Eggleston
:

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

commit r10-6692-g8f55a0eec910dd02992f4caca083048d91c0b2e1
Author: Mark Eggleston 
Date:   Tue Feb 18 12:23:20 2020 +

[Fortran] ICE in gfc_typenode_for_spec PR93603

Associating a symbol with a BOZ constant caused an ICE.  Output
an error message as an association target cannot be a BOZ
constant.

Original patch provided by Steven G. Kargl  .

gcc/fortran/ChangeLog

PR fortran/93603
* match.c (gfc_match_associate) : If target expression
has the type BT_BOZ output an error and goto
assocListError.

gcc/testsuite/ChangeLog

PR fortran/93603
* gfortran.dg/pr93603.f90 : New test.

[Bug c++/90313] [8/9 Regression] Is an assignment elided with gcc7.3 -O2?

[cvs-commit at gcc dot gnu.org]

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

--- Comment #7 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Richard Sandiford
:

https://gcc.gnu.org/g:52db14c1f700e14e5b1b6c7fc702c0a08cc3781c

commit r9-8252-g52db14c1f700e14e5b1b6c7fc702c0a08cc3781c
Author: Richard Sandiford 
Date:   Fri Aug 9 09:37:55 2019 +

Reject tail calls that read from an escaped RESULT_DECL [PR90313]

In this PR we have two return paths from a function "map".  The common
code sets  to the value returned by one path, while the other
path does:

= map (&, ...);

We treated this call as tail recursion, losing the copy semantics
on the value returned by the recursive call.

We'd correctly reject the same thing for variables:

   local = map (&local, ...);

The problem is that RESULT_DECLs didn't get the same treatment.

2020-02-18  Richard Sandiford  

gcc/
Backport from mainline
2019-08-09  Richard Sandiford  

PR middle-end/90313
* tree-tailcall.c (find_tail_calls): Reject calls that might
read from an escaped RESULT_DECL.

gcc/testsuite/
PR middle-end/90313
* g++.dg/torture/pr90313.cc: New test.

[Bug tree-optimization/92768] [8/9 Regression] Maybe a wrong code for vector constants

[cvs-commit at gcc dot gnu.org]

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

--- Comment #20 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Richard Sandiford
:

https://gcc.gnu.org/g:2408b93a10c9c6cb210bc2a93d39ce6d56144ca3

commit r9-8253-g2408b93a10c9c6cb210bc2a93d39ce6d56144ca3
Author: Richard Sandiford 
Date:   Thu Dec 5 14:20:38 2019 +

Check for bitwise identity when encoding VECTOR_CSTs [PR92768]

This PR shows that we weren't checking for bitwise-identical values
when trying to encode a VECTOR_CST, so -0.0 was treated the same as
0.0 for -fno-signed-zeros.  The patch adds a new OEP flag to select
that behaviour.

2020-02-18  Richard Sandiford  

gcc/
Backport from mainline
2019-12-05  Richard Sandiford  

PR middle-end/92768
* tree-core.h (OEP_BITWISE): New flag.
* fold-const.c (operand_compare::operand_equal_p): Handle it.
* tree-vector-builder.h (tree_vector_builder::equal_p): Pass it.

gcc/testsuite/
PR middle-end/92768
* gcc.dg/pr92768.c: New test.

[Bug fortran/93603] [10 Regression] ICE in gfc_typenode_for_spec, at fortran/trans-types.c:1201

[markeggleston at gcc dot gnu.org]

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

markeggleston at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #3 from markeggleston at gcc dot gnu.org ---
Committed.

[Bug tree-optimization/93776] [10 Regression] ICE in verify_sra_access_forest, at tree-sra.c:2326

[jamborm at gcc dot gnu.org]

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

--- Comment #3 from Martin Jambor  ---
x86_64 testcase (reproduces at -O1):

struct empty {};
struct s { int i; };
struct z
{
  int j;
  struct empty e;
  struct s s;
};

void bar (struct z);

void foo (void)
{
  struct z z, z2;

  z2.s.i = 1;
  z = z2;
  bar (z);
  z.e = (struct empty) {};
}

[Bug analyzer/93779] ICE: unhandled tree code in region_model::get_lvalue_1: 'function_decl'

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:68f9c41d54a7839e90d10e1400c8726c8ccde88d

commit r10-6693-g68f9c41d54a7839e90d10e1400c8726c8ccde88d
Author: David Malcolm 
Date:   Mon Feb 17 03:28:08 2020 -0500

analyzer: add test coverage for gfortran ICE fix [PR 93779]

PR analyzer/93779 reports an ICE in gfortran with -fanalyzer
that was fixed for GCC 10 by a workaround in
f76a88ebf089871dcce215aa0cb1956ccc060895; the tree code in
question is a FUNCTION_DECL.

Given that I want to rework the above patch at some point, it seems
prudent to add test coverage to ensure the ICE doesn't come back,
which this patch does.

gcc/testsuite/ChangeLog:
PR analyzer/93779
* gfortran.dg/analyzer/pr88304-2.f90: New test, adapted from
gfortran.fortran-torture/compile/pr88304-2.f90

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[dave.anglin at bell dot net]

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

--- Comment #189 from dave.anglin at bell dot net ---
On 2020-02-16 4:21 p.m., John David Anglin wrote:
> On 2020-02-15 3:32 p.m., peter.bisroev at groundlabs dot com wrote:
>> I have not had a chance to look through these in great detail, will do this
>> later today, but some things I've noticed (not sure how important they are
>> yet):
>> - aCC seems to use PCREL21BI relocations while GCC PCREL21B.
> That may be the clue.  With GNU ld, only PCREL21BI goes through PLT.  Need to 
> look at when
> GNU as uses PCREL21BI instead of PCREL21B.  I believe this selection is done 
> in assembler.
Sorry, only PCREL21B goes through PLT.  PCREL21BI is for local (internal)
calls.

[Bug analyzer/93774] ICE in lhd_incomplete_type_error

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r10-6694-ga674c7b8b8028c5d7e52dd38783e8e2b02034b63
Author: David Malcolm 
Date:   Mon Feb 17 09:18:39 2020 -0500

analyzer: fix ICE on pointer arithmetic with incomplete types [PR 93774]

PR analyzer/93774 reports an ICE in gfortran with -fanalyzer within
region_model::convert_byte_offset_to_array_index on a pointer of
incomplete type ("character(kind=1)[0:][1:0] * restrict").

This patch bulletproofs the routine against incomplete types, fixing
the ICE.

gcc/analyzer/ChangeLog:
PR analyzer/93774
* region-model.cc
(region_model::convert_byte_offset_to_array_index): Use
int_size_in_bytes before calling size_in_bytes, to gracefully fail
on incomplete types.

gcc/testsuite/ChangeLog:
PR analyzer/93774
* gfortran.dg/analyzer/deferred_character_25.f90: New test,
based on gfortran.dg/deferred_character_25.f90.

[Bug analyzer/93388] ensure -fanalyzer works with our C code

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:2e6233935c77b56a68e939c629702f960b8e6fb2

commit r10-6695-g2e6233935c77b56a68e939c629702f960b8e6fb2
Author: David Malcolm 
Date:   Mon Feb 17 16:43:46 2020 -0500

analyzer: fix ICE on COMPONENT_REF of ARRAY_TYPE [PR 93778]

PR analyzer/93778 reports an ICE with -fanalyzer on a gfortran test case
at this gimple stmt:

  _gfortran_st_set_nml_var (&dt_parm.0, &ro.xi.jq, &"ro%xi%jq"[1]{lb: 1 sz:
1}, 4, 0, D.3913);

where ro.xi.jq is a COMPONENT_REF, but ro.xi is of type "struct bl[3]".

The analyzer's handling of COMPONENT_REF assumes that the type of the
1st argument is a RECORD_TYPE or UNION_TYPE, whereas in this case it's
an ARRAY_TYPE, leading to a failed as_a inside
region_model::get_field_region.

This patch fixes the ICE by generalizing the "give up on this tree code"
logic from r10-6667-gf76a88ebf089871dcce215aa0cb1956ccc060895 for
PR analyzer/93388, so that the analyzer gives up when it needs to get an
lvalue for a COMPONENT_REF on something other than a RECORD_TYPE or
UNION_TYPE.

gcc/analyzer/ChangeLog:
PR analyzer/93778
* engine.cc (impl_region_model_context::on_unknown_tree_code):
Rename to...
(impl_region_model_context::on_unexpected_tree_code): ...this and
convert first argument from path_var to tree.
(exploded_node::on_stmt): Pass ctxt to purge_for_unknown_fncall.
* exploded-graph.h (region_model_context::on_unknown_tree_code):
Rename to...
(region_model_context::on_unexpected_tree_code): ...this and
convert first argument from path_var to tree.
* program-state.cc (sm_state_map::purge_for_unknown_fncall): Add
ctxt param and pass on to calls to get_rvalue.
* program-state.h (sm_state_map::purge_for_unknown_fncall): Add
ctxt param.
* region-model.cc (region_model::handle_unrecognized_call): Pass
ctxt on to call to get_rvalue.
(region_model::get_lvalue_1): Move body of default case to
region_model::make_region_for_unexpected_tree_code and call it.
Within COMPONENT_REF case, reject attempts to handle types other
than RECORD_TYPE and UNION_TYPE.
(region_model::make_region_for_unexpected_tree_code): New
function, based on default case of region_model::get_lvalue_1.
* region-model.h
(region_model::make_region_for_unexpected_tree_code): New decl.
(region_model::on_unknown_tree_code): Rename to...
(region_model::on_unexpected_tree_code): ...this and convert first
argument from path_var to tree.
(class test_region_model_context): Update vfunc implementation for
above change.

gcc/testsuite/ChangeLog:
PR analyzer/93778
* gfortran.dg/analyzer/pr93778.f90: New test.

[Bug analyzer/93778] ICE in get_region, at analyzer/region-model.h:1732

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:2e6233935c77b56a68e939c629702f960b8e6fb2

commit r10-6695-g2e6233935c77b56a68e939c629702f960b8e6fb2
Author: David Malcolm 
Date:   Mon Feb 17 16:43:46 2020 -0500

analyzer: fix ICE on COMPONENT_REF of ARRAY_TYPE [PR 93778]

PR analyzer/93778 reports an ICE with -fanalyzer on a gfortran test case
at this gimple stmt:

  _gfortran_st_set_nml_var (&dt_parm.0, &ro.xi.jq, &"ro%xi%jq"[1]{lb: 1 sz:
1}, 4, 0, D.3913);

where ro.xi.jq is a COMPONENT_REF, but ro.xi is of type "struct bl[3]".

The analyzer's handling of COMPONENT_REF assumes that the type of the
1st argument is a RECORD_TYPE or UNION_TYPE, whereas in this case it's
an ARRAY_TYPE, leading to a failed as_a inside
region_model::get_field_region.

This patch fixes the ICE by generalizing the "give up on this tree code"
logic from r10-6667-gf76a88ebf089871dcce215aa0cb1956ccc060895 for
PR analyzer/93388, so that the analyzer gives up when it needs to get an
lvalue for a COMPONENT_REF on something other than a RECORD_TYPE or
UNION_TYPE.

gcc/analyzer/ChangeLog:
PR analyzer/93778
* engine.cc (impl_region_model_context::on_unknown_tree_code):
Rename to...
(impl_region_model_context::on_unexpected_tree_code): ...this and
convert first argument from path_var to tree.
(exploded_node::on_stmt): Pass ctxt to purge_for_unknown_fncall.
* exploded-graph.h (region_model_context::on_unknown_tree_code):
Rename to...
(region_model_context::on_unexpected_tree_code): ...this and
convert first argument from path_var to tree.
* program-state.cc (sm_state_map::purge_for_unknown_fncall): Add
ctxt param and pass on to calls to get_rvalue.
* program-state.h (sm_state_map::purge_for_unknown_fncall): Add
ctxt param.
* region-model.cc (region_model::handle_unrecognized_call): Pass
ctxt on to call to get_rvalue.
(region_model::get_lvalue_1): Move body of default case to
region_model::make_region_for_unexpected_tree_code and call it.
Within COMPONENT_REF case, reject attempts to handle types other
than RECORD_TYPE and UNION_TYPE.
(region_model::make_region_for_unexpected_tree_code): New
function, based on default case of region_model::get_lvalue_1.
* region-model.h
(region_model::make_region_for_unexpected_tree_code): New decl.
(region_model::on_unknown_tree_code): Rename to...
(region_model::on_unexpected_tree_code): ...this and convert first
argument from path_var to tree.
(class test_region_model_context): Update vfunc implementation for
above change.

gcc/testsuite/ChangeLog:
PR analyzer/93778
* gfortran.dg/analyzer/pr93778.f90: New test.

[Bug analyzer/93777] ICE in maybe_cast_1, at analyzer/region-model.cc:5064

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r10-6696-g4f40164a9322105012e9070eebd57ba80c69b873
Author: David Malcolm 
Date:   Mon Feb 17 17:37:52 2020 -0500

analyzer: fix ICE on failed casts [PR 93777]

PR analyzer/93777 reports ICEs in a Fortran and C++ case involving
a cast of a NULL pointer to a REFERENCE_TYPE.

In both cases the call to build_cast fails and returns a NULL type, but
region_model::maybe_cast_1 asserts that a non-NULL type was returned.

This patch fixes the ICEs by converting the assertion to a conditional.

gcc/analyzer/ChangeLog:
PR analyzer/93777
* region-model.cc (region_model::maybe_cast_1): Replace assertion
that build_cast returns non-NULL with a conditional, falling
through to the logic which returns a new unknown value of the
desired type if it fails.

gcc/testsuite/ChangeLog:
PR analyzer/93777
* g++.dg/analyzer/pr93777.C: New test.
* gfortran.dg/analyzer/pr93777.f90: New test.

[Bug analyzer/93692] Possible typo: supergraph vs. callgraph

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:0b2b45a68f48817e2310b12db3e03e648d4d2005

commit r10-6697-g0b2b45a68f48817e2310b12db3e03e648d4d2005
Author: David Malcolm 
Date:   Tue Feb 18 06:06:31 2020 -0500

analyzer.opt: rewrite description of -fdump-analyzer-callgraph [PR 93692]

gcc/analyzer/ChangeLog:
PR analyzer/93692
* analyzer.opt (fdump-analyzer-callgraph): Rewrite description.

[Bug tree-optimization/92924] [10 regression] reproducible indirect call profile merging causes 80% slowdown in Firefox pref-reftest-singletons id-getter microbenchmarks

[cvs-commit at gcc dot gnu.org]

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

--- Comment #29 from CVS Commits  ---
The master branch has been updated by Martin Liska :

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

commit r10-6698-gea0b12523d0d9a9059b5173ce9653b92ddfb284f
Author: Martin Liska 
Date:   Tue Feb 18 14:28:22 2020 +0100

Introduce -fprofile-reproducibility and support it with TOP N.

PR ipa/92924
* common.opt: Add -fprofile-reproducibility.
* doc/invoke.texi: Document it.
* value-prof.c (dump_histogram_value):
Document and support behavior for counters[0]
being a negative value.
(get_nth_most_common_value): Handle negative
counters[0] in respect to flag_profile_reproducible.
PR ipa/92924
* libgcov-merge.c (merge_topn_values_set): Record
when a TOP N counter becomes invalid.  When merging
remove a smallest value if the space is needed.

[Bug tree-optimization/92924] [10 regression] reproducible indirect call profile merging causes 80% slowdown in Firefox pref-reftest-singletons id-getter microbenchmarks

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #30 from Martin Liška  ---
I hope it's fixed now.

[Bug analyzer/93692] Possible typo: supergraph vs. callgraph

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #6 from David Malcolm  ---
Should be fixed by the above patch.

[Bug analyzer/93777] ICE in maybe_cast_1, at analyzer/region-model.cc:5064

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

--- Comment #6 from David Malcolm  ---
Should be fixed by the above patch.

[Bug target/93598] Segfault when running libgomp.c/pr90811.c on PowerPC64le with nvptx offloading

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

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

--- Comment #1 from Tobias Burnus  ---
FIXED
Bisecting shows that it has been fixed by
  commit r10-6532-g9bc3b95dfefd37d860c5dc0004f8a53f6290fbb1
  Sun Feb 9 08:17:10 2020 +0100
  openmp: Optimize DECL_IN_CONSTANT_POOL vars in target regions

[Bug analyzer/93778] ICE in get_region, at analyzer/region-model.h:1732

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

--- Comment #5 from David Malcolm  ---
Should be fixed by the above patch.

[Bug analyzer/93774] ICE in lhd_incomplete_type_error

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from David Malcolm  ---
Should be fixed by the above patch.

[Bug analyzer/93779] ICE: unhandled tree code in region_model::get_lvalue_1: 'function_decl'

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

--- Comment #6 from David Malcolm  ---
Test coverage added in the above patch.

[Bug ipa/93583] [10 Regression] bootstrap failure on powerpc64le-linux-gnu

[cvs-commit at gcc dot gnu.org]

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

--- Comment #18 from CVS Commits  ---
The master branch has been updated by Martin Liska :

https://gcc.gnu.org/g:33351ff9faa21c4c1af377d661a52ac0ce366db3

commit r10-6699-g33351ff9faa21c4c1af377d661a52ac0ce366db3
Author: Martin Liska 
Date:   Tue Feb 18 14:39:41 2020 +0100

Drop MALLOC attribute for void functions.

PR ipa/93583
* cgraph.c (cgraph_node::verify_node): Verify MALLOC attribute
and return type of functions.
* ipa-param-manipulation.c (ipa_param_adjustments::adjust_decl):
Drop MALLOC attribute for void functions.
* ipa-pure-const.c (funct_state_summary_t::duplicate): Drop
malloc_state for a new VOID clone.
PR ipa/93583
* gcc.dg/ipa/pr93583.c: New test.

[Bug analyzer/93773] Analyzer probably fails to recognize end of C macros in some cases

[dmalcolm at gcc dot gnu.org]

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

--- Comment #3 from David Malcolm  ---
I'm still working on reproducing this.

Looking at the stderr from attachment 47857, this seems reminiscent of

g:b4f3232d6979022a36b4055d7d3aaba693a39938 (PR c++/70105 and PR c/68473)

and also g:876217ae71cf0b34490f8f53bb2a12d99d8baa7a (PR other/69554)

[Bug ipa/93583] [10 Regression] bootstrap failure on powerpc64le-linux-gnu

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #19 from Martin Liška  ---
Fixed.

[Bug ipa/93203] [10 Regression] ICE in decide_about_value, at ipa-cp.c:5448 since r278893

[jamborm at gcc dot gnu.org]

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

Martin Jambor  changed:

   What|Removed |Added

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

--- Comment #5 from Martin Jambor  ---
This has been fixed with the aforementioned patches.

[Bug fortran/92587] Compiler is unable to generate finalization wrapper

[marxin at gcc dot gnu.org]

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

--- Comment #9 from Martin Liška  ---
Created attachment 47867
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47867&action=edit
Reduced test-case

[Bug fortran/92587] [9/10 Regression] Compiler is unable to generate finalization wrapper

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||janus at gcc dot gnu.org
  Known to work||7.4.0
   Target Milestone|--- |9.3
Summary|Compiler is unable to   |[9/10 Regression] Compiler
   |generate finalization   |is unable to generate
   |wrapper |finalization wrapper
  Known to fail||10.0, 9.2.0

--- Comment #10 from Martin Liška  ---
The reduced test-case started with to ICE with r9-2925-g74b08343dab5369d

$ gcc tensor_recursive.F90 -c
f951: internal compiler error: in generate_finalization_wrapper, at
fortran/class.c:2009
0x5f4619 generate_finalization_wrapper
/home/marxin/Programming/gcc/gcc/fortran/class.c:2009
0x5f4619 gfc_find_derived_vtab(gfc_symbol*)
/home/marxin/Programming/gcc/gcc/fortran/class.c:2487
0x7e8f75 finalize_component
/home/marxin/Programming/gcc/gcc/fortran/class.c:1015
0x7e7b15 generate_finalization_wrapper
/home/marxin/Programming/gcc/gcc/fortran/class.c:2164
0x7e7b15 gfc_find_derived_vtab(gfc_symbol*)
/home/marxin/Programming/gcc/gcc/fortran/class.c:2487
0x7e568e gfc_find_derived_vtab(gfc_symbol*)
/home/marxin/Programming/gcc/gcc/fortran/class.c:2359
0x83c7c2 gfc_match_assignment()
/home/marxin/Programming/gcc/gcc/fortran/match.c:1375
0x861f82 match_word
/home/marxin/Programming/gcc/gcc/fortran/parse.c:65
0x861f82 decode_statement
/home/marxin/Programming/gcc/gcc/fortran/parse.c:361
0x867ac4 next_free
/home/marxin/Programming/gcc/gcc/fortran/parse.c:1279
0x867ac4 next_statement
/home/marxin/Programming/gcc/gcc/fortran/parse.c:1511
0x86c185 parse_executable
/home/marxin/Programming/gcc/gcc/fortran/parse.c:5425
0x86b6a9 parse_if_block
/home/marxin/Programming/gcc/gcc/fortran/parse.c:4136
0x86b6a9 parse_executable
/home/marxin/Programming/gcc/gcc/fortran/parse.c:5483
0x86b6a9 parse_if_block
/home/marxin/Programming/gcc/gcc/fortran/parse.c:4136
0x86b6a9 parse_executable
/home/marxin/Programming/gcc/gcc/fortran/parse.c:5483
0x86c3b6 parse_progunit
/home/marxin/Programming/gcc/gcc/fortran/parse.c:5877
0x86c852 parse_contained
/home/marxin/Programming/gcc/gcc/fortran/parse.c:5752
0x86d5be parse_module
/home/marxin/Programming/gcc/gcc/fortran/parse.c:6125
0x86db04 gfc_parse_file()
/home/marxin/Programming/gcc/gcc/fortran/parse.c:6428
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug ipa/92518] [10 regression] ppc rounding tests fail after r278207

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #11 from Martin Liška  ---
Fixed.

[Bug ipa/92518] [10 regression] ppc rounding tests fail after r278207

[cvs-commit at gcc dot gnu.org]

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

--- Comment #10 from CVS Commits  ---
The master branch has been updated by Martin Liska :

https://gcc.gnu.org/g:08afe87b7976e93197a66e01f93191ead496ad42

commit r10-6700-g08afe87b7976e93197a66e01f93191ead496ad42
Author: Martin Liska 
Date:   Tue Feb 18 15:07:06 2020 +0100

Always compare types of LHS for gimple_assign in ICF.

PR ipa/92518
* ipa-icf-gimple.c (func_checker::compare_gimple_assign):
Always compare LHS of gimple_assign.

[Bug gcov-profile/93401] [9/10 regression] It is no longer possible to use -fprofile-generate= on setups with different instrumentation and feedback directories

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

URL|https://gcc.gnu.org/ml/gcc- |
   |patches/2020-02/msg00186.ht |
   |ml  |
   Assignee|marxin at gcc dot gnu.org  |hubicka at gcc dot 
gnu.org

--- Comment #11 from Martin Liška  ---
Honza has a patch candidate for it. He's going to send it.

[Bug fortran/92587] [9/10 Regression] Compiler is unable to generate finalization wrapper

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P4

[Bug fortran/93601] [10 Regression] ICE: Invalid expression in gfc_element_size

[cvs-commit at gcc dot gnu.org]

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Mark Eggleston
:

https://gcc.gnu.org/g:23d3f25c87d307536f7e0f15e211968a87657602

commit r10-6701-g23d3f25c87d307536f7e0f15e211968a87657602
Author: Mark Eggleston 
Date:   Tue Feb 18 14:15:41 2020 +

[Fortran] ICE: Invalid expression in gfc_element_size PR93601

ICE occurs when assigning a BOZ constant to an class(*) variable
with the allocatable attribute. Use of BOZ constants outside
data statements and int/real/dble/cmplx intrinsics is not allowed.

Original patch provided by Steven G. Kargl  .

gcc/fortran/ChangeLog

PR fortran/93601
* match.c (gfc_match_assignment) : Reject assignment if
the lhs stype is BT_CLASS and the rhs type is BT_BOZ.

gcc/testsuite/ChangeLog

PR fortran/93601
* gfortran.dg/pr93601.f90 : New test.

[Bug fortran/93601] [10 Regression] ICE: Invalid expression in gfc_element_size

[markeggleston at gcc dot gnu.org]

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

markeggleston at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #3 from markeggleston at gcc dot gnu.org ---
Committed.

[Bug ipa/93799] [10 Regression] ice in propagate_vals_across_arith_jfunc, at ipa-cp.c:2039

[fxue at gcc dot gnu.org]

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

--- Comment #2 from fxue at gcc dot gnu.org ---
Duplicate of pr93763

[Bug c++/93801] False -Wmismatched-tags upon redundant typename

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-02-18
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

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

[Bug lto/91724] [8 Regression] profiled lto bootstrap fails on arm-linux-gnueabihf

[clyon at gcc dot gnu.org]

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

--- Comment #4 from Christophe Lyon  ---
It worked for me with gcc-8-branch at
g:9eba9635f653291804ecb832eebe1ed96e3346ba

Using:
../gcc/configure --with-arch=armv7-a --with-fpu=vfpv3-d16 --with-float=hard
--with-mode=thumb --with-build-config=bootstrap-lto
make profiledbootstrap -j50

but that's on a armv8 processor.

[Bug fortran/93787] Rejects non-ambigous specific in generic –

[burnus at gcc dot gnu.org]

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

--- Comment #2 from Tobias Burnus  ---
Note: Once this bug is fixed, libgomp/openacc_lib.h shall be updated as the
'async_' name is user visible and wrong.

[Bug rtl-optimization/88751] Performance regression reload vs lra

[sbabneet at ca dot ibm.com]

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

--- Comment #10 from Babneet Singh  ---
Confirming that this fix resolves the reported regression in all OpenJ9 builds.

[Bug lto/91724] [8 Regression] profiled lto bootstrap fails on arm-linux-gnueabihf

[doko at ubuntu dot com]

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

Matthias Klose  changed:

   What|Removed |Added

 CC||doko at ubuntu dot com

--- Comment #5 from Matthias Klose  ---
I've started a new build with today's git branch.

This is again a compiler configured with --enable-default-pie, and other
hardening flags turned on by default:

/usr/lib/gcc/arm-linux-gnueabihf/8/cc1 -quiet -v -imultiarch
arm-linux-gnueabihf foo.c -quiet -dumpbase foo.c -mfloat-abi=hard
-mfpu=vfpv3-d16 -mthumb -mtls-dialect=gnu -march=armv7-a+fp -auxbase foo
-version -fstack-protector-strong -Wformat -Wformat-security

[Bug c++/93803] New: ICE: segmentation fault with constant initialization of class having a [[no_unique_address]] field

[ppalka at gcc dot gnu.org]

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

Bug ID: 93803
   Summary: ICE: segmentation fault with constant initialization
of class having a [[no_unique_address]] field
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ppalka at gcc dot gnu.org
  Target Milestone: ---

$ cat blah.cc
struct empty { };

struct foo
{
  [[no_unique_address]] empty x;

  constexpr
  foo() : x{}
  { }
};

struct bar : foo
{
  using foo::foo;
};

constexpr bar a{};
$ g++-9 -fsyntax-only -std=c++2a blah.cc
$ g++-10 -fsyntax-only -std=c++2a blah.cc
blah.cc:17:17: internal compiler error: Segmentation fault
   17 | constexpr bar a{};
  | ^

This seems to be a regression from GCC 9.

[RFC] c++/93730 create VLA constructor if explicitly initialized as zeroes

[Slava Barinov]

* cp/decl.c (reshape_init_array_1): Enforce constructor creation
for VLAs when initialized with zero value.
* testsuite/g++.dg/pr93730.C: New test
* testsuite/g++.dg/abi/mangle72.C: Change mangling to new version

I'm not sure about fix of c++/58646 but this allows to work around certain case
when we want to initialize VLA with zeroes.

Bootstrapped on x86_64, no testsuite regressions found.

Not sure about mangling: is there any ABI requirements to mangling for cases
from mangle72.C?

Signed-off-by: Slava Barinov 
---
 gcc/ChangeLog   |  8 
 gcc/cp/decl.c   |  3 ++-
 gcc/testsuite/g++.dg/abi/mangle72.C | 14 +++---
 gcc/testsuite/g++.dg/pr93730.C  |  8 
 4 files changed, 25 insertions(+), 8 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/pr93730.C

diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 7c481407de9..e614552a1a5 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,11 @@
+2020-02-18  Vyacheslav Barinov  
+
+   PR c++/93730
+   * cp/decl.c (reshape_init_array_1): Enforce constructor creation
+   for VLAs when initialized with zero value.
+   * testsuite/g++.dg/pr93730.C: New test
+   * testsuite/g++.dg/abi/mangle72.C: Change mangling to new version
+
 2020-02-17  Richard Biener  

PR c/86134
diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
index 31a556a0a1f..e90a397fc11 100644
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -6043,7 +6043,8 @@ reshape_init_array_1 (tree elt_type, tree max_index, 
reshape_iter *d,
 even if the string is empty.  */
   tree init_type = TREE_TYPE (elt_init);
   if (POINTER_TYPE_P (elt_type) != POINTER_TYPE_P (init_type)
- || !type_initializer_zero_p (elt_type, elt_init))
+ || !type_initializer_zero_p (elt_type, elt_init)
+ || sized_array_p)
last_nonzero = index;

   /* This can happen with an invalid initializer (c++/54501).  */
diff --git a/gcc/testsuite/g++.dg/abi/mangle72.C 
b/gcc/testsuite/g++.dg/abi/mangle72.C
index 656a0cae403..928a38da021 100644
--- a/gcc/testsuite/g++.dg/abi/mangle72.C
+++ b/gcc/testsuite/g++.dg/abi/mangle72.C
@@ -27,16 +27,16 @@ void g__ (Y) { }
 // { dg-final { scan-assembler "_Z3g__1YIXtl1BtlA2_M1AA2_iLS3_0E" } }

 void g0_ (Y) { }
-// { dg-final { scan-assembler "_Z3g0_1YIXtl1BtlA2_M1AA2_iLS3_0E" } }
+// { dg-final { scan-assembler "_Z3g0_1YIXtl1BtlA2_M1AA2_iLS3_0ELS3_0E" } }

 void g00 (Y) { }
-// { dg-final { scan-assembler "_Z3g001YIXtl1BtlA2_M1AA2_iLS3_0E" } }
+// { dg-final { scan-assembler "_Z3g001YIXtl1BtlA2_M1AA2_iLS3_0ELS3_0E" } }

 void g0x (Y) { }
 // FIXME: This needs to mangle differently from g00.  The space at
 // the end is intentional to make the directive fail so that the xfail
 // can be reminder to change this once the mangling is fixed.
-// { dg-final { scan-assembler "_Z3g0x1YIXtl1BtlA2_M1AA2_iLS3_0E " { xfail 
*-*-* } } }
+// { dg-final { scan-assembler "_Z3g0x1YIXtl1BtlA2_M1AA2_iLS3_0ELS3_0E " { 
xfail *-*-* } } }

 void gx_ (Y) { }
 // { dg-final { scan-assembler "_Z3gx_1YIXtl1BtlA2_M1AA2_iLS3_0ELS3_0E" } }
@@ -49,17 +49,17 @@ void h___ (Z) { }
 // { dg-final { scan-assembler "_Z4h___1ZIXtl1CtlA3_M1AA2_iLS3_0E" } }

 void h0__ (Z) { }
-// { dg-final { scan-assembler "_Z4h0__1ZIXtl1CtlA3_M1AA2_iLS3_0E" } }
+// { dg-final { scan-assembler "_Z4h0__1ZIXtl1CtlA3_M1AA2_iLS3_0ELS3_0E" } 
}

 void h00_ (Z) { }
-// { dg-final { scan-assembler "_Z4h00_1ZIXtl1CtlA3_M1AA2_iLS3_0E" } }
+// { dg-final { scan-assembler 
"_Z4h00_1ZIXtl1CtlA3_M1AA2_iLS3_0ELS3_0ELS3_0E" } }

 void h000 (Z) { }
-// { dg-final { scan-assembler "_Z4h0001ZIXtl1CtlA3_M1AA2_iLS3_0E" } }
+// { dg-final { scan-assembler 
"_Z4h0001ZIXtl1CtlA3_M1AA2_iLS3_0ELS3_0ELS3_0E" } }

 void h00x (Z) { }
 // FIXME: This needs to mangle differently from hx0_ and hx__.
-// { dg-final { scan-assembler "_Z4h00x1ZIXtl1CtlA3_M1AA2_iLS3_0ELS3_0E " 
{ xfail *-*-*} } }
+// { dg-final { scan-assembler 
"_Z4h00x1ZIXtl1CtlA3_M1AA2_iLS3_0ELS3_0ELS3_0E " { xfail *-*-*} } }

 void h0x0 (Z) { }
 // { dg-final { scan-assembler 
"_Z4h0x01ZIXtl1CtlA3_M1AA2_iLS3_0ELS3_0ELS3_0E" } }
diff --git a/gcc/testsuite/g++.dg/pr93730.C b/gcc/testsuite/g++.dg/pr93730.C
new file mode 100644
index 000..066c23a99cb
--- /dev/null
+++ b/gcc/testsuite/g++.dg/pr93730.C
@@ -0,0 +1,8 @@
+/* { dg-do compile } */
+/* { dg-additional-options "-Wno-vla" } */
+
+int sz = 1;
+
+void f() {
+  int arr[1][sz] = { 0 };
+}
--
2.25.0

[Bug middle-end/93582] [10 Regression] -Warray-bounds gives error: array subscript 0 is outside array bounds of struct E[1]

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

  Attachment #47863|0   |1
is obsolete||

--- Comment #28 from Jakub Jelinek  ---
Created attachment 47868
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47868&action=edit
gcc10-pr93582-2.patch

Updated patch that at least on the included testcases also handles big-endian.
Not really sure how much of the further code can be outlined and moved, e.g.
the full def and partial def code doesn't have pretty much anything in common
(the partial defs case basically have some load bit range and a set of store
bit ranges that at least partially overlap and we need to handle all the
different cases, like negative pd.offset or non-negative, little vs. bit
endian, size so small that we need to preserve original bits on both sides of
the byte, size that fits or is too large...
Yes, I've thought about trying to do everything in place, but the code is quite
hard to understand and get right already now and if we tried to do the optimize
on the fly, it would need more special cases and would for gcov coverage need
more testcases to cover it.  Most of the time the sizes will be small.
Perhaps we could have just a fast path for the case where everything is byte
aligned and (for integral types the mode bitsize is equal to the size too)?

Anyway, tested it last night on x86_64-linux/i686-linux (the patch from
yesterday with a two-liner fix), where it triggered (for something where we'd
punt before) 5266 times during the bootstraps/regtests, in 421 unique
TU/function_name pairs.  Will now bootstrap/regtest it on powerpc64{,le}-linux.

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

[vmakarov at gcc dot gnu.org]

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

--- Comment #4 from Vladimir Makarov  ---
> Miscompilation occurs in same configuration: arm-linux-gnueabihf at -O2
> -flto.
> 

I don't see how these two patches *directly* resulted in miscompilation. 
Although it might trigger some latent bug.


> I'll try to narrow this down to a single object.

Thank you, Maxim.  Unfortunately I have no arm machine with spec2006 to
reproduce it by myself. You help here would be much appreciated.

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

[rearnsha at gcc dot gnu.org]

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

--- Comment #5 from Richard Earnshaw  ---
(In reply to Vladimir Makarov from comment #4)
> > Miscompilation occurs in same configuration: arm-linux-gnueabihf at -O2
> > -flto.
> > 
> 
> I don't see how these two patches *directly* resulted in miscompilation. 
> Although it might trigger some latent bug.
> 
> 
> > I'll try to narrow this down to a single object.
> 
> Thank you, Maxim.  Unfortunately I have no arm machine with spec2006 to
> reproduce it by myself. You help here would be much appreciated.

While I don't see a 1% regression, I did notice a measurable code size increase
when building CSiBE for thumb-2 and -Os.  It's hard to put my finger on what is
causing this, beyond the fact that the compiler is making more use of 'high'
registers and this results in using more 32-bit rather than 16-bit
instructions.

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

[rearnsha at gcc dot gnu.org]

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

--- Comment #6 from Richard Earnshaw  ---
(In reply to Richard Earnshaw from comment #5)
> (In reply to Vladimir Makarov from comment #4)
> > > Miscompilation occurs in same configuration: arm-linux-gnueabihf at -O2
> > > -flto.
> > > 
> > 
> > I don't see how these two patches *directly* resulted in miscompilation. 
> > Although it might trigger some latent bug.
> > 
> > 
> > > I'll try to narrow this down to a single object.
> > 
> > Thank you, Maxim.  Unfortunately I have no arm machine with spec2006 to
> > reproduce it by myself. You help here would be much appreciated.
> 
> While I don't see a 1% regression, I did notice a measurable code size
> increase when building CSiBE for thumb-2 and -Os.  It's hard to put my
> finger on what is causing this, beyond the fact that the compiler is making
> more use of 'high' registers and this results in using more 32-bit rather
> than 16-bit instructions.

Err, ignore that.  Wrong bug.

[Bug fortran/93714] [8/9/10 Regression] ICE in gfc_check_same_strlen, at fortran/check.c:1253

[cvs-commit at gcc dot gnu.org]

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Mark Eggleston
:

https://gcc.gnu.org/g:06119d691e27e25fd4f4486467ad95f7b545fde3

commit r10-6703-g06119d691e27e25fd4f4486467ad95f7b545fde3
Author: Mark Eggleston 
Date:   Tue Feb 18 15:54:13 2020 +

[fortran] ICE assign character pointer to non target PR93714

An ICE occurred if an attempt was made to assign a pointer to a
character variable that has an length incorrectly specified using
a real constant and does not have the target attribute.

gcc/fortran/ChangeLog

PR fortran/93714
* expr.c (gfc_check_pointer_assign): Move check for
matching character length to after checking the lvalue
attributes for target or pointer.

gcc/testsuite/ChangeLog

PR fortran/93714
* gfortran.dg/char_pointer_assign_6.f90: Look for no target
message instead of length mismatch.
* gfortran.dg/pr93714_1.f90
* gfortran.dg/pr93714_2.f90

[Bug c++/93804] New: exempt extern "C" headers from -Wredundant-tags

[msebor at gcc dot gnu.org]

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

Bug ID: 93804
   Summary: exempt extern "C" headers from -Wredundant-tags
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

As noted in https://gcc.gnu.org/ml/gcc-patches/2020-02/msg01016.html, 
-Wredundant-tags is not useful for declarations in shared C/C++ headers that
cannot be changed to drop the tag.  For example:

$ cat t.C && gcc -S -Wredundant-tags -Wsystem-headers t.C
#include 

In file included from /usr/include/bits/time.h:73,
 from /usr/include/time.h:33,
 from t.C:1:
/usr/include/bits/timex.h:37:3: warning: redundant class-key ‘struct’ in
reference to ‘struct timeval’ [-Wredundant-tags]
   37 |   struct timeval time;  /* (read only, except for ADJ_SETOFFSET) */
  |   ^~
  |   --
In file included from /usr/include/time.h:33,
 from t.C:1:
/usr/include/bits/time.h:78:51: warning: redundant class-key ‘struct’ in
reference to ‘struct timex’ [-Wredundant-tags]
   78 | extern int clock_adjtime (__clockid_t __clock_id, struct timex *__utx)
__THROW;
  |   ^~
  |   --
In file included from /usr/include/time.h:48,
 from t.C:1:
/usr/include/bits/types/struct_itimerspec.h:10:5: warning: redundant class-key
‘struct’ in reference to ‘struct timespec’ [-Wredundant-tags]
   10 | struct timespec it_interval;
  | ^~
  | --
/usr/include/bits/types/struct_itimerspec.h:11:5: warning: redundant class-key
‘struct’ in reference to ‘struct timespec’ [-Wredundant-tags]
   11 | struct timespec it_value;
  | ^~
  | --
...

[Bug c++/93805] New: [8/9/10 Regression] A suspicious -Werror=noexcept warning since r8-2461-g9fb82e652cee118b

[marxin at gcc dot gnu.org]

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

Bug ID: 93805
   Summary: [8/9/10 Regression] A suspicious -Werror=noexcept
warning since r8-2461-g9fb82e652cee118b
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
  Target Milestone: ---

Since the revision I see quite a suspicious warning:

$ cat rast.ii
template  class A {
public:
  int m_fn1(T);
};
struct B {
  B() {}
};
class C {
  struct D {
B extents = B();
  };
  A reflection_probe_owner;
  int m_fn2();
};
int C::m_fn2() { return reflection_probe_owner.m_fn1(D()); }

$ g++ rast.ii -c -Werror=noexcept
rast.ii: In member function ‘int C::m_fn2()’:
rast.ii:15:56: error: noexcept-expression evaluates to ‘false’ because of a
call to ‘B::B()’ [-Werror=noexcept]
   15 | int C::m_fn2() { return reflection_probe_owner.m_fn1(D()); }
  |^
rast.ii:6:3: error: but ‘B::B()’ does not throw; perhaps it should be declared
‘noexcept’ [-Werror=noexcept]
6 |   B() {}
  |   ^
cc1plus: some warnings being treated as errors

[Bug c++/93805] [8/9/10 Regression] A suspicious -Werror=noexcept warning since r8-2461-g9fb82e652cee118b

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-02-18
 CC||jason at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug tree-optimization/93667] [10 regression] ICE in esra with nested [[no_unique_address]] field

[jamborm at gcc dot gnu.org]

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

--- Comment #6 from Martin Jambor  ---
I proposed a fix on the mailing list: 

https://gcc.gnu.org/ml/gcc-patches/2020-02/msg01053.html

[Bug tree-optimization/93776] [10 Regression] ICE in verify_sra_access_forest, at tree-sra.c:2326

[jamborm at gcc dot gnu.org]

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

--- Comment #4 from Martin Jambor  ---
I proposed a fix on the mailing list:

https://gcc.gnu.org/ml/gcc-patches/2020-02/msg01054.html

[Bug c++/93801] False -Wmismatched-tags upon redundant typename

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

[Bug lto/91724] [8 Regression] profiled lto bootstrap fails on arm-linux-gnueabihf

[clyon at gcc dot gnu.org]

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

--- Comment #6 from Christophe Lyon  ---
I added --enable-default-pie to my configure options, and it's still
successful.

[Bug middle-end/93806] New: Wrong optimization: instability of floating-point results with -funsafe-math-optimizations leads to nonsense

[ch3root at openwall dot com]

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

Bug ID: 93806
   Summary: Wrong optimization: instability of floating-point
results with -funsafe-math-optimizations leads to
nonsense
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ch3root at openwall dot com
  Target Milestone: ---

With -funsafe-math-optimizations, floating-point results are effectively
unstable, this instability can taint everything around and lead to nonsense.
(Similar to pr93681 and pr93682.)

Instability is not limited to FP numbers, it extends to integers too:

--
#include 

__attribute__((noipa)) // imagine it in a separate TU
static double opaque(double d) { return d; }

int main()
{
int x = opaque(1);
int a = 1 + opaque(0x1p-60) != x;

printf("a = %d\n", a);
if (x == 1) {
opaque(0);
if (a)
printf("a is 1\n");
}
}
--
$ gcc -std=c11 -pedantic -Wall -Wextra -funsafe-math-optimizations -O3 test.c
&& ./a.out
a = 0
a is 1
--
gcc x86-64 version: gcc (GCC) 10.0.1 20200218 (experimental)
--

[Bug middle-end/93806] Wrong optimization: instability of floating-point results with -funsafe-math-optimizations leads to nonsense

[ch3root at openwall dot com]

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

--- Comment #1 from Alexander Cherepanov  ---
And instability of integers then easily taints surrounding code:

--
#include 

__attribute__((noipa)) // imagine it in a separate TU
static double opaque(double d) { return d; }

int main()
{
int one = opaque(1);

int x = opaque(1);
int a = 1 + opaque(0x1p-60) == x;

printf("one = %d\n", one);

opaque(a);
if (one == a) {
opaque(0);
if (x == 1) {
opaque(0);
if (a == 0) {
opaque(0);
if (one == 0)
printf("one = %d\n", one);
}
}
}
}
--
$ gcc -std=c11 -pedantic -Wall -Wextra -funsafe-math-optimizations -O3 test.c
&& ./a.out
one = 1
one = 0
--
gcc x86-64 version: gcc (GCC) 10.0.1 20200218 (experimental)
--

[Bug c++/93807] New: -std=c++2a allows to omit out-of-class declaration in template class

[bobogu at atlas dot cz]

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

Bug ID: 93807
   Summary: -std=c++2a allows to omit out-of-class declaration in
template class
   Product: gcc
   Version: 9.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bobogu at atlas dot cz
  Target Milestone: ---

gcc -v:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib
--libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info
--with-pkgversion='Arch Linux 9.2.1+20200130-2'
--with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++,d --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 --enable-multilib
--disable-werror --enable-checking=release --enable-default-pie
--enable-default-ssp --enable-cet=auto gdc_include_dir=/usr/include/dlang/gdc
Thread model: posix
gcc version 9.2.1 20200130 (Arch Linux 9.2.1+20200130-2)

Command line:
gcc -lstdc++ -std=c++2a main.cpp

With -std=c++2a, gcc allows me to omit out-of-class declaration of a friend
member function in a template class:

// template 
// class Foo;
// template 
// constexpr bool operator==(T lhs, const Foo& rhs);

template 
class Foo {
public:
constexpr Foo(T k) : mK(k) {}

constexpr friend bool operator==(T lhs, const Foo& rhs);
private:
T mK;
};

template 
constexpr bool operator==(T lhs, const Foo& rhs) {
return lhs == rhs.mK;
}

int main() {
return 1 == Foo(1) ? 0 : 1;
}

This code compiles just fine and the binary returns 0, although I didn't find
anything in the C++20 standard that would allow us to omit the out-of-class
declaration. I would expect this code to work only if the first 4 lines were
uncommented.

The same behaviour was also reproduced on a gcc 9.1.0.

For reference, clang doesn't accept this code.

[Bug target/93808] New: [9 Regression] [SH] Ruby crashes with 'Illegal Instruction' when compiled with gcc-9

[glaubitz at physik dot fu-berlin.de]

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

Bug ID: 93808
   Summary: [9 Regression] [SH] Ruby crashes with 'Illegal
Instruction' when compiled with gcc-9
   Product: gcc
   Version: 9.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: glaubitz at physik dot fu-berlin.de
CC: gcc-bugzilla at mkarcher dot dialup.fu-berlin.de,
jrtc27 at jrtc27 dot com, kkojima at gcc dot gnu.org,
olegendo at gcc dot gnu.org
  Target Milestone: ---
Target: sh*-*-*

When compiling the ruby2.5 package on Debian/sh4 with gcc-9 instead of gcc-8,
the Ruby interpretor crashes with 'Illegal Instruction'.

root@tirpitz:..ruby2.5-ixXW4Q/ruby2.5-2.5.5> ./miniruby 
Illegal instruction
root@tirpitz:..ruby2.5-ixXW4Q/ruby2.5-2.5.5>

Printing the assembly with GDB shows that the IP seems to be pointing at data
instead of code(?):

(gdb) x/5i $pc
=> 0x5380c0 :   .word 0x
   0x5380c2 :   .word 0x0010
   0x5380c4 :   mov r14,r2
   0x5380c6 :   bra 0x538094 
   0x5380c8 :   add #-16,r2
(gdb)

I have not tested gcc-10 yet. Will do that now.

[Bug c++/93809] New: bogus error class tag used in naming union on typedef typename ::U U2

[msebor at gcc dot gnu.org]

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

Bug ID: 93809
   Summary: bogus error class tag used in naming union on typedef
typename ::U U2
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

While testing a fix for pr93801 I noticed that G++ rejects the last type
definition in the test case below.  The code looks valid to me and is accepted
by all other compilers I tried (Clang, ICC, and Visual C++).

$ cat t.C && gcc -S t.C
class C { };
enum E { };
struct S { };
union U { };

typedef typename ::C C2;
typedef typename ::E E2;
typedef typename ::S S2;
typedef typename ::U U2;   // error

t.C:9:20: error: ‘class’ tag used in naming ‘union U’ [-fpermissive]
9 | typedef typename ::U U2;   // error
  |^
t.C:4:7: note: ‘union U’ was previously declared here
4 | union U { };
  |   ^

[Bug target/93808] [9 Regression] [SH] Ruby crashes with 'Illegal Instruction' when compiled with gcc-9

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #1 from John Paul Adrian Glaubitz  ---
Log for a successful build with gcc-8:
https://buildd.debian.org/status/fetch.php?pkg=ruby2.5&arch=sh4&ver=2.5.5-4&stamp=1564498024&raw=0

Log for a failed build with gcc-9:
https://buildd.debian.org/status/fetch.php?pkg=ruby2.5&arch=sh4&ver=2.5.7-1&stamp=1571859355&raw=0

[Bug c++/93809] bogus error class tag used in naming union on typedef typename ::U U2

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||rejects-valid
  Known to fail||10.0, 4.5.3, 4.8.5, 4.9.4,
   ||5.4.0, 6.4.0, 7.3.0, 8.3.0,
   ||9.1.0

--- Comment #1 from Martin Sebor  ---
This has been rejected since at least G++ 4.5.