https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117186
Mikael Pettersson changed:
What|Removed |Added
CC||mikpelinux at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116806
Mikael Pettersson changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116806
--- Comment #2 from Mikael Pettersson ---
(In reply to Andrew Pinski from comment #1)
> ```
> #define B ((int) ((unsigned char) '\234' * (unsigned)scale + (unsigned char)
> 'b'))
> ```
That fixes the test case on the five 16-bit targets.
I'll
Component: testsuite
Assignee: unassigned at gcc dot gnu.org
Reporter: mikpelinux at gmail dot com
Target Milestone: ---
The following is adapted from gcc.dg/cpp/charconst-3.c:
==snip==
void foo (int);
void __attribute__ ((__noreturn__)) _exit (int);
#define A '\234b'
Priority: P3
Component: testsuite
Assignee: unassigned at gcc dot gnu.org
Reporter: mikpelinux at gmail dot com
Target Milestone: ---
The pr52286.c test case does the following on 16-bit targets:
long a, b;
asm ("" : "=r" (a) : &qu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93192
--- Comment #6 from Mikael Pettersson ---
Probably fixed for gcc-14.1.0 by e0c1476d5d7c450b1b16a40364cea4e91237ea93. The
original proposed patch no longer applies.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113357
--- Comment #14 from Mikael Pettersson ---
Since gcc-15 wouldn't build due to an unrelated issue, I applied the fmo patch
to gcc-14.1 (which also has this bug) and bootstrapped that. Alas it didn't
make any difference, same error in stage2 as in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113357
--- Comment #13 from Mikael Pettersson ---
(In reply to Mikael Pettersson from comment #9)
> (In reply to Manolis Tsamis from comment #8)
> > Created attachment 58335 [details]
> > Do not modify live_out registers
> >
> > After looking again at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113357
--- Comment #9 from Mikael Pettersson ---
(In reply to Manolis Tsamis from comment #8)
> Created attachment 58335 [details]
> Do not modify live_out registers
>
> After looking again at the dumps from PR112415, which I believe is closely
> rela
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113551
Mikael Pettersson changed:
What|Removed |Added
CC||mikpelinux at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115010
Mikael Pettersson changed:
What|Removed |Added
CC||mikpelinux at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114937
--- Comment #5 from Mikael Pettersson ---
I ran a git bisect between 11.4.0 and 12.3.0, which identified the following as
fixing this test case:
2e96b5f14e4025691b57d2301d71aa6092ed44bc is the first new commit
commit 2e96b5f14e4025691b57d2301d7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114910
--- Comment #8 from Mikael Pettersson ---
According to my git bisect, the assembler error started with
551935d11817dd5b139d66c36f62c0f0eba0db06 is the first new commit
commit 551935d11817dd5b139d66c36f62c0f0eba0db06
Author: Alexandre Oliva
Dat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114910
Mikael Pettersson changed:
What|Removed |Added
CC||mikpelinux at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114910
--- Comment #5 from Mikael Pettersson ---
I don't use crosstool-ng, but I have no problems building a cross to
c6x-unknown-elf with binutils-2.42, gcc-14.1.0-RC-20240430, and
newlib-4.4.0.20231231. (A cross to c6x-unknown-uclibc with uclibc-ng-1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113779
--- Comment #4 from Mikael Pettersson ---
I'm not sure this is an m68k bug. I tried several targets that have
auto-increment addressing modes (m68k, pdp11, msp430, vax, aarch64) and none of
them would use auto-increment for this test case.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113357
--- Comment #4 from Mikael Pettersson ---
Confirmed:
04c9cf5c786b94fbe3f6f21f06cae73a7575ff7a is the first new commit
commit 04c9cf5c786b94fbe3f6f21f06cae73a7575ff7a
Author: Manolis Tsamis
Date: Mon Oct 16 13:08:12 2023 -0600
Implement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113357
--- Comment #3 from Mikael Pettersson ---
git bisect identified the following as the start of this error:
# new: [04c9cf5c786b94fbe3f6f21f06cae73a7575ff7a] Implement new RTL
optimizations pass: fold-mem-offsets
Note the error still reproduced
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82420
--- Comment #6 from Mikael Pettersson ---
Updated patch posted:
https://gcc.gnu.org/pipermail/gcc-patches/2024-January/643139.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110934
--- Comment #12 from Mikael Pettersson ---
Patch posted:
https://gcc.gnu.org/pipermail/gcc-patches/2024-January/643276.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108640
--- Comment #7 from Mikael Pettersson ---
Patch posted:
https://gcc.gnu.org/pipermail/gcc-patches/2024-January/643383.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113324
Mikael Pettersson changed:
What|Removed |Added
CC||mikpelinux at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113357
--- Comment #2 from Mikael Pettersson ---
/mnt/scratch/gcc-14-20240107/configure --prefix=/mnt/scratch/install14
--enable-bootstrap --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disab
Severity: normal
Priority: P3
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: mikpelinux at gmail dot com
Target Milestone: ---
gcc-14 native(*) bootstrap on m68k-linux-gnu fails during stage2 as follows:
ranlib libgcov.a
/mnt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113324
--- Comment #2 from Mikael Pettersson ---
I can reproduce with gcc-10.5.0 hosted on x86_64-pc-linux-gnu targeting
vax-netbsdelf, but not with gcc-11.4.0. 12.3.0, or 13.2.0.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105525
Mikael Pettersson changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110934
--- Comment #11 from Mikael Pettersson ---
Reduced test case:
> cat ../pr110934.c
extern double clobber_fp0(void);
void f(void) { clobber_fp0(); }
> gcc/xgcc -Bgcc -fzero-call-used-regs=used -fPIC -O -S ../pr110934.c
during RTL pass: zero_call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82420
--- Comment #5 from Mikael Pettersson ---
Patch submitted:
https://gcc.gnu.org/pipermail/gcc-patches/2024-January/641800.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111279
Mikael Pettersson changed:
What|Removed |Added
CC||mikpelinux at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82420
--- Comment #4 from Mikael Pettersson ---
Created attachment 56985
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56985&action=edit
proposed fix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110627
Mikael Pettersson changed:
What|Removed |Added
CC||mikpelinux at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104028
Mikael Pettersson changed:
What|Removed |Added
CC||mikpelinux at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109133
Mikael Pettersson changed:
What|Removed |Added
CC||mikpelinux at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80786
Mikael Pettersson changed:
What|Removed |Added
CC||mikpelinux at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108640
--- Comment #6 from Mikael Pettersson ---
Created attachment 56965
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56965&action=edit
Preliminary patch, only tested on the test case so far.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108640
Mikael Pettersson changed:
What|Removed |Added
CC||mikpelinux at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113086
Mikael Pettersson changed:
What|Removed |Added
CC||mikpelinux at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110934
--- Comment #9 from Mikael Pettersson ---
Created attachment 56961
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56961&action=edit
proposed fix, only tested on the given test case so far
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110934
--- Comment #8 from Mikael Pettersson ---
The generic code synthesizes a move from CONST0_RTX (XFmode) to an XFmode FP
reg, and that causes the ice. Forcing the mode of both to SFmode or DFmode
avoids the ice and generates sane-looking code. The
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110934
--- Comment #7 from Mikael Pettersson ---
The issue appears to be the clearing of FP regs. If I add an m68k-specific
version of TARGET_ZERO_CALL_USED_REGS which handles integer (address and data)
regs but skips FP regs, then the test case compil
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110934
--- Comment #6 from Mikael Pettersson ---
Affects gcc-11 and newer, gcc-10 and older are ok. Started with:
d10f3e900b0377b4760a090b0f90371bcef01686 is the first new commit
commit d10f3e900b0377b4760a090b0f90371bcef01686
Author: qing zhao
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113049
--- Comment #2 from Mikael Pettersson ---
Does -fno-tree-loop-distribute-patterns work? That's been the go-to for
disabling similar loop-to-call transformations people have been objecting to.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112413
--- Comment #7 from Mikael Pettersson ---
Patch posted after bootstrap and regression testing on m68k-linux-gnu:
https://gcc.gnu.org/pipermail/gcc-patches/2023-December/640177.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112712
--- Comment #2 from Mikael Pettersson ---
It appears the test case comes from https://github.com/dxx-rebirth/dxx-rebirth/
(a port of the old Descent game engine).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112712
Mikael Pettersson changed:
What|Removed |Added
CC||mikpelinux at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112443
--- Comment #8 from Mikael Pettersson ---
Can this be closed now?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112701
--- Comment #2 from Mikael Pettersson ---
gcc-2.95.3 generates neither, gcc-3.0.4 and up generate the bar: .long 0 (or
.zero 4) one.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83324
--- Comment #5 from Mikael Pettersson ---
To get guaranteed tail-calls to work you need to adjust the calling convention
for the caller as well as the callee. Things are trivial as long as parameters
always fit in registers. With parameters on th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112413
--- Comment #5 from Mikael Pettersson ---
Created attachment 56561
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56561&action=edit
proposed fix, only compile-tested for now
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112413
Mikael Pettersson changed:
What|Removed |Added
CC||mikpelinux at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51
Mikael Pettersson changed:
What|Removed |Added
CC||mikpelinux at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111015
--- Comment #4 from Mikael Pettersson ---
Reverting the pass_store_merging::process_store hunk makes this test case work
again:
diff --git a/gcc/gimple-ssa-store-merging.cc b/gcc/gimple-ssa-store-merging.cc
index 0d19b98ed73..c4bf8eec64e 100644
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111015
Mikael Pettersson changed:
What|Removed |Added
CC||mikpelinux at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110934
Mikael Pettersson changed:
What|Removed |Added
CC||mikpelinux at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110702
Mikael Pettersson changed:
What|Removed |Added
CC||mikpelinux at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59178
Mikael Pettersson changed:
What|Removed |Added
CC||mikpelinux at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59172
Mikael Pettersson changed:
What|Removed |Added
CC||mikpelinux at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110668
--- Comment #3 from Mikael Pettersson ---
https://gcc.gnu.org/install/prerequisites.html, GNAT section, 4th paragraph.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110668
Mikael Pettersson changed:
What|Removed |Added
CC||mikpelinux at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87944
Mikael Pettersson changed:
What|Removed |Added
CC||mikpelinux at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109670
Mikael Pettersson changed:
What|Removed |Added
CC||mikpelinux at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105525
--- Comment #3 from Mikael Pettersson ---
Patch submitted:
https://gcc.gnu.org/pipermail/gcc-patches/2023-April/617071.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105525
--- Comment #2 from Mikael Pettersson ---
The issue issue remains in gcc-13.1.0 but is no longer limited to gcov, i.e. a
vax build with --disable-gcov using gcc-13.1.0 now fails with
In file included from
/mnt/scratch/cross/sources/gcc-13.1.0/l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109402
--- Comment #2 from Mikael Pettersson ---
Please send patches to gcc-patches for review.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109140
--- Comment #10 from Mikael Pettersson ---
A bisect between 4.6.4 (good) and 4.7.4 (bad) found:
1f9ed162eb30f1b40b65d164b3a40ac78e1f006e is the first bad commit
commit 1f9ed162eb30f1b40b65d164b3a40ac78e1f006e
Author: David S. Miller
Date: Tu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109140
--- Comment #9 from Mikael Pettersson ---
I can reproduce all the way down to gcc-4.7.4, gcc-4.6.4 doesn't support
-mcpu=niagara4.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109140
--- Comment #7 from Mikael Pettersson ---
With -O2 -ftree-vectorize -mcpu=niagara4 a bisect between 9.5.0 (good) and
10.4.0 (bad) found
6271dd984d7f920d4fb17ad37af6a1f8e6b796dc is the first bad commit
commit 6271dd984d7f920d4fb17ad37af6a1f8e6b7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109140
--- Comment #6 from Mikael Pettersson ---
With -O2 -ftree-vectorize -mcpu=niagara4 the ICE reproduces with gcc-10.4.0 but
not with gcc-9.5.0.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109140
Mikael Pettersson changed:
What|Removed |Added
CC||mikpelinux at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108657
--- Comment #11 from Mikael Pettersson ---
Bisected on x86_64-linux-gnu:
dc477ffb4aba21e9cf47de22a4df6f2b23849505 is the first bad commit
commit dc477ffb4aba21e9cf47de22a4df6f2b23849505
Author: Richard Biener
Date: Thu Jul 21 10:13:46 2022 +
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108640
--- Comment #2 from Mikael Pettersson ---
Happens with 11.3.0, 10.4.0, and 9.5.0 too, so shouldn't be related to the CC0
conversion.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108640
--- Comment #1 from Mikael Pettersson ---
I can reproduce. Doesn't happen with the m68k-linux-gnu target though.
> cross-m68k-uclinux/bin/m68k-unknown-uclinux-uclibc-gcc -Os -c /tmp/ls.i
during RTL pass: final
coreutils/ls.c: In function 'ls_m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101697
--- Comment #9 from Mikael Pettersson ---
I can confirm that building the latest uClibc-ng for h8300 now succeeds with
gcc master @ 4374c424a60777a7658050f0aeb1dcc9af915647.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106892
Mikael Pettersson changed:
What|Removed |Added
CC||mikpelinux at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93242
--- Comment #10 from Mikael Pettersson ---
(In reply to Ilya Leoshkevich from comment #9)
> Would it be possible to backport this to gcc-9?
...
> There is a workaround for now, but it would be good to have this fixed in
> all the maintained gccs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106609
--- Comment #12 from Mikael Pettersson ---
I tried compiling the gcc-13 cross compiler using the broken gcc-12 host
compiler and -mtune-ctrl=^use_bt but that didn't help.
I then tried rebuilding the broken gcc-12 host compiler with the new spli
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106609
--- Comment #9 from Mikael Pettersson ---
# first bad commit: [3155d51bfd1de8b6c4645dcb2292248a8d7cc3c9] [PATCH] PR
rtl-optimization/46235: Improved use of bt for bit tests on x86_64.
Starting with this commit, the host compiler (on x86_64-linu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106609
Mikael Pettersson changed:
What|Removed |Added
CC||mikpelinux at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106064
Mikael Pettersson changed:
What|Removed |Added
CC||mikpelinux at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106025
Mikael Pettersson changed:
What|Removed |Added
CC||mikpelinux at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105872
--- Comment #3 from Mikael Pettersson ---
Also see PR105874.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105872
Mikael Pettersson changed:
What|Removed |Added
CC||mikpelinux at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105681
Mikael Pettersson changed:
What|Removed |Added
CC||mikpelinux at gmail dot com
ormal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: mikpelinux at gmail dot com
Target Milestone: ---
Attempting to build a gcc-12.1.0 based cross-compiler to lm32-uclinux-uclibc or
vax-unknown-linux fails with
/mnt/sc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103722
Mikael Pettersson changed:
What|Removed |Added
CC||mikpelinux at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105292
--- Comment #2 from Mikael Pettersson ---
Works with gcc-9.4, ICEs with gcc-10.3 and above. Git bisect identified
# first bad commit: [9b75f56d4b7951c60a6563964a65787b95bc] Apply maximum
nunits for BB SLP
as the cause of the ICEs, though i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105292
Mikael Pettersson changed:
What|Removed |Added
CC||mikpelinux at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103083
Mikael Pettersson changed:
What|Removed |Added
CC||mikpelinux at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89040
Mikael Pettersson changed:
What|Removed |Added
CC||mikpelinux at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102133
--- Comment #10 from Mikael Pettersson ---
(In reply to Hongtao.liu from comment #2)
> But failed to configure for target mcore, i didn't find any reference in
> https://gcc.gnu.org/install/specific.html
>
> --target=mcore results in
> *** Conf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101697
--- Comment #3 from Mikael Pettersson ---
As far as I can tell the problem is introduced by reload.
With a gcc-11.2.0 cross, getaddrinfo.i.290r.ira has
(insn 161 159 163 31 (set (reg/f:SI 185)
(reg/f:SI 7 sp)) "libc/inet/getaddrinfo.c"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101697
--- Comment #1 from Mikael Pettersson ---
The ICE in gcc-11 started with:
[f16897cb4b1468374d63b1a6b12d8b7be845874a] H8 cc0 conversion
It changed from "unrecognizable insn" to "could not split insn" in gcc-12 with:
[549d7f4310f6f8c2c64efcb6f3ef
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: mikpelinux at gmail dot com
Target Milestone: ---
Created attachment 51226
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51226&action=edit
pre-processed source of u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93734
--- Comment #8 from Mikael Pettersson ---
I can't reproduce the wrong code using either the fortran test case in #c2 or
the C one in #c3 with gcc-9.4.0 on Kaby Lake R. If I revert the PR92420 fix
both test cases do reproduce the wrong code. Thus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80786
--- Comment #2 from Mikael Pettersson ---
Still ICEs gcc-12. m68k_legitimate_address_p () returns false for
(const:SI (plus:SI (symbol_ref:SI ("G") [flags 0x40] )
(const_int 6 [0x6])))
mode 4 (QI is 4)
which triggers the assert failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82420
--- Comment #3 from Mikael Pettersson ---
Still ICEs in gcc-12:
> gcc/xgcc -Bgcc -march=68000 -malign-int -S /tmp/pr82420.c
during RTL pass: expand
/tmp/pr82420.c: In function 'f':
/tmp/pr82420.c:3:4: internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101175
--- Comment #4 from Mikael Pettersson ---
(In reply to Uroš Bizjak from comment #3)
> (In reply to Mikael Pettersson from comment #2)
> > (In reply to Iru Cai from comment #0)
> > > Built with '-march=x86-64-v3 -O1', the following code generates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101175
--- Comment #2 from Mikael Pettersson ---
(In reply to Iru Cai from comment #0)
> Built with '-march=x86-64-v3 -O1', the following code generates a bsr
> instruction, which has undefined behavior when the source operand is zero,
> thus gives wro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99847
--- Comment #3 from Mikael Pettersson ---
I am almost certain that you need to use an m68k-elf toolchain rather than an
m68k-linux-gnu one for the CPU32. The linux toolchain targets the classic '020
CPU or above (030, 040, or 060) and mandates th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98590
Mikael Pettersson changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
1 - 100 of 422 matches
Mail list logo
