https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109520
Bug ID: 109520
Summary: compiler never terminate
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109519
--- Comment #4 from Andrew Pinski ---
Created attachment 54863
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54863=edit
Patch to bitshuffle which fixes aliasing issues
Attached is the patch which forces to use a may_alias typedef for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109519
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109519
--- Comment #2 from Andrew Pinski ---
And adding -fno-strict-aliasing fixes the issue too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109519
--- Comment #1 from Andrew Pinski ---
Are you 100% sure there is no aliasing issues here?
Especially with code like:
uint16_t *out_ui16 = (uint16_t*) _b[((7 - kk) * nbyte + ii) / 8];
*out_ui16 = ((uint16_t*)out)[kk];
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109519
Bug ID: 109519
Summary: aarch64: wrong code with NEON intrinsics on gcc-10 and
later
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109518
Bug ID: 109518
Summary: invalid constexpr code is accepted
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109358
--- Comment #4 from Jerry DeLisle ---
Well this is getting quite interesting. There is a bit of discussion going on
the Fortran Discourse about this.
https://fortran-lang.discourse.group/t/tab-formatting-with-stream-access/5466/47
After
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99708
--- Comment #37 from CVS Commits ---
The master branch has been updated by Alexandre Oliva :
https://gcc.gnu.org/g:86b31d583a3657f11d930ff156c07b2e20ab05eb
commit r13-7191-g86b31d583a3657f11d930ff156c07b2e20ab05eb
Author: Alexandre Oliva
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109357
Jason Merrill changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109514
Jason Merrill changed:
What|Removed |Added
Resolution|--- |FIXED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109514
--- Comment #2 from CVS Commits ---
The trunk branch has been updated by Jason Merrill :
https://gcc.gnu.org/g:9964df74a9e99e850bf9b0b6ff5c47133f846db8
commit r13-7190-g9964df74a9e99e850bf9b0b6ff5c47133f846db8
Author: Jason Merrill
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109506
--- Comment #9 from Sam James ---
I violated my own rule, by the way, by not saying the origin. This was found by
sultan in Gentoo when building Chromium (112, I think).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109505
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Target Milestone|12.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109505
Andrew Pinski changed:
What|Removed |Added
Summary|[12/13 Regression] Compiler |[12/13 Regression] Compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109505
--- Comment #5 from Andrew Pinski ---
/* (X & Y) & Y -> X & Y
(X | Y) | Y -> X | Y */
(for op (bit_and bit_ior)
(simplify
(op:c (convert1?@2 (op:c @0 @@1)) (convert2? @1))
@2))
...
/* Given a bit-wise operation CODE applied to ARG0 and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109505
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |12.3
Summary|Compiler loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109505
Andrew Pinski changed:
What|Removed |Added
Status|WAITING |UNCONFIRMED
Ever confirmed|1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109027
Steven Sun changed:
What|Removed |Added
CC||StevenSun2021 at hotmail dot
com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109516
--- Comment #8 from Andrew Pinski ---
(In reply to Yann Droneaud from comment #7)
> (In reply to Andrew Pinski from comment #6)
> > >
> > > And I failed to comprehend how unsigned long int:48 can be passed to a
> > > variadic function without
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109516
--- Comment #7 from Yann Droneaud ---
(In reply to Andrew Pinski from comment #6)
> >
> > And I failed to comprehend how unsigned long int:48 can be passed to a
> > variadic function without being promoted to plain unsigned long int ...
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108910
--- Comment #18 from Jason Merrill ---
(In reply to Jakub Jelinek from comment #13)
> Jason, any thoughts on why we for build_type_attribute_qual_variant call
> build_distinct_type_copy rather than build_variant_type_copy
That does seem weird.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109516
--- Comment #6 from Andrew Pinski ---
(In reply to Yann Droneaud from comment #4)
> (In reply to Andrew Pinski from comment #1)
> >
> > Basically GCC decided that the type of the bitfield uint48 has a type of
> > unsigned:48 and since it is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109516
--- Comment #5 from Andrew Pinski ---
(In reply to Yann Droneaud from comment #4)
>
> > While clang decided that the type is still unsigned long long.
>
> AFAICT, there's no unsigned long long involved in my example.
Sorry unsigned long.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109516
Yann Droneaud changed:
What|Removed |Added
CC||yann at droneaud dot fr
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109511
--- Comment #6 from CVS Commits ---
The master branch has been updated by Harald Anlauf :
https://gcc.gnu.org/g:fa4cb42870df60debdbd51e2ddc6d6ab9e6a
commit r13-7188-gfa4cb42870df60debdbd51e2ddc6d6ab9e6a
Author: Harald Anlauf
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109517
Bug ID: 109517
Summary: Failure to compile constexpr std::copy with
-D_GLIBCXX_DEBUG
Product: gcc
Version: 12.1.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109516
--- Comment #3 from Andrew Pinski ---
https://www.open-std.org/jtc1/sc22/WG14/www/docs/dr_120.html
is the defect report which makes this implementation defined really.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109516
--- Comment #2 from Andrew Pinski ---
Note C++ does not allow implementation defined behavior here, the type is
always the same across all implementations.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109516
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
See Also|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109492
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109516
Bug ID: 109516
Summary: warning: format '%lx' expects argument of type 'long
unsigned int', but argument 2 has type 'const long
unsigned int:48' [-Wformat=]
Product: gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109500
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Last reconfirmed||2023-04-14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109511
--- Comment #5 from Sébastien Villemot ---
Thanks for your work on this issue!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105800
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Ever confirmed|0 |1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109154
--- Comment #51 from Jakub Jelinek ---
Dumb untested patch which saves 2 instructions from each of those testcases:
--- gcc/tree-if-conv.cc.jj 2023-04-12 08:53:58.264496474 +0200
+++ gcc/tree-if-conv.cc 2023-04-14 21:02:42.403826690 +0200
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109511
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109154
--- Comment #50 from Jakub Jelinek ---
Anyway, given that in the sorting the last entry has the maximum number of
occurrences,
I think without trying to do more smarts best would be to avoid evaluating that
last condition for now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108910
Bug 108910 depends on bug 109510, which changed state.
Bug 109510 Summary: [13 Regression] bootstrap with Ada broken on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109510
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109510
Eric Botcazou changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109510
--- Comment #13 from CVS Commits ---
The master branch has been updated by Eric Botcazou :
https://gcc.gnu.org/g:94a21e008c4778e446321b1355f61abc75a076be
commit r13-7187-g94a21e008c4778e446321b1355f61abc75a076be
Author: Eric Botcazou
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109154
--- Comment #49 from Jakub Jelinek ---
Plus for 4+ args_len, if we don't find some smart sorting, we should still
consider at least some reassociation between the COND_EXPRs, instead of
emitting for 4 args_len
3 COND_EXPRs where second depends
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109154
--- Comment #48 from Jakub Jelinek ---
for PHIs with 3+ arguments unless all the arguments but one are the same even
when not doing any smarts seems we emit one more COND_EXPR from what we could.
The
/* Common case. */
case loop emits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109515
Andrew Pinski changed:
What|Removed |Added
Blocks||87403
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109515
Bug ID: 109515
Summary: Diagnostic request: warning on out-of-order structured
bindings names
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109009
--- Comment #5 from Surya Kumari Jangala ---
I was analysing and comparing the following test cases:
Test1 (shrink wrapped)
long
foo (long i, long cond)
{
i = i + 1;
if (cond)
bar ();
return i;
}
Test2 (not shrink wrapped)
long
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109511
--- Comment #3 from anlauf at gcc dot gnu.org ---
Created attachment 54860
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54860=edit
Patch
Patch I am testing.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109137
--- Comment #26 from Jan Hubicka ---
reverted the znver1-3 change on gcc-12 branch. We still may want to fix IRA to
avoid the problem on core_avx512 targets.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103931
--- Comment #16 from Bernhard Reutner-Fischer ---
> Under the assumption that we have a generic "c_ptr" in a module, we know (?)
> that "c_ptr" is not ambiguous.
>
> Is that right?
When we look at gmodule (when compiled when DModule has a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109137
--- Comment #25 from CVS Commits ---
The releases/gcc-12 branch has been updated by Jan Hubicka
:
https://gcc.gnu.org/g:9075b0f19eece7d5ddf948204507b5dae9d292c4
commit r12-9400-g9075b0f19eece7d5ddf948204507b5dae9d292c4
Author: Jan Hubicka
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109511
--- Comment #2 from anlauf at gcc dot gnu.org ---
It's even worse, as simplification for arguments X below one gives wrong
results:
set_exponent(0.75, 3)
gives 3., while the runtime version correctly prints 6.00
All gfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109514
Jason Merrill changed:
What|Removed |Added
Last reconfirmed||2023-04-14
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109507
Aran Clauson changed:
What|Removed |Added
Status|RESOLVED|CLOSED
--- Comment #4 from Aran Clauson
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109512
kargl at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109494
--- Comment #5 from Patrick Palka ---
(In reply to Patrick Palka from comment #4)
> I can't reproduce the linker warning or bad output with GCC 12.2 or trunk on
> x86_64-pc-linux-gnu:
>
> $ g++ -std=c++20 -fext-numeric-literals Main.ii Test.ii
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109514
Bug ID: 109514
Summary: [13 regression] -Werror=dangling-pointer false
positive nn fheroes-1.0.3 (lambdas)
Product: gcc
Version: 13.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108807
Jeffrey A. Law changed:
What|Removed |Added
CC||law at gcc dot gnu.org
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109494
Patrick Palka changed:
What|Removed |Added
CC||ppalka at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37336
Bug 37336 depends on bug 91316, which changed state.
Bug 91316 Summary: Derived type finalization failing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91316
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91316
Paul Thomas changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86754
Bug 86754 depends on bug 84472, which changed state.
Bug 84472 Summary: Missing finalization and memory leak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84472
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37336
Bug 37336 depends on bug 84472, which changed state.
Bug 84472 Summary: Missing finalization and memory leak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84472
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84472
Paul Thomas changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37336
Bug 37336 depends on bug 65347, which changed state.
Bug 65347 Summary: [F03] Final subroutine not called for function result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65347
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65347
Paul Thomas changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79416
Jan Hubicka changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109183
--- Comment #14 from Andreas Schwab ---
It doesn't make sense to use both -MM and -MD. Either you want to generate
only dependencies, then use -M or -MM (and -MF to redirect to a file). Or you
want to generate dependencies as side effect of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104272
Paul Thomas changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109509
--- Comment #5 from Jan Hubicka ---
For a summary
- PR109491 does not seem to be about integration time. most time is RTL PRE.
- PR108086 has 10% spent in integration and seems to be operand scan issue
- PR99785 is hard to judge given
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109160
--- Comment #5 from Vincent Saulue-Laborde
---
(In reply to Patrick Palka from comment #4)
> (In reply to Patrick Palka from comment #3)
> > Fixed for GCC 12 so far.
>
> GCC 13*
I confirm that gcc trunk works fine from my side.
Thanks for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109491
Jan Hubicka changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109509
--- Comment #4 from Richard Biener ---
when working on another testcase I noticed our inlining itself creates a lot of
garbage - copies can pile up, esp. when not optimizing. The PR79416 testcase
is similar than yours but using asm("nop") and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108086
Jan Hubicka changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109491
--- Comment #16 from Richard Biener ---
Just to make the point, for the testcase when compiling with -O -g I see
> grep 'INLINE_ENTRY' t.ii.031t.einline | wc -l
16976
> grep 'INLINE_ENTRY' t.ii.034t.ccp1 | wc -l
15530
> grep 'INLINE_ENTRY'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109513
Bug ID: 109513
Summary: Missed Dead Code Elimination when using
__builtin_unreachable
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109512
Bug ID: 109512
Summary: accepts implicit dummy procedure even with "implicit
none (external)"
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109509
Jan Hubicka changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109509
--- Comment #2 from Richard Biener ---
Possible issues specific to GCC that LLVM maybe avoids are:
Another probably more common with C++ code issue would be that we
inline into not optimized callers which means calls that are
almost trivially
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109183
--- Comment #13 from Allan W. Macdonald ---
Ahhh, so, "to get back the old behaviour" (as @ Richard Biener put it), this
seems to work (at least with my project):
%.d: %.c
gcc -MM -MD -dumpbase '' $<
Not obvious in the gcc 11.3.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109491
--- Comment #15 from rguenther at suse dot de ---
On Fri, 14 Apr 2023, chip.kerchner at ibm dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109491
>
> --- Comment #14 from Chip Kerchner ---
> Just one more question and then
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109509
--- Comment #1 from Chip Kerchner ---
Just for note: The same code that has heavy use always_inline compiles about
3X faster in LLVM and uses about 2X less memory to compile.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109491
--- Comment #14 from Chip Kerchner ---
Just one more question and then I'll switch to the new bug.
Would it help any if the functions that are "always_inline" be changed from
non-static to static?
Eigen's approach (where this code originally
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109511
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109510
--- Comment #12 from rsandifo at gcc dot gnu.org
---
(In reply to Eric Botcazou from comment #10)
> Created attachment 54859 [details]
> Tentative fix
>
> To be tested.
Thanks! This works for me locally and gives clean Ada test results.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109510
--- Comment #11 from Richard Biener ---
It might be possible to re-write the aarch64 assert to be instead
diff --git a/gcc/config/aarch64/aarch64.cc b/gcc/config/aarch64/aarch64.cc
index f4ef22ce02f..9da46a5e45d 100644
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108357
--- Comment #20 from rguenther at suse dot de ---
On Fri, 14 Apr 2023, xry111 at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108357
>
> --- Comment #18 from Xi Ruoyao ---
> (In reply to Richard Biener from comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108357
--- Comment #19 from chenglulu ---
(In reply to Xi Ruoyao from comment #18)
> (In reply to Richard Biener from comment #17)
> > Isn't this the same issue as seen in another bug, most targets defining
> > TARGET_PROMOTE_PROTOTYPES to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109507
--- Comment #3 from Jonathan Wakely ---
When you created this bug report there was a red banner at the top of the page
that begins by asking you to read https://gcc.gnu.org/bugs/ and that tells you
to try -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109510
--- Comment #10 from Eric Botcazou ---
Created attachment 54859
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54859=edit
Tentative fix
To be tested.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109510
--- Comment #9 from Eric Botcazou ---
> How do you get at the alignment the type would have when the user didn't
> specify it? That's what the call ABI is supposed to look at.
>
> /* 1 if the alignment for this type was requested by "aligned"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109510
--- Comment #8 from rsandifo at gcc dot gnu.org
---
(In reply to Jakub Jelinek from comment #7)
> In patch form what I wrote above (completely untested):
Sorry in advance for the overly verbose comment, but the timeline here was
that:
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108357
--- Comment #18 from Xi Ruoyao ---
(In reply to Richard Biener from comment #17)
> Isn't this the same issue as seen in another bug, most targets defining
> TARGET_PROMOTE_PROTOTYPES to hook_bool_const_tree_true but loongarch not?
> That will
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108357
--- Comment #17 from Richard Biener ---
Isn't this the same issue as seen in another bug, most targets defining
TARGET_PROMOTE_PROTOTYPES to hook_bool_const_tree_true but loongarch not?
That will cause those conversions to be missed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104272
--- Comment #6 from CVS Commits ---
The master branch has been updated by Paul Thomas :
https://gcc.gnu.org/g:b0e85485fbf042abccee5c0a9eb499da386c8db3
commit r13-7181-gb0e85485fbf042abccee5c0a9eb499da386c8db3
Author: Paul Thomas
Date: Fri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109510
--- Comment #7 from Jakub Jelinek ---
In patch form what I wrote above (completely untested):
--- gcc/config/aarch64/aarch64.cc.jj2023-04-14 09:15:08.470312336 +0200
+++ gcc/config/aarch64/aarch64.cc 2023-04-14 12:08:59.785137542
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109359
--- Comment #7 from Jakub Jelinek ---
For the safety net I'd compare TYPE_MODE of the SCALAR_FLOAT_TYPE_Ps, that is
what matters for those whether it is a noop conversion or needs actually some
runtime adjustment.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108357
--- Comment #16 from chenglulu ---
(In reply to rguent...@suse.de from comment #15)
> On Thu, 13 Apr 2023, xry111 at gcc dot gnu.org wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108357
> >
> > --- Comment #14 from Xi Ruoyao ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109359
--- Comment #6 from Richard Biener ---
output_constant gets called with
{(float) 1.91390279997419406754488591104745864868164062e-3, (float)
6.3053899606217215841752476990222930908203125e-1}
it then eventually does
/*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109359
--- Comment #5 from Jakub Jelinek ---
Ah, cp/constexpr.cc already uses fold_binary_initializer_loc if
-fconstexpr-fp-except.
That will turn the -frounding-math temporarily off for binary operations.
For this PR guess we need to use fold_init or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109510
--- Comment #6 from Eric Botcazou ---
> Btw, we're talking about non-aggregate types here.
Right, I agree that this is unexpected for them, let me investigate.
1 - 100 of 133 matches
Mail list logo
