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/attachme
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
: 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=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 ac_cv_func_newloc
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=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=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/b
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 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
: 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
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: /tmp
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
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=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 #3 from coypu ---
include/c_compatibility/fenv.h
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 p
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=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
: 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=88421
--- Comment #1 from coypu ---
suggested change: put #include_next outside of include guards?
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=253
: 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:
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
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=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 f
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=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=77800
coypu changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution
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=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=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=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
coypu changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution
On Tue, Nov 24, 2020 at 05:27:10AM +, Maciej W. Rozycki wrote:
> On Tue, 24 Nov 2020, Maciej W. Rozycki wrote:
>
> > > I don't know how or why __FLT_HAS_INFINITY is set for a target which
> > > does not support it, but if you get rid of that macro, that particular
> > > problem should be
I hope that writing the detailed commit message will encourage someone
with better knowledge of GCC internals to point out a better place for
this logic. I can follow through with any suggestions :)
On Sat, Feb 13, 2021 at 12:20:30PM +, Maya Rashish wrote:
> Some subtargets don't provide the
101 - 142 of 142 matches
Mail list logo
