[Bug rtl-optimization/9723] With -Os optimization increases size if the loop contains array element access

[steven at gcc dot gnu.org]

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

Steven Bosscher  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #5 from Steven Bosscher  ---
For arm and ppc, trunk today at -Os produces smaller code than -O1 and -O2.

[Bug other/16996] [meta-bug] code size improvements

[steven at gcc dot gnu.org]

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

Bug 9723 Summary: With -Os optimization increases size if the loop contains 
array element access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=9723

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WORKSFORME

[Bug target/89602] New: Missing AVX512 intrinsics

[hjl.tools at gmail dot com]

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

Bug ID: 89602
   Summary: Missing AVX512 intrinsics
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: crazylht at gmail dot com
Blocks: 88918
  Target Milestone: ---
Target: i386,x86-64

The following AVX512 intrinsics are missing:

VMOVSS __m128 _mm_mask_load_ss(__m128 s, __mmask8 k, float * p);
VMOVSS __m128 _mm_maskz_load_ss( __mmask8 k, float * p);
VMOVSS __m128 _mm_mask_move_ss(__m128 sh, __mmask8 k, __m128 sl, __m128 a);
VMOVSS __m128 _mm_maskz_move_ss( __mmask8 k, __m128 s, __m128 a);
VMOVSS void _mm_mask_store_ss(float * p, __mmask8 k, __m128 a);
VMOVSD __m128d _mm_mask_load_sd(__m128d s, __mmask8 k, double * p);
VMOVSD __m128d _mm_maskz_load_sd( __mmask8 k, double * p);
VMOVSD __m128d _mm_mask_move_sd(__m128d sh, __mmask8 k, __m128d sl, __m128d a);
VMOVSD __m128d _mm_maskz_move_sd( __mmask8 k, __m128d s, __m128d a);
VMOVSD void _mm_mask_store_sd(double * p, __mmask8 k, __m128d s);


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88918
[Bug 88918] [meta-bug] x86 intrinsic issues

[Bug fortran/89601] New: ICE: Segmentation fault (in resolve_component)

[asolokha at gmx dot com]

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

Bug ID: 89601
   Summary: ICE: Segmentation fault (in resolve_component)
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: ice-on-invalid-code
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

gfortran-9.0.0-alpha20190303 snapshot (r269357) ICEs when compiling the
following testcase:

program vw
  interface
 real function ul (ki)
   real :: ki
 end function ul
  end interface
  type :: q8 ()
 procedure (ul), pointer :: pj
  end type q8
  type (q8) :: ki
end program vw

% powerpc-e300c3-linux-gnu-gfortran-9.0.0-alpha20190303 -c ebntren1.f90
f951: internal compiler error: Segmentation fault
0xd9cad6 crash_signal
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20190303/work/gcc-9-20190303/gcc/toplev.c:326
0x81191f resolve_component
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20190303/work/gcc-9-20190303/gcc/fortran/resolve.c:13964
0x81191f resolve_component
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20190303/work/gcc-9-20190303/gcc/fortran/resolve.c:13817
0x812272 resolve_fl_derived0
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20190303/work/gcc-9-20190303/gcc/fortran/resolve.c:14314
0x8128bf resolve_fl_derived0
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20190303/work/gcc-9-20190303/gcc/fortran/resolve.c:14413
0x8128bf resolve_fl_derived
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20190303/work/gcc-9-20190303/gcc/fortran/resolve.c:14443
0x80f017 resolve_symbol
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20190303/work/gcc-9-20190303/gcc/fortran/resolve.c:14817
0x837dc2 do_traverse_symtree
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20190303/work/gcc-9-20190303/gcc/fortran/symbol.c:4156
0x81c165 resolve_types
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20190303/work/gcc-9-20190303/gcc/fortran/resolve.c:16729
0x80dfbe gfc_resolve(gfc_namespace*)
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20190303/work/gcc-9-20190303/gcc/fortran/resolve.c:16843
0x80dfbe gfc_resolve(gfc_namespace*)
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20190303/work/gcc-9-20190303/gcc/fortran/resolve.c:16824
0x7ffc76 resolve_all_program_units
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20190303/work/gcc-9-20190303/gcc/fortran/parse.c:6073
0x7ffc76 gfc_parse_file()
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20190303/work/gcc-9-20190303/gcc/fortran/parse.c:6323
0x84dd5e gfc_be_parse_file
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20190303/work/gcc-9-20190303/gcc/fortran/f95-lang.c:204

==24699== Invalid read of size 8
==24699==at 0x81191F: resolve_component (resolve.c:13964)
==24699==by 0x81191F: resolve_component(gfc_component*, gfc_symbol*)
(resolve.c:13817)
==24699==by 0x812272: resolve_fl_derived0(gfc_symbol*) [clone .part.54]
(resolve.c:14314)
==24699==by 0x8128BF: resolve_fl_derived0 (resolve.c:14413)
==24699==by 0x8128BF: resolve_fl_derived(gfc_symbol*) (resolve.c:14443)
==24699==by 0x80F017: resolve_symbol(gfc_symbol*) (resolve.c:14817)
==24699==by 0x837DC2: do_traverse_symtree(gfc_symtree*, void
(*)(gfc_symtree*), void (*)(gfc_symbol*)) (symbol.c:4156)
==24699==by 0x81C165: resolve_types(gfc_namespace*) (resolve.c:16729)
==24699==by 0x80DFBE: gfc_resolve (resolve.c:16843)
==24699==by 0x80DFBE: gfc_resolve(gfc_namespace*) (resolve.c:16824)
==24699==by 0x7FFC76: resolve_all_program_units (parse.c:6073)
==24699==by 0x7FFC76: gfc_parse_file() (parse.c:6323)
==24699==by 0x84DD5E: gfc_be_parse_file() (f95-lang.c:204)
==24699==by 0xD9CB6C: compile_file() (toplev.c:456)
==24699==by 0x764E83: do_compile (toplev.c:2204)
==24699==by 0x764E83: toplev::main(int, char**) (toplev.c:2339)
==24699==by 0x7673AD: main (main.c:39)
==24699==  Address 0x30 is not stack'd, malloc'd or (recently) free'd

(While my target here is powerpc, the ICE is not target-specific.)

[Bug go/89598] [9 Regression] go frontend fails to build against mpfr 2.4.2

[ian at airs dot com]

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

Ian Lance Taylor  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

--- Comment #5 from Ian Lance Taylor  ---
This time for sure.

[Bug go/89598] [9 Regression] go frontend fails to build against mpfr 2.4.2

[ian at gcc dot gnu.org]

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

--- Comment #4 from ian at gcc dot gnu.org  ---
Author: ian
Date: Wed Mar  6 05:02:16 2019
New Revision: 269411

URL: https://gcc.gnu.org/viewcvs?rev=269411=gcc=rev
Log:
PR go/89598
compiler: use GMP_RNDN rather than MPFR_RNDN

Missed one last time around.  This fixes the build with mpfr 2.4.2.

Fixes https://gcc.gnu.org/PR89598

Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/165420

Modified:
trunk/gcc/go/gofrontend/MERGE
trunk/gcc/go/gofrontend/expressions.cc

[Bug middle-end/88588] ICE in make_decl_rtl, at varasm.c:1329

[asolokha at gmx dot com]

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

--- Comment #2 from Arseny Solokha  ---
Obviously, #pragma can be replaced w/ __attribute__ ((simd)) which is supported
since gcc 6.

[Bug driver/87769] GCC build from source uses headers and libraries from directories host machine.

[mte.zych at gmail dot com]

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

--- Comment #8 from Mateusz Zych  ---
Created attachment 45901
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45901=edit
Script creating standalone GNU toolchain for C++.

[Bug driver/87769] GCC build from source uses headers and libraries from directories host machine.

[mte.zych at gmail dot com]

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

--- Comment #7 from Mateusz Zych  ---
Hi Joseph, ;)


Thank you very much for your advice - it was really helpful!
I've managed to implement a script creating standalone GNU toolchain for C++:

 - https://github.com/mtezych/cpp/blob/master/CreateToolchain.sh


However, I still have an issue with some configurations of triples.
For example,
the following cross-compiling configurations are building successfully:

   HOST   = x86_64-pc-linux-gnu
   TARGET = x86_64-glibc-linux-gnu

   HOST   = x86_64-linux-gnu
   TARGET = x86_64-glibc-linux-gnu

   HOST   = x86_64-pc-linux-gnu
   TARGET = x86_64-unknown-linux-gnu

   HOST   = x86_64-unknown-linux-gnu
   TARGET = x86_64-pc-linux-gnu

Even cross-compiling for x86 works:

   HOST   = x86_64-unknown-linux-gnu
   TARGET = i686-pc-linux-gnu

However, for some reason these configurations do not work:

   HOST   = x86_64-linux-gnu
   TARGET = x86_64-pc-linux-gnu

   HOST   = x86_64-pc-linux-gnu
   TARGET = x86_64-linux-gnu

Also, I cannot build an isolated compiler:

   HOST   = x86_64-linux-gnu
   TARGET = x86_64-linux-gnu

   HOST   = x86_64-pc-linux-gnu
   TARGET = x86_64-pc-linux-gnu

   HOST   = x86_64-unknown-linux-gnu
   TARGET = x86_64-unknown-linux-gnu

   HOST   = x86_64-glibc-linux-gnu
   TARGET = x86_64-glibc-linux-gnu


Can you explain to me what's the significance of a vendor in a triplet?
That is, what's the difference between these triplets?

 - x86_64-linux-gnu
 - x86_64-pc-linux-gnu
 - x86_64-none-linux-gnu
 - x86_64-glibc-linux-gnu
 - x86_64-unknown-linux-gnu

Maybe there is a piece of documentation, blog post or an article,
that you can point me to, which explains this?


Which triplet configuration I should use for a host and a target,
when I am using regular GNU/Linux distro (Ubuntu MATE 18.04 LTS)
and want to target wide range or GNU/Linux distros?

Are triples returned by these commands good values for triples?
 $ gcc -dumpmachine -> x86_64-linux-gnu
 $ make -v  -> x86_64-pc-linux-gnu


Thank you, Mateusz

[Bug tree-optimization/89478] missed optimization for lambda expression when variable is uninitialized when declared

[SztfG at yandex dot ru]

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

--- Comment #3 from SztfG at yandex dot ru ---
Another testcase:
int test4 = []() constexpr {int a = a; a = 5; return a;}();

GCC is able compile this, so it "think" this is valid constexpr lambda, but
anyway doing this:

_GLOBAL__sub_I_test4:
movl$5, test4(%rip)
ret
test4:
.zero   4

[Bug target/89411] RISC-V backend will generate wrong instruction for longlong type like lw a3,-2048(a5)

[wilson at gcc dot gnu.org]

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

Jim Wilson  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-03-06
 Ever confirmed|0   |1

--- Comment #3 from Jim Wilson  ---
In the caller, riscv_classify_address, we have the address which contains a
symbol.  We can get the VAR_DECL from the symbol.  We can then get size and
alignment from the symbol.  However, there is no guarantee that a decl is in
there, it depends on what kind of symbol this is.

In the aarch64/aarch64.c file, I see code similar to what we need, which among
the checks has this
  else if (SYMBOL_REF_DECL (sym))
align = DECL_ALIGN (SYMBOL_REF_DECL (sym));
There is simpler code in the mips/mips.c file in the
mips_offset_within_alignment_p function.

RISC-V is normally strict align, so it should still be safe to assume mode
alignment if strict align is on, if there is no SYMBOL_REF_DECL.

An even simpler solution, as I mentioned earlier, is just
  if (mode == BLKmode)
return false;
and that may give a result just as good as checking the SYMBOL_REF_DECL.

[Bug c++/89576] [8/9 Regression] constexpr not working if implicitly captured in a lambda in a function template (gcc 8.3+)

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug c++/86969] [8 Regression] ICE (in tsubst_copy) for a generic recursive lambda

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

Summary|[8/9 Regression] ICE (in|[8 Regression] ICE (in
   |tsubst_copy) for a generic  |tsubst_copy) for a generic
   |recursive lambda|recursive lambda

--- Comment #7 from Jason Merrill  ---
Fixed on trunk so far.

[Bug c++/86485] [7/8 Regression] "anonymous" maybe-uninitialized false positive with ternary operator

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |jason at gcc dot gnu.org
Summary|[7/8/9 Regression]  |[7/8 Regression]
   |"anonymous" |"anonymous"
   |maybe-uninitialized false   |maybe-uninitialized false
   |positive with ternary   |positive with ternary
   |operator|operator

--- Comment #5 from Jason Merrill  ---
Fixed on trunk so far.

[Bug libfortran/89593] warning "passing argument 3 of ‘_gfortran_caf_{get,send}_by_ref’ from incompatible pointer type" when building libgfortran

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug middle-end/20408] Unnecessary code generated for empty structs

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #21 from Jason Merrill  ---
Created attachment 45900
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45900=edit
fix

Patch waiting for stage 1.

[Bug libfortran/89593] warning "passing argument 3 of ‘_gfortran_caf_{get,send}_by_ref’ from incompatible pointer type" when building libgfortran

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Author: jakub
Date: Tue Mar  5 22:41:39 2019
New Revision: 269405

URL: https://gcc.gnu.org/viewcvs?rev=269405=gcc=rev
Log:
PR libgfortran/89593
* caf/single.c (_gfortran_caf_sendget_by_ref): Cast  to
gfc_descriptor_t * to avoid warning.

Modified:
trunk/libgfortran/ChangeLog
trunk/libgfortran/caf/single.c

[Bug target/88529] G++ clears the return register on x86_64 when returning an empty class

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #1 from Jason Merrill  ---
Created attachment 45899
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45899=edit
Fix

Here's a fix.  I'm not sure if it's suitable for GCC 9 or 10.

[Bug c/88568] [7/8/9 Regression] 'dllimport' no longer implies 'extern' in C

[10walls at gmail dot com]

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

--- Comment #16 from jon_y <10walls at gmail dot com> ---
I'll try testing over the weekends.

[Bug c++/86485] [7/8/9 Regression] "anonymous" maybe-uninitialized false positive with ternary operator

[jason at gcc dot gnu.org]

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

--- Comment #4 from Jason Merrill  ---
Author: jason
Date: Tue Mar  5 22:20:41 2019
New Revision: 269403

URL: https://gcc.gnu.org/viewcvs?rev=269403=gcc=rev
Log:
PR c++/86485 - -Wmaybe-unused with empty class ?:

The problem in this testcase is that the front end expects an rvalue
COND_EXPR to initialize a single temporary from one of the arms.  But
because gimplify_cond_expr used MODIFY_EXPR, instead the arms would each
create their own temporary and then copy that into the common temporary.

So, let's use INIT_EXPR instead.

* gimplify.c (gimplify_cond_expr): Use INIT_EXPR.

Added:
trunk/gcc/testsuite/g++.dg/init/empty2.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimplify.c

[Bug c++/89538] [8.3.0] GCC miscompiling LLVM because of wrong vectorization

[twoh at fb dot com]

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

Taewook Oh  changed:

   What|Removed |Added

Version|7.3.0   |8.3.0
Summary|[7.3.0] GCC miscompiling|[8.3.0] GCC miscompiling
   |LLVM because of wrong   |LLVM because of wrong
   |vectorization   |vectorization

--- Comment #7 from Taewook Oh  ---
I'm Sorry I was confused about our internal gcc version, and it turns out that
the version was 8.3 not 7.3.

I downloaded latest 8.3 source and tried it but couldn't repro the problem. Is
there a chance that the bug is fixed after the release? Our internal version
suggests that it is based on 8.3 around 20180827.

[Bug c++/29843] [meta-bug] C++98 standard conformance issues

[egallager at gcc dot gnu.org]

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

--- Comment #3 from Eric Gallager  ---
(In reply to Jonathan Wakely from comment #2)
> This doesn't seem a very useful meta-bug. Every bug with Component=c++ and
> Keywords=rejects-valid is a standard conformance issue.
> 
> What's the point of this one?

¯\_(ツ)_/¯

Feel free to close if non-useful.

[Bug translation/40883] [meta-bug] Translation breakage with trivial fixes

[egallager at gcc dot gnu.org]

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

--- Comment #3 from Eric Gallager  ---
(In reply to Roland Illig from comment #2)
> I don't know how to add these bugs to the "Depends on" field, therefore I'm
> listing them here. Could it be that a mere reporter cannot do this?
> 
> bug 79645
> bug 79646
> bug 79846
> bug 79858
> bug 79869
> bug 79870
> bug 79924
> bug 7
> bug 80003
> bug 80022
> bug 80058
> bug 80190
> bug 80192
> bug 84911
> bug 8
> bug 79477
> bug 79595
> bug 79618
> bug 79842
> bug 79871
> bug 80012
> bug 80188
> bug 85665
> bug 79926
> bug 79861

Looks like Jakub got them for you. Thanks, Jakub!

[Bug fortran/71203] ICE in add_init_expr_to_sym, at fortran/decl.c:1512 and :1564

[anlauf at gmx dot de]

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

--- Comment #9 from Harald Anlauf  ---
Patch submitted for the character-related issues:

https://gcc.gnu.org/ml/fortran/2019-03/msg00017.html

[Bug go/89598] [9 Regression] go frontend fails to build against mpfr 2.4.2

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
   Last reconfirmed||2019-03-05
 Resolution|FIXED   |---
 Ever confirmed|0   |1

--- Comment #3 from David Malcolm  ---
Sadly no, I still get:

../../../src/gcc/go/gofrontend/expressions.cc: In member function ‘unsigned int
Numeric_constant::hash(unsigned int) const’:
../../../src/gcc/go/gofrontend/expressions.cc:17295:51: error: ‘MPFR_RNDN’ was
not declared in this scope; did you mean ‘GMP_RNDN’?
17295 |   f = mpfr_get_d_2exp(, this->u_.float_val, MPFR_RNDN) *
4294967295.0;
  |   ^
  |   GMP_RNDN


I *think* that's the only remaining one.

[Bug c++/89571] [9 Regression] ICE in nothrow_spec_p, at cp/except.c:1238

[paolo.carlini at oracle dot com]

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

--- Comment #4 from Paolo Carlini  ---
Seriously, I spent quite a bit of time today on this issue and, all in all,
barring much more invasive changes, I think that not setting *spec_p to
error_mark_node when maybe_instantiate_noexcept returns false in
process_subob_fn makes for better error recovery. After all, in quite a few
places we don't even check the return value of maybe_instantiate_noexcept... If
nobody comes up with a better solution, in a few days I will send a message to
the mailing list.

[Bug go/89598] [9 Regression] go frontend fails to build against mpfr 2.4.2

[ian at airs dot com]

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

Ian Lance Taylor  changed:

   What|Removed |Added

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

--- Comment #2 from Ian Lance Taylor  ---
Fixed, I hope.

[Bug libobjc/89586] warning: cast between incompatible function types when building libobjc

[bernd.edlinger at hotmail dot de]

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

--- Comment #4 from Bernd Edlinger  ---
as long as IMP is not used to call the function
you could try to define IMP as "void (*)(void)",
that would reliably suppress the warning.

[Bug go/89598] [9 Regression] go frontend fails to build against mpfr 2.4.2

[ian at gcc dot gnu.org]

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

--- Comment #1 from ian at gcc dot gnu.org  ---
Author: ian
Date: Tue Mar  5 19:41:42 2019
New Revision: 269399

URL: https://gcc.gnu.org/viewcvs?rev=269399=gcc=rev
Log:
PR go/89598
compiler: use GMP_RNDN rather than MPFR_RNDN

This fixes the build with mpfr 2.4.2.

Fixes https://gcc.gnu.org/PR89598

Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/165418

Modified:
trunk/gcc/go/gofrontend/MERGE
trunk/gcc/go/gofrontend/expressions.cc

[Bug c++/89600] rejects-valid on dependent block-scope using declaration

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

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

[Bug c++/89600] New: rejects-valid on dependent block-scope using declaration

[richard-gccbugzilla at metafoo dot co.uk]

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

Bug ID: 89600
   Summary: rejects-valid on dependent block-scope using
declaration
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: richard-gccbugzilla at metafoo dot co.uk
  Target Milestone: ---

GCC rejects this valid code:

template T f() { using T::Bar; return Bar; }

As follows:

: In function 'T f()':
:2:39: error: 'T' is not a namespace or unscoped enum
2 | template T f() { using T::Bar; return Bar; }
  |   ^~~

... which is wrong; T could be an unscoped enumeration:

enum E { Bar };
E e = f();

[Bug c++/89585] GCC 8.3: asm volatile no longer accepted at file scope

[harald at gigawatt dot nl]

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

--- Comment #13 from Harald van Dijk  ---
(In reply to Andrew Pinski from comment #12)
> This is wrong too since some of what -fstrict-overflow did was enabled at
> -O1 (and -O2) before hand; just the option was added for GCC 4.2.0 and only
> enabled at -O2 and above.

Thanks, I stand corrected. The basic idea should still hold though, even if I
picked a bad example.

FWIW, I checked the current release of Qt 5, and just grepping the sources, I
still see file scope asm volatile in there.

[Bug c++/89585] GCC 8.3: asm volatile no longer accepted at file scope

[pinskia at gcc dot gnu.org]

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

--- Comment #12 from Andrew Pinski  ---
(In reply to Harald van Dijk from comment #11)
> 
> That doesn't mean it's acceptable to change how that's handled in a minor
> release.  The whole concept of a release series doesn't make sense if you
> take that route. Take a look at how signed integer overflow was handled, for
> instance. We all know that's invalid and has always been invalid, but the
> change to enable -fstrict-overflow at -O2 was saved for the next major
> release and clearly documented in the GCC 4.2 Changes page
> .
> 
> A release series should mean that it is safe for distros to upgrade within
> the release series. Right now, it's not.

This is wrong too since some of what -fstrict-overflow did was enabled at -O1
(and -O2) before hand; just the option was added for GCC 4.2.0 and only enabled
at -O2 and above.

[Bug c++/89599] New: C-style function-pointer-to-void* cast is handled inconsistently

[jandemooij+gccbugs at gmail dot com]

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

Bug ID: 89599
   Summary: C-style function-pointer-to-void* cast is handled
inconsistently
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jandemooij+gccbugs at gmail dot com
  Target Milestone: ---

When compiling the code below with GCC 8.3.0 or 9, GCC reports an error:

:5:30: error: a reinterpret_cast is not a constant expression

5 | static constexpr void* ptr = (void*)

  |  ^

However shouldn't it also report an error for the |arr| version?

https://godbolt.org/z/KeEH-2

---

void func1(int x) {}
void func2(char z, bool b) {}

static constexpr void* arr[2] = {(void*), (void*)func2};
static constexpr void* ptr = (void*)

int main()
{
return 0;
}

[Bug c++/89585] GCC 8.3: asm volatile no longer accepted at file scope

[harald at gigawatt dot nl]

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

--- Comment #11 from Harald van Dijk  ---
(In reply to Segher Boessenkool from comment #10)
> 1) It wasn't defined behaviour before, so nothing changed in that regard.
> Many changes changes behaviour on invalid code.  Not all invalid code gets
> a diagnostic.

That doesn't mean it's acceptable to change how that's handled in a minor
release.  The whole concept of a release series doesn't make sense if you take
that route. Take a look at how signed integer overflow was handled, for
instance. We all know that's invalid and has always been invalid, but the
change to enable -fstrict-overflow at -O2 was saved for the next major release
and clearly documented in the GCC 4.2 Changes page
.

A release series should mean that it is safe for distros to upgrade within the
release series. Right now, it's not.

> 2) Incompatible clang behaviour on GNU C extensions is not GCC's fault.

There was no incompatible clang behaviour, so this comment does not make sense.
clang accepted the code with a warning where GCC accepted it without a warning,
but it behaved the same in both compilers, until GCC 8.3.

> 3) I've heard of only one program where this change showed this problem (Qt),
> and it has been fixed there long ago.  So silly me thought that was the end
> of it.

Long ago? It definitely breaks last years' releases, though I have not tested
with the most recent versions. Even if it didn't, distros are likely to be
stuck with supporting Qt 4.x for a while. When they bump to GCC 9, they know
they have to deal with breakage and patch code, but when they bump to GCC 8.3,
this is a nasty surprise.

> And then my backport was approved, too.

Your backport was approved after a highly misleading message on the mailing
list. You wrote:

> I'd like to backport the "asm inline" series to 8 branch and 7 branch.
> The patches are identical to trunk, except I added a patch 8/8 that
> makes these branches not error on code it only warned on before (that
> is, C code that uses restrict or const as asm qualifier).

Technically, this is 100% true. What's missing from this is that it *does*
error on code it previously accepted *without* a warning. Whether it would have
been approved if you had included that bit in your e-mail is something we'll
never know.

> 4) Yeah, a more specific diagnostic might be nice (not all qualifiers are
> asm qualifiers).  This should go to trunk first then, of course.

Given that any changes to re-accept the code would be limited to GCC 8 only,
that probably shouldn't go on trunk. But if a change on trunk to give a decent
diagnostic can be trivially tweaked to allow the code on GCC 8 again, with a
warning, then great! I'll be happy to help test anything that can be backported
to GCC 8 to allow this again.

[Bug target/47093] [meta-bug]: broken configurations

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com

--- Comment #2 from Jeffrey A. Law  ---
Actually, it's not config-list.ml, though I did use that to help generate the
list of targets I am testing.  None of them ones I'm testing would fall into
the category as a "broken configuration".

[Bug c++/86485] [7/8/9 Regression] "anonymous" maybe-uninitialized false positive with ternary operator

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
I've tried:
--- gcc/cp/cp-gimplify.c.jj 2019-02-18 20:48:37.49912 +0100
+++ gcc/cp/cp-gimplify.c2019-03-05 19:03:17.076410253 +0100
@@ -709,6 +709,16 @@ cp_gimplify_expr (tree *expr_p, gimple_s
   is_gimple_lvalue, fb_lvalue);
*expr_p = TREE_OPERAND (*expr_p, 0);
  }
+   else if (TREE_CODE (op1) == TARGET_EXPR
+&& is_really_empty_class (TREE_TYPE (op0))
+&& !TREE_THIS_VOLATILE (op1)
+&& !TREE_ADDRESSABLE (TREE_TYPE (op0)))
+ {
+   gimplify_and_add (op1, pre_p);
+   gimplify_expr (_OPERAND (*expr_p, 0), pre_p, post_p,
+  is_gimple_lvalue, fb_lvalue);
+   *expr_p = TREE_OPERAND (*expr_p, 0);
+ }
/* P0145 says that the RHS is sequenced before the LHS.
   gimplify_modify_expr gimplifies the RHS before the LHS, but that
   isn't quite strong enough in two cases:
(poor attempt to gimplify the TARGET_EXPRs on the rhs in that case always and
also the lhs, but not actually copy any data in between) but that unfortunately
causes ICEs on g++.dg/cpp0x/initlist-new1.C test (apparently CLEANUP_POINT_EXPR
then makes it through into the IL).
If the empty class has a destructor, then we actually share the same temporary
through gimplify_modify_expr_rhs
case COND_EXPR:
  /* If we're assigning to a non-register type, push the assignment
 down into the branches.  This is mandatory for ADDRESSABLE types,
 since we cannot generate temporaries for such, but it saves a
 copy in other cases as well.  */
  if (!is_gimple_reg_type (TREE_TYPE (*from_p)))
handling, but we don't do that in this case.

Jason, any ideas?

[Bug target/89557] [7/8/9 regression] 4*movq to 2*movaps IPC performance regression on znver1 with -Og

[0xe2.0x9a.0x9b at gmail dot com]

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

--- Comment #8 from Jan Ziak (http://atom-symbol.net) <0xe2.0x9a.0x9b at gmail 
dot com> ---
Testcase (a.cc) benchmark results. See attached Makefile for further
information about compiler options.

Machine 1: Ryzen 5 1600 Six-Core Processor:

  a0-7.4: 0.753795user
  ag-7.4: 0.313097user
  a1-7.4: 0.281629user

  a0-8.3: 0.739894user
  ag-8.3: 0.954584user<-- performance issue in respect to ag-7.4
  a1-8.3: 0.281554user
  a3-8.3: 0.224067user

  ag-7.4n: 1.032364user<-- performance issue in respect to ag-7.4
  ag-8.3n: 1.007429user<-- performance issue in respect to ag-7.4

Machine 2: Intel(R) Xeon(R) CPU E5-2676 v3:

  a0-7.4: 1.02user
  ag-7.4: 0.37user
  a1-7.4: 0.34user

  a0-8.3: 1.01user
  ag-8.3: 0.95user<-- performance issue in respect to a1-7.4
  a1-8.3: 0.34user
  a3-8.3: 0.27user

  ag-7.4n (-march=znver1): 1.05user<-- performance issue in respect to
ag-7.4
  ag-8.3n (-march=znver1): 0.99user<-- performance issue in respect to
ag-7.4

Machine 3: Intel(R) Celeron(R) CPU N2930:

  a0-7.4: 2.223435user
  ag-7.4: 1.017597user
  a1-7.4: 0.741288user

  a0-8.3: 2.224145user
  ag-8.3: 1.620879user<-- performance issue in respect to ag-7.4
  a1-8.3: 1.014488user<-- performance regression in respect to a1-7.4
  a3-8.3: 0.885718user<-- performance regression in respect to a1-7.4

  ag-7.4n (-march=znver1): n/a
  ag-8.3n (-march=znver1): n/a

[Bug target/47117] unfulfillable case in config.gcc

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||law at redhat dot com
 Resolution|--- |WONTFIX

--- Comment #1 from Jeffrey A. Law  ---
These configurations were removed long ago...

[Bug target/47093] [meta-bug]: broken configurations

[law at redhat dot com]

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

Bug 47117 Summary: unfulfillable case in config.gcc 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47117

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WONTFIX

[Bug target/47093] [meta-bug]: broken configurations

[law at redhat dot com]

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

Bug 52551 Summary: i686-interix3: winnt.c:400:8: error: 
‘flag_writable_rel_rdata’ undeclared
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52551

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WONTFIX

[Bug target/52551] i686-interix3: winnt.c:400:8: error: ‘flag_writable_rel_rdata’ undeclared

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||law at redhat dot com
 Resolution|--- |WONTFIX

--- Comment #3 from Jeffrey A. Law  ---
Interix was deprecated, came back and was deprecated again.

[Bug target/54707] picochip.c:332:985: error: ‘default_stabs_asm_out_constructor’ was not declared in this scope

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||law at redhat dot com
 Resolution|--- |WONTFIX

--- Comment #2 from Jeffrey A. Law  ---
Picochip was deprecated & removed.

[Bug target/47093] [meta-bug]: broken configurations

[law at redhat dot com]

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

Bug 54707 Summary: picochip.c:332:985: error: 
‘default_stabs_asm_out_constructor’ was not declared in this scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54707

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WONTFIX

[Bug target/89557] [7/8/9 regression] 4*movq to 2*movaps IPC performance regression on znver1 with -Og

[0xe2.0x9a.0x9b at gmail dot com]

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

--- Comment #7 from Jan Ziak (http://atom-symbol.net) <0xe2.0x9a.0x9b at gmail 
dot com> ---
Created attachment 45898
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45898=edit
Makefile

[Bug target/89557] [7/8/9 regression] 4*movq to 2*movaps IPC performance regression on znver1 with -Og

[0xe2.0x9a.0x9b at gmail dot com]

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

--- Comment #6 from Jan Ziak (http://atom-symbol.net) <0xe2.0x9a.0x9b at gmail 
dot com> ---
Created attachment 45897
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45897=edit
a.cc: compilable testcase

[Bug go/89598] [9 Regression] go frontend fails to build against mpfr 2.4.2

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

   Priority|P3  |P1
Summary|go frontend fails to build  |[9 Regression] go frontend
   |against mpfr 2.4.2  |fails to build against mpfr
   ||2.4.2

[Bug go/89598] New: go frontend fails to build against mpfr 2.4.2

[dmalcolm at gcc dot gnu.org]

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

Bug ID: 89598
   Summary: go frontend fails to build against mpfr 2.4.2
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: go
  Assignee: ian at airs dot com
  Reporter: dmalcolm at gcc dot gnu.org
CC: cmang at google dot com
  Target Milestone: ---

I'm building gcc against mpfr-2.4.2.tar.bz2, which is the minimum version
stated at:
  https://gcc.gnu.org/install/prerequisites.html
which says "MPFR Library version 2.4.2 (or later)".

I'm seeing build failures of the form:

../../../src/gcc/go/gofrontend/expressions.cc: In member function ‘unsigned int
Numeric_constant::hash(unsigned int) const’:
../../../src/gcc/go/gofrontend/expressions.cc:17290:40: error: ‘MPFR_RNDN’ was
not declared in this scope; did you mean ‘GMP_RNDN’?
17290 |   mpc_abs(m, this->u_.complex_val, MPFR_RNDN);
  |^
  |GMP_RNDN

The usage of MPFR_RNDN was added in r269242 (akak
0ab323427675e178efdefc397fa82f7f8530a182), in Numeric_constant::hash.

I note r244966 (aka17a58f8aef6dfbfaf7f360cce0524c7d82307a83) poisoned
MPFR_RNDN, in favor of using GMP_RNDN for compat with older MPFRs; presumably
that should be done here?

(See also this thread: https://gcc.gnu.org/ml/gcc-patches/2019-02/msg01767.html
)

[Bug target/89597] New: Inconsistent vector calling convention on windows with Clang and MSVC

[yyc1992 at gmail dot com]

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

Bug ID: 89597
   Summary: Inconsistent vector calling convention on windows with
Clang and MSVC
   Product: gcc
   Version: 8.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: yyc1992 at gmail dot com
  Target Milestone: ---

For 256bit and 512bit vector return values, Clang and MSVC always returns them
in the corresponding registers even without `__vectorcall`. GCC, however,
returns the value as reference. Together with the missing support of
`__vectorcall`[1], this means that the code GCC generate for functions that
returns vector value is not compatible with any other compilers. The problem
does not exist for 128bit vectors.

Test case.

```
typedef double vdouble __attribute__((vector_size(32)));
vdouble f(vdouble x, vdouble y)
{
return x + y;
}
```

GCC compiles this to,

```
f:
vmovapd (%r8), %ymm0
vaddpd  (%rdx), %ymm0, %ymm0
movq%rcx, %rax
vmovapd %ymm0, (%rcx)
vzeroupper
ret
```

Clang compiles this to,

```
f:
vmovapd (%rcx), %ymm0
vaddpd  (%rdx), %ymm0, %ymm0
retq
```

Given the stack alignment issue[2], I wonder if this can be fixed now without
breaking anyone's code. (i.e. everyone that's using it is probably broken
anyway due to the other bug...)

Disclaimer. I did all my test with clang. I believe MSVC behaves the same from
the compiled result I got from someone else and I don't have MSVC to personally
test it.

[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89485
[2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54412

[Bug translation/40883] [meta-bug] Translation breakage with trivial fixes

[roland.illig at gmx dot de]

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

--- Comment #2 from Roland Illig  ---
I don't know how to add these bugs to the "Depends on" field, therefore I'm
listing them here. Could it be that a mere reporter cannot do this?

bug 79645
bug 79646
bug 79846
bug 79858
bug 79869
bug 79870
bug 79924
bug 7
bug 80003
bug 80022
bug 80058
bug 80190
bug 80192
bug 84911
bug 8
bug 79477
bug 79595
bug 79618
bug 79842
bug 79871
bug 80012
bug 80188
bug 85665
bug 79926
bug 79861

[Bug target/89587] gcc's rs6000 configuration unconditionally sets MULTIARCH_DIRNAME, even when multiarch is disabled

[jakub at gcc dot gnu.org]

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

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

[Bug other/80058] fix double spaces in string literals everywhere

[roland.illig at gmx dot de]

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

--- Comment #1 from Roland Illig  ---
Before fixing these bugs, the program that checks these instances should be
checked in and be run each time before the GCC code is sent to the translators.

[Bug target/89587] gcc's rs6000 configuration unconditionally sets MULTIARCH_DIRNAME, even when multiarch is disabled

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Author: jakub
Date: Tue Mar  5 17:25:01 2019
New Revision: 269396

URL: https://gcc.gnu.org/viewcvs?rev=269396=gcc=rev
Log:
PR target/89587
* config/rs6000/t-linux (MULTIARCH_DIRNAME): Set to non-empty only
if_multiarch.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/t-linux

[Bug c++/29843] [meta-bug] C++98 standard conformance issues

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
This doesn't seem a very useful meta-bug. Every bug with Component=c++ and
Keywords=rejects-valid is a standard conformance issue.

What's the point of this one?

[Bug rtl-optimization/89588] [8/9 Regression] ICE in unroll_loop_constant_iterations, at loop-unroll.c:498

[ebotcazou at gcc dot gnu.org]

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

--- Comment #4 from Eric Botcazou  ---
#pragma GCC unroll and -fno-tree-loop-optimize?  Seriously?

[Bug libgcc/56187] void arithmetic in unwind-dw2-fde.c

[steven at gcc dot gnu.org]

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

Steven Bosscher  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |WONTFIX

[Bug tree-optimization/39201] [meta-bug] ivopts metabug

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #4 from Eric Gallager  ---
All the bugs that this one depends upon have been closed so I'm closing this
one as well; feel free to reopen if there are new bugs for this one to depend
upon.

[Bug middle-end/67118] gcc and gfortran started crashing recently

[steven at gcc dot gnu.org]

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

Steven Bosscher  changed:

   What|Removed |Added

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

--- Comment #2 from Steven Bosscher  ---
Not clear what's been going on, some years ago => closing

[Bug c++/29843] [meta-bug] C++98 standard conformance issues

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org,
   ||jason at redhat dot com,
   ||nathan at acm dot org

--- Comment #1 from Eric Gallager  ---
cc-ing C++ FE maintainers

[Bug tree-optimization/56075] [gcc-4.7.1] 64-bit version, -Os eliminate some line of code which working fine in gcc-4.6.2 64-bit version

[steven at gcc dot gnu.org]

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

Steven Bosscher  changed:

   What|Removed |Added

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

--- Comment #3 from Steven Bosscher  ---
no test case => invalid

[Bug lto/52778] gcc crashes with -flto on PA-RISC

[steven at gcc dot gnu.org]

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

Steven Bosscher  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #6 from Steven Bosscher  ---
Reportedly fixed (comment #5)

[Bug target/86952] Avoid jump table for switch statement with -mindirect-branch=thunk

[marxin at gcc dot gnu.org]

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

--- Comment #18 from Martin Liška  ---
I'm working on a more complex test-case generator. I'll post results tomorrow.

[Bug target/47093] [meta-bug]: broken configurations

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org,
   ||joseph at codesourcery dot com,
   ||law at gcc dot gnu.org

--- Comment #1 from Eric Gallager  ---
I know Jeff Law does config-list.mk builds sometimes and Joseph Myers tests a
wide range of configurations with his build-many-glibcs.py script; cc-ing them
to see if they've noticed any additional broken configurations.

[Bug middle-end/43334] Generate an XML dump of the parse tree

[steven at gcc dot gnu.org]

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

Steven Bosscher  changed:

   What|Removed |Added

 Status|WAITING |NEW
   Last reconfirmed|2012-03-13 00:00:00 |2019-3-5

[Bug c++/89585] GCC 8.3: asm volatile no longer accepted at file scope

[segher at gcc dot gnu.org]

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

--- Comment #10 from Segher Boessenkool  ---
1) It wasn't defined behaviour before, so nothing changed in that regard.
Many changes changes behaviour on invalid code.  Not all invalid code gets
a diagnostic.

2) Incompatible clang behaviour on GNU C extensions is not GCC's fault.

3) I've heard of only one program where this change showed this problem (Qt),
and it has been fixed there long ago.  So silly me thought that was the end
of it.  And then my backport was approved, too.

4) Yeah, a more specific diagnostic might be nice (not all qualifiers are
asm qualifiers).  This should go to trunk first then, of course.

[Bug bootstrap/49469] GCC fails to bootstrap when building with embedded zlib on Mac OS X 10.6.7

[steven at gcc dot gnu.org]

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

Steven Bosscher  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #7 from Steven Bosscher  ---
Old MacOS, won't fix.

[Bug translation/40883] [meta-bug] Translation breakage with trivial fixes

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org,
   ||roland.illig at gmx dot de

--- Comment #1 from Eric Gallager  ---
Roland Illig has a bunch of these open; I'll let him add the relevant ones as
dependencies here

[Bug middle-end/89590] [7/8 Regression] ICE in maybe_emit_free_warning

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[7/8/9 Regression] ICE in   |[7/8 Regression] ICE in
   |maybe_emit_free_warning |maybe_emit_free_warning

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

[Bug rtl-optimization/43473] hword size destination variable induces suboptimal code generation compared to full word size var

[steven at gcc dot gnu.org]

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

Steven Bosscher  changed:

   What|Removed |Added

 Status|WAITING |NEW
   Last reconfirmed||2019-3-5
  Known to fail||8.2.0

[Bug middle-end/89590] [7/8/9 Regression] ICE in maybe_emit_free_warning

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Tue Mar  5 16:22:16 2019
New Revision: 269392

URL: https://gcc.gnu.org/viewcvs?rev=269392=gcc=rev
Log:
PR middle-end/89590
* builtins.c (maybe_emit_free_warning): Punt if free doesn't have
exactly one argument.

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

Added:
trunk/gcc/testsuite/gcc.dg/pr89590.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/builtins.c
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/36003] pass_fast_rtl_byte_dce is disabled currently because of breakage in CC0 targets

[steven at gcc dot gnu.org]

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

Steven Bosscher  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #7 from Steven Bosscher  ---
rtl_byte_dce is gone. It was rewritten as run_word_dce called from
lower-subreg, as part of the (apparently partial) fix for PR42575.

[Bug rtl-optimization/22568] Should use cmov in some stituations

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Blocks|26914   |
 CC||pawel_sikora at zoho dot com

--- Comment #13 from Eric Gallager  ---
*** Bug 26914 has been marked as a duplicate of this bug. ***


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26914
[Bug 26914] lack of conditional moves with floating point

[Bug rtl-optimization/26914] lack of conditional moves with floating point

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||egallager at gcc dot gnu.org
 Depends on|22568   |
 Resolution|--- |DUPLICATE

--- Comment #3 from Eric Gallager  ---
(In reply to Richard Biener from comment #2)
> Related to / dup of PR22568.  Meta-bug ifcvt sucks.  Or cmov sucks on the P4
> - whatever you like ;)

I'd rather say dup-of rather than making this a meta-bug; meta-bugs should
depend on more than just 1 other bug, IMO

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


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=22568
[Bug 22568] Should use cmov in some stituations

[Bug c++/89596] [8/9 regression] Multiple templated conversion operators result in compilation error

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org,
   ||redi at gcc dot gnu.org
   Target Milestone|--- |8.4
Summary|[8 regression] Multiple |[8/9 regression] Multiple
   |templated conversion|templated conversion
   |operators result in |operators result in
   |compilation error   |compilation error

--- Comment #2 from Jakub Jelinek  ---
Started to be rejected with r258755.  Will defer to the C++ folks whether that
is desirable or not.

[Bug middle-end/89590] [7/8/9 Regression] ICE in maybe_emit_free_warning

[msebor at gcc dot gnu.org]

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

--- Comment #2 from Martin Sebor  ---
In reply to bug 89566 comment #5, one strategy is to do the same thing that's
already done for built-ins (possibly implicitly) declared with an incompatible
prototype: treat invalid calls as ordinary ones.  For example:

  char a[8];

  void f (void)
  {
memcpy (a, 8, "01234567");   // library call
  }

  void g (void)
  {
memcpy (a, "01234567", 8);   // folded to MEM_REF
  }

This is far from ideal since the call will very likely corrupt something or
crash.  The only redeeming argument in favor of it is that GCC has gotten
pretty good at warning for these bugs (but warnings can be suppressed).

Another solution might be to replace these invalid calls with traps.  The
choice between these strategies (or any others) could be controlled by some
option as has been suggested elsewhere for other kinds of undefined behavior
(e.g., pr89561).  The trap solution could obviously only be deployed only for
calls that would result in corruption, like with insufficient or excess
arguments or arguments of ABI-incompatible types, etc.  I think
-Wbad-function-cast already tries to trigger only for these kinds of casts.

[Bug c++/89596] [8 regression] Multiple templated conversion operators result in compilation error

[jleahy+gcc at gmail dot com]

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

--- Comment #1 from jleahy+gcc at gmail dot com ---
This only happens with -std=c++17, without -std=c++17 the code fails to
compile.

[Bug libfortran/89593] warning "passing argument 3 of ‘_gfortran_caf_{get,send}_by_ref’ from incompatible pointer type" when building libgfortran

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-03-05
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Ever confirmed|0   |1

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

Untested fix.

[Bug c++/87378] False -Wredundant-move (derived vs. base)

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #1 from Marek Polacek  ---
https://gcc.gnu.org/ml/gcc-patches/2019-03/msg00146.html

[Bug rtl-optimization/20369] noce_emit_move_insn emits invalid insns

[steven at gcc dot gnu.org]

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

Steven Bosscher  changed:

   What|Removed |Added

   Last reconfirmed|2007-05-17 17:50:53 |2019-3-5

--- Comment #4 from Steven Bosscher  ---
The patch of comment #2 doesn't apply since r100240 (fix for PR9814).
But comment #4 is still true.

Even without a test case, this bug could be fixed by asserting that
the generated seq is recognized.

[Bug c++/89596] New: [8 regression] Multiple templated conversion operators result in compilation error

[jleahy+gcc at gmail dot com]

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

Bug ID: 89596
   Summary: [8 regression] Multiple templated conversion operators
result in compilation error
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jleahy+gcc at gmail dot com
  Target Milestone: ---

The follow code compiles fine on GCC <=7.4 (and also on Clang). However on 8.0
(and trunk) it fails.

template
struct Bar {
Bar() = default;
Bar(double x) {}
};

struct Foo {
template
operator T() {
return T();
}
template
operator Bar() {
return Bar();
}
};

void test() {
(void)static_cast>(Foo());
}

The following error is produced:

: In function 'void test()':
:20:38: error: call of overloaded 'Bar(Foo)' is ambiguous
 (void)static_cast>(Foo());
:5:5: note: candidate: 'Bar::Bar(double) [with T = int]'
 Bar(double x) {}
:3:8: note: candidate: 'constexpr Bar::Bar(const Bar&)'
 struct Bar {
:3:8: note: candidate: 'constexpr Bar::Bar(Bar&&)'

I believe from the standard GCC should consider all converting constructors (of
which there are none applicable) and user-defined conversion operators (of
which both are applicable) then apply normal overload resolution. During
overload resolution one of the two conversion operators will be discarded as
it's less specialized than the other.

[Bug other/17652] [meta-bug] GCC 4.1 pending patches

[steven at gcc dot gnu.org]

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

Bug 20211 Summary: autoincrement generation is poor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=20211

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WONTFIX

[Bug other/23111] [meta-bug] GCC 4.2 pending patches

[steven at gcc dot gnu.org]

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

Bug 20211 Summary: autoincrement generation is poor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=20211

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WONTFIX

[Bug other/29842] [meta-bug] outstanding patches / issues from STMicroelectronics

[steven at gcc dot gnu.org]

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

Bug 20211 Summary: autoincrement generation is poor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=20211

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WONTFIX

[Bug rtl-optimization/20211] autoincrement generation is poor

[steven at gcc dot gnu.org]

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

Steven Bosscher  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC|steven at gcc dot gnu.org  |
 Resolution|--- |WONTFIX

--- Comment #41 from Steven Bosscher  ---
After 12 years of changes, the value of the patches in this bug 
report, and indeed the bug report itself, is difficult to gauge.

If this is still an issue, and that issue isn't covered by one
of the more specific auto-inc-dec issues, please open a new PR 
with a test case and with the expected code.

For now, wontfix.

[Bug debug/89498] [8/9 Regression] ICE in AT_loc_list, at dwarf2out.c:4871

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

[Bug target/89222] [7/8 regression] ARM thumb-2 misoptimisation of func ptr call with -O2 or -Os

[wilco at gcc dot gnu.org]

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

Wilco  changed:

   What|Removed |Added

   Target Milestone|--- |8.5
Summary|[7/8/9 regression] ARM  |[7/8 regression] ARM
   |thumb-2 misoptimisation of  |thumb-2 misoptimisation of
   |func ptr call with -O2 or   |func ptr call with -O2 or
   |-Os |-Os

[Bug tree-optimization/89570] [9 Regression] ICE in prepare_cmp_insn, at optabs.c:4001

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/89570] [9 Regression] ICE in prepare_cmp_insn, at optabs.c:4001

[jakub at gcc dot gnu.org]

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

--- Comment #13 from Jakub Jelinek  ---
Author: jakub
Date: Tue Mar  5 15:05:07 2019
New Revision: 269391

URL: https://gcc.gnu.org/viewcvs?rev=269391=gcc=rev
Log:
PR tree-optimization/89570
* match.pd (vec_cond into cond_op simplification): Don't use
get_conditional_internal_fn, use as_internal_fn (cond_op).

Modified:
trunk/gcc/ChangeLog
trunk/gcc/match.pd

[Bug target/89222] [7/8/9 regression] ARM thumb-2 misoptimisation of func ptr call with -O2 or -Os

[wilco at gcc dot gnu.org]

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

--- Comment #9 from Wilco  ---
Author: wilco
Date: Tue Mar  5 15:04:01 2019
New Revision: 269390

URL: https://gcc.gnu.org/viewcvs?rev=269390=gcc=rev
Log:
[ARM] Fix PR89222

The GCC optimizer can generate symbols with non-zero offset from simple
if-statements. Bit zero is used for the Arm/Thumb state bit, so relocations
with offsets fail if it changes bit zero and the relocation forces bit zero
to true.  The fix is to disable offsets on function pointer symbols.  

gcc/
PR target/89222
* config/arm/arm.md (movsi): Use targetm.cannot_force_const_mem
to decide when to split off a non-zero offset from a symbol.
* config/arm/arm.c (arm_cannot_force_const_mem): Disallow offsets
in function symbols.

testsuite/
PR target/89222
* gcc.target/arm/pr89222.c: Add new test.

Added:
trunk/gcc/testsuite/gcc.target/arm/pr89222.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/arm/arm.c
trunk/gcc/config/arm/arm.md
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/89594] [9 Regression] ICE: Segmentation fault (in gsi_for_stmt(gimple*))

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/89594] [9 Regression] ICE: Segmentation fault (in gsi_for_stmt(gimple*))

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener  ---
Author: rguenth
Date: Tue Mar  5 14:57:12 2019
New Revision: 269389

URL: https://gcc.gnu.org/viewcvs?rev=269389=gcc=rev
Log:
2019-03-05  Richard Biener  

PR tree-optimization/89594
* tree-if-conv.c (pass_if_conversion::execute): Handle
case where .LOOP_VECTORIZED_FUNCTION was removed.

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

Added:
trunk/gcc/testsuite/gcc.dg/pr89594.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-if-conv.c

[Bug tree-optimization/89247] [7/8 Regression] ICE in expand_LOOP_VECTORIZED, at internal-fn.c:2409

[rguenth at gcc dot gnu.org]

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

Bug 89594 Summary: [9 Regression] ICE: Segmentation fault (in 
gsi_for_stmt(gimple*))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89594

   What|Removed |Added

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

[Bug c/89549] [7/8/9 Regression] -Wmisleading-indentation is disabled from this point onwards, since column-tracking was disabled due to the size of the code/headers

[dmalcolm at gcc dot gnu.org]

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

--- Comment #6 from David Malcolm  ---
(In reply to Martin Liška from comment #4)
> Created attachment 45877 [details]
> test-case

Thanks; I'm able to see the behavior with that.

[Bug tree-optimization/85762] [8/9 Regression] range-v3 abstraction overhead not optimized away

[jamborm at gcc dot gnu.org]

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

--- Comment #8 from Martin Jambor  ---
(In reply to Jakub Jelinek from comment #7)
> Do you really want to match type of any field whatsoever, or better look for
> the type of a field at the particular position?

I was thinking about exactly this question but eventually I'd like to
fix this with something like
https://gcc.gnu.org/ml/gcc-patches/2019-03/msg00176.html

[Bug middle-end/39326] Segmentation fault with -O1, out of memory with -O2

[rguenth at gcc dot gnu.org]

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

--- Comment #60 from Richard Biener  ---
PRE is all find_base_term exploding ...

The LIM case is all store_motion () which is quadratic and the only
user of the quadratic in memory all_refs_stored_in_loop.  The latter
would be reasonably easy to fix by iterating.  The former is more
difficult to fix, we'd need to rewrite SM to work inner-to-outer
loops somehow.  But that's certainly doable.  Gating store-motion
on optimize > 1 is possible as well (it also has the bad side-effect
of increasing register pressure by introducing IVs).

[Bug c++/87148] [7/8/9 Regression] backward compatibility issue to take char [] as incomplete type

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #8 from Jakub Jelinek  ---
Created attachment 45895
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45895=edit
gcc9-pr87148.patch

Untested fix.

[Bug tree-optimization/85762] [8/9 Regression] range-v3 abstraction overhead not optimized away

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
Do you really want to match type of any field whatsoever, or better look for
the type of a field at the particular position?

[Bug c++/89480] internal compiler error: in unify, at cp/pt.c:22160 with the template argument force conversion

[kutdanila at yandex dot ru]

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

--- Comment #3 from Danila Kutenin  ---
Also not sure if this should compile. But if change Foo{} to static_cast
all the compilers compile.

[Bug c++/89480] internal compiler error: in unify, at cp/pt.c:22160 with the template argument force conversion

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  ---
Started to ICE with r137361 when all the C++11 features used in there got
implemented, before that it has been rejected.  clang++ accepts it, icpc
rejects it, so unsure if it is valid or not.

[Bug rtl-optimization/89487] [8 Regression] ICE in expand_expr_addr_expr_1, at expr.c:7993

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
Author: jakub
Date: Tue Mar  5 13:38:59 2019
New Revision: 269388

URL: https://gcc.gnu.org/viewcvs?rev=269388=gcc=rev
Log:
PR tree-optimization/89487
* gcc.dg/tree-ssa/pr89487.c: Include ../pr87600.h.
(caml_interprete): Ifdef the whole body out if REG1 or REG2 macros
aren't defined.  Use REG1 instead of "%r15" and REG2 instead of
"%r14".

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