Re: Always pass 0 or option number to gfc_warning*

Joseph Myers wrote: Similar to the issue with fatal_error that I fixed in , the overloads of gfc_warning and gfc_warning_now (with and without a first argument for an option number) also break gcc.pot regeneration because xgettext expects

[PATCH v2] libgcc: Use braces instead of macro's empty body to avoid xgcc warnings.

The related warning (cross compile tile with --disable-threads): ../../../../gcc-tile-new/libgcc/libgcov-interface.c: In function '__gcov_fork': ../../../../gcc-tile-new/libgcc/libgcov-interface.c:182:53: warning: suggest braces around empty body in an 'if' statement [-Wempty-body] __

Re: [PATCH] libgcc: Use braces instead of macro's empty body to avoid xgcc warnings.

On 1/31/15 06:57, Jakub Jelinek wrote: > On Sat, Jan 31, 2015 at 06:37:30AM +0800, Chen Gang S wrote: >> The related warning (cross compile tile with --disable-threads): >> >> ../../../../gcc-tile-new/libgcc/libgcov-interface.c: In function >> '__gcov_fork': >> ../../../../gcc-tile-new/libgcc

Re: [PATCH] Fix scheduling undeterminism from sorting with DEBUG_INSNs

On 01/22/15 12:01, Maxim Kuvyrkov wrote: On Jan 22, 2015, at 8:11 PM, Jeff Law wrote: On 01/19/15 06:07, Maxim Kuvyrkov wrote: The underlying problem is that the order in which elements of ready_list are compared matters to the final result. This is because rank_for_schedule sorting heurist

[RFC][PR target/39726 P4 regression] match.pd pattern to do type narrowing

So I've gone round and round with BZ39726. The basic idea here is we have an operation on widened operands that feeds a narrow comparison. ie, the two inputs are QImode, extended to SImode, subtracted, then we want to conditionally branch on the result of sign bit of QImode. If we could ju

Re: lra incorrectly reloading scratch for a memory barrier?

On Fri, Jan 30, 2015 at 12:50:01PM -0800, Richard Henderson wrote: > >> Jakub, the current formation includes both a use and a set of all > >> memory. Your > >> clobber form would not imply a use. > > > > What do you need the use for? Prevent all DSE before the barrier for some > > weird reason?

Re: [PATCH, c] PR c/48956: diagnostics for conversions involving complex types

On Fri, Jan 30, 2015 at 08:33:43AM -0800, Mike Stump wrote: > Ah, I kinda discounted that as it went by it seems. It seems most other > players go the other way, as the numbers get large, the first one fixes, and > then they add numbers at the bottom. Thanks. The GCC release "series" is now a

Go patch committed: treat map index expressions as lvalues in range expressions

This patch by Chris Manghane fixes a bug in the gofrontend in which map index expressions were not treated as lvalues in range expressions. That is, for m[0] = range s did not work. This was Go issue 9695. Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu. Committed to mainline.

Re: [debug-early] C++ clones and limbo DIEs

On 01/30/2015 02:04 PM, Jason Merrill wrote: On 01/30/2015 03:36 PM, Aldy Hernandez wrote: /* It is possible to have both DECL_ABSTRACT_P and DECLARATION be true if we started to generate the abstract instance of an inline, decided to output its containing class, and proceeded to emi

[PATCH] pr 61548 - tree-emutls needs to resolve the aliases it creates

From: Trevor Saunders Hi, tree-emutls wasn't resolvingthe aliases it created which meant that the varpool node's ref_list said it didn't refer to anything which caused get_alias_target to crash. Then varpool_node::remove called varpool_node::ctor_useful_for_folding_p which expects it can get t

Re: [PATCH, c] PR c/48956: diagnostics for conversions involving complex types

On Jan 30, 2015, at 12:36 PM, Richard Biener wrote: >> Ah, I kinda discounted that as it went by it seems. It seems most >> other players go the other way, as the numbers get large, the first one >> fixes, and then they add numbers at the bottom. Thanks. > > You obviously missed the Marketing 1

Re: [PATCH] libgcc: Use braces instead of macro's empty body to avoid xgcc warnings.

On Sat, Jan 31, 2015 at 06:37:30AM +0800, Chen Gang S wrote: > The related warning (cross compile tile with --disable-threads): > > ../../../../gcc-tile-new/libgcc/libgcov-interface.c: In function > '__gcov_fork': > ../../../../gcc-tile-new/libgcc/libgcov-interface.c:182:53: warning: > sugge

[PATCH] libgcc: Use braces instead of macro's empty body to avoid xgcc warnings.

The related warning (cross compile tile with --disable-threads): ../../../../gcc-tile-new/libgcc/libgcov-interface.c: In function '__gcov_fork': ../../../../gcc-tile-new/libgcc/libgcov-interface.c:182:53: warning: suggest braces around empty body in an 'if' statement [-Wempty-body] __

patch to fix PR 64688

The patch in the attachment solves https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64688 The patch was bootstrapped and tested on x86-64 and ppc64. Committed as rev.220297. 2015-01-30 Vladimir Makarov PR target/64688 * lra-constraints.c (original_subreg_reg_mode): New.

[PATCH, CHKP] Follow alias chain for decl visibility and aliases

Hi, This patch fixes two more cases where alias chain should be followed to emit correct assembler name for instrumented functions. Bootstrapped and tested on x86_64-unknown-linux-gnu. OK for trunk? Thanks, Ilya -- gcc/ 2015-01-30 Ilya Enkovich * varasm.c (do_assemble_alias): Fol

Always pass 0 or option number to gfc_warning*

Similar to the issue with fatal_error that I fixed in , the overloads of gfc_warning and gfc_warning_now (with and without a first argument for an option number) also break gcc.pot regeneration because xgettext expects the translated string

Re: [C++ PATCH, RFC] PR c++/63959, continued

On 30 January 2015 at 23:06, Ville Voutilainen wrote: > Let's drop libstdc++, this discussion is about a test that doesn't > really concern them. > > On 30 January 2015 at 22:51, Jason Merrill wrote: >> The patch changes all the static_assert strings to "", which is not very >> useful; let's keep

Re: #pragma GCC unroll support

On January 30, 2015 5:36:16 PM GMT+01:00, Marek Polacek wrote: >On Fri, Jan 30, 2015 at 08:27:06AM -0800, Mike Stump wrote: >> > >> +static bool >> +c_parse_pragma_ivdep (c_parser *parser) >> +{ >> + c_parser_consume_pragma (parser); >> + c_parser_skip_to_pragma_eol (parser); >> + return tru

Re: lra incorrectly reloading scratch for a memory barrier?

On January 30, 2015 9:18:57 PM CET, Richard Henderson wrote: >On 01/30/2015 12:12 PM, Mike Stump wrote: >> On Jan 30, 2015, at 9:52 AM, Jakub Jelinek wrote: >>> On Fri, Jan 30, 2015 at 09:45:26AM -0800, Mike Stump wrote: I have a port that has: (insn 47 46 48 18 (parallel [

Re: lra incorrectly reloading scratch for a memory barrier?

On 01/30/2015 12:40 PM, Richard Biener wrote: > On January 30, 2015 9:18:57 PM CET, Richard Henderson wrote: >> On 01/30/2015 12:12 PM, Mike Stump wrote: >>> On Jan 30, 2015, at 9:52 AM, Jakub Jelinek wrote: On Fri, Jan 30, 2015 at 09:45:26AM -0800, Mike Stump wrote: > I have a port that

Re: [C++ PATCH, RFC] PR c++/63959, continued

On 01/30/2015 03:05 PM, Ville Voutilainen wrote: -#define TRY(expr) static_assert (expr, #expr) The patch changes all the static_assert strings to "", which is not very useful; let's keep the macro. Jason

Re: [debug-early] C++ clones and limbo DIEs

On 01/30/2015 03:36 PM, Aldy Hernandez wrote: /* It is possible to have both DECL_ABSTRACT_P and DECLARATION be true if we started to generate the abstract instance of an inline, decided to output its containing class, and proceeded to emit the declaration of the inline from the

Re: [PATCH 1/3] PR jit/64810: driver, arm, jit: configure-time default options

On Fri, 30 Jan 2015, David Malcolm wrote: > gcc/ChangeLog: > PR jit/64810 > * Makefile.in (GCC_OBJS): Add gcc-main.o. > * gcc-main.c: New file, containing "main" taken from gcc.c. > * gcc.c (do_self_spec): Free decoded_options. > (class driver): Move declaration to gc

Re: [C++ PATCH, RFC] PR c++/63959, continued

Let's drop libstdc++, this discussion is about a test that doesn't really concern them. On 30 January 2015 at 22:51, Jason Merrill wrote: > The patch changes all the static_assert strings to "", which is not very > useful; let's keep the macro. Ok. How about this one? It reuses the macro and ke

Re: #pragma GCC unroll support

On Jan 30, 2015, at 12:52 PM, Bernhard Reutner-Fischer wrote: > This last test is still puzzling me. As it is to me. The reason it seems like they were going for in the code was due to wrapping, but wrapping should only happen at something relating to the bit size of the induction variable.

Re: [debug-early] C++ clones and limbo DIEs

On 01/28/2015 10:51 AM, Jason Merrill wrote: On 01/28/2015 01:29 PM, Aldy Hernandez wrote: + /* It is rather unfortunate that Cilk creates trees this late + (during gimplification). However, until this gets fixed, + specially handle emitting DWARF for this new function and + immediately clean

Re: [PATCH, c] PR c/48956: diagnostics for conversions involving complex types

On January 30, 2015 5:33:43 PM CET, Mike Stump wrote: >On Jan 29, 2015, at 7:16 PM, Andrew Pinski wrote: >> On Thu, Jan 29, 2015 at 6:58 PM, Mike Stump >wrote: >>> On Jan 29, 2015, at 4:15 PM, Joseph Myers >wrote: The patch is OK for GCC 6 >>> >>> We will be releasing 5.x compilers for th

Re: lra incorrectly reloading scratch for a memory barrier?

On January 30, 2015 9:12:12 PM CET, Mike Stump wrote: >On Jan 30, 2015, at 9:52 AM, Jakub Jelinek wrote: >> On Fri, Jan 30, 2015 at 09:45:26AM -0800, Mike Stump wrote: >>> I have a port that has: >>> >>> (insn 47 46 48 18 (parallel [ >>>(unspec_volatile:DI [ >>>(c

Re: lra incorrectly reloading scratch for a memory barrier?

On 01/30/2015 12:12 PM, Mike Stump wrote: > On Jan 30, 2015, at 9:52 AM, Jakub Jelinek wrote: >> On Fri, Jan 30, 2015 at 09:45:26AM -0800, Mike Stump wrote: >>> I have a port that has: >>> >>> (insn 47 46 48 18 (parallel [ >>>(unspec_volatile:DI [ >>>(const_int 128

Re: lra incorrectly reloading scratch for a memory barrier?

On Jan 30, 2015, at 9:52 AM, Jakub Jelinek wrote: > On Fri, Jan 30, 2015 at 09:45:26AM -0800, Mike Stump wrote: >> I have a port that has: >> >> (insn 47 46 48 18 (parallel [ >>(unspec_volatile:DI [ >>(const_int 128 [0x80]) >>(const_int 6 [0x6])

Re: [C++ PATCH, RFC] PR c++/63959, continued

On 30 January 2015 at 21:59, Ville Voutilainen wrote: > So, a new patch attached. The only change to the previous one is the change > to the trivial1.C test. Oops. The No-template was borken and there was remnants of the macros in commented code. Let's try that again, shall we? :) Attached. diff

Re: [C++ PATCH, RFC] PR c++/63959, continued

On 30 January 2015 at 20:25, Jason Merrill wrote: > On 01/30/2015 01:13 PM, Ville Voutilainen wrote: >>> >>> Why would void *const volatile still be trivial? >> >> >> Ah. It isn't. YES and YES2 are macros, so YES2(void*) expands to >> is_trivial::value, which is true, whereas >> is_trivial

[PATCH, i386 testsuite]: Require nonpic target for some tests

Hello! Attached patch adds nonpic target requirement for some (obvious) cases, where data access or PIC register setup confuses scan-asms. 2015-01-30 Uros Bizjak * gcc.target/i386/fuse-caller-save-rec.c: Require nonpic target. * gcc.target/i386/fuse-caller-save-xmm.c: Ditto. * gcc

Re: [PATCH][PR target/15184] Fix for direct byte access on x86

On 01/30/15 03:07, Uros Bizjak wrote: On Fri, Jan 30, 2015 at 7:12 AM, Jeff Law wrote: Hello! So here's the updated patch which handles all 4 testcases from the PR as well as a couple of my own. @@ -0,0 +1,33 @@ +/* PR 15184 first two tests, plus two addition ones. */ +/* { dg-do compile

Re: [PATCH][PR target/15184] Fix for direct byte access on x86

On 01/30/15 03:24, Jakub Jelinek wrote: On Fri, Jan 30, 2015 at 11:23:38AM +0100, Uros Bizjak wrote: On Fri, Jan 30, 2015 at 11:13 AM, Jakub Jelinek wrote: /* Each function should compile down to a byte move from the input register into x, possibly at an offset within x. */ -/* { dg-f

Re: [testsuite] Run guality tests on Solaris

On 01/30/15 01:19, Jakub Jelinek wrote: The biggest problem is that what fails and what does not varries between targets and between optimization levels. Right now we have no way to xfail test XYZ for -Os on x86_64-linux and for -O2 and -O3 on i686-linux ia32, and the lists would become very la

Re: [debug-early] remove file_table_last_lookup

On 01/30/2015 11:01 AM, Aldy Hernandez wrote: We haven't been using this for a looong time. It never even gets defined. Removed and committed to branch. Aldy Ughh, I'm having git rebase issues. I was missing part of the patch. Here's the rest. Committed to branch. Aldy diff --git a/gcc/

Re: [PATCH] Change __ARM_NEON__ to __ARM_NEON in libcpp/lex.c

On 01/30/2015 04:52 AM, Szabolcs Nagy wrote: > When running natively on AArch64 the preprocessor did not use the > AdvSIMD optimized search_line_fast function, because it was ifdefed > around by __ARM_NEON__ instead of __ARM_NEON. Yes, sorry I didn't follow up on that from September: https://gc

Re: [PATCH] Break too deep TER chains for debug stmts during expansion (PR debug/64817)

On 01/30/2015 09:47 AM, Jakub Jelinek wrote: > +hash_map *deep_ter_debug_map; Any reason this data can't be static? Otherwise, ok. r~

[debug-early] remove file_table_last_lookup

We haven't been using this for a looong time. It never even gets defined. Removed and committed to branch. Aldy commit a8076b015cad17538e369c153f8c7cf888433840 Author: Aldy Hernandez Date: Tue Jan 27 11:24:53 2015 -0800 * dwarf2out.c (file_table_last_lookup): Remove unset variable.

[PATCH] doc/invoke.texi: clarify default setting of VTA

Hello, Recently on gcc-help@ one of the users asked whether they need to set -fvar-tracking-assignments on the command line by hand. The documentation may be clearer in that this flag has a useful value by default, like -fvar-tracking (i.e. GCC's behavior is to take the value of flag_var_tracking

Re: [C++ PATCH, RFC] PR c++/63959, continued

On 01/30/2015 01:13 PM, Ville Voutilainen wrote: Why would void *const volatile still be trivial? Ah. It isn't. YES and YES2 are macros, so YES2(void*) expands to is_trivial::value, which is true, whereas is_trivial::value is false. I think it would be reasonable to convert these macro

Re: [C++ PATCH, RFC] PR c++/63959, continued

On 30 January 2015 at 19:46, Jason Merrill wrote: > On 01/20/2015 09:27 AM, Ville Voutilainen wrote: >> >> +#define YES2(type) TRY(std::is_trivial::value); \ >> + TRY(std::is_trivial::value); \ >> TRY(std::is_trivial::value) > > >> +YES2(void *); >> +YES2(int A::*); > > > Why would void *cons

Re: [fixincludes] Fix signbit on Solaris

On 01/29/15 05:38, Rainer Orth wrote: So I saw. If all else fails, we can still commit the (ugly/hard to read) initial version, otherwise libgo won't build on Solaris before some (quite recent) Solaris 11.2 patch, breaking bootstrap. Having it work at all seems like a nice feature. I think tha

Re: [PATCH, libcpp] Do not modify a token once it has been initialized

OK. Jason

Re: lra incorrectly reloading scratch for a memory barrier?

On Fri, Jan 30, 2015 at 09:45:26AM -0800, Mike Stump wrote: > I have a port that has: > > (insn 47 46 48 18 (parallel [ > (unspec_volatile:DI [ > (const_int 128 [0x80]) > (const_int 6 [0x6]) > ] UNSPECV_SPECIAL_OP) > (

patch to fix PR64617

The following patch fixes https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64617 The patch was bootstrapped and tested on x86-64 and ppc64. Committed as rev.220294. 2015-01-30 Vladimir Makarov PR target/64617 * lra-constraints.c (prohibited_class_reg_set_mode_p): New functi

[PATCH] Break too deep TER chains for debug stmts during expansion (PR debug/64817)

Hi! As the following two testcases show, while we have avoid_complex_debug_insns that decreases debug insn complexity after expansion is done, there is a problem during expansion if the TER chains are too deep, because simplify-rtx.c in some cases is inherently quadratic - does not like arbitraril

Re: [C++ PATCH, RFC] PR c++/63959, continued

On 01/20/2015 09:27 AM, Ville Voutilainen wrote: +#define YES2(type) TRY(std::is_trivial::value); \ + TRY(std::is_trivial::value); \ TRY(std::is_trivial::value) +YES2(void *); +YES2(int A::*); Why would void *const volatile still be trivial? Jason

lra incorrectly reloading scratch for a memory barrier?

I have a port that has: (insn 47 46 48 18 (parallel [ (unspec_volatile:DI [ (const_int 128 [0x80]) (const_int 6 [0x6]) ] UNSPECV_SPECIAL_OP) (set (mem/v:BLK (scratch:DI) [0 A8]) (unspec:BLK [

Re: [Ada] Fix bootstrapping on darwin9/10 (PR ada/64349)

Hi Tristan, On 30 Jan 2015, at 15:13, Arnaud Charlet wrote: > Avoid possible warning on darwin during compiler build. it's not "just a warning" it's a documented incorrect usage which causes a link error (and thus bootstrap fail) on systems that are not using the catch-all "-Wl, -undefined, dy

Re: #pragma GCC unroll support

On Fri, Jan 30, 2015 at 08:27:06AM -0800, Mike Stump wrote: >  > +static bool > +c_parse_pragma_ivdep (c_parser *parser) > +{ > + c_parser_consume_pragma (parser); > + c_parser_skip_to_pragma_eol (parser); > + return true; > +} > + > +static unsigned short > +c_parser_pragma_unroll (c_parser *

Re: [PATCH, c] PR c/48956: diagnostics for conversions involving complex types

On Jan 29, 2015, at 7:16 PM, Andrew Pinski wrote: > On Thu, Jan 29, 2015 at 6:58 PM, Mike Stump wrote: >> On Jan 29, 2015, at 4:15 PM, Joseph Myers wrote: >>> The patch is OK for GCC 6 >> >> We will be releasing 5.x compilers for the next decade?! Does he really >> have to wait 10 years? >>

Re: #pragma GCC unroll support

On Jan 30, 2015, at 7:49 AM, Joseph Myers wrote: > Use error_at, and %u directly in the format. Done. Index: ada/gcc-interface/trans.c === --- ada/gcc-interface/trans.c (revision 220084) +++ ada/gcc-interface/trans.c (working co

Re: Always pass explicit location to fatal_error

On Fri, Jan 30, 2015 at 12:52 AM, Joseph Myers wrote: > > Ian: this patch does *not* change go/gofrontend/go.cc; you'll need to > update that (such an update is of course best done before this patch > goes in; since the overload currently exists, updating it does not > depend on this patch). I th

Re: Go patch committed: Fix -fgo-prefix handling

This is the followup patch. This adds more information to the package when any imported packages have a pkgpath symbol that is not the obvious transformation of the pkgpath. This is enough to determine the right symbol name to use in all cases. Bootstrapped and ran Go testsuite on x86_64-unknown

Re: [PATCH, c] PR c/48956: diagnostics for conversions involving complex types

On Fri, 30 Jan 2015, Mikhail Maltsev wrote: > On Fri, 30 Jan 2015 00:15:02 + > Joseph Myers wrote: > > > > +#if 0 > > > + /* Check needs to be implemented. */ > > > + fuic (-1. + 0.i); > > > + vuic = -1. + 0.i; > > > +#endif > > > > The #if 0 cases should have a bug filed in Bugzilla to

Re: #pragma GCC unroll support

On Thu, 29 Jan 2015, Mike Stump wrote: > @@ -5587,6 +5600,12 @@ c_parser_for_statement (c_parser *parser > "% pragma"); > cond = error_mark_node; > } > + else if (unroll) > + { > + c_parser_error (par

[Ada] Obscure ambiguity involving user-defined operators returning Boolean

This patch fixes a rather obscure bug in case there is a user-defined "+" operator returning Boolean, passed to two contexts where the expected type is Boolean, and the expected type is the result of the PREdefined operator. This is ambiguous, and therefore illegal. gnatmake -q -f cutdown1-main.ad

[Ada] Suppress Import-In-Pure-Unit warning if Pure_Function given

The warning for use of Import in a Pure unit is refined so that it is omitted if an explicit Pure_Function aspect is given, as shown by the following test, compiled with -gnatl 1. package PureImportF is 2. pragma Pure (PureImportF); 3.function F (A : integer) return integer;

[Ada] Fix bootstrapping on darwin9/10 (PR ada/64349)

Avoid possible warning on darwin during compiler build. Should hopefully close PR 64349, committed on trunk 2015-01-30 Tristan Gingold PR ada/64349 * env.c: Move vxworks and darwin includes out of #ifdef IN_RTS. Index: env.c ===

Re: [PATCH] Fix PR64829

On 30/01/15 09:20, Richard Biener wrote: On Thu, 29 Jan 2015, Jiong Wang wrote: 2015-01-29 14:27 GMT+00:00 Kyrill Tkachov : On 29/01/15 12:44, Richard Biener wrote: Can you test? two issues during bootstrapping the patch on arm board on top of r220249 * one warning treated as error.

[Ada] Improve error message of interface primitive overriding

This patch improves the text of the error reported for RM 9.4(11.9). This new output is visible using this small reproducer: procedure by30018 is package pack is type Iface is synchronized interface; procedure Prim1_1 (M : in Iface) is abstract; protected type T_PO is new If

[Ada] Improve message for condition always False (simple variable case)

The warning message for an always True condition special cased the simple variable case. This special casing is now extended for the False case as well: 1. package CCF_Warn is 2.procedure Mess; 3. end; 1. package body CCF_Warn is 2. type T is array (1..10) of Inte

[Ada] Rejection of legal use of subp'Access within a generic body

When the Access attribute is applied within a generic body to a prefix that denotes a subprogram declared in an enclosing generic unit, the compiler rejects this as a violation of the rule in the last sentence of RM 3.10.2(32/3). This is happening because the compiler is requiring both the access t

Re: [PATCH][AArch64 Intrinsics] Replace temporary assembler for vst1_lane

On 30 January 2015 at 12:09, Alan Lawrence wrote: > This was posted towards the end of stage 3, a few days before stage 4 > started. Is it now too late to "ping" ? > > --Alan >> gcc/ChangeLog: >> >> * config/aarch64/arm_neon.h (vst1_lane_f32, vst1_lane_f64, >> vst1_lane_p8, vst1_l

Re: [PATCH] Change __ARM_NEON__ to __ARM_NEON in libcpp/lex.c

On 30/01/15 12:52, Szabolcs Nagy wrote: > Hello, > > When running natively on AArch64 the preprocessor did not use the > AdvSIMD optimized search_line_fast function, because it was ifdefed > around by __ARM_NEON__ instead of __ARM_NEON. > > (The ARM C Language Extensions specifies the __ARM_NEON

Re: [Patch, AArch64, Obvious] Fix PR64231.

On Fri, Jan 23, 2015 at 11:03:13AM +, Tejas Belagod wrote: > > Hi, > > This is an almost obvious patch to fix PR64231 as discovered by A. Pinksi > and as proposed by Jakub. > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64231 > > Regressions happy. OK to commit? This is ok for trunk. We

Re: [testsuite] Run guality tests on Solaris

Jakub Jelinek writes: > On Thu, Jan 29, 2015 at 11:11:12PM -0700, Jeff Law wrote: >> > Linux/x86_64 Solaris 11/x86 Solaris >> > 11/SPARC >> > (Fedora 20) >> > >> >gcc.dg/guality: >> > >> ># of expected passes6490

[PATCH] Change __ARM_NEON__ to __ARM_NEON in libcpp/lex.c

Hello, When running natively on AArch64 the preprocessor did not use the AdvSIMD optimized search_line_fast function, because it was ifdefed around by __ARM_NEON__ instead of __ARM_NEON. (The ARM C Language Extensions specifies the __ARM_NEON macro, but not __ARM_NEON__ which is legacy and thus

[PATCH] pr 61889 - support gcov-tool without ftw.h

From: Trevor Saunders Hi, given the glibc man page claims this is in POSIX.1-2001 and SUv1, and none of the people testing on normally odd systems other than mingw have complained it doesn't seem terribly likely there's many other hosts where this is an issue, so I just did the minimal thing of

RE: [PATCH] Allow MIPS call-saved-{4-6}.c tests to correctly run for micromips

On Wed, 14 Jan 2015, Matthew Fortune wrote: > > Yeah, but that's just the way it goes. By trying to get everyone to > > test with the options that matter to you, you're reducing the amount of > > work you have to do when tracking regressions on those targets, but > > you're saying that people who

[PATCH] Fix PR ipa/64858

Hi. Attached patch handles situation where remove_unreachable_nodes is called before IPA ICF registers removal hooks. As a result, a deleted callgraph node is touched. Tested on x86_64-linux-pc without a new regression seen. Ready for trunk? Thanks, Martin >From 3be6518536de93b9e5397a4f65cb7e0

[Patch, fortran] Cosmetics: Dup. code removal, indent fix, typo fix.

Hi all, I fear this fix is not so obvious in one location, I therefore ask for a review. The attached patch fixes: - a duplicate code fragment (possibly due to merged twice), - the indentation in the trans-expr.c block (in my first patch), and - a typo on the datatype-size to create for the charl

Re: [PATCH] Allow MIPS call-saved-{4-6}.c tests to correctly run for micromips

On Wed, 14 Jan 2015, Richard Sandiford wrote: > >> The aim of mips.exp is avoid skipping tests whereever possible. If > >> someone runs the testsuite with -mips16 and we have a -micromips test, > >> it's better to remove -mips16 for that test than to skip the test entirely. > > > > OK, good to k

Re: [PATCH][AArch64 Intrinsics] Replace temporary assembler for vst1_lane

This was posted towards the end of stage 3, a few days before stage 4 started. Is it now too late to "ping" ? --Alan Alan Lawrence wrote: Nowadays, just storing the (bigendian-corrected) vector element to the address, generates exactly the same assembler for all cases except {float,int,uint}6

Re: [PATCH] Workaround -Wmaybe-uninitialized false positives during profiledbootstrap

On Fri, Jan 30, 2015 at 12:46:43PM +0100, Martin Liška wrote: > There's a small patch that updates the version. > > Ready for trunk? > 2015-01-30 Martin Liska > > * tree.h: Guard GCC version for a pragma ifdef. * tree.h: Change GCC_VERSION >= 4004 to GCC_VERSION >= 4006

Re: [PATCH] Workaround -Wmaybe-uninitialized false positives during profiledbootstrap

On 01/27/2015 01:31 PM, Martin Liška wrote: On 01/27/2015 05:23 AM, DJ Delorie wrote: +/* Workaround -Wstrict-overflow false positive during profiledbootstrap. */ + +# if GCC_VERSION >= 4004 +#pragma GCC diagnostic push +#pragma GCC diagnostic ignored "-Wstrict-overflow" +#endif + #pragma dia

Re: [PATCH 3/3] PR jit/64810: fix for arm_option_override

On 30/01/15 11:11, David Malcolm wrote: > libgccjit can make repeated in-process calls to the compiler code. > > On arm I see failures where e.g. the top of the generated .s file has: > on the 1st iteration: > .arch armv7-a > on the 2nd iteration: > .cpu armv7-a > without changing any options.

[Ada] Wrong Finalize_Address leads to Segmentation_Fault

This patch reimplements a key aspect of heap-allocated controlled objects. Primitive Finalize_Address is now associated with the finalization master of an access-to-controlled type when the designated type is frozen and not at the point of object allocation. -- Source --

[PATCH 3/3] PR jit/64810: fix for arm_option_override

libgccjit can make repeated in-process calls to the compiler code. On arm I see failures where e.g. the top of the generated .s file has: on the 1st iteration: .arch armv7-a on the 2nd iteration: .cpu armv7-a without changing any options. What's happening is the 1st time through arm_option_ov

[PATCH 2/3] PR jit/64810: support DImode on arm

jit_langhook_type_for_mode was failing for DImode on arm (see via a segfault in test-expressions.c.exe in the jit testsuite). A fix is to add handling for: mode == TYPE_MODE (long_long_integer_type_node) to the existing checks. gcc/jit/ChangeLog: PR jit/64810 * dummy-frontend.c

[PATCH 1/3] PR jit/64810: driver, arm, jit: configure-time default options

Currently the jit completely fails to work on arm. The root cause is that the jit is ignoring configure-time default options. For example, on configuring arm with e.g.: --with-arch=armv7-a --with-float=hard --with-fpu=vfpv3-d16 these options are written into configargs.h as "configure_default_o

Re: [PATCH, libcpp] Do not modify a token once it has been initialized

Andreas Schwab writes: >> + /* force the location of the token emitted by _cpp_lex_direct() to > > s/force/Force/ Thanks for noticing this, Andreas! I have updated my local copy of the patch to fix that. Cheers! -- Dodji

Re: [PATCH, libcpp] Do not modify a token once it has been initialized

Dodji Seketeli writes: > + /* force the location of the token emitted by _cpp_lex_direct() to s/force/Force/ Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."

Re: [PATCH][PR target/15184] Fix for direct byte access on x86

On Fri, Jan 30, 2015 at 11:23:38AM +0100, Uros Bizjak wrote: > On Fri, Jan 30, 2015 at 11:13 AM, Jakub Jelinek wrote: > > >> /* Each function should compile down to a byte move from > >> the input register into x, possibly at an offset within x. */ > >> -/* { dg-final { scan-assembler-times

Re: [PATCH][PR target/15184] Fix for direct byte access on x86

On Fri, Jan 30, 2015 at 11:13 AM, Jakub Jelinek wrote: >> /* Each function should compile down to a byte move from >> the input register into x, possibly at an offset within x. */ >> -/* { dg-final { scan-assembler-times "\tmovb\t%al, x" 4 } } */ >> +/* { dg-final { scan-assembler-times "mo

Re: [PATCH][PR target/15184] Fix for direct byte access on x86

On Fri, Jan 30, 2015 at 11:07:45AM +0100, Uros Bizjak wrote: > --- gcc.target/i386/pr15184-1.c (revision 220273) > +++ gcc.target/i386/pr15184-1.c (working copy) > @@ -1,11 +1,10 @@ > /* PR 15184 first two tests, plus two addition ones. */ > -/* { dg-do compile } */ > -/* { dg-options

Re: [PATCH][PR target/15184] Fix for direct byte access on x86

On Fri, Jan 30, 2015 at 7:12 AM, Jeff Law wrote: >> Hello! >> >>> So here's the updated patch which handles all 4 testcases from the PR as >>> well as a couple of my own. >> >> >> @@ -0,0 +1,33 @@ >> +/* PR 15184 first two tests, plus two addition ones. */ >> +/* { dg-do compile } */ >> +/* { dg

Re: [PATCH][PR target/15184] Fix for direct byte access on x86

Hi Jeff, The tests gcc.target/i386/pr15184-[12].c fail on darwin. Grepping for movb, I get movb%al, (%edx) movb%al, 1(%edx) movb%al, 2(%edx) movb%al, 3(%edx) TIA Dominique

Re: [RFC] PR64703, glibc sysdeps/powerpc/powerpc64/dl-machine.h miscompile

On Fri, Jan 30, 2015 at 10:12:35AM +0100, Richard Biener wrote: > Ok - without digging into why the above would fail with your patch > (don't see that - the use in the function call can't be &opdd) - let's > take a step back and decide whether we want to allow user-created > function descriptors.

[PATCH, libcpp] Do not modify a token once it has been initialized

Hello, While looking at PR preprocessor/64803, I noticed that builtin_macro was changing the location a token after it was been handed out by _cpp_lex_direct(). Use the combination of cpp_force_token_locations() and cpp_stop_forcing_token_locations() that are intended for exactly that use case.

Re: [PATCH] Fix PR64829

On Thu, 29 Jan 2015, Jiong Wang wrote: > 2015-01-29 14:27 GMT+00:00 Kyrill Tkachov : > > > > On 29/01/15 12:44, Richard Biener wrote: > >> > >> > >> Can you test? > > > > two issues during bootstrapping the patch on arm board on top of r220249 > > * one warning treated as error. > declarat

[PATCH] PR preprocessor/64803 - __LINE__ inside macro is not constant

[This is a P1 regression for gcc 5] Hello, Consider the example code mentionned in this PR: $ cat -n test.c 1 #define C(a, b) a ## b 2 #define L(x) C(L, x) 3 #define M(a) goto L(__LINE__); __LINE__; L(__LINE__): 4 M(a /* --> this is the line of the expansion point of M.

Re: [RFC] PR64703, glibc sysdeps/powerpc/powerpc64/dl-machine.h miscompile

On Fri, Jan 30, 2015 at 6:12 AM, Alan Modra wrote: > On Fri, Jan 30, 2015 at 01:19:51PM +1030, Alan Modra wrote: >> On Thu, Jan 29, 2015 at 04:21:15PM +0100, Richard Biener wrote: >> > > This means that you still will be able to create a testcase that is >> > > miscompiled with exposing the addres

Re: Always pass explicit location to fatal_error

On Fri, Jan 30, 2015 at 08:52:03AM +, Joseph Myers wrote: > Bootstrapped with no regressions for x86_64-unknown-linux-gnu (Go > excluded, as noted above). OK to commit (once Go has been fixed)? Ok, thanks. Jakub

Always pass explicit location to fatal_error

The patch adding an overload for fatal_error that passes an explicit location broke gcc.pot regeneration because xgettext cannot handle function overloads with the diagnostic string argument in different positions. As the desired direction

Re: [testsuite] Run guality tests on Solaris

On Thu, Jan 29, 2015 at 11:11:12PM -0700, Jeff Law wrote: > > Linux/x86_64Solaris 11/x86 Solaris > > 11/SPARC > > (Fedora 20) > > > >gcc.dg/guality: > > > ># of expected passes6490 65005489 > >