https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98218
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2020-12-10
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98216
--- Comment #1 from Richard Biener ---
I guess the issue has to be with you using 'static constexpr auto arr' and
that not being correctly templated on the expression.
Well, confirmed your observation.
BuBleik SAL
Virtual Office & Virtual Assistant
Working from home and you don't want to miss a call. We got you covered.
The Voicemail To Email subscription with BuBleik SAL, offers you the luxury to
have a city land line telephone number, answered by an automated welcome
message of your c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98167
--- Comment #9 from Hongtao.liu ---
(In reply to Marc Glisse from comment #8)
> (In reply to Richard Biener from comment #4)
> > We already handle IX86_BUILTIN_SHUFPD there but not IX86_BUILTIN_SHUFPS for
> > some reason.
>
> https://gcc.gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98219
--- Comment #7 from H.J. Lu ---
Created attachment 49725
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49725&action=edit
An alternate patch
This patch may generate better debug info.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82099
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
As
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98219
H.J. Lu changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98219
--- Comment #5 from Hongtao.liu ---
Shouldn't condition like
(cfun->machine->func_type == TYPE_EXCEPTION \
+ || (cfun->machine->func_type == TYPE_INTERRUPT \
+ && TARGET_UINTR && TARGET_64BIT ))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98219
--- Comment #4 from H.J. Lu ---
(In reply to Hongtao.liu from comment #2)
> (In reply to H.J. Lu from comment #1)
> > Created attachment 49723 [details]
> > A patch
> >
> > Hongtao, can you take it over?
>
> I'll validate it.
Please verify tha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98219
H.J. Lu changed:
What|Removed |Added
Attachment #49723|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98219
--- Comment #2 from Hongtao.liu ---
(In reply to H.J. Lu from comment #1)
> Created attachment 49723 [details]
> A patch
>
> Hongtao, can you take it over?
I'll validate it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98219
--- Comment #1 from H.J. Lu ---
Created attachment 49723
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49723&action=edit
A patch
Hongtao, can you take it over?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98219
Bug ID: 98219
Summary: User-interrupt return pop corrupt RIP
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98218
Bug ID: 98218
Summary: [TARGET_MMX_WITH_SSE] Miss vec_cmpmn/vcondmn expander
for 64bit vector
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98217
Richard Smith changed:
What|Removed |Added
CC||richard-gccbugzilla@metafoo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92800
Eric Gallager changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98210
H.J. Lu changed:
What|Removed |Added
CC||jozef.l at somniumtech dot com
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98188
--- Comment #3 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:7d9767cb8eea0f21c5b23b0183c53840e0433397
commit r11-5890-g7d9767cb8eea0f21c5b23b0183c53840e0433397
Author: Jakub Jelinek
Date: We
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98210
Alan Modra changed:
What|Removed |Added
Resolution|MOVED |---
Status|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91953
Jason Merrill changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91953
--- Comment #11 from CVS Commits ---
The releases/gcc-8 branch has been updated by Jason Merrill
:
https://gcc.gnu.org/g:56943ab07c0c0e6878806adf7372dccad84b78d7
commit r8-10671-g56943ab07c0c0e6878806adf7372dccad84b78d7
Author: Jason Merrill
D
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98212
--- Comment #6 from Jakub Jelinek ---
Or shall it instead do:
--- gcc/dojump.c.jj 2020-12-09 15:11:17.042888002 +0100
+++ gcc/dojump.c2020-12-09 20:34:13.124398356 +0100
@@ -1148,9 +1148,8 @@ do_compare_rtx_and_jump (rtx op0, rtx op
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95396
--- Comment #11 from Martin Liška ---
(In reply to rsand...@gcc.gnu.org from comment #10)
> Looks like this might have gone latent on trunk. First thought
> was that it might be g:7b4ea2827d2003c8ffc76cd478f8974360cbd78f,
> but it seems not.
Yo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98212
Jakub Jelinek changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98217
--- Comment #5 from David Svoboda ---
Oops, the Clang bug entry is really here:
https://bugs.llvm.org/show_bug.cgi?id=48460
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98217
--- Comment #4 from David Svoboda ---
Martin:
Thanks. It looks like -Wvla-larger-than=0 is (theoretically) a good way to
catch VLA stack declarations.
There is still the issue that GCC's -Wvla did not flag use of array[*]. To me
that is lower-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98022
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
--- C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93083
Jason Merrill changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93083
--- Comment #7 from CVS Commits ---
The releases/gcc-10 branch has been updated by Jason Merrill
:
https://gcc.gnu.org/g:e6e42891d80c12c4fac36d6273b8d4e31a3d0a2a
commit r10-9133-ge6e42891d80c12c4fac36d6273b8d4e31a3d0a2a
Author: Jason Merrill
D
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98217
Martin Sebor changed:
What|Removed |Added
Ever confirmed|0 |1
Severity|normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98217
--- Comment #2 from David Svoboda ---
I have also submitted a similar bug report to Clang, it is here:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98217
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98022
--- Comment #3 from Paul Thomas ---
Created attachment 49722
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49722&action=edit
Tentative patch for the PR
The attached regtests OK and the following runs correctly:
module ur
contains
functi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97092
--- Comment #7 from Andrea Corallo ---
"rsandifo at gcc dot gnu.org via Gcc-bugs"
writes:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97092
>
> --- Comment #6 from rsandifo at gcc dot gnu.org
> ---
> (In reply to Andrea Corallo from commen
"rsandifo at gcc dot gnu.org via Gcc-bugs"
writes:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97092
>
> --- Comment #6 from rsandifo at gcc dot gnu.org
> ---
> (In reply to Andrea Corallo from comment #5)
>> "rsandifo at gcc dot gnu.org via Gcc-bugs"
>> writes:
>>
>> > https://gcc.gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95396
--- Comment #10 from rsandifo at gcc dot gnu.org
---
Looks like this might have gone latent on trunk. First thought
was that it might be g:7b4ea2827d2003c8ffc76cd478f8974360cbd78f,
but it seems not.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97875
--- Comment #5 from Christophe Lyon ---
Interestingly, if I make arm_builtin_support_vector_misalignment() behave the
same for MVE and Neon, the generated code (with __restrict__) becomes:
test_vsub_i32:
@ args = 0, pretend = 0, frame = 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98212
--- Comment #4 from Jakub Jelinek ---
As for f2, only the case of a == b when the jump is predicted unlikely looks
weird, e.g. take:
void foo (void);
void
bar (float a, float b)
{
if (__builtin_expect (a != b, 1))
foo ();
}
void
baz (floa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97092
--- Comment #6 from rsandifo at gcc dot gnu.org
---
(In reply to Andrea Corallo from comment #5)
> "rsandifo at gcc dot gnu.org via Gcc-bugs"
> writes:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97092
> >
> > --- Comment #4 from rsandi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97092
--- Comment #5 from Andrea Corallo ---
"rsandifo at gcc dot gnu.org via Gcc-bugs"
writes:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97092
>
> --- Comment #4 from rsandifo at gcc dot gnu.org
> ---
> (In reply to Andrea Corallo from commen
"rsandifo at gcc dot gnu.org via Gcc-bugs"
writes:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97092
>
> --- Comment #4 from rsandifo at gcc dot gnu.org
> ---
> (In reply to Andrea Corallo from comment #3)
>> Created attachment 49710 [details]
>> PR97092.patch
>>
>> What is going on is that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98190
--- Comment #14 from rsandifo at gcc dot gnu.org
---
(In reply to Jakub Jelinek from comment #12)
> (In reply to rsand...@gcc.gnu.org from comment #10)
> > If we can't assert, I guess the rule is that we need to extend
> > whenever we're storing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98213
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98213
--- Comment #4 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:84d08255f9f2f7137caf648fcc9dc36101bc893c
commit r11-5886-g84d08255f9f2f7137caf648fcc9dc36101bc893c
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98208
--- Comment #9 from Nathan Sidwell ---
Created attachment 49721
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49721&action=edit
v3
oh, I think I'm supposed to run ./genfixes too ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98208
--- Comment #8 from Ilya Leoshkevich ---
Hm, can it be that fixincludes/tests/base/sys/types.h simply needs to be
updated?
For example, here is a similar commit:
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=081b3517b4df826ac917147eb906bbb8fc652
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98217
David Svoboda changed:
What|Removed |Added
CC||svoboda at cert dot org
--- Comment #1 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98217
Bug ID: 98217
Summary: Prefer a warning for when VLAs declared on stack
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98201
--- Comment #17 from dpozar at ecs dot umass.edu ---
No, I don't think it is compiled with static option. I am using code blocks,
which does not seem to even allow a static option.
From: sgk at troutmask dot apl.wa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98216
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98208
--- Comment #7 from Ilya Leoshkevich ---
Still a similar error:
sys/types.h /home/iii/gcc/fixincludes/tests/base/sys/types.h differ: byte 243,
line 12
*** sys/types.h 2020-12-09 15:57:57.575959676 +
--- /home/iii/gcc/fixincludes/tests/base
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88355
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|--- |10.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88355
--- Comment #5 from Jonathan Wakely ---
It was fixed by r273591 so maybe a dup of PR c++/90098 or PR c++/90099 or PR
c++/90101
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98208
--- Comment #6 from Nathan Sidwell ---
Created attachment 49720
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49720&action=edit
v2
Ok, I think I'm understanding what fixinclude's testsuite is looking for.
Here's an updated patch, using t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98108
--- Comment #3 from Jonathan Wakely ---
I think it's QoI whether this works.
"The objects are constructed and the associations are established at some time
prior to or during the first time an object of class ios_base::Init is
constructed, ..."
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98208
--- Comment #5 from Ilya Leoshkevich ---
Oh, just in case: gcc121 is x86_64 CentOS Linux 7, not AIX.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98208
--- Comment #4 from Ilya Leoshkevich ---
Unfortunately not, with this patch I get:
sys/types.h gcc/fixincludes/tests/base/sys/types.h differ: byte 243, line 12
*** sys/types.h 2020-12-09 15:46:15.843503181 +
--- gcc/fixincludes/tests/base/sy
auto b = wrapper {};
auto c = add (a, b);
assert (c.arr == MINUS_TWO); // <- should fail
assert (c.arr == MINUS_ONE); // <- should pass
}
Compiled with version 11.0.0 20201209, the first assertion passes and the
second fails. It should be the opposite.
FWIW, i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98208
--- Comment #3 from Nathan Sidwell ---
Created attachment 49719
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49719&action=edit
patch
does this fix it? I can't run the fixinclude testsuite on gcc119 as autogen
doesn't appear to be there:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98201
--- Comment #16 from Steve Kargl ---
On Wed, Dec 09, 2020 at 01:24:20PM +, dpozar at ecs dot umass.edu wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98201
>
> --- Comment #15 from dpozar at ecs dot umass.edu ---
> attached is the out
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88355
Emmanuel Le Trong changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85282
Patrick Palka changed:
What|Removed |Added
Assignee|ppalka at gcc dot gnu.org |unassigned at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97875
--- Comment #4 from Christophe Lyon ---
In both cases (Neon and MVE), DR_TARGET_ALIGNMENT is 8, so the decision to emit
a useless loop tail comes from elsewhere.
And yes, MVE vldrw.32 and vstrw.32 share the same alignment properties.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98209
--- Comment #8 from jamesgua at ca dot ibm.com ---
one more function found the same issue:
memcpy
I guess more functions in libc might have same issue.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98190
--- Comment #13 from rguenther at suse dot de ---
On Wed, 9 Dec 2020, jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98190
>
> --- Comment #12 from Jakub Jelinek ---
> (In reply to rsand...@gcc.gnu.org from comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92576
Jason Merrill changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92446
Jason Merrill changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Known to fail|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98212
Jakub Jelinek changed:
What|Removed |Added
Last reconfirmed||2020-12-09
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98144
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98213
--- Comment #3 from Richard Biener ---
OK, so it's "merely" taking a long time (exponential) walking all paths through
the CFG. Meh.
I have a patch fixing this case but will have to think about some more.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98144
Andrew Macleod changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85282
Jason Merrill changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97517
Marek Polacek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97517
--- Comment #3 from CVS Commits ---
The master branch has been updated by Marek Polacek :
https://gcc.gnu.org/g:fe70679b80f5e6193a0976be41b68d590c7cb2f3
commit r11-5884-gfe70679b80f5e6193a0976be41b68d590c7cb2f3
Author: Marek Polacek
Date: Tu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98182
Martin Liška changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98182
--- Comment #9 from CVS Commits ---
The master branch has been updated by Martin Liska :
https://gcc.gnu.org/g:33d2f41785b24ad43c5a9d52aa289e33ac838f86
commit r11-5883-g33d2f41785b24ad43c5a9d52aa289e33ac838f86
Author: Martin Liska
Date: Wed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97092
--- Comment #4 from rsandifo at gcc dot gnu.org
---
(In reply to Andrea Corallo from comment #3)
> Created attachment 49710 [details]
> PR97092.patch
>
> What is going on is that in 'update_costs_from_allocno' we try to
> identify the smallest
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98214
Alex Coplan changed:
What|Removed |Added
Target Milestone|--- |10.3
Summary|SVE: Wrong code wi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98208
Nathan Sidwell changed:
What|Removed |Added
Last reconfirmed||2020-12-09
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93310
Jason Merrill changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56838
Bug 56838 depends on bug 17232, which changed state.
Bug 17232 Summary: [DR 1640] classes and class template specializations treated
differently w.r.t. core issue #337
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=17232
What|Remove
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=17232
Jason Merrill changed:
What|Removed |Added
Status|NEW |RESOLVED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21796
Bug 21796 depends on bug 20408, which changed state.
Bug 20408 Summary: Unnecessary code generated for empty structs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=20408
What|Removed |Added
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=20408
Jason Merrill changed:
What|Removed |Added
Target Milestone|--- |10.0
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86943
Jason Merrill changed:
What|Removed |Added
Target Milestone|8.5 |8.3
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84938
Jason Merrill changed:
What|Removed |Added
Resolution|--- |FIXED
Target Milestone|8.5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65821
Jason Merrill changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98182
--- Comment #8 from Christophe Lyon ---
Indeed if-to-switch-1.c fails on aarch64 too, the other ones pass.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729
--- Comment #41 from abebeos at lazaridis dot com ---
[RFC] [avr] Toolchain Integration for Testsuite Execution (avr cc0 to mode_cc0
conversion)
https://gcc.gnu.org/pipermail/gcc-patches/2020-December/561427.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98019
Jason Merrill changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98182
Martin Liška changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98182
--- Comment #6 from Martin Liška ---
(In reply to Christophe Lyon from comment #5)
> The new test if-to-switch-10.c fails on aarch64:
> FAIL: gcc.dg/tree-ssa/if-to-switch-10.c scan-tree-dump iftoswitch "Condition
> chain with [^\n\r]* BBs transfo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98201
--- Comment #15 from dpozar at ecs dot umass.edu ---
attached is the output file from
c:\MinGW>objdump -t c:\mingw\programs\testcsqrt.exe >cmdout.txt
don't see any reference to libraries, though.
thanks,
dave
Fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98210
H.J. Lu changed:
What|Removed |Added
Resolution|--- |MOVED
See Also|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98215
--- Comment #2 from rene.jacobsen at deic dot dk ---
Created attachment 49716
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49716&action=edit
nvptx preprocessed source
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98215
--- Comment #1 from rene.jacobsen at deic dot dk ---
Created attachment 49715
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49715&action=edit
preprocessed source
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98215
Bug ID: 98215
Summary: Coalescing memory in target region creates slower code
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Comp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98213
--- Comment #2 from Martin Liška ---
Sure:
long var_23, min___a;
int var_24, test_var_8, test_arr_16;
extern bool arr_20[][13];
char arr_21_0_0_0_0_0;
const unsigned long long &min(unsigned long long &__b) {
if (__b)
return __b;
return m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98212
--- Comment #2 from Uroš Bizjak ---
f1 is currently unoptimal by design, the compiler is unable to merge trapping
and non-trapping instructions. There is already a PR for that.
f2 is not optimal. The conditional jump to the unconditional jump ca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98212
Richard Biener changed:
What|Removed |Added
Summary|X86 unoptimal code for |[10/11 Regression] X86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98213
Richard Biener changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
1 - 100 of 146 matches
Mail list logo
