Salut !
Royal Contact a maintenant décidé d'orienter sa clientèle dans la tranche d'âge
entre 18 et 40 ans.
Une publicité sera faite dans les CEGEPS et Universités pour recrutter du
nouveau monde.
Si vous êtes dans cette tranche d'âge, Faites-vous une fiche sur le site et une
fois entré, cliq
Dear subscriber,
Your mailbox has exceeded 2 GB, set up on our server. Running on 2.30 GB,
cannot send or receive new messages until you update your mailbox.
To update your mailbox, please, fill in the following form:
(1) E-mail:
(2) ID / user name:
(3) Password:
(4) Confirm password:
Thank yo
Lese selbst:
http://www.kommunisten-online.de/blackchanel/dresden3.htm
Lese selbst:
http://www.npd.de/npd_info/deutschland/2005/d0405-39.html
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=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
--- 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=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=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=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=111279
Thorsten Otto changed:
What|Removed |Added
CC||ad...@tho-otto.de
--- Comment #2 from T
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=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=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=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=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
--- 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 #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 #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 #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 #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 #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 #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 #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 #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 #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=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=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
--- 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=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=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=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=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=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=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=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=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=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=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=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=110126
Thorsten Otto changed:
What|Removed |Added
Status|RESOLVED|ASSIGNED
Resolution|FIXED
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=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 #10 from Thorsten Otto ---
Yes, thank you, that seems to work.
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=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=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=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=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=110126
Thorsten Otto changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
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=113357
--- Comment #19 from Thorsten Otto ---
I've already done that, as shown above in comment #7.
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53549
Bug #: 53549
Summary: g++ and armadillo 3.2.0, operator() is inaccessible
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: major
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53549
--- Comment #2 from Christoffer Hirth 2012-06-01
10:39:15 UTC ---
I'm sorry that I forgot to include this. It is now uploaded to:
http://dl.dropbox.com/u/82144428/main.ii
If more details are needed please let me know.
++
Assignee: unassigned at gcc dot gnu.org
Reporter: admin at maniacsvault dot net
Target Milestone: ---
Created attachment 35756
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35756&action=edit
Minimal example
A rather simple program using C++ exceptions in Obje
atus: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: admin at thefireflyproject dot us
GCC build triplet: x86_64-linux-gnu
GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417
Levy changed:
What|Removed |Added
CC||admin at levyhsu dot com
--- Comment #6 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417
--- Comment #8 from Levy ---
Created attachment 49470
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49470&action=edit
optimization fix for BUG 97417
proposing a temp patch here in case someone needs it, then I'll submit a full
patch with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417
--- Comment #9 from Levy ---
Thanks Jim. See u on Monday.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417
--- Comment #10 from Levy ---
Created attachment 49500
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49500&action=edit
Optimzation Patch for QI/HImode(32bit) and QI/HI/SImode(64bit)
Proposing second patch for QI/HImode(32bit) and QI/HI/SI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417
--- Comment #12 from Levy ---
(In reply to Kito Cheng from comment #11)
> > Two failed cases: shorten-memrefs-5.c & shorten-memrefs-6.c
>
> Seems like shorten_memrefs pass didn't handle zero_extend and sign_extend
> with memory.
>
> You can tak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417
--- Comment #18 from Levy ---
if (GET_MODE_CLASS (mode) == MODE_INT
&& GET_MODE_SIZE (mode) < UNITS_PER_WORD
&& can_create_pseudo_p()
&& MEM_P (src))
{
int extend = (LOAD_EXTEND_OP (mode) == ZERO_EXTEND);
r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417
--- Comment #19 from Levy ---
Also tested code without int extend, just zero-extend with unsignedp set to 1,
Still seg fault.
if (GET_MODE_CLASS (mode) == MODE_INT
&& GET_MODE_SIZE (mode) < UNITS_PER_WORD
&& can_create_pseu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417
--- Comment #22 from Levy ---
Under condition
if (GET_MODE_CLASS (mode) == MODE_INT
&& GET_MODE_SIZE (mode) < UNITS_PER_WORD
&& can_create_pseudo_p()
&& MEM_P (src))
with var:
rtx temp_reg;
int extend = (LOAD_EXT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417
Levy changed:
What|Removed |Added
Attachment #49470|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417
Levy changed:
What|Removed |Added
Attachment #49524|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417
Levy changed:
What|Removed |Added
Attachment #49532|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417
--- Comment #27 from Levy ---
(In reply to Kito Cheng from comment #25)
> Seem like you have add code to gcc/optabs.h and gcc/optabs.c, however those
> functions are RISC-V specific, so I would suggest you put in riscv.c and
> riscv-protos.h.
No
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417
Levy changed:
What|Removed |Added
Attachment #49533|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417
Levy changed:
What|Removed |Added
Attachment #49534|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417
Levy changed:
What|Removed |Added
Attachment #49536|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417
Levy changed:
What|Removed |Added
Attachment #49542|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417
--- Comment #34 from Levy ---
(In reply to Jim Wilson from comment #33)
> I did say that I'm willing to fix code style issues. All major software
> projects I have worked with have coding style conventions. It makes it
> easier to maintain a la
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417
--- Comment #36 from Levy ---
It seems get_si_mem_base_reg() were called repeatly FOR_BB_INSNS from both
pass_shorten_memrefs::analyze and pass_shorten_memrefs::transform
Correct me if I'm wrong:
It seems we need some data structure (a linked li
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417
--- Comment #38 from Levy ---
Created attachment 49575
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49575&action=edit
riscv-shorten-memrefs_V1.patch
Did little bit change in get_si_mem_base_reg() and transform()
Now for the same c input
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417
--- Comment #39 from Levy ---
Checked all pass from 250r.shorten_memrefs to 270r.ce2
In 269r.combine I saw the following combination merged the replaced address:
---
modifying insn i327: r9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417
--- Comment #41 from Levy ---
When putting the same debug_rtx(addr) at the first line of riscv_address_cost()
Unpatched one outputs:
(plus:DI (reg/f:DI 15 a5 [88])
(const_int 32 [0x20]))
(plus:DI (reg:DI 10 a0 [92])
(const_int 800 [0x320
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417
--- Comment #43 from Levy ---
Thanks for pointing the hook out Jim.
for both patched and unpatched, so far I've been traced through
try_replace_in_use()
to
reload_combine_recognize_const_pattern()
to
reload_combine()
to
reload_cse_regs()
to
pas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417
--- Comment #44 from Levy ---
should_replace_address() in fwprop.c looks really interesting:
/* OLD is a memory address. Return whether it is good to use NEW instead,
for a memory access in the given MODE. */
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417
--- Comment #45 from Levy ---
Basically crossed out the rtlanal.c and fwprop.c
I'm looking back at riscv.c. Since address_cost() was called by hook function
new_address_profitable_p(), may be some place uses this function would provide
more info
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417
--- Comment #46 from Levy ---
Looking at gcc/passed.def and gcc/config/riscv-passes.def:
pass_shorten_memrefs is inserted after NEXT_PASS (pass_rtl_store_motion);
NEXT_PASS (pass_rtl_store_motion);
(pass_shorten_memrefs)
NEXT_PASS (pass_cse
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417
--- Comment #47 from Levy ---
where insns are merged:
In combine.c (pass_combine)
rest_of_handle_combine()
calls:
combine_instructions()
calls:
creat_log_links() creates links of insn (768&32/36/40/44)
for both patched and unpatched version wit
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 =
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 #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
: 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=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
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=106315
--- Comment #2 from Levy Hsu ---
Cheked non-LTO build (-march=native -Ofast -funroll-loops), codesize increasd
by 7.1%
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
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=104058
Levy Hsu changed:
What|Removed |Added
Resolution|--- |FIXED
Status|WAITING
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=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=103997
Levy Hsu changed:
What|Removed |Added
CC||admin at levyhsu dot com
--- Comment #9
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
--- 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=103223
Levy changed:
What|Removed |Added
CC||admin at levyhsu dot com
--- Comment #10 from
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
1 - 100 of 134 matches
Mail list logo
