[Bug c++/115511] ICE on ambigous overload for _Float32

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

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

--- Comment #3 from Andrew Pinski  ---
(In reply to dv from comment #2)
> 
> It looks like my report is a duplicate of 111343.

That was the one which I was thinking of too :). I will clean up the recording
of this tomorrow. one for the C++ ICE and one maybe for the libstdc++.

[Bug tree-optimization/115508] [14/15 regression] ICE when building flac with -O2 -march=znver1 since r14-5603-g2b59e2b4dff421

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

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

Richard Biener  changed:

   What|Removed |Added

Version|unknown |14.1.1
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Status|NEW |ASSIGNED

--- Comment #13 from Richard Biener  ---
I will have a look.

[Bug rtl-optimization/115506] Possible but missed "cmp" instruction merging (x86 & ARM, optimization)

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

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

Richard Biener  changed:

   What|Removed |Added

  Component|middle-end  |rtl-optimization

--- Comment #1 from Richard Biener  ---
On GIMPLE this cannot be realized since we do not represent condition codes so
this is ideally dealt with on RTL.

[Bug c++/115504] [14/15 Regression] Wrong decltype result for a captured reference inside lambda

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |14.2

[Bug c/115502] [15 regression] ICE when building Valgrind with -std=c23 (comptypes_same_p, at c/c-typeck.cc:1227) since r15-934-gd2cfe8a73b3c41

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

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

Richard Biener  changed:

   What|Removed |Added

Version|unknown |15.0
   Target Milestone|--- |15.0

[Bug target/115458] [15 regression] [RISC-V] ICE in lra_split_hard_reg_for, at lra-assigns.cc:1868 unable to find a register to spill since r15-518-g99b1daae18c095

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

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code

--- Comment #4 from Richard Biener  ---
The bisected rev only exposes this.

[Bug target/114189] Target implements obsolete vcond{,u,eq} expanders

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

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

--- Comment #4 from Richard Biener  ---
aarch64 reports just

FAIL: gcc.target/aarch64/if-compare_2.c check-function-bodies bar1
FAIL: gcc.target/aarch64/if-compare_2.c check-function-bodies bar2

[Bug target/114189] Target implements obsolete vcond{,u,eq} expanders

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

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

--- Comment #3 from Richard Biener  ---
arm is OK -
https://ci.linaro.org/job/tcwg_gcc_check--master-arm-precommit/7755/artifact/artifacts/artifacts.precommit/notify/mail-body.txt
loongarch is also reportedly OK

[Bug c++/115511] ICE on ambigous overload for _Float32

[dv at vollmann dot ch via Gcc-bugs]

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

--- Comment #2 from dv at vollmann dot ch ---
On 6/16/24 16:18, pinskia at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115511
> 
> Andrew Pinski  changed:
> 
> What|Removed |Added
> 
> Last reconfirmed||2024-06-16
>   Status|UNCONFIRMED |NEW
>   Ever confirmed|0   |1
> 
> --- Comment #1 from Andrew Pinski  ---
> Confirmed. I thought I had saw this before but I can't seem to find the bug
> report.

I searched again, and found this one:


It looks like my report is a duplicate of 111343.

   Detlef

[Bug tree-optimization/115494] [14/15 Regression] wrong code at -O{2,3} on x86_64-linux-gnu since r14-3485

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

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

Richard Biener  changed:

   What|Removed |Added

Version|unknown |14.1.1
 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org

--- Comment #7 from Richard Biener  ---
I will have a look.  Note PRE expression simplification should _only_ work
based on avails by design.

[Bug target/115493] gcc.c-torture/execute/pr94734.c fails on MVE after r15-1054-g202a9c8fe7d

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

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

Richard Biener  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2024-06-17
 Ever confirmed|0   |1

--- Comment #4 from Richard Biener  ---
I will have a look.  Working with the reduced.

__attribute__((noipa)) int
baz (int n, int x, unsigned long z)
{
  int arr[16], s = 0;
  arr[12] = 42;
  for (int i = 0; i < n; i++)
{
  if (x == (i & 0x25))
arr[7] = i;
}
  return arr[z];
}

int
main ()
{
  if (baz (25, 0x25, 12) != 42)
__builtin_abort ();
  return 0;
}

When trying to reproduce for me linking fails with

/usr/bin/arm-suse-linux-gnueabi-ld: error: /tmp/cc4cHDSc.o: conflicting
architecture profiles M/A
/usr/bin/arm-suse-linux-gnueabi-ld: failed to merge target specific data of
file /tmp/cc4cHDSc.o
/usr/bin/arm-suse-linux-gnueabi-ld: error:
/home/rguenther/obj-arm-g/gcc/crtend.o: conflicting CPU architectures 21/4
/usr/bin/arm-suse-linux-gnueabi-ld: failed to merge target specific data of
file /home/rguenther/obj-arm-g/gcc/crtend.o

I configure with --target=arm-suse-linux-gnueabi --with-float=hard and have a
armv7-linux sysroot.

I'm trying to work based on cc1 and your attachments.

[Bug tree-optimization/115492] [15 Regression] wrong code at -O2/O3 since r15-204-g7c469a9fc78550

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #5 from Richard Biener  ---
I will have a look.

[Bug c/115515] New: constexpr ICE

[muecker at gwdg dot de via Gcc-bugs]

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

Bug ID: 115515
   Summary: constexpr ICE
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: muecker at gwdg dot de
  Target Milestone: ---

Here is an ICE with constexpr.

https://godbolt.org/z/8EdTW84n4


const struct { float x; } i = { 3.1 };
constexpr int j = i.x;

[Bug middle-end/47081] Macro usage too clever for localization

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

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

Eric Gallager  changed:

   What|Removed |Added

 CC||jsm28 at gcc dot gnu.org,
   ||pinskia at gcc dot gnu.org

--- Comment #6 from Eric Gallager  ---
(In reply to Göran Uddeborg from comment #5)
> These messages are no longer included in the po files. I'm not sure exactly
> what prevents it; gengtype-state.cc is still not in po/EXCLUDES (while plain
> gengtype.cc is). In any case, I would say we can close this report. Does
> anyone want it kept open for any reason?

I have no objection to closing it, but let's check with Andrew or Joseph
first...

[Bug target/115500] RISC-V: Performance regression on 1bit test

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

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

--- Comment #6 from Jeffrey A. Law  ---
That's going to be a uarch issue if the slli/bltz is slower.

[Bug c/115513] attribute nonstring could help with printf mistakes

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

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

Xi Ruoyao  changed:

   What|Removed |Added

   Last reconfirmed||2024-06-17
   Severity|normal  |enhancement
 Status|UNCONFIRMED |NEW
   Keywords||diagnostic
 Ever confirmed|0   |1
 CC||xry111 at gcc dot gnu.org

--- Comment #1 from Xi Ruoyao  ---
Confirmed.

But what should we do with something like `printf("%32s", pd->name);`?

[Bug tree-optimization/115450] [15 Regression] cpu2017 502.gcc runtime miscompute on aarch64 with SVE since r15-1006-gd93353e6423eca

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

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

--- Comment #2 from kugan at gcc dot gnu.org ---
(In reply to Andrew Pinski from comment #1)
> >[r15-1006-gd93353e6423eca] Do single-lane SLP discovery for reductions
> 
> 
> Interesting because PR 115256 bisect it to an earlier patch.
I believe this is a new issue.

[Bug target/115500] RISC-V: Performance regression on 1bit test

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

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

--- Comment #5 from YunQiang Su  ---
(In reply to Jeffrey A. Law from comment #4)
> On the gcc-13, gcc-14 and the trunk I get this with -O2 on rv64gc:
> 
> sllia5,a0,44
> blt a5,zero,.L3
> 
> 
> So ISTM that we must be doing something different.  YunQiang, please make
> sure to include the optimization options used when reporting a bug.
> 

Thanks. I used -O2, and yes, slli/bltz is slower than srli/andi/bnez.

[Bug target/115408] regression between gcc 13.3.0 and 14.1.0 using -mips16 and -minterlink-mips16

[broly at mac dot com via Gcc-bugs]

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

--- Comment #8 from gagan sidhu (broly)  ---
how did you respond so fast? i don't see you on the CC list. that's kind of
cool but eerie. that's usually MY modus operandi, lol

[Bug target/115408] regression between gcc 13.3.0 and 14.1.0 using -mips16 and -minterlink-mips16

[broly at mac dot com via Gcc-bugs]

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

gagan sidhu (broly)  changed:

   What|Removed |Added

Summary|regression between gcc  |regression between gcc
   |13.3.0 and 14.1.0 using |13.3.0 and 14.1.0 using
   |-mips16 and |-mips16 and
   |-minterlink-mips16 with |-minterlink-mips16
   |openssl |

--- Comment #7 from gagan sidhu (broly)  ---
there is no secret sauce, as i said i gave the compiler command below. it's
just your typical CLFS stuff.

you should have no problem reproducing this if you use -mips16
-minterlink-mips16 with a glibc-2.3x toolchain and a multilib
mips64el-none-linux-gnu target.

[Bug target/115408] regression between gcc 13.3.0 and 14.1.0 using -mips16 and -minterlink-mips16 with openssl

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

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

--- Comment #6 from Sam James  ---
If it's "kinda urgent", please provide the full info we need, including "secret
sauce".

[Bug target/115408] regression between gcc 13.3.0 and 14.1.0 using -mips16 and -minterlink-mips16 with openssl

[broly at mac dot com via Gcc-bugs]

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

--- Comment #5 from gagan sidhu (broly)  ---
hi andrew,

i tried compiling another program that wasn't openssl and a similar issue
arose. something is seriously wrong in 14.1.0 in terms of -mips16 and
-minterlink-mips16 mode

this is kinda urgent now:


/Volumes/xtoolshit/hdr3/le/cross/bin/../lib/gcc/mips64el-none-linux-gnu/14.1.0/../../../../mips64el-none-linux-gnu/bin/ld:
/tmp/ccPV2gsV.lto.o: in function `do_upgrade_post':
/Volumes/xtoolshit/misc/dd-wrt/src/router/httpd/modules/upgrade.c:402:(.text.do_upgrade_post+0x498):
warning: the use of `mktemp' is dangerous, better use `mkstemp' or `mkdtemp'
/Volumes/xtoolshit/hdr3/le/cross/bin/../lib/gcc/mips64el-none-linux-gnu/14.1.0/../../../../mips64el-none-linux-gnu/bin/ld:
/Volumes/xtoolshit/hdr3/le/cross/bin/../lib/gcc/mips64el-none-linux-gnu/14.1.0/../../../../mips64el-none-linux-gnu/bin/ld:
DWARF error: could not find abbrev number 85
/tmp/ccPV2gsV.lto.o: in function `ej_get_currate':
:(.text.ej_get_currate+0x84): undefined reference to
`__mips16_call_stub_df_0'
/Volumes/xtoolshit/hdr3/le/cross/bin/../lib/gcc/mips64el-none-linux-gnu/14.1.0/../../../../mips64el-none-linux-gnu/bin/ld:
:(.text.ej_get_currate+0x96): undefined reference to
`__mips16_gtdf2'


something to do with the stubs is screwed up, it seems.

[Bug target/114442] ICE: in riscv_sched_variable_issue, at config/riscv/riscv.cc:8421 with -O2 -mtune=xiangshan-nanhu

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2024-06-16
 Ever confirmed|0   |1
 CC||law at gcc dot gnu.org

--- Comment #1 from Jeffrey A. Law  ---
Yes, the xiangshan-nanhu scheduler model needs some serious work.  The generic
RISC-V code will trigger an ICE if there's an insn in the stream that does not
map to a functional unit in the uarch's scheduler description.

I've asked the submitter of the xiangshan-nanhu port to fix this, but haven't
heard from them since immediately after the request.  Given the lack of
response we should probably seriously consider disabling its scheduler
description until such time as it's been updated.

[Bug tree-optimization/115387] [15 regression] ICE in iovsprintf.c since r15-1081-ge14afbe2d1c

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

--- Comment #13 from Jeffrey A. Law  ---
Fixed on the trunk.

[Bug tree-optimization/115404] [15 Regression] possibly wrong code on glibc-2.39 since r15-1113-gde05e44b2ad963

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

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

Bug 115387 Summary: [15 regression] ICE in iovsprintf.c since 
r15-1081-ge14afbe2d1c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115387

   What|Removed |Added

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

[Bug target/113362] RISCV64 divide and remainder with the same operands generates two divide operations

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at gcc dot gnu.org

--- Comment #3 from Jeffrey A. Law  ---
This is a failure to use the divmod pattern because the public riscv uarchs
haven't set that flag.  I added support for that style of code generation
perhaps a year or so ago, but I don't know the public uarchs well enough to
know if they should be using divmod or not.  I suspect most if not all should,
the only viable case for not using divmod would be if they have fusion for this
kind of idiom.

But all the proper support is in place.  And with Ventana's internal tree with
our uarch enabled:

divua5,a1,a2
mul a2,a5,a2
sd  a5,0(a0)
sub a1,a1,a2
sd  a1,8(a0)


So what really needs to happen here is folks that know the various upstreamed
uarchs need to chime in and set the bit appropriately for their uarchs.

[Bug middle-end/47081] Macro usage too clever for localization

[goeran at uddeborg dot se via Gcc-bugs]

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

--- Comment #5 from Göran Uddeborg  ---
These messages are no longer included in the po files. I'm not sure exactly
what prevents it; gengtype-state.cc is still not in po/EXCLUDES (while plain
gengtype.cc is). In any case, I would say we can close this report. Does anyone
want it kept open for any reason?

[Bug target/115500] RISC-V: Performance regression on 1bit test

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

  Known to work||14.1.1
  Known to fail||13.1.1
 Status|UNCONFIRMED |WAITING
 CC||law at gcc dot gnu.org
 Ever confirmed|0   |1
   Last reconfirmed||2024-06-16

--- Comment #4 from Jeffrey A. Law  ---
On the gcc-13, gcc-14 and the trunk I get this with -O2 on rv64gc:

sllia5,a0,44
blt a5,zero,.L3


So ISTM that we must be doing something different.  YunQiang, please make sure
to include the optimization options used when reporting a bug.

WRT Andrew's question.  Sadly the most interesting box available in the wild
for builds and such is that milk-v pioneer system.  Which sadly doesn't have
the B extension.  The 64 cores are what make that milk-v pioneer interesting
:-0

[Bug other/63426] [meta-bug] Issues found with -fsanitize=undefined

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

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

Bug 100211 Summary: [11/12/13/14/15 Regression] aarch64: OOB accesses in 
aarch64_{save,restore}_callee_saves
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100211

   What|Removed |Added

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

[Bug target/100211] [11/12/13/14/15 Regression] aarch64: OOB accesses in aarch64_{save,restore}_callee_saves

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |FIXED
   Target Milestone|11.5|15.0
 Status|ASSIGNED|RESOLVED

--- Comment #7 from Andrew Pinski  ---
Fixed on the trunk.
Note this has not caused any wrong because there is some padding between
reg_is_wrapped_separately and the next field (call_via) due to 83 not being a
multiple of alignof(rtx) (which is either 4 or 8 depending on pointer size).

  bool reg_is_wrapped_separately[LAST_SAVED_REGNUM + 1];
  /* One entry for each general purpose register.  */
  rtx call_via[SP_REGNUM];

So we can close this without needing to backporting it.

[Bug target/100211] [11/12/13/14/15 Regression] aarch64: OOB accesses in aarch64_{save,restore}_callee_saves

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

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

--- Comment #6 from GCC Commits  ---
The trunk branch has been updated by Andrew Pinski :

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

commit r15-1359-g33caee556c130b2dcf311480314e942a43d6b368
Author: Andrew Pinski 
Date:   Sun Jun 16 10:53:15 2024 -0700

aarch64: Fix reg_is_wrapped_separately array size [PR100211]

Currrently the size of the array reg_is_wrapped_separately is
LAST_SAVED_REGNUM.
But LAST_SAVED_REGNUM could be regno that is being saved. So the size needs
to be `LAST_SAVED_REGNUM + 1` like aarch64_frame->reg_offset is.

Committed as obvious after a bootstrap/test for aarch64-linux-gnu.

gcc/ChangeLog:

PR target/100211
* config/aarch64/aarch64.h (machine_function): Fix the size
of reg_is_wrapped_separately.

Signed-off-by: Andrew Pinski 

[Bug rtl-optimization/114996] [15 Regression] [RISC-V] 2->2 combination no longer occurring

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

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

--- Comment #5 from Segher Boessenkool  ---
(My name is Segher)

I implemented unCSE.  It does exactly this.  It will still be a few days before
you will see it, sorry!

[Bug libstdc++/115514] New: Nonconforming reverse_iterator::operator->

[frankhb1989 at gmail dot com via Gcc-bugs]

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

Bug ID: 115514
   Summary: Nonconforming reverse_iterator::operator->
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: frankhb1989 at gmail dot com
  Target Milestone: ---

The last comment in LWG 1052 says "the wording in [reverse.iter.elem] (of
P0896R4) for operator-> is equivalent to the PR for LWG 1052"; unfortunately
this is not true. The adopted wording in P0896R4 uses `prev` which returns a
prvalue for the call to `operator->`, while the PR uses an lvalue `tmp` for the
call to `operator->`. Since `->` is no longer concerned in C++20's iterator
requirements, there can be observable differences when the iterator having
overloaded `operator->` with different ref-qualifiers in spite of the
equivalence to the expression formed by `operator*` (for lvalues).

The implementation in libc++ follows the standard wording literally. Actually
the original implementation (https://reviews.llvm.org/D120180) has an explicit
`std::move`, suggesting the difference has been acknowledged. (Another
difference is it only applies the resolution for C++17 onward.)

[Bug rtl-optimization/114996] [15 Regression] [RISC-V] 2->2 combination no longer occurring

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

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

--- Comment #4 from Jeffrey A. Law  ---
Seger, please give some suggestions.  At least for the riscv case, I don't see
a path forward.

[Bug objc/50909] Process "#pragma options align=reset" correctly on Mac OS X

[vital.had at gmail dot com via Gcc-bugs]

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

Sergey Fedorov  changed:

   What|Removed |Added

 CC||vital.had at gmail dot com

--- Comment #17 from Sergey Fedorov  ---
(In reply to Rudolf from comment #12)
> This is still an issue... 7 YEARS LEATER!?
> I am using gcc 8.1.0. please fix this.

This is still an issue with gcc 13.

[Bug rtl-optimization/114996] [15 Regression] [RISC-V] 2->2 combination no longer occurring

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

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

--- Comment #3 from Segher Boessenkool  ---
That makes no sense.  combine only ever results in 0, 1, or 2 insns, never 3.

What you mean is that after 4 or more combinations you got what you wanter. 
But
combine (like most RTL optimisations!) is a totally local optimisation, it only
looks at a single step at a time.

It should never have done stap #1 that it did before.  It contradicts the
principles of what combine does.

The good news is that there are good ways to get the same effect (and much
more).
But restoring the previous behaviour is completely wrong.  There are more
things
in the instruction combiner that aren't so very lineair, but this takes the
cake.

[Bug c/115513] New: attribute nonstring could help with printf mistakes

[peter at eisentraut dot org via Gcc-bugs]

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

Bug ID: 115513
   Summary: attribute nonstring could help with printf mistakes
   Product: gcc
   Version: 14.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: peter at eisentraut dot org
  Target Milestone: ---

Created attachment 58446
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58446=edit
test file

Consider this test program (also attached):

```
#include 
#include 

struct Data
{
char name[32] __attribute__((nonstring));
};

int f (struct Data *pd, const char *s)
{
strncpy(pd->name, s, sizeof pd->name);

printf("%s", pd->name);  // unsafe, no warning!?!

return strlen(pd->name);   // unsafe, gets a warning
}
```

Compile with, e.g.: gcc-14 -c -Wall -Wextra -O2 test.c

As per the documentation, this will warn about the strlen() call.

But it doesn't warn about the printf() call.  This would be quite useful and
seems to be a gap in the warning coverage of this attribute.

[Bug libstdc++/115512] New: _Float32 overloads in cmath cause ICE for default AVR

[dv at vollmann dot ch via Gcc-bugs]

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

Bug ID: 115512
   Summary: _Float32 overloads in cmath cause ICE for default AVR
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dv at vollmann dot ch
  Target Milestone: ---
Target: avr

As reported in , g++
produces an ICE for calling functions with _Float32 for which both float and
double overloads exist.
I got it for __hypot3, but there are probably several others.
I'm wondering if cmath should provide overloads for _Float32 at all if double
is 32 bits.

The problem can be reproduced with a single line source:

#include 

avr-g++ -std=gnu++23 -o cmath-only.o -c cmath-only.cc

[Bug c++/115511] ICE on ambigous overload for _Float32

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2024-06-16
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
Confirmed. I thought I had saw this before but I can't seem to find the bug
report.

[Bug c++/115511] New: ICE on ambigous overload for _Float32

[dv at vollmann dot ch via Gcc-bugs]

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

Bug ID: 115511
   Summary: ICE on ambigous overload for _Float32
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dv at vollmann dot ch
  Target Milestone: ---
Target: avr

Created attachment 58445
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58445=edit
Output from -freport-bug

On AVR for the default model float and double both are 32 bit.
When calling with a _Float32, I get an internal compiler error with this
program:

void f1(float x);
void f1(double x);

void f2(_Float32 x)
{
f1(x);
}

I don't know the rules for _Float32 (this is an extremly stripped version of
the cmath header), but the program is probably ill-formed.
But still an error message would be nicer than an ICE ;-)

I used the AVR target, but this may be a problem on other targets where float
and double are the same size.

[Bug c++/115510] New: ICE : Segmentation fault in build_new_method_call and finish_call_expr

[iamanonymous.cs at gmail dot com via Gcc-bugs]

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

Bug ID: 115510
   Summary: ICE : Segmentation fault  in build_new_method_call
and finish_call_expr
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: iamanonymous.cs at gmail dot com
  Target Milestone: ---
Target: x86_64

***
The compiler produces an internal error during build_new_method_call  and
finish_call_expr when compiling the provided code with the specified options. 
The issue can also be reproduced on Compiler Explorer.

***
OS and Platform:
# uname -a
Linux ubuntu 4.15.0-213-generic #224-Ubuntu SMP Mon Jun 19 13:30:12 UTC 2023
x86_64 x86_64 x86_64 GNU/Linux
***
# g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/root/gdbtest/gcc/gcc-15/libexec/gcc/x86_64-pc-linux-gnu/15.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /root/gdbtest/gcc/obj/../gcc/configure
--prefix=/root/gdbtest/gcc/gcc-15 --enable-languages=c,c++,fortran,go
--disable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 15.0.0 20240509 (experimental) (GCC) 
***
Program:
# cat main.ii

class a {b(({
a  = ;
class {d(){
  c.b()


***
Command Lines:
# g++ main.ii -std=c++2a -Wall -Wextra -pedantic -fsanitize=address,undefined
-fno-omit-frame-pointer -g -O2 -Wshadow -Wnon-virtual-dtor -Wold-style-cast
-Wcast-align -Wunused -Woverloaded-virtual -Wpedantic -Wconversion
-Wsign-conversion -Wmisleading-indentation -Wduplicated-cond
-Wduplicated-branches -Wlogical-op -Wnull-dereference -Wuseless-cast
-Wdouble-promotion -Wformat=2 -c -o main.o
main.ii:1:20: error: expected identifier before ‘(’ token
1 | class a {b(({
  |^
main.ii:1:21: error: expected ‘)’ before ‘{’ token
1 | class a {b(({
  |~^
  | )
main.ii:1:21: error: expected ‘)’ before ‘{’ token
1 | class a {b(({
  |   ~ ^
  | )
main.ii:1:18: error: ISO C++ forbids declaration of ‘b’ with no type
[-fpermissive]
1 | class a {b(({
  |  ^
main.ii:5:9: error: expected ‘;’ after class definition
5 | 
  | ^
  | ;
main.ii: In member function ‘int a::b(...)’:
main.ii:2:12: error: expected primary-expression before ‘;’ token
2 | a  = ;
  |^
main.ii:3:24: error: ISO C++ forbids declaration of ‘d’ with no type
[-fpermissive]
3 | class {d(){
  |^
main.ii:5:7: error: expected ‘;’ after class definition
5 | 
  |   ^
  |   ;
main.ii: In member function ‘int a::b(...)d()’:
main.ii:4:10: error: use of local variable with automatic storage from
containing function
4 |   c.b()
  |   ~~~^~
main.ii:2:8: note: ‘a& c’ declared here
2 | a  = ;
  |^
main.ii:4:10: internal compiler error: Segmentation fault
4 |   c.b()
  |   ~~~^~
0x13a93af crash_signal
/root/gdbtest/gcc/obj/../gcc/gcc/toplev.cc:319
0xaaac6b build_this_conversion
/root/gdbtest/gcc/obj/../gcc/gcc/cp/call.cc:2386
0xaab84d add_function_candidate
/root/gdbtest/gcc/obj/../gcc/gcc/cp/call.cc:2564
0xaad031 add_candidates
/root/gdbtest/gcc/obj/../gcc/gcc/cp/call.cc:6724
0xab75c8 add_candidates
/root/gdbtest/gcc/obj/../gcc/gcc/cp/call.cc:6536
0xab75c8 build_new_method_call(tree_node*, tree_node*, vec**, tree_node*, int, tree_node**, int)
/root/gdbtest/gcc/obj/../gcc/gcc/cp/call.cc:11723
0xd0b682 finish_call_expr(tree_node*, vec**, bool,
bool, int)
/root/gdbtest/gcc/obj/../gcc/gcc/cp/semantics.cc:2989
0xc69c1f cp_parser_postfix_expression
/root/gdbtest/gcc/obj/../gcc/gcc/cp/parser.cc:8178
0xc44eeb cp_parser_binary_expression
/root/gdbtest/gcc/obj/../gcc/gcc/cp/parser.cc:10398
0xc45c54 cp_parser_assignment_expression
/root/gdbtest/gcc/obj/../gcc/gcc/cp/parser.cc:10742
0xc461f4 cp_parser_expression
/root/gdbtest/gcc/obj/../gcc/gcc/cp/parser.cc:10909
0xc4c927 cp_parser_expression_statement
/root/gdbtest/gcc/obj/../gcc/gcc/cp/parser.cc:13175
0xc8515b cp_parser_statement
/root/gdbtest/gcc/obj/../gcc/gcc/cp/parser.cc:12952
0xc59807 cp_parser_statement_seq_opt
/root/gdbtest/gcc/obj/../gcc/gcc/cp/parser.cc:13427
0xc59a2f 

[Bug c++/114961] [modules] using imported member functions in constexpr context causes ICE

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

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

Nathaniel Shead  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
 CC||nshead at gcc dot gnu.org
   Last reconfirmed||2024-06-16
 Ever confirmed|0   |1

--- Comment #2 from Nathaniel Shead  ---
Thanks for the report! Unfortunately this doesn't provide enough information
for me to reproduce the error. Would you be able to provide a self-contained
set of files that I can try?

Please also see https://gcc.gnu.org/bugs/ for further tips. Thanks!

[Bug c++/103524] [meta-bug] modules issue

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

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

Bug 115446 Summary: [15 Regression] [modules] Segfault when exporting operator 
new
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115446

   What|Removed |Added

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

[Bug c++/115446] [15 Regression] [modules] Segfault when exporting operator new

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

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

Nathaniel Shead  changed:

   What|Removed |Added

 CC||nshead at gcc dot gnu.org
 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Nathaniel Shead  ---
This looks to be fixed by r15-1224-g074c1fc7974359.

[Bug tree-optimization/108230] [12 regression] assert() spuriously activates maybe-uninitialized warning

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

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

Sam James  changed:

   What|Removed |Added

Summary|assert() spuriously |[12 regression] assert()
   |activates   |spuriously activates
   |maybe-uninitialized warning |maybe-uninitialized warning

--- Comment #7 from Sam James  ---
10/11 are fine too, as is 13+

[Bug tree-optimization/115508] [14/15 regression] ICE when building flac with -O2 -march=znver1 since r14-5603-g2b59e2b4dff421

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

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

Sam James  changed:

   What|Removed |Added

 CC||liuhongt at gcc dot gnu.org
Summary|[14/15 regression] ICE when |[14/15 regression] ICE when
   |building flac with -O2  |building flac with -O2
   |-march=znver1   |-march=znver1 since
   ||r14-5603-g2b59e2b4dff421

--- Comment #12 from Sam James  ---
It bisects to r14-5603-g2b59e2b4dff421 but someone more knowledgable than me
will have to say whether there's a deeper issue (e.g. missing validation or
whatever) in SLP.

[Bug target/114528] (0xFFFFFFFF0001FFFFULL - 0x00123000) constant forming could be done in 2 instructions

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

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

Xi Ruoyao  changed:

   What|Removed |Added

 CC||xry111 at gcc dot gnu.org

--- Comment #3 from Xi Ruoyao  ---
Note that on some uarch the naive implementation may have 1 cycle latency while
the "clever" implementation has 2 due to fusion.  Maybe we need a tune
parameter.

[Bug c/115509] New: ICE: in set_underlying_type, at c-family/c-common.cc:8613 with attribute aligned and sentinel

[iamanonymous.cs at gmail dot com via Gcc-bugs]

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

Bug ID: 115509
   Summary: ICE: in set_underlying_type, at
c-family/c-common.cc:8613 with attribute aligned and
sentinel
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: iamanonymous.cs at gmail dot com
  Target Milestone: ---

Compiler Explorer: https://godbolt.org/z/da8Txxbs9

***
OS and Platform:
$ uname -a:
Linux ubuntu 4.15.0-213-generic #224-Ubuntu SMP Mon Jun 19 13:30:12 UTC 2023
x86_64 x86_64 x86_64 GNU/Linux
***
gcc version:
Using built-in specs.
COLLECT_GCC=/root/gcc_set/trunk-48a320a/bin/gcc
COLLECT_LTO_WRAPPER=/root/gcc_set/trunk-48a320a/libexec/gcc/x86_64-pc-linux-gnu/15.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --prefix=/root/gcc_set/trunk-48a320a
--with-gmp=/root/build_essential --with-mpfr=/root/build_essential
--with-mpc=/root/build_essential --enable-languages=c,c++ --disable-multilib
--with-sanitizer=address,undefined,thread,leak --enable-coverage
--disable-bootstrap
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 15.0.0 20240426 (experimental) (GCC) 

***
Program:
$ cat mutant.c
__attribute__((aligned, sentinel)) typedef (*a)();

***
Command Lines:
$ gcc mutant.c
mutant.c:1:46: error: type defaults to ‘int’ in declaration of ‘a’
[-Wimplicit-int]
1 | __attribute__((aligned, sentinel)) typedef (*a)();
  |  ^
mutant.c:1:1: warning: ‘sentinel’ attribute requires prototypes with named
arguments [-Wattributes]
1 | __attribute__((aligned, sentinel)) typedef (*a)();
  | ^
mutant.c:1:1: internal compiler error: in set_underlying_type, at
c-family/c-common.cc:8613
0xf793db set_underlying_type(tree_node*)
../../gcc/gcc/c-family/c-common.cc:8613
0xd50e3f pushdecl(tree_node*)
../../gcc/gcc/c/c-decl.cc:3524
0xd5ad62 start_decl(c_declarator*, c_declspecs*, bool, tree_node*, bool,
unsigned int*)
../../gcc/gcc/c/c-decl.cc:5705
0xe3fd91 c_parser_declaration_or_fndef
../../gcc/gcc/c/c-parser.cc:2766
0xe3c6ed c_parser_external_declaration
../../gcc/gcc/c/c-parser.cc:2046
0xe3bbd7 c_parser_translation_unit
../../gcc/gcc/c/c-parser.cc:1900
0xeccd02 c_parse_file()
../../gcc/gcc/c/c-parser.cc:26889
0xfe8faa c_common_parse_file()
../../gcc/gcc/c-family/c-opts.cc:1311
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.