[PATCH] PR28901 Add two levels for -Wunused-const-variable.

There is some controversy about enabling -Wunused-const-variable for all unused static const variables because some feel there are too many errors exposed in header files. Create two levels for -Wunused-const-variable. One level to only check for unused static const variables in the main

[PATCH] Fix PR c++/69694 (non-dependent MODOP_EXPR with NULL type)

The problem here is that when processing_template_decl, the non-compound MODOP_EXPRs we build (i.e. a = b and not a += b) are given a NULL TREE_TYPE even if none of its operands are dependent. This causes decltypes such as "decltype (a = b)" (where a and b are not dependent) to fail to get

Re: [PATCH] Fix Bug 17896: The expression (a>0 & b>0) should give clearer warning message (-Wparentheses)

On Sat, 2016-01-30 at 19:05 +0530, Prasad Ghangal wrote: > Hi! > > This is my first proposed patch for > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=17896. I was willing to > do it using "APPEARS_TO_BE_BOOLEAN_EXPR_P(CODE, ARG)" to check > booleans but gcc doesn't allow (bootstraping fails).

Re: [Patch, fortran] PR69423 - [6 Regression] Invalid optimization with deferred-length character

Hi Paul, More importantly, now that it has happened in the field, I must fix the collisions in SELECT TYPE. The only way that I know to do this reliably is to drop the use of a has and to use the extended type names directly Can you also use the hash in the usual case and only do a

Re: [Patch, fortran] PR69423 - [6 Regression] Invalid optimization with deferred-length character

Le 20/02/2016 19:35, Paul Richard Thomas a écrit : The only way that I know to do this reliably is to drop the use of a has and to use the extended type names directly. This will take a bit of work! Maybe the vtab pointer can be used to discriminate between types? There is one vtab struct for

Re: [Patch, fortran] PR69423 - [6 Regression] Invalid optimization with deferred-length character

Dear Dominique, dear all, Many thanks for picking up the regression, which turned out to have a trivial cause. I have taken the liberty of assuming that this is tantamount to approval and have committed the patch as revision 233589. Any style or other wrinkles can be corrected later. The reason

[Fortran, Patch] (Coarrays) Wrong events size

Dear all, currently, the compiler doesn't pass the right size to the registration routine of OpenCoarrays for event variables: size.15 = 0; ev.data = (void * restrict) _gfortran_caf_register (MAX_EXPR , 6, , 0B, 0B, 0); The attached patch solves the problem. I don't understand the

[PATCH] Add testcase for PR61033

This patch adds a testcase for PR61033 [1]. The bug is about compiler going into infinite loop while solving data-flow in vt_find_locations on arm-* targets. The issue in fixed in GCC 5 and later by Richard B.'s r211624 [2]. The bug affects GCC 4.8 and 4.9, but is unlikely to be fixed there.

[PATCH 1/2] RFC: Add test coverage for _Pragma (PR preprocessor 69126, 69543, 69558)

We had some regressions in the ability for _Pragma to disable a warning (PR preprocessor/69126, PR preprocessor/69543, PR preprocessor/69558). This patch attempts to add more test coverage for this, for the various combinations of: - various warnings: -Wunused-variable -Wuninitialized

[PATCH 2/2] PR preprocessor/69126: avoid comparing ad-hoc and non-ad-hoc locations

Comment #18 of PR preprocessor/69126 reported a difficult-to-reproduce re-occurrence of that bug, where attempts to suppress -Wdeprecated-declarations via a _Pragma could fail. The root cause is a bug in linemap_compare_locations when comparing certain macro expansions with certain non-macro

Re: [PATCH] Fix Bug 17896: The expression (a>0 & b>0) should give clearer warning message (-Wparentheses)

PING Sorry I didn't include [Fix PR c/17896] in prev mail https://gcc.gnu.org/ml/gcc-patches/2016-01/msg02361.html On 30 January 2016 at 19:05, Prasad Ghangal wrote: > Hi! > > This is my first proposed patch for > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=17896. I

Re: [PATCH 1/3] gdb.trace: Move more target dependencies to trace-support.exp

Whoops, sorry for that mail - I typoed gdb-patches to gcc-patches. On 20/02/16 14:56, Marcin Kościelnicki wrote: While groveling through the old PPC64 tracepoint support patch, I've noticed a few target dependencies in the testsuite that both me and Antoine missed for s390 and ARM tracepoints,

Re: [RFC] Add contrib/fix-ChangeLog.sh

On 20/02/16 15:04, Tom de Vries wrote: Hi, this patch adds a script contrib/fix-ChangeLog.sh. It fixes whitespace issues, and shows ChangeLog lines that look suspicious. Using the script, I was able to find a stray changelog entry (removed in rr233583,

Re: New tests for PRs 52531 and 57365

Committed on trunk as revision r233588. Dominique > Le 15 févr. 2016 à 14:53, Dominique d'Humières a écrit : > > PRs 52531 and 57365 are fixed on trunk and gcc5 branch. Unless someone > objects I am planing to add the following tests in the coming days. > > Tested on

[RFC] Add contrib/fix-ChangeLog.sh

Hi, this patch adds a script contrib/fix-ChangeLog.sh. It fixes whitespace issues, and shows ChangeLog lines that look suspicious. Using the script, I was able to find a stray changelog entry (removed in rr233583, https://gcc.gnu.org/viewcvs?rev=233583=gcc=rev ). And I've Any comments?

[PATCH 1/3] gdb.trace: Move more target dependencies to trace-support.exp

While groveling through the old PPC64 tracepoint support patch, I've noticed a few target dependencies in the testsuite that both me and Antoine missed for s390 and ARM tracepoints, respectively. This patch moves them all to one place, so that anyone working on a new target will hopefully see the

[PATCH 3/3] gdb.trace: Remove unnecessary target check from ftrace.exp.

The check used hardcoded targets and wasn't doing anything useful anyway, since unsupported architectures blow up on link due to missing the IPA library before they ever get to that check. gdb/testsuite/ChangeLog: * gdb.trace/ftrace.exp: Remove unnecessary target check. ---

[PATCH 2/3] gdb.trace: Surround $call_insn with \y in entry-values.exp

The PPC64 tracepoint patch added \y at the end of the call_insn pattern - without that, it embarassed itself and matched the 'bl' in "Dump of assem*bl*er code for function" as the powerpc call opcode. Since that sounds like a generally good idea, I've added \y before and after call_insn for every

Re: Wonly-top-basic-asm

On 20.02.2016 02:03, David Wohlferd wrote: > @example > -/* Note that this code will not compile with -masm=intel */ > -#define DebugBreak() asm("int $3") > +/* Define macro at file scope with basic asm. */ > +/* Add macro parameter p to eax. */ > +asm (".macro testme p\n\t" > +"addl $\\p,

Re: [PATCH][RFC][Offloading] Fix PR68463

On Fri, Feb 19, 2016 at 15:53:08 +0100, Jakub Jelinek wrote: > On Wed, Feb 10, 2016 at 08:19:34PM +0300, Ilya Verbin wrote: > > This patch adds crtoffload{begin,end}.o to all -fopenmp programs, if they > > exist. > > I couldn't think of a better solution... > > Tested using the testcase from the

Re: [PATCH, PR middle-end/68134] Reject scalar modes in default get_mask_mode hook

2016-02-19 20:36 GMT+03:00 Alan Lawrence : > On 17/11/15 11:49, Ilya Enkovich wrote: >> >> Hi, >> >> Default hook for get_mask_mode is supposed to return integer vector modes. >> This means it should reject calar modes returned by mode_for_vector. >> Bootstrapped and

Re: i386: add a variant peephole for decl (mem)

(please CC me on x86 specific patches) > PR 49095 requested the following optimization: [...] > * config/i386/i386.md (operation on memory peephole): Duplicate an > existing peephole and adapt it to match lea rather than an operation > that clobbers CC. OK for mainline and release branches

Re: [PATCH] 69759 - document __builtin_alloca and __builtin_alloca_with_align

Martin Sebor writes: > +in bits (not bytes). @var{size} must be positive and not exceed the stack > +size limit. @var{align} must be a constant integer expression that Don't use a lowercase word at the start of a sentence. > +The @code{__builtin_alloca_with_align} function