We've had __has_final built-in for a good while.
the std library component is_final was added to C++14 - which is now good.
I noticed while looking at the latest SD-6 draft.
So here is a simple patch that builds and passes clean on x86_64-linux.
OK?
2014-09-14 Edward Smith-Rowland <3dw...@ver
Hi,
I get a lot of "vect/*" and "neon-*" test failure in my armv5te testing
because the arm_neon_ok test incorrectly detects that NEON is valid on
arm926ej-s.
It turns out that the reason is that the compiler only disallows NEON
for Thumb1 or soft-float configurations. Otherwise it just take
So, after a six-year break (was it so long?), I’m back among the maintainers.
Committed as rev. 215237
FX
2014-09-13 Francois-Xavier Coudert
* MAINTAINERS: Move myself to reviewers (Fortran).
Index: MAINTAINERS
===
> I don't think you need strdup here.
Updated version, bootstraps and regtests.
OK to commit?
gcc/ChangeLog:
* config/darwin-c.c (version_as_macro): Added extra 0 for OS X 10.10
and above
* config/darwin-driver.c (darwin_find_version_from_kernel): Removed
kernel version check to
FX writes:
> @@ -142,16 +140,16 @@ darwin_default_min_version (unsigned int
>
> #ifndef CROSS_DIRECTORY_STRUCTURE
>
> - /* Try to find the version from the kernel, if we fail - we print a message
> -and give up. */
> - if (!darwin_find_version_from_kernel (new_flag))
> - return;
> +
> In fact, after looking at the latest gcc-patches messages, I think it may be
> due to this commit: https://gcc.gnu.org/ml/gcc-patches/2014-09/msg01107.html
> (based purely on the fact that the unrecognized insn is a call, and the patch
> deals with CALL_EXPR).
Duh. No, it’s not, cause it’s app
In fact, after looking at the latest gcc-patches messages, I think it may be
due to this commit: https://gcc.gnu.org/ml/gcc-patches/2014-09/msg01107.html
(based purely on the fact that the unrecognized insn is a call, and the patch
deals with CALL_EXPR).
FX
> I am testing trunk on darwin14 (M
On 13 September 2014 02:04:51 Jakub Jelinek wrote:
On Fri, Sep 12, 2014 at 04:42:25PM -0700, Mike Stump wrote:
> curious, when I run atomic.exp=stdatom\*.c:
>
> gcc.dg/atomic/atomic.exp completed in 30 seconds.
>
> atomic.exp=c\*.c takes 522 seconds with 3, 2, 5 and 4 being the worst
offende
On 12 September 2014 19:46:33 Mike Stump wrote:
On Sep 12, 2014, at 9:32 AM, Jakub Jelinek wrote:
> Here is my latest version of the patch.
>
> With this patch I get identical test_summary output on make -k check
> (completely serial testing) and make -j48 -k check from toplevel directory.
>
>
> That should be allocated in darwin_find_version_from_kernel, using
> asprintf, and static doesn't make sense either.
Does this look sane? (I don’t often use asprintf, so I might have done
something stupid)
FX
darwin.diff
Description: Binary data
FX writes:
>> Index: gcc/config/darwin-driver.c
>> ===
>> --- gcc/config/darwin-driver.c (revision 215234)
>> +++ gcc/config/darwin-driver.c (working copy)
>> @@ -105,7 +103,7 @@ darwin_default_min_version (unsigned int
>
Hi James,
Thanks for the patch. I can confirm the reasoning, and that it allows the build
of trunk GCC to proceed where it previously failed. I had, in fact,
independently come up with a very similar patch on my own, before finding yours
online :(
The only suggestion which I might make is this
This patch fixes an obvious copy and paste declaration bug, introduced
on the 14th of August.
Committed as obvious as Rev. 215236 after building and regtesting.
Tobias
Index: gcc/fortran/ChangeLog
===
--- gcc/fortran/ChangeLog (Rev
On Fri, Sep 12, 2014 at 09:03:57PM -0400, Jason Merrill wrote:
> On 09/12/2014 04:52 PM, Marek Polacek wrote:
> >+protected_set_expr_location (postfix_expression, loc);
>
> Let's use the location of the (, which should just be token->location at
> this point. So column 17 instead of 13 in
14 matches
Mail list logo
