https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119319
--- Comment #9 from Hans-Peter Nilsson ---
(In reply to Andrew Pinski from comment #6)
> > I just can't find the incompleteness
>
> the use of Xyzzy is before it is fully declared. There is only a forward
> declaration of the struct type when i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118974
Tamar Christina changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |tnfchris at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118974
--- Comment #3 from Tamar Christina ---
and using the SVE CC regs:
.L6:
ldr q30, [x2, x0]
cmple p15.s, p7/z, z30.s, #0
b.none .L2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119320
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88443
Bug 88443 depends on bug 119320, which changed state.
Bug 119320 Summary: unexpected -Wstringop-overflow= when using memcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119320
What|Removed |Added
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114978
--- Comment #35 from Chen Chen ---
(In reply to chenglulu from comment #34)
> (In reply to Xi Ruoyao from comment #29)
> > For 15 r15-7525 is intended for this issue. But I don't know if it's a good
> > idea to backport it, as it's only a worka
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114978
--- Comment #36 from Andrew Pinski ---
(In reply to Chen Chen from comment #35)
>
> 1. unknown patch committed between 20250105-20250112 on gcc15: works for
> gcc15, possibly also works for gcc14? If yes, can it be backported to gcc14?
r15-665
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119291
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
Component|middle-end
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119311
--- Comment #2 from Jakub Jelinek ---
Created attachment 60789
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60789&action=edit
gcc15-pr119311.patch
Untested fix.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119312
--- Comment #9 from Bruno Haible ---
> But the callee is still allowed to assign the whole struct through the
> non-const pointer.
Oh, I see. Yes,
void
foo (struct S *s)
{
s[-1] = s[0];
}
would disable the optimization.
Yeah, then it need
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119318
Martin Jambor changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119312
--- Comment #10 from Jakub Jelinek ---
(In reply to Bruno Haible from comment #9)
> We need only to see that the compilation unit only ever accesses
> html5[i].name and html5[i].value but never html5[i] as an entire struct. I
> don't think any k
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114978
--- Comment #38 from Chen Chen ---
(In reply to Xi Ruoyao from comment #37)
> So if we revert r15-7525 now, would things work normally with just r15-6657?
> If so I'd suggest to revert r15-7525 (now or when GCC 16 stage 1 starts) and
> close thi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119244
--- Comment #18 from Jakub Jelinek ---
I think s390x-linux is similar to aarch64-linux here, neither has libquadmath
support.
Just long double is always IEEE quad on aarch64-linux and on s390x-linux it is
configurable, one can choose between IEE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119244
--- Comment #19 from Richard Biener ---
I'll cook up a preliminary patch for the Q vs. f128 change.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119244
--- Comment #20 from Iain Sandoe ---
(In reply to Jakub Jelinek from comment #18)
> I think s390x-linux is similar to aarch64-linux here, neither has
> libquadmath support.
However, libquadmath works fine on aarch64-darwin, so it is a possible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119322
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119322
Bug ID: 119322
Summary: Different results between -O1 and -O3
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119244
--- Comment #22 from Jakub Jelinek ---
Q is an extension suffix for __float128 literals.
s390*-linux doesn't support those, it only has long double (l/L suffix) or
_Float128 (f128/F128 suffix).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119244
--- Comment #21 from Richard Biener ---
(In reply to Richard Biener from comment #19)
> I'll cook up a preliminary patch for the Q vs. f128 change.
Note it seems libgfortran LIBGFOR_CHECK_FLOAT128 sets USE_IEC_60559 in
odd ways, also requiring
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119322
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119316
Marek Polacek changed:
What|Removed |Added
Summary|new expression incorrectly |[14/15 Regression] new
);
}
```
```
Using built-in specs.
COLLECT_GCC=/opt/compiler-explorer/gcc-snapshot/bin/g++
Target: x86_64-linux-gnu
Configured with: ../gcc-trunk-20250317/configure
--prefix=/opt/compiler-explorer/gcc-build/staging
--enable-libstdcxx-backtrace=yes --build=x86_64-linux-gnu
--host=x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119328
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
Last reco
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119305
Patrick Palka changed:
What|Removed |Added
Keywords|needs-bisection |
CC|
confirmed|0 |1
Last reconfirmed||2025-03-17
Status|UNCONFIRMED |NEW
--- Comment #2 from Iain Sandoe ---
confirmed on cfarm135 with 15.0.1 20250317
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117069
--- Comment #12 from Andrew Pinski ---
https://gcc.gnu.org/pipermail/gcc-patches/2025-March/60.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119325
--- Comment #5 from Tobias Burnus ---
For both the reduced and the full example: If I write the pragma as:
#pragma omp target map(to:a,b) map(from:res)
#pragma omp for simd
(i.e. I remove the 'parallel' before 'for simd') the code starts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114978
--- Comment #40 from Chen Chen ---
(In reply to Andrew Pinski from comment #36)
> (In reply to Chen Chen from comment #35)
> >
> > 1. unknown patch committed between 20250105-20250112 on gcc15: works for
> > gcc15, possibly also works for gcc14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119244
Iain Sandoe changed:
What|Removed |Added
Attachment #60777|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119244
--- Comment #25 from Iain Sandoe ---
(In reply to Iain Sandoe from comment #24)
> Created attachment 60792 [details]
> v2 patch with support for long double and literal suffix wrapping.
>
> This tries to pick up Jakub's suggestion as to how to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119220
--- Comment #3 from GCC Commits ---
The master branch has been updated by John David Anglin :
https://gcc.gnu.org/g:45f7424ce8961631ee12ba473e3c36d3952d19f2
commit r15-8089-g45f7424ce8961631ee12ba473e3c36d3952d19f2
Author: John David Anglin
D
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119343
Bug ID: 119343
Summary: No SFINAE for deleted explicit specializations
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119344
--- Comment #1 from Andrew Pinski ---
Created attachment 60795
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60795&action=edit
C++98 testcase
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119344
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2025-03-17
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119213
--- Comment #11 from GCC Commits ---
The master branch has been updated by Robert Dubner :
https://gcc.gnu.org/g:aa68eb8d5687f8e0944512cbc8533a77cd312873
commit r15-8239-gaa68eb8d5687f8e0944512cbc8533a77cd312873
Author: Bob Dubner
Date: Mon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119327
--- Comment #2 from Sergey Fedorov ---
Created attachment 60796
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60796&action=edit
Preprocessed source file which fails to compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119213
Robert Dubner changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119211
Bug 119211 depends on bug 119213, which changed state.
Bug 119213 Summary: gcc/cobol/Make-lang.in: suspicious -DEXEC_LIB with
hardcoded lib64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119213
What|Removed |A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119327
--- Comment #3 from Sergey Fedorov ---
And result of running the command manually:
$ sudo /opt/local/bin/g++-mp-14 -v -save-temps -DABSL_MIN_LOG_LEVEL=1
-Ds2_EXPORTS -I/opt/local/libexec/openssl3/include
-I/opt/local/var/macports/build/_opt_loc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119344
Bug ID: 119344
Summary: internal compiler error related to template parameters
and pointers to member functions
Product: gcc
Version: 14.2.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119314
--- Comment #6 from Novel ---
(In reply to Andrew Pinski from comment #5)
> (In reply to Novel from comment #0)
>
> > ; CODE XREF from sym.IGNORE_THIS_ITS_FUNCTION_NAME @ 0x8bcc(x)
> > ; 0x28f58
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119314
--- Comment #7 from Sam James ---
Please try to reduce the relevant functions and we can take a look with a
testcase.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119344
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119345
--- Comment #1 from Andrew Pinski ---
Created attachment 60799
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60799&action=edit
C++17 testcase
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119345
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |14.3
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119222
--- Comment #14 from Gwen Fu ---
and I will send the patch at the same time
::xform<0>;
int main() {}
```
```
Using built-in specs.
COLLECT_GCC=/opt/compiler-explorer/gcc-snapshot/bin/g++
Target: x86_64-linux-gnu
Configured with: ../gcc-trunk-20250317/configure
--prefix=/opt/compiler-explorer/gcc-build/staging
--enable-libstdcxx-backtrace=yes --build=x86_64-lin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119347
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119012
--- Comment #20 from Levi Zim ---
I have minified it to the following commands:
git -C gcc checkout 1cd744a6828f6ab9179906d16434ea40b6404737
mkdir gcc-build && cd $_
export CFLAGS="-march=rv64gc -mabi=lp64d -O2 -Wp,-D_FORTIFY_SOURCE=3 -g
-ffil
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119346
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119344
--- Comment #4 from Marek Polacek ---
I guess we need
--- a/gcc/tree.cc
+++ b/gcc/tree.cc
@@ -4101,7 +4101,7 @@ skip_simple_arithmetic (tree expr)
computations if they actually occur. */
while (true)
{
- if (UNARY_CLASS_P (e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119343
--- Comment #1 from Andrew Pinski ---
4.8.0 used to do something similar for has_f too. Maybe that can help someone.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119338
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37208
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |4.4.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119327
--- Comment #4 from Andrew Pinski ---
Trying to reduce it.
But yes I can reproduce it on the trunk and -O2 works but -Os does not.
This might be due to the code savings with the C++ front-end and constructors.
Or it could be something else.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119314
Andrew Pinski changed:
What|Removed |Added
Summary|Possibly wrong code |Possibly wrong code
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119343
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57419
--- Comment #7 from Andrew Pinski ---
r0-123716-g2e6491515ec153
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55004
Bug 55004 depends on bug 111379, which changed state.
Bug 111379 Summary: comparison between unequal pointers to void should be
illegal during constant evaluation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111379
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111379
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |WONTFIX
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117452
Hongtao Liu changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119327
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|1 |0
Keywords|needs-source
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119327
--- Comment #5 from Andrew Pinski ---
Note the quick and dirty short function testcase just includes absl and
libstdc++ classes (note is not a full testcase just what I have done so far
manually to testcase):
```
void BuildPolygonBoundaries() {
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119349
Bug ID: 119349
Summary: [15 Regression] polymorphic array dummy argument with
function result actual argument in elemental function
Product: gcc
Version: 15.0
Status: UN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119314
--- Comment #10 from Sam James ---
(We also don't care if the reduced version has the same real typedefs and so on
as the original, as long as the reduced version reproduces it, of course.)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119314
Sam James changed:
What|Removed |Added
CC||sjames at gcc dot gnu.org
--- Comment #9 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119327
--- Comment #8 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #5)
> So it is not related at all to s2geometry sources as far as I can tell.
Except for the `pragma GCC optimize` :).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119348
--- Comment #1 from nihui ---
tested commit
gcc 7efe3aa9b5d4d7aba3736d1393b007705522dc45
binutils cf4fdbd491bbf60267d4ba6ec3f533944e376e6c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119348
Bug ID: 119348
Summary: risc-v vector tuple casting optimization regression
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119348
--- Comment #2 from nihui ---
aha, just found that pointer casting works in gcc :)
though clang seems unhappy about it
```c
#include
vfloat32m8_t convert_vfloat32m1x8_to_vfloat32m8(vfloat32m1x8_t tuple)
{
return *(vfloat32m8_t*)(&tuple);
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119348
Andrew Pinski changed:
What|Removed |Added
Keywords||missed-optimization, ra
Ever confir
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117069
--- Comment #14 from Hongtao Liu ---
(In reply to Sam James from comment #13)
> (In reply to Hongtao Liu from comment #9)
> > I didn't find this commit in gcc trunk?
>
> Ah, sorry for confusion: it's from my local test results. Only the date
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119310
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119314
--- Comment #11 from Sam James ---
Or, to put it another way: you're familiar with the code enough to share those
comments about whether something is pure and so on, so it should be doable for
you to then replace the function names with some stu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119327
Andrew Pinski changed:
What|Removed |Added
Target|powerpc64-linux-gnu |powerpc*-linux-gnu
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119327
Andrew Pinski changed:
What|Removed |Added
Known to work||11.2.0
Target|powerpc-apple
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119327
--- Comment #6 from Andrew Pinski ---
Created attachment 60798
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60798&action=edit
Reduced testcase
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119340
--- Comment #2 from Sam James ---
Created attachment 60797
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60797&action=edit
reduced.i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119350
Bug ID: 119350
Summary: flexible array initialization is allowed when
initialized with `{}` with C23
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119312
--- Comment #11 from Joseph S. Myers ---
A struct with a const field is not a modifiable lvalue in C, so it's not valid
to assign to it. Modifying a const field with memcpy / byte accesses would
probably also violate "If an attempt is made to mo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119314
--- Comment #8 from Novel ---
(In reply to Sam James from comment #7)
> Please try to reduce the relevant functions and we can take a look with a
> testcase.
I am not sure to what extend it is possible for you to make a testcase for it
because
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119314
--- Comment #13 from Novel ---
(In reply to Andrew Pinski from comment #3)
> Before `DEBUG_LOG_INFO("2 Data %p\n", dest.Data);`
> is there any calls before hand? Like say to memcpy? or anything that might
> have the nonnull attribute on it and u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117069
--- Comment #15 from Hongtao Liu ---
(In reply to Sam James from comment #7)
> This stopped failing for me around:
>
> commit 2bc3ea210565dc7cdbba9adb31acceefed406254
> Author: Sam James
> Date: Fri Nov 22 15:20:45 2024 +
>
> saving
; });
}.template operator()<0>();
}
int main() {
f();
}
```
```
Using built-in specs.
COLLECT_GCC=/opt/compiler-explorer/gcc-snapshot/bin/g++
Target: x86_64-linux-gnu
Configured with: ../gcc-trunk-20250317/configure
--prefix=/opt/compiler-explorer/gcc-build/staging
--enable-lib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119222
--- Comment #13 from Gwen Fu ---
When executing the conversion_warning function, if you do not add any of
the three compilation options -Warn-conversion or -Warn_sign_conversion or
-Warn-float-conversion, the function will return directly.
/compiler-explorer/gcc-snapshot/bin/g++
Target: x86_64-linux-gnu
Configured with: ../gcc-trunk-20250317/configure
--prefix=/opt/compiler-explorer/gcc-build/staging
--enable-libstdcxx-backtrace=yes --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu --disable-bootstrap
--enable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119272
Andre Vehreschild changed:
What|Removed |Added
Status|NEW |WAITING
Assignee|unassign
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119312
--- Comment #5 from Jakub Jelinek ---
Certainly.
If you do
struct S { char a[4]; char b[4]; };
extern void foo (struct S *);
static struct S s[] = { { "abc", "def" }, { "ghi", "jkl" } };
void
bar (void)
{
foo (&s[1]);
}
i.e. if the address esc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119312
--- Comment #4 from Bruno Haible ---
> So, you're basically asking for interprocedural optimization
No, I'm basically asking for type analysis: The compiler could note that the
struct has an "all fields are const" property, and that this is eno
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117978
--- Comment #6 from Jennifer Schmitz ---
Created attachment 60790
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60790&action=edit
Proposed patch for folding SVE load/store with certain ptrue patterns to
LDR/STR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119307
--- Comment #3 from Jakub Jelinek ---
Untested fix:
--- gcc/lra.cc.jj 2025-02-26 19:24:53.408264023 +0100
+++ gcc/lra.cc 2025-03-17 10:07:24.299064598 +0100
@@ -1730,6 +1730,12 @@ lra_rtx_hash (rtx x)
case CONST_INT:
return va
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119325
--- Comment #2 from Tobias Burnus ---
(In reply to Richard Biener from comment #1)
> The bisection is quite odd
I am re-testing. Somehow mixed full rebuilds and incremental builds,
which affect whether newlib (libm) is rebuild or not.
I am now
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114978
--- Comment #41 from Chen Chen ---
(In reply to Chen Chen from comment #40)
> (In reply to Andrew Pinski from comment #36)
> > (In reply to Chen Chen from comment #35)
> > >
> > > 1. unknown patch committed between 20250105-20250112 on gcc15: w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119244
--- Comment #23 from Iain Sandoe ---
(In reply to Richard Biener from comment #21)
> (In reply to Richard Biener from comment #19)
> > I'll cook up a preliminary patch for the Q vs. f128 change.
>
> Note it seems libgfortran LIBGFOR_CHECK_FLOAT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119322
--- Comment #2 from Egor Pugin ---
Tried this without -fno-strict-aliasing
I suspect it was something on my side.
With -fno-strict-aliasing answer is 0.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119322
--- Comment #4 from Egor Pugin ---
I see, thank you.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119321
Richard Biener changed:
What|Removed |Added
Keywords||diagnostic, false-positive,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114978
--- Comment #39 from Xi Ruoyao ---
(In reply to Chen Chen from comment #38)
> (In reply to Xi Ruoyao from comment #37)
> > So if we revert r15-7525 now, would things work normally with just r15-6657?
> > If so I'd suggest to revert r15-7525 (now
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119323
Bug ID: 119323
Summary: cppcheck meets libgcobol
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: cobol
Assigne
1 - 100 of 215 matches
Mail list logo