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 is provided to make
(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 afte
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 regtested on x86_64-unknown-lin
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 p
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,
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
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
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.
---
gdb/testsuite
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&root=gcc&view=rev ).
And I've
Any comm
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 x86_64-apple-darwin15.
>
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, https://gcc.gnu.org/viewcvs?rev=233583&ro
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, r
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 was willing to
> do it using
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 exp
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
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.
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, &ev.token, 0B, 0B, 0);
The attached patch solves the problem.
I don't understand the fol
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 t
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 e
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 name-by-nam
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). Henc
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 resolve
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
compilatio
23 matches
Mail list logo
