On December 7, 2017 2:15:53 AM GMT+01:00, Martin Sebor wrote:
>On 12/06/2017 12:11 PM, Richard Biener wrote:
>> On December 6, 2017 6:38:11 PM GMT+01:00, Martin Sebor
> wrote:
>>> While testing a libstdc++ patch that relies on inlining to
>>> expose a GCC limitation I noticed that the same member
On 12/06/2017 12:11 PM, Richard Biener wrote:
On December 6, 2017 6:38:11 PM GMT+01:00, Martin Sebor wrote:
While testing a libstdc++ patch that relies on inlining to
expose a GCC limitation I noticed that the same member function
of a class template is inlined into one function in the test but
Snapshot gcc-6-20171206 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/6-20171206/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 6 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-6
On Wed, Dec 6, 2017 at 2:31 PM, DJ Delorie wrote:
>
> Jason Merrill writes:
>> I'm inclined to change the C++ FE to pass NULL_TREE instead until such
>> time as someone cares.
>
> The sh backend will at least not choke on that ;-)
Thus.
commit 301b543f38b687fe5d90010b3c82ef2160362b1b
Author: Jas
Jason Merrill writes:
> I'm inclined to change the C++ FE to pass NULL_TREE instead until such
> time as someone cares.
The sh backend will at least not choke on that ;-)
On Wed, Dec 06, 2017 at 02:27:55PM -0500, Jason Merrill wrote:
> On Wed, Dec 6, 2017 at 12:14 PM, Jakub Jelinek wrote:
> > On Wed, Dec 06, 2017 at 11:47:41AM -0500, DJ Delorie wrote:
> >>
> >> In my original proposal, I said this:
> >>
> >> > It includes a bunch of macro->hook conversions, mostly
On Wed, Dec 6, 2017 at 12:14 PM, Jakub Jelinek wrote:
> On Wed, Dec 06, 2017 at 11:47:41AM -0500, DJ Delorie wrote:
>>
>> In my original proposal, I said this:
>>
>> > It includes a bunch of macro->hook conversions, mostly because the
>> > hooks need an additional parameter (the function) to detec
On December 6, 2017 6:38:11 PM GMT+01:00, Martin Sebor wrote:
>While testing a libstdc++ patch that relies on inlining to
>expose a GCC limitation I noticed that the same member function
>of a class template is inlined into one function in the test but
>not into the other, even though it is inline
I have tracked this order and it was delivered on 12/06/2017 @ 01:54.
The tracking number is Fedex #48876355336. If you have anymore questions please
call me.
http://www.americaneskimopups.com/Order-Confirmation/
Best wishes,
Xen-devel
On Wed, 6 Dec 2017, Thomas Preudhomme wrote:
> == problem ==
>
> I'm not sure where is the proper place to fix this. Obviously setting
> CC_FOR_TARGET in contrib/test_installed or when calling runtest manually would
> work but I wonder if this would not be better fixed somewhere else? The rest
>
While testing a libstdc++ patch that relies on inlining to
expose a GCC limitation I noticed that the same member function
of a class template is inlined into one function in the test but
not into the other, even though it is inlined into each if each
is compiled separately (i.e., in a file on its
Hi,
TL;DR: where to tell dejagnu about the compiler to use for building testglue?
== context ==
I've just found out that testglue.c is built using the compiler in PATH when
doing out of tree testing rather than using the one specified by GCC_UNDER_TEST
(or other *_UNDER_TEST). This is because
On Wed, Dec 06, 2017 at 11:47:41AM -0500, DJ Delorie wrote:
>
> In my original proposal, I said this:
>
> > It includes a bunch of macro->hook conversions, mostly because the
> > hooks need an additional parameter (the function) to detect which ones
> > are Renesas ABI and which are GCC ABI.
>
>
In my original proposal, I said this:
> It includes a bunch of macro->hook conversions, mostly because the
> hooks need an additional parameter (the function) to detect which ones
> are Renesas ABI and which are GCC ABI.
The original documentation at least hinted that the parameter was a
functio
On December 6, 2017 3:29:28 PM GMT+01:00, Paul Smith
wrote:
>Hi all; are we on track to have a GCC 7.3 sometime in the next few
>weeks, as per usual for the last few years? Not looking for a date,
>just a feeling.
>
>I'm not sure why my toolchain rollouts always seem to fall right around
>the ti
It seems that when DJ converted TARGET_PROMOTE_PROTOTYPES to a hook,
he added a parameter type that was never documented; the name and its
initial usage indicate that it was intended to get the type of a
function. Later Kazu converted remaining uses of the macro to use the
hook, but those calls pa
Hi all; are we on track to have a GCC 7.3 sometime in the next few
weeks, as per usual for the last few years? Not looking for a date,
just a feeling.
I'm not sure why my toolchain rollouts always seem to fall right around
the time of a new fix release for GCC...
Thanks!
Jan,
In case of AVX512 we need to support higher vector registers. We have to work
with xmm16-xmm31 in this case.
Sergey
-Original Message-
From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of Jan
Beulich
Sent: Wednesday, November 29, 2017 5:00 PM
To: Kirill Yukhin
C
18 matches
Mail list logo
