"Jared D. McNeill" writes:
> Module Name: src
> Committed By: jmcneill
> Date: Sat Sep 18 10:45:11 UTC 2021
>
> Modified Files:
> src/external/gpl3/gcc/dist/gcc/config: host-darwin.c
> src/external/gpl3/gcc/dist/gcc/config/aarch64: aarch64.h
>
> Log Message:
> Fix build on
> On Jul 15, 2021, at 12:06 AM, matthew green wrote:
>
> "Christos Zoulas" writes:
>> Module Name: src
>> Committed By:christos
>> Date:Wed Jul 14 13:24:59 UTC 2021
>>
>> Modified Files:
>> src/external/gpl3/gcc/dist/gcc/ginclude: stddef.h
>>
>> Log Message:
>>
"Christos Zoulas" writes:
> Module Name: src
> Committed By: christos
> Date: Wed Jul 14 13:24:59 UTC 2021
>
> Modified Files:
> src/external/gpl3/gcc/dist/gcc/ginclude: stddef.h
>
> Log Message:
> clang does not support __float128 in our configuration and i386
shouldn't you
The condition is reversed. I will fix.
christos
> On Apr 26, 2021, at 10:31 PM, Rin Okuyama wrote:
>
> Hi,
>
> On 2021/04/26 7:25, Christos Zoulas wrote:
>> --- src/external/gpl3/gcc/usr.bin/cc1plus/Makefile:1.15 Sun Apr 11
>> 20:05:56 2021
>> +++
Hi,
On 2021/04/26 7:25, Christos Zoulas wrote:
--- src/external/gpl3/gcc/usr.bin/cc1plus/Makefile:1.15 Sun Apr 11 20:05:56 2021
+++ src/external/gpl3/gcc/usr.bin/cc1plus/Makefile Sun Apr 25 18:25:55 2021
(snip)
-.if ${MACHINE_ARCH} == "mipseb" || ${MACHINE_ARCH} == "mipsel"
+.if
On Wed, Oct 21, 2020 at 08:58:36AM +0900, Rin Okuyama wrote:
> I'm also one who feels hesitate to import Linux'ism into our basic
> components. However, for this problem in particular, I still think
> it is not a good choice to keep NetBSD support in driver-aarch64.c:
>
> (a) Our sysctl(3)-based
Hi,
(tech-toolchain@ added to cc)
On 2020/10/16 1:49, Kamil Rytarowski wrote:
On 15.10.2020 17:14, Rin Okuyama wrote:
On 2020/10/15 16:12, matthew green wrote:
Martin Husemann writes:
On Thu, Oct 15, 2020 at 05:28:12PM +1100, matthew green wrote:
you could try reverting most of our changes
Date:Fri, 16 Oct 2020 04:07:31 +
From:"Thomas Mueller"
Message-ID: <20201016052422.e063084...@mail.netbsd.org>
| Should I add ,linux to the end of the procfs line?
You can, but it isn't needed these days -- I used to mount procfs twice,
once without the linux
Excerpt from Rin Okuyama:
> Nowadays, -o linux is turned on by default (unless nolinux is
> specified explicitly). Still, native apps probably should not
> depend on it.
> This needs MI changes to procfs, not MD to aarch64. Should we
> enable /proc/cpuinfo unconditionally?
My NetBSD
On 15.10.2020 17:14, Rin Okuyama wrote:
> On 2020/10/15 16:12, matthew green wrote:
>> Martin Husemann writes:
>>> On Thu, Oct 15, 2020 at 05:28:12PM +1100, matthew green wrote:
you could try reverting most of our changes to this file and
making sure you run with /proc mounted -o linux.
On 2020/10/15 16:12, matthew green wrote:
Martin Husemann writes:
On Thu, Oct 15, 2020 at 05:28:12PM +1100, matthew green wrote:
you could try reverting most of our changes to this file and
making sure you run with /proc mounted -o linux. ryo@ recently
added additional /proc/cpuinfo support
Martin Husemann writes:
> On Thu, Oct 15, 2020 at 05:28:12PM +1100, matthew green wrote:
> > you could try reverting most of our changes to this file and
> > making sure you run with /proc mounted -o linux. ryo@ recently
> > added additional /proc/cpuinfo support that should make this
> > just
On Thu, Oct 15, 2020 at 05:28:12PM +1100, matthew green wrote:
> you could try reverting most of our changes to this file and
> making sure you run with /proc mounted -o linux. ryo@ recently
> added additional /proc/cpuinfo support that should make this
> just work with the upstream version, but
"Rin Okuyama" writes:
> Module Name: src
> Committed By: rin
> Date: Tue Oct 13 07:12:00 UTC 2020
>
> Modified Files:
> src/external/gpl3/gcc/dist/gcc/config/aarch64: driver-aarch64.c
>
> Log Message:
> Reduce diff with upstream a bit.
> No functional changes.
you could try
On 12.09.2020 23:36, Joerg Sonnenberger wrote:
> On Sat, Sep 12, 2020 at 10:24:16PM +0200, Kamil Rytarowski wrote:
>> On 12.09.2020 22:06, Joerg Sonnenberger wrote:
>>> On Fri, Sep 11, 2020 at 11:45:42PM +0200, Kamil Rytarowski wrote:
On 11.09.2020 23:38, Joerg Sonnenberger wrote:
> On
On Sat, Sep 12, 2020 at 10:24:16PM +0200, Kamil Rytarowski wrote:
> On 12.09.2020 22:06, Joerg Sonnenberger wrote:
> > On Fri, Sep 11, 2020 at 11:45:42PM +0200, Kamil Rytarowski wrote:
> >> On 11.09.2020 23:38, Joerg Sonnenberger wrote:
> >>> On Fri, Sep 11, 2020 at 04:07:24PM +0200, Kamil
On 12.09.2020 22:06, Joerg Sonnenberger wrote:
> On Fri, Sep 11, 2020 at 11:45:42PM +0200, Kamil Rytarowski wrote:
>> On 11.09.2020 23:38, Joerg Sonnenberger wrote:
>>> On Fri, Sep 11, 2020 at 04:07:24PM +0200, Kamil Rytarowski wrote:
The current code is confusing, as it attempts to use
On Fri, Sep 11, 2020 at 11:45:42PM +0200, Kamil Rytarowski wrote:
> On 11.09.2020 23:38, Joerg Sonnenberger wrote:
> > On Fri, Sep 11, 2020 at 04:07:24PM +0200, Kamil Rytarowski wrote:
> >> The current code is confusing, as it attempts to use unimplemented
> >> _PTHREAD_GETTCB_EXT() and in one
On 11.09.2020 23:38, Joerg Sonnenberger wrote:
> On Fri, Sep 11, 2020 at 04:07:24PM +0200, Kamil Rytarowski wrote:
>> The current code is confusing, as it attempts to use unimplemented
>> _PTHREAD_GETTCB_EXT() and in one place uses _lwp_getprivate_fast() in
>> other _lwp_getprivate(). This caused
On Fri, Sep 11, 2020 at 04:07:24PM +0200, Kamil Rytarowski wrote:
> The current code is confusing, as it attempts to use unimplemented
> _PTHREAD_GETTCB_EXT() and in one place uses _lwp_getprivate_fast() in
> other _lwp_getprivate(). This caused my confusion... as I assumed that
>
On 11.09.2020 07:13, Rin Okuyama wrote:
> Hi again,
>
> On 2020/09/10 21:53, Kamil Rytarowski wrote:
>> Module Name: src
>> Committed By: kamil
>> Date: Thu Sep 10 12:53:06 UTC 2020
>>
>> Modified Files:
>> src/external/gpl3/gcc/dist/libsanitizer/sanitizer_common:
>>
Hi again,
On 2020/09/10 21:53, Kamil Rytarowski wrote:
Module Name:src
Committed By: kamil
Date: Thu Sep 10 12:53:06 UTC 2020
Modified Files:
src/external/gpl3/gcc/dist/libsanitizer/sanitizer_common:
sanitizer_linux_libcdep.cc
On 05.09.2020 15:35, matthew green wrote:
> Module Name: src
> Committed By: mrg
> Date: Sat Sep 5 13:35:55 UTC 2020
>
> Modified Files:
> src/external/gpl3/gcc/dist/libsanitizer/sanitizer_common:
> sanitizer_linux.cc sanitizer_linux.h sanitizer_linux_libcdep.cc
>
Sorry for the late reply.
On 2020/08/11 1:16, Valery Ushakov wrote:
This sounds eerily similar to port-macppc/54827 - there's quite a bit
of confusion early on on my part there, but scroll to the last couple
of mails. http://gnats.netbsd.org/54827
It looks like some logic changed in MI gcc8
> May be we should also check other ports for similar gotcha proactively?
good idea. no other gcc/config/*/*netbsd* files define the
nasty STACK_BOUNDARY macro so hopefully we're good now.
thanks!
.mrg.
On Mon, Aug 10, 2020 at 06:24:39 +, Rin Okuyama wrote:
> Modified Files:
> src/external/gpl3/gcc/dist/gcc/config/m68k: netbsd-elf.h
>
> Log Message:
> PR port-m68k/6
>
> Reset STACK_BOUNDARY to default, 16, to fix strange freeze for amiga,
> when kernel is compiled by GCC8.
This
> Modified Files:
> src/external/gpl3/gcc/usr.bin/host-libcpp: Makefile
>
> Log Message:
> PR bin/55411 (Akihiko HAYASHI)
>
> Remove stray ``&&'' introduced in the previous revision, so that
> host tools are correctly passed to configure script.
>
> No similar problem for gcc.old. No
On 2020/06/02 17:03, matthew green wrote:
Module Name:src
Committed By: mrg
Date: Tue Jun 2 08:03:59 UTC 2020
Modified Files:
src/external/gpl3/gcc: gcc2netbsd
Log Message:
don't elide fortran components. we'd like to revive g77-as-gfortran.
To generate a diff of
Unfortunately this breaks building on a 9.0 arm64 host because it is
picking up /usr/include/aarch64/armreg.h and the one in 9.0 is missing a
bunch of stuff. It works when using armreg.h from the source tree instead,
eg:
-#include
+#include "/path/to/src/sys/arch/aarch64/include/armreg.h"
> >> > Module Name: src
> >> > Committed By:christos
> >> > Date:Wed Oct 16 15:01:56 UTC 2019
> >> >
> >> > Modified Files:
> >> > src/external/gpl3/gcc/dist/libobjc: encoding.c
> >> >
> >> > Log Message:
> >> > prevent DFmode re-definition.
> >>
> >> i'm not a fan of this
In article <20191016220250.ga23...@homeworld.netbsd.org>,
wrote:
>On Thu, Oct 17, 2019 at 07:08:45AM +1100, matthew green wrote:
>> "Christos Zoulas" writes:
>> > Module Name: src
>> > Committed By: christos
>> > Date: Wed Oct 16 15:01:56 UTC 2019
>> >
>> > Modified
On Thu, Oct 17, 2019 at 07:08:45AM +1100, matthew green wrote:
> "Christos Zoulas" writes:
> > Module Name:src
> > Committed By: christos
> > Date: Wed Oct 16 15:01:56 UTC 2019
> >
> > Modified Files:
> > src/external/gpl3/gcc/dist/libobjc: encoding.c
> >
> > Log
In article <9715.1571256...@splode.eterna.com.au>,
matthew green wrote:
>"Christos Zoulas" writes:
>> Module Name: src
>> Committed By:christos
>> Date:Wed Oct 16 15:01:56 UTC 2019
>>
>> Modified Files:
>> src/external/gpl3/gcc/dist/libobjc: encoding.c
>>
>> Log
"Christos Zoulas" writes:
> Module Name: src
> Committed By: christos
> Date: Wed Oct 16 15:01:56 UTC 2019
>
> Modified Files:
> src/external/gpl3/gcc/dist/libobjc: encoding.c
>
> Log Message:
> prevent DFmode re-definition.
i'm not a fan of this one. i'd like to figure out
what
On 04.10.2019 10:51, matthew green wrote:
> Module Name: src
> Committed By: mrg
> Date: Fri Oct 4 08:51:33 UTC 2019
>
> Modified Files:
> src/external/gpl3/gcc: README.gcc8
> src/external/gpl3/gcc/dist/gcc/config/aarch64: aarch64-netbsd.h
>
"Nick Hudson" writes:
> Module Name: src
> Committed By: skrll
> Date: Wed Oct 2 10:34:48 UTC 2019
>
> Modified Files:
> src/external/gpl3/gcc/usr.bin/gcc/arch/aarch64: defs.mk
>
> Log Message:
> Remove garbage. Maybe something is wrong with mknative or mrg's script?
thanks.
For future reference, proably by me:
Reproducer for the crash without the local diff:
#!/bin/sh
cat << EOF > oacc.i
int a, b;
int e() {
short *c = 0;
char d = c[a + 1];
b = d;
a += 2;
}
EOF
vax--netbsdelf-gcc -O2 -c oacc.i
This hits an assertion:
emit-rtl.c:2310 gcc_assert
Hi,
Christos Zoulas writes:
> Thank you. What's left now is to re-run mknative to regenerate the defs.mk
> file for libstdc++.
> mrg@ is going to do it for all archs at once because it will require an
> UPDATING entry to
> mention to clean in /usr/src/external/gpl3/lib/libstdc++. Once that is
Hi,
"Christos Zoulas" writes:
> Module Name: src
> Committed By: christos
> Date: Wed Jul 31 16:40:26 UTC 2019
>
> Modified Files:
> src/external/gpl3/gcc/dist/libstdc++-v3: configure
>
> Log Message:
> Manually patch the locale configuration to use the dragonfly code instead
>
On 01.06.2019 21:04, Christos Zoulas wrote:
> On Jun 1, 8:48pm, n...@gmx.com (Kamil Rytarowski) wrote:
> -- Subject: Re: CVS commit: src/external/gpl3/gcc/dist/libsanitizer/tsan
>
> | There is some overlap, but not full.
>
> I understand.
>
> | https://github.com/llvm
On Jun 1, 8:48pm, n...@gmx.com (Kamil Rytarowski) wrote:
-- Subject: Re: CVS commit: src/external/gpl3/gcc/dist/libsanitizer/tsan
| There is some overlap, but not full.
I understand.
| https://github.com/llvm-mirror/compiler-rt/blob/master/lib/tsan/rtl/tsan_rt=
| l_amd64.S
|
| Each call
On 01.06.2019 20:38, Christos Zoulas wrote:
> I just checked and the offsets are correct (we are the same as FreeBSD).
> We are missing support for the the names of the functions __setjmp14 etc.
>
> Thanks,
>
There is some overlap, but not full.
I just checked and the offsets are correct (we are the same as FreeBSD).
We are missing support for the the names of the functions __setjmp14 etc.
Thanks,
christos
> On Jun 1, 2019, at 1:52 PM, Kamil Rytarowski wrote:
>
> On 01.06.2019 19:22, Christos Zoulas wrote:
>> Module Name: src
>>
On 01.06.2019 19:22, Christos Zoulas wrote:
> Module Name: src
> Committed By: christos
> Date: Sat Jun 1 17:22:58 UTC 2019
>
> Modified Files:
> src/external/gpl3/gcc/dist/libsanitizer/tsan: tsan_rtl_amd64.S
>
> Log Message:
> Do as FreeBSD does now (I have not checked that the
"Maya Rashish" writes:
> Module Name: src
> Committed By: maya
> Date: Wed Apr 10 16:11:06 UTC 2019
>
> Modified Files:
> src/external/gpl3/gcc/dist/gcc/config: netbsd.h
>
> Log Message:
> remove bogus specs redefinition.
> fixes the use of -march=native
please revert this.
the
> UBSan can be combined with ASan and TSan.
>
> The way to go is to link UBSan into ASan/TSan/etc.
>
> I'm doing this in LLVM ones here:
> http://netbsd.org/~kamil/llvm/llvm-sanitizers-patch1.txt
>
> Additionally ASan should link LSan code.
>
> We apparently want more tests in ATF verifying
On 08.02.2019 23:06, matthew green wrote:
> Module Name: src
> Committed By: mrg
> Date: Fri Feb 8 22:06:12 UTC 2019
>
> Modified Files:
> src/external/gpl3/gcc/lib/libasan: Makefile
> src/external/gpl3/gcc/lib/libtsan: Makefile
> src/external/gpl3/gcc/lib/libubsan:
In article <20180715143153.gb28...@britannica.bec.de>,
Joerg Sonnenberger wrote:
>On Sat, Jul 14, 2018 at 07:41:43PM -0400, Christos Zoulas wrote:
>> Module Name: src
>> Committed By:christos
>> Date:Sat Jul 14 23:41:43 UTC 2018
>>
>> Modified Files:
>>
On Sat, Jul 14, 2018 at 07:41:43PM -0400, Christos Zoulas wrote:
> Module Name: src
> Committed By: christos
> Date: Sat Jul 14 23:41:43 UTC 2018
>
> Modified Files:
> src/external/gpl3/gcc/dist/libiberty: alloca.c
>
> Log Message:
> clang does not like auto in c++
This is not
On 05.02.2018 23:04, matthew green wrote:
> Module Name: src
> Committed By: mrg
> Date: Mon Feb 5 22:04:54 UTC 2018
>
> Modified Files:
> src/external/gpl3/gcc/dist/libsanitizer/sanitizer_common:
> sanitizer_linux.cc sanitizer_platform_limits_posix.cc
>
> Log Message:
> pull across from gcc.old:
> >https://bugzilla.eng.vmware.com/show_bug.cgi?id=1703878#c118
oops. fixed to read "ensure version.c gets rebuilt properly."
On Sep 22, 4:02pm, m...@eterna.com.au (matthew green) wrote:
-- Subject: re: CVS commit: src/external/gpl3/gcc/dist/libsanitizer/sanitizer
| sorry to bug you again, but... ;)
|
| > Modified Files:
| > src/external/gpl3/gcc/dist/libsanitizer/sanitizer_
sorry to bug you again, but... ;)
> Modified Files:
> src/external/gpl3/gcc/dist/libsanitizer/sanitizer_common:
> sanitizer_platform_limits_posix.h
>
> Log Message:
> Check the NetBSD version
! # ifdef __NetBSD__
hmmm, shouldn't that be SANITZIER_NETBSD or whatever it is?
"Christos Zoulas" writes:
> Module Name: src
> Committed By: christos
> Date: Wed Sep 21 19:18:01 UTC 2016
>
> Modified Files:
> src/external/gpl3/gcc/dist/libsanitizer/sanitizer_common:
> sanitizer_platform_limits_posix.h
>
> Log Message:
> add new field
+ #ifdef
On 2016/06/09 23:37, Christos Zoulas wrote:
Module Name:src
Committed By: christos
Date: Thu Jun 9 14:37:06 UTC 2016
Modified Files:
src/external/gpl3/gcc/dist/libsanitizer/sanitizer_common:
sanitizer_linux.cc sanitizer_syscall_generic.inc
Log Message:
Fix
On Wed, Mar 23, 2016 at 08:52:43AM -0400, Christos Zoulas wrote:
> 3) Removed definitions of EH_RETURN_STACKADJ_RTX and STARTING_FRAME_OFFSET
> from gcc/config/vax/elf.h. It's not necessary to remember the stack
> adjustment or to waste four bytes on every stack frame for a value
> that's not
"Christos Zoulas" writes:
> Module Name: src
> Committed By: christos
> Date: Thu Mar 17 00:56:05 UTC 2016
>
> Modified Files:
> src/external/gpl3/gcc/lib/libstdc++-v3/arch/x86_64: c++config.h
> src/external/gpl3/gcc/usr.bin/gcc/arch/x86_64: auto-host.h configargs.h
>
In article pine.neb.4.64.1405301548250.17...@screamer.whooppee.com,
Paul Goyette p...@whooppee.com wrote:
Joerg Sonnenberger writes:
IMO it is wrong to force every C++ program to link against
libpthread, which is not that cheap.
i'd buy that -- except that libstdc++ now references
Joerg Sonnenberger writes:
IMO it is wrong to force every C++ program to link against
libpthread, which is not that cheap.
i'd buy that -- except that libstdc++ now references
pthread_create() directly, and i don't know how to deal with that.
See how I did it for libc++? Make the
Paul Goyette writes:
Joerg Sonnenberger writes:
IMO it is wrong to force every C++ program to link against
libpthread, which is not that cheap.
i'd buy that -- except that libstdc++ now references
pthread_create() directly, and i don't know how to deal with that.
See how
On Wed, May 28, 2014 at 09:09:40AM +, Matthew Green wrote:
Module Name: src
Committed By: mrg
Date: Wed May 28 09:09:39 UTC 2014
Modified Files:
src/external/gpl3/gcc/lib/libstdc++-v3/arch/alpha: c++config.h config.h
[...]
On Wed, May 28, 2014 at 02:12:40PM +0100, Matthias Scheler wrote:
On Wed, May 28, 2014 at 09:09:40AM +, Matthew Green wrote:
Module Name:src
Committed By: mrg
Date: Wed May 28 09:09:39 UTC 2014
Modified Files:
On Wed, May 28, 2014 at 04:41:06PM +, matthew green wrote:
Module Name: src
Committed By: mrg
Date: Wed May 28 16:41:06 UTC 2014
Modified Files:
src/external/gpl3/gcc/lib/libstdc++-v3: Makefile
Log Message:
add -pthread to compiler/linker flags. fixes 1/3 of the link
Joerg Sonnenberger writes:
On Wed, May 28, 2014 at 04:41:06PM +, matthew green wrote:
Module Name:src
Committed By: mrg
Date: Wed May 28 16:41:06 UTC 2014
Modified Files:
src/external/gpl3/gcc/lib/libstdc++-v3: Makefile
Log Message:
add
On Thu, May 29, 2014 at 07:56:31AM +1000, matthew green wrote:
Joerg Sonnenberger writes:
On Wed, May 28, 2014 at 04:41:06PM +, matthew green wrote:
Module Name: src
Committed By: mrg
Date: Wed May 28 16:41:06 UTC 2014
Modified Files:
On 26.02.14 11:50, matthew green wrote:
Module Name: src
Committed By: mrg
Date: Wed Feb 26 10:50:23 UTC 2014
Added Files:
src/external/gpl3/gcc: gcc2gcc.old
Log Message:
script to copy gcc to gcc.old, ready for importing.
To generate a diff of this commit:
cvs
Christoph Egger christoph_eg...@gmx.de wrote
On 26.02.14 11:50, matthew green wrote:
+date=$(date +%Y%m%M-%H%M)
I think, it isn't necessary to invoke a subshell.
date=`date +%Y%m%M-%H%M` is enough.
date +%Y%m%d-%H%M ?
-- Takeshi Nakayama
On Wed, Feb 26, 2014 at 11:58:18AM +0100, Christoph Egger wrote:
+date=$(date +%Y%m%M-%H%M)
I think, it isn't necessary to invoke a subshell.
date=`date +%Y%m%M-%H%M` is enough.
Both forms involve a subshell, the only difference between $() and `` is
quoting.
Joerg
+date=$(date +%Y%m%M-%H%M)
I think, it isn't necessary to invoke a subshell.
date=`date +%Y%m%M-%H%M` is enough.
date +%Y%m%d-%H%M ?
ah, thanks.
On Mon, Dec 31, 2012 at 10:08:18AM +, David Laight wrote:
On Mon, Dec 31, 2012 at 03:00:42AM +0100, Joerg Sonnenberger wrote:
On Sun, Dec 30, 2012 at 08:16:59PM +, David Laight wrote:
Module Name: src
Committed By: dsl
Date: Sun Dec 30 20:16:59 UTC 2012
On Thu, Jan 03, 2013 at 03:46:08PM +0100, Joerg Sonnenberger wrote:
At least in terms of documentation, this is a regression. TARGET_64BIT
implies the presence of SSE support and that's somewhat independent of
the separate preferred stack boundary
Eh? TARGET_64BIT forces
On Mon, Dec 31, 2012 at 03:00:42AM +0100, Joerg Sonnenberger wrote:
On Sun, Dec 30, 2012 at 08:16:59PM +, David Laight wrote:
Module Name:src
Committed By: dsl
Date: Sun Dec 30 20:16:59 UTC 2012
Modified Files:
Module Name: src
Committed By: dsl
Date: Sun Dec 30 20:16:59 UTC 2012
Modified Files:
src/external/gpl3/gcc/dist/gcc/config/i386: i386.c
Log Message:
No need to check both TARGET_64BIT and ix86_preferred_stack_boundary = 64,
if the former is true the latter is also
On Tue, Jan 01, 2013 at 02:06:31AM +1100, matthew green wrote:
Module Name:src
Committed By: dsl
Date: Sun Dec 30 20:16:59 UTC 2012
Modified Files:
src/external/gpl3/gcc/dist/gcc/config/i386: i386.c
Log Message:
No need to check both
On Sun, Dec 30, 2012 at 08:16:59PM +, David Laight wrote:
Module Name: src
Committed By: dsl
Date: Sun Dec 30 20:16:59 UTC 2012
Modified Files:
src/external/gpl3/gcc/dist/gcc/config/i386: i386.c
Log Message:
No need to check both TARGET_64BIT and
On Sat, Oct 06, 2012 at 02:10:46PM +, Joerg Sonnenberger wrote:
Module Name: src
Committed By: joerg
Date: Sat Oct 6 14:10:46 UTC 2012
Modified Files:
src/external/gpl3/gcc/dist/gcc/config/i386: i386.h
Log Message:
PR 46978: ICE on spilling MMX registers
GCC/i386
(2012/09/16 16:26), SAITOH Masanobu wrote:
Module Name: src
Committed By: msaitoh
Date: Sun Sep 16 07:26:31 UTC 2012
Modified Files:
src/external/gpl3/gcc/dist/gcc: ChangeLog
src/external/gpl3/gcc/dist/gcc/config/arm: arm.md
Log Message:
Fix gcc bugid 51408 for
On Fri, Sep 14, 2012 at 01:00:01PM +, Joerg Sonnenberger wrote:
Module Name: src
Committed By: joerg
Date: Fri Sep 14 13:00:01 UTC 2012
Modified Files:
src/external/gpl3/gcc/dist/gcc/config/i386: i386.c netbsd-elf.h
netbsd64.h
Log Message:
Fix GCC to
Is someone working on submitting (the interesting ones of) these
upstream?
Now that the patches are fresh is probably the easiest time...
Thomas
On Tue, Jun 21, 2011 at 02:41:40AM +, matthew green wrote:
Module Name: src
Committed By: mrg
Date: Tue Jun 21 02:41:39 UTC 2011
79 matches
Mail list logo
