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

[amker at gcc dot gnu.org]

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

bin cheng  changed:

   What|Removed |Added

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

--- Comment #1 from bin cheng  ---
probably something with recent changes on comp_cost::operators

[Bug translation/90119] Merge translation msgids that only differ in placeholders

[marxin at gcc dot gnu.org]

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

--- Comment #8 from Martin Liška  ---
(In reply to Roland Illig from comment #7)
> I didn't want to sound that harsh in my previous comment.
> 
> What I wanted to say is: to make the linter reliable and be able to handle
> the full syntax of .po files, it's better to use an exising library that is
> well-tested instead of parsing .po files ad-hoc using regular expressions
> and raw string functions.

I welcome your linter! The one I wrote was just a one time script that I
eventually installed to our contrib scripts.

> 
> That way the code of the linter becomes easy to read since it uses the
> standard terminology of the .po structures, and it is easy to access all
> gettext features (such as plurals or other formats) without modifying the
> parser code.
> 
> It also becomes easier to add new checks to the linter.
> 
> The diagnostics of the linter now follow more closely the GCC Guidelines for
> Diagnostics, by offering guidance and saying what the actual possible
> problem is, instead of only pointing to the problematic message.
> 
> This of course requires a bit more code than the current linter.
> 
> I have checked that my rewrite preserves all existing features of the
> linter. I don't think adding new features to the current architecture of the
> linter makes sense since it requires more work than absolutely necessary. To
> add a new linter check, it shouldn't be necessary to modify any .po file
> format parser. Therefore I think replacing the current linter with the
> latest suggested code from bug 90176 actually makes sense.

Great, can you please send a patch to gcc-patches and install the new linter to
contrib scripts?

[Bug c/90241] New: [UBSAN]: in ao_ref_init_from_ptr_and_size

[dcb314 at hotmail dot com]

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

Bug ID: 90241
   Summary: [UBSAN]: in ao_ref_init_from_ptr_and_size
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

Following on from PR 85164, where I tried a UBSAN version
of gcc trunk over the testsuite, for file 
c-c++-common/Warray-bounds-2.c, I got:

../../trunk/gcc/poly-int.h:1107:5: runtime error: signed integer overflow: 8 *
-9223372036854775796 cannot be represented in type 'long int'
#0 0x2ddd587 in poly_int<1u, poly_result::is_poly>::type, long,
poly_coeff_pair_traits::is_poly>::type, long>::result_kind>::type> operator*<1u,
int, long>(int const&, poly_int_pod<1u, long> const&)
../../trunk/gcc/poly-int.h:1107
#1 0x2ddd587 in ao_ref_init_from_ptr_and_size(ao_ref*, tree_node*,
tree_node*) ../../trunk/gcc/tree-ssa-alias.c:703
#2 0x2ea1f49 in initialize_ao_ref_for_dse
../../trunk/gcc/tree-ssa-dse.c:106
#3 0x2ea1f49 in initialize_ao_ref_for_dse ../../trunk/gcc/tree-ssa-dse.c:91
#4 0x2ea784b in dse_dom_walker::dse_optimize_stmt(gimple_stmt_iterator*)
../../trunk/gcc/tree-ssa-dse.c:851
#5 0x2eab4ba in dse_dom_walker::before_dom_children(basic_block_def*)
../../trunk/gcc/tree-ssa-dse.c:944
#6 0x4e831f6 in dom_walker::walk(basic_block_def*)
../../trunk/gcc/domwalk.c:312

[Bug c/90242] New: [UBSAN]: in vn_reference_compute_hash

[dcb314 at hotmail dot com]

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

Bug ID: 90242
   Summary: [UBSAN]: in vn_reference_compute_hash
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

Following on from PR 85164, where I tried a UBSAN version
of gcc trunk over the testsuite, for file 
./c-c++-common/Warray-bounds.c, with flags -g -O3 -march=native -Wall, I got

../../trunk/gcc/poly-int.h:715:21: runtime error: signed integer overflow:
9223372036854775804 + 4 cannot be represented in type 'long int'
#0 0x318ecb2 in poly_int<1u, long>& poly_int<1u,
long>::operator+=(poly_int_pod<1u, long> const&)
../../trunk/gcc/poly-int.h:715
#1 0x318ecb2 in vn_reference_compute_hash
../../trunk/gcc/tree-ssa-sccvn.c:657
#2 0x31b26b5 in vn_reference_lookup(tree_node*, tree_node*, vn_lookup_kind,
vn_reference_s**, bool) ../../trunk/gcc/tree-ssa-sccvn.c:2714
#3 0x31ea070 in visit_reference_op_load
../../trunk/gcc/tree-ssa-sccvn.c:4091
#4 0x31ea070 in visit_stmt ../../trunk/gcc/tree-ssa-sccvn.c:4509
#5 0x31efef6 in process_bb ../../trunk/gcc/tree-ssa-sccvn.c:6130
#6 0x31f9fb0 in do_rpo_vn ../../trunk/gcc/tree-ssa-sccvn.c:6625

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

[amker at gcc dot gnu.org]

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

--- Comment #2 from bin cheng  ---
Also, cost in inner loop is scaled by big number:
Scaling cost based on bb prob by 1.00: 0 (scratch: 0) -> 0 (1/1)
Scaling cost based on bb prob by 1.00: 32 (scratch: 0) -> 32 (1/1)
Scaling cost based on bb prob by 1.00: 41 (scratch: 0) -> 41 (1/1)
Scaling cost based on bb prob by 1.00: 21 (scratch: 0) -> 21 (1/1)
Scaling cost based on bb prob by 1.00: 45 (scratch: 0) -> 45 (1/1)
Scaling cost based on bb prob by 1.00: 21 (scratch: 0) -> 21 (1/1)
Scaling cost based on bb prob by 1.00: 17 (scratch: 0) -> 17 (1/1)

Resulting:
Group 19:
  cand  costcompl.  inv.expr.   inv.vars
  1 41  0   NIL;1, 4
  2 21  0   NIL;4
  3 45  0   NIL;1, 4
  4 21  0   NIL;4
  5 17  0   35; NIL;
  300   0   NIL;NIL;
  6732  0   NIL;1, 4

Given we have 70 groups of iv_use, this easily overflow infinite_cost which is
10,000,000.

One thing unclear is the overflow happens in the middle of cost candidate
choosing algorithm.

[Bug lto/90229] Interaction among -Wl,--as-needed and LTO results in an undefined symbol

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #5 from Martin Liška  ---
(In reply to H.J. Lu from comment #4)
> I can't reproduce it with binutils master branch and GCC 9:
> 
> [hjl@gnu-cfl-1 pr90229]$ cat x.ii 
> extern int FLAGS_verbose;
> extern "C" void pthread_create(void);
> 
> void a(const char *b...) {
>   if (FLAGS_verbose) {
> __builtin_va_list ap;
> __builtin_va_start(ap, b);
>   }
> }
> void a() { pthread_create(); }
> int main() { a(""); return 0; }
> [hjl@gnu-cfl-1 pr90229]$ cat lib.ii
> int FLAGS_verbose;
> [hjl@gnu-cfl-1 pr90229]$ make
> /export/build/gnu/tools-build/gcc-wip-debug/build-x86_64-linux/gcc/xgcc
> -B/export/build/gnu/tools-build/gcc-wip-debug/build-x86_64-linux/gcc/ -B./
> -g -flto -c -o x.o x.ii
> /export/build/gnu/tools-build/gcc-wip-debug/build-x86_64-linux/gcc/xgcc
> -B/export/build/gnu/tools-build/gcc-wip-debug/build-x86_64-linux/gcc/ -B./
> -g -c -o lib.o lib.ii
> /export/build/gnu/tools-build/gcc-wip-debug/build-x86_64-linux/gcc/xgcc
> -B/export/build/gnu/tools-build/gcc-wip-debug/build-x86_64-linux/gcc/ -B./
> -shared -g -o libx.so lib.o
> /export/build/gnu/tools-build/gcc-wip-debug/build-x86_64-linux/gcc/xgcc
> -B/export/build/gnu/tools-build/gcc-wip-debug/build-x86_64-linux/gcc/ -B./
> -pthread -g -o x x.o libx.so -Wl,--as-needed 
> [hjl@gnu-cfl-1 pr90229]$

I can confirm that with current trunk of both GCC and bintuils. You used a bit
different
build steps:
1) one needs g++ for: -shared -g -o libx.so lib.o
2) you forgot to add -O and -flto to last command line

So please use following steps:

bash -x ./todo
+ gcc -g -c -o lib.o lib.ii
+ g++ -shared -g -o libx.so lib.o
+ gcc -g -flto -c -o x.o x.ii -O
+ gcc -flto -O -pthread -g -o x x.ii libx.so -Wl,--as-needed
/home/marxin/bin/binutils/bin/ld: /home/marxin/bin/gcc/lib64//libstdc++.so.6:
undefined reference to `pthread_create'
collect2: error: ld returned 1 exit status

[Bug c++/90243] New: diagnostic notes that belong to a suppressed error about an uninitialized variable in a constexpr function are still shown

[kretz at kde dot org]

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

Bug ID: 90243
   Summary: diagnostic notes that belong to a suppressed error
about an uninitialized variable in a constexpr
function are still shown
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kretz at kde dot org
  Target Milestone: ---

Test case (https://godbolt.org/z/34KB20):

struct Z {
  int y;
};

template 
constexpr Z f(const T *data) {
  Z z;
  __builtin_memcpy(&z, data, sizeof(z));
  return z;
}

constexpr Z g(const char *data) { return f(data); }

This prints:
: In instantiation of 'constexpr Z f(const T*) [with T = char]':
:12:48:   required from here
:1:8: note: 'struct Z' has no user-provided default constructor
:2:7: note: and the implicitly-defined constructor does not initialize
'int Z::y'

If f is not a template, `Z z;` is an error and the notes explain the error. But
when f is a template the error is suppressed (seems correct). However the notes
that explain the error are still shown. Whether the notes are shown should use
the same condition as the error.

[Bug c++/90243] diagnostic notes that belong to a suppressed error about an uninitialized variable in a constexpr function are still shown

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-04-25
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug target/90204] [8/9 Regression] C code is optimized worse than C++

[crazylht at gmail dot com]

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

--- Comment #7 from Hongtao.liu  ---
Yes, C++ with NRV optization, so the alignment of (res) is 4.
and the alignment of res is 16 in C.

g++/test.i.158t.vect:

../test.i:8:23: note:   recording new base alignment for &
  alignment:4
  misalignment: 0

gcc/test.i.158t.vect:

../test.i:8:5: note:   recording new base alignment for &res
  alignment:16
  misalignment: 0

When alignment of res is 16, that triggers loop peeling of vectorization.

refer to:
/* Function vect_enhance_data_refs_alignment

   This pass will use loop versioning and loop peeling in order to enhance
   the alignment of data references in the loop.
   .
*/

That's why there are more than 150 lines of assemble.

[Bug target/90204] [8/9 Regression] C code is optimized worse than C++

[crazylht at gmail dot com]

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

--- Comment #8 from Hongtao.liu  ---
Cost_model for Function vect_enhance_data_refs_alignment are quite tunable.

More benchmarks are needed if we want to do so.

[Bug c++/86932] [8 Regression] Empty non-type template parameter pack not considered for SFINAE.

[jakub at gcc dot gnu.org]

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

Bug 90227 Summary: [9 Regression] trunk rejects polymake since r269965
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90227

   What|Removed |Added

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

[Bug c++/90227] [9 Regression] trunk rejects polymake since r269965

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |jason at gcc dot gnu.org

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

[Bug gcov-profile/47618] Collecting multiple profiles and using all for PGO

[marxin at gcc dot gnu.org]

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

--- Comment #24 from Martin Liška  ---
(In reply to qinzhao from comment #23)
> (In reply to Andrew Pinski from comment #7)
> > Created attachment 27869 [details]
> > Patch for adding merge-gcda
> > 
> > here is the patch which adds merge-gcda .  I don't add any testcases as it
> > is currently designed only for how Cavium's Simple-exec works in that each
> > core writes out its own gcda file.
> 
> I recently found this bug due to a similar problem. looks like that there
> are two parts of work for this problem:
> 
> 1. GCC's new feature to guarantee that all pre-merged files are saved with
> different names for different instances of the same process. 
> 2. a merge tool to merge all the gcda files afterwards. 
> 
> from my understanding, the patch for the above 1 has been committed into
> GCC9.

Yes.

> How about the patch for the above 2? has it been committed?

It has been there for a while, please take a look at:

$ gcov-tool merge --help
merge: unrecognized option '--help'
Merge subcomand usage:  merge [options]   Merge coverage
file contents
-o, --output   Output directory
-v, --verbose   Verbose mode
-w, --weight Set weights (float point values)

[Bug rtl-optimization/87763] [9 Regression] aarch64 target testcases fail after r265398

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P1  |P2

--- Comment #55 from Jakub Jelinek  ---
This PR had various fixes applied already and the remaining issues don't
warrant a release blocker, so downgrading this to P2.

[Bug rtl-optimization/87871] [9 Regression] testcases fail after r265398 on arm

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P1  |P2

--- Comment #60 from Jakub Jelinek  ---
This PR had various fixes applied already and the remaining issues don't
warrant a release blocker, so downgrading this to P2.

[Bug c/90219] Wrong source location for "cannot convert to a pointer type" warning

[tbaeder at redhat dot com]

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

--- Comment #2 from Timm Bäder  ---
(In reply to Jonathan Wakely from comment #1)
> Well if you took the address you wouldn't need to cast it to (float*) 

Sure, this was just a dumbed-down version of the original code.

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

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P2
 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
Graphite, so IMHO not a release blocker.

[Bug c++/90172] [8/9 Regression] ICE: Segmentation fault (in contains_struct_check)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P2
Summary|[9 Regression] ICE: |[8/9 Regression] ICE:
   |Segmentation fault (in  |Segmentation fault (in
   |contains_struct_check)  |contains_struct_check)

[Bug target/90235] Unnecessary save and restore frame pointer with AVX/AVX512 pseudo registers

[crazylht at gmail dot com]

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

--- Comment #1 from Hongtao.liu  ---
(In reply to H.J. Lu from comment #0)
> From PR 90202:
> 
> [hjl@gnu-cfl-1 pr90202]$ cat x.ii
> struct v {
> int val[16];
> };
> 
> struct v test(struct v a, struct v b) {
> struct v res;
> 
> for (int i = 0; i < 16; i++)
> res.val[i] = a.val[i] + b.val[i];
> 
> return res;
> }
> [hjl@gnu-cfl-1 pr90202]$ make CC=gcc
> gcc -O3 -march=skylake  -S x.ii
> [hjl@gnu-cfl-1 pr90202]$ cat x.s
>   .file   "x.ii"
>   .text
>   .p2align 4,,15
>   .globl  _Z4test1vS_
>   .type   _Z4test1vS_, @function
> _Z4test1vS_:
> .LFB0:
>   .cfi_startproc
>   pushq   %rbp
>   .cfi_def_cfa_offset 16
>   .cfi_offset 6, -16
>   movq%rdi, %rax
>   movq%rsp, %rbp
>   .cfi_def_cfa_register 6
>   vmovdqu 16(%rbp), %ymm1
>   vmovdqu 48(%rbp), %ymm2
>   vpaddd  80(%rbp), %ymm1, %ymm0
>   vmovdqu %ymm0, (%rdi)
>   vpaddd  112(%rbp), %ymm2, %ymm0
>   vmovdqu %ymm0, 32(%rdi)
>   vzeroupper
>   popq%rbp
>   .cfi_def_cfa 7, 8
>   ret
>   .cfi_endproc
> 
> Since there is
> 
> rtx
> gen_reg_rtx (machine_mode mode)
> {
>   rtx val; 
>   unsigned int align = GET_MODE_ALIGNMENT (mode);
> 
>   gcc_assert (can_create_pseudo_p ()); 
> 
>   /* If a virtual register with bigger mode alignment is generated,
>  increase stack alignment estimation because it might be spilled
>  to stack later.  */
>   if (SUPPORTS_STACK_ALIGNMENT
>   && crtl->stack_alignment_estimated < align
>   && !crtl->stack_realign_processed)
> {
>   unsigned int min_align = MINIMUM_ALIGNMENT (NULL, mode, align);
>   if (crtl->stack_alignment_estimated < min_align)
> crtl->stack_alignment_estimated = min_align;
> }
> 
> and IRA has
> 
>   frame_pointer_needed
> = (! flag_omit_frame_pointer
>|| (cfun->calls_alloca && EXIT_IGNORE_STACK)
>/* We need the frame pointer to catch stack overflow exceptions if
>   the stack pointer is moving (as for the alloca case just above). 
> */
>|| (STACK_CHECK_MOVING_SP
>&& flag_stack_check
>&& flag_exceptions
>&& cfun->can_throw_non_call_exceptions)
>|| crtl->accesses_prior_frames
>|| (SUPPORTS_STACK_ALIGNMENT && crtl->stack_realign_needed)
>|| targetm.frame_pointer_required ());
> 
> generate AVX/AVX512 pseudo registers via gen_reg_rtx will mark frame
> pointer as needed.  Stack realignment is needed to
> 
> 1. Align the outgoing stack.
> 2. Support aligned spill of AVX/AVX512 registers.
> 
> But we won't know if spill is needed before RA. As the result, we
> save and restore frame pointer even if not needed.  Since 
> 
> (define_insn "mov_internal"
>   [(set (match_operand:VMOVE 0 "nonimmediate_operand"
>  "=v,v ,v ,m")
> (match_operand:VMOVE 1 "nonimmediate_or_sse_const_operand"
>  " C,BC,vm,v"))]
>   "TARGET_SSE
>&& (register_operand (operands[0], mode)
>|| register_operand (operands[1], mode))"
> 
> now supports both aligned and unaligned load/store of AVX/AVX512
> registers, we can change gen_reg_rtx to
> 
>   /* If a virtual register with bigger mode alignment is generated,
>  increase stack alignment estimation because it might be spilled
>  to stack later.  */
>   if (SUPPORTS_STACK_ALIGNMENT
>   && !SUPPORTS_MISALIGNED_SPILL
>   && crtl->stack_alignment_estimated < align
>   && !crtl->stack_realign_processed)
> {
>   unsigned int min_align = MINIMUM_ALIGNMENT (NULL, mode, align);
>   if (crtl->stack_alignment_estimated < min_align)
> crtl->stack_alignment_estimated = min_align;
> }

Would this generate more unaligned_loads/stores, and does harm to performance?

[Bug target/89929] __attribute__((target("avx512bw"))) doesn't work on non avx512bw systems

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Assignee|marxin at gcc dot gnu.org  |hjl.tools at gmail dot 
com

--- Comment #21 from Martin Liška  ---
I'm assigning that to H.J. as he provided the final version of the patch.

[Bug libstdc++/89819] [9 Regression] std::variant operators regressed since GCC 8.3

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-04-25
   Target Milestone|9.0 |10.0
 Ever confirmed|0   |1

--- Comment #3 from Jonathan Wakely  ---
Confirmed, but nothing will happen for GCC 9.1

[Bug libstdc++/89760] [9 Regression] libstdc++ experimental testsuite failures

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords|rejects-valid   |
 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org

--- Comment #2 from Jonathan Wakely  ---
This isn't rejects-valid, the code is fine, the tests are the problem.

[Bug c/90241] [UBSAN]: in ao_ref_init_from_ptr_and_size

[dcb314 at hotmail dot com]

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

--- Comment #1 from David Binderman  ---
Flag -O2 required.

[Bug c/90242] [UBSAN]: in vn_reference_compute_hash

[dcb314 at hotmail dot com]

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

--- Comment #1 from David Binderman  ---
Only flag -O2 required.

[Bug libstdc++/89819] [9 Regression] std::variant operators regressed since GCC 8.3

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #4 from Jonathan Wakely  ---
Ville corrected me, this was already fixed by r270056

Use single-visitation in variant assignment and swap and relops.

Also use indices instead of types when checking whether
variants hold the same thing.
* include/std/variant (__do_visit): Add a template parameter
for index visitation, invoke with indices if index visitation
is used.
(__variant_idx_cookie): New.
(__visit_with_index): Likewise.
(_Copy_assign_base::operator=): Do single-visitation with
an index visitor.
(_Move_assign_base::operator=): Likewise.
(_Extra_visit_slot_needed): Adjust.
(__visit_invoke): Call with indices if it's an index visitor.
(relops): Do single-visitation with an index visitor.
(swap): Likewise.
(__visitor_result_type): New.

[Bug fortran/83118] [7/8/9 Regression] Bad intrinsic assignment of class(*) array component of derived type

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #19 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #18 from ro at CeBiTec dot Uni-Bielefeld.DE  Uni-Bielefeld.DE> ---
[...]
> I've just applied the patch to trunk, rebuilt f951 on
> sparc-sun-solaris2.11 and tested unlimited_polymorphic_30.f03: the test
> now PASSes for both 32 and 64-bit.
>
> I'll include the patch in tonight's bootstrap and let you know if there
> are any problems elsewhere.

There weren't any in last night's sparc-sun-solaris2.11 bootstrap: both
32 and 64-bit unlimited_polymorphic_30.f03 failures are gone.

Thanks.
Rainer

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

[amker at gcc dot gnu.org]

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

--- Comment #4 from bin cheng  ---
(In reply to Jakub Jelinek from comment #3)
> Graphite, so IMHO not a release blocker.

but the issue is critical, it could happen with general optimization level for
loop nest with huge scaling factor.

So, find_optimal_iv_set_1 first chooses a candidate set, then makes different
tries to do cost descent by modifying the candidate set.  The facts are:
  1) algorithm uses a global variable of following structure and keeps track of
cost in place during computation.
   struct iv_ca {
 //...
 comp_cost cand_use_cost;
 //...
 comp_cost cost;
   };
  2) algorithm is heuristic, so it's possible to reach an intermediate state
with higher cost.
  3) as in previous comment, loop nest with huge scaling factor can easily
result in infinite_cost.
  4) once the global variable of iv_ca.{cand_use_cost, cost} reaches
infinite_cost, ICE is the best thing could happen.

We could replace gcc_assert with algorithm failure then give up ivopts, but
IMHO that would miss quite lot of optimizations.

The conclusion, candidate choosing algorithm doesn't work well with
infinite_cost.  
 I Don't know how to fix this trivially.  For now, even restricting scaling
factor is a practical change now.  Will give it a try.

[Bug c/90244] New: [UBSAN]: in get_object_alignment_2

[dcb314 at hotmail dot com]

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

Bug ID: 90244
   Summary: [UBSAN]: in get_object_alignment_2
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

Following on from PR 85164, I tried out a UBSAN version of
gcc trunk with test suite file gcc.dg/Warray-bounds-22.c
and flag -O2 and got this:

../../trunk/gcc/poly-int.h:1095:5: runtime error: signed integer overflow:
92233
72036854775807 * 8 cannot be represented in type 'long int'
#0 0xf85e20 in poly_int<1u, poly_result::is_poly>::type, poly_coeff_pair_traits::is_poly>::type>::result_kind>::type> operator*<1u, long,
in
t>(poly_int_pod<1u, long> const&, int const&) ../../trunk/gcc/poly-int.h:1095
#1 0xf85e20 in get_object_alignment_2 ../../trunk/gcc/builtins.c:344
#2 0xf86d9d in get_object_alignment_1(tree_node*, unsigned int*, unsigned
lo
ng*) ../../trunk/gcc/builtins.c:394
#3 0xf86d9d in get_object_alignment(tree_node*)
../../trunk/gcc/builtins.c:4
05
#4 0x1690d75 in expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expan
d_modifier, rtx_def**, bool) ../../trunk/gcc/expr.c:10343
#5 0x16939b8 in expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expan
d_modifier, rtx_def**, bool) ../../trunk/gcc/expr.c:9947
#6 0x16ecf5c in expand_expr ../../trunk/gcc/expr.h:279

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

[marxin at gcc dot gnu.org]

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

Bug 90045 Summary: [9 Regression] fails to build a rx-elf cross toolchain with 
C++ enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90045

   What|Removed |Added

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

[Bug libstdc++/90045] [9 Regression] fails to build a rx-elf cross toolchain with C++ enabled

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #15 from Martin Liška  ---
I can confirm it works now.

[Bug middle-end/85164] poly-int.h:845:5: runtime error: signed integer overflow

[dcb314 at hotmail dot com]

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

--- Comment #21 from David Binderman  ---
(In reply to rsand...@gcc.gnu.org from comment #20)
> Thanks for the testing.  

You are welcome.

> Could you open new PRs for the new backtraces?

Done. Most of them were already mentioned in bugzilla, but for
the rest, I have raised 90241, 90242 and 90244.

> But whether the operation triggers
> UB is usually determined by the operation being done (i.e. by the
> caller) rather than the way poly-int.h implements it.  

Thanks for the explanation. It is a lot clearer now.

[Bug tree-optimization/90245] New: A data race with a segmentation fault handler

[marxin at gcc dot gnu.org]

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

Bug ID: 90245
   Summary: A data race with a segmentation fault handler
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
  Target Milestone: ---

Created attachment 46241
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46241&action=edit
test-case

It's follow up of:
https://bugzilla.opensuse.org/show_bug.cgi?id=1133245

For the attached conftest we end up with:

56/* Check that the handler was called only once.  */
57if (handler_called != 1) <--- problematic condition
58{
59  __builtin_printf ("handler_called == 1\n");
60  exit (1);
61}
62/* Test passed!  */
63return 0;
64  }

$ gcc conftest.c -O2 -S -o/dev/stdout
main:
...

movqpage(%rip), %rax
movl$42, 1656(%rax) <--- segfault happens here
cmpl$1, handler_called(%rip) <- comparison after that
jne .L16

While using LTO:

Disassembly of section .text:

00401090 :
...
  401118:   83 3d 41 2f 00 00 01cmpl   $0x1,0x2f41(%rip)#
404060 
  40111f:   c7 83 78 06 00 00 2amovl   $0x2a,0x678(%rbx)
  401126:   00 00 00 
  401129:   75 15   jne401140 

So here we first do 'handler_called != 1' comparison and next instruction
triggers the segfault handler. I tried:
--param allow-store-data-races=0, but it does not help.

Solution is to add a barrier I guess. I guess the transformation is valid?

[Bug tree-optimization/90245] A data race with a segmentation fault handler

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Last reconfirmed||2019-4-25
 CC||rguenth at gcc dot gnu.org

--- Comment #1 from Martin Liška  ---
More clarification:

54/* The second write access should not invoke the handler.  */
55crasher (page);
56/* Check that the handler was called only once.  */
57if (handler_called != 1)
58{
59  __builtin_printf ("handler_called == 1\n");
60  exit (1);
61}

The segfault happens at line 55.

[Bug target/90204] [8/9 Regression] C code is optimized worse than C++

[crazylht at gmail dot com]

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

--- Comment #9 from Hongtao.liu  ---
Also what's better between aligned load/store of smaller size  VS unaligned 
load/store of bigger size?

aligned load/store of smaller size:

movq%rdx, (%rdi)
movq-56(%rsp), %rdx
movq%rdx, 8(%rdi)
movq-48(%rsp), %rdx
movq%rdx, 16(%rdi)
movq-40(%rsp), %rdx
movq%rdx, 24(%rdi)
vmovq   %xmm0, 32(%rax)
movq-24(%rsp), %rdx
movq%rdx, 40(%rdi)
movq-16(%rsp), %rdx
movq%rdx, 48(%rdi)
movq-8(%rsp), %rdx
movq%rdx, 56(%rdi)

unaligned load/store of bigger size:

vmovups %xmm2, (%rdi)
vmovups %xmm3, 16(%rdi)
vmovups %xmm4, 32(%rdi)
vmovups %xmm5, 48(%rdi)

[Bug tree-optimization/90245] A data race with a segmentation fault handler

[fw at gcc dot gnu.org]

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

Florian Weimer  changed:

   What|Removed |Added

 CC||fw at gcc dot gnu.org

--- Comment #2 from Florian Weimer  ---
I think that handler_called should be volatile sig_atomic_t.  Or you would have
to add signal fences.

[Bug libstdc++/90246] New: std::bad_variant_access messages are not useful

[redi at gcc dot gnu.org]

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

Bug ID: 90246
   Summary: std::bad_variant_access messages are not useful
   Product: gcc
   Version: 8.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

Every exception of type bad_variant_access has the same unhelpful text:

"Unexpected index"

Seeing this in a log file tells you almost nothing. It would be much better to
say:

"std::visit called on valueless variant"

or "std::get<1> called on variant with index 2"

This requires an ABI change, because bad_variant_access currently just stores a
const char* (which is assumed to point to a string with static storage
duration, e.g. a literal).

Something like this would allow us to store a (possibly dynamically allocated)
string in the exception object, so we can provide formatted strings with
additional information:

@@ -1200,13 +1278,21 @@ namespace __variant
   {
   public:
 bad_variant_access() noexcept : _M_reason("Unknown reason") { }
+
 const char* what() const noexcept override
-{ return _M_reason; }
+{ return _M_reason.get(); }

   private:
-bad_variant_access(const char* __reason) : _M_reason(__reason) { }
+// Must only be called with a string literal
+bad_variant_access(const char* __reason, nullptr_t)
+: _M_reason(__reason, [](const char*){})
+{ }
+
+bad_variant_access(const char* __reason)
+: _M_reason(std::strdup(__reason), [](const char* __s) { std::free(__s);
})
+{ }

-const char* _M_reason;
+__shared_ptr _M_reason;

 friend void __throw_bad_variant_access(const char* __what);
   };

[Bug libstdc++/90246] std::bad_variant_access messages are not useful

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-04-25
Version|8.3.1   |9.0
 Ever confirmed|0   |1

[Bug middle-end/90247] New: Reconsider OpenACC implicit data attributes for pointers

[tschwinge at gcc dot gnu.org]

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

Bug ID: 90247
   Summary: Reconsider OpenACC implicit data attributes for
pointers
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: openacc
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
  Target Milestone: ---

We've been reading the OpenACC specification such that a pointer variable is a
scalar (not an array), and thus gets an implicit 'firstprivate' clause (not
some kind of 'copy' clause).  This is not what users appear to expect:

int *p = (int *) malloc([...})
#pragma acc enter data create (p[0:100])

#pragma acc parallel loop // implicit 'firstprivate(p)'
for ([i])
  p[i] = [...]

#pragma acc enter data copyout (p[0:100])

The implicit 'firstprivate' clause will not translate the host 'p' to the
corresponding device 'p' that has been 'create'd above, but will copy the host
pointer value untranslated, leading to run-time failure upon dereferencing the
host 'p' on the device.  What users instead would like is what OpenMP calls
"zero-length array section" mapping.

There is discussion that the OpenACC specification is moving into that
direction.

A patch has been proposed,
,
but needs work.


Then, there are similar considerations to be made for other such data mapping
cases/constructs (not listed here now).

[Bug middle-end/90247] Reconsider OpenACC implicit data attributes for pointers

[tschwinge at gcc dot gnu.org]

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

Thomas Schwinge  changed:

   What|Removed |Added

 Status|UNCONFIRMED |SUSPENDED
   Last reconfirmed||2019-04-25
 Ever confirmed|0   |1

--- Comment #1 from Thomas Schwinge  ---
Suspended until we get clarification about the (at least future) intention of
the OpenACC specification.

[Bug tree-optimization/90245] A data race with a segmentation fault handler

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #3 from Martin Liška  ---
(In reply to Florian Weimer from comment #2)
> I think that handler_called should be volatile sig_atomic_t.  Or you would
> have to add signal fences.

Thanks Florian.

[Bug c++/90248] New: larger than 0 compare fails with -ffinite-math-only -funsafe-math-optimizations

[kau at zurich dot ibm.com]

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

Bug ID: 90248
   Summary: larger than 0 compare fails with -ffinite-math-only
-funsafe-math-optimizations
   Product: gcc
   Version: 8.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kau at zurich dot ibm.com
  Target Milestone: ---

Created attachment 46242
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46242&action=edit
preprocessed minimal example file

Hello,

the following code produces unexpected/different results using gcc 8.2.1 when
compared to gcc 7.3.1

test.cc:
#include 

int main() {
  float a = 0;
  std::cout << a << std::endl;
  a = (a > 0) ? 1.0 : -1.0;
  std::cout << a << std::endl;
  return 0;
}

I would expect this code to print
0
-1

with "gcc version 7.3.1 20180130 (Red Hat 7.3.1-2) (GCC)" it does.
with "gcc version 8.2.1 20181215 (Red Hat 8.2.1-6) (GCC)" it prints
0
1

This behavior depends on the combination of two compiler flags. If either one
is missing, the code behaves as expected.

# g++ -Wall -Wextra -ffinite-math-only -funsafe-math-optimizations  test.cc -o
test; ./test
0
1

# g++ -Wall -Wextra -funsafe-math-optimizations  test.cc -o test; ./test
0
-1

# g++ -Wall -Wextra -ffinite-math-only test.cc -o test; ./test
0
-1

# g++ -Wall -Wextra test.cc -o test; ./test
0
-1

Note that if I replace
  a = (a > 0) ? 1.0 : -1.0;
with
  if (a > 0) a = 1.0; else a = -1.0;

it also works as expected regardless of the compiler version or flags.


Compiler output
# g++ -v -save-temps -Wall -Wextra -ffinite-math-only
-funsafe-math-optimizations  test.cc -o test
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/8/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-redhat-linux
Configured with: ../configure --enable-bootstrap
--enable-languages=c,c++,fortran,objc,obj-c++,ada,go,lto --prefix=/usr
--mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared
--enable-threads=posix --enable-checking=release --enable-multilib
--with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions
--enable-gnu-unique-object --enable-linker-build-id
--with-gcc-major-version-only --with-linker-hash-style=gnu --enable-plugin
--enable-initfini-array --with-isl --enable-libmpx
--enable-offload-targets=nvptx-none --without-cuda-driver
--enable-gnu-indirect-function --enable-cet --with-tune=generic
--with-arch_32=i686 --build=x86_64-redhat-linux
Thread model: posix
gcc version 8.2.1 20181215 (Red Hat 8.2.1-6) (GCC) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-Wextra' '-ffinite-math-only'
'-funsafe-math-optimizations' '-o' 'test' '-shared-libgcc' '-mtune=generic'
'-march=x86-64'
 /usr/libexec/gcc/x86_64-redhat-linux/8/cc1plus -E -quiet -v -D_GNU_SOURCE
test.cc -mtune=generic -march=x86-64 -Wall -Wextra -ffinite-math-only
-funsafe-math-optimizations -fpch-preprocess -o test.ii
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-redhat-linux/8/include-fixed"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-redhat-linux/8/../../../../x86_64-redhat-linux/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/x86_64-redhat-linux/8/../../../../include/c++/8

/usr/lib/gcc/x86_64-redhat-linux/8/../../../../include/c++/8/x86_64-redhat-linux
 /usr/lib/gcc/x86_64-redhat-linux/8/../../../../include/c++/8/backward
 /usr/lib/gcc/x86_64-redhat-linux/8/include
 /usr/local/include
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-Wextra' '-ffinite-math-only'
'-funsafe-math-optimizations' '-o' 'test' '-shared-libgcc' '-mtune=generic'
'-march=x86-64'
 /usr/libexec/gcc/x86_64-redhat-linux/8/cc1plus -fpreprocessed test.ii -quiet
-dumpbase test.cc -mtune=generic -march=x86-64 -auxbase test -Wall -Wextra
-version -ffinite-math-only -funsafe-math-optimizations -o test.s
GNU C++14 (GCC) version 8.2.1 20181215 (Red Hat 8.2.1-6) (x86_64-redhat-linux)
compiled by GNU C version 8.2.1 20181215 (Red Hat 8.2.1-6), GMP version
6.1.2, MPFR version 3.1.6-p2, MPC version 1.0.2, isl version isl-0.16.1-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++14 (GCC) version 8.2.1 20181215 (Red Hat 8.2.1-6) (x86_64-redhat-linux)
compiled by GNU C version 8.2.1 20181215 (Red Hat 8.2.1-6), GMP version
6.1.2, MPFR version 3.1.6-p2, MPC version 1.0.2, isl version isl-0.16.1-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 2c6c0283460e534bb8025645f70a7cfb
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-Wextra' '-ffinite-math-only'
'-funsafe-math-optimizations' '-o' 'test' '-shared-libgcc' '-mtune=generic'
'-march=x86-64'
 as -v --64 -o test.o test.s
GNU assembler version 2.29.1 (x86_64-redhat-lin

[Bug debug/90194] ICE in expand_debug_expr, at cfgexpand.c:5244

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
  Known to work||9.0
  Known to fail|9.0 |

--- Comment #3 from Richard Biener  ---
Fixed on trunk sofar.

[Bug debug/90194] ICE in expand_debug_expr, at cfgexpand.c:5244

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Author: rguenth
Date: Thu Apr 25 11:15:35 2019
New Revision: 270569

URL: https://gcc.gnu.org/viewcvs?rev=270569&root=gcc&view=rev
Log:
2019-04-25  Richard Biener  

PR middle-end/90194
* match.pd: Add pattern to simplify view-conversion of an
empty constructor.

* g++.dg/torture/pr90194.C: New testcase.

Added:
trunk/gcc/testsuite/g++.dg/torture/pr90194.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/match.pd
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/90213] UBSAN: signed integer overflow: -5621332293356458048 * 8 cannot be represented in type 'long int'

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code
  Known to work||9.0

--- Comment #3 from Richard Biener  ---
Fixed on trunk sofar.

[Bug tree-optimization/90213] UBSAN: signed integer overflow: -5621332293356458048 * 8 cannot be represented in type 'long int'

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Author: rguenth
Date: Thu Apr 25 11:17:49 2019
New Revision: 270570

URL: https://gcc.gnu.org/viewcvs?rev=270570&root=gcc&view=rev
Log:
2019-04-24  Richard Biener  

PR middle-end/90213
* gimple-fold.c (fold_const_aggregate_ref_1): Do multiplication
by size and BITS_PER_UNIT on poly-wide-ints.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple-fold.c

[Bug target/89929] __attribute__((target("avx512bw"))) doesn't work on non avx512bw systems

[nheart at gmail dot com]

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

--- Comment #22 from Nikolay Bogoychev  ---
Hey,

I was reading through the mailing list discussion (
https://gcc.gnu.org/ml/gcc-patches/2019-04/msg00757.html ) and I want to say
that currently code like 

void __attribute__ ((target("avx512dq"))) foo ()

Compiles as long as function multi-versioning is not used. Making this syntax
invalid, puts us in a very annoying position, because we can't use the new
recommended syntax due to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90129

That would mean we would have to do some hacky ifdefs to match different
compiler versions.

Is there no other way.

Cheers,

Nick

[Bug debug/90232] gcc drops top-level dies with -fdebug-types-section

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-debug
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-04-25
 CC||rguenth at gcc dot gnu.org
 Ever confirmed|0   |1
  Known to fail||4.8.5

--- Comment #2 from Richard Biener  ---
Confirmed also with gcc 4.8.  -fno-eliminate-unused-debug-types doesn't help
so it's an artifact of the debug-types implementation.

[Bug target/90235] Unnecessary save and restore frame pointer with AVX/AVX512 pseudo registers

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization, ra
 Target||x86_64-*-* i?86-*-*

--- Comment #2 from Richard Biener  ---
Unaligned spills can indeed be slower (they might cross a cache line boundary).

[Bug target/90204] [8/9 Regression] C code is optimized worse than C++

[rguenther at suse dot de]

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

--- Comment #10 from rguenther at suse dot de  ---
On Thu, 25 Apr 2019, crazylht at gmail dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90204
> 
> --- Comment #9 from Hongtao.liu  ---
> Also what's better between aligned load/store of smaller size  VS unaligned 
> load/store of bigger size?
> 
> aligned load/store of smaller size:
> 
> movq%rdx, (%rdi)
> movq-56(%rsp), %rdx
> movq%rdx, 8(%rdi)
> movq-48(%rsp), %rdx
> movq%rdx, 16(%rdi)
> movq-40(%rsp), %rdx
> movq%rdx, 24(%rdi)
> vmovq   %xmm0, 32(%rax)
> movq-24(%rsp), %rdx
> movq%rdx, 40(%rdi)
> movq-16(%rsp), %rdx
> movq%rdx, 48(%rdi)
> movq-8(%rsp), %rdx
> movq%rdx, 56(%rdi)
> 
> unaligned load/store of bigger size:
> 
> vmovups %xmm2, (%rdi)
> vmovups %xmm3, 16(%rdi)
> vmovups %xmm4, 32(%rdi)
> vmovups %xmm5, 48(%rdi)

bigger stores are almost always a win while bigger loads have
the possibility to run into store-to-load forwarding issues
(and bigger stores eventually mitigate them).  Based on
CPU tuning we'd also eventually end up with mov[lh]ps splitting
unaligned loads/stores.

[Bug bootstrap/81963] ICE in stage 2 compiler while configuring libgcc in stage2, during GIMPLE pass: cfg

[rick at snowlight dot net]

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

rick at snowlight dot net changed:

   What|Removed |Added

 CC||rick at snowlight dot net

--- Comment #2 from rick at snowlight dot net ---
Created attachment 46243
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46243&action=edit
32-bit libgcc config.log for *86*-sun-solaris2.10

same here on *86*-sun-solaris2.10 during the 32-bit phase of libgcc
configuration, to say nothing of whether the previous bootstrap phases actually
worked (!)

[Bug bootstrap/81963] ICE in stage 2 compiler while configuring libgcc in stage2, during GIMPLE pass: cfg

[rick at snowlight dot net]

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

--- Comment #3 from rick at snowlight dot net ---
Comment on attachment 46243
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46243
32-bit libgcc config.log for *86*-sun-solaris2.10

note that this was part of a multi-stage build starting from GCC 3.4.3, to GCC
4.2, then miscompiling v8.3 (the last Solaris 2.10 version), since Sun Studio
12.6, while being _reasonably_ C++98/03-compiliant using either
[RogueWave|Apache]STDCXX v4.2+ or libstdc++ v5.4, is unable to bootstrap this
version of GCC, since GCC uses its own extensions to compile itself. Only other
compiler that can compile GCC is Apple C++.

[Bug middle-end/90238] Bogus warning from -Warray-bounds, triggered by zero-length character literal

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-04-25
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Ever confirmed|0   |1
   Severity|enhancement |normal

--- Comment #6 from Richard Biener  ---
Well, the warning code is confused by fortran passing &""[1], ignoring
the one-after-the-array case for

  /* Empty array.  */
  if (up_bound && tree_int_cst_equal (low_bound, up_bound_p1))
warned = warning_at (location, OPT_Warray_bounds,
 "array subscript %E is above array bounds of %qT",
 low_bound, artype);

not sure why this special-case was added here.  I think you can't create
this string literal with a C testcase (you always have the null termination).

I've added this check at r222146 possibly to rule out erratic behavior
in the anti-range handling case as part of the PR64277 fix.

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

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P2  |P1
 Status|UNCONFIRMED |NEW
 Blocks||90078
 Ever confirmed|0   |1

--- Comment #5 from Richard Biener  ---
So the bug is probably latent before the PR90078 change with a "proper"
profile?
(the GIMPLE FE will get counter/freq inputs for GCC 10)

Btw, we have precedence of using GMP for niter analysis so we could switch
the cost computation to using GMP avoiding infinity for anything but the
specially marked IVs.  Would that be prohibitly expensive?

Can you construct a non-GRAPHITE testcase (just reproduce the GRAPHITE
produced loop nest?)?


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90078
[Bug 90078] [7/8 Regression] ICE with deep templates caused by overflow

[Bug target/89929] __attribute__((target("avx512bw"))) doesn't work on non avx512bw systems

[marxin at gcc dot gnu.org]

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

--- Comment #23 from Martin Liška  ---
(In reply to Nikolay Bogoychev from comment #22)
> Hey,
> 
> I was reading through the mailing list discussion (
> https://gcc.gnu.org/ml/gcc-patches/2019-04/msg00757.html ) and I want to say
> that currently code like 
> 
> void __attribute__ ((target("avx512dq"))) foo ()
> 
> Compiles as long as function multi-versioning is not used. Making this
> syntax invalid, puts us in a very annoying position, because we can't use
> the new recommended syntax due to
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90129

No, this will be working as it is now. Suggested changes will only touch C++
features of target attribute (so having multiple functions of the same name
with a different target attribute) and target_clone attribute.

> 
> That would mean we would have to do some hacky ifdefs to match different
> compiler versions.
> 
> Is there no other way.
> 
> Cheers,
> 
> Nick

[Bug middle-end/90241] [UBSAN]: in ao_ref_init_from_ptr_and_size

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-04-25
 CC||rguenth at gcc dot gnu.org
  Component|c   |middle-end
 Ever confirmed|0   |1

--- Comment #2 from Richard Biener  ---
Confirmed.  All the byte->bit conversions on poly_[u]int64 are suspicious.  But
also expensive to fix :/

[Bug tree-optimization/90242] [UBSAN]: in vn_reference_compute_hash

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #2 from Richard Biener  ---
signed offset vs. unsigned size, but on "invalid" input (too large object).

[Bug middle-end/90244] [UBSAN]: in get_object_alignment_2

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-04-25
 CC||rguenth at gcc dot gnu.org
  Component|c   |middle-end
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Similar issue, bit position and poly_int64.

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

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-04-25
  Component|c++ |middle-end
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
We should simplify this to

 a = copysignf (1.0, a);

I guess.

Confirmed on trunk with a C testcase:

int main() {
float a = 0;
__builtin_printf ("%f\n", a);
a = (a > 0) ? 1.0 : -1.0;
__builtin_printf ("%f\n", a);
return 0;
}

And indeed .original already shows (but only with -ffinite-math-only
because of a being possibly NaN).

float a = 0.0;
  __builtin_printf ((const char *) "%f\n", (double) a);
  a = __builtin_copysignf (1.0e+0, a);
  __builtin_printf ((const char *) "%f\n", (double) a);

wrong sign for the copysign transform for zero.

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

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|NEW
 CC||pinskia at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org
  Known to work||7.3.1
  Known to fail||8.1.0, 9.0

--- Comment #2 from Richard Biener  ---
(for cmp (gt ge lt le)
 outp (convert convert negate negate)
 outn (negate negate convert convert)
 /* Transform (X > 0.0 ? 1.0 : -1.0) into copysign(1, X). */
 /* Transform (X >= 0.0 ? 1.0 : -1.0) into copysign(1, X). */
 /* Transform (X < 0.0 ? 1.0 : -1.0) into copysign(1,-X). */
 /* Transform (X <= 0.0 ? 1.0 : -1.0) into copysign(1,-X). */
 (simplify
  (cond (cmp @0 real_zerop) real_onep@1 real_minus_onep)
  (if (!HONOR_NANS (type) && !HONOR_SIGNED_ZEROS (type)
   && types_match (type, TREE_TYPE (@0)))
   (switch
(if (types_match (type, float_type_node))
 (BUILT_IN_COPYSIGNF @1 (outp @0)))
(if (types_match (type, double_type_node))
 (BUILT_IN_COPYSIGN @1 (outp @0)))
(if (types_match (type, long_double_type_node))
 (BUILT_IN_COPYSIGNL @1 (outp @0))

looks like this one is the culprit.  Similar suspicious symmetry with

 /* Transform (X > 0.0 ? -1.0 : 1.0) into copysign(1,-X). */
 /* Transform (X >= 0.0 ? -1.0 : 1.0) into copysign(1,-X). */
 /* Transform (X < 0.0 ? -1.0 : 1.0) into copysign(1,X). */
 /* Transform (X <= 0.0 ? -1.0 : 1.0) into copysign(1,X). */
 (simplify
  (cond (cmp @0 real_zerop) real_minus_onep real_onep@1)
  (if (!HONOR_NANS (type) && !HONOR_SIGNED_ZEROS (type)
   && types_match (type, TREE_TYPE (@0)))
   (switch
(if (types_match (type, float_type_node))
 (BUILT_IN_COPYSIGNF @1 (outn @0)))
(if (types_match (type, double_type_node))
 (BUILT_IN_COPYSIGN @1 (outn @0)))
(if (types_match (type, long_double_type_node))
 (BUILT_IN_COPYSIGNL @1 (outn @0)))

caused by r249704

[Bug c++/44648] missing -Wunused warning on a const variable in if statement

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  ---
Author: jakub
Date: Thu Apr 25 12:18:07 2019
New Revision: 270572

URL: https://gcc.gnu.org/viewcvs?rev=270572&root=gcc&view=rev
Log:
PR c++/44648
* g++.dg/warn/Wunused-var-35.C: Remove xfail.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/warn/Wunused-var-35.C

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

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
In fact the copysign transform, for the cases where we negate X _relies_ on
signed zeros...

Only exact

 /* Transform (X >= 0.0 ? 1.0 : -1.0) into copysign(1, X). */

and

 /* Transform (X < 0.0 ? -1.0 : 1.0) into copysign(1,X). */

look correct to me?

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

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
   Target Milestone|--- |8.4
Summary|larger than 0 compare fails |[8/9 Regression] larger
   |with -ffinite-math-only |than 0 compare fails with
   |-funsafe-math-optimizations |-ffinite-math-only
   ||-funsafe-math-optimizations

[Bug target/89929] __attribute__((target("avx512bw"))) doesn't work on non avx512bw systems

[nheart at gmail dot com]

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

--- Comment #24 from Nikolay Bogoychev  ---
(In reply to Martin Liška from comment #23)
> (In reply to Nikolay Bogoychev from comment #22)
> > Hey,
> > 
> > I was reading through the mailing list discussion (
> > https://gcc.gnu.org/ml/gcc-patches/2019-04/msg00757.html ) and I want to say
> > that currently code like 
> > 
> > void __attribute__ ((target("avx512dq"))) foo ()
> > 
> > Compiles as long as function multi-versioning is not used. Making this
> > syntax invalid, puts us in a very annoying position, because we can't use
> > the new recommended syntax due to
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90129
> 
> No, this will be working as it is now. Suggested changes will only touch C++
> features of target attribute (so having multiple functions of the same name
> with a different target attribute) and target_clone attribute.
> 
> > 
> > That would mean we would have to do some hacky ifdefs to match different
> > compiler versions.
> > 
> > Is there no other way.
> > 
> > Cheers,
> > 
> > Nick

Ok, thank you for the clarification!

Cheers,

Nick

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

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Yeah, all those look quite questionable, -fno-signed-zeros doesn't mean 0.0 or
-0.0 won't appear, just that it shouldn't matter if 0.0 or -0.0 appears.
So the > 0.0 and <= 0.0 cases look completely bogus and the rest too, >= 0.0 or
< 0.0 works regardless of what sign the zero has, while if copysign is used,
then it is significant, and not just in the sign of some zero, but actually
whether the result is -1.0 or 1.0.

[Bug sanitizer/89832] confusing error message when there is a problem with ASAN_OPTIONS "ERROR: expected '='"

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Target Milestone|9.0 |10.0

[Bug sanitizer/88277] ASAN stack poisoning is using unaligned stores on e.g. x86_64

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #3 from Martin Liška  ---
(In reply to Andi Kleen from comment #2)
> FWIW modern x86 CPUs are fairly good at unaligned accesses, so it might not
> be worth it for performance.

That said, I'm leaving that..

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

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
(In reply to Jakub Jelinek from comment #4)
> Yeah, all those look quite questionable, -fno-signed-zeros doesn't mean 0.0
> or -0.0 won't appear, just that it shouldn't matter if 0.0 or -0.0 appears.

Yeah, it means that when a is 0. or -0. the behavior can either
match 0. > 0 ? 1. : -1. or -0. > 0 ? 1. : -1.  So probably the
cases where we negate X are OK-ish in that regard?

> So the > 0.0 and <= 0.0 cases look completely bogus and the rest too, >= 0.0
> or
> < 0.0 works regardless of what sign the zero has, while if copysign is used,
> then it is significant, and not just in the sign of some zero, but actually
> whether the result is -1.0 or 1.0.

[Bug rtl-optimization/90249] New: [9 regression] Code size regression on thumb2 due to sub-optimal register allocation.

[rearnsha at gcc dot gnu.org]

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

Bug ID: 90249
   Summary: [9 regression] Code size regression on thumb2 due to
sub-optimal register allocation.
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: ra
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rearnsha at gcc dot gnu.org
CC: ramana.radhakrishnan at arm dot com, vmakarov at redhat dot 
com,
wdijkstr at arm dot com
  Target Milestone: ---
Target: arm

Created attachment 46244
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46244&action=edit
testcase

GCC 9 has regressed on code size due to some sub-optimal register allocation. 
For this example, the only difference in the output is that the assignments for
r7 and r8 have been switched, but the result is significant growth in code size
since r8 requires predominantly 32-bit instructions to be used while r7
requires predominantly 16-bit instructions.

cc1 -fpreprocessed binding2.i -quiet -dumpbase binding2.i -mthumb
-mcpu=cortex-a8 -march=armv7-a -auxbase-strip binding.o -Os -w -version
-fno-short-enums -fgnu89-inline -o binding2.s

In gcc-8 the output was
DefineConnectorBinding:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
push{r0, r1, r2, r3, r4, r5, r6, r7, r8, lr}
mov r4, r1
mov r8, r0
mov r1, r2
mov r0, r4
mov r5, r2
mov r7, r3
bl  LookupBinding
mov r6, r0
cbz r0, .L2
ldr r7, .L5
mov r1, r4
ldr r0, [r7] // 16-bit instruction
bl  GetAtomString
mov r1, r5
mov r4, r0
ldr r0, [r7] // 16-bit instruction
bl  GetAtomString
ldrhr1, [r6, #8]
mov r5, r0
ldr r0, [r7] // 16-bit instruction
bl  GetAtomString
ldrhr3, [r6, #10]
ldr r2, .L5+4
movsr1, #103
str r5, [sp]
strdr0, r3, [sp, #4]
mov r3, r4
mov r0, r8
bl  SemanticError
add sp, sp, #16
@ sp needed
pop {r4, r5, r6, r7, r8, pc}
.L2:
mov r3, r7
mov r2, r5
mov r1, r4
mov r0, r8
bl  NewConnectorBindingTree
add sp, sp, #16
@ sp needed
pop {r4, r5, r6, r7, r8, lr}
b   AddBinding

In gcc-9 we get

DefineConnectorBinding:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
push{r0, r1, r2, r3, r4, r5, r6, r7, r8, lr}
mov r4, r1
mov r7, r0
mov r1, r2
mov r0, r4
mov r5, r2
mov r8, r3
bl  LookupBinding
mov r6, r0
cbz r0, .L2
ldr r8, .L5+4
mov r1, r4
ldr r0, [r8] // 32-bit instruction
bl  GetAtomString
mov r1, r5
mov r4, r0
ldr r0, [r8] // 32-bit instruction
bl  GetAtomString
ldrhr1, [r6, #8]
mov r5, r0
ldr r0, [r8] // 32-bit instruction
bl  GetAtomString
ldrhr3, [r6, #10]
ldr r2, .L5
movsr1, #103
str r5, [sp]
strdr0, r3, [sp, #4]
mov r3, r4
mov r0, r7
bl  SemanticError
add sp, sp, #16
@ sp needed
pop {r4, r5, r6, r7, r8, pc}
.L2:
mov r3, r8
mov r2, r5
mov r1, r4
mov r0, r7
bl  NewConnectorBindingTree
add sp, sp, #16
@ sp needed
pop {r4, r5, r6, r7, r8, lr}
b   AddBinding

R8 is used more often than R7, so it seems odd that it is preferred over the
latter.

[Bug target/89765] Multiple problems with vec-insert implementation on PowerPC

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

--- Comment #1 from Richard Biener  ---
Seems to work with a cross (but host headers).

[Bug rtl-optimization/90249] [9 regression] Code size regression on thumb2 due to sub-optimal register allocation.

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
   Target Milestone|--- |9.0

[Bug target/90204] [8/9 Regression] C code is optimized worse than C++

[hjl.tools at gmail dot com]

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

--- Comment #11 from H.J. Lu  ---
(In reply to Hongtao.liu from comment #7)
> Yes, C++ with NRV optization, so the alignment of (res) is 4.
> and the alignment of res is 16 in C.
> 
> g++/test.i.158t.vect:
> 
> ../test.i:8:23: note:   recording new base alignment for &
>   alignment:4
>   misalignment: 0
> 
> gcc/test.i.158t.vect:
> 
> ../test.i:8:5: note:   recording new base alignment for &res
>   alignment:16
>   misalignment: 0
> 
> When alignment of res is 16, that triggers loop peeling of vectorization.
> 

Why does struct v have different alignments in C and C++?

[Bug d/90250] New: libphobos: segfault in runtime caused by unexpected GC of TLS data.

[ibuclaw at gdcproject dot org]

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

Bug ID: 90250
   Summary: libphobos: segfault in runtime caused by unexpected GC
of TLS data.
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: ibuclaw at gdcproject dot org
  Target Milestone: ---

The crash is only observed on non Linux/glibc systems.

Reason being because glibc puts the TLS area for each new thread at the
beginning of the newly created stack. Due to the way we detect the stack
bottom, we hoover up the TLS data along with what we think the stack is.

This is of course a dirty implementation detail, but explains why things don't
crash on GNU/Linux the way they are.

---
final class Class
{
// This gets triggered although the instance always stays referenced.
~this()
{
import core.stdc.stdlib;
abort();
}
}

Class obj;

static this()
{
obj = new Class;
}

static ~this()
{
// Free without destruction to avoid triggering abort()
import core.memory;
GC.free(cast(void*)obj);
}

void doit()
{
foreach (i; 0 .. 10_000)
new ubyte[](100_000);
}

void main()
{
import core.thread;
auto t = new Thread(&doit);
t.start();

// This triggers the GC that frees the still referenced Class instance.
doit();
}

[Bug target/90204] [8/9 Regression] C code is optimized worse than C++

[rguenther at suse dot de]

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

--- Comment #12 from rguenther at suse dot de  ---
On Thu, 25 Apr 2019, hjl.tools at gmail dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90204
> 
> --- Comment #11 from H.J. Lu  ---
> (In reply to Hongtao.liu from comment #7)
> > Yes, C++ with NRV optization, so the alignment of (res) is 4.
> > and the alignment of res is 16 in C.
> > 
> > g++/test.i.158t.vect:
> > 
> > ../test.i:8:23: note:   recording new base alignment for &
> >   alignment:4
> >   misalignment: 0
> > 
> > gcc/test.i.158t.vect:
> > 
> > ../test.i:8:5: note:   recording new base alignment for &res
> >   alignment:16
> >   misalignment: 0
> > 
> > When alignment of res is 16, that triggers loop peeling of vectorization.
> > 
> 
> Why does struct v have different alignments in C and C++?

I think we re-align automatic variables but obviously cannot do the
same for incoming DECL_RESULT.

[Bug fortran/88154] [F18] ICE: Intrinsic function '_gfortran_caf_get_team' (119) not recognized

[zbeekman at gmail dot com]

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

Zaak  changed:

   What|Removed |Added

 CC||zbeekman at gmail dot com

--- Comment #2 from Zaak  ---
xref to the OC bug tracker:
https://github.com/sourceryinstitute/OpenCoarrays/issues/545

[Bug bootstrap/87338] gcc 8.2 fails to bootstrap on ia64

[jrtc27 at jrtc27 dot com]

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

James Clarke  changed:

   What|Removed |Added

 CC||jrtc27 at jrtc27 dot com

--- Comment #6 from James Clarke  ---
Created attachment 46245
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46245&action=edit
Proposed patch

Currently performing a test build with this patch, but applying
`s/^.LBI[0-9]*:$/[&]/g` to the stage2 (the one with debug info enabled)
assembly for one of the differing files fixed the differences to the stage3
file, so I'm confident this will fix it (assuming my change actually compiles).

[Bug bootstrap/87338] gcc 8.2 fails to bootstrap on ia64

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||wilson at gcc dot gnu.org

--- Comment #7 from Richard Biener  ---
CCing ia64 port maintainer

[Bug target/89765] Multiple problems with vec-insert implementation on PowerPC

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
The ICE started with r262946.  Short testcase reproduceable with a cross to
powerpc64le-linux with -maltivec -mvsx -O1:
typedef unsigned __int128 V __attribute__((vector_size (sizeof (__int128;

V
foo (unsigned __int128 x, V y, int z)
{
  return __builtin_vec_insert (x, y, z);
}

During gimplification, gimplify_expr does:
12577   *expr_p = fold_indirect_ref_loc (input_location, *expr_p);
12578   if (*expr_p != save_expr)
12579 {
12580   ret = GS_OK;
12581   break;
12582 }
12583   
12584   ret = gimplify_expr (&TREE_OPERAND (*expr_p, 0), pre_p,
post_p,
12585is_gimple_reg, fb_rvalue);
12586   if (ret == GS_ERROR)
12587 break;
on *expr_p:
 
unit-size 
align:128 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7fffea7f7bd0 precision:128 min  max

pointer_to_this >
side-effects
arg:0 
unsigned DI
size 
unit-size 
align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7fffea983f18>
side-effects
arg:0 
side-effects
arg:0 
side-effects addressable
arg:0 
side-effects arg:0 
pr89765.i:6:10 start: pr89765.i:6:10 finish:
pr89765.i:6:29>>
pr89765.i:6:10 start: pr89765.i:6:10 finish: pr89765.i:6:29>
pr89765.i:6:10 start: pr89765.i:6:10 finish: pr89765.i:6:29>
pr89765.i:6:10 start: pr89765.i:6:10 finish: pr89765.i:6:29>
fold_indirect_ref_1 has for this:
14205 else if (VECTOR_TYPE_P (optype)
14206  && type == TREE_TYPE (optype))
14207   {
14208 tree part_width = TYPE_SIZE (type);
14209 tree index = bitsize_int (0);
14210 return fold_build3_loc (loc, BIT_FIELD_REF, type, op,
part_width,
14211 index);
14212   }
but match.pd actually folds that into a VIEW_CONVERT_EXPR and we keep it at the
lhs and ICE during checking.
Without the match.pd change, we used to have:
  D.2803 = y_2(D);
  BIT_FIELD_REF  = x_4(D);
  _6 = D.2803;
even in ssa pass and only ccp1 changed that into:
  _7 = y_2(D);
  _8 = BIT_INSERT_EXPR <_7, x_4(D), 0 (128 bits)>;
  _6 = _8;
Now we ICE already during gimple pass verification.

Shall we special case VIEW_CONVERT_EXPR on lhs of assignment by moving the VCE
to the rhs instead?  Something different?

[Bug bootstrap/87338] gcc 8.2 fails to bootstrap on ia64

[jrtc27 at jrtc27 dot com]

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

--- Comment #8 from James Clarke  ---
Oh, and the reason it didn't show up with an older binutils is because it
didn't support dwarf2 debug_view:

> checking assembler for dwarf2 debug_view support... no

[Bug target/89765] Multiple problems with vec-insert implementation on PowerPC

[kelvin at gcc dot gnu.org]

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

--- Comment #3 from kelvin at gcc dot gnu.org ---
I have found that removing the pattern in match.pd resolves this issue with no
regressions on various powerpc targets.  I have not tested on other platforms.



Index: gcc/match.pd
===
--- gcc/match.pd(revision 270020)
+++ gcc/match.pd(working copy)
@@ -4963,11 +4963,6 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
  (BIT_FIELD_REF @0 @1 @2))

 (simplify
- (BIT_FIELD_REF @0 @1 integer_zerop)
- (if (tree_int_cst_equal (@1, TYPE_SIZE (TREE_TYPE (@0
-  (view_convert @0)))
-
-(simplify
  (BIT_FIELD_REF @0 @1 @2)
  (switch
   (if (TREE_CODE (TREE_TYPE (@0)) == COMPLEX_TYPE

[Bug target/89765] Multiple problems with vec-insert implementation on PowerPC

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
That is not the right thing to do.
Anyway, as for the wrong-code, do you see any gcc version where it actually
passes?  Tried various versions, e.g. r205000, r235000, r250907 and r268427 and
all of them abort, older versions print more messages than newer ones.

[Bug fortran/88154] [F18] ICE: Intrinsic function '_gfortran_caf_get_team' (119) not recognized

[zbeekman at gmail dot com]

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

--- Comment #3 from Zaak  ---
Some additional test cases from the OC bug tracker. These fail using

gfortran -fcoarray=single

and when linking against opencoarrays, so it seems there is an issue on the GCC
side (possibly the OC side too, but let's get -fcoarray=single working first)

-8<

I get a compile error when trying to use the get_team() intrinsic:

program test_get_team
   use, intrinsic :: iso_fortran_env, only: team_type
   type(team_type) :: initial
   initial = get_team()
 end program test_get_team
Compiling the above, I get:

../get-team.f90:4:13:

initial = get_team()
 1
Error: Can't convert INTEGER(4) to TYPE(team_type) at (1)

So, it appears that get_team() returns an integer.

FURTHER...

I then changed the return type to an integer:

program test_get_team
   use, intrinsic :: iso_fortran_env, only: team_type
   integer :: tn
   tn = get_team()
 end program test_get_team

I then get a internal compiler error

[Bug fortran/90237] Bogus warning from -Wdo-subscript

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2019-04-25
 Ever confirmed|0   |1

--- Comment #3 from Dominique d'Humieres  ---
Duplicate of pr85737 and pr87606.

[Bug target/89765] Multiple problems with vec-insert implementation on PowerPC

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
I think the issue is that we gimplify

VIEW_CONVERT_EXPR<__int128 unsigned>(<<< Unknown tree: compound_literal_expr
V D.2833 = y; >>>)

via

12399   case VIEW_CONVERT_EXPR:
12400 if (is_gimple_reg_type (TREE_TYPE (*expr_p))
12401 && is_gimple_reg_type (TREE_TYPE (TREE_OPERAND (*expr_p,
0
12402   {
12403 ret = gimplify_expr (&TREE_OPERAND (*expr_p, 0), pre_p,
12404  post_p, is_gimple_val, fb_rvalue);
(gdb) l
12405 recalculate_side_effects (*expr_p);
12406 break;

when in gimplify_expr with fallback == fb_lvalue and gimple_test_f ==
is_gimple_lvalue.  If we fix that with

Index: gcc/gimplify.c
===
--- gcc/gimplify.c  (revision 270437)
+++ gcc/gimplify.c  (working copy)
@@ -12397,7 +12397,8 @@ gimplify_expr (tree *expr_p, gimple_seq
  break;

case VIEW_CONVERT_EXPR:
- if (is_gimple_reg_type (TREE_TYPE (*expr_p))
+ if ((fallback & fb_rvalue)
+ && is_gimple_reg_type (TREE_TYPE (*expr_p))
  && is_gimple_reg_type (TREE_TYPE (TREE_OPERAND (*expr_p, 0
{
  ret = gimplify_expr (&TREE_OPERAND (*expr_p, 0), pre_p,

then we gimplify to the correct

  VIEW_CONVERT_EXPR<__int128 unsigned>(D.2833) = x;

and yes, we could move the VIEW_CONVERT_EXPR to the RHS as a trick to make
D.2833 SSA rewritable in update-address-taken.

Have to think whether requiring fallback & fb_rvalue is to be used or
if fallback != fb_lvalue is better.  I guess the latter.

[Bug tree-optimization/90037] [9 Regression] -Wnull-dereference false positive after r269302

[law at gcc dot gnu.org]

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

--- Comment #14 from Jeffrey A. Law  ---
Author: law
Date: Thu Apr 25 14:32:16 2019
New Revision: 270574

URL: https://gcc.gnu.org/viewcvs?rev=270574&root=gcc&view=rev
Log:
PR tree-optimization/90037
* Makefile.in (OBJS): Remove tree-ssa-phionlycprop.c
* passes.def: Replace all instance of phi-only cprop with the
lattice propagator.  Move propagation pass from after erroneous
path isolation to before erroneous path isolation.
* tree-ssa-phionlycprop.c: Remove.

* gcc.dg/tree-ssa/20030710-1.c: Update dump file to scan.
* gcc.dg/isolate-2.c: Likewise.
* gcc.dg/isolate-4.c: Likewise.
* gcc.dg/pr19431.c: Accept either ordering of PHI args.
* gcc.dg/pr90037.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr90037.c
Removed:
trunk/gcc/tree-ssa-phionlycprop.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/Makefile.in
trunk/gcc/passes.def
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/tree-ssa/20030710-1.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/isolate-2.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/isolate-4.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr19431.c

[Bug middle-end/86172] [meta-bug] issues with -Wnull-dereference

[law at redhat dot com]

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

Bug 90037 Summary: [9 Regression] -Wnull-dereference false positive after 
r269302
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90037

   What|Removed |Added

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

[Bug middle-end/89765] Multiple problems with vec-insert implementation on PowerPC

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-04-25
  Component|target  |middle-end
   Assignee|kelvin at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Ever confirmed|0   |1

[Bug tree-optimization/90037] [9 Regression] -Wnull-dereference false positive after r269302

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

--- Comment #15 from Jeffrey A. Law  ---
Fixed on trunk.

[Bug middle-end/89765] Multiple problems with vec-insert implementation on PowerPC

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
Actually we use is_gimple_val so testing fallback & fb_rvalue.

[Bug middle-end/89765] [9 Regression] Multiple problems with vec-insert implementation on PowerPC

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|--- |9.0
Summary|Multiple problems with  |[9 Regression] Multiple
   |vec-insert implementation   |problems with vec-insert
   |on PowerPC  |implementation on PowerPC

--- Comment #7 from Jakub Jelinek  ---
Making this a regression for the ICE, for the wrong-code we don't have a proof
of it being a regression.

[Bug middle-end/89765] [9 Regression] Multiple problems with vec-insert implementation on PowerPC

[rguenth at gcc dot gnu.org]

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

--- Comment #8 from Richard Biener  ---
Btw, the C notation

typedef unsigned __int128 V __attribute__((vector_size (sizeof (__int128;

V
foo (unsigned __int128 x, V y, int z)
{
  y[0] = x;
}

on x86_64 prouces

{
  VIEW_CONVERT_EXPR<__int128 unsigned[1]>(y)[0] = x;
}

the array-ref prevents the gimplification into SSA.  That also works
for variable indices btw.  It is eventually turns into

  BIT_FIELD_REF  = x_2(D);

by gimplification first and then

  y_5 = BIT_INSERT_EXPR ;

by update-address-taken.  Not sure why the folding doesn't trigger here
but does for ppc64.  The BIT_FIELD_REF is produced by
maybe_canonicalize_mem_ref_addr which uses build3 instead of fold_build3
to build the BIT_FIELD_REF (probably not expecting simplification or
avoding constant folding on the LHS).  Indeed using fold_build3 there
gets us

  VIEW_CONVERT_EXPR<__int128 unsigned>(y) = x;

[Bug target/88809] do not use rep-scasb for inline strlen/memchr

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Target Milestone|--- |10.0

[Bug d/90250] libphobos: segfault in runtime caused by unexpected GC of TLS data.

[ibuclaw at gcc dot gnu.org]

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

--- Comment #1 from ibuclaw at gcc dot gnu.org ---
Author: ibuclaw
Date: Thu Apr 25 15:31:35 2019
New Revision: 270576

URL: https://gcc.gnu.org/viewcvs?rev=270576&root=gcc&view=rev
Log:
libphobos: Fix segfault in runtime caused by unexpected GC of TLS data.

libphobos/ChangeLog:

2019-04-25  Iain Buclaw  

PR d/90250
* libdruntime/gcc/sections/elf_shared.d (initTLSRanges): Populate
_tlsRanges in every startup thread.
* testsuite/libphobos.thread/thread.exp: Load libphobos-dg.exp.
* testsuite/libphobos.thread/tlsgc_sections.d: New test.

Added:
trunk/libphobos/testsuite/libphobos.thread/tlsgc_sections.d
Modified:
trunk/libphobos/ChangeLog
trunk/libphobos/libdruntime/gcc/sections/elf_shared.d
trunk/libphobos/testsuite/libphobos.thread/thread.exp

[Bug d/90250] libphobos: segfault in runtime caused by unexpected GC of TLS data.

[ibuclaw at gdcproject dot org]

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

Iain Buclaw  changed:

   What|Removed |Added

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

--- Comment #2 from Iain Buclaw  ---
Done in r270576.

[Bug c/90036] [8/9 Regression] false positive: directive argument is null [-Werror=format-overflow=]

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com
   Target Milestone|8.4 |10.0

--- Comment #2 from Jeffrey A. Law  ---
My tester had tripped over this a while back.  I'd been meaning to dig into it
since it was clearly a false positive.

With the reduced testcase (I'll attach it shortly) the key path is blocks
2->9->4->6 which have the following contents:


;;   basic block 2, loop depth 0
;;pred:   ENTRY
  _1 = vptr_14(D) == 0;
  _2 = ownvptr_15(D) != 0;
  _3 = _1 | _2;
  if (_3 != 0)
goto ; [67.00%]
  else
goto ; [33.00%]

;;   basic block 9, loop depth 0
;;pred:   2
  if (vptr_14(D) != 0)
goto ; [33.33%]
  else
goto ; [66.67%]


;;   basic block 4, loop depth 0
;;pred:   9
  if (ownvptr_15(D) != 0)
goto ; [100.00%]
  else
goto ; [0.00%]

;;   basic block 6, loop depth 0
;;pred:   4
;;3
  # definition_36 = PHI <0(4), definition_17(3)>
  # vstring_38 = PHI <0B(4), vstring_19(3)>
  _5 = strlen (vstring_38);
  _6 = _5 + 3;
  vtable_21 = xmalloc (_6);
  sprintf (vtable_21, "~%%%s", vstring_38);
  if (definition_36 != 0)
goto ; [97.40%]
  else
goto ; [2.60%]


We can obviously see the path 2->4->9->6 is not feasible, but DOM isn't going
to be able to make that determination.  ie when we traverse 2->4 it knows that
_3 is true, but it doesn't know if that's because _1 is true or because _2 is
true and it's incapable of tracking the relationship between them.

DOM is going to thread the edge 4->6 to target bb8.  This will result in the
path morphing a bit into 2->8->4->9.  The key blocks look like this after DOM
has completed:

;;   basic block 2, loop depth 0
;;pred:   ENTRY
  _1 = vptr_14(D) == 0;
  _2 = ownvptr_15(D) != 0;
  _3 = _1 | _2;
  if (_3 != 0)
goto ; [67.00%]
  else
goto ; [33.00%]


;;   basic block 8, loop depth 0
;;pred:   2
  if (vptr_14(D) != 0)
goto ; [33.33%]
  else
goto ; [66.67%]

;;   basic block 4, loop depth 0
;;pred:   8
  if (_2 != 0)
goto ; [100.00%]
  else
goto ; [0.00%]

;;   basic block 9, loop depth 0
;;pred:   4
  # definition_37 = PHI <0(4)>
  # vstring_11 = PHI <0B(4)>
  _33 = strlen (vstring_11);
  _35 = _33 + 3;
  vtable_31 = xmalloc (_35);
  sprintf (vtable_31, "~%%%s", vstring_11);
  goto ; [100.00%]

bb9 is a clone of what was previously bb6, but it's isolated so that we
threading could change it without affecting the non-threaded path.

But the key issue remains, DOM can't track the relationship between vptr and
ownvptr.

This is actually the kind of thing I'd like to be able to use the predicate
analysis found in tree-ssa-uninit.c to fix.

Anyway, there's very very little chance this will be fixed for gcc-9. 
Deferring out.

[Bug rtl-optimization/90249] [9 Regression] Code size regression on thumb2 due to sub-optimal register allocation starting with r265398

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P2
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-04-25
 CC||jakub at gcc dot gnu.org,
   ||segher at gcc dot gnu.org
Summary|[9 regression] Code size|[9 Regression] Code size
   |regression on thumb2 due to |regression on thumb2 due to
   |sub-optimal register|sub-optimal register
   |allocation. |allocation starting with
   ||r265398
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Started with r265398.  Doesn't look severe enough to block a release at this
point, a lot of code changed with that change.

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

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #6 from Jakub Jelinek  ---
(In reply to Richard Biener from comment #5)
> (In reply to Jakub Jelinek from comment #4)
> > Yeah, all those look quite questionable, -fno-signed-zeros doesn't mean 0.0
> > or -0.0 won't appear, just that it shouldn't matter if 0.0 or -0.0 appears.
> 
> Yeah, it means that when a is 0. or -0. the behavior can either
> match 0. > 0 ? 1. : -1. or -0. > 0 ? 1. : -1.  So probably the
> cases where we negate X are OK-ish in that regard?

Well, AFAIK 0. > 0 is 0 and -0. > 0 is also 0.
And similarly 0.0 >= 0 is 1 and -0.0 >= 0 is also 1.  So the a > 0 ? 1.0 : -1.0
expression is completely insensitive to signed zeros and so is a >= 0 ? 1.0 :
-1.0.  With the a > 0 ? 1.0 : -1.0 to copysign (1.0, a) transformation it is
also insensitive to sign of zero, but wrong for both -0.0 and 0.0.  With the a
>= 0 ? 1.0 : -1.0 to copysign (1.0, a) it is correct for +0.0 and incorrect for
-0.0, so
what has been previously insensitive to the sign of zero is now sensitive to
it.

[Bug libstdc++/90246] std::bad_variant_access messages are not useful

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
It's too late to change this now, but we could still improve the messages:

--- a/libstdc++-v3/include/std/variant
+++ b/libstdc++-v3/include/std/variant
@@ -1200,10 +1200,12 @@ namespace __variant
   {
   public:
 bad_variant_access() noexcept : _M_reason("Unknown reason") { }
+
 const char* what() const noexcept override
 { return _M_reason; }

   private:
+// Must only be called with a string literal
 bad_variant_access(const char* __reason) : _M_reason(__reason) { }

 const char* _M_reason;
@@ -1211,10 +1213,20 @@ namespace __variant
 friend void __throw_bad_variant_access(const char* __what);
   };

+  // Must only be called with a string literal
   inline void
   __throw_bad_variant_access(const char* __what)
   { _GLIBCXX_THROW_OR_ABORT(bad_variant_access(__what)); }

+  inline void
+  __throw_bad_variant_access(bool __valueless)
+  {
+if (__valueless) [[__unlikely__]]
+  __throw_bad_variant_access("std::get: variant is valueless");
+else
+  __throw_bad_variant_access("std::get: wrong index for variant");
+  }
+
   template
 class variant
 : private __detail::__variant::_Variant_base<_Types...>,
@@ -1584,7 +1596,7 @@ namespace __variant
   static_assert(_Np < sizeof...(_Types),
"The index should be in [0, number of alternatives)");
   if (__v.index() != _Np)
-   __throw_bad_variant_access("Unexpected index");
+   __throw_bad_variant_access(__v.valueless_by_exception());
   return __detail::__variant::__get<_Np>(__v);
 }

@@ -1595,7 +1607,7 @@ namespace __variant
   static_assert(_Np < sizeof...(_Types),
"The index should be in [0, number of alternatives)");
   if (__v.index() != _Np)
-   __throw_bad_variant_access("Unexpected index");
+   __throw_bad_variant_access(__v.valueless_by_exception());
   return __detail::__variant::__get<_Np>(std::move(__v));
 }

@@ -1606,7 +1618,7 @@ namespace __variant
   static_assert(_Np < sizeof...(_Types),
"The index should be in [0, number of alternatives)");
   if (__v.index() != _Np)
-   __throw_bad_variant_access("Unexpected index");
+   __throw_bad_variant_access(__v.valueless_by_exception());
   return __detail::__variant::__get<_Np>(__v);
 }

@@ -1617,7 +1629,7 @@ namespace __variant
   static_assert(_Np < sizeof...(_Types),
"The index should be in [0, number of alternatives)");
   if (__v.index() != _Np)
-   __throw_bad_variant_access("Unexpected index");
+   __throw_bad_variant_access(__v.valueless_by_exception());
   return __detail::__variant::__get<_Np>(std::move(__v));
 }

@@ -1648,7 +1660,7 @@ namespace __variant
 visit(_Visitor&& __visitor, _Variants&&... __variants)
 {
   if ((__variants.valueless_by_exception() || ...))
-   __throw_bad_variant_access("Unexpected index");
+   __throw_bad_variant_access("std::visit: variant is valueless");

   return __do_visit(std::forward<_Visitor>(__visitor),
std::forward<_Variants>(__variants)...);
@@ -1660,7 +1672,7 @@ namespace __variant
 visit(_Visitor&& __visitor, _Variants&&... __variants)
 {
   if ((__variants.valueless_by_exception() || ...))
-   __throw_bad_variant_access("Unexpected index");
+   __throw_bad_variant_access("std::visit: variant is valueless");

   if constexpr (std::is_void_v<_Res>)
 (void) __do_visit(std::forward<_Visitor>(__visitor),

[Bug tree-optimization/89689] [7/8/9 regression] false warning -Wstringop-overflow=

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com
   Target Milestone|7.5 |10.0

--- Comment #3 from Jeffrey A. Law  ---
It's almost certainly the case that we've duplicated the block with the call to
builtin_memcpy_chk so that we can thread jumps and remove the second   if (p !=
__sb_slop) test.


In .forwprop2 we have:

;;   basic block 4, loop depth 0
;;pred:   2
;;3
  _1 = __builtin_object_size (p_4(D), 0);
  __builtin___memcpy_chk (p_4(D), "abcd", 4, _1);
  if (p_4(D) != &__sb_slop)
goto ; [70.00%]
  else
goto ; [30.00%]

Which is exactly what we'd expect.  Then objsz2 runs resulting in:

;;   basic block 4, loop depth 0
;;pred:   2
;;3
  _1 = __builtin_object_size (p_4(D), 0);
  __builtin_memcpy (p_4(D), "abcd", 4);
  if (p_4(D) != &__sb_slop)
goto ; [70.00%]
  else
goto ; [30.00%]

What's happened here?  Well, objsz evaluated the _b_o_s call and determined it
was undeterminable (-1) and transformed the memcpy_chk to a standard memcpy.

The key point is we had an indeterminable size and transformed the _chk into a
standard memcpy.

Jump threading comes along and duplicates the block.  As a result on the
duplicated path we'll know that p_4 points to sb_slop and thus has a size of 1.
 That causes the memcpy of 4 bytes to trigger the warning.

I would hazard a guess that the original user code didn't have the calls to
_builtin_object_size and __builtin__memcpy_chk, but that those instead came in
via the glibc header files.

This certainly isn't going to be fixed for gcc-9 (possibly ever).

And FWIW, I think marking things with TREE_NO_WARNING at the time we convert
the memcpy_chk to a memcpy would be fundamentally wrong in the case where the
__b_o_s call returned -1 (indeterminate size).  It'll hide real bugs.

[Bug other/90251] New: missing spaces in string literals

[roland.illig at gmx dot de]

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

Bug ID: 90251
   Summary: missing spaces in string literals
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: roland.illig at gmx dot de
  Target Milestone: ---

Created attachment 46246
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46246&action=edit
linter for string literals

From engtype.c:

  printf ("\t -D | --debug "
  " \t# Give debug output to debug %s itself.\n", progname);

Splitting the string literal in the middle of two spaces looks arbitrary. This
applies to all string literals in print_usage.

From tree-ssa-loop-ch.c:

fprintf (dump_file,
 "  Not duplicating bb %i: condition based on non-IV loop"
 "variant.\n", header->index);

From tree-vect-data-refs.c:

return opt_result::failure_at (stmt_info->stmt,
   "not vectorized:"
   "not suitable for strided load %G",
   stmt_info->stmt);

From locales.c:

  "US", "United-States"
  "UY", "Uruguay",

The comma is missing at the end of the upper line.

From arc.c:

fprintf (dump_file, ";; loop %d has a control like last insn;"
 "add a nop\n",
 loop->loop_no);


fprintf (dump_file, ";; loop %d has a label as last insn;"
 "add a nop\n",
 loop->loop_no);

fprintf (dump_file, ";; loop %d has no fallthru edge jumping"
 "into the loop\n",
 loop->loop_no);

From rx.c:

  warning (0, "unrecognized control register number: %d"
   "- using %", (int) INTVAL (op));


From decl.c:

error ("too many braces around scalar initializer"
   "for type %qT", type);


From parser.c:

pedwarn (DECL_SOURCE_LOCATION (decl), OPT_Wpedantic,
 "ISO C++ did not adopt string literal operator templa"
 "tes taking an argument pack of characters");

This one is different. There's not really a space missing, but proper line
breaking. Breaking the line in the middle of a word is really ugly.

From parser.h:

  } GTY((desc ("(%1.type == CPP_TEMPLATE_ID)"
   "|| (%1.type == CPP_NESTED_NAME_SPECIFIER)"
   "|| (%1.type == CPP_DECLTYPE)"))) u;

If there's a space after the || operator, there should be one before the
operator, too.

From tree.c:

w = warning_at (loc, OPT_Wabi, "%<-fabi-version=12%> (GCC 8.1) accident"
"ally changes the calling convention for %qT", t);

Nothing missing again, only the line breaking is ugly, as pointed out above.



I found all the above issues by manually inspecting the output of the attached
linter. That linter could be placed in the contrib/ folder.

[Bug other/90251] missing spaces in string literals

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
> From parser.h:

  } GTY((desc ("(%1.type == CPP_TEMPLATE_ID)"
   "|| (%1.type == CPP_NESTED_NAME_SPECIFIER)"
   "|| (%1.type == CPP_DECLTYPE)"))) u;

> If there's a space after the || operator, there should be one before the 
> operator, too.

This one does not matter that much.  Because it is C code in the end.