On Thu, May 21, 2015 at 7:01 PM, H.J. Lu wrote:
> Here is the updated patch. It limited memory operand to
> GOT slot only. It used a single pattern to cover both call
> and sibcall since only GOT slot is allowed.
>
> OK for master if there is no regression?
>
> Thanks.
>
>
> --
> H.J.
> ---
> X
Le 21/05/2015 19:51, Thomas Koenig a écrit :
> Am 18.05.2015 um 00:05 schrieb Thomas Koenig:
>> this patch extends the inline matmul functionality to conjugate
>> complex numbers.
>>
>> Regression-tested. OK for trunk?
>
> OK (with the trivial change in the follow-up e-mail)?
>
> I'd like to star
On Thu, 2015-05-21 at 16:45 +0100, Matthew Wahab wrote:
> On 19/05/15 20:20, Torvald Riegel wrote:
> > On Mon, 2015-05-18 at 17:36 +0100, Matthew Wahab wrote:
> >> Hello,
> >>
> >> On 15/05/15 17:22, Torvald Riegel wrote:
> >>> This patch improves the documentation of the built-ins for atomic
> >>>
On Thu, May 21, 2015 at 11:19 AM, Uros Bizjak wrote:
> On Thu, May 21, 2015 at 7:01 PM, H.J. Lu wrote:
>
>> Here is the updated patch. It limited memory operand to
>> GOT slot only. It used a single pattern to cover both call
>> and sibcall since only GOT slot is allowed.
>>
>> OK for master if
On Thu, May 21, 2015 at 8:36 PM, H.J. Lu wrote:
> I am testing this now. I will check it in if there is no regression.
OK.
Maybe just :
;; Return true if OP is a GOT memory operand.
(define_predicate "GOT_memory_operand"
(match_operand 0 "memory_operand")
{
return CONSTANT_P ...
On 05/21/2015 05:59 AM, H.J. Lu wrote:
> +(define_predicate "x32_sibcall_memory_operand"
> + (and (match_operand 0 "memory_operand")
> + (match_test "CONSTANT_P (XEXP (op, 0))")
> + (match_test "GET_CODE (XEXP (XEXP (op, 0), 0)) == UNSPEC")
> + (match_test "XINT (XEXP (XEXP (op,
On Thu, May 21, 2015 at 11:41 AM, Richard Henderson wrote:
> On 05/21/2015 05:59 AM, H.J. Lu wrote:
>> +(define_predicate "x32_sibcall_memory_operand"
>> + (and (match_operand 0 "memory_operand")
>> + (match_test "CONSTANT_P (XEXP (op, 0))")
>> + (match_test "GET_CODE (XEXP (XEXP (op,
On 05/21/2015 12:01 PM, H.J. Lu wrote:
> +++ b/gcc/testsuite/gcc.target/i386/pr66232-1.c
> @@ -0,0 +1,13 @@
> +/* { dg-do compile { target *-*-linux* } } */
> +/* { dg-options "-O2 -fpic -fno-plt" } */
> +
> +extern void bar (void);
> +
> +void
> +foo (void)
> +{
> + bar ();
> +}
> +
> +/* { dg-fi
Hi Mikael,
> There is little that is specific to conjg (any elemental function would
> work roughly the same), but anyway, the patch is OK.
Conjg has the advantage that it is an extremely cheap function -
essentially zero cost.
For an arbitrary elemental function, we would have to think about
cr
A program I instrumented to help me debug an otherwise unrelated
problem in 5.1.0 has been crashing in calls to
__builtin_return_address. After checking the manual, I didn't
think I was doing anything wrong. I then did some debugging and
found that the function simply isn't safe to call with non-z
On Thu, May 21, 2015 at 12:06 PM, Richard Henderson wrote:
> On 05/21/2015 12:01 PM, H.J. Lu wrote:
>> +++ b/gcc/testsuite/gcc.target/i386/pr66232-1.c
>> @@ -0,0 +1,13 @@
>> +/* { dg-do compile { target *-*-linux* } } */
>> +/* { dg-options "-O2 -fpic -fno-plt" } */
>> +
>> +extern void bar (void)
On Thu, 21 May 2015, H.J. Lu wrote:
> On Thu, May 21, 2015 at 12:06 PM, Richard Henderson wrote:
> > On 05/21/2015 12:01 PM, H.J. Lu wrote:
> >> +++ b/gcc/testsuite/gcc.target/i386/pr66232-1.c
> >> @@ -0,0 +1,13 @@
> >> +/* { dg-do compile { target *-*-linux* } } */
> >> +/* { dg-options "-O2 -fpi
On Thu, May 21, 2015 at 12:32 PM, Alexander Monakov wrote:
> On Thu, 21 May 2015, H.J. Lu wrote:
>> On Thu, May 21, 2015 at 12:06 PM, Richard Henderson wrote:
>> > On 05/21/2015 12:01 PM, H.J. Lu wrote:
>> >> +++ b/gcc/testsuite/gcc.target/i386/pr66232-1.c
>> >> @@ -0,0 +1,13 @@
>> >> +/* { dg-do
In this PR, we find ourselves instrumenting a static initializer and
then crashing when expanding an unlowered UBSAN_NULL. Jakub suggests
to not instrument DECL_INITIAL of a static variable. The following
patch is an attempt to do that. Note that we're still able to sanitize
similar cases (they
On Thu, 21 May 2015, H.J. Lu wrote:
> On Thu, May 21, 2015 at 12:32 PM, Alexander Monakov
> wrote:
> > On Thu, 21 May 2015, H.J. Lu wrote:
> >> On Thu, May 21, 2015 at 12:06 PM, Richard Henderson
> >> wrote:
> >> > On 05/21/2015 12:01 PM, H.J. Lu wrote:
> >> >> +++ b/gcc/testsuite/gcc.target
On 21.05.15 20:14, Andreas Tobler wrote:
On 20.05.15 22:30, Jeff Law wrote:
On 05/20/2015 11:04 AM, Andreas Tobler wrote:
Hi,
the attached patch enables some PIE tests on FreeBSD.
Ok for trunk?
Thanks,
Andreas
2015-05-20 Andreas Tobler
* gcc.target/i386/pr32219-1.c: Enable test o
On 05/21/2015 01:19 PM, Martin Sebor wrote:
2015-05-21 Martin Sebor
* extend.texi (Return Address): Clarify possible effects
of calling the functions with non-zero arguments.
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index 7470e40..b37e893 100644
--- a/gcc/doc/extend.
Hello,
I would like to ping this. Currently we have a problem with Ada ICE because we
consider a global variable produced by ada to have type in C++ anonymous
namespace and we get false ODR merging wraning compiling clang because we
consider instances of templates with parameter in anonymous namesp
On 05/21/2015 02:05 PM, Sandra Loosemore wrote:
On 05/21/2015 01:19 PM, Martin Sebor wrote:
2015-05-21 Martin Sebor
* extend.texi (Return Address): Clarify possible effects
of calling the functions with non-zero arguments.
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
in
I've committed this obvious patch to fix PR 60943. When deducing an auto return
type we failed to propagate any reference qualification on the function type.
built & tested on x86_64-linux.
nathan
2015-05-21 Nathan Sidwell
cp/
PR c++/60943
* decl2.c (change_return_type): Propagate FUNCT
On Sun, May 10, 2015 at 10:01 AM, Sriraman Tallam wrote:
>
> On Sun, May 10, 2015, 8:19 AM H.J. Lu wrote:
>
> On Sat, May 9, 2015 at 9:34 AM, H.J. Lu wrote:
>> On Mon, May 4, 2015 at 7:45 AM, Michael Matz wrote:
>>> Hi,
>>>
>>> On Thu, 30 Apr 2015, Sriraman Tallam wrote:
>>>
We noticed tha
On 05/08/2015 06:26 AM, Eric Botcazou wrote:
[Jason, question below.]
What's the replacement mechanism for the first pass on global_decls? The
comment explains that generating debug info must be delayed in this case.
My apologies for the delay on Ada. I have reworked the patch to leave
the
On 05/21/2015 04:32 PM, Jan Hubicka wrote:
I think at LTO time it is useful to have two things
- be able to say what type comply C++ ODR rule, because we special case these
for ODR warnings
- be able to say at LTO time what types are anonymous, that is they are not
compatible with
On Thu, May 21, 2015 at 2:12 PM, Sriraman Tallam wrote:
> On Sun, May 10, 2015 at 10:01 AM, Sriraman Tallam wrote:
>>
>> On Sun, May 10, 2015, 8:19 AM H.J. Lu wrote:
>>
>> On Sat, May 9, 2015 at 9:34 AM, H.J. Lu wrote:
>>> On Mon, May 4, 2015 at 7:45 AM, Michael Matz wrote:
Hi,
Jeff Law writes:
> On 05/14/2015 03:13 PM, Jiong Wang wrote:
>>
>> Jeff Law writes:
>>
>>> For all kinds of reassociation we have to concern ourselves with adding
>>> overflow where it didn't already occur. Assuming a 32 bit architecture
>>> we could get overflow if A is 0x7fff, b is -4 and
> On 05/21/2015 04:32 PM, Jan Hubicka wrote:
> >I think at LTO time it is useful to have two things
> > - be able to say what type comply C++ ODR rule, because we special case
> > these
> > for ODR warnings
> > - be able to say at LTO time what types are anonymous, that is they are
> > no
On 05/21/2015 08:19 PM, Martin Sebor wrote:
> A program I instrumented to help me debug an otherwise unrelated
> problem in 5.1.0 has been crashing in calls to
> __builtin_return_address. After checking the manual, I didn't
> think I was doing anything wrong. I then did some debugging and
> found t
On 05/21/2015 10:12 PM, Sriraman Tallam wrote:
>
> My original proposal, for x86_64 only, was to add
> -fno-plt=. This lets the user decide for which
> functions PLT must be avoided. Let the compiler always generate an
> indirect call using call *func@GOTPCREL(%rip). We could do this for
> non-P
On Thu, May 21, 2015 at 10:51:50PM +0100, Pedro Alves wrote:
> On 05/21/2015 10:12 PM, Sriraman Tallam wrote:
> >
> > My original proposal, for x86_64 only, was to add
> > -fno-plt=. This lets the user decide for which
> > functions PLT must be avoided. Let the compiler always generate an
> > ind
On Thu, May 21, 2015 at 12:01 PM, H.J. Lu wrote:
> On Thu, May 21, 2015 at 11:41 AM, Richard Henderson wrote:
>> On 05/21/2015 05:59 AM, H.J. Lu wrote:
>>> +(define_predicate "x32_sibcall_memory_operand"
>>> + (and (match_operand 0 "memory_operand")
>>> + (match_test "CONSTANT_P (XEXP (op,
On Thu, May 21, 2015 at 2:51 PM, Pedro Alves wrote:
> On 05/21/2015 10:12 PM, Sriraman Tallam wrote:
>>
>> My original proposal, for x86_64 only, was to add
>> -fno-plt=. This lets the user decide for which
>> functions PLT must be avoided. Let the compiler always generate an
>> indirect call usi
On Thu, May 21, 2015 at 2:58 PM, Jakub Jelinek wrote:
> On Thu, May 21, 2015 at 10:51:50PM +0100, Pedro Alves wrote:
>> On 05/21/2015 10:12 PM, Sriraman Tallam wrote:
>> >
>> > My original proposal, for x86_64 only, was to add
>> > -fno-plt=. This lets the user decide for which
>> > functions PLT
Jason,
this fixes 65936, where we have two identical types with mismatching
TYPE_CANONICAL. The problem comes from template decl creation vs template
instantiation.
At the point we create 'const C' in the operator function we have not
applied the 'may_alias' attribute to 'const C'. This mea
We have -finstrument-functions-exclude-function-list=.. in GCC, though
it is not using mangled names.
David
On Thu, May 21, 2015 at 2:58 PM, Jakub Jelinek wrote:
> On Thu, May 21, 2015 at 10:51:50PM +0100, Pedro Alves wrote:
>> On 05/21/2015 10:12 PM, Sriraman Tallam wrote:
>> >
>> > My original
How about adding may_alias support to the code a bit lower down that
copies the abi_tag attribute?
Jason
On 05/21/2015 05:34 PM, Jan Hubicka wrote:
This would also work, yes. We can set it into something like "".
One problem would be that type_with_linkage_p/type_in_anonymous_namespace_p
would not work on non-C++ types without LTO (because then we do not produce the
type manglings). I suppose it
My earlier patch to compile stage 1 with -std=c++98 ran into trouble on
FreeBSD, where that flag suppresses declaration of C99 library functions
like strtoull. I was surprised that configure was seeing the
declaration, but discovered that this was because configure was using
the C compiler rat
This patch fixes
FAIL: gcc.target/powerpc/ti_math1.c scan-assembler-times adde 1
a failure caused by combine simplifying this i2src
(plus:DI (plus:DI (reg:DI 165 [ val+8 ])
(reg:DI 169 [+8 ]))
(reg:DI 76 ca))
to this
(plus:DI (plus:DI (reg:DI 76 ca)
(reg:DI 165 [ val+8 ]))
101 - 138 of 138 matches
Mail list logo
