[Bug target/108758] [12/13 Regression] gcc.target/powerpc/float128-cmp2-runnable.c fails with excess errors on power 9 BE since r12-5752

[linkw at gcc dot gnu.org via Gcc-bugs]

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

Kewen Lin  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 CC||linkw at gcc dot gnu.org
   Last reconfirmed||2023-04-26
 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |linkw at gcc dot gnu.org
Summary|gcc.target/powerpc/float128 |[12/13 Regression]
   |-cmp2-runnable.c fails with |gcc.target/powerpc/float128
   |excess errors on power 9 BE |-cmp2-runnable.c fails with
   ||excess errors on power 9 BE
   ||since r12-5752

[Bug target/108758] gcc.target/powerpc/float128-cmp2-runnable.c fails with excess errors on power 9 BE

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by Kewen Lin :

https://gcc.gnu.org/g:33a44e3aa81f9fdf8f6b87018abd4c664e545b53

commit r14-240-g33a44e3aa81f9fdf8f6b87018abd4c664e545b53
Author: Kewen Lin 
Date:   Wed Apr 26 00:21:14 2023 -0500

rs6000: Guard power9-vector for vsx_scalar_cmp_exp_qp_* [PR108758]

__builtin_vsx_scalar_cmp_exp_qp_{eq,gt,lt,unordered} used
to be guarded with condition TARGET_P9_VECTOR before new
bif framework was introduced (r12-5752-gd08236359eb229),
since r12-5752 they are placed under stanza ieee128-hw,
that is to check condition TARGET_FLOAT128_HW, it caused
test case float128-cmp2-runnable.c to fail at -m32 as the
condition TARGET_FLOAT128_HW isn't satisified with -m32.

By checking the commit history, I didn't see any notes on
why this condition change on them was made, so this patch
is to move these bifs from stanza ieee128-hw to stanza
power9-vector as before.

PR target/108758

gcc/ChangeLog:

* config/rs6000/rs6000-builtins.def
(__builtin_vsx_scalar_cmp_exp_qp_eq,
__builtin_vsx_scalar_cmp_exp_qp_gt
__builtin_vsx_scalar_cmp_exp_qp_lt,
__builtin_vsx_scalar_cmp_exp_qp_unordered): Move from stanza
ieee128-hw
to power9-vector.

[Bug target/109069] [12/13/14 Regression] Vector truncation test program produces incorrect result since r12-6537-g080a06fcb076b3

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #8 from CVS Commits  ---
The master branch has been updated by Kewen Lin :

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

commit r14-239-gfd75f6ae5625f087980ff4a7e76cc6284cfe5a3e
Author: Kewen Lin 
Date:   Wed Apr 26 00:21:05 2023 -0500

rs6000: Fix predicate for const vector in sldoi_to_mov [PR109069]

As PR109069 shows, commit r12-6537-g080a06fcb076b3 which
introduces define_insn_and_split sldoi_to_mov adopts
easy_vector_constant for const vector of interest, but it's
wrong since predicate easy_vector_constant doesn't guarantee
each byte in the const vector is the same.  One counter
example is the const vector in pr109069-1.c.  This patch is
to introduce new predicate const_vector_each_byte_same to
ensure all bytes in the given const vector are the same by
considering both int and float, meanwhile for the constants
which don't meet easy_vector_constant we need to gen a move
instead of just a set, and uses VECTOR_MEM_ALTIVEC_OR_VSX_P
rather than VECTOR_UNIT_ALTIVEC_OR_VSX_P for V2DImode support
under VSX since vector long long type of vec_sld is guarded
under stanza vsx.

PR target/109069

gcc/ChangeLog:

* config/rs6000/altivec.md (sldoi_to_mov): Replace predicate
easy_vector_constant with const_vector_each_byte_same, add
handlings in preparation for !easy_vector_constant, and update
VECTOR_UNIT_ALTIVEC_OR_VSX_P with VECTOR_MEM_ALTIVEC_OR_VSX_P.
* config/rs6000/predicates.md (const_vector_each_byte_same): New
predicate.

gcc/testsuite/ChangeLog:

* gcc.target/powerpc/pr109069-1.c: New test.
* gcc.target/powerpc/pr109069-2-run.c: New test.
* gcc.target/powerpc/pr109069-2.c: New test.
* gcc.target/powerpc/pr109069-2.h: New test.

[Bug target/109272] RISCV: vbool*_t opportunities of a better code generation

[kito at gcc dot gnu.org via Gcc-bugs]

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

Kito Cheng  changed:

   What|Removed |Added

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

--- Comment #2 from Kito Cheng  ---
Fixed on trunk

[Bug target/109272] RISCV: vbool*_t opportunities of a better code generation

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by Kito Cheng :

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

commit r14-235-ga8d5e14f524283484c2a466353f92f7eaadae9f7
Author: Pan Li 
Date:   Tue Apr 25 22:29:04 2023 +0800

RISC-V: Bugfix for RVV vbool*_t vn_reference_equal

In most architecture the precision_size of vbool*_t types are caculated
like as the multiple of the type size.  For example:
precision_size = type_size * 8 (aka, bit count per bytes).

Unfortunately, some architecture like RISC-V will adjust the
precision_size
for the vbool*_t in order to align the ISA. For example as below.
type_size  = [1, 1, 1, 1,  2,  4,  8]
precision_size = [1, 2, 4, 8, 16, 32, 64]

Then the precision_size of RISC-V vbool*_t will not be the multiple of
the
type_size. This PATCH try to enrich this case when comparing the
vn_reference.

Given we have the below code:
void test_vbool8_then_vbool16(int8_t * restrict in, int8_t * restrict
out) {
vbool8_t v1 = *(vbool8_t*)in;
vbool16_t v2 = *(vbool16_t*)in;

*(vbool8_t*)(out + 100) = v1;
*(vbool16_t*)(out + 200) = v2;
}

Before this PATCH:
csrrt0,vlenb
sllit1,t0,1
csrra3,vlenb
sub sp,sp,t1
sllia4,a3,1
add a4,a4,sp
addia2,a1,100
vsetvli a5,zero,e8,m1,ta,ma
sub a3,a4,a3
vlm.v   v24,0(a0)
vsm.v   v24,0(a2)
vsm.v   v24,0(a3)
addia1,a1,200
csrrt0,vlenb
vsetvli a4,zero,e8,mf2,ta,ma
sllit1,t0,1
vlm.v   v24,0(a3)
vsm.v   v24,0(a1)
add sp,sp,t1
jr  ra

After this PATCH:
addia3,a1,100
vsetvli a4,zero,e8,m1,ta,ma
addia1,a1,200
vlm.v   v24,0(a0)
vsm.v   v24,0(a3)
vsetvli a5,zero,e8,mf2,ta,ma
vlm.v   v24,0(a0)
vsm.v   v24,0(a1)
ret

PR target/109272

gcc/ChangeLog:

* tree-ssa-sccvn.cc (vn_reference_eq): add type vector subparts
check for vn_reference equal.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/rvv/base/pr108185-4.c: Update test check
condition.
* gcc.target/riscv/rvv/base/pr108185-5.c: Likewise.
* gcc.target/riscv/rvv/base/pr108185-6.c: Likewise.

Signed-off-by: Pan Li 

[Bug target/109610] [14 regression] gcc.target/powerpc/dform-3.c fails after r14-172-g0368d169492017

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Hongtao.liu  ---
> 1 unit cost is aligned with what's did in recog_reg_class
> 
> /* If the alternative actually allows memory, make
>things a bit cheaper since we won't need an extra
>insn to load it.  */
> pp->mem_cost
>   = ((out_p ? ira_memory_move_cost[mode][op_class][0] : 0)
>  + (in_p ? ira_memory_move_cost[mode][op_class][1] : 0)
>  - allows_mem[i]) * frequency;

But it regressed other cases, .i.e

gcc/testsuite/gcc.target/i386/pr18041-1.c

[Bug tree-optimization/100958] two_value_replacement should move to match.pd

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #2 from Andrew Pinski  ---
Created attachment 54923
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54923=edit
Patch which is under testing

[Bug target/109629] internal compiler error: in final_scan_insn_1, at final.c:3078 6480 | }

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #19 from Andrew Pinski  ---
(In reply to Linus from comment #18)
> By the way, same code didn't survive aarch64 gcc 9.3.1, but did survive X86
> gcc 9.3.1 -- devtoolset-9-gcc-9.3.1-2.el7.x86_64.
> Do you have any clue about it?

Yes it is a target specific issue. Again if you want a fix for these
devtoolset, please talk with Redhat, we don't support them here.

[Bug target/109629] internal compiler error: in final_scan_insn_1, at final.c:3078 6480 | }

[linus.zhu at mavenir dot com via Gcc-bugs]

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

--- Comment #18 from Linus  ---
(In reply to Andrew Pinski from comment #17)
> (In reply to Linus from comment #16)
> > (In reply to Andrew Pinski from comment #15)
> > > Already fixed.
> > > 
> > > *** This bug has been marked as a duplicate of bug 98136 ***
> > 
> > Thanks.
> > 
> > 1. 98136 was fixed for gcc 9.2.0. So original gcc 10 includes the fix, 
> > right?
> > 2. I still saw the issue with gcc 10 just because of the fix was not picked
> > by devtoolset-10-gcc-c++-10.2.1-11.2.el7.aarch64, right?
> 
> It was NOT fixed in GCC 9.2.0 but rather 9.4.0; it was reported against
> 9.2.0 though.
> 
> The versions which incldue the fix: 10.4.0, 11.1.0, 8.5.0, 9.4.0 (and above
> versions, e.g. 12.1.0).

Great thanks, Andrew, for your time and effort.

By the way, same code didn't survive aarch64 gcc 9.3.1, but did survive X86 gcc
9.3.1 -- devtoolset-9-gcc-9.3.1-2.el7.x86_64.
Do you have any clue about it?

Again, thanks for the great support!

[Bug target/109629] internal compiler error: in final_scan_insn_1, at final.c:3078 6480 | }

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #17 from Andrew Pinski  ---
(In reply to Linus from comment #16)
> (In reply to Andrew Pinski from comment #15)
> > Already fixed.
> > 
> > *** This bug has been marked as a duplicate of bug 98136 ***
> 
> Thanks.
> 
> 1. 98136 was fixed for gcc 9.2.0. So original gcc 10 includes the fix, right?
> 2. I still saw the issue with gcc 10 just because of the fix was not picked
> by devtoolset-10-gcc-c++-10.2.1-11.2.el7.aarch64, right?

It was NOT fixed in GCC 9.2.0 but rather 9.4.0; it was reported against 9.2.0
though.

The versions which incldue the fix: 10.4.0, 11.1.0, 8.5.0, 9.4.0 (and above
versions, e.g. 12.1.0).

[Bug target/109629] internal compiler error: in final_scan_insn_1, at final.c:3078 6480 | }

[linus.zhu at mavenir dot com via Gcc-bugs]

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

--- Comment #16 from Linus  ---
(In reply to Andrew Pinski from comment #15)
> Already fixed.
> 
> *** This bug has been marked as a duplicate of bug 98136 ***

Thanks.

1. 98136 was fixed for gcc 9.2.0. So original gcc 10 includes the fix, right?
2. I still saw the issue with gcc 10 just because of the fix was not picked by
devtoolset-10-gcc-c++-10.2.1-11.2.el7.aarch64, right?

[Bug target/109629] internal compiler error: in final_scan_insn_1, at final.c:3078 6480 | }

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|WAITING |RESOLVED

--- Comment #15 from Andrew Pinski  ---
Already fixed.

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

[Bug target/98136] [8 Regression] [aarch64] Internal compiler error with large classes and virtual methods since r8-5967-gf5470a77425a54efebfe1732488c40f05ef176d0

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||linus.zhu at mavenir dot com

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

[Bug target/109629] internal compiler error: in final_scan_insn_1, at final.c:3078 6480 | }

[linus.zhu at mavenir dot com via Gcc-bugs]

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

--- Comment #14 from Linus  ---
devtoolset-9-gcc-9.3.1-2.2.el7.aarch64

devtoolset-9-gcc-9.3.1-2.el7.x86_64

[Bug target/109629] internal compiler error: in final_scan_insn_1, at final.c:3078 6480 | }

[linus.zhu at mavenir dot com via Gcc-bugs]

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

--- Comment #13 from Linus  ---
(In reply to Andrew Pinski from comment #12)
> (In reply to Linus from comment #10)
> > (In reply to Andrew Pinski from comment #5)
> > > /* If we have a length attribute, this instruction should have
> > >been split in shorten_branches, to ensure that we would have
> > >valid length info for the splitees.  */
> > > gcc_assert (!HAVE_ATTR_length);
> > 
> > Yes, when I checked source code of gcc 11, I saw them.
> 
> > I just wait for your new response, right?
> > Thanks for checking the issue.
> 
> No, I was just pointing out where the ICE is happening. But really it is
> something inside the target backend's md file. Still need to reduce/debug it
> to figure out which pattern is not being split.
> 
> Also Please FILE this with redhat since this is a redhat modified compiler
> first.

Okay and thanks.
Is there a chance that this issue will be gone if I try the original gcc 9 or
gcc 10?
By the way, same code didn't survive aarch64 gcc 9.3.1, but did survive X86 gcc
9.3.1.

[Bug target/109629] internal compiler error: in final_scan_insn_1, at final.c:3078 6480 | }

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #12 from Andrew Pinski  ---
(In reply to Linus from comment #10)
> (In reply to Andrew Pinski from comment #5)
> > /* If we have a length attribute, this instruction should have
> >been split in shorten_branches, to ensure that we would have
> >valid length info for the splitees.  */
> > gcc_assert (!HAVE_ATTR_length);
> 
> Yes, when I checked source code of gcc 11, I saw them.

> I just wait for your new response, right?
> Thanks for checking the issue.

No, I was just pointing out where the ICE is happening. But really it is
something inside the target backend's md file. Still need to reduce/debug it to
figure out which pattern is not being split.

Also Please FILE this with redhat since this is a redhat modified compiler
first.

[Bug target/109629] internal compiler error: in final_scan_insn_1, at final.c:3078 6480 | }

[linus.zhu at mavenir dot com via Gcc-bugs]

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

--- Comment #11 from Linus  ---
(In reply to Andrew Pinski from comment #9)
> (In reply to Linus from comment #8)
> > hi Andrew, thanks. And before raising another ticket for attaching the
> > second half of ccdNSTWA.out, I did try to add one more attachment to this
> > bug, but it hinted that previous one will be obsolete.
> 
> No it will not. It says:
> "(optional) Check each existing attachment made obsolete by your new
> attachment."
> See the optional part. It will only make it is obsolete if you chose to do
> that.

Thanks for the clarification.

[Bug target/109629] internal compiler error: in final_scan_insn_1, at final.c:3078 6480 | }

[linus.zhu at mavenir dot com via Gcc-bugs]

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

--- Comment #10 from Linus  ---
(In reply to Andrew Pinski from comment #5)
> /* If we have a length attribute, this instruction should have
>been split in shorten_branches, to ensure that we would have
>valid length info for the splitees.  */
> gcc_assert (!HAVE_ATTR_length);

Yes, when I checked source code of gcc 11, I saw them.

And I saw:
"
Tue Mar 18 16:12:28 1997  Jim Wilson  

* final.c (shorten_branches): Split all insns before computing insn
lengths.
(final_scan_insn, case default): If HAVE_ATTR_length defined, call
abort for any insn that has a '#' output template.

"


I just wait for your new response, right?
Thanks for checking the issue.

[Bug modula2/108121] Failing tests on x86_64-linux-gnu

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #8 from CVS Commits  ---
The master branch has been updated by Gaius Mulley :

https://gcc.gnu.org/g:68201409bc2867da45791331e385198826fa4576

commit r14-232-g68201409bc2867da45791331e385198826fa4576
Author: Gaius Mulley 
Date:   Wed Apr 26 02:55:59 2023 +0100

PR modula2/108121 Re-implement overflow detection for constant literals

This patch fixes the overflow detection for constant literals.
The ZTYPE is changed to int128 (or int64) if int128 is unavailable and
constant literals are built from widest_int.  The widest_int is converted
into the tree type and checked for overflow.
m2expr_interpret_integer and append_m2_digit are removed.

gcc/m2/ChangeLog:

PR modula2/108121
* gm2-compiler/M2ALU.mod (Less): Reformatted.
* gm2-compiler/SymbolTable.mod (DetermineSizeOfConstant): Remove
from import.
(ConstantStringExceedsZType): Import.
(GetConstLitType): Re-implement using ConstantStringExceedsZType.
* gm2-gcc/m2decl.cc (m2decl_DetermineSizeOfConstant): Remove.
(m2decl_ConstantStringExceedsZType): New function.
(m2decl_BuildConstLiteralNumber): Re-implement.
* gm2-gcc/m2decl.def (DetermineSizeOfConstant): Remove.
(ConstantStringExceedsZType): New function.
* gm2-gcc/m2decl.h (m2decl_DetermineSizeOfConstant): Remove.
(m2decl_ConstantStringExceedsZType): New function.
* gm2-gcc/m2expr.cc (append_digit): Remove.
(m2expr_interpret_integer): Remove.
(append_m2_digit): Remove.
(m2expr_StrToWideInt): New function.
(m2expr_interpret_m2_integer): Remove.
* gm2-gcc/m2expr.def (CheckConstStrZtypeRange): New function.
* gm2-gcc/m2expr.h (m2expr_StrToWideInt): New function.
* gm2-gcc/m2type.cc (build_m2_word64_type_node): New function.
(build_m2_ztype_node): New function.
(m2type_InitBaseTypes): Call build_m2_ztype_node.
* gm2-lang.cc (gm2_type_for_size): Re-write using early returns.

gcc/testsuite/ChangeLog:

PR modula2/108121
* gm2/pim/fail/largeconst.mod: Increased constant value test
to fail now that cc1gm2 uses widest_int to represent a ZTYPE.
* gm2/pim/fail/largeconst2.mod: New test.

Signed-off-by: Gaius Mulley 

[Bug target/109629] internal compiler error: in final_scan_insn_1, at final.c:3078 6480 | }

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #9 from Andrew Pinski  ---
(In reply to Linus from comment #8)
> hi Andrew, thanks. And before raising another ticket for attaching the
> second half of ccdNSTWA.out, I did try to add one more attachment to this
> bug, but it hinted that previous one will be obsolete.

No it will not. It says:
"(optional) Check each existing attachment made obsolete by your new
attachment."
See the optional part. It will only make it is obsolete if you chose to do
that.

[Bug target/109629] internal compiler error: in final_scan_insn_1, at final.c:3078 6480 | }

[linus.zhu at mavenir dot com via Gcc-bugs]

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

--- Comment #8 from Linus  ---
hi Andrew, thanks. And before raising another ticket for attaching the second
half of ccdNSTWA.out, I did try to add one more attachment to this bug, but it
hinted that previous one will be obsolete.

Anyway it's not important, another part of ccdNSTWA.out was uploaded to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109630.

[Bug target/109629] internal compiler error: in final_scan_insn_1, at final.c:3078 6480 | }

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #7 from Andrew Pinski  ---
(In reply to Linus from comment #4)
> due to 1M-attachment limit, I'll raise another bug and attach ccdNSTWA.out.2

The limit is just per-attachment, not per bug.

[Bug target/109629] internal compiler error: in final_scan_insn_1, at final.c:3078 6480 | }

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

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

[Bug c++/109630] internal compiler error: in final_scan_insn_1, at final.c:3078 6480 | }, to attach another half /tmp/ccdNSTWA.out

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Dup of bug 109629. You can attach the part after the fact.

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

[Bug target/109629] internal compiler error: in final_scan_insn_1, at final.c:3078 6480 | }

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #5 from Andrew Pinski  ---
/* If we have a length attribute, this instruction should have
   been split in shorten_branches, to ensure that we would have
   valid length info for the splitees.  */
gcc_assert (!HAVE_ATTR_length);

[Bug c++/109630] New: internal compiler error: in final_scan_insn_1, at final.c:3078 6480 | }, to attach another half /tmp/ccdNSTWA.out

[linus.zhu at mavenir dot com via Gcc-bugs]

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

Bug ID: 109630
   Summary: internal compiler error: in final_scan_insn_1, at
final.c:3078 6480 | }, to attach another half
/tmp/ccdNSTWA.out
   Product: gcc
   Version: 10.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: linus.zhu at mavenir dot com
  Target Milestone: ---

Created attachment 54922
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54922=edit
ccdNSTWA.out.2

UeDtCmi.cpp: In member function ‘virtual cm_ims_rmt_server_t*
UeDtCmi::_ZThn21812712_N7UeDtCmi12GetImsRmtSrvEv()’:
UeDtCmi.cpp:6480:1: internal compiler error: in final_scan_insn_1, at
final.c:3078
 6480 | }
  | ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
{standard input}: Assembler messages:
{standard input}: Error: open CFI at the end of file; missing .cfi_endproc
directive
Preprocessed source stored into /tmp/ccdNSTWA.out file, please attach this to
your bugreport.
make[1]: *** [Makefile:619: libUeDtMgr_a-UeDtCmi.o] Error 1



similar issue was reported by aarch64 gcc 8.3.1/9.3.1/10.2.1,
and the code survived aarch64 gcc 4.8.5


attaching another half /tmp/ccdNSTWA.out

[Bug target/109629] internal compiler error: in final_scan_insn_1, at final.c:3078 6480 | }

[linus.zhu at mavenir dot com via Gcc-bugs]

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

--- Comment #4 from Linus  ---
due to 1M-attachment limit, I'll raise another bug and attach ccdNSTWA.out.2

[Bug target/109629] internal compiler error: in final_scan_insn_1, at final.c:3078 6480 | }

[linus.zhu at mavenir dot com via Gcc-bugs]

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

--- Comment #3 from Linus  ---
Created attachment 54921
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54921=edit
ccdNSTWA.out.1

ccdNSTWA.out.1

[Bug modula2/108121] Failing tests on x86_64-linux-gnu

[gaius at gcc dot gnu.org via Gcc-bugs]

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

Gaius Mulley  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #7 from Gaius Mulley  ---
I've bootstrapped the previous patch on the master branch (gcc-14) on x86_64
and aarch64.  Bootstrapping is continuing on armv7l and ppc64le.  All tests now
pass on x86_64 and aarch64 (gcc-14).

[Bug target/109629] internal compiler error: in final_scan_insn_1, at final.c:3078 6480 | }

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2023-04-26

--- Comment #2 from Andrew Pinski  ---
Also note:
Preprocessed source stored into /tmp/ccdNSTWA.out file, please attach this to
your bugreport.


You might need to compress it.

[Bug target/109629] internal compiler error: in final_scan_insn_1, at final.c:3078 6480 | }

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
  Component|c++ |target

--- Comment #1 from Andrew Pinski  ---
Note this:
See  for instructions.

[Bug c++/109629] New: internal compiler error: in final_scan_insn_1, at final.c:3078 6480 | }

[linus.zhu at mavenir dot com via Gcc-bugs]

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

Bug ID: 109629
   Summary: internal compiler error: in final_scan_insn_1, at
final.c:3078  6480 | }
   Product: gcc
   Version: 10.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: linus.zhu at mavenir dot com
  Target Milestone: ---

UeDtCmi.cpp: In member function ‘virtual cm_ims_rmt_server_t*
UeDtCmi::_ZThn21812712_N7UeDtCmi12GetImsRmtSrvEv()’:
UeDtCmi.cpp:6480:1: internal compiler error: in final_scan_insn_1, at
final.c:3078
 6480 | }
  | ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
{standard input}: Assembler messages:
{standard input}: Error: open CFI at the end of file; missing .cfi_endproc
directive
Preprocessed source stored into /tmp/ccdNSTWA.out file, please attach this to
your bugreport.
make[1]: *** [Makefile:619: libUeDtMgr_a-UeDtCmi.o] Error 1



similar issue was reported by aarch64 gcc 8.3.1/9.3.1/10.2.1,
and the code survived aarch64 gcc 4.8.5

[Bug modula2/108121] Failing tests on x86_64-linux-gnu

[gaius at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #6 from Gaius Mulley  ---
Created attachment 54920
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54920=edit
Proposed fix for TestLong4.mod (ZTYPE fix)

Here is a proposed patch to allow testLong4.mod to compile without warning.
The ZTYPE is changed to int128 (or int64) if int128 is unavailable and
constant literals are built from widest_int.  The widest_int is converted into
the tree type and checked for overflow.

m2expr_interpret_integer and append_m2_digit are removed.

[Bug analyzer/109628] New: -Wanalyzer-use-of-uninitialized-value false positive on static storage

[eggert at cs dot ucla.edu via Gcc-bugs]

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

Bug ID: 109628
   Summary: -Wanalyzer-use-of-uninitialized-value false positive
on static storage
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: eggert at cs dot ucla.edu
  Target Milestone: ---

Created attachment 54919
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54919=edit
compile with "gcc -fanalyzer -S" to reproduce the bug

I ran into this problem when compiling GNU coreutils fmt.c. This is with gcc
(GCC) 13.0.1 20230401 (Red Hat 13.0.1-0) on x86-64. Compile the attached
program with:

gzip -d u.i.gz
gcc -fanalyzer -S u.i

GCC outputs the following diagnostic which is a false positive because 'this'
points to the static array unused_word_type, and static storage by definition
is initialized.

u.i: In function ‘base_cost’:
u.i:5950:7: warning: use of uninitialized value ‘((unsigned
char*)&*this)[16]’ [CWE-457] [-Wanalyzer-use-of-uninitialized-value]
 5950 |   if (this->paren)
  |   ^~~~
  ‘fmt_paragraph’: events 1-4
|
| 5894 | fmt_paragraph (void)
|  | ^
|  | |
|  | (1) entry to ‘fmt_paragraph’
|..
| 5903 |   for (start = word_limit - 1; start >= unused_word_type;
start--)
|  |~
|  |  |
|  |  (2) following ‘true’
branch...
| 5904 | {
| 5905 |   best = ((COST) (! (! ((COST) 0 < (COST) -1)) ?
(COST) -1 : COST) 1 << ((sizeof (COST) * 8
|  |  
~
|  ||
|  |(3) ...to here
| 5906 | ) - 2)) - 1) * 2 + 1)));
|  | ~~~
|..
| 5913 |   wcost = line_cost (w, len) + w->best_cost;
|  |   ~~
|  |   |
|  |   (4) calling ‘line_cost’ from
‘fmt_paragraph’
|
+--> ‘line_cost’: events 5-7
   |
   | 5957 | line_cost (WORD *next, int len)
   |  | ^
   |  | |
   |  | (5) entry to ‘line_cost’
   |..
   | 5961 |   if (next == word_limit)
   |  |  ~
   |  |  |
   |  |  (6) following ‘true’ branch...
   | 5962 | return 0;
   |  |~
   |  ||
   |  |(7) ...to here
   |
<--+
|
  ‘fmt_paragraph’: events 8-9
|
| 5913 |   wcost = line_cost (w, len) + w->best_cost;
|  |   ^~
|  |   |
|  |   (8) returning to ‘fmt_paragraph’ from
‘line_cost’
|..
| 5922 |   if (w == word_limit)
|  |  ~ 
|  |  |
|  |  (9) following ‘true’ branch...
|
  ‘fmt_paragraph’: event 10
|
|cc1:
| (10): ...to here
|
  ‘fmt_paragraph’: event 11
|
| 5927 |   start->best_cost = best + base_cost (start);
|  | ^
|  | |
|  | (11) calling ‘base_cost’
from ‘fmt_paragraph’
|
+--> ‘base_cost’: events 12-13
   |
   | 5932 | base_cost (WORD *this)
   |  | ^
   |  | |
   |  | (12) entry to ‘base_cost’
   |..
   | 5950 |   if (this->paren)
   |  |   
   |  |   |
   |  |   (13) use of uninitialized value ‘((unsigned
char*)&*this)[16]’ here
   |

[Bug driver/109627] [PATCH] driver: Extend 'getenv' function to allow default value

[keithp at keithp dot com via Gcc-bugs]

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

--- Comment #1 from keithp at keithp dot com  ---
This patch was submitted to the mailing list here:

https://gcc.gnu.org/pipermail/gcc-patches/2022-August/600452.html

[Bug driver/109627] New: [PATCH] driver: Extend 'getenv' function to allow default value

[keithp at keithp dot com via Gcc-bugs]

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

Bug ID: 109627
   Summary: [PATCH] driver: Extend 'getenv' function to allow
default value
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: driver
  Assignee: unassigned at gcc dot gnu.org
  Reporter: keithp at keithp dot com
  Target Milestone: ---

Created attachment 54918
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54918=edit
Patch implementing proposed change

Right now, a missing environment variable provided to the 'getenv'
function in a .specs file causes a fatal error. That makes writing a
spec file that uses the GCC_EXEC_PREFIX value difficult as that
variable is only set when the driver has been relocated, but not when
run from the defined location. This makes building a relocatable
toolchain difficult to extend to other ancilary pieces which use specs
files to locate header and library files adjacent to the toolchain.

This patch adds an optional third argument to the getenv function that
can be used to fall back to the standard installation path when the
driver hasn't set GCC_EXEC_PREFIX in the environment.

For example, if an alternate C library is installed in
${prefix}/extra, then this change allows the specs file to locate that
relative to the gcc directory, if gcc is located in the original
installation directory (which would leave GCC_EXEC_PREFIX unset), or
if the gcc tree has been moved to a different location (where gcc
would set GCC_EXEC_PREFIX itself):

*cpp:
-isystem %:getenv(GCC_EXEC_PREFIX ../../extra/include ${prefix}/extra/include)

I considered changing the behavior of either the %R sequence so that
it had a defined behavior when there was no sysroot defined, or making
the driver always set the GCC_EXEC_PREFIX environment variable and
decided that the approach of adding functionality to getenv where it
was previously invalid would cause the least potential for affecting
existing usage.

[Bug c++/109625] [14 regression] 'error: use of built-in trait ‘__type_pack_element’ in function signature; use library traits instead' when building folly

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #3 from Andrew Pinski  ---
Folly should not use internal functions which is not designed for other than
libstdc++.

[Bug c++/109625] [14 regression] 'error: use of built-in trait ‘__type_pack_element’ in function signature; use library traits instead' when building folly

[arsen at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #2 from Arsen Arsenović  ---
almost certainly started with r14-92-g58b7dbf865b146, of course

[Bug c++/109625] [14 regression] 'error: use of built-in trait ‘__type_pack_element’ in function signature; use library traits instead' when building folly

[arsen at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #1 from Arsen Arsenović  ---
related code (folly/Traits.h)


  #if FOLLY_HAS_BUILTIN(__type_pack_element)

  template 
  using type_pack_element_t = __type_pack_element;

  #else

  template 
  using type_pack_element_t = traits_detail::type_pack_element_fallback;

  #endif

it is what it says on the tin :)

do we want to match what clang does here?  that being:

~ 1 $ clang++ -x c++ - -S -o - <<<$'template void
FOOBAR(__type_pack_element<4, T...>&&) {} void g() { FOOBAR(3.0); }' | grep FOOBAR
callq   _Z6FOOBARIJdEEvO19__type_pack_elementILm4EJDpT_EE

... not the prettiest

[Bug tree-optimization/109626] New: forwprop introduces new signed multiplication UB

[kristerw at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 109626
   Summary: forwprop introduces new signed multiplication UB
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kristerw at gcc dot gnu.org
  Target Milestone: ---

Consider the function

int foo(_Bool v0, unsigned v1, unsigned v2)
{
  signed int v5 = v1 >> v2;
  unsigned v6 = -v1;
  unsigned int v7 = v2 - v0;
  return (int)v7 * (int)v6;
}

This does not invoke undefined behavior when called as foo(0, 0x8000, 1),
but forwprop1 optimizes this to the equivalent of

int foo(_Bool v0, unsigned v1, unsigned v2)
{
  signed int v5 = v1 >> v2;
  unsigned int v7 = v0 - v2;
  return (int)v7 * (int)v1;
}

where the signed multiplication now is calculating -1 * INT_MIN.

[Bug c++/109625] New: [14 regression] 'error: use of built-in trait ‘__type_pack_element’ in function signature; use library traits instead' when building folly

[sjames at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 109625
   Summary: [14 regression] 'error: use of built-in trait
‘__type_pack_element’
in function signature; use library traits instead'
when building folly
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sjames at gcc dot gnu.org
CC: arsen at gcc dot gnu.org, ppalka at gcc dot gnu.org
  Target Milestone: ---

Created attachment 54917
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54917=edit
Unicode.cpp.ii.xz

Not sure if this is a GCC issue or not, but it's a new compile failure of
folly-2023.04.10.00 with GCC 14.0.0 20230423:
```
FAILED: CMakeFiles/folly_base.dir/folly/Unicode.cpp.o 
/usr/bin/aarch64-unknown-linux-gnu-g++ -DBOOST_ATOMIC_DYN_LINK
-DBOOST_ATOMIC_NO_LIB -DBOOST_CONTEXT_DYN_LINK -DBOOST_CONTEXT_NO_LIB
-DBOOST_FILESYSTEM_DYN_LINK -DBOOST_FILESYSTEM_NO_LIB
-DBOOST_PROGRAM_OPTIONS_DYN_LINK -DBOOST_PROGRAM_OPTIONS_NO_LIB
-DBOOST_REGEX_DYN_LINK -DBOOST_REGEX_NO_LIB -DBOOST_SYSTEM_DYN_LINK
-DBOOST_SYSTEM_NO_LIB -DBOOST_THREAD_DYN_LINK -DBOOST_THREAD_NO_LIB
-DFMT_SHARED
-DFOLLY_XLOG_STRIP_PREFIXES=\"/var/tmp/portage/dev-cpp/folly-2023.04.10.00/work/folly-2023.04.10.00:/var/tmp/portage/dev-cpp/folly-2023.04.10.00/work/folly-2023.04.10.00_build\"
-DGFLAGS_IS_A_DLL=0 -D_GNU_SOURCE -D_REENTRANT
-I/var/tmp/portage/dev-cpp/folly-2023.04.10.00/work/folly-2023.04.10.00
-I/var/tmp/portage/dev-cpp/folly-2023.04.10.00/work/folly-2023.04.10.00_build
-I/usr/include/libiberty  -O2 -pipe -mcpu=native -fPIC -fcoroutines -g
-std=gnu++1z -finput-charset=UTF-8 -fsigned-char -Wall -Wno-deprecated
-Wno-deprecated-declarations -Wno-sign-compare -Wno-unused -Wuninitialized
-Wunused-label -Wunused-result -Wshadow-compatible-local -Wno-noexcept-type
-faligned-new -fopenmp -std=gnu++17 -MD -MT
CMakeFiles/folly_base.dir/folly/Unicode.cpp.o -MF
CMakeFiles/folly_base.dir/folly/Unicode.cpp.o.d -o
CMakeFiles/folly_base.dir/folly/Unicode.cpp.o -c
/var/tmp/portage/dev-cpp/folly-2023.04.10.00/work/folly-2023.04.10.00/folly/Unicode.cpp
In file included from
/var/tmp/portage/dev-cpp/folly-2023.04.10.00/work/folly-2023.04.10.00/folly/Unicode.cpp:21:
/var/tmp/portage/dev-cpp/folly-2023.04.10.00/work/folly-2023.04.10.00/folly/Conv.h:
In instantiation of ‘folly::detail::LastElement&
folly::detail::getLastElement(const Ts& ...) [with Ts = {char [26], unsigned
int, char [4], unsigned int, std::__cxx11::basic_string, std::allocator >*}]’:
/var/tmp/portage/dev-cpp/folly-2023.04.10.00/work/folly-2023.04.10.00/folly/Conv.h:312:27:
error: use of built-in trait ‘__type_pack_element’ in function signature; use library traits instead
  312 | const LastElement& getLastElement(const Ts&... ts) {
  |   ^~
/var/tmp/portage/dev-cpp/folly-2023.04.10.00/work/folly-2023.04.10.00/folly/Conv.h:
In instantiation of ‘folly::detail::LastElement&
folly::detail::getLastElement(const Ts& ...) [with Ts = {char [26], unsigned
int, char [6], unsigned int, std::__cxx11::basic_string, std::allocator >*}]’:
/var/tmp/portage/dev-cpp/folly-2023.04.10.00/work/folly-2023.04.10.00/folly/Conv.h:312:27:
error: use of built-in trait ‘__type_pack_element’ in function signature; use library traits instead
[...]
```

---

```
$ /usr/bin/aarch64-unknown-linux-gnu-g++ -O2 -fcoroutines -std=gnu++1z
-finput-charset=UTF-8 -fsigned-char -faligned-new -fopenmp -std=gnu++17 -c
Unicode.cpp.ii
In file included from
/var/tmp/portage/dev-cpp/folly-2023.04.10.00/work/folly-2023.04.10.00/folly/Unicode.cpp:21:
/var/tmp/portage/dev-cpp/folly-2023.04.10.00/work/folly-2023.04.10.00/folly/Conv.h:
In instantiation of ‘folly::detail::LastElement&
folly::detail::getLastElement(const Ts& ...) [with Ts = {char [26], unsigned
int, char [4], unsigned int, std::__cxx11::basic_string, std::allocator >*}]’:
/var/tmp/portage/dev-cpp/folly-2023.04.10.00/work/folly-2023.04.10.00/folly/Conv.h:312:27:
error: use of built-in trait ‘__type_pack_element’ in function signature; use library traits instead
  312 | const LastElement& getLastElement(const Ts&... ts) {
  |   ^~
[...]
```

[Bug target/108851] gcc -pie generates unwanted PE export table

[pali at kernel dot org via Gcc-bugs]

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

--- Comment #3 from Pali Rohár  ---
Or do you have any other suggestions?

[Bug c++/108975] [10/11 Regression] ICE on constexpr variable used as nontype template since r9-5473-ge32fc4499f863f

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #17 from CVS Commits  ---
The master branch has been updated by Patrick Palka :

https://gcc.gnu.org/g:3d674e29d7f89bf93fcfcc963ff0248c6347586d

commit r14-228-g3d674e29d7f89bf93fcfcc963ff0248c6347586d
Author: Patrick Palka 
Date:   Tue Apr 25 15:59:22 2023 -0400

c++: value dependence of by-ref lambda capture [PR108975]

We are still ICEing on the generic lambda version of the testcase from
this PR, even after r13-6743-g6f90de97634d6f, due to the by-ref capture
of the constant local variable 'dim' being considered value-dependent
when regenerating the lambda (at which point processing_template_decl is
set since the lambda is generic), which prevents us from constant folding
its uses.  Later during prune_lambda_captures we end up not thoroughly
walking the body of the lambda and overlook the (non-folded) uses of
'dim' within the array bound and using-decls.

We could fix this by making prune_lambda_captures walk the body of the
lambda more thoroughly so that it finds these uses of 'dim', but ideally
we should be able to constant fold all uses of 'dim' ahead of time and
prune the implicit capture after all.

To that end this patch makes value_dependent_expression_p return false
for such by-ref captures of constant local variables, allowing their
uses to get constant folded ahead of time.  It seems we just need to
disable the predicate's conservative early exit for reference variables
(added by r5-5022-g51d72abe5ea04e) when DECL_HAS_VALUE_EXPR_P.  This
effectively makes us treat by-value and by-ref captures more consistently
when it comes to value dependence.

PR c++/108975

gcc/cp/ChangeLog:

* pt.cc (value_dependent_expression_p) :
Suppress conservative early exit for reference variables
when DECL_HAS_VALUE_EXPR_P.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/lambda/lambda-const11a.C: New test.

[Bug target/105523] Wrong warning array subscript [0] is outside array bounds

[konrad at silmor dot de via Gcc-bugs]

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

--- Comment #30 from Konrad Rosenbaum  ---
(In reply to Andrew Pinski from comment #28)
> (In reply to Wilhelm M from comment #26)
> > As you can see in my opening bug report, there is no nullptr reference nor
> > dereferencing a pointer with value 0.
> 
> Yes but as I mentioned by the time the warning happens, the IR has lost
> information if the constant came from a null pointer or from some other
> constant that the user used. So a heuristic needs to be used and the idea
> was it would be the lower bytes by default and that the lower bytes would be
> defined by a "page size" and that is how the naming of the option happened.

To be honest, this sounds like a missing feature or even a design bug:
shouldn't the IR be aware of what original address (type) a pointer/array
originated from?

If it makes a difference whether I access a[70] or a[7] then the
heuristic is not very helpful. If a useful option has a completely unintuitive
name that is also a problem.

Null pointers usually derive from nullptr, NULL or the integer constant 0. I
think it would be worth a flag or two to mark code pathes that transmit real
null pointers or offsets to real null pointers. Anything derived from a
non-zero integer is something that the programmer bears full responsibility for
- if he wants to aim at his foot, let him!

Even if something derives from integer 0 (as opposed to nullptr or NULL), there
is a chance that it was something that is intended (on the MCU I'm currently
using this is the register that sets the first 8 GPIO pins) - usually
"volatile" will be a good indicator of that, because memory mapped registers
are always volatile.

A few examples I can think of:


struct MyStruct { int a,b,c; };

auto *nps = (MyStruct*)nullptr; // -> originates from a nullptr, definitely a
problem!
auto *npi = >c; // -> still derived from nullptr, still a problem!

MyStruct myvar;
auto *vps =  ; // -> dereferences a real variable, definitely not a
problem
auto *vpi = >c; // -> still not a problem

auto *sps = (MyStruct*)0x101; // -> static address, very likely not a problem
or at least the programmer's problem, not the compiler's
auto *spi = >c; // same here

auto *xps = (MyStruct*)0x00; // -> static address, but 0x00 -> probably nullptr
auto *xpi = >c; // -> derived from probably nullptr -> probably a problem

struct VMyStruct { volatile int a,b,c; };
auto *yps = (VMyStruct*)0x00; // -> static null address, but has volatile
members, may or may not be problematic
auto *ypi = >c; // -> derived from static null address, but access is
volatile, it's the programmer's problem, no warning

auto *zps = (VMyStruct*)NULL; // NULL=((void*)0) -> derived from non-volatile
pointer to 0, count it like nullptr!

No heuristic at the point of use will be able to properly catch and categorize
those. There will have to be some flags that get passed along with the
(changing) pointer value.

Even then there should be a way to tell the compiler whether (SomeType*)0 is a
null pointer or a pointer to a legitimate memory location. Can pointer values
have attributes?

The question that remains is: is this change worth it and might it help to
catch other problems?

[Bug fortran/103931] Type name "c_ptr" is ambiguous when iso_c_binding is imported both directly and indirectly

[anlauf at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #22 from anlauf at gcc dot gnu.org ---
Here another invalid example which ICEs because the clash is not detected:

module AModule
  implicit none
  type, bind(C) :: c_ptr
 private
 integer(8) :: c_address
  end type c_ptr
end module

module GModule
  use AModule, only: C_PTR
  use, intrinsic :: ISO_C_BINDING, only: C_PTR
  implicit none
  type(c_ptr) :: ptr
end module

This hits an assert a few lines above the place you looked at...
(Interchanging the use statements helps here.)

[Bug target/105523] Wrong warning array subscript [0] is outside array bounds

[gjl at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #29 from Georg-Johann Lay  ---
(In reply to David Brown from comment #20)
> This is not an AVR backend issue - it is much wider than that.  It is
> perhaps reasonable to test a patch just on the AVR, but this needs to be
> fixed in the core of gcc.

Ok, just the fact that the issue is sitting there for > 1 year now lead me to
the conclusion it's an AVR issue...

On older AVR devices, SFR area starts at 0x20, but on newer devices it starts
at 0x0.  There are devices where 0x0 is actually some SFR address like PINB for
ATtiny10 just to mention one.

At least for AVR, the warning does not make sense for dereferencing volatile
pointers to addresses known at compile time.

But there are also cases for addresses known only at link time, like with AVR
attribute __address__ or __io__.

Hence, for any addresses known at link time or earlier (aka. immediates), the
warning makes no sense to me, because you cannot allocate them, anyways. (And
when you can allocate by means of, say, a memory protection unit, GCC is out of
the game.)

[Bug fortran/103931] Type name "c_ptr" is ambiguous when iso_c_binding is imported both directly and indirectly

[aldot at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #21 from Bernhard Reutner-Fischer  ---
(In reply to anlauf from comment #19)

> C_PTR is an intrinsic DT and not a procedure;
> so we should not mark it as "generic".

Ok, that makes sense indeed.

> 
> As long as a symbol from an *intrinsic module* is use-associated - either
> directly or indirectly - the conflict check could trace it down to its
> origin (in case it is renamed), and we would resolve this explicitly.

I think renaming works. Let's concentrate on a case without renaming first.
I'll have another look now.

Btw, there is also module == "(intrinsic)" which we might want to reconsider
nowadays, but that is for another day.

[Bug tree-optimization/109154] [13/14 regression] jump threading de-optimizes nested floating point comparisons

[jakub at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #55 from Jakub Jelinek  ---
If you could do it, that would be great.  I'm now working on frange libm
functions and will need to switch to OpenMP work soon.

[Bug tree-optimization/109154] [13/14 regression] jump threading de-optimizes nested floating point comparisons

[tnfchris at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #54 from Tamar Christina  ---
@Jakub, just to check to avoid doing duplicate work, did you intend to do the
remaining ifcvt changes or should we?

[Bug fortran/103931] Type name "c_ptr" is ambiguous when iso_c_binding is imported both directly and indirectly

[anlauf at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #20 from anlauf at gcc dot gnu.org ---
(In reply to Bernhard Reutner-Fischer from comment #18)
> diff --git a/gcc/fortran/symbol.cc b/gcc/fortran/symbol.cc
> index 221165d6dac..28ed1a32b9e 100644
> --- a/gcc/fortran/symbol.cc
> +++ b/gcc/fortran/symbol.cc
> @@ -4977,6 +4986,10 @@ generate_isocbinding_symbol (const char *mod_name,
> iso_c_binding_symbol s,
> if (!tmp_sym->attr.function
> && !gfc_add_function (_sym->attr, tmp_sym->name, NULL))
>   return NULL;
> +
> +   /* Mark the derived-type symbol in the generic interface
> +  as generic.  */
> +   dt_sym->attr.generic = 1;
>   }
>  
> /* Say what module this symbol belongs to.  */
> 
> 

This change would lead to an accepts-invalid, such as for:

module AModule
  use, intrinsic :: ISO_C_BINDING, only: C_PTR
  use, intrinsic :: ISO_C_BINDING, only: X_PTR => C_FUNPTR
  implicit none
end module

module GModule
  use AModule, only: X_PTR => C_PTR ! C_PTR
  implicit none
end module

module HModule
  use AModule, only: C_PTR => X_PTR ! C_FUNPTR
  use GModule, only: C_PTR => X_PTR ! C_PTR
  implicit none
  type(c_ptr) :: ptr
end module

Without the patch I'd get (as expected):

pr103931-v3.f90:16:14:

   16 |   type(c_ptr) :: ptr
  |  1
Error: Type name 'c_ptr' at (1) is ambiguous

With the patch the actual type of ptr depends on the order of the use
statements in HModule - at least this is what the fortran-dump says...

[Bug fortran/109624] New: dump-parse-tree prints attributes with unbalanced braces

[aldot at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 109624
   Summary: dump-parse-tree prints attributes with unbalanced
braces
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: internal-improvement
  Severity: trivial
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: aldot at gcc dot gnu.org
  Target Milestone: ---

(gdb) call debug(gfc_current_ns)

Namespace: A-H: (REAL 4) I-N: (INTEGER 4) O-Z: (REAL 4)
procedure name = fmodule
  symtree: 'C_ptr'   || symbol: 'c_ptr'
type spec : (UNKNOWN 0)
attributes: )
  symtree: '__def_init___iso_c_binding_C_ptr'|| symbol:
'__def_init___iso_c_binding_C_ptr' 
type spec : (UNKNOWN 0)
attributes: )
...

There is an open brace missing after "attributes: "

diff --git a/gcc/fortran/dump-parse-tree.cc b/gcc/fortran/dump-parse-tree.cc
index 1fc1f311e84..2380fa04796 100644
--- a/gcc/fortran/dump-parse-tree.cc
+++ b/gcc/fortran/dump-parse-tree.cc
@@ -125,6 +125,16 @@ void debug (gfc_ref *p)
   dumpfile = tmp;
 }

+void
+debug (gfc_namespace *ns)
+{
+  FILE *tmp = dumpfile;
+  dumpfile = stderr;
+  show_namespace (ns);
+  fputc ('\n', dumpfile);
+  dumpfile = tmp;
+}
+
 void
 gfc_debug_expr (gfc_expr *e)
 {
@@ -136,7 +146,6 @@ gfc_debug_expr (gfc_expr *e)
 }

 /* Allow for dumping of a piece of code in the debugger.  */
-void gfc_debug_code (gfc_code *c);

 void
 gfc_debug_code (gfc_code *c)
@@ -758,12 +767,13 @@ show_expr (gfc_expr *p)
 static void
 show_attr (symbol_attribute *attr, const char * module)
 {
+  fputc ('(', dumpfile);
   if (attr->flavor != FL_UNKNOWN)
 {
   if (attr->flavor == FL_DERIVED && attr->pdt_template)
-   fputs (" (PDT-TEMPLATE", dumpfile);
+   fputs ("PDT-TEMPLATE ", dumpfile);
   else
-fprintf (dumpfile, "(%s ", gfc_code2string (flavors, attr->flavor));
+   fprintf (dumpfile, "%s ", gfc_code2string (flavors, attr->flavor));
 }
   if (attr->access != ACCESS_UNKNOWN)
 fprintf (dumpfile, "%s ", gfc_code2string (access_types, attr->access));

[Bug c++/109621] [10/11/12/13/14 Regression] GCC accepts invalid program with multiple using declarations

[redi at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #3 from Jonathan Wakely  ---
Which makes it a regression in 4.3.0 and later.

[Bug c++/109621] [10/11/12/13/14 Regression] GCC accepts invalid program with multiple using declarations

[redi at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #2 from Jonathan Wakely  ---
Possibly started with 

re PR c++/31749 (ICE with invalid redeclaration of builtin)

PR c++/31749

gcc/cp/
* name-lookup.c (do_nonmember_using_decl): Shift implicit type
declarations into appropriate slots for comparison.  Fix type
comparison.

gcc/testsuite/
* g++.dg/lookup/builtin3.C: New test.
* g++.dg/lookup/builtin4.C: New test.
* g++.dg/lookup/using19.C: New test.

From-SVN: r127600

Or something before that and after r127526.

[Bug c++/109623] constexpr restrictions are not relaxed enough

[redi at gcc dot gnu.org via Gcc-bugs]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=106649

--- Comment #1 from Jonathan Wakely  ---
I think this shoulda been done for Bug 106649, IIUC

[Bug debug/109616] internal compiler error: in dwarf2out_var_location, at dwarf2out.c:26371 （GreenLiant）

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|FIXED   |INVALID

--- Comment #8 from Andrew Pinski  ---
.

[Bug target/105523] Wrong warning array subscript [0] is outside array bounds

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #28 from Andrew Pinski  ---
(In reply to Wilhelm M from comment #26)
> As you can see in my opening bug report, there is no nullptr reference nor
> dereferencing a pointer with value 0.

Yes but as I mentioned by the time the warning happens, the IR has lost
information if the constant came from a null pointer or from some other
constant that the user used. So a heuristic needs to be used and the idea was
it would be the lower bytes by default and that the lower bytes would be
defined by a "page size" and that is how the naming of the option happened.

[Bug target/105523] Wrong warning array subscript [0] is outside array bounds

[klaus.doldinger64 at googlemail dot com via Gcc-bugs]

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

--- Comment #27 from Wilhelm M  ---

> I don't know if every embedded developer feels the same way.  (Georg-Johann
> could chime in with his opinion.)

Indeed, limiting the warning on volatile-qualified ptr would help.

[Bug target/105523] Wrong warning array subscript [0] is outside array bounds

[klaus.doldinger64 at googlemail dot com via Gcc-bugs]

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

--- Comment #26 from Wilhelm M  ---
As you can see in my opening bug report, there is no nullptr reference nor
dereferencing a pointer with value 0.

[Bug target/105523] Wrong warning array subscript [0] is outside array bounds

[david at westcontrol dot com via Gcc-bugs]

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

--- Comment #25 from David Brown  ---
(In reply to Andrew Pinski from comment #24)
> (In reply to LIU Hao from comment #22)
> > Yes, GCC should be told to shut up about dereferencing artificial address
> > values.
> 
> NO.
> Take:
> ```
> static inline int f(int *a)
> {
>   return a[10];
> }
> 
> int g()
> {
>   return f(0);
> }
> ```
> The warning is there for the above case really (and similar ones with struct
> offsets). Where you originally have a null pointer and have an offset from
> there; by the time the warning happens, the IR does not know if it was
> originally from an offset of a null pointer or if the value was written in.
> The paramater is there to "tune" the heurstic to figure out if it is null
> pointer deference or if it is some real (HW) address. Maybe
> -fno-delete-null-pointer-checks should imply --param=min-pagesize=0, though
> some folks want the warning indepdent of trying to delete null pointer
> checks.

It is worth noting, I think, that although on a target like the AVR (and most
embedded systems without an MMU) the address 0 is a real part of memory, and
can really be read and/or written, any code that tries to dereference a 0
pointer is almost always wrong.  I don't want gcc to consider 0 as an
acceptable address on these targets - I want it to warn me if it sees a null
pointer dereference.  If I really want to target address 0, as I might
occasionally do, I'll use a pointer to volatile - /then/ I'd like gcc to
believe me without question.

I don't know if every embedded developer feels the same way.  (Georg-Johann
could chime in with his opinion.)

[Bug fortran/109622] [13/14 regression][OpenACC] internal compiler error: in omp_group_base, at gimplify.cc:9412 if -fopenacc is set.

[patrick.begou--- via Gcc-bugs]

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

--- Comment #7 from Patrick Bégou  ---
Le 25/04/2023 à 14:49, pault at gcc dot gnu.org a écrit :
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109622
>
> --- Comment #4 from Paul Thomas  ---
> Hi Patrick,
>
> Confirmed on pre-release GNU Fortran (GCC) 13.0.1 20230414.
>
> .
>
> Thanks for the report.

No, Paul. Thanks for providing such a powerful development environment!

Users should thanks, not developers. ;-)


Patrick

[Bug c++/109623] New: constexpr restrictions are not relaxed enough

[oleksandr.koval.dev at gmail dot com via Gcc-bugs]

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

Bug ID: 109623
   Summary: constexpr restrictions are not relaxed enough
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: oleksandr.koval.dev at gmail dot com
  Target Milestone: ---

https://godbolt.org/z/eo8K3Ehqq

```cpp
#include 

struct S{
constexpr S() = default;   // error, not implicitly constexpr
constexpr S(){}// this works
std::unordered_map m;
};

```

My understanding is that in C++23 this should be allowed because the only
restriction for constexpr constructors and destructors is the absence of
virtual base classes.

[Bug target/105523] Wrong warning array subscript [0] is outside array bounds

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #24 from Andrew Pinski  ---
(In reply to LIU Hao from comment #22)
> Yes, GCC should be told to shut up about dereferencing artificial address
> values.

NO.
Take:
```
static inline int f(int *a)
{
  return a[10];
}

int g()
{
  return f(0);
}
```
The warning is there for the above case really (and similar ones with struct
offsets). Where you originally have a null pointer and have an offset from
there; by the time the warning happens, the IR does not know if it was
originally from an offset of a null pointer or if the value was written in. The
paramater is there to "tune" the heurstic to figure out if it is null pointer
deference or if it is some real (HW) address. Maybe
-fno-delete-null-pointer-checks should imply --param=min-pagesize=0, though
some folks want the warning indepdent of trying to delete null pointer checks.

[Bug middle-end/109609] [12/13 Regression] tail call for function even when passing a ptr which references a local array still

[gburca-gnu at ebixio dot com via Gcc-bugs]

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

--- Comment #17 from Gabriel Burca  ---
Speaking of the size parameter, my workaround for the original issue was to
pre-compute the size argument a different way. This however resulted in a
warning that's both right and wrong. Here's the sample code that must be
compiled with -O3 and -Wall:

https://godbolt.org/z/jbf74994z


```
static constexpr unsigned N = 20;
char dst[N + 1];

int main() {
  char buf[10];
  char *src = buf + sizeof(buf);
  *(--src) = 0;
  *(--src) = 'a';
  strncpy(dst, src, std::min(N, strlen(src) + 1));

//   constexpr volatile size_t n = std::min(N, strlen(src) + 1);
//   strncpy(dst, src, n);
}
```

: In function 'int main()':
:13:10: warning: 'char* strncpy(char*, const char*, size_t)' specified
bound depends on the length of the source argument [-Wstringop-truncation]
   13 |   strncpy(dst, src, std::min(N, strlen(src) + 1));
  |   ~~~^~~~
:13:47: note: length computed here
   13 |   strncpy(dst, src, std::min(N, strlen(src) + 1));
  | ~~^

Sure, it depends on the src, but in a "good" way.

The commented out code doesn't produce the warning. An alternative way to make
the warning go away is to change to:

char *src = buf + sizeof(buf) - 1;

[Bug testsuite/109608] [10 regression] net test case g++.dg/cpp0x/constexpr-pmf3.C in r10-11306-gda17a9049ee0a8 has excess errors

[jason at gcc dot gnu.org via Gcc-bugs]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #4 from Jason Merrill  ---
Fixed

[Bug testsuite/109608] [10 regression] net test case g++.dg/cpp0x/constexpr-pmf3.C in r10-11306-gda17a9049ee0a8 has excess errors

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

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

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

commit r10-11312-g52c451e6ef67d428304be3299bb67195177f6759
Author: Jason Merrill 
Date:   Tue Apr 25 11:12:33 2023 -0400

testsuite: remove stray ';' [PR109608]

GCC 10 is still pedantic about empty declarations.

PR testsuite/109608

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/constexpr-pmf3.C: Remove stray ';'.

[Bug testsuite/109608] [10 regression] net test case g++.dg/cpp0x/constexpr-pmf3.C in r10-11306-gda17a9049ee0a8 has excess errors

[jason at gcc dot gnu.org via Gcc-bugs]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug c++/109621] [10/11/12/13/14 Regression] GCC accepts invalid program with multiple using declarations

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|GCC accepts invalid program |[10/11/12/13/14 Regression]
   |with multiple using |GCC accepts invalid program
   |declarations|with multiple using
   ||declarations
  Known to fail||4.4.7
   Target Milestone|--- |10.5
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
  Known to work||4.1.2
   Last reconfirmed||2023-04-25

--- Comment #1 from Andrew Pinski  ---
C++98 version which shows it is a regression and it started to fail between GCC
4.1.2 and 4.4.7:
```
namespace X 
{ 
struct type {}; 
}
namespace Y 
{ 
typedef int type;
}
using Y::type;
using X::type;
int i = sizeof(type); //gcc and msvc accepts this but clang rejects this

```

[Bug target/94324] [10/11/12/13/14 regression] gfortran.dg/default_format_1.f90 etc. FAIL on 32-bit Solaris/x86

[ro at gcc dot gnu.org via Gcc-bugs]

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

Rainer Orth  changed:

   What|Removed |Added

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

--- Comment #10 from Rainer Orth  ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #4)
> > --- Comment #3 from Dominique d'Humieres  ---
> > Is it a fortran bug or a bug in a Solaris lib?
> 
> The latter, I suspect (or rather: the Studio compiler used to build
> them).  However, I'd like to keep the PR open until that's confirmed.
> Didn't have time to investigate yet.

I just noticed that the bug hasn't occurred after 20221014.  Thus closing
as fixed (as I said, most likely upstream in Studio cc, thus fixing the libc
build).

[Bug d/103528] [12/13/14 regression] d21 doesn't build on Solaris

[ro at gcc dot gnu.org via Gcc-bugs]

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

Rainer Orth  changed:

   What|Removed |Added

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

--- Comment #19 from Rainer Orth  ---
(In reply to Richard Biener from comment #18)
> What's the status of this bug now?

AFAICS everything is in place now, both code and documentation changes.

[Bug middle-end/109609] [12/13 Regression] tail call for function even when passing a ptr which references a local array still

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

Summary|[12/13/14 Regression] tail  |[12/13 Regression] tail
   |call for function even when |call for function even when
   |passing a ptr which |passing a ptr which
   |references a local array|references a local array
   |still   |still
  Known to work||14.0

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

[Bug middle-end/109609] [12/13/14 Regression] tail call for function even when passing a ptr which references a local array still

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #15 from CVS Commits  ---
The master branch has been updated by Richard Biener :

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

commit r14-225-ge8d00353017f895d03a9eabae3506fd126ce1a2d
Author: Richard Biener 
Date:   Tue Apr 25 14:56:44 2023 +0200

tree-optimization/109609 - correctly interpret arg size in fnspec

By majority vote and a hint from the API name which is
arg_max_access_size_given_by_arg_p this interprets a memory access
size specified as given as other argument such as for strncpy
in the testcase which has "1cO313" as specifying the _maximum_
size read/written rather than the exact size.  There are two
uses interpreting it that way already and one differing.  The
following adjusts the differing and clarifies the documentation.

PR tree-optimization/109609
* attr-fnspec.h (arg_max_access_size_given_by_arg_p):
Clarify semantics.
* tree-ssa-alias.cc (check_fnspec): Correctly interpret
the size given by arg_max_access_size_given_by_arg_p as
maximum, not exact, size.

* gcc.dg/torture/pr109609.c: New testcase.

[Bug target/109566] [12 Regression] powerpc: unrecognizable insn for -mcpu=e6500, -mcpu=power3, ..., -mcpu=power10

[jakub at gcc dot gnu.org via Gcc-bugs]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|13.0|12.3

[Bug target/109566] [12 Regression] powerpc: unrecognizable insn for -mcpu=e6500, -mcpu=power3, ..., -mcpu=power10

[jakub at gcc dot gnu.org via Gcc-bugs]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[12/13/14 Regression]   |[12 Regression] powerpc:
   |powerpc: unrecognizable |unrecognizable insn for
   |insn for -mcpu=e6500,   |-mcpu=e6500, -mcpu=power3,
   |-mcpu=power3, ...,  |..., -mcpu=power10
   |-mcpu=power10   |

--- Comment #19 from Jakub Jelinek  ---
Fixed on the trunk and for 13.1 so far.

[Bug fortran/109622] [13/14 regression][OpenACC] internal compiler error: in omp_group_base, at gimplify.cc:9412 if -fopenacc is set.

[burnus at gcc dot gnu.org via Gcc-bugs]

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

Tobias Burnus  changed:

   What|Removed |Added

 CC||jules at gcc dot gnu.org
Summary|[13/14 regression] internal |[13/14 regression][OpenACC]
   |compiler error: in  |internal compiler error: in
   |omp_group_base, at  |omp_group_base, at
   |gimplify.cc:9412 if |gimplify.cc:9412 if
   |-fopenacc is set.   |-fopenacc is set.

--- Comment #6 from Tobias Burnus  ---
The ICE is in omp_group_base, which was added by Julian
in r13-2661-gb57abd072dd319a72839a49e769bffc244a52bc0 and updated in later
commits.


The debugger shows:

Breakpoint 1, omp_index_mapping_groups_1 (grpmap=0x2d2f960, groups=0x2cc4700,
reindex_sentinel=0x0) at ../../repos/gcc/gcc/gimplify.cc:9426
9426{
(gdb) n
9431  FOR_EACH_VEC_ELT (*groups, i, grp)
...
9441  tree node = omp_group_base (grp, , );

for the last grp (i = 1, there are only 2).

9292omp_group_base (omp_mapping_group *grp, unsigned int *chained,
9293tree *firstprivate)
9294{
9295  tree node = *grp->grp_start;

(gdb) p debug(*grp->grp_start)
map(attach_detach:atransform2->next [bias: 0])

Which fails at 'gcc_unreachable' for 'switch (OMP_CLAUSE_MAP_KIND (node))'.

* * *

I note that
case GOMP_MAP_ATTACH:
case GOMP_MAP_DETACH:
are handled but GOMP_MAP_ATTACH_DETACH isn't.


Actually, it is handled but not as separate input but as:

case :
  ...
  node = OMP_CLAUSE_CHAIN (node);
switch (OMP_CLAUSE_MAP_KIND (node))
...
  case GOMP_MAP_ATTACH_DETACH:

 * * *

The original input is ("debug(...)" for i = 0, which shows i=0 and i=1):

map(attach:*atransform2->next [bias: 184]) map(attach_detach:atransform2->next
[bias: 0])

which is fine, but as   FOR_EACH_VEC_ELT (*groups, i, grp) then also processes
i=1 separately, it fails.

[Bug target/99195] Optimise away vec_concat of 64-bit AdvancedSIMD operations with zeroes in aarch64

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #5 from CVS Commits  ---
The master branch has been updated by Kyrylo Tkachov :

https://gcc.gnu.org/g:9e9503e7b2c1517e8c46ea4d2e8805cc20301f34

commit r14-222-g9e9503e7b2c1517e8c46ea4d2e8805cc20301f34
Author: Kyrylo Tkachov 
Date:   Tue Apr 25 14:52:37 2023 +0100

aarch64: PR target/PR99195 Annotate more simple integer binary patterns
with vcz subst rules

This patch adds more straightforward annotations to some more integer
binary ops to
eliminate redundant fmovs around 64-bit SIMD results.

Bootstrapped and tested on aarch64-none-linux.

gcc/ChangeLog:

PR target/99195
* config/aarch64/aarch64-simd.md (orn3): Rename to...
(orn3): ... This.
(bic3): Rename to...
(bic3): ... This.
(3): Rename to...
(3): ... This.

gcc/testsuite/ChangeLog:

PR target/99195
* gcc.target/aarch64/simd/pr99195_1.c: Add tests for orn, bic, max
and min.

[Bug testsuite/109608] [10 regression] net test case g++.dg/cpp0x/constexpr-pmf3.C in r10-11306-gda17a9049ee0a8 has excess errors

[seurer at gcc dot gnu.org via Gcc-bugs]

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

seurer at gcc dot gnu.org changed:

   What|Removed |Added

Summary|[14 regression] net test|[10 regression] net test
   |case|case
   |g++.dg/cpp0x/constexpr-pmf3 |g++.dg/cpp0x/constexpr-pmf3
   |.C in   |.C in
   |r10-11306-gda17a9049ee0a8   |r10-11306-gda17a9049ee0a8
   |has excess errors   |has excess errors

--- Comment #2 from seurer at gcc dot gnu.org ---
Sorry, I saw it in 10 only.

[Bug fortran/109622] [13/14 regression] internal compiler error: in omp_group_base, at gimplify.cc:9412 if -fopenacc is set.

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |13.0
   Keywords||openacc

[Bug middle-end/109609] [12/13/14 Regression] tail call for function even when passing a ptr which references a local array still

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #14 from Richard Biener  ---
Btw, looking at the user modref_access_analysis::get_access_for_fnspec it
interprets the size as upper bound (also for 't').  Likewise for
get_access_for_fnspec.  Just the check_fnspec use in tree-ssa-alias.cc
interprets both as exact sizes.

So a "conservative" fix that's backportable would simply adjust the
tree-ssa-alias.cc use to behave similarly.

[Bug fortran/109622] [13/14 regression] internal compiler error: in omp_group_base, at gimplify.cc:9412 if -fopenacc is set.

[pault at gcc dot gnu.org via Gcc-bugs]

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

Paul Thomas  changed:

   What|Removed |Added

 Ever confirmed|0   |1
Summary|internal compiler error: in |[13/14 regression] internal
   |omp_group_base, at  |compiler error: in
   |gimplify.cc:9412 if |omp_group_base, at
   |-fopenacc is set.   |gimplify.cc:9412 if
   ||-fopenacc is set.
 CC||burnus at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2023-04-25

--- Comment #5 from Paul Thomas  ---
Hi Patrick,

We had a mid-air collision :-)

Paul

[Bug fortran/109622] internal compiler error: in omp_group_base, at gimplify.cc:9412 if -fopenacc is set.

[pault at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #4 from Paul Thomas  ---
Hi Patrick,

Confirmed on pre-release GNU Fortran (GCC) 13.0.1 20230414.

The compiler is objecting to the dereferencing in the pragma call:
  while (1)
{
  if (done) goto L.4;
  copy_transform (, );
  #pragma acc enter data map(attach:*atransform2->next [bias: 184])
map(attach_detach:atransform2->next [bias: 0]);
  if (atransform1->next != 0B && atransform2->next != 0B)
{
  atransform1 = atransform1->next;
  atransform2 = atransform2->next;
}
  else
{
  done = 1;
}
  L.5:;
  L.3:;
}

Compiles OK with GNU Fortran (GCC) 12.2.1 20230321 so I am marking as a
regression. ifort compiles it OK with -qopenmp.

It compiles fine is a non-pointer transform_t is passed.

I am cc'ing Tobias, who at least knows a lot about the workings of OpenMP in
gcc.

Thanks for the report.

Paul

[Bug c++/109278] a note without a warning

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

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

https://gcc.gnu.org/g:784e03f378bb2c330b96459928d0472d38748970

commit r14-220-g784e03f378bb2c330b96459928d0472d38748970
Author: Jakub Jelinek 
Date:   Tue Apr 25 14:38:01 2023 +0200

testsuite: Fix up ext-floating15.C tests on powerpc64-linux [PR109278]

I've noticed this test FAILs on powerpc64-linux, with
FAIL: g++.dg/cpp23/ext-floating15.C  -std=gnu++98 (test for excess errors)
Excess errors:
/home/jakub/gcc/gcc/testsuite/g++.dg/cpp23/ext-floating15.C:8:5: error:
'_Float128' is not supported on this target
/home/jakub/gcc/gcc/testsuite/g++.dg/cpp23/ext-floating15.C:8:5: error:
'_Float128' is not supported on this target
/home/jakub/gcc/gcc/testsuite/g++.dg/cpp23/ext-floating15.C:8:1: error:
variable or field 'bar' declared void
/home/jakub/gcc/gcc/testsuite/g++.dg/cpp23/ext-floating15.C:8:5: error:
'_Float128' is not supported on this target
/home/jakub/gcc/gcc/testsuite/g++.dg/cpp23/ext-floating15.C:8:6: error:
expected primary-expression before '_Float128'
and similarly other std versions.
powerpc64-linux is float128 target, but needs to add some options for it.

Fixed by adding them.

2023-04-25  Jakub Jelinek  

PR c++/109278
* g++.dg/cpp23/ext-floating15.C: Add dg-add-options float128.

[Bug target/109566] [12/13/14 Regression] powerpc: unrecognizable insn for -mcpu=e6500, -mcpu=power3, ..., -mcpu=power10

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #18 from CVS Commits  ---
The releases/gcc-13 branch has been updated by Jakub Jelinek
:

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

commit r13-7240-gfb4e50a7c1cdd14e8f06421c642837292c9d8dee
Author: Jakub Jelinek 
Date:   Tue Apr 25 14:20:51 2023 +0200

powerpc: Fix up *branch_anddi3_dot for -m32 -mpowerpc64 [PR109566]

The following testcase reduced from newlib ICEs on powerpc-linux,
with -O2 -m32 -mpowerpc64 since r12-6433 PR102239 optimization was
added and on the original testcase since some ranger improvements in
GCC 13 made it no longer latent on newlib.
The problem is that the *branch_anddi3_dot define_insn_and_split
relies on the *rotldi3_mask_dot define_insn_and_split being recognized
during splitting.  The rs6000_is_valid_rotate_dot_mask function checks
whether
the mask is a CONST_INT which is a valid mask, but *rotl3_mask_dot in
addition to checking that it is a valid mask also has
  (mode == Pmode || UINTVAL (operands[3]) <= 0x7fff)
test in the condition.  For TARGET_64BIT that doesn't add any further
requirements, but for !TARGET_64BIT && TARGET_POWERPC64 if the AND
second operand is larger than INT_MAX it will not be recognized.

The rs6000_is_valid_rotate_dot_mask function is used solely in one spot,
condition of *branch_anddi3_dot, so the following patch adjusts it
to check for that as well.

2023-04-25  Jakub Jelinek  

PR target/109566
* config/rs6000/rs6000.cc (rs6000_is_valid_rotate_dot_mask): For
!TARGET_64BIT, don't return true if UINTVAL (mask) << (63 - nb)
is larger than signed int maximum.

* gcc.target/powerpc/pr109566.c: New test.

(cherry picked from commit 97f8f2d0a0384d377ca46da88495f9a3d18d4415)

[Bug rtl-optimization/109585] [10/11/12/13 regression] Carla/sord miscompiled with -O2 on ARM64 with flexible array member

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

Summary|[10/11/12/13/14 regression] |[10/11/12/13 regression]
   |Carla/sord miscompiled with |Carla/sord miscompiled with
   |-O2 on ARM64 with flexible  |-O2 on ARM64 with flexible
   |array member|array member
  Known to work||14.0

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

[Bug fortran/109622] internal compiler error: in omp_group_base, at gimplify.cc:9412 if -fopenacc is set.

[patrick.begou--- via Gcc-bugs]

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

--- Comment #3 from Patrick Bégou  ---
Following Harald Anlauf idea, I have built the compilers from the
devel/omp/gcc-12 branch for testing:
GNU Fortran (GCC) 12.2.1 20230302 [OG12]

The "internal error" shown with this small test case (begou.f90) do not occur
with this branch. I have to test with the full application but I need first to
rebuild all the prerequisites (Gcc13 modules files are not backward compatibles
with Gcc12).

[Bug target/109566] [12/13/14 Regression] powerpc: unrecognizable insn for -mcpu=e6500, -mcpu=power3, ..., -mcpu=power10

[segher at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #17 from Segher Boessenkool  ---
So, apparently powerpc-rtems uses -mpowerpc64 by default?!  That is
problematic,
it changes the ABI, might not actually work at all (it requires your
setjmp/longjmp
and getcontext/setcontext to restore the full 64-bit registers), and is often
bigger and slower code (but not always).

I suppose powerpc-rtems gets this from a default CPU choice?

[Bug rtl-optimization/109585] [10/11/12/13/14 regression] Carla/sord miscompiled with -O2 on ARM64 with flexible array member

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #23 from CVS Commits  ---
The master branch has been updated by Richard Biener :

https://gcc.gnu.org/g:6d4bd27a60447c7505cb4783e675e98a191a8904

commit r14-219-g6d4bd27a60447c7505cb4783e675e98a191a8904
Author: Richard Biener 
Date:   Mon Apr 24 13:31:07 2023 +0200

rtl-optimization/109585 - alias analysis typo

When r10-514-gc6b84edb6110dd2b4fb improved access path analysis
it introduced a typo that triggers when there's an access to a
trailing array in the first access path leading to false
disambiguation.

PR rtl-optimization/109585
* tree-ssa-alias.cc (aliasing_component_refs_p): Fix typo.

* gcc.dg/torture/pr109585.c: New testcase.

[Bug target/109566] [12/13/14 Regression] powerpc: unrecognizable insn for -mcpu=e6500, -mcpu=power3, ..., -mcpu=power10

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

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

https://gcc.gnu.org/g:97f8f2d0a0384d377ca46da88495f9a3d18d4415

commit r14-218-g97f8f2d0a0384d377ca46da88495f9a3d18d4415
Author: Jakub Jelinek 
Date:   Tue Apr 25 14:20:51 2023 +0200

powerpc: Fix up *branch_anddi3_dot for -m32 -mpowerpc64 [PR109566]

The following testcase reduced from newlib ICEs on powerpc-linux,
with -O2 -m32 -mpowerpc64 since r12-6433 PR102239 optimization was
added and on the original testcase since some ranger improvements in
GCC 13 made it no longer latent on newlib.
The problem is that the *branch_anddi3_dot define_insn_and_split
relies on the *rotldi3_mask_dot define_insn_and_split being recognized
during splitting.  The rs6000_is_valid_rotate_dot_mask function checks
whether
the mask is a CONST_INT which is a valid mask, but *rotl3_mask_dot in
addition to checking that it is a valid mask also has
  (mode == Pmode || UINTVAL (operands[3]) <= 0x7fff)
test in the condition.  For TARGET_64BIT that doesn't add any further
requirements, but for !TARGET_64BIT && TARGET_POWERPC64 if the AND
second operand is larger than INT_MAX it will not be recognized.

The rs6000_is_valid_rotate_dot_mask function is used solely in one spot,
condition of *branch_anddi3_dot, so the following patch adjusts it
to check for that as well.

2023-04-25  Jakub Jelinek  

PR target/109566
* config/rs6000/rs6000.cc (rs6000_is_valid_rotate_dot_mask): For
!TARGET_64BIT, don't return true if UINTVAL (mask) << (63 - nb)
is larger than signed int maximum.

* gcc.target/powerpc/pr109566.c: New test.

[Bug fortran/109622] internal compiler error: in omp_group_base, at gimplify.cc:9412 if -fopenacc is set.

[patrick.begou--- via Gcc-bugs]

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

--- Comment #2 from Patrick Bégou  ---
Sorry, exact branch is: releases/gcc-13

[Bug fortran/109622] internal compiler error: in omp_group_base, at gimplify.cc:9412 if -fopenacc is set.

[patrick.begou--- via Gcc-bugs]

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

--- Comment #1 from Patrick Bégou  ---
OS: CentOS8
Compiler 13 built with native CentOS8 compiler: GNU Fortran (GCC) 8.3.1
20191121 (Red Hat 8.3.1-5)

[Bug fortran/109622] New: internal compiler error: in omp_group_base, at gimplify.cc:9412 if -fopenacc is set.

[patrick.begou--- via Gcc-bugs]

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

Bug ID: 109622
   Summary: internal compiler error: in omp_group_base, at
gimplify.cc:9412 if -fopenacc is set.
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: patrick.be...@univ-grenoble-alpes.fr
  Target Milestone: ---

Created attachment 54916
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54916=edit
Simple file to reproduce the bug

Gfortran is git master branch, commit n°
f743863e09ad788b044dd01696b073581116843b from Apr 24 00:22:57

How to reproduce:
Small fortran file is attached (begou.f90).

gfortran -c -fopenacc begou.f90 

0xa830c6 omp_group_base
../../gcc/gcc/gimplify.cc:9412
0xa830c6 omp_index_mapping_groups_1
../../gcc/gcc/gimplify.cc:9441
0xa833c7 omp_index_mapping_groups
../../gcc/gcc/gimplify.cc:9502
0xa96a9a gimplify_scan_omp_clauses
../../gcc/gcc/gimplify.cc:10802
0xa8660d gimplify_omp_target_update
../../gcc/gcc/gimplify.cc:15563
0xa8660d gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gcc/gimplify.cc:16928
0xa89826 gimplify_stmt(tree_node**, gimple**)
../../gcc/gcc/gimplify.cc:7219
0xa875a3 gimplify_statement_list
../../gcc/gcc/gimplify.cc:2019
0xa875a3 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gcc/gimplify.cc:16821
0xa89826 gimplify_stmt(tree_node**, gimple**)
../../gcc/gcc/gimplify.cc:7219
0xa86e8a gimplify_and_add(tree_node*, gimple**)
../../gcc/gcc/gimplify.cc:492
0xa86e8a gimplify_loop_expr
../../gcc/gcc/gimplify.cc:1993
0xa86e8a gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gcc/gimplify.cc:16581
0xa89826 gimplify_stmt(tree_node**, gimple**)
../../gcc/gcc/gimplify.cc:7219
0xa875a3 gimplify_statement_list
../../gcc/gcc/gimplify.cc:2019
0xa875a3 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gcc/gimplify.cc:16821
0xa89826 gimplify_stmt(tree_node**, gimple**)
../../gcc/gcc/gimplify.cc:7219
0xa89d2b gimplify_bind_expr
../../gcc/gcc/gimplify.cc:1430
0xa86d8e gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gcc/gimplify.cc:16577
0xa89826 gimplify_stmt(tree_node**, gimple**)
../../gcc/gcc/gimplify.cc:7219


Script used for building the compiler:

#!/bin/sh

#
# Build GCC with support for offloading to NVIDIA GPUs.
#

work_dir=/robin/data/begou/GCC_GIT_BUILD
install_dir=/robin/data/begou/GCC_GIT_binaries
rm -rf $install_dir $work_dir/build-host-gcc $work_dir/build-nvptx-gcc
$work_dir/gcc $work_dir/nvptx-*
CC=$(which gcc)
CXX=$(which g++)
FC=$(which gfortran)
F90=$(which gfortran)

# Location of the installed CUDA toolkit
cuda=/opt/nvidia/hpc_sdk/Linux_x86_64/22.5/cuda/

# Build assembler and linking tools
mkdir -p $work_dir
cd $work_dir
git clone https://github.com/MentorEmbedded/nvptx-tools
cd nvptx-tools
./configure \
--with-cuda-driver-include=$cuda/include \
--with-cuda-driver-lib=$cuda/lib64 \
--prefix=$install_dir
make || exit 1
make install || exit 1
cd ..

# Set up the GCC source tree
git clone git://sourceware.org/git/newlib-cygwin.git nvptx-newlib
git clone git://gcc.gnu.org/git/gcc.git gcc
#git clone --branch releases/gcc-11 git://gcc.gnu.org/git/gcc.git gcc
cd gcc
contrib/download_prerequisites
ln -s ../nvptx-newlib/newlib newlib
cd ..
target=$(gcc/config.guess)

# Build nvptx GCC
mkdir build-nvptx-gcc
cd build-nvptx-gcc
../gcc/configure \
--disable-gcov \
--target=nvptx-none --with-build-time-tools=$install_dir/nvptx-none/bin \
--enable-as-accelerator-for=$target \
--disable-sjlj-exceptions \
--enable-newlib-io-long-long \
--enable-languages="c,c++,fortran,lto" \
--prefix=$install_dir
make -j`nproc` || exit 1
make install || exit 1
cd ..

# Build host GCC
mkdir build-host-gcc
cd  build-host-gcc
../gcc/configure \
--enable-offload-targets=nvptx-none \
--with-cuda-driver-include=$cuda/include \
--with-cuda-driver-lib=$cuda/lib64 \
--disable-bootstrap \
--disable-multilib \
--enable-languages="c,c++,fortran,lto" \
--prefix=$install_dir
make -j`nproc` || exit 1
make install || exit 1
cd ..

[Bug c++/109621] New: GCC accepts invalid program with multiple using declarations

[jlame646 at gmail dot com via Gcc-bugs]

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

Bug ID: 109621
   Summary: GCC accepts invalid program with multiple using
declarations
   Product: gcc
   Version: 13.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jlame646 at gmail dot com
  Target Milestone: ---

The following invalid program(afaik) is accepted by gcc and msvc.
https://godbolt.org/z/1Tsx54ro5

```
namespace X 
{ 
struct type {}; 
}
namespace Y 
{ 
using type = int; 
}
using X::type;
using Y::type;
int main()
{
auto i = sizeof(type); //gcc and msvc accepts this but clang rejects this
}
```

[Bug target/109610] [14 regression] gcc.target/powerpc/dform-3.c fails after r14-172-g0368d169492017

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Hongtao.liu  ---

> 
> And after my commit, RA take best scenario when preferred reg_class is
> unkown, which make cost of MEM:0,0 of r117 same as VSX_REGS:0,0, and
> allocate r117 as VSX_REGS, which create an extra move and failed the
> testcase.

The extra move normally can be eliminated by reload if both src and dest have
same reg_class, but here src is VSX_REGS and dest is GENERAL_REGS.

Maybe we should add a little bit extra cost to best scenario to make RA handle
such redundancy but not relies on pass_reload for that.

@@ -1580,7 +1580,7 @@ scan_one_insn (rtx_insn *insn)
   int num = COST_INDEX (REGNO (reg));

   COSTS (costs, num)->mem_cost
-   -= ira_memory_move_cost[GET_MODE (reg)][cl][1] * frequency;
+   -= (ira_memory_move_cost[GET_MODE (reg)][cl][1] + 1) * frequency;

1 unit cost is aligned with what's did in recog_reg_class

  /* If the alternative actually allows memory, make
 things a bit cheaper since we won't need an extra
 insn to load it.  */
  pp->mem_cost
= ((out_p ? ira_memory_move_cost[mode][op_class][0] : 0)
   + (in_p ? ira_memory_move_cost[mode][op_class][1] : 0)
   - allows_mem[i]) * frequency;

[Bug target/109610] [14 regression] gcc.target/powerpc/dform-3.c fails after r14-172-g0368d169492017

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Hongtao.liu  ---
testcase:

#ifndef TYPE
#define TYPE vector double
#endif

struct foo {
  TYPE a, b, c, d;
};

/* Make sure we don't use direct moves to get stuff into GPR registers.  */
void
gpr (struct foo *p)
{
  TYPE x = p->c;

  __asm__ (" # reg = %0" : "+r" (x));

  p->b = x;
}


Here's dump in ira.

-
a2(r117,l0) costs: BASE_REGS:12000,12000 GENERAL_REGS:12000,12000
FLOAT_REGS:0,0 ALTIVEC_REGS:0,0 VSX_REGS:0,0 GEN_OR_FLOAT_REGS:12000,12000
GEN_OR_VSX_REGS:12000,12000 MEM:0,0

(insn 6 3 13 2 (set (reg/v:V2DF 117 [ x ])
(mem:V2DF (plus:DI (reg/v/f:DI 118 [ p ])
(const_int 32 [0x20])) [1 p_2(D)->c+0 S16 A128]))
"testsuite/gcc.target/powerpc/dform-3.c":23:8 1148 {vsx_movv2df_64bit}
 (nil))
(insn 13 6 8 2 (set (reg:V2DF 119 [ x ])
(reg/v:V2DF 117 [ x ])) "testsuite/gcc.target/powerpc/dform-3.c":25:3
-1
 (nil))
(insn 8 13 9 2 (parallel [
(set (reg:V2DF 119 [ x ])
(asm_operands:V2DF (" # reg = %0") ("=r") 0 [
(reg:V2DF 119 [ x ])
]
 [
(asm_input:V2DF ("0")
testsuite/gcc.target/powerpc/dform-3.c:25)
]
 [] testsuite/gcc.target/powerpc/dform-3.c:25))
(clobber (reg:SI 98 ca))
]) "testsuite/gcc.target/powerpc/dform-3.c":25:3 -1
---


And after my commit, RA take best scenario when preferred reg_class is unkown,
which make cost of MEM:0,0 of r117 same as VSX_REGS:0,0, and allocate r117 as
VSX_REGS, which create an extra move and failed the testcase.

[Bug libgomp/109620] New: [OpenMP][Offloading] OMP_CANCELLATION ICV not mapped to device

[frederik at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 109620
   Summary: [OpenMP][Offloading] OMP_CANCELLATION ICV not mapped
to device
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgomp
  Assignee: unassigned at gcc dot gnu.org
  Reporter: frederik at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
  Target Milestone: ---

The value of the OMP_CANCELLATION ICV does not get copied to offloading
devices.
I have tested it by running the following test code both with nvptx and amgdcn
offloading as a part of the libgomp testsuite:   

/* { dg-set-target-env-var OMP_CANCELLATION "true" } */

#include 

int
main ()
{

  __builtin_printf("OMP_CANCELLATION on host: %d\n",
 omp_get_cancellation ());
#pragma omp target
{
  __builtin_printf("OMP_CANCELLATION on device: %d\n",
   omp_get_cancellation ());
}

  return 0;
}

In both cases, the output was:

OMP_CANCELLATION on host: 1
OMP_CANCELLATION on device: 0

Does libgomp copy global ICVs to the device environment at all?
I did not find any tests that use cancellation in "target" regions. I think
there is no way for a user to enable it if the ICV is not forwarded.
But would it be supported in principle?

[Bug target/105523] Wrong warning array subscript [0] is outside array bounds

[david at westcontrol dot com via Gcc-bugs]

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

--- Comment #23 from David Brown  ---
(In reply to LIU Hao from comment #22)
> Yes, GCC should be told to shut up about dereferencing artificial address
> values.

One possibility is to have the warnings disabled whenever you are using a
volatile pointer.  After all, "volatile" is an indication that the compiler
doesn't know everything, and it has to trust the programmer.

[Bug middle-end/109609] [12/13/14 Regression] tail call for function even when passing a ptr which references a local array still

[jakub at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #13 from Jakub Jelinek  ---
strncpy second argument is an array rather than necessarily a string and
characters after '\0' are not copied, so if n is non-zero, it reads between 1
and n characters from the source array (not sure if a dumb implementation could
try to read all characters and only copy those until '\0' inclusive though).

[Bug middle-end/109609] [12/13/14 Regression] tail call for function even when passing a ptr which references a local array still

[jakub at gcc dot gnu.org via Gcc-bugs]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jsm28 at gcc dot gnu.org

--- Comment #12 from Jakub Jelinek  ---
I had a look at memcmp recently in the context of PR109306 and my understanding
is that the function may but doesn't have to access all bytes from both arrays
up to the given size.
While for memchr, C17 contains:
"The implementation shall behave as if it reads the characters sequentially and
stops as soon as a matching character is found."
and my reading of that is that it has to stop reading upon reaching the match,
so in that case the read is always just up to the given size, not the whole
size.
While e.g. strchr doesn't say something similar and so it needs to be passed
valid zero terminated string and can but doesn't have to read the whole string.

[Bug target/105523] Wrong warning array subscript [0] is outside array bounds

[lh_mouse at 126 dot com via Gcc-bugs]

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

--- Comment #22 from LIU Hao  ---
Yes, GCC should be told to shut up about dereferencing artificial address
values.

[Bug target/105523] Wrong warning array subscript [0] is outside array bounds

[david at westcontrol dot com via Gcc-bugs]

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

--- Comment #21 from David Brown  ---
(In reply to Andrew Pinski from comment #1)
> --param=min-pagesize= should be set to 0 for avr as zero is a valid address.

Is there any convenient description of "min-pagesize" ?  The user manual is
unhelpful: "Minimum page size for warning purposes."  Your comment here
suggests it is connected to whether zero is a valid address or not, which does
not sound at all related to the issue here.  (But you are correct that for the
AVR, and many embedded systems, accessing memory at address zero is valid.)

Testing (on godbolt) shows that setting "--param=min-pagesize=0" does stop this
warning triggering.  But this is an issue that affects all systems for which
the user might want to convert a fixed value to an address - i.e., all embedded
systems, and perhaps device drivers or other low-level code on bigger systems. 
Is setting "min-pagesize" to 0 actually a fix, or is it a workaround, and will
it have other effects on static warning checks and/or code generation?

A workaround is, of course, helpful - especially since this can be added to
peoples CFLAGS list.

[Bug target/105523] Wrong warning array subscript [0] is outside array bounds

[david at westcontrol dot com via Gcc-bugs]

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

--- Comment #20 from David Brown  ---
(In reply to Georg-Johann Lay from comment #19)
> Created attachment 54912 [details]
> pr105532.diff: Proposed patch for the AVR backend
> 
> Here is a proposed, untested patch.
> 
> gcc/
>   PR target/105532
>   * config/avr/avr.cc (opts.h): Include it.
>   (avr_option_override): Set --param_min_pagesize=0.
> 
> gcc/testsuite/
>   PR target/105532
>   * gcc.target/avr/torture/pr105532.c: New test.

This is not an AVR backend issue - it is much wider than that.  It is perhaps
reasonable to test a patch just on the AVR, but this needs to be fixed in the
core of gcc.