On Wed, May 28, 2014 at 12:03:39PM +0200, Richard Biener wrote:
> > Any other compilers that define __GNUC__?
>
> Every one I guess. ICC 9 has it defined to 4, __GNUC_MINOR__ to 0.
For ICC it seems to depend on the ICC version, newer ICC versions
report newer __GNUC_MINOR__.
That said, ICC doesn
On Wed, May 28, 2014 at 12:07:41PM +0200, Richard Biener wrote:
> >> #ifndef GCC_VERSION
> >> +/* Some compilers pretend to be GCC, even when they are not. */
> >> +#if defined(__clang__) || defined(__INTEL_COMPILER)
> >> +#define GCC_VERSION 0
> >> +#else
> >> #define GCC_VERSION (__GNUC__ * 10
On Wed, May 28, 2014 at 12:03 PM, Richard Biener
wrote:
> On Wed, May 28, 2014 at 11:48 AM, Jakub Jelinek wrote:
>> On Wed, May 28, 2014 at 11:38:55AM +0200, Richard Biener wrote:
>>> On Wed, May 28, 2014 at 10:24 AM, FX wrote:
>>> >> Yeah, a portable (C and C++) static assert would be nice. An
On Wed, May 28, 2014 at 11:48 AM, Jakub Jelinek wrote:
> On Wed, May 28, 2014 at 11:38:55AM +0200, Richard Biener wrote:
>> On Wed, May 28, 2014 at 10:24 AM, FX wrote:
>> >> Yeah, a portable (C and C++) static assert would be nice. And also
>> >> pushing
>> >> this to gmp then.
>> >>
>> >> In t
On Wed, May 28, 2014 at 11:38:55AM +0200, Richard Biener wrote:
> On Wed, May 28, 2014 at 10:24 AM, FX wrote:
> >> Yeah, a portable (C and C++) static assert would be nice. And also pushing
> >> this to gmp then.
> >>
> >> In the meantime I see nothing wrong in "merging" from GMP.
> >
> > One que
On Wed, May 28, 2014 at 10:24 AM, FX wrote:
>> Yeah, a portable (C and C++) static assert would be nice. And also pushing
>> this to gmp then.
>>
>> In the meantime I see nothing wrong in "merging" from GMP.
>
> One question, one comment:
>
> 1. can I count your “I see nothing wrong” as an approv
On Wed, May 28, 2014 at 8:50 AM, Jakub Jelinek wrote:
> On Mon, May 26, 2014 at 08:36:31AM -0700, Mike Stump wrote:
>> On May 26, 2014, at 2:22 AM, FX wrote:
>> >> This causes GCC bootstrap to fail on Darwin systems (whose system
>> >> compiler is clang-based). Since PR 61146 was resolved as INV
On Mon, May 26, 2014 at 08:36:31AM -0700, Mike Stump wrote:
> On May 26, 2014, at 2:22 AM, FX wrote:
> >> This causes GCC bootstrap to fail on Darwin systems (whose system compiler
> >> is clang-based). Since PR 61146 was resolved as INVALID (but I’m not sure
> >> it’s the right call, see below)
> Or, I can ask, any objections? In https://gcc.gnu.org/PR61146 it is stated
> that GMP removed the casts in 2005.
Among the many many versions of longlong.h that one can find around the web,
many have don’t have these casts, including GMP and coreutils
(http://code.metager.de/source/xref/gnu/
Ping?
Or, I can ask, any objections? In https://gcc.gnu.org/PR61146 it is stated
that GMP removed the casts in 2005.
On May 26, 2014, at 4:26 AM, FX wrote:
>> So changing just 2 of them doesn't feel right to me…
>
> [Again, with the patch actually attached… sorry]
>
> Here’s a patch that rem
On May 26, 2014, at 2:22 AM, FX wrote:
>> This causes GCC bootstrap to fail on Darwin systems (whose system compiler
>> is clang-based). Since PR 61146 was resolved as INVALID (but I’m not sure
>> it’s the right call, see below), I’ve filed a separate report for the
>> bootstrap issue (https://
On May 26, 2014, at 4:26 AM, FX wrote:
> Here’s a patch that removes all the casts on output operands in x86/x86_64
> code in longlong.h.
I’d love for someone to explain why the casts were there in the first place… I
like the idea of removing them.
> So changing just 2 of them doesn't feel right to me…
[Again, with the patch actually attached… sorry]
Here’s a patch that removes all the casts on output operands in x86/x86_64 code
in longlong.h. Again bootstrapped on x86_64-apple-darwin13, passing both stage1
(system compiler) and stages 2-
> So changing just 2 of them doesn't feel right to me…
Here’s a patch that removes all the casts on output operands in x86/x86_64 code
in longlong.h. Again bootstrapped on x86_64-apple-darwin13, passing both stage1
(system compiler) and stages 2-3 (gcc). OK to commit?
Other archs which have suc
On Mon, May 26, 2014 at 12:32:15PM +0200, FX wrote:
> > Please post a patch.
>
> How about that? I’m not doing a full clean-up of the longlong.h code
> outside the area affected. This restores bootstrap on darwin, confirming
> that both the system compiler and later-stage-gcc accepts it.
grep '"
> Please post a patch.
How about that? I’m not doing a full clean-up of the longlong.h code outside
the area affected. This restores bootstrap on darwin, confirming that both the
system compiler and later-stage-gcc accepts it.
FX
longlong.diff
Description: Binary data
longlong.ChangeLog
D
On Mon, May 26, 2014 at 1:14 AM, FX wrote:
>> > .././../gcc-4.10-20140518/gcc/wide-int.cc:1274:23: error: invalid use of a
>> > cast in a inline asm context requiring an l-value: remove the cast or
>> > build with -fheinous-gnu-extensions
>> > umul_ppmm (val[1], val[0], op1.ulow (), op2.
On Mon, May 26, 2014 at 10:14 AM, FX wrote:
>> > .././../gcc-4.10-20140518/gcc/wide-int.cc:1274:23: error: invalid use of a
>> > cast in a inline asm context requiring an l-value: remove the cast or
>> > build with -fheinous-gnu-extensions
>> > umul_ppmm (val[1], val[0], op1.ulow (), op2
On Mon, May 26, 2014 at 2:22 AM, FX wrote:
>> This causes GCC bootstrap to fail on Darwin systems (whose system compiler
>> is clang-based). Since PR 61146 was resolved as INVALID (but I’m not sure
>> it’s the right call, see below), I’ve filed a separate report for the
>> bootstrap issue (http
> This causes GCC bootstrap to fail on Darwin systems (whose system compiler is
> clang-based). Since PR 61146 was resolved as INVALID (but I’m not sure it’s
> the right call, see below), I’ve filed a separate report for the bootstrap
> issue (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61315).
> > .././../gcc-4.10-20140518/gcc/wide-int.cc:1274:23: error: invalid use of a
> > cast in a inline asm context requiring an l-value: remove the cast or
> > build with -fheinous-gnu-extensions
> > umul_ppmm (val[1], val[0], op1.ulow (), op2.ulow ());
> > ~~~^~~
Richard Sandiford writes:
> Gerald Pfeifer writes:
>> On Sat, 17 May 2014, Richard Sandiford wrote:
>>> To rule out one possibility: which GCC are you using for stage1?
>>
>> I think that may the smoking gun. When I use GCC 4.7 to bootstrap,
>> FreeBSD 8, 9 and 10 all build fine on i386 (= i486)
Gerald Pfeifer writes:
> On Sat, 17 May 2014, Richard Sandiford wrote:
>> To rule out one possibility: which GCC are you using for stage1?
>
> I think that may the smoking gun. When I use GCC 4.7 to bootstrap,
> FreeBSD 8, 9 and 10 all build fine on i386 (= i486) and amd64.
>
> When I use the sys
On Sat, 17 May 2014, Richard Sandiford wrote:
> To rule out one possibility: which GCC are you using for stage1?
I think that may the smoking gun. When I use GCC 4.7 to bootstrap,
FreeBSD 8, 9 and 10 all build fine on i386 (= i486) and amd64.
When I use the system compiler, which is GCC 4.2 on F
Gerald Pfeifer writes:
> On Sat, 10 May 2014, Gerald Pfeifer wrote:
>> Since (at least) 16:40 UTC that day my i386-unknown-freebsd10.0 builds
>> fail as follows:
>>
>> Comparing stages 2 and 3
>> warning: gcc/cc1obj-checksum.o differs
>> warning: gcc/cc1-checksum.o differs
>> warning: gcc
On Sat, 10 May 2014, Gerald Pfeifer wrote:
> Since (at least) 16:40 UTC that day my i386-unknown-freebsd10.0 builds
> fail as follows:
>
> Comparing stages 2 and 3
> warning: gcc/cc1obj-checksum.o differs
> warning: gcc/cc1-checksum.o differs
> warning: gcc/cc1plus-checksum.o differs
> B
On Tue, 6 May 2014, Mike Stump wrote:
> All done… It is in.
Since (at least) 16:40 UTC that day my i386-unknown-freebsd10.0 builds
fail as follows:
Comparing stages 2 and 3
warning: gcc/cc1obj-checksum.o differs
warning: gcc/cc1-checksum.o differs
warning: gcc/cc1plus-checksum.o differs
On Fri, 2014-05-09 at 00:48 +0200, Jan-Benedict Glaw wrote:
> [...]
>
> Just found this for iq2000:
>
> g++ -c -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -fno-exceptions
> -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing
> -Wwrite-strings -Wcast-qual -Wmissing-format-attribut
[...]
Just found this for iq2000:
g++ -c -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -fno-exceptions
-fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic
-Wno-long-long -Wno-variadic-macros -Wno
Jan-Benedict Glaw writes:
> On Tue, 2014-05-06 12:20:54 -0700, Mike Stump wrote:
>> On May 6, 2014, at 8:19 AM, Kenneth Zadeck wrote:
>> > please hold off on committing patches for the next couple of hours
>> > as we have a very large merge to do.
>> > thanks.
>>
>> All done… It is in.
>
> Jus
On 7 May 2014 09:48, Andreas Schwab wrote:
> Christophe Lyon writes:
>
>> It also looks like the git-svn-id property is now wrong/incomplete.
>> For instance, commit 9a5942c1d4d9116ab74b0741cfe3894a89fd17fb has:
>> git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/branches/wide-int@201706
>> 138bc75d
Christophe Lyon writes:
> It also looks like the git-svn-id property is now wrong/incomplete.
> For instance, commit 9a5942c1d4d9116ab74b0741cfe3894a89fd17fb has:
> git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/branches/wide-int@201706
> 138bc75d-0d04-0410-961f-82ee72b054a4
>
> How does it map to
On Tue, 2014-05-06 12:20:54 -0700, Mike Stump wrote:
> On May 6, 2014, at 8:19 AM, Kenneth Zadeck wrote:
> > please hold off on committing patches for the next couple of hours as we
> > have a very large merge to do.
> > thanks.
>
> All done… It is in.
Just found one more:
g++ -c -g -O2 -D
On May 6, 2014, at 3:54 PM, Mike Stump wrote:
>
>> My build robot experiences errors like this:
>>
>> g++ -c -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -fno-exceptions
>> -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing
>> -Wwrite-strings -Wcast-qual -Wmissing-format-attribu
On May 6, 2014, at 3:54 PM, Mike Stump wrote:
>
> I’m pretty sure this:
> will fix it. If someone can confirm that would be great.
I tried that on my p7 and on my x86_64 machines, they both build fine.
On Tue, 2014-05-06 15:54:05 -0700, Mike Stump wrote:
> On May 6, 2014, at 2:17 PM, Jan-Benedict Glaw wrote:
> > On Tue, 2014-05-06 12:20:54 -0700, Mike Stump wrote:
> > > On May 6, 2014, at 8:19 AM, Kenneth Zadeck
> > > wrote:
> > > > please hold off on committing patches for the next couple o
I have noticed build failures too (arm, aarch64).
It also looks like the git-svn-id property is now wrong/incomplete.
For instance, commit 9a5942c1d4d9116ab74b0741cfe3894a89fd17fb has:
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/branches/wide-int@201706
138bc75d-0d04-0410-961f-82ee72b054a4
How
On May 6, 2014, at 2:17 PM, Jan-Benedict Glaw wrote:
> On Tue, 2014-05-06 12:20:54 -0700, Mike Stump wrote:
>> On May 6, 2014, at 8:19 AM, Kenneth Zadeck wrote:
>>> please hold off on committing patches for the next couple of hours as we
>>> have a very large merge to do.
>>> thanks.
>>
>> All
On Tue, 2014-05-06 12:20:54 -0700, Mike Stump wrote:
> On May 6, 2014, at 8:19 AM, Kenneth Zadeck wrote:
> > please hold off on committing patches for the next couple of hours as we
> > have a very large merge to do.
> > thanks.
>
> All done… It is in.
My build robot experiences errors like t
On May 6, 2014, at 8:19 AM, Kenneth Zadeck wrote:
> please hold off on committing patches for the next couple of hours as we have
> a very large merge to do.
> thanks.
All done… It is in.
please hold off on committing patches for the next couple of hours as we
have a very large merge to do.
thanks.
kenny
41 matches
Mail list logo
