https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85401
coypu changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86811
coypu changed:
What|Removed |Added
CC||coypu at sdf dot org
--- Comment #1 from coypu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85401
--- Comment #7 from coypu ---
I sent a patch to gcc-patches.
https://gcc.gnu.org/ml/gcc-patches/2019-09/msg00896.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58442
coypu changed:
What|Removed |Added
CC||coypu at sdf dot org
--- Comment #12 from coypu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77800
coypu changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58901
coypu changed:
What|Removed |Added
CC||coypu at sdf dot org
--- Comment #7 from coypu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85401
--- Comment #6 from coypu ---
I imagine I didn't write scheduling for the broken instruction, so it doesn't
ever happen. something silly like that, rather than it being a valid fix.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85401
--- Comment #5 from coypu ---
Created attachment 46872
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46872=edit
providing instruction scheduling avoids this crash
So, I am trying to beat gcc/vax into shape and incorporate changes from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77952
coypu changed:
What|Removed |Added
CC||coypu at sdf dot org
--- Comment #2 from coypu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90929
coypu changed:
What|Removed |Added
Target|mips64-linux-gnuabi64 |mips64-linux-gnuabi64,
--- Comment #1 from
: libgcc
Assignee: unassigned at gcc dot gnu.org
Reporter: coypu at sdf dot org
Target Milestone: ---
MIPS needs cache synchronization.
libgcc's __clear_cache expands to:
000119b0 <__clear_cache>:
119b0: 03e8jr ra
119b4:
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: coypu at sdf dot org
Target Milestone: ---
if I compile this code with -O3
typedef struct once_t {
int val;
int pto_done;
} once_t;
int
once_stub(once_t *o, void (*r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=448
--- Comment #44 from coypu ---
(In reply to jos...@codesourcery.com from comment #31)
> GCC: some NetBSD targets (netbsd-stdint.h only used for x86 / x86_64),
Speaking for NetBSD only:
as of https://gcc.gnu.org/viewcvs/gcc?view=revision=253323 ,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62144
coypu changed:
What|Removed |Added
CC||coypu at sdf dot org
--- Comment #10 from coypu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88421
--- Comment #5 from coypu ---
(In reply to Jakub Jelinek from comment #4)
> That is one header, not two, so why should that fenv.h's #include_next
> include that same header or some copy of that header in a different path?
I am in the process
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88421
--- Comment #3 from coypu ---
include/c_compatibility/fenv.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65794
--- Comment #4 from coypu ---
Hi,
It's probably a setup/configuration issue for everyone reporting this issue.
It's hard to debug, my patch helps with figuring out the problem - but doesn't
fix it.
I didn't ping this bug report because I don't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88421
--- Comment #1 from coypu ---
suggested change: put #include_next outside of include guards?
: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: coypu at sdf dot org
Target Milestone: ---
I built GCC #1 (x86_64->sh3)
Now I'm trying to build GCC #2 (sh3->sh3) using GCC #1
during the build process,
libtool: compile: shle--netbsdelf-c++ --sysroot=/home/f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88194
coypu changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
gnu.org
Reporter: coypu at sdf dot org
Target Milestone: ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39570
coypu changed:
What|Removed |Added
CC||coypu at sdf dot org
--- Comment #16 from coypu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86383
--- Comment #14 from coypu ---
Also, after these two patches, my own build of arm--netbsdelf is failing from
this:
configure: error: Pthreads are required to build libgomp
Looking at config.log, the error is actually:
configure:15118:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86383
--- Comment #13 from coypu ---
I sent this to gcc-patches
for netbsd/eabi and stop picking arm6 -mcpu for oabi too:
https://gcc.gnu.org/ml/gcc-patches/2018-10/msg01256.html
for all of arm to stop defaulting to non-existent -mcpu=arm6:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86383
--- Comment #12 from coypu ---
to clarify, I still had trouble building oabi, but it fails elsewhere now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86383
--- Comment #11 from coypu ---
That cross builds with trunk.
For attempting to build oabi it wasn't enough to not specify
target_cpu_cname=arm6, because the default cpu is still arm6.
in gcc/config.gcc:3989 right now
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86383
--- Comment #10 from coypu ---
Created attachment 44836
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44836=edit
netbsd eabi support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87221
--- Comment #3 from coypu ---
I think the change in bug 81523 to make -static imply no PIE might be wrong, as
static PIE is a thing.
It might be more right to limit that change only for configurations that don't
support static PIE.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87221
--- Comment #2 from coypu ---
(In reply to Andrew Pinski from comment #1)
> This is related to bug 81523. How did you configure GCC?
Configured with nothing related to default pie:
export ac_cv_func_freelocale=no
export
: unassigned at gcc dot gnu.org
Reporter: coypu at sdf dot org
Target Milestone: ---
With any example code,
> /usr/local/bin/gcc -pie -fpie test2.c
/usr/bin/ld: /usr/local/lib/gcc/x86_64-unknown-netbsd8.99/9.0.0/crtbegin.o:
relocation R_X86_64_32 against hidden symbol `__TMC_END__'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86383
coypu changed:
What|Removed |Added
CC||coypu at sdf dot org
--- Comment #5 from coypu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85905
coypu changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
Assignee: unassigned at gcc dot gnu.org
Reporter: coypu at sdf dot org
Target Milestone: ---
Created attachment 44176
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44176=edit
move linux specfile stuff to linux file.
when I build trunk I get in libgomp/config.log can
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: coypu at sdf dot org
Target Milestone: ---
Created attachment 44175
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44175=edit
Fixes configure for me
Out of the box (+3 patches I would like to get merged
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85401
--- Comment #1 from coypu ---
Threw computing resources at the problem, so now I have an "offending" commit.
Before this commit, it doesn't segfault.
After, it does.
commit bbb9b536dd58015b5712a867954d34aae9d9dae5 (HEAD, refs/bisect/bad)
Assignee: unassigned at gcc dot gnu.org
Reporter: coypu at sdf dot org
Target Milestone: ---
Created attachment 43929
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43929=edit
Reproduce test
build with the following flags fails:
-O2 -fno-pic -c ip_icmp.i
here is a backtr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85152
--- Comment #1 from coypu ---
*** Bug 85151 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85151
coypu changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
: unassigned at gcc dot gnu.org
Reporter: coypu at sdf dot org
Target Milestone: ---
Created attachment 43808
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43808=edit
Test case.
ICE with -O2, no ICE with -O0.
~/gcc/build/gcc$ PATH=.:$PATH ./xgcc -x c small.c -c -O2
during RTL p
: unassigned at gcc dot gnu.org
Reporter: coypu at sdf dot org
Target Milestone: ---
Created attachment 43807
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43807=edit
Test case.
ICE with -O2, no ICE with -O0.
~/gcc/build/gcc$ PATH=.:$PATH ./xgcc -x c ~/small.c -c -O2
during RTL p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83826
--- Comment #2 from coypu ---
Created attachment 43145
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43145=edit
fixed sys/types.h
--- Comment #3 from coypu ---
Created attachment 43146
-->
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83826
--- Comment #2 from coypu ---
Created attachment 43145
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43145=edit
fixed sys/types.h
Assignee: unassigned at gcc dot gnu.org
Reporter: coypu at sdf dot org
Target Milestone: ---
At least on netbsd:
#include
#include
int main() { return 0; }
> /usr/pkg/gcc8snapshot/bin/gcc -ffreestanding -Wsystem-headers test.c
In file included from /usr/include/amd64/int_limit
Assignee: unassigned at gcc dot gnu.org
Reporter: coypu at sdf dot org
Target Milestone: ---
stack_probe on x86 is "or 0 offset(%rsp)".
it's not a no-op because it isn't atomic.
Related:
https://github.com/golang/go/issues/20427
https://lkml.org/lkml/2017/11/10/188
https:/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82068
coypu changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82068
--- Comment #4 from coypu ---
sorry, I attached an object file rather than assembly. I am guessing it's good
enough.
I am passing only -mieee to make it fail.
(If I use instead -mieee -mfp-trap-mode=n, it doesn't fail, and I get a very
similar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82068
--- Comment #3 from coypu ---
Created attachment 42104
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42104=edit
-mieee -mfp-trap-mode=n, doesn't assert
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82068
--- Comment #2 from coypu ---
Created attachment 42103
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42103=edit
-mieee, asserts
Assignee: unassigned at gcc dot gnu.org
Reporter: coypu at sdf dot org
Target Milestone: ---
background:
gcc 8.0.0 20170827
netbsd-8.99.2/alpha, 21264
the following test case asserts if built with -mieee, but not without:
#include
#include
#include
int
main (void
: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: coypu at sdf dot org
Target Milestone: ---
occasionally workarounds are needed for old libstdc++ versions, it would be
easier to do so with the help of a macro.
if the compiler used is not GCC, we can't check for GCC's
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81199
--- Comment #2 from coypu ---
To relay a comment on the netbsd bug,
"I don't think (the proposed idea) is correct and the real problem is that we
are linking libgcc first (again)."
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81199
--- Comment #1 from coypu ---
Maybe expose __clz_tab but only in the fallback definition case, and not make
it hidden.
Priority: P3
Component: libgcc
Assignee: unassigned at gcc dot gnu.org
Reporter: coypu at sdf dot org
Target Milestone: ---
Bug report from building cmake on netbsd/vax with GCC 5.4.0
http://gnats.netbsd.org/52326
[ 88%] Building CXX object
Source/CMakeFiles
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: coypu at sdf dot org
Target Milestone: ---
Hi, I'm building a libc.
It doesn't use __attribute__((nonnull)) anywhere in stdio.h and other headers,
instead asserts in a convoluted way that the arguments aren't NULL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80600
--- Comment #10 from coypu ---
(In reply to H.J. Lu from comment #9)
>
> This may break Linux. You may want to investigate if this approach:
>
> commit 6e6c7fc1e15525a10f48d4f5ac2edd853e2f5cb7
> Author: nsz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80600
--- Comment #8 from coypu ---
Created attachment 41317
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41317=edit
Unbreak NetBSD following r243219
This patch works for me.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80600
--- Comment #3 from coypu ---
$ /usr/pkg/gcc7/bin/gfortran -Wl,--verbose test.f95 |grep succeeded |sort -u
..
attempt to open /usr/lib/crt0.o succeeded
attempt to open /usr/lib/crtbegin.o succeeded
attempt to open /usr/lib/crtend.o succeeded
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80600
--- Comment #1 from coypu ---
Related and possible duplicate for dfly: libgcc/61309
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: coypu at sdf dot org
Target Milestone: ---
building a simple fortran hello world:
/usr/bin/ld: a.out: hidden symbol `__cpu_model' in
/usr/pkg/gcc7/lib/gcc/x86_64--netbsd/7.1.0/libgcc.a(cpuinfo.o) is referenced by
DSO
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: coypu at sdf dot org
Target Milestone: ---
This is the (currently latest) 20161218 snapshot.
int main() {
int num = 3;
int a;
switch (num
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: coypu at sdf dot org
Target Milestone: ---
Hello,
Building GCC 5.4.0 on netbsd 7.0.1 armv6hf I encounter failure like:
gcc.o:(.rodata+0x58c4): undefined reference to `host_detect_local_cpu(int, char
const**)'
I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=4
--- Comment #6 from coypu ---
It is a local change bug! thanks.
I'll let you know if the build completes.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=4
--- Comment #4 from coypu ---
indeed in EXTRAOBJS I only have netbsd.o
I'll try to use arm*) instead, and will report back.
Priority: P3
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: coypu at sdf dot org
Target Milestone: ---
Created attachment 39716
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39716=edit
Errors in the build
Attached errors from the bu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77470
--- Comment #1 from coypu ---
Created attachment 39560
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39560=edit
Correct includes for libssp
This gets me a bit further, but I still have trouble using it.
For netbsd we have in stdio.h:
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: coypu at sdf dot org
Target Milestone: ---
Created attachment 39557
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39557=edit
less bogus specfile for netbsd.
Attached a patch tha
Assignee: unassigned at gcc dot gnu.org
Reporter: coypu at sdf dot org
Target Milestone: ---
apologies if this is invalid for vanilla GCC, I am very skeptical I will be
able to build it without the help of a package, which includes small changes.
configuring with --enable-libssp, I got
67 matches
Mail list logo
