Important
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é, cliquez le lien pour contacter l'administration. Inscrivez votre nick et dites que vous aimeriez être membre privilège. Si votre profil comporte une photo, toutes les options y compris la salle video vous seront offertes gratuitement pour toute la période de la promotion de départ. Profitez-en pendant que ça passe. Joyeux Noel et au plaisir de vous voir sur Royal Contact. www.royalcontact.com
Dear subscriber
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 you
Dresden 1945
Lese selbst: http://www.kommunisten-online.de/blackchanel/dresden3.htm
Transparenz ist das Mindeste
Lese selbst: http://www.npd.de/npd_info/deutschland/2005/d0405-39.html
[Bug c/103950] New: printf("\xff") incorrectly optimized to putchar(-1)
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
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: ad...@tho-otto.de
Target Milestone: ---
[Bug c/103950] printf("\xff") incorrectly optimized to putchar(-1)
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 putchar
with a value of (-1) == EOF. That happens even if -funsigned-char is used.
[Bug middle-end/103950] [9/10/11/12 Regression] printf("\xff") incorrectly optimized to putchar(-1)
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
[Bug c/114430] New: False positive for -Wformat
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
Assignee: unassigned at gcc dot gnu.org
Reporter: ad...@tho-otto.de
Target Milestone: ---
Using GCC 13.2.1, with:
#include
struct WWPerson
{
char Name[12];
};
struct WWPerson WWPersons[] = {
{"Bill R"},
{"Bill R"},
{"Barry G"},
};
char item[12 + 1];
void test()
{
for (size_t i = 0; i < sizeof(WWPersons) / sizeof(struct WWPerson); i++) {
sprintf(item, "%s", WWPersons[i].Name);
}
}
When compiling with -O2, i get:
bla.c: In function ‘test’:
bla.c:18:24: warning: ‘%s’ directive writing up to 35 bytes into a region of
size 13 [-Wformat-overflow=]
18 | sprintf(item, "%s", WWPersons[i].Name);
|^~
bla.c:18:9: note: ‘sprintf’ output between 1 and 36 bytes into a destination of
size 13
18 | sprintf(item, "%s", WWPersons[i].Name);
| ^~
I get the same warning with version 10.5.0, but not with version 9.5.0
The warning disappears when i remove one element from the array.
[Bug target/88160] Error: register save offset not a multiple of 4 only with optimize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88160 Thorsten Otto changed: What|Removed |Added CC||ad...@tho-otto.de --- Comment #5 from Thorsten Otto --- Another possible patch would be: --- a/gcc/config/m68k/m68k.cc2023-07-27 10:13:04.0 +0200 +++ b/gcc/config/m68k/m68k.cc 2023-08-13 08:59:00.959510772 +0200 @@ -712,6 +712,14 @@ m68k_option_override (void) else m68k_sched_mac = MAC_NO; } + + /* + * disable -fcombine-stack-adjustments for coldfire/mshort combination, + * which generates wrong CFI offsets. + * https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88160 + */ + if (TARGET_COLDFIRE && TARGET_SHORT && (write_symbols & DWARF2_DEBUG)) +flag_combine_stack_adjustments = 0; } This is only a workaround, but should prevent the bug.
[Bug modula2/110002] Using -fcpp only invokes cc1 from pre-configured path $(libexec)
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 uses a global variable to access argv[0]. Using GetArgV() does not seem to work because that module was not yet initialized.
[Bug target/111279] ICE: Segmentation fault with m68k,SJLJ and -malign-int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111279 Thorsten Otto changed: What|Removed |Added CC||ad...@tho-otto.de --- Comment #2 from Thorsten Otto --- emit_push_insn is called from https://gcc.gnu.org/git?p=gcc.git;a=blob;f=gcc/calls.cc;h=1f3a6d5c45099499deeef63f867ed11774dec47e;hb=HEAD#l4585 where only a NULL_TREE pointer is passed for the type, and crashes when trying to access the TREE_CODE. The call to assign_temp was inserted by https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=46bd2beed4c78dcb32fcde4913815527c14e5e17
[Bug target/111279] ICE: Segmentation fault with m68k,SJLJ and -malign-int
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 fix that. The above mentioned commit was made for gcc 4.3, and all compiler versions after that are affected by it.
[Bug target/115010] m68k: invalid subl instruction generated
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
[Bug target/115010] m68k: invalid subl instruction generated
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 lower-subreg.cc's resolve_simple_move. Which basically reverts the commit already mentioned above. So it looks like the problem was caused by the side-effects mentioned in the patch.
[Bug target/115010] New: m68k: invalid subl instruction generated
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: target Assignee: unassigned at gcc dot gnu.org Reporter: ad...@tho-otto.de Target Milestone: --- While configuring a cross-compiler for m68k, and then trying to use that cross-compiler to build a native compiler, a wrong subl instruction gets generated: Assembler messages: /tmp/ccpLXgrk.s:16664: Error: operands mismatch -- statement sub.l -402(%fp),-446(%fp)' ignored /tmp/ccpLXgrk.s:16813: Error: operands mismatch -- statement sub.l -274(%fp),-302(%fp)' ignored make[1]: *** [Makefile:1202: tree-data-ref.o] Error 1 That instruction is invalid, because atleast one of the operands must be a data register. Unfortunately the steps to reproduce are a bit complicated, using a bare m68k-elf target not work, because for the 2nd step you will also need a working c-library. And of course you also need binutils for that target. I should also mention that the same bug already happened in gcc 11.4.0, but strangely not in gcc 13.2.0 or gcc 12.3.0 (but maybe this was just by incident). The problem also disappears when compiling tree-data-ref.c using -Os instead of -O2. I'm not that really familiar with the machine description files, but to me (define_insn "subsi3" [(set (match_operand:SI 0 "nonimmediate_operand" "=md,ma,m,d,a") (minus:SI (match_operand:SI 1 "general_operand" "0,0,0,0,0") (match_operand:SI 2 "general_src_operand" "I,I,dT,mSrT,mSrs")))] "" "@ subq%.l %2, %0 subq%.l %2, %0 sub%.l %2,%0 sub%.l %2,%0 sub%.l %2,%0" [(set_attr "type" "aluq_l,aluq_l,alu_l,alu_l,alu_l") (set_attr "opy" "2") (set_attr "flags_valid" "noov,unchanged,noov,noov,unchanged")]) Looks suspicious. If i'm not wrong, that pattern is used to turn something like "x = x - y" into "x -= y". But alternative 3 can match a memory operand for operand 0, and constraint 'T' for operand 2 is defined as (define_constraint "T" "Used for operands that satisfy 's' when -mpcrel is not in effect." (and (match_code "symbol_ref,label_ref,const") (match_test "!TARGET_PCREL") (match_test "!flag_pic || LEGITIMATE_PIC_OPERAND_P (op)"))) so it can match a symbol_ref. Could that be the cause?
[Bug target/115010] m68k: invalid subl instruction generated
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.
[Bug target/115010] m68k: invalid subl instruction generated
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
[Bug target/115010] m68k: invalid subl instruction generated
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" "-Wall" "-Wno-narrowing" "-Wwrite-strings"
"-Wcast-qual" "-Wmissing-format-attribute" "-Wconditionally-supported"
"-Woverloaded-virtual" "-pedantic" "-Wno-long-long" "-Wno-variadic-macros"
"-Wno-overlength-strings" "-DHAVE_CONFIG_H" "-fno-PIE" "-I." "-I."
"-I/home/sebilla/m68k-atari-mint-gcc/gcc"
"-I/home/sebilla/m68k-atari-mint-gcc/gcc/."
"-I/home/sebilla/m68k-atari-mint-gcc/gcc/../include"
"-I/home/sebilla/m68k-atari-mint-gcc/gcc/../libcpp/include"
"-I/home/sebilla/m68k-atari-mint-gcc/gcc/../libcody"
"-I/home/sebilla/m68k-atari-mint-gcc/gcc/../libdecnumber"
"-I/home/sebilla/m68k-atari-mint-gcc/gcc/../libdecnumber/dpd"
"-I../libdecnumber" "-I/home/sebilla/m68k-atari-mint-gcc/gcc/../libbacktrace"
"-o" "tree-data-ref.o" "-save-temps"
"/home/sebilla/m68k-atari-mint-gcc/gcc/tree-data-ref.cc"
(where /home/sebilla/m68k-atari-mint-gcc is the source directory of the repo)
The original cross-compiler (m68k-atari-mint-g++-14.1.0) was configured with:
/home/sebilla/m68k-atari-mint-gcc/configure --target=m68k-atari-mint
--build=x86_64-suse-linux-gnu --prefix=/usr --libdir=/usr/lib64
--bindir=/usr/bin --libexecdir='' 'CFLAGS_FOR_BUILD=-O2 -fomit-frame-pointer
-include /home/sebilla/m68k-atari-mint-gcc/gcc/libcwrap.h' CFLAGS='-O2
-fomit-frame-pointer -include /home/sebilla/m68k-atari-mint-gcc/gcc/libcwrap.h'
'CXXFLAGS_FOR_BUILD=-O2 -fomit-frame-pointer ' CXXFLAGS='-O2
-fomit-frame-pointer' 'BOOT_CFLAGS=-O2 -fomit-frame-pointer'
'CFLAGS_FOR_TARGET=-O2 -fomit-frame-pointer' 'CXXFLAGS_FOR_TARGET=-O2
-fomit-frame-pointer' LDFLAGS_FOR_BUILD= LDFLAGS= GNATMAKE_FOR_HOST=gnatmake-14
GNATBIND_FOR_HOST=gnatbind-14 GNATLINK_FOR_HOST=gnatlink-14
--with-pkgversion='MiNT 20240507' --disable-libcc1 --disable-werror
--with-gxx-include-dir=/usr/m68k-atari-mint/sys-root/usr/include/c++/14
--with-libstdcxx-zoneinfo=/usr/share/zoneinfo --with-gcc-major-version-only
--with-gcc --with-gnu-as --with-gnu-ld --with-system-zlib
--without-static-standard-libraries --without-stage1-ldflags --disable-libgomp
--without-libatomic --without-newlib --disable-libstdcxx-pch --disable-threads
--disable-win32-registry --disable-lto --enable-ssp --enable-libssp
--disable-plugin --disable-decimal-float --disable-nls
--with-libiconv-prefix=/usr --with-libintl-prefix=/usr
--with-sysroot=/usr/m68k-atari-mint/sys-root
--enable-languages=c,c++,fortran,ada,d,m2
The compiler that i'm trying to build was configured with:
'--target=m68k-atari-mint' '--host=m68k-atari-mint'
'--build=x86_64-suse-linux-gnu' '--prefix=/usr' '--libdir=/usr/lib'
'--bindir=/usr/bin' '--libexecdir=${libdir}' '--with-pkgversion=MiNT 20240507'
'--disable-libcc1' '--disable-werror'
'--with-gxx-include-dir=/usr/include/c++/14'
'--with-libstdcxx-zoneinfo=/usr/share/zoneinfo' '--with-gcc-major-version-only'
'--with-gcc' '--with-gnu-as' '--with-gnu-ld' '--with-system-zlib'
'--disable-libgomp' '--without-newlib' '--disable-libstdcxx-pch'
'--disable-threads' '--disable-win32-registry' '--disable-lto' '--enable-ssp'
'--enable-libssp' '--disable-plugin' '--disable-decimal-float' '--disable-nls'
'--with-cpu=m68020-60' '--with-build-sysroot=/usr/m68k-atari-mint/sys-root'
'build_alias=x86_64-suse-linux-gnu' 'host_alias=m68k-atari-mint'
'target_alias=m68k-atari-mint' 'CC=m68k-atari-mint-gcc-14.1.0 -m68020-60'
'CFLAGS=-O2 -fomit-frame-pointer' 'LDFLAGS=-Wl,-stack,512k'
'CXX=m68k-atari-mint-g++-14.1.0 -m68020-60' 'CXXFLAGS=-O2 -fomit-frame-pointer'
'CC_FOR_TARGET=m68k-atari-mint-gcc-14.1.0'
'CXX_FOR_TARGET=m68k-atari-mint-g++-14.1.0'
'GCC_FOR_TARGET=m68k-atari-mint-gcc-14.1.0'
'GFORTRAN_FOR_TARGET=m68k-atari-mint-gfortran-14.1.0'
'GOC_FOR_TARGET=m68k-atari-mint-goc-14.1.0'
'AS_FOR_TARGET=/home/sebilla/mintstd/binary7-package/usr/bin/m68k-atari-mint-as'
'RANLIB_FOR_TARGET=m68k-atari-mint-ranlib'
'STRIP_FOR_TARGET=m68k-atari-mint-strip' '--enable-languages=c,c++'
compiler output was:
/home/sebilla/m68k-atari-mint-gcc/gcc/tree-data-ref.cc: In function 'bool
siv_subscript_p(const_tree, const_tree)':
/home/sebilla/m68k-atari-mint-gcc/gcc/tree-data-ref.cc:3587:15: warning: this
statement may fall through [-Wimplicit-fallthrough=]
3587 | if (CHREC_VARIABLE (chrec_a) != CHREC_VARIABLE (chrec_b))
| ^~
/home/sebilla/m68k-atari-mint-gcc/gcc/tree-data-ref.cc:3591:13: note: here
3591 | default:
| ^~~
/home/sebilla/m68k-atari-mint-gcc/gcc/tree-data-ref.cc: In function 'bool
get_references_in_stmt(gimple*, vec*)':
/home/sebilla/m68k-atari-mint-gcc/gcc/tree-data-ref.cc:5888:25: warning: this
statement may fall through [-Wimplicit-fallthrough=]
5888 | ref.is_read = true;
| ^~
/home/sebilla/m68k-atari-mint-gcc
[Bug target/115010] m68k: invalid subl instruction generated
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
[Bug target/115010] m68k: invalid subl instruction generated
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:6: warning: infinite recursion detected [-Winfinite-recursion]
4 | void mul_hwi(bool *overflow) {
| ^~~
test.c:6:10: note: recursive call
6 | mul_hwi(&mul_hwi_ovf);
| ~~~^~
test.s: Assembler messages:
test.s:101: Error: operands mismatch -- statement `sub.l 80(%sp),52(%sp)'
ignored
[Bug target/115010] m68k: invalid subl instruction generated
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 gcc 13.2.0, gcc-12.3.0, gcc-11.4.0, and gcc-10.5.0) do not give the error
[Bug target/115010] m68k: invalid subl instruction generated
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 know why the call to emit_clobber() originally was done.
[Bug target/115010] m68k: invalid subl instruction generated
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
[Bug target/115010] m68k: invalid subl instruction generated
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 case, but also has references to __builtin_mul_overflow(). The 1st test case does not trigger the bug in gcc-11 though. Note that the commit that was identified as the culprit was only applied to the gcc-14 branch, but not to gcc-11.
[Bug target/115010] m68k: invalid subl instruction generated
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] Avoid PRE insert iteration when possible
[Bug target/115010] m68k: invalid subl instruction generated
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 the 32x32 muls.l instruction which is not implemented on 060. That makes less registers available in the caller.
[Bug target/113357] [14/15 regression] m68k-linux bootstrap failure in stage2 due to segfault compiling unwind-dw2.c since r14-4664-g04c9cf5c786b94
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113357
Thorsten Otto changed:
What|Removed |Added
CC||ad...@tho-otto.de
--- Comment #7 from Thorsten Otto ---
I ran into a similar problem. The symptom was that code in
tree-switch-conversion was miscompiled:
if (k == count)
{
gcc_checking_assert (count < m_max_case_bit_tests);
test[k].mask = wi::zero (prec);
test[k].target_bb = n->m_case_bb;
test[k].label = n->m_case_label_expr;
test[k].bits = 0;
test[k].prob = profile_probability::never ();
count++;
}
--- good.s 2024-06-02 13:20:13.453987931 +0200
+++ bad.s 2024-06-02 13:50:03.452881214 +0200
@@ -26976,11 +26976,10 @@
move.l %d1,-330(%a0)| prephitmp_336, MEM
[(struct wide_int_storage *)&test][count_1036].mask.D.16112.len
| gcc/tree-switch-conversion.cc:1639: test[k].target_bb =
n->m_case_bb;
move.l 4(%a3),%d1 | MEM [(void *)n_1051
+ 4B], vect__12.3140
- lea (-322,%fp),%a4 |,,
- lea (%a4,%d0.l),%a1 |, vectp.3143
+ lea (%fp,%d0.l),%a1 | tmp12, tmp638, vectp.3143
| gcc/tree-switch-conversion.cc:1639: test[k].target_bb =
n->m_case_bb;
move.l 8(%a3),(%a1) | MEM [(void *)n_1051
+ 8B], MEM [(void *)vectp.3143_425]
- move.l %d1,4(%a1) | vect__12.3140, MEM
[(void *)vectp.3143_425 + 4B]
+ move.l %d1,-318(%a1)| vect__12.3140, MEM
[(void *)vectp.3143_425 + 4B]
| gcc/tree-switch-conversion.cc:1641: test[k].bits = 0;
clr.l -314(%a0) | test[count_1036].bits
| gcc/tree-switch-conversion.cc:1642: test[k].prob =
profile_probability::never ();
Apparently the offset to the local test array was optimized away for the first
store, causing the outer loop to not find the previous m_case_bb pointer, and
then either crash or fail with an assertion because the array overflowed.
Seems like this is not the first regression caused by this "optimization".
Maybe it should be disabled for targets other than riscv, atleast until more
tests have been written.
A crash with such a buggy compiler can be produced with eg.
int date_is_valid(int mon)
{
switch (mon) {
case 1:
case 3:
case 5:
case 7:
case 8:
case 10:
case 12:
break;
default:
return 0x2400;
}
return 0;
}
[Bug target/113357] [14/15 regression] m68k-linux bootstrap failure in stage2 due to segfault compiling unwind-dw2.c since r14-4664-g04c9cf5c786b94
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: if even after 3-4 attempts of fixing this it still does not work, please revert that fold-mem-offset patch(es), or atleast disable them. Its not worth of doing unsafe optimizations whose only purpose is to save a single instruction for a particular machine, but cause trouble for others.
[Bug target/113357] [14/15 regression] m68k-linux bootstrap failure in stage2 due to segfault compiling unwind-dw2.c since r14-4664-g04c9cf5c786b94
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?
[Bug modula2/92336] cross compiling gcc fails in gm2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92336 Thorsten Otto changed: What|Removed |Added CC||ad...@tho-otto.de --- Comment #5 from Thorsten Otto --- I get a related problem here. Configuring works, but during build, some of the helper programs (like mc) are compiled using $(CXX), which is already a cross-compiler, and therefor the resulting binaries cannot be executed.
[Bug modula2/110002] New: Using -fcpp only invokes cc1 from pre-configured path $(libexec)
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 Priority: P3 Component: modula2 Assignee: gaius at gcc dot gnu.org Reporter: ad...@tho-otto.de Target Milestone: ---
[Bug modula2/110002] Using -fcpp only invokes cc1 from pre-configured path $(libexec)
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_64-suse-linux/13/cc1 first, like the driver does.
[Bug modula2/110003] New: Wrong source line listed for unused parameters
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: modula2 Assignee: gaius at gcc dot gnu.org Reporter: ad...@tho-otto.de Target Milestone: --- When compiling a module with -Wall and a parameter in the in implementation module is unused, the error message lists the source line of the definition module instead: DEFINITION MODULE foo; PROCEDURE bla(a: INTEGER); END foo. IMPLEMENTATION MODULE foo; PROCEDURE bla(a: INTEGER); BEGIN END bla; END foo. $ gm2 -c -Wall foo.mod ./foo.def:3:15: warning: In procedure 'bla': unused parameter 'a' in procedure 'bla' 3 | PROCEDURE bla(a: INTEGER); | ^ That information is rather useless, because an unused parameter can only be unused in the implementation.
[Bug modula2/110019] New: Reported line numbers ar off-by-1 when preprocessing source files
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 Priority: P3 Component: modula2 Assignee: gaius at gcc dot gnu.org Reporter: ad...@tho-otto.de Target Milestone: --- When preprocessing modula sources with -fcpp, both the line number and the quoted source line are off-by-1 in error reports. Compiling eg: MODULE foo; BEGIN i := 0; END foo. gives: foo.mod:3:3: error: In program module 'foo': unknown symbol 'i' 3 | BEGIN | ^ foo.mod:4:8: error: the following unknown symbols in module 'foo' were unresolved: and i 4 | i := 0; |^ Additionally, the "and" in the summary of unresolved symbols is wrong.
[Bug modula2/110125] New: Variables are reported as uninitialized when only set inside WITH statement
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: normal Priority: P3 Component: modula2 Assignee: gaius at gcc dot gnu.org Reporter: ad...@tho-otto.de Target Milestone: --- In the following fragment: MODULE foo; TYPE Date = RECORD day: INTEGER; END; PROCEDURE test(): Date; VAR d: Date; BEGIN WITH d DO day := 0; END; RETURN d; END test; END foo. When compiling with $ gm2 -c -O2 -Wall foo.mod i get reports about d being uninitialized: foo.mod:9:5: warning: In procedure ‘test’: variable ‘d’ is being used but it is never initialized in procedure ‘test’ 9 | VAR d: Date; | ^ This does not happen when *not* using WITH, eg MODULE foo; TYPE Date = RECORD day: INTEGER; END; PROCEDURE test(): Date; VAR d: Date; BEGIN d.day := 0; RETURN d; END test; END foo.
[Bug modula2/110126] New: Variables are reported as unused when only referenced by ASM statements
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: normal
Priority: P3
Component: modula2
Assignee: gaius at gcc dot gnu.org
Reporter: ad...@tho-otto.de
Target Milestone: ---
In the following fragment:
MODULE foo;
VAR x: INTEGER;
PROCEDURE test;
BEGIN
ASM("" : : "m"(x));
END test;
END foo.
x is reported as unused (same happens when specifying it as output parameter)
Even worse, when used as input operand only, the whole asm statement seems to
be optimized away.
[Bug modula2/110126] Variables are reported as unused when only referenced by ASM statements
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 %1,%%eax; addl $1,%%eax; movl %%eax,%0" : "=r"(x) : "0"(x) :
"eax");
END test;
i still get the warning.
BTW, is there a reason why the string in the asm statement can't be
concatenated?
eg. especially if the statement becomes longer, you would usually want to write
it something like
ASM("movl %1,%%eax;" +
"addl $1,%%eax;" +
"movl %%eax,%0"
: "=r"(x) : "0"(x) : "eax");
[Bug modula2/110161] New: Comparing a typed procedure variable to 0 gives ICE or assertions
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 Priority: P3 Component: modula2 Assignee: gaius at gcc dot gnu.org Reporter: ad...@tho-otto.de Target Milestone: --- In the following example: MODULE foo; TYPE xProc = PROCEDURE(): BOOLEAN; VAR x: xProc; BEGIN IF x = 0 THEN END; END foo. I get: cc1gm2: internal compiler error: assert failed (unfortunately without any line number information). Same happens when comparing to NIL or PROC(0). Only xProc(0) works.
[Bug modula2/110125] Variables are reported as uninitialized when only set inside WITH statement
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 carrier: Carrier); BEGIN carrier.head.magic := 0; carrier.tail.magic := 0; END test; VAR x: Carrier; BEGIN test(x); END foo. also gives warning about unused parameter "carrier" in function test.
[Bug modula2/110174] New: Using illegal constraints for builtin return_address gives ICE
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
Priority: P3
Component: modula2
Assignee: gaius at gcc dot gnu.org
Reporter: ad...@tho-otto.de
Target Milestone: ---
When compiling the the following module with -O2
MODULE foo;
FROM Builtins IMPORT return_address;
FROM SYSTEM IMPORT ADDRESS;
VAR x: ADDRESS;
PROCEDURE test();
BEGIN
ASM VOLATILE("" : "=m"(x) : "m"(return_address(0)) : );
END test;
BEGIN
test();
END foo.
I get an ICE:
during RTL pass: expand
In function ‘test’,
inlined from ‘_M2_foo_init’ at foo.mod:13:3:
foo.mod:9:56: internal compiler error: in expand_asm_stmt, at cfgexpand.cc:3419
9 | ASM VOLATILE("" : "=m"(x) : "m"(return_address(0)) : );
|^
The ICE is triggered at
https://github.com/gcc-mirror/gcc/blob/9589a46ddadc8b93c224c3f84fa94746c04596bf/gcc/cfgexpand.cc#L3419
Using "m" as constraint is actually wrong, however the C backend handles that
correctly:
foo.c:5:39: error: memory input 1 is not directly addressable
5 | __asm__ volatile("" : "=m"(x) : "m"(__builtin_return_address(0)) : );
[Bug modula2/110126] Variables are reported as unused when only referenced by ASM statements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110126 Thorsten Otto changed: What|Removed |Added Status|RESOLVED|ASSIGNED Resolution|FIXED |--- --- Comment #7 from Thorsten Otto --- Thanks for looking into this. Unfortunately, with the new patch applied, i now get cc1gm2: internal compiler error: symbol out of bounds 0x7f4dfde2cbaf __libc_start_call_main ???:0 0x7f4dfde2cc78 __libc_start_main_alias_1 ???:0 Have yet to try to create a simple testcase that triggers this bug.
[Bug modula2/110126] Variables are reported as unused when only referenced by ASM statements
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): [ INTEGER32 ];
VAR
retvalue: INTEGER32;
BEGIN
ASM VOLATILE(""
: "=r"(retvalue)
: "g"(n)
: "cc", "memory"
);
RETURN retvalue
END trap_13_w;
BEGIN
END BIOS.
The crash disappears when i remove the clobber list from the asm.
[Bug modula2/110189] New: Using an unknown TYPE as argument to VAL gives ICE
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
Component: modula2
Assignee: gaius at gcc dot gnu.org
Reporter: ad...@tho-otto.de
Target Milestone: ---
In the following example:
MODULE foo;
VAR x: INTEGER;
BEGIN
x := VAL(abcd, 0);
END foo.
I get:
M2MetaError.mod:1535:internalformat error detected
errorBlock
type = abort
out = ||
in= |undeclared type found in builtin procedure function {%AkVAL}
{%A1ad}|
Length (out) = 0
len = 68
highplus1 = 1*** WARNING *** there are active plugins, do not report this as a
bug unless you can reproduce it without enabling any plugins.
Event| Plugins
PLUGIN_FINISH| m2rte
cc1gm2: internal compiler error: in libc_abort, at m2/mc-boot-ch/Glibc.c:70
0x195d5c6 internal_error(char const*, ...)
???:0
0x6f0e97 fancy_abort(char const*, int, char const*)
???:0
0x6aa497 libc_abort
???:0
0x808f05 FormatStrings_Sprintf1
???:0
0x767c73 M2Printf_fprintf1
???:0
0x76da13 M2MetaError_MetaErrorStringT1
???:0
0x786078 M2Quads_BuildFunctionCall
???:0
0x7e59d9 P3Build_CompilationUnit
???:0
0x75ba6b M2Comp_compile
???:0
[Bug modula2/110126] Variables are reported as unused when only referenced by ASM statements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110126 --- Comment #10 from Thorsten Otto --- Yes, thank you, that seems to work.
[Bug modula2/110126] Variables are reported as unused when only referenced by ASM statements
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"
[Bug modula2/110246] New: Using variables of type CHAR or BYTE as array index does not work
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
Priority: P3
Component: modula2
Assignee: gaius at gcc dot gnu.org
Reporter: ad...@tho-otto.de
Target Milestone: ---
In the following example:
IMPLEMENTATION MODULE foo;
FROM SYSTEM IMPORT BYTE;
VAR arr: ARRAY['A'..'Z'] OF INTEGER;
VAR ch: CHAR;
BEGIN
FOR ch := 'A' TO 'Z' DO arr[ch] := 0 END;
END foo.
I get error messages:
/usr/lib64/gcc/x86_64-suse-linux/13/m2/m2pim/COROUTINES.def:37:1: error: type
incompatibility, attempting to use a string ('_T38') when a CHAR is expected
/usr/lib64/gcc/x86_64-suse-linux/13/m2/m2pim/COROUTINES.def:37:1: error: type
incompatibility, attempting to use a string ('_T38') when a CHAR is expected
/usr/lib64/gcc/x86_64-suse-linux/13/m2/m2pim/COROUTINES.def:37:1: error: type
incompatibility, attempting to use a string ('_T38') when a CHAR is expected
/usr/lib64/gcc/x86_64-suse-linux/13/m2/m2pim/COROUTINES.def:37:1: error: type
incompatibility, attempting to use a string ('_T38') when a CHAR is expected
(note also the totally unrelated source line in the error message)
Changing the type of ch to BYTE i get instead:
/usr/lib64/gcc/x86_64-suse-linux/13/m2/m2pim/COROUTINES.def:37:1: error: left
operand ‘ch’ of type ‘BYTE’ is not allowed in binary expression +
[Bug modula2/110246] Using variables of type CHAR or BYTE as array index does not work
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.
[Bug modula2/110189] Using an unknown TYPE as argument to VAL gives ICE
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?
[Bug modula2/110633] New: Using an unknown identifier as argument to ORD results in ICE
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
Priority: P3
Component: modula2
Assignee: gaius at gcc dot gnu.org
Reporter: ad...@tho-otto.de
Target Milestone: ---
When compiling
MODULE foo;
VAR x: CARDINAL;
BEGIN
x := ORD(nosuchvar);
END foo.
I get:
M2MetaError.mod:1535:internalformat error detected
errorBlock
type = abort
out = ||
in= |the parameter to {%A1k%a} must be a variable or constant, seen
{%2ad}|
Length (out) = 0
len = 69
highplus1 = 2*** WARNING *** there are active plugins, do not report this as a
bug unless you can reproduce it without enabling any plugins.
Event| Plugins
PLUGIN_FINISH| m2rte
cc1gm2: internal compiler error: in libc_abort, at m2/mc-boot-ch/Glibc.c:70
Might be a general problem when using builtin functions (replacing ORD by CHR
gives the same ICE). Maybe a similar problem as in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110189
[Bug modula2/110126] Variables are reported as unused when only referenced by ASM statements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110126
Thorsten Otto changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED |---
--- Comment #14 from Thorsten Otto ---
And another problem i just encountered. In the following example:
DEFINITION MODULE foo;
PROCEDURE ConWS(str: ARRAY OF CHAR);
END foo.
IMPLEMENTATION MODULE foo;
FROM SYSTEM IMPORT ADR, CARDINAL16, CARDINAL32, INTEGER16, ADDRESS,
INTEGER32, WORD;
FROM StrIO IMPORT WriteString, WriteLn;
TYPE strtmp = ARRAY [0..255] OF CHAR;
PROCEDURE str0(VAR dst: strtmp; src: ARRAY OF CHAR);
VAR i, len: CARDINAL;
BEGIN
len := HIGH(dst);
FOR i := 0 TO len DO
dst[i] := src[i];
END;
END str0;
PROCEDURE trap_1_wl(n: INTEGER16; a: ADDRESS): [ INTEGER32 ];
VAR
retvalue: INTEGER32;
BEGIN
ASM VOLATILE("move.l %2,-(%%sp); move.w %1,-(%%sp); trap #1; addq.l
#6,%%sp; move.l %%d0,%0"
: "=r"(retvalue)
: "g"(n), "r"(a)
: "memory"
);
RETURN retvalue
END trap_1_wl;
PROCEDURE ConWS(str: ARRAY OF CHAR);
VAR s: strtmp;
BEGIN
str0(s, str);
trap_1_wl(9, ADR(s));
END ConWS;
END foo.
The call to str0 (in reality supposed to ensure the string is 0-terminated;
just simplified for the example) is now completely eliminated. The assembler
statement is of course only for m68k, but it can even be triggered for other
targets when just producing assembler output.
It does not happen when replacing the call to trap_1_wl eg. by WriteString.
[Bug target/111279] ICE: Segmentation fault with m68k,SJLJ and -malign-int
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.
[Bug target/113357] [14/15 regression] m68k-linux bootstrap failure in stage2 due to segfault compiling unwind-dw2.c since r14-4664-g04c9cf5c786b94
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.
[Bug target/96532] [m68k] gcc 10.x generates calls to memset even for very small amounts
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, although the commit in question does not look to me as if it had any target dependencies. Also note that the commit itself (due to a typo) is not compilable, you have to use the next one (https://github.com/gcc-mirror/gcc/commit/5fbe6a8e73b52c6ebc28b9111456226c1cda6472) instead.
[Bug c++/53549] New: g++ and armadillo 3.2.0, operator() is inaccessible
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
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ad...@toffyrn.net
Compiling my project using armadillo fails with `is inaccessible' when trying
to use fixed size vectors, for example `ivec3'.
Armadillo is version 3.2.0 from http://arma.sourceforge.net/
The bug is seen in both gcc 4.7.0 and gcc-snapshot 4.8.20120520, on Arch Linux.
The bug is not present in gcc 4.6.3.
===
Test program:
[toffyrn@bohr Test]$ cat main.cpp
#include
int main(int argc, char** argv)
{
arma::ivec3 jjj;
return 0;
}
Error:
[toffyrn@bohr Test]$ g++ main.cpp -o run -larmadillo
In file included from /usr/include/armadillo:399:0,
from main.cpp:1:
/usr/include/armadillo_bits/Col_bones.hpp: In instantiation of ‘class
arma::Col::fixed<3u>’:
main.cpp:5:17: required from here
/usr/include/armadillo_bits/Col_meat.hpp:512:1: error: ‘const
arma::subview_col arma::Col::operator()(const arma::span&) const’ is
inaccessible
In file included from /usr/include/armadillo:142:0,
from main.cpp:1:
/usr/include/armadillo_bits/Col_bones.hpp:113:9: error: within this context
In file included from /usr/include/armadillo:399:0,
from main.cpp:1:
/usr/include/armadillo_bits/Col_meat.hpp:500:1: error: ‘arma::subview_col
arma::Col::operator()(const arma::span&)’ is inaccessible
In file included from /usr/include/armadillo:142:0,
from main.cpp:1:
/usr/include/armadillo_bits/Col_bones.hpp:113:9: error: within this context
GCC version:
[toffyrn@bohr Test]$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /build/src/gcc-4.7-20120505/configure --prefix=/usr
--libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared
--enable-threads=posix --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch
--enable-libstdcxx-time --enable-gnu-unique-object --enable-linker-build-id
--with-ppl --enable-cloog-backend=isl --enable-lto --enable-gold
--enable-ld=default --enable-plugin --with-plugin-ld=ld.gold
--with-linker-hash-style=gnu --disable-multilib --disable-libssp
--disable-build-with-cxx --disable-build-poststage1-with-cxx
--enable-checking=release
Thread model: posix
gcc version 4.7.0 20120505 (prerelease) (GCC)
[Bug c++/53549] g++ and armadillo 3.2.0, operator() is inaccessible
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.
[Bug objc++/66504] New: ICE using C++ exceptions in Objective-C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66504 Bug ID: 66504 Summary: ICE using C++ exceptions in Objective-C++ Product: gcc Version: 5.1.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: objc++ 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 Objective-C++ can generate an ICE. exceptionice.mm: In function 'void Problem()': exceptionice.mm:1:6: internal compiler error: in objc_eh_runtime_type, at objc/objc-next-runtime-abi-01.c:2804 void Problem() ^ Compiled on Mac OS X 10.4 on a PowerMac G4 with the following configuration: CC=gcc-4.2 CXX=g++-4.2 AS=/opt/cctools/usr/bin/as AS_FOR_TARGET=/opt/cctools/usr/bin/as ../GCC/configure --prefix=/opt/gcc/5 --disable-nls --enable-languages=c,c++,objc,obj-c++,lto --disable-multilib --with-dwarf2 Command line used to get the error is: /opt/gcc/5/bin/g++ exceptionice.mm
[Bug c++/45328] New: bug w/ typedefs and std::initializer_list
Given this code,
#include
typedef std::initializer_list init_list;
struct A {
A (init_list list) { }
};
struct B {
B (std::initializer_list list) { }
};
int main (void) {
A a { 0, 1, 1, 2}; // compiler error
B b { 0, 1, 1, 2};
}
I get a compiler error when trying to brace initialize an instance of struct A.
The specific error:
initializer_bug.cpp: In function âint main()â:
initializer_bug.cpp:14:19: error: no matching function for call to
âA::A()â
initializer_bug.cpp:6:3: note: candidates are: A::A(init_list)
initializer_bug.cpp:5:10: note: A::A(const A&)
Compiled example code with g++ --std=c++0x initializer_bug.cpp -o
initializer_bug.
Using gcc version 4.5.1 20100617 (prerelease) (Debian 4.5.0-6)
--
Summary: bug w/ typedefs and std::initializer_list
Product: gcc
Version: 4.5.1
Status: 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-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45328
[Bug other/97417] RISC-V Unnecessary andi instruction when loading volatile bool
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417
Levy changed:
What|Removed |Added
CC||admin at levyhsu dot com
--- Comment #6 from Levy ---
Hi Jim
Levy from StarFive.
Adding following code to the head of riscv_legitimize_move() according to your
reply seems to solve the problem:
if(mode == QImode && MEM_P (src) && REG_P (dest))
{
rtx temp_reg;
if (TARGET_64BIT)
{
temp_reg = gen_reg_rtx (DImode);
emit_insn(gen_zero_extendqidi2(temp_reg, src));
}
else
{
temp_reg = gen_reg_rtx (SImode);
emit_insn(gen_zero_extendqisi2(temp_reg, src));
}
riscv_emit_move(dest, gen_rtx_SUBREG(QImode,temp_reg,0));
return true;
}
same foo.c will produce:
foo:
lui a5,%hi(active)
lbu a5,%lo(active)(a5)
li a0,42
bne a5,zero,.L6
ret
.L6:
li a0,-42
ret
.size foo, .-foo
.ident "GCC: (GNU) 10.2.0"
Not sure if I'm doing it right, especially for 64bit DImode because I've only
been with gcc for a month. Just wonder if you have time after Monday's compiler
meeting so we may discuss movsi, movhi and MEM to MEM copy.
[Bug other/97417] RISC-V Unnecessary andi instruction when loading volatile bool
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 test case later.
Following code was added to the riscv_legitimize_move () in the
riscv-gcc/gcc/config/riscv/riscv.c
if(mode == QImode && MEM_P (src) && REG_P (dest) && can_create_pseudo_p())
{
rtx temp_reg;
if (TARGET_64BIT)
{
temp_reg = gen_reg_rtx (DImode);
emit_insn(gen_zero_extendqidi2(temp_reg, src));
}
else
{
temp_reg = gen_reg_rtx (SImode);
emit_insn(gen_zero_extendqisi2(temp_reg, src));
}
riscv_emit_move(dest, gen_lowpart(QImode,temp_reg));
return true;
}
Tested with make report-gcc, haven't done the regression/performance test yet:
= Summary of gcc testsuite =
| # of unexpected case / # of unique unexpected
case
| gcc | g++ | gfortran |
rv64imafdc/ lp64d/ medlow |0 / 0 |0 / 0 | - |
[Bug other/97417] RISC-V Unnecessary andi instruction when loading volatile bool
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417 --- Comment #9 from Levy --- Thanks Jim. See u on Monday.
[Bug other/97417] RISC-V Unnecessary andi instruction when loading volatile bool
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/SImode(64bit)
Both Zero-Extend & Subreg
Tested with make report-gcc
Two failed cases: shorten-memrefs-5.c & shorten-memrefs-6.c
Both were failed due to dejaGNU rule:
/* { dg-final { scan-assembler "load1r:\n\taddi" } } */
But if we look at the assembly code, for same input in both file:
int load1r (int *array)
{
int a = 0;
a += array[200];
a += array[201];
a += array[202];
a += array[203];
return a;
}
Current gcc risc-v port will produce:
load1r:
addia5,a0,768
lw a4,36(a5)
lw a0,32(a5)
addwa0,a0,a4
lw a4,40(a5)
addwa4,a4,a0
lw a0,44(a5)
addwa0,a0,a4
ret
Patched new port will produce:
load1r:
lwu a4,800(a0)
lwu a5,804(a0)
addwa5,a5,a4
lwu a4,808(a0)
lwu a0,812(a0)
addwa5,a5,a4
addwa0,a5,a0
ret
With one instruction less, the patched one seems right and even faster to me.
However we still need a test on sign extend and check performance
Test case and performance evaluation will be provided later (hopefully)
[Bug other/97417] RISC-V Unnecessary andi instruction when loading volatile bool
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 take a look into > riscv-shorten-memrefs.c:pass_shorten_memrefs::analyze and add logic to > handle zero_extend and sign_extend. > > > > With one instruction less, the patched one seems right and even faster to > > me. However we still need a test on sign extend and check performance > > shorten_memrefs is optimize for size, the idea is transform several load > instructions with large immediate to a load immediate instruction and load > instructions with small immediate, to use C-extensions instruction as > possible. > > so the instruction count seems increased, but the code size is smaller. Thank you cheng, I'll have a look.
[Bug other/97417] RISC-V Unnecessary andi instruction when loading volatile bool
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);
rtx temp_reg = force_reg (word_mode, convert_to_mode (word_mode, src,
extend));
riscv_emit_move(dest, temp_reg);
return true;
}
tried to insert code at the beginning of riscv_legitimize_move() but seems
convert_to_mode() raised seg fault druing make
[Bug other/97417] RISC-V Unnecessary andi instruction when loading volatile bool
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_pseudo_p()
&& MEM_P (src))
{
rtx temp_reg = force_reg (word_mode, convert_to_mode (word_mode, src, 1));
riscv_emit_move(dest, temp_reg);
return true;
}
[Bug other/97417] RISC-V Unnecessary andi instruction when loading volatile bool
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_EXTEND_OP (mode) == ZERO_EXTEND);
I've tried the combination of:
gen_extend_insn (temp_reg, force_reg (mode, src), word_mode, mode, extend);
gen_extend_insn (temp_reg, force_reg (word_mode, src), word_mode, word_mode,
extend);
gen_extend_insn (temp_reg, src, word_mode, mode, extend);
with:
riscv_emit_move(dest, gen_lowpart (mode, temp_reg));
riscv_emit_move(dest, force_reg(mode, temp_reg));
then return true
All raised segfault during make gcc.
For example:
if (GET_MODE_CLASS (mode) == MODE_INT
&& GET_MODE_SIZE (mode) < UNITS_PER_WORD
&& can_create_pseudo_p()
&& MEM_P (src))
{
rtx temp_reg;
int extend = (LOAD_EXTEND_OP (mode) == ZERO_EXTEND);
gen_extend_insn (temp_reg, force_reg (mode, src), word_mode, mode, extend);
riscv_emit_move(dest, force_reg(mode, temp_reg));
return true;
}
At beginning of riscv_legitimize_move()
[Bug other/97417] RISC-V Unnecessary andi instruction when loading volatile bool
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417 Levy changed: What|Removed |Added Attachment #49470|0 |1 is obsolete|| Attachment #49500|0 |1 is obsolete|| --- Comment #23 from Levy --- Created attachment 49524 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49524&action=edit Third test patch While I'm waiting for a solution, I've reused my second patch and made a new patch. Third test patch adds one extra function gen_extend_insn_auto() in optabs.c/h then just called by riscv_legitimize_move() Now it can emit sign/unsigned-extend insn automatically. Still haven't solved the shorten-memrefs issue. So it will still raise 2 error when make report-gcc So the -Os option (size optimization) may not behave as expected.
[Bug other/97417] RISC-V Unnecessary andi instruction when loading volatile bool
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417 Levy changed: What|Removed |Added Attachment #49524|0 |1 is obsolete|| --- Comment #24 from Levy --- Created attachment 49532 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49532&action=edit QI/HI/SI/DI zero/sign-extend for RV32/64/128 Rewrote the third proposed patch.
[Bug other/97417] RISC-V Unnecessary andi instruction when loading volatile bool
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417 Levy changed: What|Removed |Added Attachment #49532|0 |1 is obsolete|| --- Comment #26 from Levy --- Created attachment 49533 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49533&action=edit QI/HI/SI/DI zero/sign-extend for RV32/64/128 BUG fix for unimplemented code
[Bug other/97417] RISC-V Unnecessary andi instruction when loading volatile bool
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 problem, I'll make a new patch.
[Bug other/97417] RISC-V Unnecessary andi instruction when loading volatile bool
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417 Levy changed: What|Removed |Added Attachment #49533|0 |1 is obsolete|| --- Comment #28 from Levy --- Created attachment 49534 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49534&action=edit V4 patch for QI/HI/SI/DI zero/sign-extend for RV32/64/128 Suggest by Kito, The V4 patch moved the gen_extend_insn_auto() to riscv.c and was included in riscv-protos.h since it handles riscv backend only.
[Bug other/97417] RISC-V Unnecessary andi instruction when loading volatile bool
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417
Levy changed:
What|Removed |Added
Attachment #49534|0 |1
is obsolete||
--- Comment #29 from Levy ---
Created attachment 49536
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49536&action=edit
QI/HI/SImode auto Zero/Sign-extend
Finally, make gen_extend_insn() seems to work with auto-extension based on Jim
and Kito's idea.
Just 10 lines of code at the beginning of riscv_legitimize_move() in
riscv-gcc/gcc/config/riscv.c
if (GET_MODE_CLASS (mode) == MODE_INT
&& GET_MODE_SIZE (mode) < UNITS_PER_WORD
&& can_create_pseudo_p()
&& MEM_P (src))
{
rtx temp_reg = gen_reg_rtx (word_mode);
int zero_sign_extend = (LOAD_EXTEND_OP (mode) == ZERO_EXTEND);
emit_insn(gen_extend_insn(temp_reg, src, word_mode, mode,
zero_sign_extend));
riscv_emit_move(dest, gen_lowpart(mode, temp_reg));
return true;
}
Haven't make report-gcc, but already passed 2-stage make.
I'll have a test later.
[Bug other/97417] RISC-V Unnecessary andi instruction when loading volatile bool
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417 Levy changed: What|Removed |Added Attachment #49536|0 |1 is obsolete|| --- Comment #31 from Levy --- Created attachment 49542 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49542&action=edit QI/HI/SImode auto Zero/Sign-extend Much appreciated Jim. The new patch should solve the format issue by adding the same tabs on each line. In the meanwhile I'll try to patch the pass_shorten_memrefs::analyze() in riscv-shorten-memrefs.c Any idea on the combiner issue?
[Bug other/97417] RISC-V Unnecessary andi instruction when loading volatile bool
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417 Levy changed: What|Removed |Added Attachment #49542|0 |1 is obsolete|| --- Comment #32 from Levy --- Created attachment 49543 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49543&action=edit QI/HI/SImode auto Zero/Sign-extend Added one missing space at the end of the comment. Added one tab before each brace. Replace all tabs with space (come on)
[Bug other/97417] RISC-V Unnecessary andi instruction when loading volatile bool
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 large software base when everything is using the same > coding style. We do have info to help you follow the GNU coding style. See > https://gcc.gnu.org/wiki/FormattingCodeForGCC > which has emacs and vim settings to get the right code style. No problem and thank you, Jim, I'll try to catch up the coding style. what about the combine issue and shorten-memrefs? Shall we fix it here or someplace else?
[Bug other/97417] RISC-V Unnecessary andi instruction when loading volatile bool
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 list should work) to store the zero/sign extend when we strip it off like: if (GET_CODE (mem) == ZERO_EXTEND || GET_CODE (mem) == SIGN_EXTEND) mem = XEXP (mem, 0); in each insns. Then in pass_shorten_memrefs::transform(), each time get_si_mem_base_reg() is called, we check whether if we need to put it back.
[Bug other/97417] RISC-V Unnecessary andi instruction when loading volatile bool
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 array_test.c
int load1r (int *array)
{
int a = 0;
a += array[200];
a += array[201];
a += array[202];
a += array[203];
return a;
}
int main ()
{
int arr[300]= {0};
arr[200] = 15;
arr[201] = -33;
arr[202] = 7;
arr[203] = -999;
int b = load1r(arr);
printf("Result: %d\n",b);
return 0;
}
in loadlr, when put a debug_rtx(pat) after:
(unpatched)XEXP (pat, i) = replace_equiv_address (mem, addr);
or
(patched)XEXP (XEXP (pat, I), 0) = replace_equiv_address(XEXP (mem, 0), addr);
unpatched gcc will produce follwing insns:
-
(set (reg:SI 81 [ MEM[(int *)array_5(D) + 800B] ])
(mem:SI (plus:DI (reg:DI 88)
(const_int 32 [0x20])) [1 MEM[(int *)array_5(D) + 800B]+0 S4 A32]))
(set (reg:SI 82 [ MEM[(int *)array_5(D) + 804B] ])
(mem:SI (plus:DI (reg:DI 89)
(const_int 36 [0x24])) [1 MEM[(int *)array_5(D) + 804B]+0 S4 A32]))
(set (reg:SI 84 [ MEM[(int *)array_5(D) + 808B] ])
(mem:SI (plus:DI (reg:DI 90)
(const_int 40 [0x28])) [1 MEM[(int *)array_5(D) + 808B]+0 S4 A32]))
(set (reg:SI 86 [ MEM[(int *)array_5(D) + 812B] ])
(mem:SI (plus:DI (reg:DI 91)
(const_int 44 [0x2c])) [1 MEM[(int *)array_5(D) + 812B]+0 S4 A32]))
-
patched gcc will produce follwing insns:
-
(set (reg:DI 82 [ MEM[(int *)array_5(D) + 800B] ])
(sign_extend:DI (mem:SI (plus:DI (reg:DI 92)
(const_int 32 [0x20])) [1 MEM[(int *)array_5(D) + 800B]+0 S4
A32])))
(set (reg:DI 84 [ MEM[(int *)array_5(D) + 804B] ])
(sign_extend:DI (mem:SI (plus:DI (reg:DI 93)
(const_int 36 [0x24])) [1 MEM[(int *)array_5(D) + 804B]+0 S4
A32])))
(set (reg:DI 87 [ MEM[(int *)array_5(D) + 808B] ])
(sign_extend:DI (mem:SI (plus:DI (reg:DI 94)
(const_int 40 [0x28])) [1 MEM[(int *)array_5(D) + 808B]+0 S4
A32])))
(set (reg:DI 90 [ MEM[(int *)array_5(D) + 812B] ])
(sign_extend:DI (mem:SI (plus:DI (reg:DI 95)
(const_int 44 [0x2c])) [1 MEM[(int *)array_5(D) + 812B]+0 S4
A32])))
-
which the patched one looks ok for me, but the final assembly code still shows
no change (both under -Os)
Not quite sure where the problem is, I'll have a look near
array_test.c.250r.shorten_memrefs tomorrow.
Please ignore the coding style as it's just a debug patch
[Bug other/97417] RISC-V Unnecessary andi instruction when loading volatile bool
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: r92:DI=r96:DI+0x300
REG_DEAD r96:DI
deferring rescan insn with uid = 27.
(!)allowing combination of insns 27 and 6
original costs 4 + 16 = 20
replacement costs 4 + 16 = 20
modifying insn i227: r92:DI=r96:DI+0x300
deferring rescan insn with uid = 27.
modifying insn i3 6: r82:DI=sign_extend([r96:DI+0x320])
REG_DEAD r96:DI
deferring rescan insn with uid = 6.
(!)allowing combination of insns 27 and 8
original costs 4 + 16 = 20
replacement costs 4 + 16 = 20
modifying insn i227: r92:DI=r96:DI+0x300
deferring rescan insn with uid = 27.
modifying insn i3 8: r84:DI=sign_extend([r96:DI+0x324])
REG_DEAD r96:DI
deferring rescan insn with uid = 8.
(!)allowing combination of insns 27 and 12
original costs 4 + 16 = 20
replacement costs 4 + 16 = 20
modifying insn i227: r92:DI=r96:DI+0x300
deferring rescan insn with uid = 27.
modifying insn i312: r87:DI=sign_extend([r96:DI+0x328])
REG_DEAD r96:DI
deferring rescan insn with uid = 12.
(!)allowing combination of insns 27 and 16
original costs 4 + 16 = 20
replacement cost 16
deferring deletion of insn with uid = 27.
modifying insn i316: r90:DI=sign_extend([r96:DI+0x32c])
REG_DEAD r96:DI
deferring rescan insn with uid = 16.
allowing combination of insns 18 and 19
---
Where in 268r.ud_dce both insns 27 are same (except for memory address):
(insn 27 26 28 2 (set (reg:DI 10 a0)
(lo_sum:DI (reg/f:DI 85)
(symbol_ref/f:DI ("*.LC0") [flags 0x82] ))) "array_test.c":21:5 133 {*lowdi}
(expr_list:REG_DEAD (reg/f:DI 85)
(expr_list:REG_EQUAL (symbol_ref/f:DI ("*.LC0") [flags 0x82] )
(nil
---
In 270r.combine (patched):
(note 27 3 6 2 NOTE_INSN_DELETED)
and following insns 768 + 32/36/40/44 were put back as:
(insn 6 27 8 2 (set (reg:DI 82 [ MEM[(int *)array_5(D) + 800B] ])
(sign_extend:DI (mem:SI (plus:DI (reg:DI 96)
(const_int 800 [0x320])) [1 MEM[(int *)array_5(D) + 800B]+0
S4 A32]))) "array_test.c":7:5 90 {extendsidi2}
(insn 8 6 10 2 (set (reg:DI 84 [ MEM[(int *)array_5(D) + 804B] ])
(sign_extend:DI (mem:SI (plus:DI (reg:DI 96)
(const_int 804 [0x324])) [1 MEM[(int *)array_5(D) + 804B]+0
S4 A32]))) "array_test.c":7:5 90 {extendsidi2}
(insn 12 10 14 2 (set (reg:DI 87 [ MEM[(int *)array_5(D) + 808B] ])
(sign_extend:DI (mem:SI (plus:DI (reg:DI 96)
(const_int 808 [0x328])) [1 MEM[(int *)array_5(D) + 808B]+0
S4 A32]))) "array_test.c":8:5 90 {extendsidi2}
(insn 16 14 18 2 (set (reg:DI 90 [ MEM[(int *)array_5(D) + 812B] ])
(sign_extend:DI (mem:SI (plus:DI (reg:DI 96)
(const_int 812 [0x32c])) [1 MEM[(int *)array_5(D) + 812B]+0
S4 A32]))) "array_test.c":9:5 90 {extendsidi2}
(expr_list:REG_DEAD (reg:DI 96)
(nil)))
Maybe combine.c needs some modification?
[Bug target/97417] RISC-V Unnecessary andi instruction when loading volatile bool
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])) (plus:DI (reg/f:DI 15 a5 [88]) (const_int 36 [0x24])) (plus:DI (reg:DI 10 a0 [92]) (const_int 804 [0x324])) ... Patched one outputs nothing. what it means to me is that riscv backend, something like: (sign_extend:DI (mem:SI (plus:DI (reg:DI 93) is never passed to riscv_address_cost(), unlike: (mem:SI (plus:DI (reg:DI 89) so whether riscv_mshorten_memrefs is set or not doesn't really matter here. Then I traced back to where address_cost() is called, 1.address_cost() is called by riscv_new_address_profitable_p() in riscv.c 2.riscv_new_address_profitable_p() is called by attempt_change() in sched-deps.c And since I'm not that familiar with struct mem_inc_info, this of trace could be wrong: 3.attempt_change() is called by find_inc() in sched-deps.c (Still tracing) -- Also since Arm can handle sign/zero/extend with subreg under -Os, I had a quick search on arm.c in arm_address_cost(), rtx here were passed as x, not addr (which addr may be XEXP (mem, 0)). So GET_CODE (x) cam be used to determine whether it has a MEM/LABEL_REF/SYMBOL_REF... at front. Then cost can be vary from 0 all the way to 10. This also worth some investigation to see how -Os works on arm side. -- Need some time to work on it.
[Bug target/97417] RISC-V Unnecessary andi instruction when loading volatile bool
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
pass_postreload_cse::execute()
in postreload.c
---
For reload_combine(), by printing each insn at front of the loop: (line 1302)
for (insn = get_last_insn (); insn; insn = prev)
{
debug_rtx(insn)
...
}
---
Unpatched gcc shows:
(insn 13 11 14 2 (set (reg:DI 10 a0)
(sign_extend:DI (mem:SI (plus:DI (reg/f:DI 15 a5 [88])
(const_int 44 [0x2c])) [1 MEM[(int *)array_5(D) + 812B]+0
S4 A32]))) "array_test.c":9:5 90 {extendsidi2}
(nil))
(insn 11 10 13 2 (set (reg:SI 14 a4 [83])
(plus:SI (reg:SI 14 a4 [orig:84 MEM[(int *)array_5(D) + 808B] ] [84])
(reg:SI 10 a0 [80]))) "array_test.c":8:5 3 {addsi3}
(nil))
(insn 10 8 11 2 (set (reg:DI 14 a4)
(sign_extend:DI (mem:SI (plus:DI (reg/f:DI 15 a5 [88])
(const_int 40 [0x28])) [1 MEM[(int *)array_5(D) + 808B]+0
S4 A32]))) "array_test.c":8:5 90 {extendsidi2}
(expr_list:REG_EQUIV (mem:SI (plus:DI (reg/f:DI 15 a5 [88])
(const_int 40 [0x28])) [1 MEM[(int *)array_5(D) + 808B]+0 S4
A32])
(nil)))
(insn 8 7 10 2 (set (reg:SI 10 a0 [80])
(plus:SI (reg:SI 10 a0 [orig:81 MEM[(int *)array_5(D) + 800B] ] [81])
(reg:SI 14 a4 [orig:82 MEM[(int *)array_5(D) + 804B] ] [82])))
"array_test.c":7:5 3 {addsi3}
(nil))
(insn 7 6 8 2 (set (reg:DI 14 a4)
(sign_extend:DI (mem:SI (plus:DI (reg/f:DI 15 a5 [88])
(const_int 36 [0x24])) [1 MEM[(int *)array_5(D) + 804B]+0
S4 A32]))) "array_test.c":7:5 90 {extendsidi2}
(expr_list:REG_EQUIV (mem:SI (plus:DI (reg/f:DI 15 a5 [88])
(const_int 36 [0x24])) [1 MEM[(int *)array_5(D) + 804B]+0 S4
A32])
(nil)))
(insn 6 23 7 2 (set (reg:DI 10 a0)
(sign_extend:DI (mem:SI (plus:DI (reg/f:DI 15 a5 [88])
(const_int 32 [0x20])) [1 MEM[(int *)array_5(D) + 800B]+0
S4 A32]))) "array_test.c":7:5 90 {extendsidi2}
(expr_list:REG_EQUIV (mem:SI (plus:DI (reg/f:DI 15 a5 [88])
(const_int 32 [0x20])) [1 MEM[(int *)array_5(D) + 800B]+0 S4
A32])
(nil)))
---
Patched one shows already merged results:
(insn 16 14 18 2 (set (reg:DI 10 a0 [orig:90 MEM[(int *)array_5(D) + 812B] ]
[90])
(sign_extend:DI (mem:SI (plus:DI (reg:DI 10 a0 [96])
(const_int 812 [0x32c])) [1 MEM[(int *)array_5(D) + 812B]+0
S4 A32]))) "array_test.c":9:5 90 {extendsidi2}
(nil))
(insn 14 12 16 2 (set (reg:SI 15 a5 [85])
(plus:SI (reg:SI 15 a5 [80])
(reg:SI 14 a4 [orig:87 MEM[(int *)array_5(D) + 808B] ] [87])))
"array_test.c":8:5 3 {addsi3}
(nil))
(insn 12 10 14 2 (set (reg:DI 14 a4 [orig:87 MEM[(int *)array_5(D) + 808B] ]
[87])
(sign_extend:DI (mem:SI (plus:DI (reg:DI 10 a0 [96])
(const_int 808 [0x328])) [1 MEM[(int *)array_5(D) + 808B]+0
S4 A32]))) "array_test.c":8:5 90 {extendsidi2}
(nil))
(insn 10 8 12 2 (set (reg:SI 15 a5 [80])
(plus:SI (reg:SI 15 a5 [orig:84 MEM[(int *)array_5(D) + 804B] ] [84])
(reg:SI 14 a4 [orig:82 MEM[(int *)array_5(D) + 800B] ] [82])))
"array_test.c":7:5 3 {addsi3}
(nil))
(insn 8 6 10 2 (set (reg:DI 15 a5 [orig:84 MEM[(int *)array_5(D) + 804B] ]
[84])
(sign_extend:DI (mem:SI (plus:DI (reg:DI 10 a0 [96])
(const_int 804 [0x324])) [1 MEM[(int *)array_5(D) + 804B]+0
S4 A32]))) "array_test.c":7:5 90 {extendsidi2}
(nil))
(insn 6 27 8 2 (set (reg:DI 14 a4 [orig:82 MEM[(int *)array_5(D) + 800B] ]
[82])
(sign_extend:DI (mem:SI (plus:DI (reg:DI 10 a0 [96])
(const_int 800 [0x320])) [1 MEM[(int *)array_5(D) + 800B]+0
S4 A32]))) "array_test.c":7:5 90 {extendsidi2}
(nil))
---
Before reload_combine () is reload_cse_regs_1() in reload_cse_regs() which
"detects no-op moves where we happened to assign two different pseudo-registers
to the same hard register"
and pass_postreload_cse::execute calls reload_cse_regs()
pass_postreload_cse::execute() look like the entry point for postreload.c
In order to confirm it's not in postreload.c, I put:
--
rtx_insn *insn, *next;
for (insn = get_insns (); insn; insn = next)
{
debug_rtx(insn);
next = NEXT_INSN (insn);
}
--
in pass_postreload_cse::execute (function *fun)
right after:
if (!dbg_cnt (postreload_cse))
return 0;
-
[Bug target/97417] RISC-V Unnecessary andi instruction when loading volatile bool
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. */
[Bug target/97417] RISC-V Unnecessary andi instruction when loading volatile bool
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
[Bug target/97417] RISC-V Unnecessary andi instruction when loading volatile bool
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_after_global_opts); NEXT_PASS (pass_rtl_ifcvt); NEXT_PASS (pass_reginfo_init); /* Perform loop optimizations. It might be better to do them a bit sooner, but we want the profile feedback to work more efficiently. */ NEXT_PASS (pass_loop2); PUSH_INSERT_PASSES_WITHIN (pass_loop2) NEXT_PASS (pass_rtl_loop_init); NEXT_PASS (pass_rtl_move_loop_invariants); NEXT_PASS (pass_rtl_unroll_loops); NEXT_PASS (pass_rtl_doloop); NEXT_PASS (pass_rtl_loop_done); POP_INSERT_PASSES () NEXT_PASS (pass_lower_subreg2); NEXT_PASS (pass_web); NEXT_PASS (pass_rtl_cprop); NEXT_PASS (pass_cse2); NEXT_PASS (pass_rtl_dse1); NEXT_PASS (pass_rtl_fwprop_addr); NEXT_PASS (pass_inc_dec); NEXT_PASS (pass_initialize_regs); NEXT_PASS (pass_ud_rtl_dce); NEXT_PASS (pass_combine); NEXT_PASS (pass_if_after_combine); NEXT_PASS (pass_jump_after_combine); NEXT_PASS (pass_partition_blocks); NEXT_PASS (pass_outof_cfg_layout_mode); NEXT_PASS (pass_split_all_insns); NEXT_PASS (pass_lower_subreg3); NEXT_PASS (pass_df_initialize_no_opt); NEXT_PASS (pass_stack_ptr_mod); NEXT_PASS (pass_mode_switching); NEXT_PASS (pass_match_asm_constraints); NEXT_PASS (pass_sms); NEXT_PASS (pass_live_range_shrinkage); NEXT_PASS (pass_sched); NEXT_PASS (pass_early_remat); NEXT_PASS (pass_ira); NEXT_PASS (pass_reload); NEXT_PASS (pass_postreload); PUSH_INSERT_PASSES_WITHIN (pass_postreload) NEXT_PASS (pass_postreload_cse); NEXT_PASS (pass_gcse2); NEXT_PASS (pass_split_after_reload); .. After some debugging processes. it seems either: 1.The address cost info was calculated between (pass_combine) and (pass_shorten_memrefs) for patched version, then merged in the combined pass. patched one is failed to be recognized as unpathed one due to Sign/Zero extend then Subreg. This can be verified by adding -fdisable-rtl-combine option when compile, also the address_cost was not called for the whole time. 2.4 insn was determined(or say fixed?) before (pass_rtl_fwprop_addr), as for patched version, I saw forward_propagate_and_simplify() was called for 4 extra times, then pass all the way to propagate_rtx()->propagate_rtx_1()->should_replace_address()->address_cost() in fwprop.c I've also tested the (pass_postreload) as mentioned by Jim and new_address_profitable_p(). But they seem not to be the right one. Need some time to examine and trace the pass between (pass_shorten_memrefs) and (pass_rtl_fwprop_addr).
[Bug target/97417] RISC-V Unnecessary andi instruction when loading volatile bool
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 with log_links()
Then in combine_instructions(), for_each_log_link(), try_combine() calls
combine_validate_cost()
in combine_validate_cost(), for the patched version:
OLD===846930886===OLD
i2 & Cost 4:
(insn 27 3 6 2 (set (reg/f:DI 92)
(plus:DI (reg:DI 96)
(const_int 768 [0x300]))) "array_test.c":7:5 4 {adddi3}
(expr_list:REG_DEAD (reg:DI 96)
(nil)))
i3 & Cost 16:
(insn 6 27 8 2 (set (reg:DI 82 [ MEM[(int *)array_5(D) + 800B] ])
(sign_extend:DI (mem:SI (plus:DI (reg:DI 96)
(const_int 800 [0x320])) [1 MEM[(int *)array_5(D) + 800B]+0
S4 A32]))) "array_test.c":7:5 90 {extendsidi2}
(nil))
Old Cost 20:
NEW===846930886===NEW
New_Cost: 20
i0 & Cost 0:
(nil)
i1 & Cost 0:
(nil)
i2 & Cost 4:
(insn 27 3 6 2 (set (reg/f:DI 92)
(plus:DI (reg:DI 96)
(const_int 768 [0x300]))) "array_test.c":7:5 4 {adddi3}
(expr_list:REG_DEAD (reg:DI 96)
(nil)))
i3 & Cost 16:
(insn 6 27 8 2 (set (reg:DI 82 [ MEM[(int *)array_5(D) + 800B] ])
(sign_extend:DI (mem:SI (plus:DI (reg:DI 96)
(const_int 800 [0x320])) [1 MEM[(int *)array_5(D) + 800B]+0
S4 A32]))) "array_test.c":7:5 90 {extendsidi2}
(nil))
newpat:
(set (reg:DI 82 [ MEM[(int *)array_5(D) + 800B] ])
(sign_extend:DI (mem:SI (plus:DI (reg:DI 96)
(const_int 800 [0x320])) [1 MEM[(int *)array_5(D) + 800B]+0 S4
A32])))
newi2pat:
(set (reg/f:DI 92)
(plus:DI (reg:DI 96)
(const_int 768 [0x300])))
newotherpat:
(nil)
GO!---
OLD===1681692777===OLD
i2 & Cost 4:
(insn 27 3 6 2 (set (reg/f:DI 92)
(plus:DI (reg:DI 96)
(const_int 768 [0x300]))) "array_test.c":7:5 4 {adddi3}
(nil))
i3 & Cost 16:
(insn 8 6 10 2 (set (reg:DI 84 [ MEM[(int *)array_5(D) + 804B] ])
(sign_extend:DI (mem:SI (plus:DI (reg:DI 96)
(const_int 804 [0x324])) [1 MEM[(int *)array_5(D) + 804B]+0
S4 A32]))) "array_test.c":7:5 90 {extendsidi2}
(nil))
Old Cost 20:
NEW===1681692777===NEW
New_Cost: 20
i0 & Cost 0:
(nil)
i1 & Cost 0:
(nil)
i2 & Cost 4:
(insn 27 3 6 2 (set (reg/f:DI 92)
(plus:DI (reg:DI 96)
(const_int 768 [0x300]))) "array_test.c":7:5 4 {adddi3}
(nil))
i3 & Cost 16:
(insn 8 6 10 2 (set (reg:DI 84 [ MEM[(int *)array_5(D) + 804B] ])
(sign_extend:DI (mem:SI (plus:DI (reg:DI 96)
(const_int 804 [0x324])) [1 MEM[(int *)array_5(D) + 804B]+0
S4 A32]))) "array_test.c":7:5 90 {extendsidi2}
(nil))
newpat:
(set (reg:DI 84 [ MEM[(int *)array_5(D) + 804B] ])
(sign_extend:DI (mem:SI (plus:DI (reg:DI 96)
(const_int 804 [0x324])) [1 MEM[(int *)array_5(D) + 804B]+0 S4
A32])))
newi2pat:
(set (reg/f:DI 92)
(plus:DI (reg:DI 96)
(const_int 768 [0x300])))
newotherpat:
(nil)
GO!---
OLD===1714636915===OLD
i2 & Cost 4:
(insn 27 3 6 2 (set (reg/f:DI 92)
(plus:DI (reg:DI 96)
(const_int 768 [0x300]))) "array_test.c":7:5 4 {adddi3}
(nil))
i3 & Cost 16:
(insn 12 10 14 2 (set (reg:DI 87 [ MEM[(int *)array_5(D) + 808B] ])
(sign_extend:DI (mem:SI (plus:DI (reg:DI 96)
(const_int 808 [0x328])) [1 MEM[(int *)array_5(D) + 808B]+0
S4 A32]))) "array_test.c":8:5 90 {extendsidi2}
(nil))
Old Cost 20:
NEW===1714636915===NEW
New_Cost: 20
i0 & Cost 0:
(nil)
i1 & Cost 0:
(nil)
i2 & Cost 4:
(insn 27 3 6 2 (set (reg/f:DI 92)
(plus:DI (reg:DI 96)
(const_int 768 [0x300]))) "array_test.c":7:5 4 {adddi3}
(nil))
i3 & Cost 16:
(insn 12 10 14 2 (set (reg:DI 87 [ MEM[(int *)array_5(D) + 808B] ])
(sign_extend:DI (mem:SI (plus:DI (reg:DI 96)
(const_int 808 [0x328])) [1 MEM[(int *)array_5(D) + 808B]+0
S4 A32]))) "array_test.c":8:5 90 {extendsidi2}
(nil))
newpat:
(set (reg:DI 87 [ MEM[(int *)array_5(D) + 808B] ])
(sign_extend:DI (mem:SI (plus:DI (reg:DI 96)
(const_int 808 [0x328])) [1 MEM[(int *)array_5(D) + 808B]+0 S4
A32])))
newi2pat:
(set (reg/f:DI 92)
(plus:DI (reg:DI 96)
(const_int 768 [0x300])))
newotherpat:
(nil)
GO!---
OLD===1957747793===OLD
i2 & Cost 4:
(insn 27 3 6 2 (set (reg/f:DI 92)
(plus:DI (reg:DI 96)
(const_int 768 [0x300]))) "array_test.c":7:5 4 {adddi3}
(nil))
i3 & Cost 16:
(insn 16 14 18 2 (set (reg:DI 90 [ MEM[(int *)ar
[Bug target/97417] RISC-V Unnecessary andi instruction when loading volatile bool
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 = | # of unexpected case / # of unique unexpected case | gcc | g++ | gfortran | rv64imafdc/ lp64d/ medlow |0 / 0 |0 / 0 | - | I'll merge all 3 patches together and fix all the debug/coding style/efficiency /whatever problem with explanations later this week. Looks likes it's fixed from my side.
[Bug target/97417] RISC-V Unnecessary andi instruction when loading volatile bool
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417 Levy changed: What|Removed |Added Attachment #49543|0 |1 is obsolete|| Attachment #49575|0 |1 is obsolete|| Attachment #49757|0 |1 is obsolete|| --- Comment #49 from Levy --- Created attachment 49767 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49767&action=edit Auto-extend Patch Combined all three patches. = Summary of gcc testsuite = | # of unexpected case / # of unique unexpected case | gcc | g++ | gfortran | rv64imafdc/ lp64d/ medlow |0 / 0 |0 / 0 | - | (May require some work on coding style)
[Bug target/97417] RISC-V Unnecessary andi instruction when loading volatile bool
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 flag and UNITS_PER_WORD check or maybe Just skip over a ZERO_EXTEND or SIGN_EXTEND before the general_operand check, but that seems inconvenient. Probably need more testing on all patches to see the differences in code size & speed. Maybe after EEMBC results come out then decide what to proceed next.
[Bug c++/98485] New: Symbols for identical constrained specializations have different linkage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98485 Bug ID: 98485 Summary: Symbols for identical constrained specializations have different linkage Product: gcc Version: 10.2.0 Status: UNCONFIRMED Severity: 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 code When using multiple constrained specializations, the symbols generated have different linkage based on the order the specializations are defined in the file. The first specialization will generate weak symbols as expected, the second generates local symbols. See attached example. S1 is a structure containing a static member function. S2 and S3 differ in some way that's detectable through concepts. main.cpp can only see these definitions so all it knows is that S1::f() is forward declared. a.cpp and b.cpp include s1-defs.h which contains two basically identical specializations of S1. The first is applied for S2, the second for S3. a.cpp instantiates S1. b.cpp instantiates S1. These do not need to be separate files, this was just done to make it easier to diff the two outputs. What you will notice is that a.o contains an externally visible S1::f1 symbol. b.o contains a local S1::f1 symbol. Thus the program can't link since main can't reference S1::f1. Despite there being basically no difference in the two specializations the linkage is unexpectedly different. If the order of the two specializations in s1-defs.h is reversed then S1::f1 will become problematic. In s1-defs.h there's a USE_SINGLE define which when toggled uses if constexpr instead of two specializations. This effectively works around the issue and the program links.
[Bug c++/98485] Symbols for identical constrained specializations have different linkage
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 actually considered a different definition? Thinking of C++20 6.3 paragraph 13.8 here. While same sequence of tokens isn't strictly true in the provided example, one could easily hoist the definitions of f1 out of the structure definition to make each specialization exactly the same as the base template and GCC still wants to use internal linkage for the second specialization. Not that it technically would matter if it's indeed an ODR violation, but Clang does seem to work as expected for this scenario.
[Bug c++/98485] Symbols for identical constrained specializations have different linkage
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 thing hidden is the S1::f1 definition itself which should be valid to do given explicit instantiations. Same behavior of the second specialization having different linkage for some reason. Although in this case a compiler warning is produced on main.cpp. main.h:25:28: warning: ‘static void S1::f1() [with T = S3]’ used but never defined Interestingly despite presumably being more well defined Clang 11 doesn't like this version at all.
[Bug tree-optimization/106315] [13 Regression] 7.8% increased codesize on specfp 507.cactuBSSN_r
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%
[Bug tree-optimization/106315] [13 Regression] 7.8% increased codesize on specfp 507.cactuBSSN_r
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: 372967 Size2: 408964 File: LocalReduce/Norm4Functions.o Size1: 378371 Size2: 434948 File: LocalReduce/Norm1Functions.o Size1: 370431 Size2: 442340 File: LocalReduce/Norm2Functions.o Size1: 373212 Size2: 460212 File: LocalReduce/SumFunctions.o Size1: 373858 Size2: 452466 File: LocalReduce/AvgFunctions.o Size1: 379238 Size2: 437511 File: LocalReduce/NormInfFunctions.o Size1: 374379 Size2: 384654 File: LocalReduce/MaxFunctions.o Size1: 377728 Size2: 387170 File: LocalReduce/MinFunctions.o Size1: 379068 Size2: 395071 File: LocalReduce/Norm3Functions.o Size1: 7136496 Size2: 7640664 File: cactusBSSN_r Not sure if they were caused by the same head file
[Bug tree-optimization/104058] New: [12 Regression] 6-7% x264_r regression with -march=native -Ofast -funroll-loops -flto on x86 since r12-6420-gd3ff7420e941931d32ce2e332e7968fe67ba20af
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104058 Bug ID: 104058 Summary: [12 Regression] 6-7% x264_r regression with -march=native -Ofast -funroll-loops -flto on x86 since r12-6420-gd3ff7420e941931d32ce2e332e7968fe67ba20af 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 regression on 525.x264_r with commit d3ff7420e941931d32ce2e332e7968fe67ba20af On IceLake(8358): -7.27% On Zen3(7763): -6.67% On Zen3(5800x): -6.45% The regression on Zen 3 can also be found in https://lnt.opensuse.org/db_default/v4/SPEC/graph?highlight_run=22984&plot.0=475.377.0
[Bug tree-optimization/104058] [12 Regression] 6-7% x264_r regression with -march=native -Ofast -funroll-loops -flto on x86 since r12-6420-gd3ff7420e941931d32ce2e332e7968fe67ba20af
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104058 Levy Hsu changed: What|Removed |Added Resolution|--- |FIXED Status|WAITING |RESOLVED --- Comment #4 from Levy Hsu --- SkyLake +6.79% CascadeLake +7.56% Zen2 +5.77% Look likes it's resolved. We'll track it further in weekly report. Thanks
[Bug middle-end/26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)
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/bugzilla/show_bug.cgi?id=104058 What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/53947] [meta-bug] vectorizer missed-optimizations
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/bugzilla/show_bug.cgi?id=104058 What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED
[Bug regression/103997] [12 Regression] gcc.target/i386/pr88531-??.c scan-assembler-times FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103997 Levy Hsu changed: What|Removed |Added CC||admin at levyhsu dot com --- Comment #9 from Levy Hsu --- Compare to one commit before (ffc7f200adbdf47f14b3594d9b21855c19cf797a) commit r12-6740-gf4ca0a53be18dfc7162fd5dcc1e73c4203805e14 causes regression on AlderLake (12900K) Multi-Core 548.exchange2_r -3.48% Skylake Workstation(7920x) Single Core 538.imagick_r -2.29% 549.fotonik3d_r -3.81% With label march_native_ofast_lto and 5 iterations -march=native -Ofast -funroll-loops -flto
[Bug regression/103997] [12 Regression] gcc.target/i386/pr88531-??.c scan-assembler-times FAILs
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 some different binary, but too long to dig deep. I'll fix the Vtune and see if I can get some results back.
[Bug regression/103997] [12 Regression] gcc.target/i386/pr88531-??.c scan-assembler-times FAILs
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.
[Bug tree-optimization/103223] [12 regression] Access attribute dropped when ipa-sra is applied
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103223 Levy changed: What|Removed |Added CC||admin at levyhsu dot com --- Comment #10 from Levy --- Hi Jan Just want provide a status report that this commit ecdf414bd89e6ba251f6b3f494407139b4dbae0e seems to caused about 50% regression when running multi-copy 548.exchange2_r with march_native_ofast_lto on spec2017: Xeon(R) Platinum 8358 (IceLake) (64C 128T 512G): BenchMarks Copies RunTime1RunTime2Rate1 Rate2 Compare 548.exchange2_r 128 479 913 700 367 -47.57% Xeon(R) Gold 6252 (CascadeLake) (48C 96T 192G) BenchMarks Copies RunTime1RunTime2Rate1 Rate2 Compare 548.exchange2_r 96 643 1240391 203 -48.08% Best Levy
[Bug tree-optimization/105643] New: [13 Regression] Code-Size regression for specrate 538.imagick_r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105643 Bug ID: 105643 Summary: [13 Regression] Code-Size regression for specrate 538.imagick_r Product: gcc Version: 13.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 found on Intel platform, commit r13-128-g938a02a589dc22 (938a02a589dc22cef65bba2b131fc9e4874baddb) results 53.7% codesize increment when compiled with march_native_ofast_lto(-march=native -Ofast -funroll-loops -flto) for specrate 538.imagick_r on SkylakeW, Cascade Lake and IceLake. On Zen3 Server/Client code size looks alright.
