[Bug c/108941] Error: operand type mismatch for `shr' with binutils master

[jbeulich at suse dot com via Gcc-bugs]

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

--- Comment #16 from jbeulich at suse dot com ---
(In reply to Jakub Jelinek from comment #15)
> Above you're mixing a 32-bit argument with 8-bit argument in an instruction
> which
> expects probably 2 32-bit arguments or at least both arguments with the same
> width.
> Just try to pass 2 variables to it and use "ri" and you'll see assembler
> errors,
> add %dl, %eax and the like.

Of course, and I did say the example was over-simplified. If it helps, consider
(as also indicated) invoking a macro instead, which then inspects the operands
and decides what insn to produce. This could be particularly interesting with
the .insn that I'm in the process of preparing to add to x86 gas, where one
would then inspect arguments in order to select a suitable major opcode. Since
x86 has different possible encodings for "add immediate", the wrongly
represented value would then lead to silent bad code generation. And btw - what
"size" to assign to e.g. a sign-extended 8-bit immediate is at least ambiguous.

I can only repeat: Unless the anomaly is properly called out in non-internal
documentation, I continue to think there's a bug here. And the reference to
Clang getting it right, which you simply put off, isn't entirely meaningless
imo (I agree we're talking about a GNU extension here, but that doesn't imply
only GNU tools can get it right).

[Bug c/108941] Error: operand type mismatch for `shr' with binutils master

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

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

--- Comment #15 from Jakub Jelinek  ---
(In reply to jbeulich from comment #14)
> (In reply to Jakub Jelinek from comment #5)
> > GCC doesn't even have that information at all, at the RTL level it doesn't
> > know
> > if it was signed or unsigned.
> > All it has is the constraint and operand for it, like (reg:QI 126) or
> > (const_int -1).
> 
> Lack of information at a certain layer doesn't mean this isn't a bug. It
> merely makes whatever possible bug one that's hard to fix.

Well, we are talking about behavior of an extension that behaved since its
introduction that way and lots of code in the wild can rely on that behavior.
So, why would you all of sudden consider it a bug?

> Furthermore you did refer to gcc internal doc as to justifying the behavior.
> But can you also point me at non-internal doc making explicit that e.g.
> 
> static inline unsigned aux(unsigned i, unsigned char j) {
> #if 1
>   asm("add %1,%0" : "+rm" (i) : "i" (j));

This is just misunderstanding on how inline asm works.  GCC (intentionally)
treats
inline asm as a black box, text in which it does replacements according to the
rules,
it is a very low level interface and needs the author know what they are doing.
Above you're mixing a 32-bit argument with 8-bit argument in an instruction
which
expects probably 2 32-bit arguments or at least both arguments with the same
width.
Just try to pass 2 variables to it and use "ri" and you'll see assembler
errors,
add %dl, %eax and the like.  There are various modifiers (often target
specific) which
allows one to say a particular operand should be printed as if in this mode,
when you don't use them, it means the operand mode is to be used.
So, for add above one should really use "i" ((int) j) if you want it 32-bit.
Similarly how ffmpeg should be using "rI" instead of "ri" that it uses...
 'I'
  Integer constant in the range 0 ... 31, for 32-bit shifts.
even documents it that way.

[Bug ipa/108959] [13 Regression] ice in modify_assignment, at ipa-param-manipulation.cc:1905

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #3 from David Binderman  ---
I will have a go at a git bisection.

[Bug c/108941] Error: operand type mismatch for `shr' with binutils master

[jbeulich at suse dot com via Gcc-bugs]

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

--- Comment #14 from jbeulich at suse dot com ---
(In reply to Jakub Jelinek from comment #5)
> GCC doesn't even have that information at all, at the RTL level it doesn't
> know
> if it was signed or unsigned.
> All it has is the constraint and operand for it, like (reg:QI 126) or
> (const_int -1).

Lack of information at a certain layer doesn't mean this isn't a bug. It merely
makes whatever possible bug one that's hard to fix.

Furthermore you did refer to gcc internal doc as to justifying the behavior.
But can you also point me at non-internal doc making explicit that e.g.

static inline unsigned aux(unsigned i, unsigned char j) {
#if 1
asm("add %1,%0" : "+rm" (i) : "i" (j));
return i;
#else
return i + j;
#endif
}

unsigned test(unsigned i, unsigned j) {
return aux(i, 255) * aux(j, -1);
}

does not do (at -O1 or -O2) what one would expect (again on x86)? The example
is intentionally over-simplified (and hence won't build at -O0); anything more
involved could be taken care of by using assembler macros, where it is not
overly difficult to separately deal with immediates and registers.

In the absence of such documentation I would also view the "has always been
like that" argument as at least questionable.

[Bug c++/108165] -Wdangling-reference false positive

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

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

--- Comment #10 from Martin Liška  ---
@Marek, is there any progress on this?

[Bug target/106770] PPCLE: Unnecessary xxpermdi before mfvsrd

[jens.seifert at de dot ibm.com via Gcc-bugs]

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

--- Comment #6 from Jens Seifert  ---
The left part of VSX registers overlaps with floating point registers, that is
why no register xxpermdi is required and mfvsrd can access all (left) parts of
VSX registers directly.
The xxpermdi x,y,y,3 indicates to me that gcc prefers right part of register
which might also cause the xxpermdi at the beginning. At the end the mystery is
why gcc adds 3 xxpermdi to the code.

[Bug target/108315] -mcpu=power10 changes ABI

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

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

--- Comment #4 from Alexander Monakov  ---
Let me address one point separately:

(In reply to Peter Bergner from comment #1)
> CCing Alan, since he probably knows best how this all works, but yes,
> -mcpu-power10 changes the ABI, namely it adds pcrel support which is an ABI
> extension, where the function compiled with -mcpu=power10 doesn't use r2 to
> access its GOT, but uses pcrel code instead.  I think copying over a p10
> compiled asm or obj file to a p9 system and them linking there with a
> non-p10 aware compiler/binutils seems to be a user error on my part.  Just
> because the -mcpu=power10 compiled file doesn't use any p10 instructions
> doesn't mean it's safe to use on a pre-p10 system.
> 
> I'll let Alan correct me if I'm wrong, but this seems like user error to me.

And the user deserves to get a silently mislinked executable that mysteriously
fails at runtime [*] because it's the users' job to tag static libraries with
minimum required ABI level, not the toolchain's. Yeah.

[*] it does not immediately segfault when returning from a localentry 1
function; it just continues with wrong r2, that may very well point to valid
memory

[Bug target/108315] -mcpu=power10 changes ABI

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

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

--- Comment #3 from Alexander Monakov  ---
Alan implemented the special case of .localentry 1 in this patch for the BFD
linker (that appeared in binutils 2.32 if my calculations are correct):
https://sourceware.org/pipermail/binutils/2018-July/103936.html

and, I think, in this patchset for the Gold linker:
https://sourceware.org/pipermail/binutils/2019-July/107486.html

Corresponding support in the LLVM linker (LLD) also seems to appear around
2018.

It looks like de-facto ABI change even if on paper nothing changed, because all
Linux linkers interpreted .localentry 1 accordingly to the general rule and
would silently produce wrong code. Hence my suggestion to document it.

Plus, someone would have to reach out to the mold maintainer, as mold doesn't
seem to implement this special case.

[Bug d/108962] New: d: Don't generate code that throws exceptions when compiling with `-fno-exceptions'

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

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

Bug ID: 108962
   Summary: d: Don't generate code that throws exceptions when
compiling with `-fno-exceptions'
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: ibuclaw at gcc dot gnu.org
  Target Milestone: ---

There are a few constructs that implicitly raise an Error exception, for
example, `final switch`.

```
void main()
{
final switch (0)
{
case 1:
return;
}
}
```

It might be more desirable to instead abort the runtime, optionally creating a
trace before exiting.

[Bug target/108315] -mcpu=power10 changes ABI

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

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

Kewen Lin  changed:

   What|Removed |Added

 CC||linkw at gcc dot gnu.org

--- Comment #2 from Kewen Lin  ---
(In reply to Alexander Monakov from comment #0)
> Created attachment 54202 [details]
> testcase
> 
> At least the documentation should mention that if intentional.
> 
> In the attached example, the function bar is compiled to
> 
> bar:
> .localentry bar,1
> mtctr 3
> mr 12,3
> bctr
> .long 0
> .byte 0,0,0,0,0,0,0,0
> 
> i.e. it does not preserve r2 (it's compiled with -mcpu=power10). If the
> caller is not compiled with -mcpu=power10, it needs r2 preserved (bar has a
> localentry, so the nop in the caller stays a nop after linking).

My local 64bit-elfv2-abi spec v1.5 has the following description:

3.4.1. Symbol Values

"The values of these three most significant bits of the st_other field have the
following meanings:

...

1 The local and global entry points are the same, and r2 should be treated as
caller-saved for local and global callers. "

...

"The value of st_other is determined from the .localentry directive as follows:
If the .localentry value is 0, the value of st_other is 0. If the .localentry
value is 1, the value of st_other is 1. Otherwise, the value of st_other is the
logarithm (base 2) of the .localentry value."

The function bar is with st_other value 1, r2 should be treated as
caller-saved, so it doesn't take action to preserve r2.

> 
> I verified the testcase misbehaves on Compile Farm's gcc135: as it does not
> use any power10-specific instructions, it's runnable there.

I tried the attachment on one local machine (also ppc64le p9) and noticed the
linker already did some fix-ups with long_branch.bar stub,

Dump of assembler code for function main:
   0x1540 <+0>: lis r2,4098
   0x1544 <+4>: addir2,r2,32512
   0x1548 <+8>: mflrr0
   0x154c <+12>:nop
   0x1550 <+16>:ld  r3,-32728(r2)
   0x1554 <+20>:std r0,16(r1)
   0x1558 <+24>:stdur1,-32(r1)
   0x155c <+28>:bl  0x1510 <0038.long_branch.bar>
=> 0x1560 <+32>:ld  r2,24(r1)
   0x1564 <+36>:addis   r3,r2,-2
   0x1568 <+40>:addir3,r3,-30328

Dump of assembler code for function 0038.long_branch.bar:
=> 0x1510 <+0>: std r2,24(r1)
   0x1514 <+4>: b   0x1710 

which would save r2 onto the corresponding stack slot ahead, it runs well as
expected. Not sure why it doesn't work on your side, maybe this inter-operation
requires some support in newer binutils? My local one is GNU ld 2.34 which is
for final linking (and 2.35 for power10 support, ie. bar.o generation).

[Bug target/108315] -mcpu=power10 changes ABI

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

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

Peter Bergner  changed:

   What|Removed |Added

 CC||amodra at gcc dot gnu.org

--- Comment #1 from Peter Bergner  ---
CCing Alan, since he probably knows best how this all works, but yes,
-mcpu-power10 changes the ABI, namely it adds pcrel support which is an ABI
extension, where the function compiled with -mcpu=power10 doesn't use r2 to
access its GOT, but uses pcrel code instead.  I think copying over a p10
compiled asm or obj file to a p9 system and them linking there with a non-p10
aware compiler/binutils seems to be a user error on my part.  Just because the
-mcpu=power10 compiled file doesn't use any p10 instructions doesn't mean it's
safe to use on a pre-p10 system.

I'll let Alan correct me if I'm wrong, but this seems like user error to me.

[Bug modula2/108956] [13 regression] SEGV in M2RTS_RegisterModule

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

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

--- Comment #2 from Gaius Mulley  ---
The hand built modules were not changed to include the libname.  (UnixArgs,
ldtoa, dtoa for the tool pge).  The patch corrects the hand built modules and
also includes fixes for the attribute noreturn warnings generated when
compiling M2RTS.cc.

[Bug libstdc++/107778] handle_contract_violation should reflect _GLIBCXX_VERBOSE

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|--- |13.0
 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED

--- Comment #11 from Jonathan Wakely  ---
.

[Bug testsuite/91419] [10 Regression]: gcc.dg/tree-ssa/pr91091-2.c, ssa-fre-61.c, ssa-fre-61.c with r273232

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

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

--- Comment #8 from CVS Commits  ---
The master branch has been updated by Hans-Peter Nilsson :

https://gcc.gnu.org/g:5c70121c57c544a9afeb842984c9a0a36816c590

commit r13-6367-g5c70121c57c544a9afeb842984c9a0a36816c590
Author: Hans-Peter Nilsson 
Date:   Mon Feb 27 18:40:02 2023 +0100

testsuite: Remove xfail gcc.dg/tree-ssa/pr91091-2.c RHS !
natural_alignment_32

Reacting to a long-standing XPASS for CRIS.  This one is
slightly brown paper-bag level; it was never the here-removed
xfailed scan that failed and I didn't notice that XPASS when
reporting success on the commit as a whole.  It's not logical to
re-read what was just-written even with overlap issues, and I'm
sure that edit was originally a copy-pasto.  I checked
historical m68k-linux and pru-elf test-results too, to verify
that I got that part right.

PR testsuite/91419
* gcc.dg/tree-ssa/pr91091-2.c:15 Remove xfail for RHS.

[Bug testsuite/91419] [10 Regression]: gcc.dg/tree-ssa/pr91091-2.c, ssa-fre-61.c, ssa-fre-61.c with r273232

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

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

--- Comment #7 from Hans-Peter Nilsson  ---
Oops, the second xfail for gcc.dg/tree-ssa/pr91091-2.c is wrong and I never
noticed the xpass at the time.  Same for pru-elf and m68k-linux.  Will commit
an update; a revert of that line (of the commit from 2019, see log above).

[Bug modula2/108956] [13 regression] SEGV in M2RTS_RegisterModule

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

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

Gaius Mulley  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2023-02-28
 Status|UNCONFIRMED |ASSIGNED

[Bug modula2/108956] [13 regression] SEGV in M2RTS_RegisterModule

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

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

Gaius Mulley  changed:

   What|Removed |Added

 CC||gaius at gcc dot gnu.org

--- Comment #1 from Gaius Mulley  ---
Created attachment 54553
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54553=edit
Proposed fix

Thanks for the bug report - here is a proposed fix.

[Bug testsuite/79356] XPASS in attr-alloc_size-11.c

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

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

--- Comment #16 from CVS Commits  ---
The master branch has been updated by Hans-Peter Nilsson :

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

commit r13-6365-g2f2c0bc57be12ca92d3e2cc74f6cca048da9ed55
Author: Hans-Peter Nilsson 
Date:   Mon Feb 27 17:22:44 2023 +0100

testsuite: Add CRIS to targets not xfailing
gcc.dg/attr-alloc_size-11.c:50,51

Reacting to a long-standing XPASS for CRIS.  Maybe better do
as https://gcc.gnu.org/PR79356#c11 suggests: xfail it for
x86 only ...except I see m68k also does not xpass.

testsuite:
PR testsuite/79356
* gcc.dg/attr-alloc_size-11.c: Add CRIS to the list
of targets excluding xfail on lines 50 and 51.

[Bug tree-optimization/108828] ivopts silencing gcc.dg/Wuse-after-free-2.c:115

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

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

Hans-Peter Nilsson  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2023-02-28
 Status|UNCONFIRMED |SUSPENDED

--- Comment #3 from Hans-Peter Nilsson  ---
Suspending, pending actual fix for tracking through ivopts.

[Bug tree-optimization/108828] ivopts silencing gcc.dg/Wuse-after-free-2.c:115

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

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Hans-Peter Nilsson :

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

commit r13-6364-g8c58f4b798177d419c5af37b7e23c490849f2d45
Author: Hans-Peter Nilsson 
Date:   Fri Feb 24 17:22:02 2023 +0100

testsuite: Add -fno-ivopts to gcc.dg/Wuse-after-free-2.c, PR108828

For cris-elf before this patch, ever since it was added,
this test gets:

Running /x/gcc/testsuite/gcc.dg/dg.exp ...
FAIL: gcc.dg/Wuse-after-free-2.c  (test for warnings, line 115)
FAIL: gcc.dg/Wuse-after-free-2.c  (test for warnings, line 116)

and comparing tree dumps with a native x86_64-pc-linux-gnu
run shows a suspicious difference in the "180t.ivopts" dump.
Indeed -fno-ivopts makes the warning appear for cris-elf
too.  It was suggested to simply add -fno-ivopts to the
test-flags, like before -fno-tree-loop-distribute-patterns
was added; thus.

PR tree-optimization/108828
* gcc.dg/Wuse-after-free-2.c: Add -fno-ivopts.

[Bug fortran/108961] Segfault when associating to pointer from C_F_POINTER

[jeffrey.p.hill at nasa dot gov via Gcc-bugs]

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

--- Comment #1 from Jeffrey Hill  ---
Created attachment 54552
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54552=edit
Minimal Example of failing operation

[Bug fortran/108961] New: Segfault when associating to pointer from C_F_POINTER

[jeffrey.p.hill at nasa dot gov via Gcc-bugs]

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

Bug ID: 108961
   Summary: Segfault when associating to pointer from C_F_POINTER
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jeffrey.p.hill at nasa dot gov
  Target Milestone: ---

Created attachment 54551
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54551=edit
Full example of failing test

In support of exposing a Fortran library via a C API, I am trying to implement
C_F_STRPOINTER from the upcoming F202X standard in F2008:

  https://j3-fortran.org/doc/year/19/19-197r3.txt

A sample implementation was provided in an earlier paper, as well as on the
Intel forums:

  https://j3-fortran.org/doc/year/18/18-258r2.txt 
 
https://community.intel.com/t5/Intel-Fortran-Compiler/New-Interoperability-Fortran-to-C-String-case/m-p/1144681/highlight/true#M138173

Example usage is provided in this paper:

  https://j3-fortran.org/doc/year/21/21-107.txt

Attachment #1 is a full example that implements and exercises c_f_strpointer
per the above references. This works in ifort and nvfortran, but segfaults in
all versions of gfortran I tested (4.8 => 11). Tests were done under Ubuntu and
RH7. The problematic line is Line 37, when trying to associate the
deferred-length output pointer with the defined-length pointer returned by
c_f_pointer:

  call C_F_POINTER(CSTRPTR, p)
  FSTRPTR => p

Attachment #2 in a minimal example that just focuses on the C_F_POINTER/pointer
associate operations. I find the error only happens when the pointer
to-be-associated is in a separate module with deferred length.

Fall back is to simply copy the contents of the character array pointer into a
character string, but I was hoping to get this approach working, which is
zero-copy/zero-allocation.

Thanks!

[Bug analyzer/108935] Incorrect warning for infinite recursion

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

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

David Malcolm  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2023-02-27
 Status|UNCONFIRMED |ASSIGNED

--- Comment #1 from David Malcolm  ---
Thanks for filing this bug.  Confirmed; am investigating.

[Bug c++/108960] clear tf_partial in instantiate_template

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

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

Marek Polacek  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org
 Ever confirmed|0   |1
   Last reconfirmed||2023-02-27
 Status|UNCONFIRMED |ASSIGNED
   Keywords||internal-improvement

--- Comment #1 from Marek Polacek  ---
Mine for GCC 14.

[Bug c++/108960] New: clear tf_partial in instantiate_template

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

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

Bug ID: 108960
   Summary: clear tf_partial in instantiate_template
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

As the subject says; we should be able to do so since we're instantiating and
we have the full set of targs.

See  for
further discussion.

[Bug ipa/108959] [13 Regression] ice in modify_assignment, at ipa-param-manipulation.cc:1905

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|ice in modify_assignment,   |[13 Regression] ice in
   |at  |modify_assignment, at
   |ipa-param-manipulation.cc:1 |ipa-param-manipulation.cc:1
   |905 |905
   Target Milestone|--- |13.0

[Bug fortran/108937] Intrinsic IBITS(I,POS,LEN) fails when LEN equals to BIT_SIZE(I).

[saitofuyuki at jamstec dot go.jp via Gcc-bugs]

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

--- Comment #9 from saitofuyuki at jamstec dot go.jp ---
Thanks a lot for your effort.  I am very happy I can contribute.

[Bug target/106770] PPCLE: Unnecessary xxpermdi before mfvsrd

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

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

--- Comment #5 from Segher Boessenkool  ---
(In reply to Jens Seifert from comment #4)
> PPCLE with no special option means -mcpu=power8 -maltivec  (altivecle to be
> mor precise).

What?  No.

$ sh config.sub ppcle  
powerpcle-unknown-none

This is typically the old 32-bit PowerPC ELF format.  powerpcle-elf (which
non-canonically can be called ppcle-elf) for example, or ppcle-linux, but not
ppcle-aix and the like (that one doesn't even exist; at least one COFF
format has existed in the past though).

This may not matter for you, but it is awfully confusing for others.


powerpc64le-linux (and I believe all other existing ELFv2 ports) require
a p8 or later CPU, sure; but it is perfectly valid to have no AltiVec even
then, or for a port to default to some other CPU.  Currently we have no such
thing, and all default defaults are like you say, but that might change.

> vec_promote(, 1) should be a noop on ppcle.

It never is, not on powerpc64le either.  It always duplicates the selected
elt to all lanes.

> But value gets
> splatted to both left and right part of vector register. => 2 unnecesary
> xxpermdi

So why are those not optimised away?  *That* is the question!

> The rest of the operations are done on left and right part.
> 
> vec_extract(, 1) should be noop on ppcle. But value gets
> taken from right part of register which requires a xxpermdi
> 
> Overall 3 unnecessary xxpermdi. Don't know why the right part of register
> gets "preferred".

I don't know what you mean there?  The ABIs say where parameters and return
values are stored, but you mean something else?

[Bug other/107915] new test case g++.dg/contracts/contracts-tmpl-spec2.C in r13-4160-g2efb237ffc68ec fails

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2023-02-27

[Bug c/108959] ice in modify_assignment, at ipa-param-manipulation.cc:1905

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #2 from David Binderman  ---
Reduced code seems to be:

union U2 {
  long f0;
  int f1
};
g_16;
g_70[];
static func_61(int) {
  for (;;)
g_70[g_16] = 4;
}
static func_43(int *p_44) { func_61(*p_44); }
main() {
  union U2 l_38 = {9};
  int *l_49 = _38;
  func_43(l_49);
}

[Bug c/108959] ice in modify_assignment, at ipa-param-manipulation.cc:1905

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #1 from David Binderman  ---
The bug first seems to occur sometime between git hash g:5c43f06c228d169c,
dated 20230202 and g:f0065f207cf19cd9, dated 20230203.

[Bug c/108959] New: ice in modify_assignment, at ipa-param-manipulation.cc:1905

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 108959
   Summary: ice in modify_assignment, at
ipa-param-manipulation.cc:1905
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

Created attachment 54550
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54550=edit
C source code

The attached C code does this:

$ ../results/bin/gcc -c -w -O1 bug890.c
$ ../results/bin/gcc -c -w -O2 bug890.c
during IPA pass: inline
In function ‘func_43.constprop.isra’:
cc1: internal compiler error: in modify_assignment, at
ipa-param-manipulation.cc
:1905
0x76b001 ipa_param_body_adjustments::modify_assignment(gimple*, gimple**)
../../trunk.d1/gcc/ipa-param-manipulation.cc:1905

I have a reduction running.

[Bug target/108958] New: Powerpcle could generate mtvsrdd for zero extend DI to TI mode, when the TImode is in a vector register

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

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

Bug ID: 108958
   Summary: Powerpcle could generate mtvsrdd for zero extend DI to
TI mode, when the TImode is in a vector register
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: meissner at gcc dot gnu.org
  Target Milestone: ---

If you have a DImode variable (i.e. long) in a GPR, and you want to zero extend
it to TImode (i.e. `__int128', and the result is needed in a vector register,
you could just do a single `mtvsrdd' instruction, instead of separate zero a
GPR register, and then `mtvsrd' and `mtvsrdd' instructions.

[Bug fortran/108957] New: Fortran FE memleak with interfaces

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

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

Bug ID: 108957
   Summary: Fortran FE memleak with interfaces
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: anlauf at gcc dot gnu.org
  Target Milestone: ---

The frontend leaks memory for the following sample:

module m
  interface
 subroutine s ()
 end
  end interface
end

==7949== 3,176 (2,792 direct, 384 indirect) bytes in 1 blocks are definitely
lost in loss record 160 of 174
==7949==at 0x4C39571: calloc (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==7949==by 0x2E5B904: xcalloc (xmalloc.c:164)
==7949==by 0xC6C174: gfc_get_namespace(gfc_namespace*, int)
(symbol.cc:2875)
==7949==by 0xC12CB0: parse_interface (parse.cc:3789)
==7949==by 0xC12CB0: parse_spec(gfc_statement) (parse.cc:4150)
==7949==by 0xC173D8: parse_module() (parse.cc:6531)
==7949==by 0xC17851: gfc_parse_file() (parse.cc:6842)
==7949==by 0xC76E02: gfc_be_parse_file() (f95-lang.cc:229)
==7949==by 0x14F78AB: compile_file() (toplev.cc:444)
==7949==by 0x14FA80B: do_compile(bool) (toplev.cc:2125)
==7949==by 0x14FABD4: toplev::main(int, char**) (toplev.cc:2277)
==7949==by 0x2D9DE05: main (main.cc:39)

[Bug fortran/108937] Intrinsic IBITS(I,POS,LEN) fails when LEN equals to BIT_SIZE(I).

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

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

--- Comment #8 from CVS Commits  ---
The master branch has been updated by Harald Anlauf :

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

commit r13-6362-g6cce953ebec274f1468d5d3a0697cf05bb43b8f6
Author: Harald Anlauf 
Date:   Mon Feb 27 21:37:11 2023 +0100

Fortran: fix corner case of IBITS intrinsic [PR108937]

gcc/fortran/ChangeLog:

PR fortran/108937
* trans-intrinsic.cc (gfc_conv_intrinsic_ibits): Handle corner case
LEN argument of IBITS equal to BITSIZE(I).

gcc/testsuite/ChangeLog:

PR fortran/108937
* gfortran.dg/ibits_2.f90: New test.

[Bug libstdc++/108952] [10/11/12/13 Regression] Regression in uses_allocator_construction_args for pair of rvalue references

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

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

Jonathan Wakely  changed:

   What|Removed |Added

Summary|Regression in   |[10/11/12/13 Regression]
   |uses_allocator_construction |Regression in
   |_args for pair of rvalue|uses_allocator_construction
   |references  |_args for pair of rvalue
   ||references
   Keywords||rejects-valid
  Known to fail||10.1.0, 11.1.0, 12.1.0,
   ||13.0, 9.2.0
  Known to work||8.5.0, 9.1.0

--- Comment #6 from Jonathan Wakely  ---
Aha, I broke std::get(pair&&) for C++20 mode.

[Bug modula2/108956] [13 regression] SEGV in M2RTS_RegisterModule

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

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

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |13.0

[Bug modula2/108956] New: [13 regression] SEGV in M2RTS_RegisterModule

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

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

Bug ID: 108956
   Summary: [13 regression] SEGV in M2RTS_RegisterModule
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: modula2
  Assignee: gaius at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
  Target Milestone: ---
  Host: sparc-sun-solaris2.11
Target: sparc-sun-solaris2.11
 Build: sparc-sun-solaris2.11

Between 20230224 (0ccfa3884f638816af0f5a3f0ee2695e0771ef6d) and 20230227
(dfa85beebfbc2f879d30d3918f634feabc851782),
32-bit Solaris/SPARC bootstrap failed in stage 2:

m2/pge -k -l /vol/gcc/src/hg/master/local/gcc/m2/gm2-compiler/P2Build.bnf -o
m2/gm2-compiler-boot/P2Build.mod
make[3]: *** [/vol/gcc/src/hg/master/local/gcc/m2/Make-lang.in:1629:
m2/gm2-compiler-boot/P2Build.mod] Segmentation Fault

P3Build.mod is likewise affected.

gdb shows

Thread 2 received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1 (LWP 1)]
0x00034d24 in M2RTS_RegisterModule (name=0x25c98, 
libname=0x4dd24 <_M2_UnixArgs_init(int, char**, char**)>, init=..., 
fini=..., dependencies=...)
at /vol/gcc/src/hg/master/local/gcc/m2/pge-boot/GM2RTS.c:464
464 {
1: x/i $pc
=> 0x34d24 : ld  [ %i5 ], %g1
(gdb) p/x $i5
$1 = 0x2944
(gdb) bt
#0  0x00034d24 in M2RTS_RegisterModule (name=0x25c98, 
libname=0x4dd24 <_M2_UnixArgs_init(int, char**, char**)>, init=..., 
fini=..., dependencies=...)
at /vol/gcc/src/hg/master/local/gcc/m2/pge-boot/GM2RTS.c:464
#1  0x0004ddcc in _M2_UnixArgs_ctor::_M2_UnixArgs_ctor (
this=0x83958 <_M2_UnixArgs_ctor>)
at /vol/gcc/src/hg/master/local/gcc/m2/pge-boot/GUnixArgs.cc:89
#2  0x0004ddec in __static_initialization_and_destruction_0 ()
at /vol/gcc/src/hg/master/local/gcc/m2/pge-boot/GUnixArgs.cc:85
#3  0x0004de04 in _GLOBAL__sub_I_UnixArgs_GetArgC ()
at /vol/gcc/src/hg/master/local/gcc/m2/pge-boot/GUnixArgs.cc:91
#4  0xff1b2b48 in call_array () from /usr/lib/ld.so.1
#5  0xff1b2cd8 in call_init () from /usr/lib/ld.so.1
#6  0xff1b1fb4 in setup () from /usr/lib/ld.so.1
#7  0xff1c42ec in _setup () from /usr/lib/ld.so.1
#8  0xff1a44c0 in _rt_boot () from /usr/lib/ld.so.1

Address 0x2944 isn't mapped, thus the SEGV.

Apparently this is a caller/callee mismatch:

#0  0x00034d24 in M2RTS_RegisterModule (name=0x25c98, 
libname=0x4dd24 <_M2_UnixArgs_init(int, char**, char**)>, init=..., 
fini=..., dependencies=...)
at /vol/gcc/src/hg/master/local/gcc/m2/pge-boot/GM2RTS.c:464
464 {
(gdb) p dependencies
$4 = {proc = 0x0}
(gdb) up
#1  0x0004ddcc in _M2_UnixArgs_ctor::_M2_UnixArgs_ctor (
this=0x83958 <_M2_UnixArgs_ctor>)
at /vol/gcc/src/hg/master/local/gcc/m2/pge-boot/GUnixArgs.cc:89
89M2RTS_RegisterModule ("UnixArgs", _M2_UnixArgs_init,
_M2_UnixArgs_fini,
(gdb) p _M2_UnixArgs_dep
$3 = {void (void)} 0x4dd8c <_M2_UnixArgs_dep()>

dependencies is of type PROC (i.e.struct { PROC_t proc; }) while
_M2_UnixArgs_dep is extern "C" void _M2_UnixArgs_dep (void).

This is almost certainly caused by

commit 05652ac4e8b8685fe0c0f4ee2f75516d28bbf892
Author: Gaius Mulley 
Date:   Sat Feb 25 16:28:19 2023 +

modula-2 module registration process seems to fail with shared libraries
[PR
108261]

64-bit Solaris/SPARC (sparcv9-sun-solaris2.11) isn't affected.

[Bug target/108922] fmod() 13x slowdown in gcc4.9 dropping "fprem" and calling fmod()

[ubizjak at gmail dot com via Gcc-bugs]

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

Uroš Bizjak  changed:

   What|Removed |Added

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

--- Comment #32 from Uroš Bizjak  ---
Fixed by reverting g:4f2611b6e872.

[Bug target/108922] fmod() 13x slowdown in gcc4.9 dropping "fprem" and calling fmod()

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

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

--- Comment #31 from CVS Commits  ---
The master branch has been updated by Uros Bizjak :

https://gcc.gnu.org/g:8020c9c42349f51f75239b9d35a2be41848a97bd

commit r13-6361-g8020c9c42349f51f75239b9d35a2be41848a97bd
Author: Uros Bizjak 
Date:   Mon Feb 27 22:10:01 2023 +0100

i386: Do not constrain fmod and remainder patterns with
flag_finite_math_only [PR108922]

According to Intel ISA manual, fprem and fprem1 return NaN when invalid
arithmetic exception is generated. This is documented in Table 8-10 of the
ISA manual and makes these two instructions fully IEEE compatible.

The reverted patch was based on the data from table 3-30 and 3-31 of the
Intel ISA manual, where results in case of st(0) being infinity or
st(1) being 0 are not specified.

2023-02-27  Uroš Bizjak  

gcc/ChangeLog:

PR target/108922
Revert:
* config/i386/i386.md (fmodxf3): Enable for flag_finite_math_only
only.
(fmod3): Ditto.
(fpremxf4_i387): Ditto.
(reminderxf3): Ditto.
(reminder3): Ditto.
(fprem1xf4_i387): Ditto.

[Bug fortran/108937] Intrinsic IBITS(I,POS,LEN) fails when LEN equals to BIT_SIZE(I).

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #7 from anlauf at gcc dot gnu.org ---
Submitted: https://gcc.gnu.org/pipermail/fortran/2023-February/058984.html

[Bug c++/108955] Ultimate++ fails with its specialized AssertMoveable

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

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

--- Comment #4 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #3)
> The code is definitely invalid.
> 
> How to fix it is to move this:
> template 
> inline void AssertMoveable(T *t = 0) { if(t) AssertMoveable0(t); }
> 
> 
> Below the definitions of AssertMoveable0.
>  (__GNUC__ < 4 || __GNUC_MINOR__ < 1)
> 
> That is check is just wrong. Especially while GCC 13.0.1 is a stage 4
> compiler.
> 
> Maybe it should be just:
> __GNUC__ < 4 || (__GNUC__ == 4 && __GNUC_MINOR__ < 4)

That is if this is GCC before GCC 4.1.0 do it differently.
The reason why not many people hit this is because the first official release
of a major release of GCC these days is N.1.0 and you would only hit this
during the development of the trunk ...

[Bug c++/108955] Ultimate++ fails with its specialized AssertMoveable

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #3 from Andrew Pinski  ---
The code is definitely invalid.

How to fix it is to move this:
template 
inline void AssertMoveable(T *t = 0) { if(t) AssertMoveable0(t); }


Below the definitions of AssertMoveable0.
 (__GNUC__ < 4 || __GNUC_MINOR__ < 1)

That is check is just wrong. Especially while GCC 13.0.1 is a stage 4 compiler.

Maybe it should be just:
__GNUC__ < 4 || (__GNUC__ == 4 && __GNUC_MINOR__ < 4)

[Bug fortran/108937] Intrinsic IBITS(I,POS,LEN) fails when LEN equals to BIT_SIZE(I).

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

  Component|libfortran  |fortran
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2023-02-27
 Ever confirmed|0   |1

--- Comment #6 from anlauf at gcc dot gnu.org ---
Adjusting component as the issue is in the frontend generating the code.

[Bug c++/108955] Ultimate++ fails with its specialized AssertMoveable

[piotr5 at netscape dot net via Gcc-bugs]

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

--- Comment #2 from piotr5 at netscape dot net ---
Created attachment 54549
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54549=edit
gunzip then: c++-13 -c delme-E13.cxx

also fails with c++-12 so the problem must be in the preprocessor...

[Bug sanitizer/108894] -fsanitize=bounds missing bounds provided by __builtin_dynamic_object_size()

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

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

--- Comment #13 from qinzhao at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #12)
> Created attachment 54547 [details]
> gcc13-pr108894.patch
> 
> Untested fix.

several comments on the patch:

1. should the documentation of -fsanitize=bounds and -fsanitize=strict-bounds
be updated to reflect the interaction with -fstrict-flex-arrays=N?
2. there are several routines in c-decl.cc:
 static bool  flexible_array_member_type_p (const_tree type);
 static bool  one_element_array_type_p (const_tree type);
 static bool  zero_length_array_type_p (const_tree type);

can they be generalized  as well to be used in the routine 
"ubsan_instrument_bounds" to check for [], [0], or [1]? (in the patch lines
from 405 to 442). 
3. could you add comments for lines (I guess they are for [0])?

370   if (!bound)
371 bound = fold_build2 (PLUS_EXPR, TREE_TYPE (bound), bound,   371
{
372  build_int_cst (TREE_TYPE (bound), 1)); 372
  if (!c_dialect_cxx ()
373   && COMPLETE_TYPE_P (type)
374   && integer_zerop (TYPE_SIZE (type)))
375 bound = build_int_cst (TREE_TYPE (TYPE_MIN_VALUE (domain)),
-1);
376   else
377 return NULL_TREE;
378 }

[Bug c++/108955] Ultimate++ fails with its specialized AssertMoveable

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2023-02-27

--- Comment #1 from Andrew Pinski  ---
Can you attach the preprocessed source of the non-minimal example? Since it is
not obvious what is going wrong ...

[Bug c++/108955] New: Ultimate++ fails with its specialized AssertMoveable

[piotr5 at netscape dot net via Gcc-bugs]

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

Bug ID: 108955
   Summary: Ultimate++ fails with its specialized AssertMoveable
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: piotr5 at netscape dot net
  Target Milestone: ---

Created attachment 54548
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54548=edit
my failed attempt at a minimal example after preprocessor

I'm on gentoo with sys-devel/gcc-13.0.1_pre20230219 and tried to recompile
anything using Ultimate++ from upp.sf.net and already the heaqders fail to
compile. error: invalid type argument of unary '*' (have 'unsigned int')

this indicates the pre-c++11 test for "unsigned int" being a moveable data-type
failed. I tried to reproduce the problem with a minimal example but that had no
such problems in compilation. the way it's supposed to work is Core/Topt.h:
```
template 
inline void AssertMoveablePtr(T, T) {}

template 
inline void AssertMoveable0(T *t) { AssertMoveablePtr(&**t, *t); }
// COMPILATION ERROR HERE MEANS TYPE T WAS NOT MARKED AS Moveable

template 
struct Moveable_ {
friend void AssertMoveable0(T *) {}
};

template 
inline void AssertMoveable(T *t = 0) { if(t) AssertMoveable0(t); }

#if defined(COMPILER_MSC) || defined(COMPILER_GCC) && (__GNUC__ < 4 ||
__GNUC_MINOR__ < 1)
#define NTL_MOVEABLE(T) inline void AssertMoveable0(T *) {}
#else
#define NTL_MOVEABLE(T) template<> inline void AssertMoveable(T *)
{}
#endif


NTL_MOVEABLE(bool)
NTL_MOVEABLE(char)
NTL_MOVEABLE(signed char)
NTL_MOVEABLE(unsigned char)
NTL_MOVEABLE(short)
NTL_MOVEABLE(unsigned short)
NTL_MOVEABLE(int)
NTL_MOVEABLE(unsigned int)
NTL_MOVEABLE(long)
NTL_MOVEABLE(unsigned long)
NTL_MOVEABLE(int64)
NTL_MOVEABLE(uint64)
NTL_MOVEABLE(float)
NTL_MOVEABLE(double)
NTL_MOVEABLE(void *)
NTL_MOVEABLE(const void *)
```
then in destructor for Vector there is

AssertMoveable((T *)0);

where T = unsigned int

what is supposed to happen is that NTL_MOVEABLE expands to
template<> inline void AssertMoveable(T *) {}
so far it works as expected. however upon encontering that AssertMoveable((T
*)0); it is expanded into
inline void AssertMoveable0(T *t) { AssertMoveablePtr(&**t, *t); }
instead. is it because that was defined in the wrong order? but then why did my
minimal example work? why is there no such problem with gcc-12?

[Bug libfortran/108937] Intrinsic IBITS(I,POS,LEN) fails when LEN equals to BIT_SIZE(I).

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 CC||anlauf at gcc dot gnu.org

--- Comment #5 from anlauf at gcc dot gnu.org ---
Interestingly, we simplify IBITS(-1,0,32) to -1, and also the code generated
for ibits(x, p, lbits) produces the result expected by the reporter,
and which is also generated by Intel and NAG.

For ISHFT we have

/* ISHFT (I, SHIFT) = (abs (shift) >= BIT_SIZE (i))
? 0
: ((shift >= 0) ? i << shift : i >> -shift)
   where all shifts are logical shifts.  */

so we might as well consider doing what the reporter suggests.

[Bug target/108803] [10/11/12/13 Regression] wrong code for 128bit rotate on aarch64-unknown-linux-gnu with -Og

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||segher at gcc dot gnu.org

--- Comment #7 from Jakub Jelinek  ---
Besides this question whether it is ok to emit possibly out-of-bounds shifts
into code executed at runtime where source code didn't have any UB, provided
that their destination is only used in a conditional move that will not pick
that result up, I think we have a combiner bug here.

Copying what I wrote in
https://gcc.gnu.org/pipermail/gcc-patches/2023-February/612909.html:
I've added debug_bb_n after
every successful combine attempt,
--- gcc/combine.cc.jj   2023-01-02 09:32:43.720977011 +0100
+++ gcc/combine.cc  2023-02-27 19:27:28.151289055 +0100
@@ -4755,6 +4755,16 @@ try_combine (rtx_insn *i3, rtx_insn *i2,
   if (added_notes_insn && DF_INSN_LUID (added_notes_insn) < DF_INSN_LUID
(ret))
 ret = added_notes_insn;

+{
+static int cnt = 0;
+char buf[64];
+sprintf (buf, "/tmp/combine.%d", cnt++);
+FILE *f = fopen (buf, "a");
+fprintf (f, "%d\n", combine_successes);
+basic_block bb = BASIC_BLOCK_FOR_FN (cfun, 2);
+dump_bb (f, bb, 0, dump_flags_t ());
+fclose (f);
+}
   return ret;
 }

and I see
(insn 52 48 53 2 (set (reg:CC 66 cc)
(compare:CC (reg:SI 130)
(const_int 0 [0]))) "pr108803.c":12:25 437 {cmpsi}
 (expr_list:REG_DEAD (reg:SI 130)
(expr_list:REG_EQUAL (compare:CC (const_int -64 [0xffc0])
(const_int 0 [0]))
(nil
(insn 53 52 57 2 (set (reg:DI 152 [ _6+8 ])
(if_then_else:DI (ge (reg:CC 66 cc)
(const_int 0 [0]))
(reg:DI 132)
(const_int 0 [0]))) "pr108803.c":12:25 490 {*cmovdi_insn}
 (expr_list:REG_DEAD (reg:DI 132)
(nil)))
(insn 57 53 59 2 (set (reg:DI 151 [ _6 ])
(if_then_else:DI (ge (reg:CC 66 cc)
(const_int 0 [0]))
(const_int 0 [0])
(reg:DI 126))) "pr108803.c":12:25 490 {*cmovdi_insn}
 (expr_list:REG_DEAD (reg:CC 66 cc)
(nil)))
...
(insn 71 68 72 2 (set (reg:CC 66 cc)
(compare:CC (reg:SI 137)
(const_int 0 [0]))) "pr108803.c":12:42 437 {cmpsi}
 (expr_list:REG_DEAD (reg:SI 137)
(expr_list:REG_EQUAL (compare:CC (const_int -64 [0xffc0])
(const_int 0 [0]))
(nil
(insn 72 71 76 2 (set (reg:DI 153 [ _8 ])
(if_then_else:DI (ge (reg:CC 66 cc)
(const_int 0 [0]))
(reg:DI 139)
(reg:DI 153 [ _8 ]))) "pr108803.c":12:42 490 {*cmovdi_insn}
 (expr_list:REG_DEAD (reg:DI 139)
(nil)))
(insn 76 72 77 2 (set (reg:DI 154 [ _8+8 ])
(if_then_else:DI (ge (reg:CC 66 cc)
(const_int 0 [0]))
(reg:DI 138)
(reg:DI 127))) "pr108803.c":12:42 490 {*cmovdi_insn}
 (expr_list:REG_DEAD (reg:DI 138)
(expr_list:REG_DEAD (reg:DI 127)
(expr_list:REG_DEAD (reg:CC 66 cc)
(nil)
(insn 77 76 78 2 (set (reg:DI 159 [ b ])
(ior:DI (reg:DI 151 [ _6 ])
(reg:DI 126))) "pr108803.c":12:12 537 {iordi3}
 (expr_list:REG_DEAD (reg:DI 126)
(expr_list:REG_DEAD (reg:DI 151 [ _6 ])
(nil
(insn 78 77 80 2 (set (reg:DI 160 [ b+8 ])
(reg:DI 152 [ _6+8 ])) "pr108803.c":12:12 65 {*movdi_aarch64}
 (expr_list:REG_DEAD (reg:DI 152 [ _6+8 ])
(nil)))
in one of the dumps which still looks correct from brief skimming,
r130 here is k - 64 aka -64 and it is the pair of conditional moves of the
first TImode shift, effectively (a + 63) << 0 but 0 is obfuscated at
expansion time, while the second pair of conditional moves are for the
second TImode shift, effectively (a + 63) >> (0 & 63) and then both ored
together.  It makes sense that the second set of conditional moves are
optimized
earlier because the shift count in that case is more constrained, it is masked
with 63,
so one can see (0 & 63) - 64 < 0, while r130 comparison isn't optimized so
early
because r130 has 2 users and one of them couldn't be merged.
Note, this is the exact spot why I think we want the other patch, we can't
merge
(insn 40 37 41 2 (set (reg:SI 130)
(const_int -64 [0xffc0])) "pr108803.c":12:25 64
{*movsi_aarch64}
 (nil))
(insn 41 40 43 2 (set (reg:DI 132)
(ashift:DI (reg:DI 126)
(subreg:QI (reg:SI 130) 0))) "pr108803.c":12:25 781
{*aarch64_ashl_sisd_or_int_di3}
 (expr_list:REG_EQUAL (ashift:DI (reg:DI 126)
(const_int -64 [0xffc0]))
(nil)))
because the backend doesn't like out of bounds shift count immediates in the
instruction
directly.
When doing
Trying 53 -> 78:
   53: r152:DI={(cc:CC>=0)?r132:DI:0}
  REG_DEAD r132:DI
   78: r160:DI=r152:DI
  REG_DEAD r152:DI
Successfully matched this instruction:
(set 

[Bug libfortran/108937] Intrinsic IBITS(I,POS,LEN) fails when LEN equals to BIT_SIZE(I).

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

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

--- Comment #4 from kargl at gcc dot gnu.org ---
(In reply to saitofuyuki from comment #3)
> Thanks a lot.
> 
> > Not sure it's a bug.
> 
> I see.  I do agree it's not a bug and the answer of the particular case is
> undefined.
> 
> But (for 32-bit integer case), since implemented ISHFT(I,32) returns 0 for
> any representation of I, I suppose it may be better to return I as it is by
> IBITS(I,0,32) (again, I agree it is not defined by standard).
> 
> Anyway, thanks a lot for your comment.

In the end, gfortran should probably do something that a user
might expect, and that would likely be two-complements wrap-around
unsigned integer arithmetic.

[Bug c++/108936] internal compiler error: in type_has_nontrivial_copy_init, at cp/tree.cc:4525

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

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #2 from Marek Polacek  ---
template
struct Endianness
{
  static constexpr bool BigEndianHost = (union{short s;char c;}){1}.c != 1;
};

int main()
{
  Endianness<>::BigEndianHost;
}


$ ./cc1plus -quiet bz.C
bz.C: In instantiation of ‘constexpr const bool Endianness<>::BigEndianHost’:
bz.C:9:17:   required from here
bz.C:4:69: internal compiler error: in type_has_nontrivial_copy_init, at
cp/tree.cc:4631
4 |   static constexpr bool BigEndianHost = (union{short s;char c;}){1}.c
!= 1;
  | ^
0x1058fa5 type_has_nontrivial_copy_init(tree_node const*)
/home/mpolacek/src/gcc/gcc/cp/tree.cc:4631
0x1047c78 build_target_expr_with_type(tree_node*, tree_node*, int)
/home/mpolacek/src/gcc/gcc/cp/tree.cc:904
0x1047e65 get_target_expr(tree_node*, int)
/home/mpolacek/src/gcc/gcc/cp/tree.cc:948
0x10112be finish_compound_literal(tree_node*, tree_node*, int, fcl_t)
/home/mpolacek/src/gcc/gcc/cp/semantics.cc:3356
0xfbfd62 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*)
/home/mpolacek/src/gcc/gcc/cp/pt.cc:21515
0xfb763b tsubst_non_call_postfix_expression
/home/mpolacek/src/gcc/gcc/cp/pt.cc:19866
0xfbe98a tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*)
/home/mpolacek/src/gcc/gcc/cp/pt.cc:21314
0xfbab12 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*)
/home/mpolacek/src/gcc/gcc/cp/pt.cc:20576
0xfb7019 tsubst_expr(tree_node*, tree_node*, int, tree_node*)
/home/mpolacek/src/gcc/gcc/cp/pt.cc:19775
0xfa50de tsubst_init
/home/mpolacek/src/gcc/gcc/cp/pt.cc:17014
0xfd413b regenerate_decl_from_template
/home/mpolacek/src/gcc/gcc/cp/pt.cc:26334
0xfd62e8 instantiate_body
/home/mpolacek/src/gcc/gcc/cp/pt.cc:26651
0xfd8412 instantiate_decl(tree_node*, bool, bool)
/home/mpolacek/src/gcc/gcc/cp/pt.cc:27006
0xdc8886 mark_used(tree_node*, int)
/home/mpolacek/src/gcc/gcc/cp/decl2.cc:5840
0x1016792 finish_id_expression_1
/home/mpolacek/src/gcc/gcc/cp/semantics.cc:4252
0x1017079 finish_id_expression(tree_node*, tree_node*, tree_node*, cp_id_kind*,
bool, bool, bool*, bool, bool, bool, bool, char const**, unsigned int)
/home/mpolacek/src/gcc/gcc/cp/semantics.cc:4398
0xed94b6 cp_parser_primary_expression
/home/mpolacek/src/gcc/gcc/cp/parser.cc:6149
0xedd48c cp_parser_postfix_expression
/home/mpolacek/src/gcc/gcc/cp/parser.cc:
0xee0e91 cp_parser_unary_expression
/home/mpolacek/src/gcc/gcc/cp/parser.cc:9138
0xee243b cp_parser_cast_expression
/home/mpolacek/src/gcc/gcc/cp/parser.cc:10044

[Bug target/106770] PPCLE: Unnecessary xxpermdi before mfvsrd

[jens.seifert at de dot ibm.com via Gcc-bugs]

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

--- Comment #4 from Jens Seifert  ---
PPCLE with no special option means -mcpu=power8 -maltivec  (altivecle to be mor
precise).

vec_promote(, 1) should be a noop on ppcle. But value gets
splatted to both left and right part of vector register. => 2 unnecesary
xxpermdi
The rest of the operations are done on left and right part.

vec_extract(, 1) should be noop on ppcle. But value gets taken
from right part of register which requires a xxpermdi

Overall 3 unnecessary xxpermdi. Don't know why the right part of register gets
"preferred".

[Bug testsuite/108942] ICE in build2, at tree.c: 5096 for gcc/testsuite/gcc.dg/torture/ssa-fre-7.c:23:3

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

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

Andrew Pinski  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=108954
   Keywords|ice-on-invalid-code |
  Component|c   |testsuite

--- Comment #2 from Andrew Pinski  ---
I split the ICE off into PR 108954 as I found a testcase which ICEs on
x86_64-linux-gnu.

So this bug report is just about the testsuite fix.

[Bug c/108954] New: ICE with invalid gimple source

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

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

Bug ID: 108954
   Summary: ICE with invalid gimple source
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: ice-on-invalid-code
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---

Take:
```
/* { dg-do compile } */
/* { dg-require-effective-target int32 } */
/* { dg-skip-if "" { *-*-* } { "-O0" } { "" } } */
/* { dg-additional-options "-fgimple -fdump-tree-fre1" } */

typedef int v4si __attribute__((vector_size(16)));

int __GIMPLE (ssa,startwith("fre"))
foo (int c)
{
  int * p;
  int i;
  int x[4];
  short unsigned int _1;
  short unsigned int _2;
  int _7;
  v4si _6;

  __BB(2):
  i_3 = 0;
  _1 = (short unsigned int) i_3;
  _2 = _1 * 4ul;
  p_4 = _Literal (int *)  + _2; /* { dg-error "" } */
  _6 = _Literal (v4si) { c_5(D), c_5(D), c_5(D), c_5(D) };
  __MEM  ((v4si *)p_4) = _6;
  _7 = x[0];
  return _7;
}
```
This should not ICE but current does:

:19:3: internal compiler error: in build2, at tree.cc:5096
   19 |   p_4 = _Literal (int *)  + _2;
  |   ^~~

[Bug c/108942] ICE in build2, at tree.c: 5096 for gcc/testsuite/gcc.dg/torture/ssa-fre-7.c:23:3

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2023-02-27
 Status|UNCONFIRMED |NEW
   Keywords|ice-on-valid-code   |ice-on-invalid-code

--- Comment #1 from Andrew Pinski  ---
So there are two issues here, one a testsuite issue:
  long unsigned int _1;
  long unsigned int _2;

  _1 = (long unsigned int) i_3;

Those types should have been __SIZE_TYPE__ .

The other is the ICE happens because of the invalidness of the above ...

[Bug libstdc++/108952] Regression in uses_allocator_construction_args for pair of rvalue references

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

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

--- Comment #5 from Jonathan Wakely  ---
(In reply to Peter Dimov from comment #4)
> An easy fix is to use `std::get<0>` instead of `.first`.

Yeah I tried that, but I think there's an additional change needed (or I messed
something up).

[Bug libstdc++/108952] Regression in uses_allocator_construction_args for pair of rvalue references

[pdimov at gmail dot com via Gcc-bugs]

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

Peter Dimov  changed:

   What|Removed |Added

 CC||pdimov at gmail dot com

--- Comment #4 from Peter Dimov  ---
An easy fix is to use `std::get<0>` instead of `.first`.

[Bug libstdc++/108952] Regression in uses_allocator_construction_args for pair of rvalue references

[rs2740 at gmail dot com via Gcc-bugs]

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

TC  changed:

   What|Removed |Added

 CC||rs2740 at gmail dot com

--- Comment #3 from TC  ---
https://cplusplus.github.io/LWG/issue3527

[Bug tree-optimization/108953] inefficient codegen for trivial equality

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #1 from Jakub Jelinek  ---
I don't think there is anything the C++ FE should do here, user can write it
like that
by hand too:
bool check(C const& lhs, C const& rhs) {
  if (lhs.a != rhs.a) return false;
  if (lhs.b != rhs.b) return false;
  if (lhs.c != rhs.c) return false;
  if (lhs.d != rhs.d) return false;
  if (lhs.e != rhs.e) return false;
  if (lhs.f != rhs.f) return false;
  if (lhs.g != rhs.g) return false;
  return true;
}
etc., so we should pattern match this somewhere during GIMPLE opts.

The memcmp issue is a RTL issue (so I think we want actually two bugs), at
GIMPLE level it is optimized into:
  _1 = __builtin_memcmp_eq (lhs_3(D), rhs_4(D), 12);
  _5 = _1 == 0;
  return _5;
which is I think what we want.

The reason for doing conditional branch after each comparison is
targetm.compare_by_pieces_branch_ratio (DImode) tells it not to batch more than
one.
Not really sure if we should override it to something else and on which
targets.

The reason for the weird
mov eax, 1
testeax, eax
seteal
instead of
xor eax, eax
and
xor eax, eax
testeax, eax
seteal
instead of
mov eax, 1
is that the epilogue is threaded only too late where the constant propagation
through it isn't possible.

[Bug libstdc++/108952] Regression in uses_allocator_construction_args for pair of rvalue references

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
 Ever confirmed|0   |1
   Last reconfirmed||2023-02-27

--- Comment #2 from Jonathan Wakely  ---
The problem is that std::move(pr).first always yields an lvalue, even if the
type of pr is pair.

I tried to simplify uses_allocator_construction_args to avoid indirection,
which I think is the source of this issue.

[Bug sanitizer/108894] -fsanitize=bounds missing bounds provided by __builtin_dynamic_object_size()

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

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

--- Comment #12 from Jakub Jelinek  ---
Created attachment 54547
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54547=edit
gcc13-pr108894.patch

Untested fix.

[Bug c++/108953] inefficient codegen for trivial equality

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement
   Keywords||missed-optimization

[Bug modula2/108944] libgm2/libm2pim/sckt.cc:254:3: warning: memset() called to fill 0 bytes. [memsetZeroBytes]

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

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

Gaius Mulley  changed:

   What|Removed |Added

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

--- Comment #4 from Gaius Mulley  ---
many thanks for the flag info - will use these when building.
Closing now that the master branch has this fix.

[Bug modula2/108944] libgm2/libm2pim/sckt.cc:254:3: warning: memset() called to fill 0 bytes. [memsetZeroBytes]

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

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

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

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

commit r13-6359-ge5fcf084e381aefe170dcd418dc97e469dacfa91
Author: Gaius Mulley 
Date:   Mon Feb 27 16:29:18 2023 +

libgm2/libm2pim/sckt.cc:254:3: warning: memset() called to fill 0 bytes
[PR108944]

The pattern parameter to memset is second.  Correct an obvious mistake
in libm2pim/sckt.cc.

libgm2/ChangeLog:

PR modula2/108944
* libm2pim/sckt.cc (getLocalIP): Correct parameter order.

Signed-off-by: Gaius Mulley 

[Bug c++/108953] New: inefficient codegen for trivial equality

[barry.revzin at gmail dot com via Gcc-bugs]

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

Bug ID: 108953
   Summary: inefficient codegen for trivial equality
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: barry.revzin at gmail dot com
  Target Milestone: ---

Consider this example:

#include 
#include 
#include 

struct C
{
   uint8_t a;
   uint8_t b;
   uint8_t c;
   uint8_t d;
   uint16_t e;
   uint16_t f;
   int32_t g;

   bool operator==(C const&) const = default;
};

bool check(C const& lhs, C const& rhs) {
#ifdef MEMCMP
return memcmp(, , sizeof(lhs)) == 0;
#else
return lhs == rhs;
#endif
}

There are two implementations of check here, but lead to suboptimal code.

When using MEMCMP, gcc trunk -O3 emits:

check(C const&, C const&):
mov rax, QWORD PTR [rsi]
cmp QWORD PTR [rdi], rax
je  .L5
.L2:
mov eax, 1
testeax, eax
seteal
ret
.L5:
mov eax, DWORD PTR [rsi+8]
cmp DWORD PTR [rdi+8], eax
jne .L2
xor eax, eax
testeax, eax
seteal
ret

There's a few extra instructions here (mov eax, 1; test eax, eax; sete al;...
do we need all three of those to return 0?)

When using defaulted comparisons, gcc trunk -O3 doesn't collapse any of the
comparisons, and instead emits 7 distinct checks:

check(C const&, C const&):
movzx   ecx, BYTE PTR [rsi]
xor eax, eax
cmp BYTE PTR [rdi], cl
jne .L1
movzx   edx, BYTE PTR [rsi+1]
cmp BYTE PTR [rdi+1], dl
jne .L1
movzx   edx, BYTE PTR [rsi+2]
cmp BYTE PTR [rdi+2], dl
jne .L1
movzx   edx, BYTE PTR [rsi+3]
cmp BYTE PTR [rdi+3], dl
jne .L1
movzx   edx, WORD PTR [rsi+4]
cmp WORD PTR [rdi+4], dx
jne .L1
movzx   eax, WORD PTR [rsi+6]
cmp WORD PTR [rdi+6], ax
mov edx, DWORD PTR [rsi+8]
seteal
cmp DWORD PTR [rdi+8], edx
setedl
and eax, edx
.L1:
ret

Compare this to clang, which for both the memcmp and the default equality
versions emits this:

check(C const&, C const&):# @check(C const&, C const&)
mov rax, qword ptr [rdi]
xor rax, qword ptr [rsi]
mov ecx, dword ptr [rdi + 8]
xor ecx, dword ptr [rsi + 8]
or  rcx, rax
seteal
ret

Looks like there are two missing optimizations here for gcc: (1) the memcmp
does get optimized into an 8-byte and 4-byte comparison, but then the result of
that optimization doesn't get optimized further and (2) multiple trivial
comparisons don't get coalesced together.

[Bug tree-optimization/108949] Optimize shift counts

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement
   Keywords||missed-optimization

[Bug target/108940] Offset of pointer to global variable not set correctly for position independent executable

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #4 from Andrew Pinski  ---
You need to link with -pie if you want a PIE executable. BUT that does not work
with -elf/-eabi targets as there is no loader.

Since there is no loader and shared libraries are not supported with bare
metal, you need to have a modified binutils to do the right thing and have a
correct target.

[Bug target/106770] PPCLE: Unnecessary xxpermdi before mfvsrd

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

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

Segher Boessenkool  changed:

   What|Removed |Added

 CC||segher at gcc dot gnu.org

--- Comment #3 from Segher Boessenkool  ---
You get xxpermdi ,3 only with -mlittle.  Maybe you mean this is for target
powerpc64le-linux?  That is very different from powerpcle-linux fwiw, don't
confuse those :-)

What -mcpu= did you use?

xxpermdi doesn't extract any element of course, it is mfvsr[l]d that does
that.  But duplicating the element you extract isn't needed, sure.

[Bug target/108940] Offset of pointer to global variable not set correctly for position independent executable

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

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

--- Comment #3 from Andrew Pinski  ---
Can you instead attach the output of `readelf -a`?

[Bug tree-optimization/107561] [13 Regression] g++.dg/pr71488.C and [g++.dg/warn/Warray-bounds-16.C -m32] regression due to -Wstringop-overflow problem

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

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

--- Comment #14 from Aldy Hernandez  ---
(In reply to Richard Biener from comment #11)
> So I've missed the VR_ANTI_RANGE handling in get_size_range where we run into
> 
>   wide_int maxsize = wi::to_wide (max_object_size ());
>   min = wide_int::from (min, maxsize.get_precision (), UNSIGNED);
>   max = wide_int::from (max, maxsize.get_precision (), UNSIGNED);
>   if (wi::eq_p (0, min - 1))
> {
>   /* EXP is unsigned and not in the range [1, MAX].  That means
>  it's either zero or greater than MAX.  Even though 0 would
>  normally be detected by -Walloc-zero, unless ALLOW_ZERO
>  is set, set the range to [MAX, TYPE_MAX] so that when MAX
>  is greater than the limit the whole range is diagnosed.  */
>   wide_int maxsize = wi::to_wide (max_object_size ());
>   if (flags & SR_ALLOW_ZERO)
> {
>   if (wi::leu_p (maxsize, max + 1)
>   || !(flags & SR_USE_LARGEST))
> min = max = wi::zero (expprec);
>   else
> {
>   min = max + 1;
>   max = wi::to_wide (TYPE_MAX_VALUE (exptype));
> }
> }
>   else
> {
>   min = max + 1;
>   max = wi::to_wide (TYPE_MAX_VALUE (exptype));
> }
> 
> and from [0,0] [8, +INF] pick [8, +INF] based on the comments reasoning.

Ughh, you're reaching all the problematic cases I ran into while trying to
remove legacy.

> 
> This all wouldn't happen if we'd be able to CSE the zero size ...
> 
> We can now try to put additional heuristic ontop of the above heuristic,
> namely when the object we write to is of size zero set SR_ALLOW_ZERO.
> Or try to "undo" the multiplication trick which would probably make us
> end up with VARYING.
> 
> I'll note that with the earlier proposed change we regress the following,
> that's an observation I make a lot of times - all "weirdness" in the code
> is backed by (artificial) testcases verifying it works exactly as coded ...

+1

> 
> FAIL: gcc.dg/Wstringop-overflow-15.c pr82608 (test for warnings, line 37)
> FAIL: gcc.dg/Wstringop-overflow-15.c pr82608 (test for warnings, line 38)
> FAIL: gcc.dg/Wstringop-overflow-15.c pr82608 (test for warnings, line 69)
> FAIL: gcc.dg/Wstringop-overflow-15.c pr82608 (test for warnings, line 70)
> FAIL: gcc.dg/Wstringop-overflow-56.c  (test for warnings, line 64)
> FAIL: gcc.dg/Wstringop-overflow-56.c  (test for warnings, line 75)
> FAIL: gcc.dg/Wstringop-overflow-56.c  (test for warnings, line 86)
> FAIL: gcc.dg/Wstringop-overflow-56.c  (test for warnings, line 97)
> FAIL: gcc.dg/Wstringop-overflow-56.c  (test for warnings, line 108)
> FAIL: gcc.dg/Wstringop-overflow-56.c  (test for warnings, line 148)
> FAIL: gcc.dg/Wstringop-overflow-56.c  (test for warnings, line 159)
> FAIL: gcc.dg/attr-alloc_size-11.c  (test for warnings, line 52)
> FAIL: gcc.dg/attr-alloc_size-11.c  (test for warnings, line 53)
> FAIL: gcc.dg/attr-alloc_size-11.c  (test for warnings, line 54)
> FAIL: gcc.dg/attr-alloc_size-11.c  (test for warnings, line 55)
> FAIL: gcc.dg/attr-alloc_size-11.c  (test for warnings, line 56)
> FAIL: gcc.dg/attr-alloc_size-11.c  (test for warnings, line 57)
> FAIL: gcc.dg/attr-alloc_size-11.c  (test for warnings, line 58)
> FAIL: gcc.dg/attr-alloc_size-11.c  (test for warnings, line 64)
> FAIL: gcc.dg/attr-alloc_size-11.c  (test for warnings, line 65)
> FAIL: gcc.dg/attr-alloc_size-3.c  (test for warnings, line 438)
> FAIL: gcc.dg/attr-alloc_size-4.c  (test for warnings, line 138)
> FAIL: gcc.dg/attr-alloc_size-4.c  (test for warnings, line 143)
> FAIL: gcc.dg/attr-alloc_size-4.c  (test for warnings, line 187)
> FAIL: gcc.dg/pr98721-1.c  (test for warnings, line 11)
> FAIL: gcc.dg/pr98721-1.c  (test for warnings, line 12)
> 
> For example gcc.dg/pr98721-1.c has
> 
> int
> foo (int n)
> {
>   if (n <= 0)
> {
>   char vla[n];  /* { dg-message "source object 'vla'
> of size 0" } */
>   return __builtin_strlen (vla);/* { dg-warning "'__builtin_strlen'
> reading 1 or more bytes from a region of size 0" } */
> 
> but of course we do not diagnose
> 
> int
> foo (int n)
> {
>   if (n < 0)
> {
>   char vla[n];
> 
> or when no condition is present or a n > 32 condition is present.

Yup, ran into that too.

> 
> I fear it's not possible to "fix" this testcase without changing the
> expectation on a bunch of other testcases.  But the messaging to the
> user is quite unhelpful because it doesn't actually inform him about
> above reasoning.

Agreed.

[Bug libstdc++/108952] Regression in uses_allocator_construction_args for pair of rvalue references

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

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

--- Comment #1 from Andrew Pinski  ---
Created attachment 54546
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54546=edit
testcase

Please next time also attach or put inline the testcase

[Bug libstdc++/108952] New: Regression in uses_allocator_construction_args for pair of rvalue references

[christian.mazakas at gmail dot com via Gcc-bugs]

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

Bug ID: 108952
   Summary: Regression in uses_allocator_construction_args for
pair of rvalue references
   Product: gcc
   Version: 12.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: christian.mazakas at gmail dot com
  Target Milestone: ---

Consider the following example as demonstrated on Compiler Explorer:
https://godbolt.org/z/jhxxK9hT3

The C++20 version of uses_allocator_construction_args seems to inappropriately
forward the pair's data members and when they happen to be rvalue references,
they decay to an lvalue reference which breaks constructibility tests.

This same code will pass for previous standards versions.

I'm not sure about the range of compilers affected by this but it seems to
follow wherever C++20 support is enabled.

[Bug target/108950] [11/12/13 Regression] ICE: verify_gimple failed (error: conversion of register to a different size in 'view_convert_expr'; error: type mismatch in 'widen_sum_expr') since r11-418-g

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

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

Martin Liška  changed:

   What|Removed |Added

   Last reconfirmed||2023-02-27
 CC||marxin at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org
Summary|[11/12/13 Regression] ICE:  |[11/12/13 Regression] ICE:
   |verify_gimple failed|verify_gimple failed
   |(error: conversion of   |(error: conversion of
   |register to a different |register to a different
   |size in |size in
   |'view_convert_expr'; error: |'view_convert_expr'; error:
   |type mismatch in|type mismatch in
   |'widen_sum_expr')   |'widen_sum_expr') since
   ||r11-418-g584a3c080bbd6e
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Started with r11-418-g584a3c080bbd6e.

[Bug modula2/108944] libgm2/libm2pim/sckt.cc:254:3: warning: memset() called to fill 0 bytes. [memsetZeroBytes]

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #2 from David Binderman  ---
(In reply to Gaius Mulley from comment #1)
> Thank you very much for reporting this bug - very useful regarding PR108835 
> (or at least it is related and timely).

You are welcome. gcc flags -Wall and -Wmemset-transposed-args
seem to provide this warning.

For example:

memset.cc:17:15: warning: ‘memset’ used with constant zero length parameter;
thi
s could be due to transposed parameters [-Wmemset-transposed-args]
   17 | memset( t.buf1, 20, 0);
  | ~~^~~~

[Bug c++/108936] internal compiler error: in type_has_nontrivial_copy_init, at cp/tree.cc:4525

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

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

Martin Liška  changed:

   What|Removed |Added

   Last reconfirmed||2023-02-27
 CC||jason at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Started likely with r9-1493-g8945521a50a7dd26, it was rejected before the
revision.

[Bug libstdc++/108951] New: std::valarray doesn't support extended alignment

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

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

Bug ID: 108951
   Summary: std::valarray doesn't support extended alignment
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

Memory for valarrays is obtained via:

  template
inline _Tp*
__valarray_get_storage(size_t __n)
{ return static_cast<_Tp*>(operator new(__n * sizeof(_Tp))); }

  // Return memory to the system
  inline void
  __valarray_release_memory(void* __p)
  { operator delete(__p); }


This will be wrong for types with extended alignments.

We should either copy the code from std::allocator::allocate, or just use
std::allocator<_Tp> here.

[Bug tree-optimization/107561] [13 Regression] g++.dg/pr71488.C and [g++.dg/warn/Warray-bounds-16.C -m32] regression due to -Wstringop-overflow problem

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

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

--- Comment #13 from Jonathan Wakely  ---
(In reply to Richard Biener from comment #11)
> We can again work around this in libstdc++ by CSEing ->_M_size ourselves.
> The following helps:
> 
> diff --git a/libstdc++-v3/include/std/valarray
> b/libstdc++-v3/include/std/valarray
> index 7a23c27a0ce..7383071f98d 100644
> --- a/libstdc++-v3/include/std/valarray
> +++ b/libstdc++-v3/include/std/valarray
> @@ -647,8 +647,13 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>  inline
>  valarray<_Tp>::valarray(const valarray<_Tp>& __v)
>  : _M_size(__v._M_size),
> _M_data(__valarray_get_storage<_Tp>(__v._M_size))
> -{ std::__valarray_copy_construct(__v._M_data, __v._M_data + _M_size,
> -_M_data); }
> +{
> +  auto __v_M_size = __v._M_size;
> +  _M_size = __v_M_size;
> +  _M_data = __valarray_get_storage<_Tp>(__v_M_size);
> +  std::__valarray_copy_construct(__v._M_data, __v._M_data + __v_M_size,
> +_M_data);
> +}
>  
>  #if __cplusplus >= 201103L
>template

Ugh, gross.

This makes no sense to me. this->_M_size is already a local copy of __v._M_size
that cannot have escaped, because its enclosing object hasn't been constructed
yet. Why do we need another "more local" copy of it?

_M_size is a copy of __v._M_size, which is passed to the get_storage function.
The compiler thinks that the get_storage call might modify __v, but it can't
modify this->_M_size. So then _M_size still has the same value when passed to
the copy_construct call.


Since it would be undefined for users to modify this->_M_size or __v._M_size
from operator new (because they cannot access an object under construction, and
cannot modify an object while it's in the process of being copied), I wish we
could say that a specific call to operator new does not modify anything
reachable from the enclosing function's arguments, including `this`.

Or maybe we just teach the compiler that operator new will not touch anything
defined in namespace std, on pain of death.

[Bug tree-optimization/107561] [13 Regression] g++.dg/pr71488.C and [g++.dg/warn/Warray-bounds-16.C -m32] regression due to -Wstringop-overflow problem

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

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

--- Comment #12 from Aldy Hernandez  ---
(In reply to Richard Biener from comment #10)
> (In reply to Richard Biener from comment #9)
> > Note I think there's still a bug in value_range (irange) here. 
> > get_size_range
> > does
> > 
> >   if (integral)
> > {
> >   value_range vr;
> > 
> >   query->range_of_expr (vr, exp, stmt);
> > 
> >   if (vr.undefined_p ())
> > vr.set_varying (TREE_TYPE (exp));
> >   range_type = vr.kind ();
> >   min = wi::to_wide (vr.min ());
> >   max = wi::to_wide (vr.max ());
> > 
> > and we have vr:
> > 
> > (gdb) p vr
> > $13 = { = { = {
> >   _vptr.vrange = 0x3693a30 +16>, 
> >   m_kind = VR_ANTI_RANGE, m_discriminator = VR_IRANGE}, 
> > m_num_ranges = 1 '\001', m_max_ranges = 1 '\001', 
> > m_nonzero_mask = , m_base = 0x7fffc8f0}, m_ranges = {
> > , }}
> > (gdb) p vr.dump (stderr)
> > [irange] unsigned int [0, 0][8, +INF]$17 = void
> > 
> > but vr.min () produces 1 and vr.max () produces 7, just as if it doesn't
> > interpret VR_ANTI_RANGE transparently here (if that's the intent?!).
> > At least
> > 
> > // Return the highest bound of a range expressed as a tree.
> > 
> > inline tree
> > irange::tree_upper_bound () const
> > 
> > suggests that.  Note that vr.num_pairs () produces 2 (because constant_p ())
> > but vr.m_num_ranges is 1 and tree_upper_bound uses m_num_ranges.
> > 
> > I suppose irange::{min,max,tree_lower_bound,tree_upper_bound} miss "support"
> > for legacy_mode_p here.
> 
> OTOH gimple-array-bounds.cc does
> 
>   const value_range *vr = NULL;
>   if (TREE_CODE (low_sub_org) == SSA_NAME)
> {
>   vr = get_value_range (low_sub_org, stmt);
>   if (!vr->undefined_p () && !vr->varying_p ())
> {
>   low_sub = vr->kind () == VR_RANGE ? vr->max () : vr->min ();
>   up_sub = vr->kind () == VR_RANGE ? vr->min () : vr->max ();
> }
> 
> so the bug is a documentation bug on min/max/lower/upper bound?!
> 
> I'm policeing other uses of value_range right now.

Haven't looked at this yet, but min/max/lower/upper bound are broken and
inconsistent.  They give different results in legacy and the new irange API. 
This was not by intent, but it crept in :/.  My fault.  I noticed this when
removing the legacy code for next stage1.

[Bug modula2/108944] libgm2/libm2pim/sckt.cc:254:3: warning: memset() called to fill 0 bytes. [memsetZeroBytes]

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

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

Gaius Mulley  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2023-02-27
 Ever confirmed|0   |1

--- Comment #1 from Gaius Mulley  ---
Thank you very much for reporting this bug - very useful regarding PR108835 
(or at least it is related and timely).

[Bug analyzer] -Wanalyser-malloc-leak false positive on gcc 12.1/12.2

[Martin Georgiev via Gcc-bugs]

I send this to gcc-help but it would probably be more appropriate.
While compiling a source file with the -fanalyzer option I got a compiler
-Wanalyser-malloc-leak warning. I followed the diagnostic message but
didn't see the problem so I decided to go look at the assembly code.
Compiling the same source file with gcc 11 and gcc trunk generated
identical assembly code but I did not get the error message. Is this a gcc
12 bug or am I missing something?

You can recreate the behavior described above by switching between
different gcc versions on godbolt.org.


#include 
#include 
#include 

struct Binary_Tree_Node {
struct Binary_Tree_Node *left;
struct Binary_Tree_Node *right;
struct Binary_Tree_Node *parent;
void *key;
};

typedef struct{
struct Binary_Tree_Node *root;
int (*comp)(const void *, const void *);
void (*key_destr)(void *);
size_t size;
} Binary_Tree;

struct AVL_Node {
struct Binary_Tree_Node node;
int balance;
};

typedef struct {
Binary_Tree tree;
} AVL_Tree;


enum cdsa_err {ERR_OK = 0, ERR_OUT_OF_MEM, ERR_ELEMENT_NOT_FOUND,
ERR_ELEMENT_EXISTS, ERR_TREE_IS_FULL};

__attribute__((nonnull(1), access(read_write, 1), access(read_only, 2)))
extern enum cdsa_err avl_insert(AVL_Tree * const t, void * const key);


extern enum cdsa_err avl_insert(AVL_Tree * const t, void * const key)
{
Binary_Tree * const bt = (Binary_Tree * const)t;
if (bt->size == SIZE_MAX)
return ERR_TREE_IS_FULL;

struct Binary_Tree_Node **bn = &(bt->root);
struct Binary_Tree_Node *parent = NULL;

// Removing this traversal loop which shouldn't have any effect
removes the diagnose.
while (*bn) {
const int res = bt->comp(key, (*bn)->key);
if (!res)
return ERR_ELEMENT_EXISTS;
parent = *bn;
if (res < 0) {
bn = &(*bn)->left;
continue;
}
bn = &(*bn)->right;
}

struct AVL_Node **n = (struct AVL_Node **)bn;
*n = malloc(sizeof(**n));
if (!(*n))
return ERR_OUT_OF_MEM;

(*bn)->key = key;
(*bn)->left = NULL;
(*bn)->right = NULL;
(*bn)->parent = parent;
(*n)->balance = 0;

//balance_insert(t, *n);
++(bt->size);

return ERR_OK;
}



Here is the output:


:60:9: warning: leak of '' [CWE-401]
[-Wanalyzer-malloc-leak]
   60 | (*bn)->right = NULL;
  | ^
  'avl_insert': events 1-11
|
|   35 | if (bt->size == SIZE_MAX)
|  |^
|  ||
|  |(1) following 'false' branch...
|..
|   38 | struct Binary_Tree_Node **bn = &(bt->root);
|  | ~~
|  | |
|  | (2) ...to here
|..
|   41 | while (*bn) {
|  |~
|  ||
|  |(3) following 'true' branch...
|   42 | const int res = bt->comp(key, (*bn)->key);
|  | ~
|  | |
|  | (4) ...to here
|   43 | if (!res)
|  |~
|  ||
|  |(5) following 'false' branch (when 'res !=
0')...
|   44 | return ERR_ELEMENT_EXISTS;
|   45 | parent = *bn;
|  | ~~
|  | |
|  | (6) ...to here
|..
|   54 | *n = malloc(sizeof(**n));
|  |  ~~~
|  |  |
|  |  (7) allocated here
|   55 | if (!(*n))
|  |~
|  ||
|  |(8) assuming 'malloc(40)' is non-NULL
|  |(9) following 'false' branch...
|..
|   58 | (*bn)->key = key;
|  | ~
|  | |
|  | (10) ...to here
|   59 | (*bn)->left = NULL;
|   60 | (*bn)->right = NULL;
|  | ~
|  | |
|  | (11) '' leaks here; was allocated at (7)

[Bug modula2/108261] modula-2 module registration process seems to fail with shared libraries.

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

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

Gaius Mulley  changed:

   What|Removed |Added

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

--- Comment #28 from Gaius Mulley  ---
Closing as this original PR has now been solved.  The focus now moves onto
coroutines (RTco.cc and RTint.cc in particular) which are reported in PR108835.

[Bug target/108940] Offset of pointer to global variable not set correctly for position independent executable

[rob.meades--- via Gcc-bugs]

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

--- Comment #2 from Rob Meades  ---
Created attachment 54545
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54545=edit
Disassembly of executable file

Here is the complete disassembly of the executable output file: we do indeed
seem to be missing a .reloc section.  I guess we should be specifying a flag to
the linker to obtain this?

[Bug target/108943] ARM Unaligned memory access with high optimizer levels

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

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

Richard Earnshaw  changed:

   What|Removed |Added

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

--- Comment #1 from Richard Earnshaw  ---
There's no compiler bug here.

Cortex-M7 implements the ARMv7em version of the architecture, which supports
unaligned accesses.  If this is faulting then it's because you're trying to use
the operation on something like device memory without informing the compiler
about this.  You need to mark your pointers as volatile in this case.

The alternative is to compile with -mno-unaligned-access, but I wouldn't
recommend this as that will disable other optimizations where this might be
safe and useful.

[Bug target/108940] Offset of pointer to global variable not set correctly for position independent executable

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

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

--- Comment #1 from Andrew Pinski  ---
There should be a .reloc section in the executable which does the fix up ...

[Bug target/108910] [12/13 Regression] Further ICE in aarch64_layout_arg

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

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

--- Comment #5 from Jakub Jelinek  ---
Created attachment 54544
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54544=edit
gcc13-pr108910-lto.patch

Untested fix for the lto side of this bug.  No testcase included, as when
the target bug is fixed, the lto testcase will not fail regardless of whether
this fix is in or not.

[Bug tree-optimization/107561] [13 Regression] g++.dg/pr71488.C and [g++.dg/warn/Warray-bounds-16.C -m32] regression due to -Wstringop-overflow problem

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||jwakely.gcc at gmail dot com
   Keywords|testsuite-fail  |missed-optimization

--- Comment #11 from Richard Biener  ---
So I've missed the VR_ANTI_RANGE handling in get_size_range where we run into

  wide_int maxsize = wi::to_wide (max_object_size ());
  min = wide_int::from (min, maxsize.get_precision (), UNSIGNED);
  max = wide_int::from (max, maxsize.get_precision (), UNSIGNED);
  if (wi::eq_p (0, min - 1))
{
  /* EXP is unsigned and not in the range [1, MAX].  That means
 it's either zero or greater than MAX.  Even though 0 would
 normally be detected by -Walloc-zero, unless ALLOW_ZERO
 is set, set the range to [MAX, TYPE_MAX] so that when MAX
 is greater than the limit the whole range is diagnosed.  */
  wide_int maxsize = wi::to_wide (max_object_size ());
  if (flags & SR_ALLOW_ZERO)
{
  if (wi::leu_p (maxsize, max + 1)
  || !(flags & SR_USE_LARGEST))
min = max = wi::zero (expprec);
  else
{
  min = max + 1;
  max = wi::to_wide (TYPE_MAX_VALUE (exptype));
}
}
  else
{
  min = max + 1;
  max = wi::to_wide (TYPE_MAX_VALUE (exptype));
}

and from [0,0] [8, +INF] pick [8, +INF] based on the comments reasoning.

This all wouldn't happen if we'd be able to CSE the zero size ...

We can now try to put additional heuristic ontop of the above heuristic,
namely when the object we write to is of size zero set SR_ALLOW_ZERO.
Or try to "undo" the multiplication trick which would probably make us
end up with VARYING.

I'll note that with the earlier proposed change we regress the following,
that's an observation I make a lot of times - all "weirdness" in the code
is backed by (artificial) testcases verifying it works exactly as coded ...

FAIL: gcc.dg/Wstringop-overflow-15.c pr82608 (test for warnings, line 37)
FAIL: gcc.dg/Wstringop-overflow-15.c pr82608 (test for warnings, line 38)
FAIL: gcc.dg/Wstringop-overflow-15.c pr82608 (test for warnings, line 69)
FAIL: gcc.dg/Wstringop-overflow-15.c pr82608 (test for warnings, line 70)
FAIL: gcc.dg/Wstringop-overflow-56.c  (test for warnings, line 64)
FAIL: gcc.dg/Wstringop-overflow-56.c  (test for warnings, line 75)
FAIL: gcc.dg/Wstringop-overflow-56.c  (test for warnings, line 86)
FAIL: gcc.dg/Wstringop-overflow-56.c  (test for warnings, line 97)
FAIL: gcc.dg/Wstringop-overflow-56.c  (test for warnings, line 108)
FAIL: gcc.dg/Wstringop-overflow-56.c  (test for warnings, line 148)
FAIL: gcc.dg/Wstringop-overflow-56.c  (test for warnings, line 159)
FAIL: gcc.dg/attr-alloc_size-11.c  (test for warnings, line 52)
FAIL: gcc.dg/attr-alloc_size-11.c  (test for warnings, line 53)
FAIL: gcc.dg/attr-alloc_size-11.c  (test for warnings, line 54)
FAIL: gcc.dg/attr-alloc_size-11.c  (test for warnings, line 55)
FAIL: gcc.dg/attr-alloc_size-11.c  (test for warnings, line 56)
FAIL: gcc.dg/attr-alloc_size-11.c  (test for warnings, line 57)
FAIL: gcc.dg/attr-alloc_size-11.c  (test for warnings, line 58)
FAIL: gcc.dg/attr-alloc_size-11.c  (test for warnings, line 64)
FAIL: gcc.dg/attr-alloc_size-11.c  (test for warnings, line 65)
FAIL: gcc.dg/attr-alloc_size-3.c  (test for warnings, line 438)
FAIL: gcc.dg/attr-alloc_size-4.c  (test for warnings, line 138)
FAIL: gcc.dg/attr-alloc_size-4.c  (test for warnings, line 143)
FAIL: gcc.dg/attr-alloc_size-4.c  (test for warnings, line 187)
FAIL: gcc.dg/pr98721-1.c  (test for warnings, line 11)
FAIL: gcc.dg/pr98721-1.c  (test for warnings, line 12)

For example gcc.dg/pr98721-1.c has

int
foo (int n)
{
  if (n <= 0)
{
  char vla[n];  /* { dg-message "source object 'vla' of
size 0" } */
  return __builtin_strlen (vla);/* { dg-warning "'__builtin_strlen'
reading 1 or more bytes from a region of size 0" } */

but of course we do not diagnose

int
foo (int n)
{
  if (n < 0)
{
  char vla[n];

or when no condition is present or a n > 32 condition is present.

I fear it's not possible to "fix" this testcase without changing the
expectation on a bunch of other testcases.  But the messaging to the
user is quite unhelpful because it doesn't actually inform him about
above reasoning.

That we are not allowed to optimize the code is not of help either.

We can again work around this in libstdc++ by CSEing ->_M_size ourselves.
The following 

[Bug target/108950] New: [11/12/13 Regression] ICE: verify_gimple failed (error: conversion of register to a different size in 'view_convert_expr'; error: type mismatch in 'widen_sum_expr')

[asolokha at gmx dot com via Gcc-bugs]

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

Bug ID: 108950
   Summary: [11/12/13 Regression] ICE: verify_gimple failed
(error: conversion of register to a different size in
'view_convert_expr'; error: type mismatch in
'widen_sum_expr')
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---
Target: aarch64-linux-gnu

gcc 13.0.1 20230226 snapshot (g:e6d39f68d03c46637ca6e1bede3d28eae6278df3) ICEs
when compiling the following testcase w/ -O1:

int m;
short int n;

__attribute__ ((simd)) int
foo (void)
{
  m += n;
  m += n;
}

% aarch64-linux-gnu-gcc-13 -O1 -c t0pgrthf.c
t0pgrthf.c: In function 'foo.simdclone.0':
t0pgrthf.c:5:1: error: conversion of register to a different size in
'view_convert_expr'
5 | foo (void)
  | ^~~
VIEW_CONVERT_EXPR(n.0_1);

_21 = VIEW_CONVERT_EXPR(n.0_1);
t0pgrthf.c:5:1: error: type mismatch in 'widen_sum_expr'
vector(4) int
vector(4) int
vector(4) int
vect_patt_19.21_28 = _25 w+ vect_m_lsm.20_27;
during GIMPLE pass: vect
t0pgrthf.c:5:1: internal compiler error: verify_gimple failed
0xf7c152 verify_gimple_in_cfg(function*, bool, bool)
   
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-13.0.1_p20230226/work/gcc-13-20230226/gcc/tree-cfg.cc:5648
0xe39450 execute_function_todo
   
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-13.0.1_p20230226/work/gcc-13-20230226/gcc/passes.cc:2091
0xe3993e execute_todo
   
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-13.0.1_p20230226/work/gcc-13-20230226/gcc/passes.cc:2145

[Bug d/108877] Explicit immutable struct import internal compiler error

[belka at caraus dot de via Gcc-bugs]

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

--- Comment #2 from Eugen Wissner  ---
Not sure about class and enum, but „const struct“ results in a similar error.

[Bug tree-optimization/108949] New: Optimize shift counts

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

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

Bug ID: 108949
   Summary: Optimize shift counts
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

>From https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108941#c13 :
Because various backends support shift count truncation or have patterns that
recognize it in certain cases, I wonder if middle-end couldn't canonicalize
shift count (N + x)
where N is multiple of shift first operand's bitsize B to x & (B - 1) where the
latter
is often optimized away while the former is not.
For similar N - x it is more questionable because N - x is a single GIMPLE
statement while -y & (B - 1) are two; perhaps it could be done at expansion
time though.
In generic code at least for SHIFT_COUNT_TRUNCATED targets, otherwise maybe if
one can easily detect negation optab and subtraction instruction not accepting
immediate for the minuend.  Or handle all this in each of the backends?

int
foo (int x, int y)
{
  return x << (y & 31);
}

int
bar (int x, int y)
{
  return x << (32 + y);
}

int
baz (int x, int y)
{
  return x << (-y & 31);
}

int
qux (int x, int y)
{
  return x << (32 - y);
}

[Bug c++/108948] for function template with auto return and parameter pack

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Keywords||rejects-valid
 Ever confirmed|0   |1
   Last reconfirmed||2023-02-27

[Bug c++/108948] for function template with auto return and parameter pack

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=56190

--- Comment #1 from Jonathan Wakely  ---
It has nothing to do with the auto return (and so probably nothing to do with
64194).

Reduced:

template struct tuple { };

template auto apply(F&&, Tuple&&) { }

template  void add1(const Types...) { }

int main() {
  apply(add1, tuple());
}

[Bug c++/105200] user-defined operator <=> for enumerated types is ignored

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|SUSPENDED   |NEW

--- Comment #9 from Jakub Jelinek  ---
I think CWG2673 has been approved as DR in Issaquah 2023.

More complete testcase could be:

#include 

enum class E : int { E0 = 0, E1 = 1 };
enum class F : int { F0 = 0, F1 = 1 };

constexpr auto
operator<=> (E lhs, E rhs)
{
  return (int) rhs <=> (int) lhs;
}

static_assert ((E::E0 <=> E::E1) == std::strong_ordering::greater);

static_assert (E::E0 > E::E1);

constexpr bool
operator== (F lhs, F rhs)
{
  return (int) lhs != (int) rhs;
}

static_assert (F::F0 == F::F1);
static_assert (!(F::F0 == F::F0));
static_assert (!(F::F0 != F::F1));
static_assert (F::F0 != F::F0);

The reason we don't handle this is that joust encounters the
https://eel.is/c++draft/over.match.best#general-2.8 and
https://eel.is/c++draft/over.match.best#general-2.9 handling first:
  /* F2 is a rewritten candidate (12.4.1.2) and F1 is not, or F1 and F2 are
 rewritten candidates, and F2 is a synthesized candidate with reversed
 order of parameters and F1 is not.  */
  if (cand1->rewritten ())
{
  if (!cand2->rewritten ())
return -1;
  if (!cand1->reversed () && cand2->reversed ())
return 1;
  if (cand1->reversed () && !cand2->reversed ())
return -1;
}
  else if (cand2->rewritten ())
return 1;
before it handles the https://eel.is/c++draft/over.match.oper#3.3.4
  /* Check whether we can discard a builtin candidate, either because we
 have two identical ones or matching builtin and non-builtin candidates.

 (Pedantically in the latter case the builtin which matched the user
 function should not be added to the overload set, but we spot it here.

 [over.match.oper]
 ... the builtin candidates include ...
 - do not have the same parameter type list as any non-template
   non-member candidate.  */

  if (identifier_p (cand1->fn) || identifier_p (cand2->fn))
{
  for (i = 0; i < len; ++i)
if (!same_type_p (cand1->convs[i]->type,
  cand2->convs[i]->type))
  break;
  if (i == cand1->num_convs)
{
  if (cand1->fn == cand2->fn)
/* Two built-in candidates; arbitrarily pick one.  */
return 1;
  else if (identifier_p (cand1->fn))
/* cand1 is built-in; prefer cand2.  */
return -1;
  else
/* cand2 is built-in; prefer cand1.  */
return 1;
}
}

Now, I wonder if the https://eel.is/c++draft/over.match.oper#3.3.4 stuff
shouldn't be conceptually done somewhere else, not in joust because it is about
whether certain candidate is added to the list of built-in candidates at all. 
Or, if it is done in joust, shouldn't it be done first or very close to the
start?

[Bug c++/108948] New: for function template with auto return and parameter pack

[egpt.gcc at wolke7 dot net via Gcc-bugs]

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

Bug ID: 108948
   Summary:  for function
template with auto return and parameter pack
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: egpt.gcc at wolke7 dot net
  Target Milestone: ---

Hello,

consider the following code (with -std=c++17):
--
#include 

template 
auto add1(const Types... x) { return std::make_tuple((x+1)...); }

int main() {
  auto x = std::apply(add1, std::make_tuple(10,20));
  return 0;
}
--

Compiling with g++ 12.2.0 (Debian testing) yields the following error message:
--
add1.cpp: In function 'int main()':
add1.cpp:11:29: error: invalid initialization of non-const reference of type
'std::tuple (&)(int, int)' from an rvalue of type ''
   11 | auto x = std::apply(add1, t);
  | ^
--

Both, clang++ 14.0.6 (Debian testing) and icpx 2023.0.0 compile just fine. It
seems related to the resolved bug 64194. It works with add1 being defined
without parameter pack as follows:
--
template 
auto add1(const Type1 x, const Type2 y) { return std::make_tuple(x+1,y+1); }
--

Kind regards
Elmar

[Bug target/108947] New: [13 Regression] wrong code with -O2 -fno-forward-propagate and vector compare on riscv64

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 108947
   Summary: [13 Regression] wrong code with -O2
-fno-forward-propagate and vector compare on riscv64
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: riscv64-unknown-linux-gnu

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

Output:
$ riscv64-unknown-linux-gnu-gcc -O2 -fno-forward-propagate testcase.c -static
$ qemu-riscv64 -- ./a.out 
Aborted

w == { 0, 0 } instead of { 0x, 0 }

$ riscv64-unknown-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-riscv64/bin/riscv64-unknown-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r13-6353-20230227090511-g529e03b9882-checking-yes-rtl-df-extra-riscv64/bin/../libexec/gcc/riscv64-unknown-linux-gnu/13.0.1/lto-wrapper
Target: riscv64-unknown-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--with-cloog --with-ppl --with-isl --with-isa-spec=2.2
--with-sysroot=/usr/riscv64-unknown-linux-gnu --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=riscv64-unknown-linux-gnu
--with-ld=/usr/bin/riscv64-unknown-linux-gnu-ld
--with-as=/usr/bin/riscv64-unknown-linux-gnu-as --disable-multilib
--disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r13-6353-20230227090511-g529e03b9882-checking-yes-rtl-df-extra-riscv64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.0.1 20230227 (experimental) (GCC)

[Bug d/108946] New: [13.0] d: Identity comparison of vectors not supported

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

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

Bug ID: 108946
   Summary: [13.0] d: Identity comparison of vectors not supported
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: ibuclaw at gcc dot gnu.org
  Target Milestone: ---

The operation `bool r = vector1 is vector2;` should be allowed by the D
front-end codegen, and have a boolean result.

[Bug d/108945] New: [13.0] d: vector float comparison doesn't result in 0 or -1

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

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

Bug ID: 108945
   Summary: [13.0] d: vector float comparison doesn't result in 0
or -1
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: ibuclaw at gcc dot gnu.org
  Target Milestone: ---

This is because we're using VEC_COND_EXPR using a float vector in both the true
and false branches, this then reinterprets `-1.0f' as an integer.

Only affects mainline, as vector comparison is a new addition to the D
implementation.

[Bug c/108941] Error: operand type mismatch for `shr' with binutils master

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

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

--- Comment #13 from Jakub Jelinek  ---
We could file an x86 backend enhancement request based on those comments,
int
foo (int x, int y)
{
  return x << (y & 31);
}

int
bar (int x, int y)
{
  return x << (32 + y);
}

int
baz (int x, int y)
{
  return x << (-y & 31);
}

int
qux (int x, int y)
{
  return x << (32 - y);
}
where we optimize away the & 31 masks, but actually not the additions of 32. 
It actually doesn't change anything on the number of instructions in this case,
but bar needs 1 more bytes than equivalent foo and qux even 3 more bytes than
equivalent baz.

[Bug modula2/108944] New: libgm2/libm2pim/sckt.cc:254:3: warning: memset() called to fill 0 bytes. [memsetZeroBytes]

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 108944
   Summary: libgm2/libm2pim/sckt.cc:254:3: warning: memset()
called to fill 0 bytes. [memsetZeroBytes]
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: modula2
  Assignee: gaius at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

Source code is

  memset (, sizeof (struct sockaddr_in), 0);

Parameters wrong way around. Maybe better code:

  memset (, 0, sizeof (struct sockaddr_in));

Thanks to static analyser cppcheck for finding this problem.

[Bug tree-optimization/107561] [13 Regression] g++.dg/pr71488.C and [g++.dg/warn/Warray-bounds-16.C -m32] regression due to -Wstringop-overflow problem

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

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

--- Comment #10 from Richard Biener  ---
(In reply to Richard Biener from comment #9)
> Note I think there's still a bug in value_range (irange) here. 
> get_size_range
> does
> 
>   if (integral)
> {
>   value_range vr;
> 
>   query->range_of_expr (vr, exp, stmt);
> 
>   if (vr.undefined_p ())
> vr.set_varying (TREE_TYPE (exp));
>   range_type = vr.kind ();
>   min = wi::to_wide (vr.min ());
>   max = wi::to_wide (vr.max ());
> 
> and we have vr:
> 
> (gdb) p vr
> $13 = { = { = {
>   _vptr.vrange = 0x3693a30 +16>, 
>   m_kind = VR_ANTI_RANGE, m_discriminator = VR_IRANGE}, 
> m_num_ranges = 1 '\001', m_max_ranges = 1 '\001', 
> m_nonzero_mask = , m_base = 0x7fffc8f0}, m_ranges = {
> , }}
> (gdb) p vr.dump (stderr)
> [irange] unsigned int [0, 0][8, +INF]$17 = void
> 
> but vr.min () produces 1 and vr.max () produces 7, just as if it doesn't
> interpret VR_ANTI_RANGE transparently here (if that's the intent?!).
> At least
> 
> // Return the highest bound of a range expressed as a tree.
> 
> inline tree
> irange::tree_upper_bound () const
> 
> suggests that.  Note that vr.num_pairs () produces 2 (because constant_p ())
> but vr.m_num_ranges is 1 and tree_upper_bound uses m_num_ranges.
> 
> I suppose irange::{min,max,tree_lower_bound,tree_upper_bound} miss "support"
> for legacy_mode_p here.

OTOH gimple-array-bounds.cc does

  const value_range *vr = NULL;
  if (TREE_CODE (low_sub_org) == SSA_NAME)
{
  vr = get_value_range (low_sub_org, stmt);
  if (!vr->undefined_p () && !vr->varying_p ())
{
  low_sub = vr->kind () == VR_RANGE ? vr->max () : vr->min ();
  up_sub = vr->kind () == VR_RANGE ? vr->min () : vr->max ();
}

so the bug is a documentation bug on min/max/lower/upper bound?!

I'm policeing other uses of value_range right now.