[Bug target/85401] segfault building code for VAX

[coypu at sdf dot org]

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

[Bug target/86811] Vax port needs updating for CVE-2017-5753

[coypu at sdf dot org]

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

[coypu at sdf dot org]

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/58442] bootstrapping vax crashes on NetBSD

[coypu at sdf dot org]

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/77800] Undefined ref to host_detect_local_cpu on netbsd/arm

[coypu at sdf dot org]

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/58901] vax bootstrap fails on subreg reload

[coypu at sdf dot org]

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/85401] segfault building code for VAX

[coypu at sdf dot org]

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/85401] segfault building code for VAX

[coypu at sdf dot org]

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/77952] c++11 and gcc: internal compiler error: in convert_move

[coypu at sdf dot org]

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 libgcc/90929] libgcc MIPS __clear_cache shouldn't be a no-op

[coypu at sdf dot org]

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 libgcc/90929] New: libgcc MIPS __clear_cache shouldn't be a no-op

[coypu at sdf dot org]

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 target/90360] New: Missed optimization: unnecessary use of callee-saved registers

[coypu at sdf dot org]

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 c/448] -related issues (C99 issues)

[coypu at sdf dot org]

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 inline-asm/62144] "Frame pointer required, but reserved" error with -fomit-frame-pointer but only with -m32 -O2

[coypu at sdf dot org]

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

[coypu at sdf dot org]

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 libstdc++/88421] compat C headers break building GCC with GCC

[coypu at sdf dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88421

--- Comment #3 from coypu  ---
include/c_compatibility/fenv.h

[Bug other/65794] Building crossback fails: No rule to make target `auto-build.h', needed by `build/genmddeps.o'

[coypu at sdf dot org]

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] compat C headers break building GCC with GCC

[coypu at sdf dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88421

--- Comment #1 from coypu  ---
suggested change: put #include_next outside of include guards?

[Bug libstdc++/88421] New: compat C headers break building GCC with GCC

[coypu at sdf dot org]

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 c++/88194] can

[coypu at sdf dot org]

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

[coypu at sdf dot org]

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

[coypu at sdf dot org]

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 target/86383] [9 Regression] arm-netbsdelf cross compiler fails in selftests

[coypu at sdf dot org]

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

[coypu at sdf dot org]

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

[coypu at sdf dot org]

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

[coypu at sdf dot org]

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

[coypu at sdf dot org]

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 target/87221] cannot build with -pie

[coypu at sdf dot org]

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/87221] cannot build with -pie

[coypu at sdf dot org]

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 c/87221] New: cannot build with -pie

[coypu at sdf dot org]

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/86383] [9 Regression] arm-netbsdelf cross compiler fails in selftests

[coypu at sdf dot org]

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/85905] cannot build for netbsd/alpha (with patch)

[coypu at sdf dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85905

coypu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #1 from coypu  ---
Committed in revision 261707.

[Bug target/85905] New: cannot build for netbsd/alpha (with patch)

[coypu at sdf dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85905

Bug ID: 85905
   Summary: cannot build for netbsd/alpha (with patch)
   Product: gcc
   Version: 9.0
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 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 cannot create executables:

configure:3725: checking for C compiler default output file name
configure:3747: /tmp/build/./gcc/xgcc -B/tmp/build/./gcc/
-B/usr/local/alpha--netbsd/bin/ -B/usr/local/alpha--netbsd/lib/ -isystem
/usr/local/alpha--netbsd/include -isystem /usr/local/alpha--netbsd/sys-include
--sysroot=/home/fly/alpha/destdir.alpha/   -g -O2 -mieee   conftest.c  >&5
/home/fly/alpha/tooldir.NetBSD-8.99.17-amd64/alpha--netbsd/bin/ld: cannot find
crt1.o: No such file or directory
collect2: error: ld returned 1 exit status


I include two tm files that have effect on STARTFILE_SPEC definition.


alpha/elf.h:
#undef  STARTFILE_SPEC
#ifdef HAVE_LD_PIE
#define STARTFILE_SPEC \
  "%{!shared: %{pg|p:gcrt1.o%s;pie:Scrt1.o%s;:crt1.o%s}}\
   crti.o%s %{static:crtbeginT.o%s;shared|pie:crtbeginS.o%s;:crtbegin.o%s}"

This is good for linux probably but I don't have crt1.o on netbsd.

netbsd-elf.h

#define NETBSD_STARTFILE_SPEC   \
  "%{!shared:   \
 %{pg:gcrt0%O%s}\
 %{!pg: \
   %{p:gcrt0%O%s}   \
   %{!p:crt0%O%s}}} \
   %:if-exists(crti%O%s)\
   %{static:%:if-exists-else(crtbeginT%O%s crtbegin%O%s)} \
   %{!static: \
 %{!shared:crtbegin%O%s} %{shared:crtbeginS%O%s}}"

#undef STARTFILE_SPEC
#define STARTFILE_SPEC NETBSD_STARTFILE_SPEC

This should work for all netbsd targets.

Attached is a patch to move alpha/elf.h definitions to linux.
I've previously sent it to gcc-patches but it didn't work so well. I'll resend.
https://gcc.gnu.org/ml/gcc-patches/2017-10/msg00887.html

I'm not very good at cross building and relying on netbsd's existing cross
tools to do these checks (binutils etc.). I don't know how to set it up for
openbsd, and they don't provide a similar toolchain. I have no alpha hardware
of my own but I tested this on someone's machine then.

[Bug libstdc++/85904] New: configure issue cross compiling on netbsd, with patch

[coypu at sdf dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85904

Bug ID: 85904
   Summary: configure issue cross compiling on netbsd, with patch
   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: ---

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) I got:

/home/fly/gcc/libstdc++-v3/libsupc++/new_opa.cc:62:1: error: 'void*
aligned_alloc(std::size_t, std::size_t)' was declared 'extern' and later
'static' [-fpermissive]
 aligned_alloc (std::size_t al, std::size_t sz)
 ^
In file included from /tmp/build/alpha--netbsd/libstdc++-v3/include/cstdlib:75,
 from
/tmp/build/alpha--netbsd/libstdc++-v3/include/stdlib.h:36,
 from /home/fly/gcc/libstdc++-v3/libsupc++/new_opa.cc:27:
/tmp/build/gcc/include-fixed/stdlib.h:254:7: note: previous declaration of
'void* aligned_alloc(size_t, size_t)'
 void *aligned_alloc(size_t, size_t);
   ^


I took the liberty to modify configure following similar platform examples.
with the patches I can build trunk.
Yes I will also email it to gcc-patches.

[Bug target/85401] segfault building code for VAX

[coypu at sdf dot org]

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 
Date:   Tue Jan 6 11:51:16 2015 +

2015-01-06  Thomas Preud'homme  

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

[coypu at sdf dot org]

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

[coypu at sdf dot org]

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

[coypu at sdf dot org]

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/85152] New: VAX ICE with -O2

[coypu at sdf dot org]

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/85151] New: VAX ICE with -O2

[coypu at sdf dot org]

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 other/83826] Fixinclude creates redefinitions

[coypu at sdf dot org]

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

[coypu at sdf dot org]

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

[coypu at sdf dot org]

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 target/83302] New: i386 stack_probe has side effects

[coypu at sdf dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83302

Bug ID: 83302
   Summary: i386 stack_probe has side effects
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  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://marcan.st/2017/12/debugging-an-evil-go-runtime-bug/

[Bug target/82068] wrong double to uint64_t conversion with -mieee

[coypu at sdf dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82068

coypu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #5 from coypu  ---
OK, after asking and learning how an alpha IEEE754 implementation should work
(with the kernel completing parts), it seems that it's a netbsd kernel bug.

Sorry for the noise.

[Bug c/82068] wrong double to uint64_t conversion with -mieee

[coypu at sdf dot org]

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 object, also attached).

It won't be surprising if the problem is not GCC, but I don't know enough about
alpha to know.

[Bug c/82068] wrong double to uint64_t conversion with -mieee

[coypu at sdf dot org]

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

[Bug c/82068] wrong double to uint64_t conversion with -mieee

[coypu at sdf dot org]

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

[Bug c/82068] New: wrong double to uint64_t conversion with -mieee

[coypu at sdf dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82068

Bug ID: 82068
   Summary: wrong double to uint64_t conversion with -mieee
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  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)
{
long double even = 9223372036854775808.00; /* 2^63 */
uint64_t unsigned_even = even;

assert(unsigned_even % 2 == 0);

return 0;
}

[Bug libstdc++/81353] New: Please provide a libstdc++ version macro

[coypu at sdf dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81353

Bug ID: 81353
   Summary: Please provide a libstdc++ version macro
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: 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 version.

[Bug libgcc/81199] fallback definition of count_leading_zeros references hidden symbol

[coypu at sdf dot org]

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)."

[Bug libgcc/81199] fallback definition of count_leading_zeros references hidden symbol

[coypu at sdf dot org]

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.

[Bug libgcc/81199] New: fallback definition of count_leading_zeros references hidden symbol

[coypu at sdf dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81199

Bug ID: 81199
   Summary: fallback definition of count_leading_zeros references
hidden symbol
   Product: gcc
   Version: 5.4.0
Status: UNCONFIRMED
  Severity: normal
  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/ccmake.dir/CursesDialog/ccmake.cxx.o
[ 88%] Linking CXX executable ../bin/ccmake
ld: ../bin/ccmake: hidden symbol `__clz_tab' in /usr/lib/libgcc.a(_clz.o) is
referenced by DSO
ld: final link failed: Bad value

my analysis may be wrong, but this appears to be because vax does not provide a
definition of count_leading_zeros in include/longlong.h, and then we have:

extern const UQItype __clz_tab[256] attribute_hidden;

...

#if !defined (count_leading_zeros)
#define count_leading_zeros(count, x) \
  do {  \
UWtype __xr = (x);  \
UWtype __a; \
\
if (W_TYPE_SIZE <= 32)  \
  { \
__a = __xr < ((UWtype)1<<2*__BITS4) \
  ? (__xr < ((UWtype)1<<__BITS4) ? 0 : __BITS4) \
  : (__xr < ((UWtype)1<<3*__BITS4) ?  2*__BITS4 : 3*__BITS4);   \
  } \
else\
  { \
for (__a = W_TYPE_SIZE - 8; __a > 0; __a -= 8)  \
  if (((__xr >> __a) & 0xff) != 0)  \
break;  \
  } \
\
(count) = W_TYPE_SIZE - (__clz_tab[__xr >> __a] + __a); \
  } while (0)
#define COUNT_LEADING_ZEROS_0 W_TYPE_SIZE
#endif


this appears to be true for the definition for alpha as well.

[Bug c/80685] New: -Wnonnull-compare warns based on builtin declaration

[coypu at sdf dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80685

Bug ID: 80685
   Summary: -Wnonnull-compare warns based on builtin declaration
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 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.

Building with gcc -Werror -Wall etc. I get lots of warnings about these NULL
checks:

/usr/src/lib/libc/../../common/lib/libc/string/strncat.c: In function
'strncat':
/usr/src/lib/libc/../../common/lib/libc/string/strncat.c:63:2: error: nonnull
argument 'dst' compared to NULL [-Werror=nonnull-compare]
  _DIAGASSERT(dst != NULL);
  ^

I believe that warning may be bogus, feel free to close if you disagree.

[Bug target/80600] hidden symbol `__cpu_model' is referenced by DSO

[coypu at sdf dot org]

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 
> Date:   Fri Nov 11 17:31:07 2016 +
> 
> [i386][musl] Add cpuinfo to static libgcc only on *-musl*
> 
> The __cpu_indicator_init and __cpu_model symbols are not safe to use
> from shared libgcc_s.so from ifunc resolvers, so since gcc-6, only
> the definitions from static libgcc.a are used, however the symbols
> are kept in libgcc_s as well for backward compatibility (with
> appropriate symbol version).  On targets without such backward
> compatibility concern add cpuinfo to the static library only (this
> avoids running the ctor, reduces libgcc_s size and elf abi concerns
> about the versioned symbols).
> 
> works for you.

Thanks. if I understand it correctly, it breaks backwards compatibility, so
would rather avoid it. With my (not upstreamable) patch we have a working GCC,
so it's not a pressing issue for us, although it seems to affect many other
platforms.

[Bug target/80600] hidden symbol `__cpu_model' is referenced by DSO

[coypu at sdf dot org]

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.

[Bug target/80600] hidden symbol `__cpu_model' is referenced by DSO

[coypu at sdf dot org]

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
attempt to open /usr/lib/crti.o succeeded
attempt to open /usr/lib/crtn.o succeeded
attempt to open /usr/lib/libc.so succeeded
attempt to open /usr/lib/libm.so succeeded
attempt to open /usr/pkg/gcc7/lib/gcc/x86_64--netbsd/7.1.0/../../../libgcc_s.so
succeeded
attempt to open
/usr/pkg/gcc7/lib/gcc/x86_64--netbsd/7.1.0/../../../libgfortran.so succeeded
attempt to open
/usr/pkg/gcc7/lib/gcc/x86_64--netbsd/7.1.0/../../../libquadmath.so succeeded
attempt to open /usr/pkg/gcc7/lib/gcc/x86_64--netbsd/7.1.0/libgcc.a succeeded
attempt to open /var/tmp//ccCfh5i1.o succeeded

if I 'nm library | grep cpu_model' I get:
/usr/pkg/gcc7/lib/gcc/x86_64--netbsd/7.1.0/../../../libgcc_s.so:   
00214540 b __cpu_model
/usr/pkg/gcc7/lib/gcc/x86_64--netbsd/7.1.0/../../../libgfortran.so:
 U __cpu_model
/usr/pkg/gcc7/lib/gcc/x86_64--netbsd/7.1.0/libgcc.a:   
 B __cpu_model

I got everything (all those) under /usr/pkg/gcc7 from building GCC 7.1.0, it's
possible I built it wrong
I hope this is the right information

[Bug target/80600] hidden symbol `__cpu_model' is referenced by DSO

[coypu at sdf dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80600

--- Comment #1 from coypu  ---
Related and possible duplicate for dfly: libgcc/61309

[Bug target/80600] New: hidden symbol `__cpu_model' is referenced by DSO

[coypu at sdf dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80600

Bug ID: 80600
   Summary: hidden symbol `__cpu_model' is referenced by DSO
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: 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
/usr/bin/ld: final link failed: Bad value
collect2: error: ld returned 1 exit status

Trying the test case in target/65612 which sounds related:
mv20.cc:11:5: error: multiversioning needs ifunc which is not supported on this
target

[Bug c/78927] New: implicit-fallthrough is very picky about FALLTHROUGH comment location

[coypu at sdf dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78927

Bug ID: 78927
   Summary: implicit-fallthrough is very picky about FALLTHROUGH
comment location
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  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) {
case 1:
{
a = 3;
/* FALLTHROUGH */
}
case 2:
{
a = 2;
break;
}
default:
a = 3;
}
return 0;
}

% /home/pkg2/pkg/gcc7snapshot/bin/gcc -Werror=implicit-fallthrough test16.c
test16.c: In function ‘main’:
test16.c:7:6: error: this statement may fall through
[-Werror=implicit-fallthrough=]
a = 3;
~~^~~
test16.c:10:3: note: here
   case 2:
   ^~~~
cc1: some warnings being treated as errors

% /home/pkg2/pkg/gcc7snapshot/bin/gcc --version
gcc (GCC) 7.0.0 20161218 (experimental)
Copyright (C) 2016 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

There are some more warnings I get while compiling netbsd's kernel regarding
FALLTHRU location, but perhaps more "controversial" than this.
Moving the FALLTHROUGH comment one line below works.

[Bug bootstrap/77800] New: Undefined ref to host_detect_local_cpu on netbsd/arm

[coypu at sdf dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77800

Bug ID: 77800
   Summary: Undefined ref to host_detect_local_cpu on netbsd/arm
   Product: gcc
   Version: 5.4.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 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 believe this is because gcc/config.host includes driver-arm.o which defines
this function only on freebsd/arm and linux/arm.

NetBSD does have a procfs which is mounted by default. it usually does include
the expected useful info on /proc/cpuinfo (although not on netbsd-7.0.1/arm,
maybe this will change in a next release).

I am working around this by excluding the prototype for this function in
gcc/config/arm/arm.h.

I don't believe any of this has changed in GCC 5.4.1, but did not try to build
it yet.

[Bug bootstrap/77774] Build failure on netbsd-7.0.1/arm6hf of gcc 6.2.0, 7-20160925

[coypu at sdf dot org]

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.

[Bug bootstrap/77774] Build failure on netbsd-7.0.1/arm6hf of gcc 6.2.0, 7-20160925

[coypu at sdf dot org]

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.

[Bug bootstrap/77774] New: Build failure on netbsd-7.0.1/arm6hf of gcc 6.2.0, 7-20160925

[coypu at sdf dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=4

Bug ID: 4
   Summary: Build failure on netbsd-7.0.1/arm6hf of gcc 6.2.0,
7-20160925
   Product: gcc
   Version: 6.2.0
Status: UNCONFIRMED
  Severity: normal
  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 build.

This is from an RPi1 (ARM1176JZF-S apparently) armed with a lot of swap.
failing on things like:
undefined reference to `arm_no_early_mul_dep(rtx_def*, rtx_def*)'

If relevant, native compiler:
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/lto-wrapper
Target: armv6--netbsdelf-eabihf
Configured with: /usr/7/src/tools/gcc/../../external/gpl3/gcc/dist/configure
--target=armv6--netbsdelf-eabihf --enable-long-long --enable-threads
--with-bugurl=http://www.NetBSD.org/Misc/send-pr.html --with-pkgversion='NetBSD
nb2 20150115' --with-system-zlib --enable-__cxa_atexit
--enable-libstdcxx-threads --enable-libstdcxx-time=rt --enable-lto
--with-mpc-lib=/var/obj/mknative/evbarm-earmv6hf/usr/7/src/external/lgpl3/mpc/lib/libmpc
--with-mpfr-lib=/var/obj/mknative/evbarm-earmv6hf/usr/7/src/external/lgpl3/mpfr/lib/libmpfr
--with-gmp-lib=/var/obj/mknative/evbarm-earmv6hf/usr/7/src/external/lgpl3/gmp/lib/libgmp
--with-mpc-include=/usr/7/src/external/lgpl3/mpc/dist/src
--with-mpfr-include=/usr/7/src/external/lgpl3/mpfr/dist/src
--with-gmp-include=/usr/7/src/external/lgpl3/gmp/lib/libgmp/arch/earmhf
--enable-tls --enable-initfini-array --disable-multilib --disable-symvers
--disable-libstdcxx-pch --build=x86_64-unknown-netbsd6.0.
--host=armv6--netbsdelf-eabihf
--with-sysroot=/var/obj/mknative/evbarm-earmv6hf/usr/7/src/destdir.evbarm
Thread model: posix
gcc version 4.8.4 (nb2 20150115)

[Bug libgcc/77470] libssp may have bad includes

[coypu at sdf dot org]

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:
 #if _FORTIFY_SOURCE > 0
 #include 
 #endif

for non-netbsd, you can likely achieve the same failure by attempting
to compile this code:
 #define _FORTIFY_SOURCE
 #include 
 #include 
 void main() { printf("Hello!"); }

[Bug c/77480] New: netbsd specfile will not link against libc when building -shared

[coypu at sdf dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77480

Bug ID: 77480
   Summary: netbsd specfile will not link against libc when
building -shared
   Product: gcc
   Version: 5.4.0
Status: UNCONFIRMED
  Severity: normal
  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 that I needed to build more things.

[Bug libgcc/77470] New: libssp may have bad includes

[coypu at sdf dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77470

Bug ID: 77470
   Summary: libssp may have bad includes
   Product: gcc
   Version: 5.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgcc
  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 a header file:

$ grep ssp /usr/pkg/gcc5/lib/gcc/x86_64--netbsd/5.4.0/include/ssp/stdio.h 
#include 

there is no /usr/pkg/gcc5/lib/gcc/x86_64--netbsd/5.4.0/include/ssp.h,
only /usr/pkg/gcc5/lib/gcc/x86_64--netbsd/5.4.0/include/ssp/ssp.h.

and if I try to build hello world (i.e. include stdio.h) with -D_FORTIFY_SOURCE
I get:

$ /usr/pkg/gcc5/bin/gcc -D_FORTIFY_SOURCE test.c
In file included from /usr/include/stdio.h:597:0,
 from test.c:1:
/usr/pkg/gcc5/lib/gcc/x86_64--netbsd/5.4.0/include/ssp/stdio.h:38:17: fatal
error: ssp.h: No such file or directory
compilation terminated.