https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69124
--- Comment #5 from Mikael Pettersson ---
The OP's compiler has --with-mode=thumb! If I compile with
-mtune=generic-armv7-a -mthumb then I see the following errors from the test
case:
12 0xc0b165f1 != 0xdf5e0cae
13 0x8b329fe4 != 0x8b329fe3
19 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69124
Mikael Pettersson changed:
What|Removed |Added
CC||mikpelinux at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67781
--- Comment #10 from Mikael Pettersson ---
(In reply to Thomas Preud'homme from comment #9)
> I have a patch that seems to be working. Running regression testing and
> bootstrap now.
Is there any progress on that patch?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69051
--- Comment #3 from Mikael Pettersson ---
Sounds like you're using the wrong target. m68k-linux implies a 68020, 030,
040, or 060 CPU, and they don't have alignment constraints. Perhaps you should
be using an m68k-elf toolchain?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69037
--- Comment #3 from Mikael Pettersson ---
Trunk had the same regression, until r231374 fixed it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69037
--- Comment #2 from Mikael Pettersson ---
Started with r231722.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69037
Mikael Pettersson changed:
What|Removed |Added
CC||mikpelinux at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67781
--- Comment #5 from Mikael Pettersson ---
m68k is also affected, so it looks like all big-endian targets have this bug:
--- shift.s-m68k-r2108422015-12-12 18:50:53.358503028 +0100
+++ shift.s-m68k-r2108432015-12-12 18:54:43.93835
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67781
Mikael Pettersson changed:
What|Removed |Added
CC||thomas.preudhomme at arm dot
com
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67781
Mikael Pettersson changed:
What|Removed |Added
CC||mikpelinux at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68840
--- Comment #1 from Mikael Pettersson ---
Your program invokes undefined behaviour by running off the end of that array.
Your loop termination condition is off by one. It's also the wrong way around:
you must check the index before indexing the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68328
--- Comment #3 from Mikael Pettersson ---
I'm on Fedora 20 / x86_64 (Ivy Bridge i7-3770K) w/ the 4.3 Linux kernel. I've
tried various combinations of bootstrap compiler (system gcc-4.8.3 or my own
gcc-4.9.3 + patches), support libraries (system
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68298
Mikael Pettersson changed:
What|Removed |Added
CC||mikpelinux at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68328
Mikael Pettersson changed:
What|Removed |Added
CC||mikpelinux at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68184
Mikael Pettersson changed:
What|Removed |Added
CC||mikpelinux at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68189
--- Comment #7 from Mikael Pettersson ---
(In reply to Mikael Pettersson from comment #6)
> Started with r208165 (on x86_64-linux with -O3).
And the subsequent fix in r208222 does not help for this test case.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68189
Mikael Pettersson changed:
What|Removed |Added
CC||mikpelinux at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68067
Mikael Pettersson changed:
What|Removed |Added
CC||mikpelinux at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67474
Mikael Pettersson changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67474
--- Comment #2 from Mikael Pettersson ---
Still occurs with gcc-6-20150927. Started with r227382, an LRA patch.
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: mikpelinux at gmail dot com
Target Milestone: ---
Attempting to bootstrap gcc-6-20150920 (r227952) on s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67474
--- Comment #1 from Mikael Pettersson ---
Still occurs with gcc-6-20150920.
oduct: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: mikpelinux at gmail dot com
Target Milestone: ---
The last snapshot of trunk I was able to bo
: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: mikpelinux at gmail dot com
Target Milestone: ---
Attempting to bootstrap gcc-6-20150906 on armv7l w/ hard float fails with:
/mnt/scratch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67037
--- Comment #3 from Mikael Pettersson ---
Started with r206023, an LRA patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65358
--- Comment #28 from Mikael Pettersson ---
See PR67226 for another testcase that fails on ARM with the final fix for this
PR (r223753), but succeeds with the initial proposed fix posted in:
https://gcc.gnu.org/ml/gcc-patches/2015-03/msg01014.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67226
--- Comment #2 from Mikael Pettersson ---
This bug is clearly related to PR65358. This PR's test case is NOT fixed by
the final fix for PR65358 (r223753), but it IS fixed (on both trunk and gcc-5
branch) by the initial proposed fix for PR65358:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67226
Mikael Pettersson changed:
What|Removed |Added
CC||mikpelinux at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67223
--- Comment #1 from Mikael Pettersson ---
You didn't provide a self-contained test case. After extracting stats_record
and the stats declaration from the source to linked to and providing my own
stats_alloc (I'm not using your zcalloc), I cannot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67037
Mikael Pettersson changed:
What|Removed |Added
CC||mikpelinux at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66964
Mikael Pettersson changed:
What|Removed |Added
CC||mikpelinux at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66917
--- Comment #2 from Mikael Pettersson ---
This test case changed behaviour twice in the 4.7->4.8 development cycle.
First r185807 broke it by replacing code for unaligned memory accesses with
code requiring more alignment than present in the sou
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66917
Mikael Pettersson changed:
What|Removed |Added
CC||mikpelinux at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66876
Mikael Pettersson changed:
What|Removed |Added
CC||mikpelinux at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66809
--- Comment #3 from Mikael Pettersson ---
The --with-gmp= etc options work for include files and static link libraries.
but do nothing for shared libraries.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66809
--- Comment #1 from Mikael Pettersson ---
> ld.so.1: cc1: fatal: libmpc.so.3: open failed: No such file or directory
> xgcc: internal compiler error: Killed (program cc1)
You need to
1. Tell the dynamic linker where to find the gmp etc shared l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58493
--- Comment #6 from Mikael Pettersson ---
(In reply to vgrebin...@gmail.com from comment #5)
> (In reply to Mikael Pettersson from comment #4)
> > Checked that this works with current gcc-6/5/4.9. Can this be closed now?
>
> I'm fine to close i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57859
--- Comment #3 from Mikael Pettersson ---
-ftrapv seems to be working a bit better in gcc-6: only the first test case
fails (doesn't report the overflow) at -O1/2 for both -m32/-m64, but all other
combinations of test case, -O0 vs -O1/2, and -m32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58493
--- Comment #4 from Mikael Pettersson ---
Checked that this works with current gcc-6/5/4.9. Can this be closed now?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66754
Mikael Pettersson changed:
What|Removed |Added
CC||mikpelinux at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66186
Mikael Pettersson changed:
What|Removed |Added
CC||mikpelinux at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=6
--- Comment #10 from Mikael Pettersson ---
(In reply to Antonio Poggiali from comment #9)
> Sorry, this code:
>
> https://gcc.gnu.org/viewcvs/gcc/trunk/gcc/cgraphunit.
> c?r1=221077&r2=221076&pathrev=221077
Yes, but I'm not convinced it's the r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=6
--- Comment #7 from Mikael Pettersson ---
The test case in comment #0 stopped breaking on trunk with r221077, the fix for
PR65236 (a gcc-5 IPA regression). Backporting r221077 to 4.9.3 unbreaks this
test case there. However:
- I can't get this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=6
Mikael Pettersson changed:
What|Removed |Added
CC||mikpelinux at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66598
--- Comment #2 from Mikael Pettersson ---
Started with r197189.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66598
Mikael Pettersson changed:
What|Removed |Added
CC||mikpelinux at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66252
--- Comment #3 from Mikael Pettersson ---
Still occurs with trunk @ r223652.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66252
--- Comment #1 from Mikael Pettersson ---
Started with r67:
fc6cc27b3f46a6f70f610ec93a1c5e68d83c933b is the first bad commit
commit fc6cc27b3f46a6f70f610ec93a1c5e68d83c933b
Author: rguenth
Date: Tue Apr 21 12:52:43 2015 +
2015-04
Priority: P3
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: mikpelinux at gmail dot com
Target Milestone: ---
Attempting to bootstrap gcc trunk on sparc64-linux with options to default to
32-bit code, fails with:
Comparing stages 2 and 3
Priority: P3
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: mikpelinux at gmail dot com
Target Milestone: ---
Attempting to bootstrap gcc-6-20150510 on powerpc64-linux fails with:
/mnt/scratch/objdir6/./prev-gcc/xg++ -B/mnt/scratch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61114
Mikael Pettersson changed:
What|Removed |Added
CC||mikpelinux at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64972
--- Comment #9 from Mikael Pettersson ---
Please note that sizeof(long) == 4 while sizeof(size_t) == sizeof(void*) == 8
on x86_64-w64-mingw32, so your patch changes the behaviour of the code.
Perhaps the change is benign, but I'd use uintptr_t a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63234
--- Comment #8 from Mikael Pettersson ---
The failures on 4.7+ seem to be triggered by r177855, yet another ARM costing
tweak.
I'm not going to investigate this any further.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63234
--- Comment #7 from Mikael Pettersson ---
The wrong-code started in the 4.7 dev cycle with r183328, a fix for a similar
bug (PR50313) in 4.6. That fix was backported to 4.6 but doesn't trigger this
PR there (I just re-checked with 4.6.4).
The b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65358
--- Comment #6 from Mikael Pettersson ---
(In reply to Honggyu Kim from comment #4)
> Can I add this testcase with your modification as my first gcc contribution?
> :)
Sure, just attach it to this PR as a new test case.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65358
Mikael Pettersson changed:
What|Removed |Added
CC||mikpelinux at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62109
--- Comment #3 from Mikael Pettersson ---
Do you have a test case which fails without your patch?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65090
--- Comment #1 from Mikael Pettersson ---
I can reproduce the wrong-code with g++ 4.7.4 on sparc64-linux, but g++ 4.8.4
and 5 (current trunk) work.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64941
Mikael Pettersson changed:
What|Removed |Added
CC||mikpelinux at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64756
--- Comment #2 from Mikael Pettersson ---
Also fails on m68k, but not on powerpc64, sparc64, or ARMv5.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64756
Mikael Pettersson changed:
What|Removed |Added
CC||mikpelinux at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57748
--- Comment #65 from Mikael Pettersson ---
(In reply to Bernd Edlinger from comment #64)
> (In reply to Mikael Pettersson from comment #63)
> > The backport request has been posted:
> >
> > https://gcc.gnu.org/ml/gcc-patches/2015-01/msg02192.htm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57748
--- Comment #63 from Mikael Pettersson ---
The backport request has been posted:
https://gcc.gnu.org/ml/gcc-patches/2015-01/msg02192.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57748
--- Comment #62 from Mikael Pettersson ---
(In reply to Bernd Edlinger from comment #61)
> if you already have used/tested that patch on 4.8 for such a long time,
> I would appreciate it very much if you post it on the gcc-patches mailing
> list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57748
Mikael Pettersson changed:
What|Removed |Added
CC||mikpelinux at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64451
--- Comment #1 from Mikael Pettersson ---
The ICE started with r189458, still occurs with 4.8.4, 4.9.2, and current
trunk.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64442
--- Comment #3 from Mikael Pettersson ---
See PR323 and https://gcc.gnu.org/bugs/#known
You could experiment with -ffloat-store, -mpc64, or -msse2 (if your CPU
supports SSE2, which it should if it isn't ancient).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64442
--- Comment #1 from Mikael Pettersson ---
Are you compiling on 32-bit x86? I can reproduce on m68k, but not on x86_64
(even with -m32) or on ARMv5. I suspect you're seeing the effects of excess
precision of the x87 FPU (much like the m68k FPU).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63681
--- Comment #5 from Mikael Pettersson ---
The ICE on bfin-elf started for 4.9 with r204985, and stopped for 5.0 with
r210683. Backporting r210683 to current 4.9 branch is easy and fixes the ICE
there too. I haven't checked c6x.
See also:
https
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64172
Mikael Pettersson changed:
What|Removed |Added
CC||mikpelinux at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50865
Mikael Pettersson changed:
What|Removed |Added
Attachment #34323|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50865
Mikael Pettersson changed:
What|Removed |Added
CC||mikpelinux at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64379
Mikael Pettersson changed:
What|Removed |Added
CC||mikpelinux at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64379
--- Comment #5 from Mikael Pettersson ---
I can reproduce the wrong-code with gcc-4.9.2 on armv7l-linux-gnueabi. Appears
to need both -foptimize-sibling-calls and -mapcs-frame to trigger.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64379
--- Comment #3 from Mikael Pettersson ---
Can you add a main() with the necessary parameter setup and call to mark_set()
to make the testcase self-contained and executable? You can annotate
mark_set() with attribute((noinline,noclone)) to preven
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61931
--- Comment #5 from Mikael Pettersson ---
Created attachment 34307
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34307&action=edit
backport of r197965 (without neon bits) + testcase
Patch which fixes this testcase; I'll do a full bootstra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61931
--- Comment #4 from Mikael Pettersson ---
This was fixed for 4.9 by r197965.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61931
Mikael Pettersson changed:
What|Removed |Added
CC||mikpelinux at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64294
--- Comment #10 from Mikael Pettersson ---
You're invoking undefined behaviour due to overflow in signed integer
arithmetic.
Running it after compiling with -fsanitize=undefined produces:
petite.c:391:28: runtime error: signed integer overflow:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57569
Mikael Pettersson changed:
What|Removed |Added
CC||mikpelinux at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64294
--- Comment #7 from Mikael Pettersson ---
The testcases don't build due to linkage errors. Please submit a
self-contained and preferably minimized testcase.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64364
--- Comment #2 from Mikael Pettersson ---
Re-run g++ on the testcase with the -v flag, note the command line for cc1plus,
run cc1plus from gdb with that command line, and show us the faulting
instruction and what code/function it occurs in.
You
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63347
--- Comment #9 from Mikael Pettersson ---
This wrong-code started with Bernd's r171845, possibly by exposing a latent
issue.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63375
--- Comment #17 from Mikael Pettersson ---
(In reply to Pranith Kumar from comment #16)
> printf("%d\n", *(int *)(&val1+4));
This is broken, you're invoking undefined behaviour.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63624
Mikael Pettersson changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63645
--- Comment #25 from Mikael Pettersson ---
So, is there a way to under-allocate a union (just allocate enough for the
member you want) and access it via the union pointer that is valid C?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63645
--- Comment #10 from Mikael Pettersson ---
I now think the test case is invalid. There is special provision in the
standard for accessing "the wrong member" of a union, but the member has to be
a struct type which shares a prefix with the curren
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63645
--- Comment #9 from Mikael Pettersson ---
Can you tweak the testcase into something that throws an actual runtime error
(by faulting or returning 1 from main or doing exit(1)) instead of relying on
valgrind (which I don't trust) to spot a/the pro
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: mikpelinux at gmail dot com
Attempting to bootstrap gcc-5-20141019 (r216444) on m68k-linux fails with:
mkdir -p ./m68k
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61770
--- Comment #2 from Mikael Pettersson ---
(In reply to R. Dragone from comment #1)
> Just encountered the same problem myself.
>
> >> gcc -march=native -E -v - &1 | grep cc1
> /usr/libexec/gcc/x86_64-pc-linux-gnu/4.7.3/cc1 -E -quiet -v -
> -mar
: normal
Priority: P3
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: mikpelinux at gmail dot com
Attempting to bootstrap gcc-5-20141012 on sparc-linux (sparc64 w/ --build and
--target overridden) fails with:
/mnt/scratch/objdir50/./prev-gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63347
Mikael Pettersson changed:
What|Removed |Added
CC||mikpelinux at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63461
--- Comment #5 from Mikael Pettersson ---
Use .pushsection and .popsection .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63347
--- Comment #3 from Mikael Pettersson ---
I can't reproduce with a vanilla gcc-4.8.3 configured for m68k-elf. For the
"if (0x0 == haddr) ..." it generates:
lea (20,%sp),%sp
tst.l %d2
seq %d2
extb.l %d2
ne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63302
Mikael Pettersson changed:
What|Removed |Added
CC||mikpelinux at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63395
--- Comment #10 from Mikael Pettersson ---
I strongly suspect 32-bit Cygwin uses x87 by default, while 64-bit Cygwin
probably uses SSE2 by default. These two FP implementations are very
different, and it's not at all surprising to see different
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63394
--- Comment #1 from Mikael Pettersson ---
(In reply to Bruce Dale from comment #0)
> gcc build options: unknown
"gcc -v" will tell you that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63393
--- Comment #3 from Mikael Pettersson ---
I don't know if this is supposed to be "fixed" (for all str* and mem* functions
one might want to implement oneself), but the standard workaround is to compile
with -fno-tree-loop-distribute-patterns. Th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63373
--- Comment #2 from Mikael Pettersson ---
Related to PR57180?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63234
--- Comment #4 from Mikael Pettersson ---
(apparently TAB became "save changes", how weird...)
... but .LPIC3 is not defined at all. .LPIC[0124] are all defined and used.
201 - 300 of 421 matches
Mail list logo
