https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64402
--- Comment #4 from Yaakov Selkowitz ---
(In reply to Bernd Edlinger from comment #3)
> Created attachment 37172 [details]
> Patch to fix ICE and make interrupt restore r0
That allows me to finish the --without-headers build of 5.3.0 and subsequ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65501
--- Comment #6 from Yaakov Selkowitz ---
Created attachment 37849
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37849&action=edit
patch for gcc-5
(In reply to Jeffrey A. Law from comment #5)
> Fixed on the trunk by the change for 68271.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51749
--- Comment #32 from Yaakov Selkowitz ---
In an effort to enable C99-in-C++ functionality on newlib-based targets
(including Cygwin and RTEMS), we just overhauled our feature test macros to be
functionally compatible with glibc's. Ignoring the l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21530
Yaakov Selkowitz changed:
What|Removed |Added
CC||yselkowi at redhat dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64400
Yaakov Selkowitz changed:
What|Removed |Added
Version|5.2.0 |6.1.0
--- Comment #2 from Yaakov Selk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64375
--- Comment #2 from Yaakov Selkowitz ---
Still not working with 6.1.0 m32c-elf at calls.c:3679.
++
Assignee: unassigned at gcc dot gnu.org
Reporter: yselkowi at redhat dot com
Target Milestone: ---
Building gcc 6.1.0 with newlib 2.4.0 for target msp430-elf fails during
configure-target-libstdc++-v3 in the 'large' multilib:
checking how size_t is mangled... x
: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: yselkowi at redhat dot com
Target Milestone: ---
Host: x86_64-cygwin
Target: rl78-elf
Build: x86_64-cygwin
rl78-elf FTBFS in GCC 6.1 libstdc++-v3 (but not in recent 4.x or 5) due to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71135
--- Comment #2 from Yaakov Selkowitz ---
(In reply to Jonathan Wakely from comment #1)
> I think we just want to disable TM library support for such targets.
Okay, h8300-elf and xstormy16-elf are both similarly affected. msp430-elf
probably wil
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71135
--- Comment #3 from Yaakov Selkowitz ---
It seems that #define _GLIBCXX_USE_WEAK_REF 1 would fix this; the question is
where exactly it should go (config/os/generic/os_defines.h ?) and under what
conditions.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71135
--- Comment #4 from Yaakov Selkowitz ---
(In reply to Yaakov Selkowitz from comment #3)
> It seems that #define _GLIBCXX_USE_WEAK_REF 1 would fix this; the question
> is where exactly it should go (config/os/generic/os_defines.h ?) and under
> wh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71133
--- Comment #1 from Yaakov Selkowitz ---
Created attachment 38505
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38505&action=edit
Draft patch for 6.1
The results of this test are (so far) used only in the code that will later
fail to comp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71135
--- Comment #5 from Yaakov Selkowitz ---
Possible patch included in attachment 38505 for bug 71133.
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: yselkowi at redhat dot com
Target Milestone: ---
Host: x86_64-cygwin
Target: mmix-knuth-mmixware
Build: x86_64-cygwin
Created attachment 38530
--> https://gcc.gnu.org/bugzi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71208
Yaakov Selkowitz changed:
What|Removed |Added
See Also||https://sourceware.org/bugz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71208
--- Comment #10 from Yaakov Selkowitz ---
A fix for PR ld/20125, set for the 2.29.1 release, has been committed. Does
anything further need to happen on the gcc side?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79771
--- Comment #4 from Yaakov Selkowitz ---
This is an upstream issue in the recent zlib releases, here's a patch:
https://github.com/cygwinports/zlib/blob/master/1.2.11-gzopen_w.patch
Configuring with --with-system-zlib avoids this, as long as gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79771
--- Comment #6 from Yaakov Selkowitz ---
(In reply to Jakub Jelinek from comment #5)
> Do you really need even the zlib.def change?
For standalone zlib, yes; if you try to export a symbol which doesn't exist, ld
errors out.
> That part has been
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: yselkowi at redhat dot com
Host: x86_64-cygwin
Target: cr16-elf
Build: x86_64-cygwin
While compiling gcc-4.9.2 --target=cr16-elf with binutils-2.25 and newlib-2.2.0
libtool
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: yselkowi at redhat dot com
While building gcc-4.9.2 --target=tic6x-elf with newlib-2.2.0:
libtool: compile:
/usr/src/ports/cross-gcc/cross-gcc-4.9.2-1.x86_64/build/tic6x-elf/./gcc/xgcc
-B/usr/src/ports/cross-gcc/cross
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63681
--- Comment #6 from Yaakov Selkowitz ---
(In reply to Mikael Pettersson from comment #5)
> The ICE on bfin-elf started for 4.9 with r204985, and stopped for 5.0 with
> r210683. Backporting r210683 to current 4.9 branch is easy and fixes the
> IC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64451
Yaakov Selkowitz changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57295
Yaakov Selkowitz changed:
What|Removed |Added
CC||yselkowi at redhat dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57295
--- Comment #4 from Yaakov Selkowitz ---
This still occurs with 4.9.2, and the patch in comment 2 fixes it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64408
--- Comment #3 from Yaakov Selkowitz ---
(In reply to Nick Clifton from comment #2)
> Fixed by:
>
> https://gcc.gnu.org/ml/gcc-patches/2015-02/msg00247.html
Fix confirmed with 4.9.2; thanks.
: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: yselkowi at redhat dot com
With binutils-2.25, bootstrapping gcc-4.9.2 with --target=iq2000-elf
--without-headers fails:
/usr/src/ports/cross-gcc/cross-gcc-4.9.2-1.x86_64/build/iq2000-elf/./gcc/xgcc
-B/usr/src/ports/cross
Assignee: unassigned at gcc dot gnu.org
Reporter: yselkowi at redhat dot com
Host: x86_64-cygwin
Target: avr-elf
Build: x86_64-cygwin
Building gcc-4.9.2 with --target=avr-elf --without-headers using binutils-2.25,
libgcc.a itself and crtend.o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63681
Yaakov Selkowitz changed:
What|Removed |Added
CC||yselkowi at redhat dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63681
--- Comment #3 from Yaakov Selkowitz ---
I'm seeing an ICE in the same code on the tic6x-elf target as well.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57636
--- Comment #6 from Yaakov Selkowitz ---
This is working in 4.9.2, so it seems that indeed fixed it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45360
Yaakov Selkowitz changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
Assignee: unassigned at gcc dot gnu.org
Reporter: yselkowi at redhat dot com
Host: x86_64-cygwin
Target: mep-elf
Build: x86_64-cygwin
While building 4.9.2 with --target=mep-elf --without-headers, in apparently all
multilibs:
/usr/src/ports/cross
Assignee: unassigned at gcc dot gnu.org
Reporter: yselkowi at redhat dot com
Host: x86_64-cygwin
Target: m32c-elf, m32c-rtems
Build: x86_64-cygwin
While building 4.9.2 with binutils-2.25 for m32c-{elf,rtems} targets, the m32cm
multilib
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: yselkowi at redhat dot com
Host: x86_64-cygwin
Target: xstormy16-elf
Build: x86_64-cygwin
While compiling newlib-2.2.0 with gcc-4.9.2 --target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64407
--- Comment #1 from Yaakov Selkowitz ---
Created attachment 34333
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34333&action=edit
preprocessed source
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: yselkowi at redhat dot com
Host: x86_64-cygwin
Target: fr30-elf
Build: x86_64-cygwin
Created attachment 34334
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34334&acti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64400
Yaakov Selkowitz changed:
What|Removed |Added
Version|4.9.2 |5.2.0
--- Comment #1 from Yaakov Selk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64402
Yaakov Selkowitz changed:
What|Removed |Added
Version|4.9.2 |5.2.0
--- Comment #1 from Yaakov Selk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64375
Yaakov Selkowitz changed:
What|Removed |Added
CC||yselkowi at redhat dot com
-valid-code
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: yselkowi at redhat dot com
Target Milestone: ---
Host: x86_64-cygwin
Target: sh64-elf
Build: x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64403
Yaakov Selkowitz changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64424
Yaakov Selkowitz changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64401
Yaakov Selkowitz changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: yselkowi at redhat dot com
Target Milestone: ---
Host: x86_64-cygwin
Target: sh64-elf
Build: x86_64-cygwin
After the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67049
--- Comment #2 from Yaakov Selkowitz ---
(In reply to Kazumoto Kojima from comment #1)
> My bad. Could you please try this patch?
That gets me through libgcc, but when I get to newlib I see bug 67061.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67061
--- Comment #3 from Yaakov Selkowitz ---
(In reply to Kazumoto Kojima from comment #2)
> Does the patch below work?
Yes, this patch in combination of that from bug 67049 allows me to complete the
sh64-elf toolchain and does not break the sh-elf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65501
Yaakov Selkowitz changed:
What|Removed |Added
CC||yselkowi at redhat dot com
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: yselkowi at redhat dot com
CC: jon_y at users dot sourceforge.net, ktietz at gcc dot
gnu.org
Target Milestone: ---
Targets that use libssp for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77409
--- Comment #2 from Yaakov Selkowitz ---
(In reply to Andrew Pinski from comment #1)
> I don't think this is a security hole at all. In fact the security holes
> should be on the applications side rather than the library side.
The compiler is t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77409
--- Comment #8 from Yaakov Selkowitz ---
(In reply to Andrew Pinski from comment #3)
> In fact this is by design. NetBSD for an example has ssp/stdio.h where you
> use that to get the fority.
This does not apply where the libc provides its own
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77409
Yaakov Selkowitz changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALI
51 matches
Mail list logo
