On 2025-02-24 10:28 pm, matthew green wrote:
"Christos Zoulas" writes:
Module Name:src
Committed By: christos
Date: Sun Feb 23 15:33:49 UTC 2025
Modified Files:
src/external/gpl3/gcc/dist/gcc/config/i386: avx2intrin.h
Log Message:
Pr/59093: Onno van der Linden: Elide ca
"Christos Zoulas" writes:
> Module Name: src
> Committed By: christos
> Date: Sun Feb 23 15:33:49 UTC 2025
>
> Modified Files:
> src/external/gpl3/gcc/dist/gcc/config/i386: avx2intrin.h
>
> Log Message:
> Pr/59093: Onno van der Linden: Elide cast-qual gcc warning
for dist code i rea
"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 macO
> 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:
>> cl
"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 replace
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
>> +++ src/external/gpl3/gcc/usr.bin/cc1plus/Ma
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 ${MACHINE
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 i
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 t
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 o
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 sys
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 th
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 wor
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 i
"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 revert
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 Fri
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 Rytarows
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 unimpl
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 plac
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 m
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
> _lwp_getprivate_f
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:
>> sanit
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
src/external/gpl3/gcc/li
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 th
> 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 s
> 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 relea
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 thi
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 o
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 Files
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 M
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 Mes
"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
> src/external/gpl3/gcc/dist/l
"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. thi
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 (memory_addr
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
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 done and
all the archs
are building, I w
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
> of
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 of
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.
https://github.com/llvm-mirror/compiler-rt/blob/m
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
>> Commi
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 o
"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 r
> 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 *Sa
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: Mak
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:
>> src/external/
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 abo
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
> src/externa
> 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 __NetB
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 s
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 neede
"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
> sr
> I am planning to sync them with our sources again anyway... When are you
> going to import gcc-5?
i was hoping to this week! still have a few days ... ;)
On Jan 20, 5:29pm, m...@eterna.com.au (matthew green) wrote:
-- Subject: re: CVS commit: src/external/gpl3/gcc/dist/gcc
| "Christos Zoulas" writes:
| > Module Name:src
| > Committed By: christos
| > Date: Sat Jan 16 19:28:36 UTC 2016
| &g
"Christos Zoulas" writes:
> Module Name: src
> Committed By: christos
> Date: Sat Jan 16 19:28:36 UTC 2016
>
> Modified Files:
> src/external/gpl3/gcc/dist/gcc: regsub.c
>
> Log Message:
> ifdef __RCSID
please just remove these -- they won't be useful when pushed
upstream.
.mrg.
In article ,
Paul Goyette 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
>> > pthread_create() directly, and i don't know how to de
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 wit
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 r
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:
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 Me
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
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:
> > src/external/gpl3/gcc/lib/
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
[...]
> src/external/gpl3/gcc/usr.bin/gcc/ar
> > > +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 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
>>> Christoph Egger 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 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
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_64
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 U
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 che
> 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
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:
> > src/external/gpl3/gcc/dis
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 ix86_preferre
> Module Name: src
> Committed By: christos
> Date: Sat Dec 8 02:35:06 UTC 2012
>
> Modified Files:
> src/external/gpl3/gcc/lib/libgcc/libgcov: Makefile
>
> Log Message:
> XXX: Use earm for earmeb
what's this about? please don't do this. if you want an earmeb
configuration, pl
On Mon, Oct 08, 2012 at 08:12:26AM +0100, David Laight wrote:
> 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/d
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
>
>
(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 5140
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
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
>
87 matches
Mail list logo