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 #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=64756
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=64941
Mikael Pettersson changed:
What|Removed |Added
CC||mikpelinux at gmail dot com
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=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=65358
Mikael Pettersson changed:
What|Removed |Added
CC||mikpelinux at gmail dot com
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.
: 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=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
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=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
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 #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=63624
Mikael Pettersson changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
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=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=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=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=57569
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=61931
Mikael Pettersson changed:
What|Removed |Added
CC||mikpelinux at gmail dot com
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
--- 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=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=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
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
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=64172
Mikael Pettersson changed:
What|Removed |Added
CC||mikpelinux at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61518
--- Comment #4 from Mikael Pettersson ---
Isn't this fixed now?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61517
--- Comment #4 from Mikael Pettersson ---
Isn't this fixed now?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61622
--- Comment #6 from Mikael Pettersson ---
This _is_ a dup of PR57431 -- unfortunately PR57431 didn't fill out the "known
to work" or "known to fail" fields, so you might think it only applied to
trunk-to-be-4.9.0, but in fact its test case also I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61680
Mikael Pettersson changed:
What|Removed |Added
CC||mikpelinux at gmail dot com
Version: 4.10.0
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-4.10-20140713 (r212499) on x86_64-linux fails w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61797
--- Comment #1 from Mikael Pettersson ---
decl_in_symtab_p is used under #ifdef ENABLE_CHECKING by symtab_get_node (also
in craph.h), and unconditionally by fold-const.c:tree_single_nonzero_warnv_p.
Sticking an __attribute__((__used__)) on decl_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61851
--- Comment #1 from Mikael Pettersson ---
You ran out of RAM. Add some swap.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61860
--- Comment #1 from Mikael Pettersson ---
You ran out of RAM during the g++ job so the kernel killed it. You need more
RAM (preferably), or to add some swap (unpleasant but sometimes necessary).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61863
Mikael Pettersson changed:
What|Removed |Added
CC||mikpelinux at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61863
--- Comment #2 from Mikael Pettersson ---
This was fixed for 4.9 by r205694 (PR59374).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61964
Mikael Pettersson changed:
What|Removed |Added
CC||mikpelinux at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62031
Mikael Pettersson changed:
What|Removed |Added
CC||mikpelinux at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62015
Mikael Pettersson changed:
What|Removed |Added
CC||mikpelinux at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62663
--- Comment #2 from Mikael Pettersson ---
Without -msep-data gcc outputs
jsr square_test
With -msep-data gcc outputs
move.l square_test@GOT(%a5),%a0
jsr (%a0)
Is that move.l unavailable on the mcf5307? (I'm familiar w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63189
Mikael Pettersson changed:
What|Removed |Added
CC||mikpelinux at gmail dot com
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: mikpelinux at gmail dot com
Attempting to bootstrap latest gcc-5 snapshot (20140907, aka r215005) fails
with:
g++ -c -g -DIN_GC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63209
Mikael Pettersson changed:
What|Removed |Added
CC||mikpelinux at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63233
--- Comment #6 from Mikael Pettersson ---
(In reply to leis from comment #5)
> Fundamentally, what I'm really trying to do, is to have two arrays (of
> different types) in a fixed-sized struct. One array grows from the front,
> and one from the e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52773
--- Comment #11 from Mikael Pettersson ---
Probably just needs pinging. FWIW I've had it in my 4.7 and 4.8 toolchains
(for all my targets) since last summer w/o issues.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52897
--- Comment #5 from Mikael Pettersson ---
I'm afraid that improving performance on m68k is not a high priority for most
gcc developers. Interested parties may have to do the work themselves, or hire
someone to do it for them.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63234
Mikael Pettersson changed:
What|Removed |Added
CC||mikpelinux at gmail dot com
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.
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=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=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=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=63302
Mikael Pettersson changed:
What|Removed |Added
CC||mikpelinux at gmail dot com
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=63461
--- Comment #5 from Mikael Pettersson ---
Use .pushsection and .popsection .
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=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=67781
Mikael Pettersson changed:
What|Removed |Added
CC||mikpelinux at gmail dot com
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
--- 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=69037
Mikael Pettersson changed:
What|Removed |Added
CC||mikpelinux at gmail dot com
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
--- Comment #3 from Mikael Pettersson ---
Trunk had the same regression, until r231374 fixed it.
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=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=69124
Mikael Pettersson changed:
What|Removed |Added
CC||mikpelinux at gmail dot com
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=69097
Mikael Pettersson changed:
What|Removed |Added
CC||mikpelinux at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67781
--- Comment #12 from Mikael Pettersson ---
Thanks for posting the patch, I'm currently doing a sparc64-linux bootstrap and
regtest with it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69124
--- Comment #11 from Mikael Pettersson ---
(In reply to ktkachov from comment #9)
> So I did a bisection between 4.9 and 5.
> The offending commit is r217624:
> Author: vmakarov
> Date: Sun Nov 16 05:00:30 2014 +
>
> 2014-11-15 Vladi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67781
--- Comment #13 from Mikael Pettersson ---
Patch passed bootstrap and regtest on sparc64-linux. No regressions.
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=66598
--- Comment #2 from Mikael Pettersson ---
Started with r197189.
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=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
--- 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=66186
Mikael Pettersson changed:
What|Removed |Added
CC||mikpelinux at gmail dot com
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=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=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 #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=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=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=66876
Mikael Pettersson changed:
What|Removed |Added
CC||mikpelinux at gmail dot com
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=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=66964
Mikael Pettersson changed:
What|Removed |Added
CC||mikpelinux at gmail dot com
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=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=67226
Mikael Pettersson changed:
What|Removed |Added
CC||mikpelinux at gmail dot com
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=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=67037
--- Comment #3 from Mikael Pettersson ---
Started with r206023, an LRA patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71903
--- Comment #1 from Mikael Pettersson ---
Can you add a standalone (compilable and runnable) test case?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71903
--- Comment #3 from Mikael Pettersson ---
No worries. As the reporter you should be able to resolve it as "invalid".
201 - 300 of 442 matches
Mail list logo
