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
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 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 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 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 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: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 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 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 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: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: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
> 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
I ported the pass to the fsf trunk. It is built with —enable-checking.
The patch applied with no changes and also the behaviour is the same.
So I probably mess up the cfg somehow.
Can you suggest any strategy for finding the problem that I could use?
/home/bhuber/sandbox/fsf/install/bin/gcc -O3 -c
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,
On Wed, May 28, 2014 at 3:28 PM, Benedikt Huber
wrote:
> I ported the pass to the fsf trunk. It is built with —enable-checking.
> The patch applied with no changes and also the behaviour is the same.
> So I probably mess up the cfg somehow.
> Can you suggest any strategy for finding the problem th
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 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
Hi all,
The documentation for TARGET_MACRO_FUSION_PAIR says that it can be used
to tell the scheduler that two insns should not be scheduled apart. It
doesn't specify what kinds of insns those can be.
Yet from what I can see in sched-deps.c it can only be used on compares
and conditional bra
> 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/
> 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-
On Wed, 28 May 2014, Kyrill Tkachov wrote:
> Hi all,
>
> The documentation for TARGET_MACRO_FUSION_PAIR says that it can be used to
> tell the scheduler that two insns should not be scheduled apart. It doesn't
> specify what kinds of insns those can be.
>
> Yet from what I can see in sched-dep
On 28/05/14 17:36, Alexander Monakov wrote:
On Wed, 28 May 2014, Kyrill Tkachov wrote:
Hi all,
The documentation for TARGET_MACRO_FUSION_PAIR says that it can be used to
tell the scheduler that two insns should not be scheduled apart. It doesn't
specify what kinds of insns those can be.
Yet
Snapshot gcc-4.9-20140528 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.9-20140528/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.9 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
25 matches
Mail list logo
