https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113143
--- Comment #11 from Alexander von Gluck ---
Hm.. Could you point me to where Linux is using the (get/set/swap)context
calls? I still haven't found them in the codebase.
I don't want to miss any edge cases if I work up a patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113143
--- Comment #9 from Alexander von Gluck ---
Doing a little research, it looks like complaints of ucontext.h have come up
before multiple times:
Similar issue on OpenBSD a long time ago:
https://gcc-help.gcc.gnu.narkive.com/Xx1bResV/can-t-build-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113143
--- Comment #8 from Alexander von Gluck ---
Not at all a dumb question :-)
I'm working through compiling libgo / gccgo on Haiku.We have our own lovely
libc which tests posix compliant.
Some historic consideration behind us not having ucont
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113143
--- Comment #6 from Alexander von Gluck ---
For added clairity. Searching the upstream go sources:
```
grep -R getcontext
src/cmd/vendor/golang.org/x/sys/unix/syscall_netbsd.go:// getcontext
src/cmd/vendor/golang.org/x/sys/unix/zsysnum_freebsd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113143
--- Comment #5 from Alexander von Gluck ---
> I understand that makecontext/getcontext/setcontext were removed from POSIX.
> However, there is no adequate replacement. Their functionality is absolutely
> required for what libgo does.
No Linu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113143
--- Comment #3 from Alexander von Gluck ---
Good call out. It looks like in 2004 these functions were flagged as
obsolescent though:
https://pubs.opengroup.org/onlinepubs/009695399/functions/makecontext.html
Here's the note on it in the linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113143
--- Comment #1 from Alexander von Gluck ---
$ grep -R ucontext.h gcc/libgo
gcc/libgo/configure:#include
gcc/libgo/configure.ac:#include
gcc/libgo/go/runtime/runtime2.go:// _sizeof_ucontext_t is defined by
mkrsysinfo.sh from .
gcc/libgo/misc/c
Assignee: ian at airs dot com
Reporter: kallisti5 at unixzen dot com
Target Milestone: ---
libgo/sysinfo.c references #include which breaks the libgo build
on strict POSIX compliance platforms.
ucontext.h was removed in issue 7, and types were migrated to signal.h.
Old 2004 spec:
https
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017
--- Comment #67 from Alexander von Gluck ---
(In reply to cqwrteur from comment #65)
>
> Difficult? hmmm. Even middle school kids could...
Uh uh. Yeah i'm just tuning you out at this point.
*anyway* for the adults left in the thread. Jonat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017
--- Comment #64 from Alexander von Gluck ---
(In reply to cqwrteur from comment #61)
> TBH, I failed to see how cross-compile in llvm is simple compared to GCC.
I mean... bootstrap. Compiling Canadian toolchains to compile non-Canadian
toolcha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017
--- Comment #56 from Alexander von Gluck ---
Canadian builds are pretty important in GCC.
clang doesn't really need Canadian builds since they support all targets out of
the box on every platform, but we don't have that luxury with gcc.
With t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017
Alexander von Gluck changed:
What|Removed |Added
CC||kallisti5 at unixzen dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89955
--- Comment #8 from Alexander von Gluck ---
Looks good to me. Now also matches other architectures.
Thanks! (viva riscv)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90653
Alexander von Gluck changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90653
--- Comment #6 from Alexander von Gluck ---
Created attachment 46424
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46424&action=edit
gcc8-verbose.txt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90653
--- Comment #5 from Alexander von Gluck ---
Created attachment 46423
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46423&action=edit
gcc7-verbose.txt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90653
--- Comment #4 from Alexander von Gluck ---
ok, this one got kinda long. I've discovered the "how".
gcc7 calling the linker using a --sysroot:
/work/generated.ppc/objects/haiku/ppc/packaging/repositories/HaikuPortsCross-build/sys-devel/gcc_boot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90653
--- Comment #3 from Alexander von Gluck ---
I ran an strace on it, and it's almost like ld isn't aware of the correct
library directory for our libraries after gcc8...
8838 openat(AT_FDCWD,
"/work/generated.ppc/cross-tools-ppc/lib/gcc/powerpc-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90653
--- Comment #2 from Alexander von Gluck ---
I was wrong about the autotools aspect... it *is* passing the sysroot to gcc
during the C compiler test.
I reproduced the test configure is running and enabled verbosity...
root@9e90f9304b75:/work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90653
--- Comment #1 from Alexander von Gluck ---
Created attachment 46421
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46421&action=edit
config.loh
attached is the config.log from gcc.
I should mention we see the same error across all of our
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: kallisti5 at unixzen dot com
Target Milestone: ---
After updating from gcc 7.3.x to 8.3.x, the early stage of our bootstrap is no
longer finding our provided sysroot.
Build flags
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89955
--- Comment #4 from Alexander von Gluck ---
oh.. also some context I missed.
Our libraries aren't at /lib,/usr/lib,etc. (which is also reflected in our os
config headers)
Am I wrong to think making that assumption in the architecture level seem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89955
--- Comment #3 from Alexander von Gluck ---
The issue here is RISC-V is the only one that does this. We do override the
STARTFILE_PREFIX_SPEC for our OS, however the architecture headers come later
and undo our undef.
root@b36eea373140:/work/s
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: kallisti5 at unixzen dot com
Target Milestone: ---
https://gcc.gnu.org/viewcvs/gcc/trunk/gcc/config/riscv/riscv.h?view=markup#l885
gcc/config/riscv.h defines STARTFILE_PREFIX_SPEC which breaks sysroot's.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81283
Alexander von Gluck changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81283
--- Comment #4 from Alexander von Gluck ---
I mean... I know we have 32-bit x86 builds using that exact same code :-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81283
--- Comment #3 from Alexander von Gluck ---
I may be misguided, but wouldn't it be possible to handle these in software
with some sync's and some wrapper code?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81283
--- Comment #1 from Alexander von Gluck ---
Here is some context on our wrapper for the atomic call generating the
__atomic_fetch_add_8 references.
static __inline__ void
atomic_set64(int64* value, int64 newValue)
{
__atomic_store_n(valu
: plugins
Assignee: unassigned at gcc dot gnu.org
Reporter: kallisti5 at unixzen dot com
Target Milestone: ---
Context:
/home/kallisti5/Code/haiku/generated.ppc/cross-tools-ppc/bin/powerpc-apple-haiku-gcc
-fno-strict-aliasing -fno-tree-vrp -Wno-array-bounds -Xlinker --no
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60358
--- Comment #1 from Alexander von Gluck ---
Created attachment 32225
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32225&action=edit
rev2
an additional resolution path. This one may be better, however driver-arm.c
would need additional cha
Assignee: unassigned at gcc dot gnu.org
Reporter: kallisti5 at unixzen dot com
Created attachment 32224
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32224&action=edit
fix revision 1
host_detect_local_cpu only works on Linux platforms and should be disable on
Haiku (due
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56938
Bug #: 56938
Summary: Compiling GCC 4.6.3 with GCC 4.8.0 results in internal
build errors.
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52986
Bug #: 52986
Summary: x86_64 GCC 4.7.0 can't compile x86 GCC 4.6.2;
gtype-desc.c
Classification: Unclassified
Product: gcc
Version: 4.6.2
Status: UNCONFIRMED
33 matches
Mail list logo
