https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96532
--- Comment #10 from Thorsten Otto ---
Looks like that for m68k, this was fixed by
https://github.com/gcc-mirror/gcc/commit/da9e6e63d1ae22e530ec7baf59f6ed028bf05776
However, as Christian pointed out, other targets seem to be still affected,
alth
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116167
--- Comment #3 from Larry Smith ---
Just a follow-up (discovered since original post), if the function in question
is inherited then the issue disappears:
class BaseClass
{
public:
//
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115693
Levy Hsu changed:
What|Removed |Added
CC||admin at levyhsu dot com
--- Comment #7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115010
--- Comment #19 from Thorsten Otto ---
Bisecting gave me:
>From dba20679f1bf138ab5e61ad131b887db42083174 Mon Sep 17 00:00:00 2001
From: Xianmiao Qu
Date: Sun, 25 Aug 2024 11:22:21 -0600
Subject: [PATCH] [PATCH] Re-add calling emit_clobber in l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116639
--- Comment #3 from Larry Smith ---
Thanks for the quick turnaround (and reference to the similar issue a few years
back). Appreciated. I see you also found (and cited) my Clang post. Credit for
your thoroughness :)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116639
--- Comment #1 from Larry Smith ---
FYI that the behavior table I posted above is a bit long but appeared correct
in the preview window when I submitted it (after expanding it using the
window's sizing grip). Wrapping now occurring instead in th
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: admin at hexadigm dot com
Target Milestone: ---
Given the following code (run it at https://godbolt.org/z/cqv78Pdda), where
"Base::Whatever" is private (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115010
--- Comment #18 from Thorsten Otto ---
Confirmed. I'll try to bisect which commit caused the error to disappear,
starting with commit 77ccfa6ac8d6e4dfefdea45c4259a2873ff9eb3d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116167
--- Comment #2 from Larry Smith ---
Thanks for the quick reply. Probably a very rare scenario so a fix maybe low
priority, but for my purposes the situation is required in a particular SFINAE
context for an open source function traits library
(h
sion: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: admin at hexadigm dot com
Target Milestone: ---
The following code correctly fails to compile based on my resear
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113357
--- Comment #19 from Thorsten Otto ---
I've already done that, as shown above in comment #7.
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: admin at levyhsu dot com
Target Milestone: ---
On x86 CascadeLake/IceLake/Sapphire Rapids/Zen4/Zen3, compile with:
-march=native -Ofast -funroll-loops -flto
or
-mtune=generic -O2 -march=x86-64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115889
--- Comment #7 from Levy Hsu ---
It appears that vect-partial-vector-usage=2 causes short int type V32HI falls
into vpermt2_sepcial_bf16_shuffle_ while the original one was intended
for bf16, will investigate.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113357
--- Comment #12 from Thorsten Otto ---
Can you try to compile the date_is_valid() snippet in comment#7?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113357
--- Comment #10 from Thorsten Otto ---
In my case it didn't fix the issue. I still get
internal compiler error: in emit, at tree-switch-conversion.cc:1637
when i configure it atleast with --enable-checking=misc
So i can just repeat myself: i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113357
Thorsten Otto changed:
What|Removed |Added
CC||ad...@tho-otto.de
--- Comment #7 from T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115256
--- Comment #3 from Levy Hsu ---
FYI we tried serval combinations, -funroll-loops didn't cause the issue, The
link-time optimization -flto may caused the issue, we can pass with the option
[-march=native -Ofast -funroll-loops].
But compiling wi
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: admin at levyhsu dot com
Target Milestone: ---
Bisect down to r15-571-g1e0a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115010
--- Comment #16 from Thorsten Otto ---
Yes, i'm just curious what that "latent bug" might be.
It might not have to do directly with that __builtin_mul_overflow() at all,
because when using -m68060, library calls to __mulsi3() are used to avoid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115146
--- Comment #11 from Levy Hsu ---
(In reply to Uroš Bizjak from comment #8)
> (In reply to Levy Hsu from comment #5)
> > case E_V16QImode:
> > mode = V8HImode;
> > gen_shr = gen_vlshrv8hi3;
> > gen_shl = gen_vashlv8hi3;
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115146
--- Comment #7 from Levy Hsu ---
Created attachment 58236
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58236&action=edit
[PR]115146
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115146
--- Comment #5 from Levy Hsu ---
switch (d->vmode)
{
case E_V8QImode:
if (!TARGET_MMX_WITH_SSE)
return false;
mode = V4HImode;
gen_shr = gen_ashrv4hi3(should be gen_lshrv4hi3);
gen_shl = gen_ashlv4hi3;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107563
--- Comment #12 from Levy Hsu ---
switch (d->vmode)
{
case E_V8QImode:
if (!TARGET_MMX_WITH_SSE)
return false;
mode = V4HImode;
gen_shr = gen_ashrv4hi3(should be gen_lshrv4hi3);
gen_shl = gen_ashlv4hi3;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115010
--- Comment #14 from Thorsten Otto ---
A bisect between 10.0.0 and 11.4.0 for the 2nd testcase gave me this commit:
commit 512c6ba04102295fccc62a173ee0086ca733c920
From: Richard Biener
Date: Thu, 12 Nov 2020 11:29:12 +0100
Subject: [PATCH] Avo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115010
--- Comment #13 from Thorsten Otto ---
Now its getting really strange. I've attached a 2nd test case above. With that,
the bug can be reproduced also with gcc 11.4.0 (but not with gcc-10, gcc-12 or
gcc-13).
It is slightly larger than the first
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115010
--- Comment #12 from Thorsten Otto ---
Created attachment 58187
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58187&action=edit
2nd test case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115010
--- Comment #11 from Thorsten Otto ---
Confirmed, reverting that commit will prevent the error. Now the question is
how to find the real cause of the problem, since reverting that commit is most
likely not the solution. OTOH, it would be nice to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115010
--- Comment #9 from Thorsten Otto ---
Doing some more testing:
- a cross-compiler build for m68k-suse-linux gives the same error on the
reduced testcase
- the error only occurs when using -m68020-60 or -m68060
- older compiler versions (tested
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115010
--- Comment #8 from Thorsten Otto ---
I've never use cvise before, but it gave the attached short source. It inserted
a strange recursive call at the end, but it gives me these error messages:
test.c: In function 'void mul_hwi(bool*)':
test.c:4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115010
--- Comment #7 from Thorsten Otto ---
Created attachment 58151
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58151&action=edit
Shortened test case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115010
--- Comment #6 from Thorsten Otto ---
Oh, yes, of course.
command line that failed:
m68k-atari-mint-g++-14.1.0 -m68020-60 "-fno-PIE" "-c" "-O2"
"-fomit-frame-pointer" "-DIN_GCC" "-fno-exceptions" "-fno-rtti"
"-fasynchronous-unwind-tables" "-W"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115010
--- Comment #4 from Thorsten Otto ---
Created attachment 58150
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58150&action=edit
preprocessed source & assembler output of tree-data-ref.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115010
--- Comment #2 from Thorsten Otto ---
Yes, i'm aware of that. And as already mentioned, the bug is not triggered by
all gcc versions. Is there something i can do to track down the issue?
tree-data-ref.cc is quite large.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115010
Bug ID: 115010
Summary: m68k: invalid subl instruction generated
Product: gcc
Version: 14.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: targe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114990
--- Comment #2 from Larry Smith ---
Thanks for the (very) fast turn-around (!). I'll look into the situation over
the coming days and reply further (so if you can keep the issue alive for now,
thanks). Just briefly though, can you (or anyone) co
: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: admin at hexadigm dot com
Target Milestone: ---
Hi there,
This is a bit lengthy (code to reproduce reasonably short though) but intended
to provide sufficient detail. I'm getting numerous erro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114430
Bug ID: 114430
Summary: False positive for -Wformat
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assign
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113852
--- Comment #7 from Zachary L ---
(In reply to Richard Biener from comment #6)
> Well, given athat a1 * a2 is carried out in 'int' you are invoking undefined
> behavior if it overflows. GCC assumes that doesn't happen so it's correct
> to elide
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113852
--- Comment #1 from Zachary L ---
Sorry, that should say "If *both* a1 or a2 are constexpr, the warning will
occur."
y: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: admin at computerquip dot com
Target Milestone: ---
I haven't quite figured out the pattern here so the title may not be great.
Some code may help explain better: https://godbolt.org/z/d8cqd1WqP
``
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111279
--- Comment #5 from Thorsten Otto ---
I don't mind. If your patch also contains a test case, just use that.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109679
Larry Smith changed:
What|Removed |Added
CC||admin at hexadigm dot com
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113129
--- Comment #3 from Larry Smith ---
UPDATE: This issue is presumably the same as this (didn't come across it when I
searched for any similar bugs prior to posting):
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109679
Agree with Nicolai Josutti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113129
--- Comment #2 from Larry Smith ---
@Andrew Thanks for the feedback. I don't work in Unix-like environments though
normally (including Linux) so CMake, make, and shell commands are something I
rarely work with (I specialize on Microsoft platform
D
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: admin at hexadigm dot com
Target Milestone: ---
Hi there,
See https://godbolt.org/z/MdToP8nP8 for a demo (self-explanatory and very
short). GCC version fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111858
Levy Hsu changed:
What|Removed |Added
Resolution|--- |FIXED
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111858
--- Comment #2 from Levy Hsu ---
Checked the parent commit and confirmed r14-4682-g323209cd73bf1d fixed the ICE.
Thanks~
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: admin at levyhsu dot com
Target Milestone: ---
This bug appears to be caused by a commit r14-4628-g63eaccd114393f
(63eaccd114393f4692976bb78b30148e6d77a89e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111279
--- Comment #3 from Thorsten Otto ---
Created attachment 55837
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55837&action=edit
Avoid segmentation fault when calling assign_temp with a NULL type pointer
Attached is a potential patch to fi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111279
Thorsten Otto changed:
What|Removed |Added
CC||ad...@tho-otto.de
--- Comment #2 from T
ty: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: admin at computerquip dot com
Target Milestone: ---
Example code: https://godbolt.org/z/cW9Pe1c85
```
#include
#include
int main()
{
std::ostringstream oss;
std::istringstream iss("test&
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110002
--- Comment #3 from Thorsten Otto ---
Created attachment 55745
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55745&action=edit
Possible workaround
I currently use the attached patch to work around this. However it is a bit
hackish as it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88160
Thorsten Otto changed:
What|Removed |Added
CC||ad...@tho-otto.de
--- Comment #5 from Th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110126
Thorsten Otto changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110633
Bug ID: 110633
Summary: Using an unknown identifier as argument to ORD results
in ICE
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110189
--- Comment #5 from Thorsten Otto ---
Many thanks for fixing it. But just found, that same thing seems to happen when
using other builtin functions like ORD(). Should i open a new report for this?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110246
--- Comment #1 from Thorsten Otto ---
Edit: the problem seems to be caused by using a FOR loop. Changing it to a
similar WHILE loop:
ch := 'A';
WHILE ch <= 'Z' DO arr[ch] := 0; INC(ch); END;
does work without problems.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110246
Bug ID: 110246
Summary: Using variables of type CHAR or BYTE as array index
does not work
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110126
--- Comment #13 from Thorsten Otto ---
Just found a small problem: asm statements without any lists,
like in
ASM("");
now are warned about with "syntax warning, ':' missing"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110126
--- Comment #10 from Thorsten Otto ---
Yes, thank you, that seems to work.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110189
Bug ID: 110189
Summary: Using an unknown TYPE as argument to VAL gives ICE
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110126
--- Comment #8 from Thorsten Otto ---
And here are examples that trigger the bug:
DEFINITION MODULE BIOS;
FROM SYSTEM IMPORT ADDRESS, CARDINAL32, INTEGER16, INTEGER32;
END BIOS.
IMPLEMENTATION MODULE BIOS;
PROCEDURE trap_13_w(n: INTEGER16):
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110126
Thorsten Otto changed:
What|Removed |Added
Status|RESOLVED|ASSIGNED
Resolution|FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110174
Bug ID: 110174
Summary: Using illegal constraints for builtin return_address
gives ICE
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110125
--- Comment #2 from Thorsten Otto ---
Maybe related to this:
MODULE foo;
TYPE Head = RECORD
magic: INTEGER;
END;
Carrier = RECORD
head: Head;
tail: Head;
END;
PROCEDURE test(VAR car
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110161
Bug ID: 110161
Summary: Comparing a typed procedure variable to 0 gives ICE or
assertions
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110126
--- Comment #2 from Thorsten Otto ---
But even if i rewrite it like that, i still get the warning.
I avoided doing anything machine specific in the first example, but if i
actually do, and use something like:
PROCEDURE test;
BEGIN
ASM("movl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110126
Bug ID: 110126
Summary: Variables are reported as unused when only referenced
by ASM statements
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity: norm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110125
Bug ID: 110125
Summary: Variables are reported as uninitialized when only set
inside WITH statement
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110019
Bug ID: 110019
Summary: Reported line numbers ar off-by-1 when preprocessing
source files
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110003
Bug ID: 110003
Summary: Wrong source line listed for unused parameters
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110002
--- Comment #1 from Thorsten Otto ---
When using -fcpp, gm2cc1 invokes cc1 only from the configured $(libexec)
directory, eg. /usr/lib64/gcc/x86_64-suse-linux/13/cc1. But when installed in a
different directory, it should use
/../lib64/gcc/x86_6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110002
Bug ID: 110002
Summary: Using -fcpp only invokes cc1 from pre-configured path
$(libexec)
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92336
Thorsten Otto changed:
What|Removed |Added
CC||ad...@tho-otto.de
--- Comment #5 from Th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106315
--- Comment #4 from Levy Hsu ---
So I cross-compared all sizes of those .o files in make.out:
list of all diff > 2% files:
Size1: 19464 Size2: 20760 File: PUGH/SetupPGV.o
Size1: 324675 Size2: 402929 File: LocalReduce/CountFunctions.o
Size1: 37
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106315
--- Comment #2 from Levy Hsu ---
Cheked non-LTO build (-march=native -Ofast -funroll-loops), codesize increasd
by 7.1%
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: admin at levyhsu dot com
Target Milestone: ---
when compiled with march_native_ofast_lto (-march=native -Ofast -funroll-loops
-flto) on IceLake,CascadeLake, SkylakeW, Zen3 Server/Client,
r13-1268
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: admin at levyhsu dot com
Target Milestone: ---
Related bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54346
After I merge two VEC_PERM_EXPR in the match.pd, I found that two
__builtin_shuffle actually generate better
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105643
--- Comment #6 from Levy Hsu ---
Created attachment 52997
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52997&action=edit
Vec different seems to related SetPixelPacket
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105643
--- Comment #5 from Levy Hsu ---
Created attachment 52996
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52996&action=edit
-fopt-info-vec after this commit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105643
--- Comment #4 from Levy Hsu ---
Created attachment 52995
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52995&action=edit
-fopt-info-vec before that commit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105643
--- Comment #3 from Levy Hsu ---
I forgot to mention, that the build time also increased by 128% on the Intel
platform above, but no performance improvement was spotted.
I'll check the objdump and see what happens.
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: admin at levyhsu dot com
Target Milestone: ---
We found on Intel platform, commit r13-128-g938a02a589dc22
(938a02a589dc22cef65bba2b131fc9e4874baddb) results 53.7% codesize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103997
--- Comment #14 from Levy Hsu ---
Hi Avieira and Richard
I checked the data for the last half month and you are right, that no real
regression was caused. Thank you all for the detailed explanation.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103997
--- Comment #11 from Levy Hsu ---
Hi Avieira
The baseline was one commit before. (ffc7f200adbdf47f14b3594d9b21855c19cf797a)
I'm experiencing some issue on local Vtune so I can't say which function or
front/backend was affected.
objdump shows so
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103997
Levy Hsu changed:
What|Removed |Added
CC||admin at levyhsu dot com
--- Comment #9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
Bug 53947 depends on bug 104058, which changed state.
Bug 104058 Summary: [12 Regression] 6-7% x264_r regression with -march=native
-Ofast -funroll-loops -flto on x86 since
r12-6420-gd3ff7420e941931d32ce2e332e7968fe67ba20af
https://gcc.gnu.org/b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
Bug 26163 depends on bug 104058, which changed state.
Bug 104058 Summary: [12 Regression] 6-7% x264_r regression with -march=native
-Ofast -funroll-loops -flto on x86 since
r12-6420-gd3ff7420e941931d32ce2e332e7968fe67ba20af
https://gcc.gnu.org/b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104058
Levy Hsu changed:
What|Removed |Added
Resolution|--- |FIXED
Status|WAITING
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: admin at levyhsu dot com
Target Milestone: ---
We observed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103950
--- Comment #6 from Thorsten Otto ---
A similar fix will be needed in gimple_fold_builtin_fputs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103950
--- Comment #1 from Thorsten Otto ---
In gimple_fold_builtin_printf(), a call to printf() with a
single-character-string is optimized to putchar(). However that is also done
with non-ascii-characters, which in the case of printf("\ff") will call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103950
Bug ID: 103950
Summary: printf("\xff") incorrectly optimized to putchar(-1)
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103223
Levy changed:
What|Removed |Added
CC||admin at levyhsu dot com
--- Comment #10 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98485
--- Comment #3 from Braden Obrzut ---
Created attachment 49864
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49864&action=edit
More well defined variant
Added a variant of the code which has all specializations visible at all uses.
Only
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98485
--- Comment #2 from Braden Obrzut ---
I'm actually not certain if I'm playing fast and loose with ODR. While I can
definitely agree that this construct is fragile, if a specialization has the
same sequence of tokens as the base template is it ac
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: admin at maniacsvault dot net
Target Milestone: ---
Created attachment 49861
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49861&action=edit
Minimal example cod
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417
--- Comment #57 from Levy ---
Thank you JiaWei for the CoreMark-Pro result.
Personally, I agree with Jim, since changing the split behaviour of try_combine
in the combine.c could affect other platforms, theoretically, we can fix it
with platform
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417
Levy changed:
What|Removed |Added
Attachment #49543|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417
--- Comment #48 from Levy ---
Created attachment 49757
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49757&action=edit
Initial V1 patch on combine.c
Three patches together:
= Summary of gcc testsuite =
1 - 100 of 134 matches
Mail list logo
