> After lengthy IRC discussions, what Richard and I can live with is
> && !defined(__clang__) in this particular case that uses longlong.h
> in GCC sources, with a comment why.
> If we get too many of these workarounds, we should reconsider.
Committed as revision 211023, after bootstrap on x86_64-
> I suppose casting the result of CWI_ELT () to uint64_t fixes this. Do
> similar errors happen elsewhere?
I don’t think you can cast to uint64_t, as host wide int might be some other
type, no?
There are others:
../../trunk/gcc/print-rtl.c: In function ‘void print_rtx(const_rtx)’:
../../trunk/
On Wed, May 28, 2014 at 04:00:32PM +0200, Jakub Jelinek wrote:
> Defining HOST_WIDE_INT to long long or long based on whether long is 64-bit
> or not, but using PRIx64 etc. unconditionally is just wrong, either
> HOST_WIDE_INT should be uint64_t and then you should use PRI*64, or it is
> not, and t
On Wed, May 28, 2014 at 03:47:52PM +0200, Richard Biener wrote:
> On Wed, May 28, 2014 at 3:15 PM, FX wrote:
> >> After lengthy IRC discussions, what Richard and I can live with is
> >> && !defined(__clang__) in this particular case that uses longlong.h
> >> in GCC sources, with a comment why.
> >
On Wed, May 28, 2014 at 3:15 PM, FX wrote:
>> After lengthy IRC discussions, what Richard and I can live with is
>> && !defined(__clang__) in this particular case that uses longlong.h
>> in GCC sources, with a comment why.
>
> I’ll test this patch and commit if there is no problem. But right now,
> After lengthy IRC discussions, what Richard and I can live with is
> && !defined(__clang__) in this particular case that uses longlong.h
> in GCC sources, with a comment why.
I’ll test this patch and commit if there is no problem. But right now, current
trunk doesn’t build on x86_64-apple-darwi
On Wed, May 28, 2014 at 12:18:13PM +0200, Richard Biener wrote:
> > ATM we get the testing coverage for i686 and ppc32 hosts. So TBH I'd
> > prefer to keep it simple and just bump the version number.
>
> Works for me (though see Jakubs idea on the other thread, so please
> wait until we settled o
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 11:49 AM, Richard Sandiford
wrote:
> Richard Biener writes:
>> On Wed, May 28, 2014 at 11:40 AM, Richard Biener
>> wrote:
>>> On Wed, May 28, 2014 at 10:24 AM, Richard Sandiford
>>> wrote:
Richard Biener writes:
> On Wed, May 28, 2014 at 8:50 AM, Jakub Jelinek
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
Richard Biener writes:
> On Wed, May 28, 2014 at 11:40 AM, Richard Biener
> wrote:
>> On Wed, May 28, 2014 at 10:24 AM, Richard Sandiford
>> wrote:
>>> Richard Biener writes:
On Wed, May 28, 2014 at 8:50 AM, Jakub Jelinek wrote:
> On Mon, May 26, 2014 at 08:36:31AM -0700, Mike Stump w
On Wed, May 28, 2014 at 11:40 AM, Richard Biener
wrote:
> On Wed, May 28, 2014 at 10:24 AM, Richard Sandiford
> wrote:
>> Richard Biener writes:
>>> 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
On Wed, May 28, 2014 at 10:24 AM, Richard Sandiford
wrote:
> Richard Biener writes:
>> 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 D
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
Richard Biener writes:
> 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
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 ());
> > ~~~^~~
33 matches
Mail list logo
