[Bug lto/109428] GCC did not fix CVE-2022-37434, a heap overflow bug introduced by its dependency zlib code.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109428 --- Comment #5 from chluo at cse dot cuhk.edu.hk --- OK, also thanks for the kind explanations!
[Bug lto/109428] GCC did not fix CVE-2022-37434, a heap overflow bug introduced by its dependency zlib code.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109428 --- Comment #4 from Andrew Pinski --- (In reply to chluo from comment #2) > Thank you for your quick update! The commit might just list one approach to > exploit the bug in **inflate()** function. I am not sure if there are other > ways to reach there but the buggy code is definitely a hazard. > Anyway, it is good to align with the patched version of upstream code zlib. > It would not take effort since the patch is very easy to apply and verify. Also the only way hit the bug is if state->head is non-null. the only place which sets state->head to non-null is in inflateGetHeader since state is an opaque object outside of zlib even. So if someone modifies the state from outside of zlib, then there might be other issues. Anyways GCC does not modify state either nor calls inflateGetHeader so it would not hit this bug.
[Bug c/85696] OpenMP with variably modified and default(none) won't compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85696 zhonghao at pku dot org.cn changed: What|Removed |Added CC||zhonghao at pku dot org.cn --- Comment #11 from zhonghao at pku dot org.cn --- Is this bug really fixed? I tried the latest version, but it is still rejected: :1:28: error: use of parameter outside function body before ']' token 1 | void foo(int n, int a[][n]) |^ : In function 'void foo(...)': :4:9: error: 'a' was not declared in this scope 4 | a[23][0] = 42; | ^ Compiler returned: 1
[Bug other/105404] new version of zlib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105404 --- Comment #11 from Andrew Pinski --- *** Bug 109428 has been marked as a duplicate of this bug. ***
[Bug lto/109428] GCC did not fix CVE-2022-37434, a heap overflow bug introduced by its dependency zlib code.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109428 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #3 from Andrew Pinski --- Still a dup of bug 105404 because we have not updated the sources yet for either CVEs. *** This bug has been marked as a duplicate of bug 105404 ***
[Bug lto/109428] GCC did not fix CVE-2022-37434, a heap overflow bug introduced by its dependency zlib code.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109428 chluo at cse dot cuhk.edu.hk changed: What|Removed |Added Resolution|DUPLICATE |--- Status|RESOLVED|UNCONFIRMED --- Comment #2 from chluo at cse dot cuhk.edu.hk --- Thank you for your quick update! The commit might just list one approach to exploit the bug in **inflate()** function. I am not sure if there are other ways to reach there but the buggy code is definitely a hazard. Anyway, it is good to align with the patched version of upstream code zlib. It would not take effort since the patch is very easy to apply and verify.
[Bug other/105404] new version of zlib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105404 --- Comment #10 from Andrew Pinski --- Note GCC does not call inflateGetHeader so it is not affected by CVE-2022-37434.
[Bug lto/109428] GCC did not fix CVE-2022-37434, a heap overflow bug introduced by its dependency zlib code.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109428 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Andrew Pinski --- Dup. *** This bug has been marked as a duplicate of bug 105404 ***
[Bug other/105404] new version of zlib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105404 Andrew Pinski changed: What|Removed |Added CC||chluo at cse dot cuhk.edu.hk --- Comment #9 from Andrew Pinski --- *** Bug 109428 has been marked as a duplicate of this bug. ***
[Bug c/109426] Gcc runs into Infinite loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109426 Xi Ruoyao changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||xry111 at gcc dot gnu.org Resolution|--- |INVALID --- Comment #3 from Xi Ruoyao --- (In reply to Andrew Pinski from comment #2) > There is no infinite loop and the code finally completes. > > You are causing an warnings of over 2x warning messages with the macros. > This will be slow. Looks like it's slow not only because of the warnings. The preprocessed code is 1.6M and it's slow even with -w (62.76s with 12.2.0). > > I don't run into an infinite loop at all on the trunk. Anyway this is INVALID. You cannot assume any compiler able to compile such a compiler bomb efficiently.
[Bug lto/109428] New: GCC did not fix CVE-2022-37434, a heap overflow bug introduced by its dependency zlib code.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109428 Bug ID: 109428 Summary: GCC did not fix CVE-2022-37434, a heap overflow bug introduced by its dependency zlib code. Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: chluo at cse dot cuhk.edu.hk CC: marxin at gcc dot gnu.org Target Milestone: --- GCC reused zlib 1.2.11. A heap overflow vulnerability (https://github.com/madler/zlib/issues/723) was recently found in zlib through version 1.2.12 and was patched in the latest version of zlib in https://github.com/madler/zlib/commit/eff308af425b67093bab25f80f1ae950166bece1. The patch basically inserted an additional check at the if condition and does not influence any functionalities. We found that in the current version of GCC (0f816116356fec32e3a3a2fb5af790a0438c5da4), the simple patch has still not been propagated yet. Since the vulnerability in zlib also impacts GCC and it is publically known for a while, we believe GCC should apply the patch ASAP.
[Bug tree-optimization/109427] param=vect-induction-float= has a typo for IntegerRange
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109427 Andrew Pinski changed: What|Removed |Added Status|ASSIGNED|RESOLVED Target Milestone|--- |12.3 Resolution|--- |FIXED --- Comment #4 from Andrew Pinski --- Fixed.
[Bug tree-optimization/109427] param=vect-induction-float= has a typo for IntegerRange
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109427 --- Comment #3 from CVS Commits --- The releases/gcc-12 branch has been updated by Andrew Pinski : https://gcc.gnu.org/g:6c5d6ed689d24418a3bc0647ab34a7ab017d7030 commit r12-9388-g6c5d6ed689d24418a3bc0647ab34a7ab017d7030 Author: Andrew Pinski Date: Wed Apr 5 21:13:00 2023 -0700 Fix typo in -param=vect-induction-float= attributes There was a typo in the attributes of the option -param=vect-induction-float= for IntegerRange. This fixes that typo. Committed to GCC 12 branch as obvious after a build/test. gcc/ChangeLog: PR tree-optimization/109427 * params.opt (-param=vect-induction-float=): Fix option attribute typo for IntegerRange. (cherry picked from commit 0f816116356fec32e3a3a2fb5af790a0438c5da4)
[Bug tree-optimization/109427] param=vect-induction-float= has a typo for IntegerRange
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109427 --- Comment #2 from CVS Commits --- The trunk branch has been updated by Andrew Pinski : https://gcc.gnu.org/g:0f816116356fec32e3a3a2fb5af790a0438c5da4 commit r13-7022-g0f816116356fec32e3a3a2fb5af790a0438c5da4 Author: Andrew Pinski Date: Wed Apr 5 21:13:00 2023 -0700 Fix typo in -param=vect-induction-float= attributes There was a typo in the attributes of the option -param=vect-induction-float= for IntegerRange. This fixes that typo. Committed as obvious after a build/test. gcc/ChangeLog: PR tree-optimization/109427 * params.opt (-param=vect-induction-float=): Fix option attribute typo for IntegerRange.
[Bug tree-optimization/109427] param=vect-induction-float= has a typo for IntegerRange
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109427 Andrew Pinski changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org Ever confirmed|0 |1 Last reconfirmed||2023-04-06 Summary|Wrong param description in |param=vect-induction-float= |params.opt |has a typo for IntegerRange Status|UNCONFIRMED |ASSIGNED --- Comment #1 from Andrew Pinski --- Oh there is a small typo. Let me fix it. I looked into the awk files before and yes they don't detect invalid attributes.
[Bug fortran/109358] Wrong formatting with T-descriptor during stream output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109358 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #3 from kargl at gcc dot gnu.org --- (In reply to Jerry DeLisle from comment #2) > I am using my copy of the F2018 standard. > > "13.8.1.2 The Tn edit descriptor indicates that the transmission of the next > character to or from a record is to occur at the nth character position of > the record, relative to the left tab limit. This position can be in either > direction from the current position." > > Currently we do this: > > 1234567890123 > 1234 0123 > 1234 0123 > > We should do this: > > 1234567890123 > 1234 0123 > 1234 0123 > > "13.5 (3) During formatted stream output, processing of an A edit descriptor > can cause file positioning to occur (13.7.4)." > > I am not finding anything that says file positioning is not allowed. The > above is just elaborating different ways that an A edit descriptor affects > the positioning. Positioning is always done no matter what with the T > specifier. > > Regardless, I do need to fix this. Yes, there is a bug. The A edit descriptor and whether or not it does file positioning is not relevant. The relevant words from F2018 are 13.8.1.2 T, TL, and TR editing The left tab limit affects file positioning by the T and TL edit descriptors. Immediately prior to nonchild data transfer (12.6.4.8.3), the left tab limit becomes defined as the character position of the current record or the current position of the stream file. If, during data transfer, the file is positioned to another record, the left tab limit becomes defined as character position one of that record. with write(fd, "(a)") "1234567890123" write(fd, "(a, t10, a)") "1234", "0123" ! A-descriptor, file positioning the left tab limit for the 2nd write is established before data transfer to position 1. The 'T10' edit descriptor is relative to that position. The write of "1234" in the 2nd write might place the character position to 5, but it does not update the left tab limit because the write() is not positioned to a new record.
[Bug tree-optimization/109427] New: Wrong param description in param.opt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109427 Bug ID: 109427 Summary: Wrong param description in param.opt Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: fxue at os dot amperecomputing.com Target Milestone: --- -param=vect-induction-float= Common Joined UInteger Var(param_vect_induction_float) Init(1) IntegerRage(0, 1) Param Optimization ^^^
[Bug target/109384] [13 Regression] unquoted keyword 'float' in format [-Werror=format-diag]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109384 --- Comment #8 from jiawei --- Thank you for this fix, I neglected to confirm the format, sorry for that.
[Bug fortran/109358] Wrong formatting with T-descriptor during stream output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109358 Jerry DeLisle changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2023-04-06 --- Comment #2 from Jerry DeLisle --- I am using my copy of the F2018 standard. "13.8.1.2 The Tn edit descriptor indicates that the transmission of the next character to or from a record is to occur at the nth character position of the record, relative to the left tab limit. This position can be in either direction from the current position." Currently we do this: 1234567890123 1234 0123 1234 0123 We should do this: 1234567890123 1234 0123 1234 0123 "13.5 (3) During formatted stream output, processing of an A edit descriptor can cause file positioning to occur (13.7.4)." I am not finding anything that says file positioning is not allowed. The above is just elaborating different ways that an A edit descriptor affects the positioning. Positioning is always done no matter what with the T specifier. Regardless, I do need to fix this.
[Bug testsuite/108899] [13 Regression] ERROR: can't rename to "saved-unsupported": command already exists on i386
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108899
--- Comment #10 from CVS Commits ---
The master branch has been updated by Alexandre Oliva :
https://gcc.gnu.org/g:673a2a6445a79bcce5ba433d6bbec4b99a1bc7c6
commit r13-7021-g673a2a6445a79bcce5ba433d6bbec4b99a1bc7c6
Author: Alexandre Oliva
Date: Wed Apr 5 11:27:28 2023 -0300
testsuite: fix proc unsupported overriding in modules.exp [PR108899]
The overrider of proc unsupported in modules.exp had two problems
reported by Thomas Schwinge, even after Jakub Jelínek's fix:
- it remained in effect while running other dejagnu testsets
- it didn't quote correctly the argument list passed to it, which
caused test names to be surrounded by curly braces, as in:
UNSUPPORTED: {...}
This patch fixes both issues, obsoleting and reverting Jakub's change,
by dropping the overrider and renaming the saved proc back, and by
using uplevel's argument list splicing.
Co-authored-by: Thomas Schwinge
for gcc/testsuite/ChangeLog
PR testsuite/108899
* g++.dg/modules/modules.exp (unsupported): Drop renaming.
Fix quoting.
[Bug c/109426] Gcc runs into Infinite loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109426 Andrew Pinski changed: What|Removed |Added Component|c++ |c --- Comment #2 from Andrew Pinski --- There is no infinite loop and the code finally completes. You are causing an warnings of over 2x warning messages with the macros. This will be slow. I don't run into an infinite loop at all on the trunk.
[Bug c++/109426] Gcc runs into Infinite loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109426 Andrew Pinski changed: What|Removed |Added Summary|Gcc runs into Infinite |Gcc runs into Infinite loop |loop, when resolving| |templates | --- Comment #1 from Andrew Pinski --- The code example you provided does not have any templates ...
[Bug c++/109426] New: Gcc runs into Infinite loop, when resolving templates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109426
Bug ID: 109426
Summary: Gcc runs into Infinite loop, when resolving templates
Product: gcc
Version: 12.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: zhonghao at pku dot org.cn
Target Milestone: ---
The code is as follows:
typedef struct astruct_d
{
void *data;
} astruct;
/* Generate a whole bunch of unique fake mallocs, this
keeps the vartrack dump simpler to understand (all
the "size" arguments have a unique name). */
#define DE0(X) \
void *malloc##X (unsigned long size##X);
#define DE1(X) \
DE0(X##0) DE0(X##1) DE0(X##2) DE0(X##3) DE0(X##4) \
DE0(X##5) DE0(X##6) DE0(X##7) DE0(X##8) DE0(X##9)
#define DE2(X) \
DE1(X##0) DE1(X##1) DE1(X##2) DE1(X##3) DE1(X##4) \
DE1(X##5) DE1(X##6) DE1(X##7) DE1(X##8) DE1(X##9)
#define DE3(X) \
DE2(X##0) DE2(X##1) DE2(X##2) DE2(X##3) DE2(X##4) \
DE2(X##5) DE2(X##6) DE2(X##7) DE2(X##8) DE2(X##9)
#define DE4(X) \
DE3(X##0) DE3(X##1) DE3(X##2) DE3(X##3) DE3(X##4) \
DE3(X##5) DE3(X##6) DE3(X##7) DE3(X##8) DE3(X##9)
DE4(0)
#undef DE0
#undef DE1
#undef DE2
#undef DE3
#undef DE4
void foo (void)
{
/* Now call all those mallocs and generate a series of
variables while at it. */
#define DE0(X) \
astruct *A##X = (astruct *) malloc##X(sizeof (astruct));
#define DE1(X) \
DE0(X##0) DE0(X##1) DE0(X##2) DE0(X##3) DE0(X##4) \
DE0(X##5) DE0(X##6) DE0(X##7) DE0(X##8) DE0(X##9)
#define DE2(X) \
DE1(X##0) DE1(X##1) DE1(X##2) DE1(X##3) DE1(X##4) \
DE1(X##5) DE1(X##6) DE1(X##7) DE1(X##8) DE1(X##9)
#define DE3(X) \
DE2(X##0) DE2(X##1) DE2(X##2) DE2(X##3) DE2(X##4) \
DE2(X##5) DE2(X##6) DE2(X##7) DE2(X##8) DE2(X##9)
#define DE4(X) \
DE3(X##0) DE3(X##1) DE3(X##2) DE3(X##3) DE3(X##4) \
DE3(X##5) DE3(X##6) DE3(X##7) DE3(X##8) DE3(X##9)
DE4(0)
DE4(1)
}
GCC runs into an infinite loop:
code0.c:35:18: warning: cast to pointer from integer of different size
[-Wint-to-pointer-cast]
35 | astruct *A##X = (astruct *) malloc##X(sizeof (astruct));
| ^
code0.c:37:32: note: in expansion of macro ‘DE0’
37 | DE0(X##0) DE0(X##1) DE0(X##2) DE0(X##3) DE0(X##4) \
|^~~
code0.c:41:42: note: in expansion of macro ‘DE1’
41 | DE1(X##5) DE1(X##6) DE1(X##7) DE1(X##8) DE1(X##9)
| ^~~
code0.c:44:2: note: in expansion of macro ‘DE2’
44 | DE2(X##5) DE2(X##6) DE2(X##7) DE2(X##8) DE2(X##9)
| ^~~
code0.c:46:22: note: in expansion of macro ‘DE3’
46 | DE3(X##0) DE3(X##1) DE3(X##2) DE3(X##3) DE3(X##4) \
| ^~~
code0.c:49:1: note: in expansion of macro ‘DE4’
49 | DE4(1)
| ^~~
[Bug c++/109425] mismatched argument pack lengths while expanding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109425 --- Comment #2 from Hannes Hauswedell --- Thanks for the quick reply, and nice that it is already fixed for 13! I assume this will not be backported? It wouldn't be a huge problem, because it is possible to workaround with non-friend operators.
[Bug target/70243] PowerPC V4SFmode should not use Altivec instructions on VSX systems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70243 --- Comment #5 from Michael Meissner --- Created attachment 54814 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54814=edit Test case This is test case that shows the generation of fmaddfp and fnmsubfp.
[Bug target/109399] RISC-V: RVV VSETVL PASS backward demand fusiton bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109399 JuzheZhong changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from JuzheZhong --- fixed
[Bug target/70243] PowerPC V4SFmode should not use Altivec instructions on VSX systems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70243 --- Comment #4 from Chip Kerchner --- It shows up as a rounding difference on BE machines.
[Bug target/70243] PowerPC V4SFmode should not use Altivec instructions on VSX systems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70243 Chip Kerchner changed: What|Removed |Added CC||chip.kerchner at ibm dot com --- Comment #3 from Chip Kerchner --- This is showing up in some of the binaries generated by Eigen (with GCC13).
[Bug modula2/109423] cc1gm2 ICE if an INCL or EXCL is performced on an unknown set
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109423 Gaius Mulley changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #3 from Gaius Mulley --- Closing now the patch has been applied.
[Bug modula2/109423] cc1gm2 ICE if an INCL or EXCL is performced on an unknown set
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109423 Gaius Mulley changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2023-04-05 Status|UNCONFIRMED |ASSIGNED --- Comment #2 from Gaius Mulley --- The bugfix was a format specifier in M2Quads.mod:BuildInclProcedure and BuildExclProcedure. The patch above include these fixes and also removes unused variables.
[Bug modula2/109423] cc1gm2 ICE if an INCL or EXCL is performced on an unknown set
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109423 --- Comment #1 from CVS Commits --- The master branch has been updated by Gaius Mulley : https://gcc.gnu.org/g:1bd13193fab77a19da323974aec876f0fc1817ee commit r13-7019-g1bd13193fab77a19da323974aec876f0fc1817ee Author: Gaius Mulley Date: Wed Apr 5 23:07:46 2023 +0100 PR modula2/109423 cc1gm2 ICE if an INCL or EXCL is performed on an unknown set This patch fixes an ICE if attempting to INCL or EXCL on an unknown set. The fix was to correct an error format string. Also included in the patch are patches to remove unused variables. The patch also marks a variable as written in BuildAdr. gcc/m2/ChangeLog: PR modula2/109423 * gm2-compiler/M2Base.def (Unbounded): Remove. * gm2-compiler/M2Error.def (ErrorAbort0): Add noreturn attribute. * gm2-compiler/M2Quads.mod (BuildInclProcedure): Correct error format string. (BuildExceptProcedure): Correct error format string. (BuildAdrFunction): Call PutWriteQuad when taking the address of a variable. * gm2-libs-ch/SysExceptions.c (_M2_SysExceptions_init): Add parameters. * gm2-libs-ch/wrapc.c (_M2_wrapc_init): Add parameters. * gm2-libs/DynamicStrings.mod (DumpStringInfo): Remove t. (PopAllocationExemption): Remove f. * gm2-libs/FIO.mod (BufferedWrite): Remove result. * gm2-libs/FormatStrings.mod (Copy): Remove endpos and afterperc. (HandlePercent): Remove result. * gm2-libs/Indexing.mod (RemoveIndiceFromIndex): Remove k. * gm2-libs/M2Dependent.mod (CreateModule): Remove p0 and p1. (DumpModuleData): Remove mptr. (ConstructModules): Remove nulp. * gm2-libs/RTExceptions.mod (PopHandler): Remove i. * gm2-libs/RTint.mod (Listen): Remove b4s, b4m, afs and afm. * gm2-libs/SFIO.mod (ReadS): Remove c. * gm2-libs/StringConvert.mod (doDecimalPlaces): Remove whole and fraction. gcc/testsuite/ChangeLog: * gm2/pim/fail/setunknown.mod: New test. PR modula2/109423 * gm2/pim/fail/setunknown2.mod: New test. Signed-off-by: Gaius Mulley
[Bug fortran/104312] ICE with -ff2c in fold_convert_loc, at fold-const.cc:2451
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104312 anlauf at gcc dot gnu.org changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW CC||anlauf at gcc dot gnu.org Last reconfirmed||2023-04-05 --- Comment #1 from anlauf at gcc dot gnu.org --- Confirmed. The issue may be clearer if the testcase is extended as follows: function f() real, pointer :: f, e real, target :: a(2) f => a(1) return entry e() e => a(2) end so that one gets (before the traceback): pr104312-zz.f90:5:8: 5 | return |1 Error: pointer value used where a floating-point was expected pr104312-zz.f90:8:3: 8 | end | 1 Error: pointer value used where a floating-point was expected pr104312-zz.f90:1:0: 1 | function f() | internal compiler error: in fold_convert_loc, at fold-const.cc:2504 Setting a breakpoint in gfc_generate_return and checking the fndecl, one sees that it is wrong for -ff2c.
[Bug c++/107853] [10/11/12 Regression] variadic template with a variadic template friend with a requires of fold expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107853 Marek Polacek changed: What|Removed |Added CC||h2+bugs at fsfe dot org --- Comment #8 from Marek Polacek --- *** Bug 109425 has been marked as a duplicate of this bug. ***
[Bug c++/109425] mismatched argument pack lengths while expanding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109425 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE CC||mpolacek at gcc dot gnu.org --- Comment #1 from Marek Polacek --- Seems to have been fixed by r13-4876-gbd1fc4a219d8c0 commit bd1fc4a219d8c0fad0ec41002e895b49e384c1c2 Author: Patrick Palka Date: Fri Dec 23 09:18:37 2022 -0500 c++: template friend with variadic constraints [PR107853] so it is related to bug 107853. In fact I think we can say it's a dup. *** This bug has been marked as a duplicate of bug 107853 ***
[Bug tree-optimization/109417] [13 Regression] ICE on valid code at -O3 on x86_64-linux-gnu: Segmentation fault since r13-6945
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109417 --- Comment #2 from Andrew Macleod --- (In reply to Jakub Jelinek from comment #1) > Started with r13-6945-g429a7a88438cc80e I've run into this before. _54 = _22 is processed, and we cache _22 as a dependency fo _54. then we do some propagation and rewrite this statement as _54 = 3 When we look at _54 later, it still shows the cached dependency as _22, but there is no longer a _22 in the IL. We are trapping because may_recompute_p is expecting the dependency to be up to date. The fix is to check if it is in the FREE_LIST or not as well. Patch in testing. diff --git a/gcc/gimple-range-gori.cc b/gcc/gimple-range-gori.cc index 5f4313b27dd..2a575c006fc 100644 --- a/gcc/gimple-range-gori.cc +++ b/gcc/gimple-range-gori.cc @@ -1314,7 +1314,7 @@ gori_compute::may_recompute_p (tree name, basic_block bb, int depth) tree dep2 = depend2 (name); // If the first dependency is not set, there is no recomputation. - if (!dep1) + if (!dep1 || SSA_NAME_IN_FREE_LIST (dep1)) return false;
[Bug c++/109425] New: mismatched argument pack lengths while expanding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109425
Bug ID: 109425
Summary: mismatched argument pack lengths while expanding
Product: gcc
Version: 12.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: h2+bugs at fsfe dot org
Target Milestone: ---
The following snippet is rejected by GCC10, GCC11 and GCC12:
```cpp
#include
template
concept weakly_eq_comparable = requires (T1 t1, T2 t2) { { t1 == t2 } ->
std::convertible_to; };
template
struct my_tuple
{
template
requires ((sizeof...(Ts) == sizeof...(T2s)) && (weakly_eq_comparable && ...))
friend bool operator==(my_tuple const & lhs, my_tuple const & rhs)
{
return true;
}
};
int main()
{
my_tuple m1;
}
```
See also:
https://godbolt.org/z/3eEjT589o
The error is:
```
: In instantiation of 'struct my_tuple':
:20:26: required from here
:11:86: error: mismatched argument pack lengths while expanding
'weakly_eq_comparable'
11 | requires ((sizeof...(Ts) == sizeof...(T2s)) &&
(weakly_eq_comparable && ...))
|
~~^~~~
Compiler returned: 1
```
Clang>=13 accepts this code.
I am not sure if this is related to #107853, because I am not getting an ICE,
but it seems like the problems (or their solutions) could be related.
Thank you!
[Bug tree-optimization/109424] ~((x > y) ? x : y) produces two not instructions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109424 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=96694 Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Last reconfirmed||2023-04-05 --- Comment #2 from Andrew Pinski --- I noticed this while looking into PR 96694 .
[Bug tree-optimization/109424] ~((x > y) ? x : y) produces two not instructions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109424 Andrew Pinski changed: What|Removed |Added Summary|~ |~((x > y) ? x : y) produces ||two not instructions --- Comment #1 from Andrew Pinski --- > You would assume GCC produce the same code for both, but nope, the first f is > worse. Sorry f1 is worse.
[Bug tree-optimization/109424] New: ~
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109424
Bug ID: 109424
Summary: ~
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P3
Component: tree-optimization
Assignee: pinskia at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Target Milestone: ---
Take:
```
int f(int x, int y)
{
int t = ((x > y) ? x : y);
return ~t;
}
int f1(int x, int y)
{
return ~((x > y) ? x : y);
}
```
You would assume GCC produce the same code for both, but nope, the first f is
worse.
The reason why is GCC decides to move the ~ into the ?: operator making the
code worse.
fold does this "optimization" but nothing undones it, phi-opt undones it for
casts in some but not all cases.
[Bug tree-optimization/101024] Missed min expression at phiopt1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101024 --- Comment #6 from Andrew Pinski --- Part of this is in the patch set in bug 25290 comment # 27 patch set. Mostly the "c ? min/max : min/max" part, I still need to implement the "c ? min : d" part.
[Bug tree-optimization/25290] PHI-OPT could be rewritten so that is uses match
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25290 Andrew Pinski changed: What|Removed |Added Attachment #40185|0 |1 is obsolete|| --- Comment #27 from Andrew Pinski --- Created attachment 54813 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54813=edit Set of patches for moving part of the minmax_replacement to match This is my current set of patches for moving minmax_replacement to match.
[Bug target/103100] [11/12/13 Regression] unaligned access generated with memset or {} and -O2 -mstrict-align
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103100 Andrew Pinski changed: What|Removed |Added URL|https://gcc.gnu.org/piperma | |il/gcc-patches/2023-Februar | |y/611684.html | Assignee|pinskia at gcc dot gnu.org |unassigned at gcc dot gnu.org Status|ASSIGNED|NEW --- Comment #22 from Andrew Pinski --- I am no longer working on this.
[Bug target/108947] [13 Regression] wrong code with -O2 -fno-forward-propagate and vector compare on riscv64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108947 Sam James changed: What|Removed |Added CC||sjames at gcc dot gnu.org --- Comment #3 from Sam James --- Note that's substantial discussion (including a patch) in dupe PR109040.
[Bug libstdc++/88508] std::bad_cast in std::basic_ostringstream.oss.fill()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88508
Frank Heckenbach changed:
What|Removed |Added
CC||f.heckenb...@fh-soft.de
--- Comment #2 from Frank Heckenbach ---
According to
https://stackoverflow.com/questions/57406448/canot-read-char8-t-from-basic-stringstreamchar8-t
this seems to be the same issue, so I'm not filing a new bug, just adding a
comment.
Apparently this is no GCC bug, but according to the standard. IMHO this shows
how ridiculous the current UTF-8 support is. A common I/O manipulator (setw)
fails with an inscrutable error (bad cast, what cast?) which is even suppressed
by default, unless enabled with o.exceptions, so by the default the stream just
mysteriously stops working. And all that because the library doesn't know what
the space character is in UTF-8. Just ranting, I know, but it's silly.
% cat test.cpp
#include
#include
#include
int main ()
{
std::basic_ostringstream o;
o.exceptions (std::ifstream::badbit);
o << std::setw (1) << u8"";
}
% g++ -std=c++20 -Wall -Wextra -o test test.cpp
% ./test
terminate called after throwing an instance of 'std::bad_cast'
what(): std::bad_cast
Aborted
[Bug modula2/109423] New: cc1gm2 ICE if an INCL or EXCL is performced on an unknown set
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109423 Bug ID: 109423 Summary: cc1gm2 ICE if an INCL or EXCL is performced on an unknown set Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: modula2 Assignee: gaius at gcc dot gnu.org Reporter: gaius at gcc dot gnu.org Target Milestone: --- cc1gm2 ICE if an INCL or EXCL is performced on an unknown set. For example: MODULE setunknown2 ; BEGIN INCL (unknownSet, unknownVariable) END setunknown2.
[Bug tree-optimization/109417] [13 Regression] ICE on valid code at -O3 on x86_64-linux-gnu: Segmentation fault since r13-6945
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109417 Jakub Jelinek changed: What|Removed |Added Target Milestone|--- |13.0 Priority|P3 |P1 Summary|[13 Regression] ICE on |[13 Regression] ICE on |valid code at -O3 on|valid code at -O3 on |x86_64-linux-gnu: |x86_64-linux-gnu: |Segmentation fault |Segmentation fault since ||r13-6945 CC||aldyh at gcc dot gnu.org, ||amacleod at redhat dot com, ||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- Started with r13-6945-g429a7a88438cc80e
[Bug c++/109422] wrong depth used for template parameter mangling for lambdas in function signatures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109422 --- Comment #1 from Richard Smith --- > This should instead be mangled as T_TL__ Sorry, that's wrong; the rule we ended up with would mangle this as T_TL0__.
[Bug c++/109422] New: wrong depth used for template parameter mangling for lambdas in function signatures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109422
Bug ID: 109422
Summary: wrong depth used for template parameter mangling for
lambdas in function signatures
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: richard-gccbugzilla at metafoo dot co.uk
Target Milestone: ---
Testcase:
struct C {
template
void f(decltype([](T, auto) { return 0; })) {}
};
void g() { C().f({}); }
GCC mangles f as _ZN1C1fIiEEvDTtlNS_UlT_T_E_EEE -- note that this is
mangling / numbering the lambda directly within C, which is not permitted by
http://itanium-cxx-abi.github.io/cxx-abi/abi.html#closure-types but seems like
the best choice (see https://github.com/itanium-cxx-abi/cxx-abi/issues/165).
But the mangling of the as T_T_ is definitely wrong -- two
different template parameters should not be mangled the same. This should
instead be mangled as T_TL__ under
https://github.com/itanium-cxx-abi/cxx-abi/issues/31#issuecomment-528122117
[Bug c++/109421] Compilation takes a long time for struct that contains a large default-initialized array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109421 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #2 from Andrew Pinski --- Dup of bug 92385. *** This bug has been marked as a duplicate of bug 92385 ***
[Bug c++/92385] extremely long and memory intensive compilation for brace construction of array member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92385 Andrew Pinski changed: What|Removed |Added CC||ejakobs at boerboeltrading dot com --- Comment #18 from Andrew Pinski --- *** Bug 109421 has been marked as a duplicate of this bug. ***
[Bug c++/109421] Compilation takes a long time for struct that contains a large default-initialized array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109421 --- Comment #1 from Andrew Pinski --- Looks to be fixed with GCC 12.1.0 .
[Bug c++/109421] New: Compilation takes a long time for struct that contains a large default-initialized array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109421
Bug ID: 109421
Summary: Compilation takes a long time for struct that contains
a large default-initialized array
Product: gcc
Version: 11.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ejakobs at boerboeltrading dot com
Target Milestone: ---
This is similar to #59659, but is still a problem in GCC 11.2.1 and GCC 10.2.1.
The following code takes a very long time to compile with -O3 enabled:
#include
#ifndef SIZE
#define SIZE 10
#endif
struct S
{
int a;
};
struct T
{
std::vector arr[SIZE]{}; // remove the default-initializer {} to compile
fast
};
int main(int argc, char** argv)
{
T t;
for (int i=0; i
[Bug libstdc++/98678] 30_threads/future/members/poll.cc execution test FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98678 John David Anglin changed: What|Removed |Added CC||danglin at gcc dot gnu.org --- Comment #6 from John David Anglin --- Fails consistently with timeout on hppa-unknown-linux-gnu. Increasing timeout doesn't help. dave@mx3210:~/gnu/gcc/objdir/hppa-linux-gnu/libstdc++-v3/testsuite$ time ./poll.exe wait_for(0s): 1098ns for 169420 calls, avg 59.0255ns per call wait_until(system_clock minimum): 4394ns for 169420 calls, avg 236.102ns per call wait_until(steady_clock minimum): 5492ns for 169420 calls, avg 295.127ns per call wait_until(system_clock epoch): 1695216533549ns for 169420 calls, avg 1.0006e+07ns per call wait_until(steady_clock epoch: 1694205876189ns for 169420 calls, avg 1e+07ns per call wait_for when ready: 0ns for 169420 calls, avg 0ns per call /home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/30_threads/future/members/poll.cc:129: int main(): Assertion 'wait_for_0 < (ready * 30)' failed. Aborted (core dumped) real56m29.632s user0m5.355s sys 0m8.722s
[Bug middle-end/108892] [13 Regression] unable to generate reloads for at -Og on riscv64 since r13-4907
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108892 Jeffrey A. Law changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Jeffrey A. Law --- Fixed on the trunk. Currently no plans to backport as this hasn't been seen on any release branches.
[Bug middle-end/108892] [13 Regression] unable to generate reloads for at -Og on riscv64 since r13-4907
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108892
--- Comment #6 from CVS Commits ---
The master branch has been updated by Jeff Law :
https://gcc.gnu.org/g:4a45f5d6a9b53f7f5446dee47e25b07d413bb7eb
commit r13-7013-g4a45f5d6a9b53f7f5446dee47e25b07d413bb7eb
Author: Jeff Law
Date: Wed Apr 5 09:16:29 2023 -0600
[RFA][Bug target/108892 ][13 regression] Force re-recognition after
changing RTL structure of an insn
So as mentioned in the PR the underlying issue here is combine changes the
form of an existing insn, but fails to force re-recognition. As a result other
parts of the compiler blow up.
> /* Temporarily replace the set's source with the
> contents of the REG_EQUAL note. The insn will
> be deleted or recognized by try_combine. */
> rtx orig_src = SET_SRC (set); rtx
orig_dest = SET_DEST (set); if (GET_CODE (SET_DEST (set)) ==
ZERO_EXTRACT)
> SET_DEST (set) = XEXP (SET_DEST (set), 0);
> SET_SRC (set) = note;
> i2mod = temp;
> i2mod_old_rhs = copy_rtx (orig_src);
> i2mod_new_rhs = copy_rtx (note);
> next = try_combine (insn, i2mod, NULL, NULL,
> _direct_jump_p,
last_combined_insn);
> i2mod = NULL;
> if (next)
> {
> statistics_counter_event (cfun, "insn-with-note
combine", 1);
> goto retry;
> } SET_SRC (set) = orig_src;
> SET_DEST (set) = orig_dest;
This code replaces the SET_SRC of an insn in the RTL stream with the
contents of a REG_EQUAL note. So given an insn like this:
> (insn 122 117 127 2 (set (reg:DI 157 [ _46 ])
> (ior:DI (reg:DI 200)
> (reg:DI 251))) "j.c":14:5 -1
> (expr_list:REG_EQUAL (const_int 25769803782 [0x60006])
> (nil)))
It replaces the (ior ...) with a (const_int ...). The resulting insn is
passed to try_combine which will try to recognize it, then use it in a
combination attempt. Recognition succeeds with the special
define_insn_and_split pattern in the risc-v backend resulting in:
> (insn 122 117 127 2 (set (reg:DI 157 [ _46 ])
> (const_int 25769803782 [0x60006])) "j.c":14:5 177
{*mvconst_internal}
> (expr_list:REG_EQUAL (const_int 25769803782 [0x60006])
> (nil)))
This is as-expected. Now assume we were unable to combine anything, so
try_combine returns NULL_RTX. The quoted code above restores SET_SRC (and
SET_DEST) resulting in:
> (insn 122 117 127 2 (set (reg:DI 157 [ _46 ])
> (ior:DI (reg:DI 200)
> (reg:DI 251))) "j.c":14:5 177 {*mvconst_internal}
> (expr_list:REG_EQUAL (const_int 25769803782 [0x60006])
> (nil)))
But this doesn't get re-recognized and we ICE later in LRA.
The fix is trivial, reset the INSN_CODE to force re-recognition in the case
where try_combine fails.
PR target/108892
gcc/
* combine.cc (combine_instructions): Force re-recognition when
after restoring the body of an insn to its original form.
gcc/testsuite/
* gcc.c-torture/compile/pr108892.c: New test.
[Bug target/109374] FAIL: gnat.dg/div_zero.adb execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109374 --- Comment #12 from dave.anglin at bell dot net --- On 2023-04-05 10:56 a.m., ebotcazou at gcc dot gnu.org wrote: > Nice work! Your comments were accurate and very helpful. Thanks, dave
[Bug target/109374] FAIL: gnat.dg/div_zero.adb execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109374 --- Comment #11 from Eric Botcazou --- Nice work!
[Bug target/109374] FAIL: gnat.dg/div_zero.adb execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109374 John David Anglin changed: What|Removed |Added Resolution|--- |FIXED Status|WAITING |RESOLVED --- Comment #10 from John David Anglin --- Fixed on trunk.
[Bug target/109374] FAIL: gnat.dg/div_zero.adb execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109374 --- Comment #9 from CVS Commits --- The master branch has been updated by John David Anglin : https://gcc.gnu.org/g:ddb0f66e6c1e846bdc217075c9a770bfd0b01970 commit r13-7012-gddb0f66e6c1e846bdc217075c9a770bfd0b01970 Author: John David Anglin Date: Wed Apr 5 14:44:54 2023 + Add assember CFI directives to millicode division and remainder routines. The millicode division and remainder routines trap division by zero. The unwinder needs these directives to unwind divide by zero traps. 2023-04-05 John David Anglin libgcc/ChangeLog: PR target/109374 * config/pa/milli64.S (RETURN_COLUMN): Define. ($$divI): Add CFI directives. ($$divU): Likewise. ($$remI): Likewise. ($$remU): Likewise.
[Bug ipa/108959] [13 Regression] ice in modify_assignment, at ipa-param-manipulation.cc:1905 since r13-5681-ge8109bd87766be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108959 Martin Jambor changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #10 from Martin Jambor --- Fixed.
[Bug ipa/108959] [13 Regression] ice in modify_assignment, at ipa-param-manipulation.cc:1905 since r13-5681-ge8109bd87766be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108959 --- Comment #9 from CVS Commits --- The master branch has been updated by Martin Jambor : https://gcc.gnu.org/g:f0f372fab3e70622a4ea6fe4073991e1bb506e4e commit r13-7011-gf0f372fab3e70622a4ea6fe4073991e1bb506e4e Author: Martin Jambor Date: Wed Apr 5 16:36:49 2023 +0200 ipa: Avoid another ICE when dealing with type-incompatibilities (PR 108959) PR 108959 shows one more example where undefined code with type incompatible accesses to stuff passed in parameters can cause an ICE because we try to create a VIEW_CONVERT_EXPR of mismatching sizes: 1. IPA-CP tries to push one type from above, 2. IPA-SRA (correctly) decides the parameter is useless because it is only used to construct an argument to another function which does not use it and so the formal parameter should be removed, 3. but the code reconciling IPA-CP and IPA-SRA transformations still wants to perform the IPA-CP and overrides the built-in DCE of useless statements and tries to stuff constants into them instead, constants of a type with mismatching type and size. This patch avoids the situation in IPA-SRA by purging the IPA-CP results from any "aggregate" constants that are passed in parameters which are detected to be useless. It also removes IPA value range and bits information associated with removed parameters stored in the same structure so that the useless information is not streamed later on. gcc/ChangeLog: 2023-03-22 Martin Jambor PR ipa/108959 * ipa-sra.cc (zap_useless_ipcp_results): New function. (process_isra_node_results): Call it. gcc/testsuite/ChangeLog: 2023-03-17 Martin Jambor PR ipa/108959 * gcc.dg/ipa/pr108959.c: New test.
[Bug target/108947] [13 Regression] wrong code with -O2 -fno-forward-propagate and vector compare on riscv64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108947 --- Comment #2 from Jeffrey A. Law --- *** Bug 109040 has been marked as a duplicate of this bug. ***
[Bug target/109040] [13 Regression] wrong code with v16hi compare & mask on riscv64 at -O2 since r13-4907-g2e886eef7f2b5a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109040 Jeffrey A. Law changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #8 from Jeffrey A. Law --- Duplicate. *** This bug has been marked as a duplicate of bug 108947 ***
[Bug c++/109420] [13 Regression] lookup of 'struct T::X' at instantiation time does not ignore non-type bindings of 'X'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109420 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org Priority|P3 |P1
[Bug c++/109420] [13 Regression] lookup of 'struct T::X' at instantiation time does not ignore non-type bindings of 'X'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109420 Patrick Palka changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Known to fail||13.0 Target Milestone|--- |13.0 Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org Ever confirmed|0 |1 Last reconfirmed||2023-04-05 Known to work||12.2.0 --- Comment #1 from Patrick Palka --- Started with r13-6098-g46711ff8e60d64
[Bug c++/109420] New: [13 Regression] lookup of 'struct T::X' at instantiation time does not ignore non-type bindings of 'X'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109420
Bug ID: 109420
Summary: [13 Regression] lookup of 'struct T::X' at
instantiation time does not ignore non-type bindings
of 'X'
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ppalka at gcc dot gnu.org
Target Milestone: ---
struct A {
struct X { };
int X;
};
template
void f() {
struct T::X x;
}
template void f();
: In instantiation of ‘void f() [with T = A]’:
:11:20: required from here
:8:15: error: ‘typename A::X’ names ‘int A::X’, which is not a type
[Bug fortran/104272] finalizer gets called during allocate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104272 --- Comment #5 from Kai Germaschewski --- (In reply to Paul Thomas from comment #4) > Created attachment 54811 [details] > Fix for this PR > > I was sufficiently intrigued by this bug that I decided that I would look > into it right away. After all, it is the first time that such an old > finalization problem was producing too many calls to the final subroutine. > > I'll be posting to the list after checking the deja-gnuified testcase. > > Paul Thanks a lot for looking into this. I briefly looked at `gfc_trans_allocate`, but it's definitely beyond me ;)
[Bug target/99312] __ARM_ARCH is not implemented correctly when compiled with -march=armv8.1-a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99312 --- Comment #8 from Richard Earnshaw --- Applies to both AArch64 and Arm back-ends.
[Bug target/99312] __ARM_ARCH is not implemented correctly when compiled with -march=armv8.1-a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99312 Richard Earnshaw changed: What|Removed |Added CC||Vedant.VijayYevale@infineon ||.com --- Comment #7 from Richard Earnshaw --- *** Bug 109415 has been marked as a duplicate of this bug. ***
[Bug target/109415] No predefined macros to differentiate between ARM Cortex-M33 and Cortex-M55
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109415 Richard Earnshaw changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #9 from Richard Earnshaw --- https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99312 *** This bug has been marked as a duplicate of bug 99312 ***
[Bug target/109415] No predefined macros to differentiate between ARM Cortex-M33 and Cortex-M55
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109415 --- Comment #8 from Richard Earnshaw --- The __ARM_ARCH_...__ macros turned out to be a very bad design decision. Each new architecture needs a new macro that older compilers (and software) will not know about. The ACLE approach is far more sensible and GCC has mostly adopted that now. I personally consider the existing __ARM_ARCH_...__ macros to be deprecated, though I don't think the manual actually says this yet. There is a known bug in GCC. ACLE says that __ARM_ARCH should have the value *100 + for architectures after arm-v8, but we don't implement that yet (there may already be a PR about this) and report __ARM_ARCH=8 for all existing armv8.xxx variants.
[Bug c++/109419] New: [modules] ICE: Segmentation fault when using -fmodules-ts and -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109419
Bug ID: 109419
Summary: [modules] ICE: Segmentation fault when using
-fmodules-ts and -g
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: pap...@gmx.de
Target Milestone: ---
compiling
-8x---8x---8x---8x---
#include
struct A {
A() {
s.insert(1);
}
std::set s;
};
#include
-8x---8x---8x---8x---
as test.cpp with
g++ -ggdb -std=c++20 -fmodules-ts -freport-bug -c test.cpp
leads to an segmentation fault:
internal compiler error: Segmentation fault signal terminated program cc1plus
[Bug libstdc++/109418] -Werror=maybe-uninitialized triggered by /usr/include/c++/12.2.1/bits/random.tcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109418 Xi Ruoyao changed: What|Removed |Added Keywords|easyhack| CC||xry111 at gcc dot gnu.org --- Comment #2 from Xi Ruoyao --- Remove "easyhack" to prevent anyone from submitting a patch zero-initializing these variables to paper over the issue.
[Bug libstdc++/109418] -Werror=maybe-uninitialized triggered by /usr/include/c++/12.2.1/bits/random.tcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109418 --- Comment #1 from Xi Ruoyao --- (In reply to Gareth Anthony Hulse from comment #0) > Created attachment 54812 [details] > Output of `make -B 2> /tmp/errors.txt` > > `/usr/include/c++/12.2.1/bits/random.tcc` has variables that are possibly > uninitialised. The two culprits being line 1577: `double __x;` and line > 1600: `double __v;`. initialising them with a value such as 0, stops the > complaints from the compiler. No it's not the culprit. It's obvious __x and __v are not used uninitialized so it's a false warning. But -Wmaybe-uninitialized creates false warnings in the nature (so it's named *maybe*-uninitialized). To me -Werror=maybe-uninitialized does not make any sense.
[Bug libstdc++/109418] New: -Werror=maybe-uninitialized triggered by /usr/include/c++/12.2.1/bits/random.tcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109418 Bug ID: 109418 Summary: -Werror=maybe-uninitialized triggered by /usr/include/c++/12.2.1/bits/random.tcc Product: gcc Version: 12.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: gareth-anthony-hulse at posteo dot net Target Milestone: --- Created attachment 54812 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54812=edit Output of `make -B 2> /tmp/errors.txt` `/usr/include/c++/12.2.1/bits/random.tcc` has variables that are possibly uninitialised. The two culprits being line 1577: `double __x;` and line 1600: `double __v;`. initialising them with a value such as 0, stops the complaints from the compiler. This bug triggers for me when compiling ImHex with commit version 89aee456c6cd897ea7e998340ded2004d3638412. The commit mentioned was supposed to work around this issue, but had no effect. Attached log 'errors.txt' which is an output from `make -B 2> /tmp/errors.txt`. Specs: https://linux-hardware.org/?probe=201a4578ea FLAGS: - CPPFLAGS = -D_FORTIFY_SOURCE=2 - CXXFLAGS = -O3 -ftree-vectorize -floop-interchange -ftree-loop-distribution -ftree-loop-linear -floop-parallelize-all -fgraphite-identity -ftree-parallelize-loops=24 -floop-strip-mine -floop-block -fPIC -ffat-lto-objects -flto-compression-level=9 -pipe -fno-signed-zeros -fno-trapping-math -fno-plt -frename-registers -fstack-protector-all -flto=24 -pthread -DNDEBUG -fstack-clash-protection -fcf-protection=full - $LDFLAGS = -Wl,-O3,-flto,--strip-all,--sort-common,--as-needed,-z,relro,-z,now,-z,defs -pthread
[Bug libstdc++/109405] Should class final decoration result in larger unique_ptr with deleter ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109405 --- Comment #4 from Jonathan Wakely --- It's possible to fix for the --enable-symvers=gnu-versioned-namespace build which does not promise a backwards compatible ABI. I didn't do that yet, I *think* it was because support for [[no_unique_address]] was still patchy in Clang and other non-GCC compilers. Maybe that's no longer an issue and it could be done now.
[Bug tree-optimization/109154] [13 regression] jump threading de-optimizes nested floating point comparisons
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109154 ktkachov at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1 --- Comment #43 from ktkachov at gcc dot gnu.org --- Indeed, thank you for the high quality analysis and improvements! Marking this as P1 as it's a regression on aarch64-linux in GCC 13 so we'd want to track this for the release, but of course it's up to RMs for the final say.
[Bug libstdc++/109405] Should class final decoration result in larger unique_ptr with deleter ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109405 Xi Ruoyao changed: What|Removed |Added Resolution|--- |WONTFIX CC||xry111 at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED --- Comment #3 from Xi Ruoyao --- WONTFIX then.
[Bug tree-optimization/109154] [13 regression] jump threading de-optimizes nested floating point comparisons
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109154 --- Comment #42 from Tamar Christina --- Thanks for all the work so far folks! Just to clarify the current state, it looks like the first reduced testcase is now correct. But the larger example as in c26 is still suboptimal, but slightly better. https://godbolt.org/z/7vbrG8EMj
[Bug tree-optimization/109417] [13 Regression] ICE on valid code at -O3 on x86_64-linux-gnu: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109417 Xi Ruoyao changed: What|Removed |Added Last reconfirmed||2023-04-05 Ever confirmed|0 |1 CC||xry111 at gcc dot gnu.org Keywords||ice-on-valid-code Known to work||12.2.0 Version|unknown |13.0 Summary|ICE on valid code at -O3 on |[13 Regression] ICE on |x86_64-linux-gnu: |valid code at -O3 on |Segmentation fault |x86_64-linux-gnu: ||Segmentation fault Status|UNCONFIRMED |NEW
[Bug c++/109356] Enhancement idea to provide clearer missing brace line number
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109356
Xi Ruoyao changed:
What|Removed |Added
Resolution|--- |WONTFIX
Status|UNCONFIRMED |RESOLVED
--- Comment #4 from Xi Ruoyao ---
(In reply to Jonny Grant from comment #3)
> A different example where GCC does a good job of indicating the line number
> of a missing comma problem.
>
>
> https://godbolt.org/z/asGhE3W17
>
>
> :6:5: error: expected '}' before '{' token
> 6 | {"G", "H"},
> | ^
> :2:1: note: to match this '{'
> 2 | {
> | ^
> :6:5: error: expected ',' or ';' before '{' token
> 6 | {"G", "H"},
> | ^
This is easy because the parser has to insert a comma here to correct the
syntax. But for a missing } it can be added at one of multiple places to make
the syntax correct.
The parser always keeps progressing unless it's sure there is a syntax error.
Note that
static const char * list[][2] =
{
{"A", "B"},
{"C", "D"},
{"E", "F",
{"G", "H"},
{"I", "J"}
}};
is NOT a syntax error. It's a semantic error (violating a constraint) but the
parser does not know about semantics (i.e. the parser does not know what "[2]"
means at all). So the parser cannot be sure about the syntax error until the
last line.
Mixing the semantic analysis into the parser is not acceptable because it's not
how a compiler is implemented.
Make the parser try different locations and pass all possible syntax tree to
the further passes is at least quadratic behavior and not acceptable.
I'll say this WONTFIX. If someone knows how to do this in a rational way
please reopen.
[Bug ipa/109303] [13 Regression] ICE in push_agg_values_from_plats, at ipa-cp.cc:1458 since r13-3358-ge0403e95689af7d5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109303 --- Comment #12 from Martin Liška --- *** Bug 109408 has been marked as a duplicate of this bug. *** --- Comment #13 from Martin Liška --- *** Bug 109408 has been marked as a duplicate of this bug. ***
[Bug ipa/109303] [13 Regression] ICE in push_agg_values_from_plats, at ipa-cp.cc:1458 since r13-3358-ge0403e95689af7d5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109303 --- Comment #12 from Martin Liška --- *** Bug 109408 has been marked as a duplicate of this bug. *** --- Comment #13 from Martin Liška --- *** Bug 109408 has been marked as a duplicate of this bug. ***
[Bug ipa/109408] [13 Regression] ICE in decide_about_value, at ipa-cp.cc:6154
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109408 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #2 from Martin Liška --- Dup. *** This bug has been marked as a duplicate of bug 109303 *** --- Comment #3 from Martin Liška --- Dup. *** This bug has been marked as a duplicate of bug 109303 ***
[Bug ipa/109408] [13 Regression] ICE in decide_about_value, at ipa-cp.cc:6154
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109408 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Martin Liška --- Dup. *** This bug has been marked as a duplicate of bug 109303 ***
[Bug tree-optimization/109417] New: ICE on valid code at -O3 on x86_64-linux-gnu: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109417
Bug ID: 109417
Summary: ICE on valid code at -O3 on x86_64-linux-gnu:
Segmentation fault
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: zhendong.su at inf dot ethz.ch
Target Milestone: ---
This appears to be a recent regression.
Compiler Explorer: https://godbolt.org/z/eM6aG1aYc
[605] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/suz-local/software/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/13.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--enable-checking=yes --prefix=/local/suz-local/software/local/gcc-trunk
--enable-sanitizers --enable-languages=c,c++ --disable-werror --enable-multilib
--with-system-zlib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 13.0.1 20230405 (experimental) [master r13-7008-gfdc5abbdcfb] (GCC)
[606] %
[606] % gcctk -O2 small.c; ./a.out
[607] %
[607] % gcctk -O3 small.c
during GIMPLE pass: vrp
small.c: In function ‘main’:
small.c:3:5: internal compiler error: Segmentation fault
3 | int main() {
| ^~~~
0xeeb4bf crash_signal
../../gcc-trunk/gcc/toplev.cc:314
0x1cea605 gori_compute::may_recompute_p(tree_node*, basic_block_def*, int)
../../gcc-trunk/gcc/gimple-range-gori.cc:1322
0x1cda775 ranger_cache::range_from_dom(vrange&, tree_node*, basic_block_def*,
ranger_cache::rfd_mode)
../../gcc-trunk/gcc/gimple-range-cache.cc:1462
0x1cdc8e0 ranger_cache::range_from_dom(vrange&, tree_node*, basic_block_def*,
ranger_cache::rfd_mode)
../../gcc-trunk/gcc/gimple-range-cache.cc:1426
0x1cdc8e0 ranger_cache::fill_block_cache(tree_node*, basic_block_def*,
basic_block_def*)
../../gcc-trunk/gcc/gimple-range-cache.cc:1212
0x1cdd5a4 ranger_cache::block_range(vrange&, basic_block_def*, tree_node*,
bool)
../../gcc-trunk/gcc/gimple-range-cache.cc:1039
0x1cd3ce8 gimple_ranger::range_on_entry(vrange&, basic_block_def*, tree_node*)
../../gcc-trunk/gcc/gimple-range.cc:156
0x11bde4a remove_unreachable::remove_and_update_globals(bool)
../../gcc-trunk/gcc/tree-vrp.cc:156
0x11c066d remove_unreachable::remove_and_update_globals(bool)
../../gcc-trunk/gcc/tree-vrp.cc:1104
0x11c066d execute_ranger_vrp(function*, bool, bool)
../../gcc-trunk/gcc/tree-vrp.cc:1104
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
[608] %
[608] % cat small.c
int printf(const char *, ...);
int c, d, *e, f[1][2], g;
int main() {
int h = 0, *a = , **b[1] = {};
while (e)
while (g) {
L:
for (h = 0; h < 2; h++) {
while (d)
for (*e = 0; *e < 1;)
printf("0");
while (c)
;
f[g][h] = 0;
}
}
if (h)
goto L;
return 0;
}
[Bug tree-optimization/107591] range-op{,-float}.cc for x * x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107591
--- Comment #19 from Pilar Latiesa ---
The testcase:
#include
struct TVec { double x, y, z; };
double dot(TVec const , TVec const )
{ return u.x * v.x + u.y * v.y + u.y * v.y + u.z * v.z; }
double mag(TVec const )
{ return std::sqrt(dot(u, u)); }
with current trunk is compiled as:
vmovsd 8(%rdi), %xmm0
vmovsd (%rdi), %xmm1
vmulsd %xmm0, %xmm0, %xmm0
vmovsd %xmm1, %xmm1, %xmm2
vfmadd132sd %xmm1, %xmm0, %xmm2
vmovsd 16(%rdi), %xmm1
vaddsd %xmm2, %xmm0, %xmm0
vfmadd132sd %xmm1, %xmm0, %xmm1
vsqrtsd %xmm1, %xmm1, %xmm0
ret
That's excellent. Thanks
[Bug fortran/104272] finalizer gets called during allocate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104272 --- Comment #4 from Paul Thomas --- Created attachment 54811 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54811=edit Fix for this PR I was sufficiently intrigued by this bug that I decided that I would look into it right away. After all, it is the first time that such an old finalization problem was producing too many calls to the final subroutine. I'll be posting to the list after checking the deja-gnuified testcase. Paul
[Bug target/109416] Missed constant propagation cases after reload
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109416
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2023-04-05
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
--- Comment #2 from Andrew Pinski ---
For the init function:
(insn 5 2 6 (set (reg/f:SI 15 a5 [134])
(high:SI (symbol_ref:SI ("Data") [flags 0x86] ))) "t4.c":5:10 180 {*movsi_internal}
(expr_list:REG_EQUIV (high:SI (symbol_ref:SI ("Data") [flags 0x86]
))
(nil)))
(insn 6 5 13 (set (reg/f:SI 15 a5 [135])
(lo_sum:SI (reg/f:SI 15 a5 [134])
(symbol_ref:SI ("Data") [flags 0x86] ))) "t4.c":5:10 174 {*lowsi}
(expr_list:REG_EQUIV (symbol_ref:SI ("Data") [flags 0x86] )
(nil)))
(insn 13 6 14 (set (reg:SI 13 a3 [137])
(const_int 0 [0])) "t4.c":5:10 180 {*movsi_internal}
(nil))
(insn 14 13 15 (set (reg:SI 14 a4 [+4 ])
(const_int 0 [0])) "t4.c":5:10 180 {*movsi_internal}
(nil))
(insn 15 14 16 (set (mem/c:SI (reg/f:SI 15 a5 [135]) [1 Data+0 S4 A64])
(reg:SI 13 a3 [137])) "t4.c":5:10 180 {*movsi_internal}
(expr_list:REG_DEAD (reg:SI 13 a3 [137])
(nil)))
(insn 16 15 23 (set (mem/c:SI (plus:SI (reg/f:SI 15 a5 [135])
(const_int 4 [0x4])) [1 Data+4 S4 A32])
(reg:SI 14 a4 [+4 ])) "t4.c":5:10 180 {*movsi_internal}
(expr_list:REG_DEAD (reg/f:SI 15 a5 [135])
(expr_list:REG_DEAD (reg:SI 14 a4 [+4 ])
(nil
LRA/reload decides to change:
(insn 7 6 10 2 (set (mem/c:DI (reg/f:SI 135) [1 Data+0 S8 A64])
(const_int 0 [0])) "t4.c":5:10 178 {*movdi_32bit}
(expr_list:REG_DEAD (reg/f:SI 135)
(nil)))
To:
(insn 7 6 12 2 (set (reg:DI 13 a3 [137])
(const_int 0 [0])) "t4.c":5:10 178 {*movdi_32bit}
(nil))
(insn 12 7 10 2 (set (mem/c:DI (reg/f:SI 15 a5 [135]) [1 Data+0 S8 A64])
(reg:DI 13 a3 [137])) "t4.c":5:10 178 {*movdi_32bit}
(nil))
I would have expected not have happened ...
So the init function is definitely a target issue As LRA should have kept it as
one store instruction ...
[Bug rtl-optimization/109416] Missed constant propagation cases after reload
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109416
--- Comment #1 from Andrew Pinski ---
Note aarch64 issue is totally different:
(insn 13 6 14 2 (set (reg:DI 2 x2 [94])
(const_int 1048575 [0xf])) "/app/example.cpp":5:10 65
{*movdi_aarch64}
(nil))
(insn 14 13 8 2 (set (reg:DI 3 x3 [+8 ])
(const_int 0 [0])) "/app/example.cpp":5:10 65 {*movdi_aarch64}
(nil))
(insn 8 14 11 2 (set (mem/c:TI (reg/f:DI 0 x0 [92]) [1 Data+0 S16 A128])
(reg:TI 2 x2 [94])) "/app/example.cpp":5:10 70 {*movti_aarch64}
(nil))
Please file that seperately.
[Bug rtl-optimization/109416] New: Missed constant propagation cases after reload
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109416
Bug ID: 109416
Summary: Missed constant propagation cases after reload
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: sinan.lin at linux dot alibaba.com
Target Milestone: ---
gcc splits a movdi_32bit pattern into two insns after reload in rv32, which
brings constant propagation opportunities.
e.g.
```
long long int Data;
void init() {
Data = 0x0;
}
void init2() {
Data = 0xf;
}
void init3() {
Data = 0xf000f;
}
```
asm output
```
init:
lui a5,%hi(Data)
li a3,0
li a4,0
sw a3,%lo(Data)(a5)
sw a4,%lo(Data+4)(a5)
ret
init2:
lui a5,%hi(Data)
li a2,0
li a3,15
sw a2,%lo(Data)(a5)
sw a3,%lo(Data+4)(a5)
ret
init3:
lui a5,%hi(Data)
li a2,15
li a3,15
sw a2,%lo(Data)(a5)
sw a3,%lo(Data+4)(a5)
ret
```
could be optimized into
```
init:
lui a5,%hi(Data)
sw zero,%lo(Data)(a5)
sw zero,%lo(Data+4)(a5)
ret
init2:
lui a5,%hi(Data)
li a2,15
sw zero,%lo(Data)(a5)
sw a2,%lo(Data+4)(a5)
ret
init3:
lui a5,%hi(Data)
li a2,15
sw a2,%lo(Data)(a5)
sw a2,%lo(Data+4)(a5)
ret
```
A similar case in AArch64
```
__int128 Data;
void init() {
Data = 0xf;
}
```
output
```
init:
adrpx0, .LANCHOR0
add x0, x0, :lo12:.LANCHOR0
mov x2, 1048575
mov x3, 0
stp x2, x3, [x0]
ret
```
could be optimized into
```
init:
adrpx0, .LANCHOR0
add x0, x0, :lo12:.LANCHOR0
mov x2, 1048575
stp x2, xzr, [x0]
ret
```
[Bug target/109415] No predefined macros to differentiate between ARM Cortex-M33 and Cortex-M55
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109415 --- Comment #7 from vedant --- in ARM and IAR as well ARMv8.1-m vs ARMv8-m have different macros. it is needed to maintain code compatibility in different build ecosystems. instead of specifying -DXYZ everywhere
[Bug target/109415] No predefined macros to differentiate between ARM Cortex-M33 and Cortex-M55
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109415 --- Comment #6 from Andrew Pinski --- Also I noticed the ACLE is confusing for any of the -m profile stuff and mostly just references the -a profile too.
[Bug target/109415] No predefined macros to differentiate between ARM Cortex-M33 and Cortex-M55
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109415 --- Comment #5 from Andrew Pinski --- (In reply to vedant from comment #3) > in arm compiler i have found __ARM_ARCH_8M_MAIN__ and __ARM_ARCH_8_1M_MAIN__ > for CM33 and CM55 respectively. As far as I can tell those macros are not documented in https://github.com/ARM-software/acle . You might want to file a bug with that first.
[Bug target/109415] No predefined macros to differentiate between ARM Cortex-M33 and Cortex-M55
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109415 --- Comment #4 from Andrew Pinski --- Depending on the feature you are testing for, you could use some other macros. e.g. __ARM_FEATURE_PAUTH, __ARM_FEATURE_BTI, __ARM_FEATURE_CMSE .
[Bug target/109415] No predefined macros to differentiate between ARM Cortex-M33 and Cortex-M55
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109415 --- Comment #3 from vedant --- in arm compiler i have found __ARM_ARCH_8M_MAIN__ and __ARM_ARCH_8_1M_MAIN__ for CM33 and CM55 respectively.
[Bug rtl-optimization/109351] RA uses lowest cost for the mode of different reg_classes w/o considering hard_regno_mode_ok.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109351 --- Comment #2 from Uroš Bizjak --- Patch at https://gcc.gnu.org/pipermail/gcc-patches/2023-April/615074.html
[Bug target/109415] No predefined macros to differentiate between ARM Cortex-M33 and Cortex-M55
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109415 --- Comment #2 from Andrew Pinski --- https://github.com/ARM-software/acle Does not define one either ... That is it does not define ARMv8.1-m vs ARMv8-m difference either ...
