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
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
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=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
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=68328
Mikael Pettersson changed:
What|Removed |Added
CC||mikpelinux at gmail dot com
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=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.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67474
--- Comment #1 from Mikael Pettersson ---
Still occurs with gcc-6-20150920.
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
: 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
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 bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67037
--- Comment #3 from Mikael Pettersson mikpelinux at gmail dot com ---
Started with r206023, an LRA patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67223
--- Comment #1 from Mikael Pettersson mikpelinux at gmail dot com ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67226
Mikael Pettersson mikpelinux at gmail dot com changed:
What|Removed |Added
CC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65358
--- Comment #28 from Mikael Pettersson mikpelinux at gmail dot com ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67226
--- Comment #2 from Mikael Pettersson mikpelinux at gmail dot com ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67037
Mikael Pettersson mikpelinux at gmail dot com changed:
What|Removed |Added
CC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66964
Mikael Pettersson mikpelinux at gmail dot com changed:
What|Removed |Added
CC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66917
--- Comment #2 from Mikael Pettersson mikpelinux at gmail dot com ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66917
Mikael Pettersson mikpelinux at gmail dot com changed:
What|Removed |Added
CC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66876
Mikael Pettersson mikpelinux at gmail dot com changed:
What|Removed |Added
CC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66809
--- Comment #1 from Mikael Pettersson mikpelinux at gmail dot com ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66809
--- Comment #3 from Mikael Pettersson mikpelinux at gmail dot com ---
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=58493
--- Comment #6 from Mikael Pettersson mikpelinux at gmail dot com ---
(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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58493
--- Comment #4 from Mikael Pettersson mikpelinux at gmail dot com ---
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 mikpelinux at gmail dot com ---
-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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66186
Mikael Pettersson mikpelinux at gmail dot com changed:
What|Removed |Added
CC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66754
Mikael Pettersson mikpelinux at gmail dot com changed:
What|Removed |Added
CC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=6
--- Comment #10 from Mikael Pettersson mikpelinux at gmail dot com ---
(In reply to Antonio Poggiali from comment #9)
Sorry, this code:
https://gcc.gnu.org/viewcvs/gcc/trunk/gcc/cgraphunit.
c?r1=221077r2=221076pathrev=221077
Yes, but I'm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=6
--- Comment #7 from Mikael Pettersson mikpelinux at gmail dot com ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=6
Mikael Pettersson mikpelinux at gmail dot com changed:
What|Removed |Added
CC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66598
Mikael Pettersson mikpelinux at gmail dot com changed:
What|Removed |Added
CC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66598
--- Comment #2 from Mikael Pettersson mikpelinux at gmail dot com ---
Started with r197189.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66252
--- Comment #1 from Mikael Pettersson mikpelinux at gmail dot com ---
Started with r67:
fc6cc27b3f46a6f70f610ec93a1c5e68d83c933b is the first bad commit
commit fc6cc27b3f46a6f70f610ec93a1c5e68d83c933b
Author: rguenth rguenth@138bc75d-0d04
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66252
--- Comment #3 from Mikael Pettersson mikpelinux at gmail dot com ---
Still occurs with trunk @ r223652.
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 mikpelinux at gmail dot com changed:
What|Removed |Added
CC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64972
--- Comment #9 from Mikael Pettersson mikpelinux at gmail dot com ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63234
--- Comment #7 from Mikael Pettersson mikpelinux at gmail dot com ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63234
--- Comment #8 from Mikael Pettersson mikpelinux at gmail dot com ---
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=65358
--- Comment #6 from Mikael Pettersson mikpelinux at gmail dot com ---
(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 mikpelinux at gmail dot com changed:
What|Removed |Added
CC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62109
--- Comment #3 from Mikael Pettersson mikpelinux at gmail dot com ---
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 mikpelinux at gmail dot com ---
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 mikpelinux at gmail dot com changed:
What|Removed |Added
CC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64756
Mikael Pettersson mikpelinux at gmail dot com changed:
What|Removed |Added
CC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64756
--- Comment #2 from Mikael Pettersson mikpelinux at gmail dot com ---
Also fails on m68k, but not on powerpc64, sparc64, or ARMv5.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57748
--- Comment #65 from Mikael Pettersson mikpelinux at gmail dot com ---
(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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57748
--- Comment #63 from Mikael Pettersson mikpelinux at gmail dot com ---
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 mikpelinux at gmail dot com ---
(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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57748
Mikael Pettersson mikpelinux at gmail dot com changed:
What|Removed |Added
CC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64451
--- Comment #1 from Mikael Pettersson mikpelinux at gmail dot com ---
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 #1 from Mikael Pettersson mikpelinux at gmail dot com ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64442
--- Comment #3 from Mikael Pettersson mikpelinux at gmail dot com ---
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=63681
--- Comment #5 from Mikael Pettersson mikpelinux at gmail dot com ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64172
Mikael Pettersson mikpelinux at gmail dot com changed:
What|Removed |Added
CC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50865
Mikael Pettersson mikpelinux at gmail dot com changed:
What|Removed |Added
Attachment #34323|0 |1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64379
--- Comment #5 from Mikael Pettersson mikpelinux at gmail dot com ---
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 mikpelinux at gmail dot com changed:
What|Removed |Added
CC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50865
Mikael Pettersson mikpelinux at gmail dot com changed:
What|Removed |Added
CC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64379
--- Comment #3 from Mikael Pettersson mikpelinux at gmail dot com ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61931
--- Comment #5 from Mikael Pettersson mikpelinux at gmail dot com ---
Created attachment 34307
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34307action=edit
backport of r197965 (without neon bits) + testcase
Patch which fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64364
--- Comment #2 from Mikael Pettersson mikpelinux at gmail dot com ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64294
--- Comment #7 from Mikael Pettersson mikpelinux at gmail dot com ---
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 mikpelinux at gmail dot com changed:
What|Removed |Added
CC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64294
--- Comment #10 from Mikael Pettersson mikpelinux at gmail dot com ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61931
Mikael Pettersson mikpelinux at gmail dot com changed:
What|Removed |Added
CC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61931
--- Comment #4 from Mikael Pettersson mikpelinux at gmail dot com ---
This was fixed for 4.9 by r197965.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63347
--- Comment #9 from Mikael Pettersson mikpelinux at gmail dot com ---
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 mikpelinux at gmail dot com ---
(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 mikpelinux at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63645
--- Comment #25 from Mikael Pettersson mikpelinux at gmail dot com ---
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 mikpelinux at gmail dot com ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63645
--- Comment #9 from Mikael Pettersson mikpelinux at gmail dot com ---
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
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 mikpelinux at gmail dot com ---
(In reply to R. Dragone from comment #1)
Just encountered the same problem myself.
gcc -march=native -E -v - /dev/null 21 | grep cc1
/usr/libexec/gcc/x86_64-pc-linux-gnu
: 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 mikpelinux at gmail dot com changed:
What|Removed |Added
CC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63461
--- Comment #5 from Mikael Pettersson mikpelinux at gmail dot com ---
Use .pushsection and .popsection .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63302
Mikael Pettersson mikpelinux at gmail dot com changed:
What|Removed |Added
CC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63347
--- Comment #3 from Mikael Pettersson mikpelinux at gmail dot com ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63393
--- Comment #3 from Mikael Pettersson mikpelinux at gmail dot com ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63394
--- Comment #1 from Mikael Pettersson mikpelinux at gmail dot com ---
(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 mikpelinux at gmail dot com ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63373
--- Comment #2 from Mikael Pettersson mikpelinux at gmail dot com ---
Related to PR57180?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63234
Mikael Pettersson mikpelinux at gmail dot com changed:
What|Removed |Added
CC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63234
--- Comment #4 from Mikael Pettersson mikpelinux at gmail dot com ---
(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=63233
--- Comment #6 from Mikael Pettersson mikpelinux at gmail dot com ---
(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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52773
--- Comment #11 from Mikael Pettersson mikpelinux at gmail dot com ---
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 mikpelinux at gmail dot com ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63209
Mikael Pettersson mikpelinux at gmail dot com changed:
What|Removed |Added
CC
201 - 300 of 416 matches
Mail list logo
