[Bug other/83826] Fixinclude creates redefinitions
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/attachment.cgi?id=43146=edit Normal sys/types.h
[Bug other/83826] Fixinclude creates redefinitions
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
[Bug other/83826] New: Fixinclude creates redefinitions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83826
Bug ID: 83826
Summary: Fixinclude creates redefinitions
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
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_limits.h:36,
from /usr/include/sys/stdint.h:92,
from /usr/include/sys/bswap.h:9,
from /usr/include/amd64/bswap.h:13,
from /usr/include/sys/endian.h:107,
from /usr/include/amd64/endian.h:3,
from
/usr/pkg/gcc8snapshot/lib/gcc/x86_64--netbsd/8.0.0/include-fixed/sys/types.h:107,
from /usr/include/sys/time.h:38,
from test.c:2:
/usr/include/sys/common_int_limits.h:46: warning: "INT8_MIN" redefined
#define INT8_MIN (-__INT8_MAX__-1)
In file included from
/usr/pkg/gcc8snapshot/lib/gcc/x86_64--netbsd/8.0.0/include/stdint.h:11,
from test.c:1:
/usr/pkg/gcc8snapshot/lib/gcc/x86_64--netbsd/8.0.0/include/stdint-gcc.h:103:
note: this is the location of the previous definition
# define INT8_MIN (-INT8_MAX - 1)
Repeating for a lot of things.
using -save-temps, it seems we have include order:
fixincludes stdint.h:
#undef WORKING_THING
#define WORKING_THING 0x7f
normal stdint.h:
#define WORKING_THING 0x7F
[Bug c/87221] New: cannot build with -pie
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87221
Bug ID: 87221
Summary: cannot build with -pie
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: 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__' can not be used when
making a shared object
/usr/bin/ld: /usr/local/lib/gcc/x86_64-unknown-netbsd8.99/9.0.0/crtend.o:
relocation R_X86_64_32 against `.ctors' can not be used when making a shared
object; recompile with -fPIC
/usr/bin/ld: final link failed: Nonrepresentable section on output
collect2: error: ld returned 1 exit status
The following patch seems to help, but I don't know why the problem doesn't
affect more people:
diff --git a/libgcc/Makefile.in b/libgcc/Makefile.in
index 84738e76eaa..4906034555f 100644
--- a/libgcc/Makefile.in
+++ b/libgcc/Makefile.in
@@ -297,7 +297,7 @@ INTERNAL_CFLAGS = $(CFLAGS) $(LIBGCC2_CFLAGS)
$(HOST_LIBGCC2_CFLAGS) \
CRTSTUFF_CFLAGS = -O2 $(GCC_CFLAGS) $(INCLUDES) $(MULTILIB_CFLAGS) -g0 \
$(NO_PIE_CFLAGS) -finhibit-size-directive -fno-inline -fno-exceptions \
-fno-zero-initialized-in-bss -fno-toplevel-reorder -fno-tree-vectorize \
- -fbuilding-libgcc -fno-stack-protector $(FORCE_EXPLICIT_EH_REGISTRY) \
+ -fbuilding-libgcc -fPIC -fno-stack-protector $(FORCE_EXPLICIT_EH_REGISTRY) \
$(INHIBIT_LIBC_CFLAGS)
# Extra flags to use when compiling crt{begin,end}.o.
[Bug target/87221] cannot build with -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 ac_cv_func_newlocale=no export ac_cv_func_uselocale=no ./configure --disable-nls --with-system-zlib MAKEINFO=/usr/pkg/bin/makeinfo
[Bug target/87221] cannot build with -pie
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.
[Bug target/86383] [9 Regression] arm-netbsdelf cross compiler fails in selftests
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 --- (In reply to Richard Earnshaw from comment #2) > I'm not sure how relevant the netbsd-elf port is these days. I believe > they've now moved onto an EABI based ABI. But no GCC port of that has been > contributed. hi, I have a big working patch for netbsd/arm eabi. I didn't test it against trunk/clean it up yet. (https://v4.freshbsd.org/commit/netbsd/pkgsrc/yfUHHZvopo2aGFGA) can I assign this to myself?
[Bug target/85401] segfault building code for VAX
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) Author: thopre01 <thopre01@138bc75d-0d04-0410-961f-82ee72b054a4> Date: Tue Jan 6 11:51:16 2015 + 2015-01-06 Thomas Preud'homme <thomas.preudho...@arm.com> gcc/ PR tree-optimization/63259 * tree-ssa-math-opts.c (pass_optimize_bswap::execute): Stop checking if optab exists for 16bit byteswap. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@219256 138bc75d-0d04-0410-961f-82ee72b054a4
[Bug target/85401] New: segfault building code for VAX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85401
Bug ID: 85401
Summary: segfault building code for VAX
Product: gcc
Version: 8.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
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 backtrace, from trunk as of April 14 2018.
Starting program: /home/fly/gcc/build/gcc/cc1 -fpreprocessed ip_icmp.i -quiet
-dumpbase ip_icmp.i -auxbase ip_icmp -O2 -fno-pic -o /var/tmp//ccO5AxRb.s
In file included from ../../../../sys/timevar.h:66,
from ../../../../sys/time.h:307,
from ../../../../sys/param.h:145,
from ../../../../netinet/ip_icmp.c:103:
../../../../sys/systm.h:225:6: warning: conflicting types for built-in function
'printf' [-Wbuiltin-declaration-mismatch]
../../../../sys/systm.h:229:6: warning: conflicting types for built-in function
'vprintf' [-Wbuiltin-declaration-mismatch]
In file included from ../../../../netinet/ip_icmp.c:112:
../../../../sys/syslog.h:233:6: warning: conflicting types for built-in
function 'log' [-Wbuiltin-declaration-mismatch]
Program received signal SIGSEGV, Segmentation fault.
0x00bfd868 in allocno_copy_cost_saving (allocno=0x7e3c3e791190,
hard_regno=11) at ../../gcc/ira-color.c:2832
2832 cost += cp->freq *
ira_register_move_cost[allocno_mode][rclass][rclass];
1: rclass = ALL_REGS
2: allocno_mode = E_QImode
3: ira_register_move_cost[allocno_mode][rclass][rclass] =
4: cp->freq = 36
5: ira_register_move_cost = {0x0, 0x0, 0x0, 0x0, 0x0, 0x7e3c3ed98850,
0x7e3c3ed98850, 0x0 }
(gdb) bt full
#0 0x00bfd868 in allocno_copy_cost_saving (allocno=0x7e3c3e791190,
hard_regno=11) at ../../gcc/ira-color.c:2832
cost = 0
allocno_mode = E_QImode
rclass = ALL_REGS
cp = 0x7e3c3e511380
next_cp = 0x0
__FUNCTION__ = "allocno_copy_cost_saving"
#1 0x00bfdbb9 in improve_allocation () at ../../gcc/ira-color.c:2905
i = 2
j = 11
k = 11
n = 5
hregno = 11
conflict_hregno = 1
base_cost = 2232
class_size = 12
word = 1
nwords = 1
check = 3
spill_cost = 4068
min_cost = -594
nregs = 1
conflict_nregs = 1
r = 2
best = 10
try_p = true
aclass = ALL_REGS
mode = E_SImode
allocno_costs = 0x7e3c3e7313c8
costs = {-1740536, 40443, 0, 484, 552, 0, -2232, -2232, -2232, -2232,
-2232, 0, 1050933376, 32316, -1741856, 32639}
conflicting_regs = {18446744073709547521, 140187730799504}
profitable_hard_regs = 4032
a = 0x7e3c3e791190
bi = {elt1 = 0x7e3c3e7b1a90, elt2 = 0x0, word_no = 0, bits =
4611686018427387903}
__FUNCTION__ = "improve_allocation"
#2 0x00bfea51 in color_allocnos () at ../../gcc/ira-color.c:3201
i = 256
n = 32316
bi = {elt1 = 0x0, elt2 = 0x0, word_no = 2, bits = 0}
a = 0x7e3c3e799050
__FUNCTION__ = "color_allocnos"
#3 0x00bff13f in color_pass (loop_tree_node=0x7e3c3ed2fc00) at
../../gcc/ira-color.c:3310
regno = 32316
hard_regno = -1741504
index = -1
n = 81
cost = 0
exit_freq = 1048255088
enter_freq = 0
j = 256
bi = {elt1 = 0x0, elt2 = 0x0, word_no = 2, bits = 0}
mode = 32639
rclass = NO_REGS
aclass = (unknown: 33152352)
pclass = (ALL_REGS | LIM_REG_CLASSES | unknown: 9049864)
a = 0x7e3c3e799050
subloop_allocno = 0xb8
subloop_node = 0x7f7fffe56d20
__FUNCTION__ = "color_pass"
#4 0x00be8146 in ira_traverse_loop_tree (bb_p=false,
loop_node=0x7e3c3ed2fc00,
preorder_func=0xbfef25 <color_pass(ira_loop_tree_node_t)>,
postorder_func=0x0) at ../../gcc/ira-build.c:1781
subloop_node = 0xbd6ab8 <ira_allocate_bitmap()+14>
__FUNCTION__ = "ira_traverse_loop_tree"
#5 0x00bffa0d in do_coloring () at ../../gcc/ira-color.c:3461
No locals.
#6 0x00c03501 in color () at ../../gcc/ira-color.c:4838
No locals.
#7 0x00c039d3 in ira_color () at ../../gcc/ira-color.c:4953
a = 0x7e3c3e799050
ai = {n = 172}
#8 0x00be30ff in ira (f=0x0) at ../../gcc/ira.c:5308
loops_p = true
ira_max_point_before_emit = 524288
saved_flag_caller_saves = true
saved_flag_ira_region = IRA_REGION_MIXED
__FUNCTION__ = "ira"
#9 0x00be3887 in (anonymous namespace)::pass_ira::execute
(this=0x7e3c3ed86bc0) at ../../gcc/ira.c:5606
No loca
[Bug target/85152] VAX ICE with -O2
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. ***
[Bug target/85151] VAX ICE with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85151 coypu changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from coypu --- Made a double bug report by mistake. *** This bug has been marked as a duplicate of bug 85152 ***
[Bug target/85151] New: VAX ICE with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85151 Bug ID: 85151 Summary: VAX ICE with -O2 Product: gcc Version: 8.0.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: 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 pass: final /home/fly/small.c: In function 'fn1': /home/fly/small.c:7:1: internal compiler error: in change_address_1, at emit-rtl.c:2286 } ^ 0x7d86ed change_address_1 ../../gcc/emit-rtl.c:2286 0x7dc9d5 adjust_address_1(rtx_def*, machine_mode, poly_int<1u, long>, int, int, int, poly_int<1u, long>) ../../gcc/emit-rtl.c:2420 0x101b783 output_101 ../../gcc/config/vax/vax.md:824 0x82ac0a final_scan_insn_1 ../../gcc/final.c:3105 0x82c79b final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*) ../../gcc/final.c:3218 0x82c935 final_1 ../../gcc/final.c:2088 0x82d984 rest_of_handle_final ../../gcc/final.c:4671 0x82d984 execute ../../gcc/final.c:4745 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions.
[Bug target/85152] New: VAX ICE with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85152 Bug ID: 85152 Summary: VAX ICE with -O2 Product: gcc Version: 8.0.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: 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 pass: final small.c: In function 'fn1': small.c:7:1: internal compiler error: in change_address_1, at emit-rtl.c:2286 } ^ 0x7d86ed change_address_1 ../../gcc/emit-rtl.c:2286 0x7dc9d5 adjust_address_1(rtx_def*, machine_mode, poly_int<1u, long>, int, int, int, poly_int<1u, long>) ../../gcc/emit-rtl.c:2420 0x101b783 output_101 ../../gcc/config/vax/vax.md:824 0x82ac0a final_scan_insn_1 ../../gcc/final.c:3105 0x82c79b final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*) ../../gcc/final.c:3218 0x82c935 final_1 ../../gcc/final.c:2088 0x82d984 rest_of_handle_final ../../gcc/final.c:4671 0x82d984 execute ../../gcc/final.c:4745 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions.
[Bug target/86383] [9 Regression] arm-netbsdelf cross compiler fails in selftests
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/build/./gcc/xgcc -B/tmp/build/./gcc/ -B/usr/local/arm--netbsdelf/bin/ -B/usr/local/arm--netbsdelf/lib/ -isystem /usr/local/arm--netbsdelf/include -isystem /usr/local/arm--netbsdelf/sys-include --sysroot=/home/fly/shark/destdir.shark/ -o conftest -g -O2 conftest.c -lpthread >&5 /home/fly/shark/destdir.shark/usr/lib/libpthread.so: undefined reference to `__modsi3@GCC_3.0' collect2: error: ld returned 1 exit status I'm not sure what is the cause of that.
[Bug target/86383] [9 Regression] arm-netbsdelf cross compiler fails in selftests
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/ml/gcc-patches/2018-10/msg01262.html
[Bug target/86383] [9 Regression] arm-netbsdelf cross compiler fails in selftests
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.
[Bug target/86383] [9 Regression] arm-netbsdelf cross compiler fails in selftests
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
target_cpu_cname=${target_cpu_cname:-arm6}
maybe that needs to be arm8 or something?
[Bug target/86383] [9 Regression] arm-netbsdelf cross compiler fails in selftests
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
[Bug inline-asm/62144] "Frame pointer required, but reserved" error with -fomit-frame-pointer but only with -m32 -O2
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 --- fyi, if you are considering this a bug, I can still reproduce it with trunk as of gcc (GCC) 9.0.0 20181125
[Bug libstdc++/88421] compat C headers break building GCC with GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88421 --- Comment #3 from coypu --- include/c_compatibility/fenv.h
[Bug libstdc++/88421] compat C headers break building GCC with GCC
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 of building libstdc++. -I/tmp/build/shle--netbsdelf/libstdc++-v3/include there's a libstdc++ fenv.h there
[Bug c++/88194] can
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88194 coypu changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from coypu --- sorry, clicked too many buttons:-)
[Bug c++/88194] New: can
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88194 Bug ID: 88194 Summary: can Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: coypu at sdf dot org Target Milestone: ---
[Bug target/39570] cabs and cabsf are named differently on NetBSD 5
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 --- well, the workaround only works for x86 and powerpc. Other archs are not calling SUBTARGET_INIT_BUILTINS. I'm not sure whether that should be grounds for keeping the ticket open, though.
[Bug other/65794] Building crossback fails: No rule to make target `auto-build.h', needed by `build/genmddeps.o'
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 understand what the other patch described here does.
[Bug libstdc++/88421] New: compat C headers break building GCC with GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88421 Bug ID: 88421 Summary: compat C headers break building GCC with GCC Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: 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/fly/sh3/destdir.evbsh3/ -I/current/gcc/libstdc++-v3/../libgcc -I/tmp/build/shle--netbsdelf/libstdc++-v3/include/shle--netbsdelf -I/tmp/build/shle--netbsdelf/libstdc++-v3/include -I/current/gcc/libstdc++-v3/libsupc++ -std=gnu++98 -D_GLIBCXX_SHARED -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi=2 -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -frandom-seed=c++locale.lo -g -O2 -fimplicit-templates -c c++locale.cc -fPIC -DPIC -D_GLIBCXX_SHARED -o c++locale.o mv -f .deps/list_read.Tpo .deps/list_read.Plo In file included from /home/fly/sh3/destdir.evbsh3/usr/include/evbsh3/ieeefp.h:3, from /home/fly/sh3/destdir.evbsh3/usr/include/ieeefp.h:12, from c++locale.cc:40: /home/fly/sh3/destdir.evbsh3/usr/include/sh3/ieeefp.h: In function 'fp_except __FPE(int)': /home/fly/sh3/destdir.evbsh3/usr/include/sh3/ieeefp.h:62:13: error: 'FE_DIVBYZERO' was not declared in this scope 62 | if (__fe & FE_DIVBYZERO) | ^~~~ /home/fly/sh3/destdir.evbsh3/usr/include/sh3/ieeefp.h:64:13: error: 'FE_INEXACT' was not declared in this scope 64 | if (__fe & FE_INEXACT) | ^~ /home/fly/sh3/destdir.evbsh3/usr/include/sh3/ieeefp.h:66:13: error: 'FE_INVALID' was not declared in this scope; did you mean 'EINVAL'? 66 | if (__fe & FE_INVALID) | ^~ | EINVAL /home/fly/sh3/destdir.evbsh3/usr/include/sh3/ieeefp.h:68:13: error: 'FE_OVERFLOW' was not declared in this scope; did you mean 'EOVERFLOW'? 68 | if (__fe & FE_OVERFLOW) | ^~~ | EOVERFLOW /home/fly/sh3/destdir.evbsh3/usr/include/sh3/ieeefp.h:70:13: error: 'FE_UNDERFLOW' was not declared in this scope; did you mean 'UNDERFLOW'? 70 | if (__fe & FE_UNDERFLOW) | ^~~~ | UNDERFLOW /home/fly/sh3/destdir.evbsh3/usr/include/sh3/ieeefp.h: In function 'int __FEE(fp_except)': /home/fly/sh3/destdir.evbsh3/usr/include/sh3/ieeefp.h:81:11: error: 'FE_DIVBYZERO' was not declared in this scope 81 | __fe |= FE_DIVBYZERO; | ^~~~ /home/fly/sh3/destdir.evbsh3/usr/include/sh3/ieeefp.h:83:11: error: 'FE_INEXACT' was not declared in this scope 83 | __fe |= FE_INEXACT; | ^~ /home/fly/sh3/destdir.evbsh3/usr/include/sh3/ieeefp.h:85:11: error: 'FE_INVALID' was not declared in this scope; did you mean 'EINVAL'? 85 | __fe |= FE_INVALID; | ^~ | EINVAL /home/fly/sh3/destdir.evbsh3/usr/include/sh3/ieeefp.h:87:11: error: 'FE_OVERFLOW' was not declared in this scope; did you mean 'EOVERFLOW'? 87 | __fe |= FE_OVERFLOW; | ^~~ | EOVERFLOW /home/fly/sh3/destdir.evbsh3/usr/include/sh3/ieeefp.h:89:11: error: 'FE_UNDERFLOW' was not declared in this scope; did you mean 'UNDERFLOW'? 89 | __fe |= FE_UNDERFLOW; | ^~~~ | UNDERFLOW /home/fly/sh3/destdir.evbsh3/usr/include/sh3/ieeefp.h: In function 'fp_rnd __FPR(int)': /home/fly/sh3/destdir.evbsh3/usr/include/sh3/ieeefp.h:98:7: error: 'FE_TONEAREST' was not declared in this scope 98 | case FE_TONEAREST: | ^~~~ /home/fly/sh3/destdir.evbsh3/usr/include/sh3/ieeefp.h:100:7: error: 'FE_DOWNWARD' was not declared in this scope 100 | case FE_DOWNWARD: | ^~~ /home/fly/sh3/destdir.evbsh3/usr/include/sh3/ieeefp.h:102:7: error: 'FE_UPWARD' was not declared in this scope 102 | case FE_UPWARD: | ^ /home/fly/sh3/destdir.evbsh3/usr/include/sh3/ieeefp.h:104:7: error: 'FE_TOWARDZERO' was not declared in this scope 104 | case FE_TOWARDZERO: | ^ /home/fly/sh3/destdir.evbsh3/usr/include/sh3/ieeefp.h: In function 'int __FER(fp_rnd)': /home/fly/sh3/destdir.evbsh3/usr/include/sh3/ieeefp.h:117:10: error: 'FE_TONEAREST' was not declared in this scope 117 | return FE_TONEAREST; | ^~~~ /home/fly/sh3/destdir.evbsh3/usr/include/sh3/ieeefp.h:119:10: error: 'FE_DOWNWARD' was not declared in this scope 119 | return FE_DOWNWARD; | ^~~ /home/fly/sh3/destdir.evbsh3/usr/include/sh3/ieeefp.h:121:10: error: 'FE_UPWARD' was not declared in this scope 121 | return FE_UPWARD; | ^ /home/
[Bug libstdc++/88421] compat C headers break building GCC with GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88421 --- Comment #1 from coypu --- suggested change: put #include_next outside of include guards?
[Bug c/448] -related issues (C99 issues)
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 , we include netbsd-stdint.h for all netbsd targets.
[Bug libgcc/90929] New: libgcc MIPS __clear_cache shouldn't be a no-op
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90929 Bug ID: 90929 Summary: libgcc MIPS __clear_cache shouldn't be a no-op Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: 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: nop ... (a no-op) Running compiler-rt's test[1] on real hardware running netbsd/mips64 (n32) without optimizations fails. If -O2 is used it succeeds, presumably because the call is inlined. # gcc clear_cache_test.c -o clear_cache_test; nm clear_cache_test |grep clear_cache; ./clear_cache_test; echo $? U __clear_cache@@GCC_3.0 1 # gcc -O2 clear_cache_test.c -o clear_cache_test; nm clear_cache_test |grep clear_cache; ./clear_cache_test; echo $? 0 To confirm this isn't caused by local changes or build oddities, I built with trunk for "mips64-linux-gnuabi64" on linux, and it still shows the no-op function. The correct behaviour is to emit a call to libc (it's a privileged instruction on older MIPS, so the kernel must do it). [1] https://github.com/llvm-mirror/compiler-rt/blob/master/test/builtins/Unit/clear_cache_test.c
[Bug libgcc/90929] libgcc MIPS __clear_cache shouldn't be a no-op
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 coypu --- To clarify, the correct behaviour is implemented, it just doesn't get expanded in libgcc for header reasons.
[Bug target/90360] New: Missed optimization: unnecessary use of callee-saved registers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90360
Bug ID: 90360
Summary: Missed optimization: unnecessary use of callee-saved
registers
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
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)(void))
{
if (o->pto_done == 0) {
(*r)();
o->pto_done = 1;
}
return (0);
}
The output is:
once_stub(once_t*, void (*)()):
movl4(%rdi), %eax
testl %eax, %eax
jne .L4
pushq %rbx
movq%rdi, %rbx
call*%rsi
movl$1, 4(%rbx)
xorl%eax, %eax
popq%rbx
ret
.L4:
xorl%eax, %eax
ret
I think push/pop instructions won't be necessary if
another register besides rbx is picked.
[Bug target/85401] segfault building code for VAX
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 netbsd's patches. I noticed one of the changes I made for another reason avoids this crash. It is providing a (trivial) instruction scheduling.
[Bug target/85401] segfault building code for VAX
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.
[Bug target/58901] vax bootstrap fails on subreg reload
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 --- Created attachment 46884 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46884=edit matt's changes, synced by other matt, against trunk. Confirming as still occurring in gcc-trunk as of: xgcc (GCC) 10.0.0 20190907 (experimental) NetBSD has a local diff to avoid this crash. I attached it (updated for trunk) for reference. The commit message for it (by Matt Thomas): https://github.com/NetBSD/src/commit/e437e96750193b86d0464965661f616e011056fa "Fix a problem with reloading the inner reg of a subreg when it's a mode dependent address."
[Bug target/77800] Undefined ref to host_detect_local_cpu on netbsd/arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77800 coypu changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #1 from coypu --- driver-arm.o now included for netbsd, too, after https://gcc.gnu.org/viewcvs/gcc?view=revision=272290
[Bug target/58442] bootstrapping vax crashes on NetBSD
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 --- I think this ticket can be closed. all the vax code with mode_dependent_address_p already checks that it's MEM_P like suggested by matt thomas. I can almost complete a build with the patch in #58901, with the other unfixed bug being in binutils rather than GCC :-)
[Bug target/77952] c++11 and gcc: internal compiler error: in convert_move
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 --- hi, I tested some versions: 6.3.0: fail 7.4.0: OK trunk (10.x): OK I suspect this means the bug can be closed as already being fixed in supported branches.
[Bug target/85401] segfault building code for VAX
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
[Bug target/86811] Vax port needs updating for CVE-2017-5753
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 --- I sent a patch to gcc-patches. vax does not need speculation barriers. it doesn't speculate. https://gcc.gnu.org/ml/gcc-patches/2019-09/msg01031.html
[Bug target/85401] segfault building code for VAX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85401 coypu changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #9 from coypu --- Fixed, also the very related second failure (that creduce managed to find, when reducing this test case). https://gcc.gnu.org/viewcvs/gcc?view=revision=276587
Re: [PATCH 00/31] VAX: Bring the port up to date (yes, MODE_CC conversion is included)
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 solved. > > > > Thanks for the hint; I didn't look into it any further not to distract > > myself from the scope of the project. I have now, and the check you have > > quoted is obviously broken (as are all the remaining similar ones), given: > > > > $ vax-netbsdelf-gcc -E -dM - < /dev/null | sort | grep _HAS_ > > #define __DBL_HAS_DENORM__ 0 > > #define __DBL_HAS_INFINITY__ 0 > > #define __DBL_HAS_QUIET_NAN__ 0 > > #define __FLT_HAS_DENORM__ 0 > > #define __FLT_HAS_INFINITY__ 0 > > #define __FLT_HAS_QUIET_NAN__ 0 > > #define __LDBL_HAS_DENORM__ 0 > > #define __LDBL_HAS_INFINITY__ 0 > > #define __LDBL_HAS_QUIET_NAN__ 0 > > $ > > > > which looks reasonable to me. This seems straightforward to fix to me, so > > I'll include it along with verification I am about to schedule (assuming > > that this will be enough for libgfortran to actually build; obviously it > > hasn't been tried by anyone with such a setup for a while now, as these > > libgfortran checks date back to 2009). > > Well, it is still broken, owing to NetBSD failing to implement POSIX 2008 > locale handling correctly, apparently deliberately[1], and missing > uselocale(3)[2] while still providing newlocale(3). This confuses our > conditionals and consequently: > > .../libgfortran/io/transfer.c: In function 'data_transfer_init_worker': > .../libgfortran/io/transfer.c:3416:30: error: > 'old_locale_lock' undeclared (first use in this function) > 3416 | __gthread_mutex_lock (_locale_lock); > | ^~~ > > etc. > > We can probably work it around by downgrading to setlocale(3) for NetBSD > (i.e. whenever either function is missing) unless someone from the NetBSD > community contributes a better implementation (they seem to prefer their > own non-standard printf_l(3) library API). Hi Maciej, I've been building successfully with setting: export ac_cv_func_freelocale=no export ac_cv_func_newlocale=no export ac_cv_func_uselocale=no I think the code to avoid these functions already exists, but just the configure tests need tuning. Also, this is amazing work!
Re: [PATCH 2/2] sparc: Run SUBTARGET_INIT_BUILTINS if it exists
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 canonical function names as > the symbol name in C libraries, and libcalls will only work if > the builtins are patched to emit the correct library name. > > For example, on NetBSD, cabsl has the symbol name __c99_cabsl, > and the patching is done via netbsd_patch_builtin. > > With this change, libgfortran.so is correctly built with a > reference to __c99_cabsl, instead of "cabsl" which is not defined.
