When compiling invalid C++ code, CALL_EXPR that contains identifier_node
instead of a FUNCTION_DECL got into dump_expr - and is_ubsan_builtin_p
was expecting that it only gets FUNCTION_DECLs. Fixed by changing the
assert into a condition so is_ubsan_builtin_p returns false for
non-functions.
Regt
On Wed, May 21, 2014 at 04:46:14PM +0200, Jakub Jelinek wrote:
> Here is a testcase that (IMHO, not tested with your patch) should
> test various boundary cases that shouldn't result in undefined behavior.
> I've tried to keep it portable across various architectures, assumes
> primarily two's comp
On Wed, May 21, 2014 at 08:46:22PM +0200, Marek Polacek wrote:
> 2014-05-21 Marek Polacek
>
> PR sanitizer/61272
> * ubsan.c (is_ubsan_builtin_p): Turn assert into a condition.
>
> * g++.dg/ubsan/pr61272.C: New test.
Ok, thanks.
Jakub
> +(define_expand "one_cmpl2"
> + [(match_operand:IMSA 0 "register_operand")
> + (match_operand:IMSA 1 "register_operand")]
> + "ISA_HAS_MSA"
> +{
> + if (mode == V16QImode)
> +emit_insn (gen_msa_nori_b (operands[0], operands[1], const0_rtx));
> + else
> +{
> + rtx reg = gen_reg_
On Wed, May 21, 2014 at 04:09:19PM +0400, Konstantin Serebryany wrote:
> A new patch based on r209283.
> This one has the H.J.'s patches for x32.
Ok for trunk then. But please help the ppc*/arm*/sparc* maintainers if issues
on
those targets are reported.
Thanks.
Jakub
Hi,
one of the transformations performed by associate_plusminus is:
/* Second match patterns that allow contracting a plus-minus pair
irrespective of overflow issues.
[...]
(T)(P + A) - (T)P -> (T)A
but it is actually applied only to POINTER_PLUS_EXPR and pointer types:
Matthew Fortune writes:
>> > *) Because GCC can be built to have mfpxx or mfp64 as the default option
>> >the ASM_SPEC has to handle these specially such that they are not
>> >passed in conjunction with -msingle-float. Depending on how all this
>> >option handling pans out then this ma
Compiling some applications with -mgeneral-regs-only produces better
code (runs faster) compared to not using it. The difference here is that
when -mgeneral-regs-only is not used, floating point register are also
used in register allocation. Then IRA/LRA has to move them to core
registers before pe
On Wed, May 21, 2014 at 4:44 PM, Kugan
wrote:
> Compiling some applications with -mgeneral-regs-only produces better
> code (runs faster) compared to not using it. The difference here is that
> when -mgeneral-regs-only is not used, floating point register are also
> used in register allocation. Th
This fixes another case where we use the wrong memory constraint. See
the analysis in the PR. The rule for operand predicate and
constraints is simply that the union of all constraints must exactly
match the operand predicate.
Bootstrapped and regression tested powerpc64-linux and
powerpc64le-li
On Wed, May 21, 2014 at 8:13 PM, Alan Modra wrote:
> This fixes another case where we use the wrong memory constraint. See
> the analysis in the PR. The rule for operand predicate and
> constraints is simply that the union of all constraints must exactly
> match the operand predicate.
>
> Bootst
On 21 May 2014 20:43, Steven Bosscher wrote:
> On Wed, May 21, 2014 at 11:58 AM, Zhenqiang Chen wrote:
>> Hi,
>>
>> The patch fixes the gcc.target/i386/pr49095.c FAIL in PR61225. The
>> test case tends to check a peephole2 optimization, which optimizes the
>> following sequence
>>
>> 2: bx:SI=
Em ter 20 maio 2014 22:04:32 você escreveu:
> Hi,
> as disucssed some time ago, our assumption that every symbol of shared
> library can be interposed at runtime is expensive and prevents a lot of
> useful optimizations, including inlining or IPA propagation.
>
> While this is useful feature, it i
Hello;
FWIW, I have been looking at some changes from Apple's GCC and these two
small changes should be interesting to have in the official gcc.
Implement -Wmost for compatibility with clang.
http://svnweb.freebsd.org/base?view=revision&revision=259920
Add Apple compatible -Wnewline-eof
http:
On Wed, May 21, 2014 at 7:50 PM, Pedro Giffuni wrote:
> Hello;
>
> FWIW, I have been looking at some changes from Apple's GCC and these two
> small changes should be interesting to have in the official gcc.
>
> Implement -Wmost for compatibility with clang.
> http://svnweb.freebsd.org/base?view=re
On Wed, May 21, 2014 at 7:58 PM, Andrew Pinski wrote:
> On Wed, May 21, 2014 at 7:50 PM, Pedro Giffuni wrote:
>> Hello;
>>
>> FWIW, I have been looking at some changes from Apple's GCC and these two
>> small changes should be interesting to have in the official gcc.
>>
>> Implement -Wmost for com
Committed to trunk, 4.9, and waiting for the release of 4.8.3.
OK for google/main and google/4.9?
thanks
Carrot
On Wed, May 21, 2014 at 1:34 AM, Richard Biener wrote:
> On Wed, 21 May 2014, Marcus Shawcroft wrote:
>
>> On 21 May 2014 09:28, Marcus Shawcroft wrote:
>> > On 20 May 2014 18:37, Ca
Since it is in trunk and gcc-4_9-branch, there is no need to put into
google branches -- will get it automatically after next merge.
David
On Wed, May 21, 2014 at 8:13 PM, Carrot Wei wrote:
> Committed to trunk, 4.9, and waiting for the release of 4.8.3.
>
> OK for google/main and google/4.9?
>
On Wed, May 21, 2014 at 11:17:53AM +0200, Richard Biener wrote:
> On Wed, May 21, 2014 at 3:59 AM, Rich Felker wrote:
> > Bug # 61144 is a regression in 4.9.0 that breaks building of musl libc
> > due to aggressive and semantically-incorrect constant folding of weak
> > aliases. The attached patch
Hi,
this patch fixes an ICE on undefined symbol. The testcase does not really go
easily to testsuite
because it needs the undefined symbols to trigger. THe bug is however clear -
one of the
loops is not properly skipping the static symbols.
Bootstrapped/regtested x86_64-linux, comitted to mainli
On Wed, May 21, 2014 at 4:35 PM, Steve Kargl
wrote:
> On Mon, May 19, 2014 at 11:40:06PM +0300, Janne Blomqvist wrote:
>> Hello,
>>
>> some systems such as GNU Hurd, don't define PATH_MAX at all, and on
>> some other systems many syscalls apparently work for paths longer than
>> PATH_MAX. Thus GFo
On Wed, May 21, 2014 at 11:43 PM, Jakub Jelinek wrote:
> On Wed, May 21, 2014 at 04:09:19PM +0400, Konstantin Serebryany wrote:
>> A new patch based on r209283.
>> This one has the H.J.'s patches for x32.
>
> Ok for trunk then. But please help the ppc*/arm*/sparc* maintainers if
> issues on
> th
101 - 122 of 122 matches
Mail list logo
