[PATCH] Combine related fail of gcc.target/powerpc/ti_math1.c

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 ]))

PATCH to run autoconf tests with C++ compiler

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

Re: [C frontend] Fix construction of TYPE_STUB_DECL

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

Re: [C++ PATCH] fix canonical type ICE

How about adding may_alias support to the code a bit lower down that copies the abi_tag attribute? Jason

Re: [RFC][PATCH][X86_64] Eliminate PLT stubs for specified external functions via -fno-plt=

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

[C++ PATCH] fix canonical type ICE

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

Re: [RFC][PATCH][X86_64] Eliminate PLT stubs for specified external functions via -fno-plt=

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

Re: [RFC][PATCH][X86_64] Eliminate PLT stubs for specified external functions via -fno-plt=

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

Re: [PATCH] PR target/66232: -fPIC -fno-plt -mx32 fails to generate indirect branch via GOT

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,

Re: [RFC][PATCH][X86_64] Eliminate PLT stubs for specified external functions via -fno-plt=

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

Re: [RFC][PATCH][X86_64] Eliminate PLT stubs for specified external functions via -fno-plt=

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

Re: [PATCH] clarify doc for __builtin_return_address

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

Re: [C frontend] Fix construction of TYPE_STUB_DECL

> 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

Re: [PATCH] PR 62173, re-shuffle insns for RTL loop invariant hoisting

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

Re: [RFC][PATCH][X86_64] Eliminate PLT stubs for specified external functions via -fno-plt=

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,

Re: [C frontend] Fix construction of TYPE_STUB_DECL

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

Re: [patch 1/10] debug-early merge: Ada front-end

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

Re: [RFC][PATCH][X86_64] Eliminate PLT stubs for specified external functions via -fno-plt=

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

[C++ PATCH] Fix return deduction and ref-quals

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

Re: [PATCH] clarify doc for __builtin_return_address

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

Re: [C frontend] Fix construction of TYPE_STUB_DECL

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

Re: [PATCH] clarify doc for __builtin_return_address

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.

Re: [patch] testsuite enable PIE tests on FreeBSD

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

Re: [PATCH] PR target/66232: -fPIC -fno-plt -mx32 fails to generate indirect branch via GOT

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

[PATCH] Don't instrument DECL_INITIAL of statics (PR sanitizer/66190)

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

Re: [PATCH] PR target/66232: -fPIC -fno-plt -mx32 fails to generate indirect branch via GOT

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

Re: [PATCH] PR target/66232: -fPIC -fno-plt -mx32 fails to generate indirect branch via GOT

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

Re: [PATCH] PR target/66232: -fPIC -fno-plt -mx32 fails to generate indirect branch via GOT

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)

[PATCH] clarify doc for __builtin_return_address

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

Re: Ping ** 0.5 patch, fortran] Inline matmul with conjugate complex numbers

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

Re: [PATCH] PR target/66232: -fPIC -fno-plt -mx32 fails to generate indirect branch via GOT

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

Re: [PATCH] PR target/66232: -fPIC -fno-plt -mx32 fails to generate indirect branch via GOT

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,

Re: [PATCH] PR target/66232: -fPIC -fno-plt -mx32 fails to generate indirect branch via GOT

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,

Re: [PATCH] PR target/66232: -fPIC -fno-plt -mx32 fails to generate indirect branch via GOT

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 ...

Re: [PATCH] PR target/66232: -fPIC -fno-plt -mx32 fails to generate indirect branch via GOT

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

Re: [PATCH] Fix memory orders description in atomic ops built-ins docs.

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 > >>>

Re: Ping ** 0.5 patch, fortran] Inline matmul with conjugate complex numbers

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

Re: [PATCH] PR target/66232: -fPIC -fno-plt -mx32 fails to generate indirect branch via GOT

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

Calculate TYPE_CANONICAL only for types that can be accessed in memory

Hi, this is next part of the series. It disables canonical type calculation for incomplete types with exception of arrays based on claim that we do not have good notion of those. I can botostrap this with additional checks in alias.c that canonical types are always present with LTO but I need fix

Re: [patch] testsuite enable PIE tests on FreeBSD

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 on FreeBSD. * gcc.target/i386/pr32219-

Re: C/C++ PATCH to allow deprecating enum values (PR c/47043)

On 05/07/2015 12:22 PM, Marek Polacek wrote: - mark_used (decl); + mark_used (decl, 0); This should use tf_none rather than 0. + build_enumerator (DECL_NAME (decl), value, newtag, + DECL_ATTRIBUTES (decl), DECL_SOURCE_LOCATION (decl)); This is assuming t

Re: [AArch64][TLSLE][4/N] Recognize -mtls-size

Jiong Wang writes: > This patch add -mtls-size option for AArch64. This option let user to do > finer control on code generation for various TLS model on AArch64. > > For example, for TLS LE, user can specify smaller tls-size, for example > 4K which is quite usual, to let AArch64 backend generate

Ping ** 0.5 patch, fortran] Inline matmul with conjugate complex numbers

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 start extending this to TRANSPOSE(CONJG(A)) :-) Thoma

Re: PING^3: [PATCH]: New configure options that make the compiler use -fPIE and -pie as default option

On Thu, May 21, 2015 at 7:13 AM, Rainer Orth wrote: > "H.J. Lu" writes: > >> Here is the complete patch. Tested on Linux/x86-64. It is also >> available on hjl/pie/master branch in git mirror. > > As always, please keep generated files like configure and config.in out > of the submission: it si

Re: [PATCH][AArch64] Add __extension__ and __always_inline__ to crypto intrinsics

On Thu, May 21, 2015 at 03:42:33PM +0100, Kyrill Tkachov wrote: > Hi all, > > The crypto intrinsics are missing an __extension__ and an __always_inline__ > attribute that all the other intrinsics have. I don't see any reason for them > to be different and the always_inline attribute will be needed

Avoid non-canonical RTL in splitter for adding a large constant to register on the PA

The PA has a splitter to optimize the addition of certain constants to a register. One of the cases the splitter handles is when the constant requires 2 insns to generate, is divisible by 2, 4, or 8 and if divided by 2, 4 or 8 it only needs a single insn to generate the constant. Obviously

Re: PING^3: [PATCH]: New configure options that make the compiler use -fPIE and -pie as default option

On Thu, 21 May 2015, Rainer Orth wrote: > @@ -1864,6 +1873,12 @@ libgcc.mvars: config.status Makefile specs > xgcc$(exeext) > echo GCC_CFLAGS = '$(GCC_CFLAGS)' >> tmp-libgcc.mvars > echo INHIBIT_LIBC_CFLAGS = '$(INHIBIT_LIBC_CFLAGS)' >> tmp-libgcc.mvars > echo TARGET_SYSTEM_ROOT

Re: Check canonical types in verify_type

> > Hmm, I see, interesting hack. For the first part of comment, I see that > > qualifiers needs to be ignored, but I do not see why we put > > short * and int * pointers to same class. > > For the reason that people are very lazy. For example GCC has code > punning void ** and void * and void *

Re: [PATCH] PR target/66232: -fPIC -fno-plt -mx32 fails to generate indirect branch via GOT

On Thu, May 21, 2015 at 6:33 AM, H.J. Lu wrote: > On Thu, May 21, 2015 at 6:11 AM, Uros Bizjak wrote: >> On Thu, May 21, 2015 at 2:59 PM, H.J. Lu wrote: >>> X32 doesn't support indirect branch via 32-bit memory slot since >>> indirect branch will load 64-bit address from 64-bit memory slot. >>>

Re: [PATCH][ARM][stage-1] Initialise cost to COSTS_N_INSNS (1) and increment in arm rtx costs

Ping^3. Thanks, Kyrill On 12/05/15 10:09, Kyrill Tkachov wrote: Ping^2. Thanks, Kyrill On 30/04/15 13:00, Kyrill Tkachov wrote: Ping. https://gcc.gnu.org/ml/gcc-patches/2015-04/msg01130.html Thanks, Kyrill On 21/04/15 10:11, Kyrill Tkachov wrote: Hi all, This is the first of a series to

Re: [PATCH][ARM/AArch64] Properly cost rev16 operand

Ping. Thanks, Kyrill On 12/05/15 10:07, Kyrill Tkachov wrote: Ping. https://gcc.gnu.org/ml/gcc-patches/2015-05/msg00013.html Thanks, Kyrill On 01/05/15 09:24, Kyrill Tkachov wrote: Hi all, It occurs to me that in the IOR-of-shifts form of the rev16 operation we should be costing the operand

Re: [PATCH][ARM] Handle UNSPEC_VOLATILE in rtx costs and don't recurse inside the unspec

Ping^3. Thanks, Kyrill On 12/05/15 10:08, Kyrill Tkachov wrote: Ping^2. Thanks, Kyrill On 30/04/15 13:01, Kyrill Tkachov wrote: Ping. https://gcc.gnu.org/ml/gcc-patches/2015-04/msg01047.html Thanks, Kyrill On 20/04/15 17:28, Kyrill Tkachov wrote: Hi all, A pet project of mine is to get to

Re: [PATCH][DRIVER] Wrong C++ include paths when configuring with "--with-sysroot=/"

On Thu, 21 May 2015, Yvan Roux wrote: > There is this old patch submitted by Matthias on that same issue, if > its logic is the right one for you Joseph I can rebase/validate it > Joseph. > > https://gcc.gnu.org/ml/gcc-patches/2012-02/msg00320.html Yes, that seems better. -- Joseph S. Myers jo

Re: [PATCH 1/7] always define STACK_GROWS_DOWNWARD

This patch needs to update tm.texi.in and regenerate tm.texi to describe the new semantics of STACK_GROWS_DOWNWARD. -- Joseph S. Myers jos...@codesourcery.com

[AArch64][TLSLE][N/N] Implement local executable mode for all memory model

4 instruction sequences can be implemented for AArch64 TLS LE model based on relocations provided. These instruction sequences are the same for tiny/small/large, We just need to choose the most efficient one to use accoding to tls size. the 12bit version give us 4K TLS size, 24bit give us 16M, 3

[gomp4.1] Add taskloop-4.c testcase

Hi! I've committed another testcase, which tests the computation of number of iterations for each task and number of tasks. 2015-05-21 Jakub Jelinek * testsuite/libgomp.c/taskloop-4.c: New test. --- libgomp/testsuite/libgomp.c/taskloop-4.c(revision 0) +++ libgomp/testsuite/libgom

[AArch64][TLSLE][5/N] Recognize -mtls-size

This patch add -mtls-size option for AArch64. This option let user to do finer control on code generation for various TLS model on AArch64. For example, for TLS LE, user can specify smaller tls-size, for example 4K which is quite usual, to let AArch64 backend generate more efficient instruction s

Re: Do not compare type attributes in gimple_canonical_types_compatible_p

On May 21, 2015 6:06:18 PM GMT+02:00, Jan Hubicka wrote: >Hi, >this patch removes call to comp_type_attributes (wich happens for >METHOD_TYPE and FUNCTION_TYPE only). This does not make sense, because >type attributes may change in variants and pointers should be >considered >compatible. > >We did

Re: Fix hashing of basetypes of methods

On May 21, 2015 6:02:27 PM GMT+02:00, Jan Hubicka wrote: >Hi, >this patch drops TYPE_METHOD_BASETYPE from hash_canonical_type. It is >not >compared by gimple_canonical_types_compatible_p and thus it can only >corrupt the hashtable by having two entries that are equal but having >different >hash.

Re: [patch, testsuite, ARM] don't try to execute advsimd-intrinsics tests on hardware without NEON

On 05/21/2015 03:48 AM, Christophe Lyon wrote: On 21 May 2015 at 07:33, Sandra Loosemore wrote: ARM testing shares the AArch64 advsimd-intrinsics execution tests. On ARM, though, the NEON support being tested is optional -- some arches are compatible with the NEON compilation options but hardw

RE: Fix PR48052: loop not vectorized if index is "unsigned int"

I tested this patch and it passes bootstrap and no extra failures. Thanks -Aditya Symbolically evaluate conditionals, and subtraction when additional constraints are provided. Adding this evaluation mechanism helps vectorize some loops on 64bit machines because on 64bit, a typecast appears w

Do not compare type attributes in gimple_canonical_types_compatible_p

Hi, this patch removes call to comp_type_attributes (wich happens for METHOD_TYPE and FUNCTION_TYPE only). This does not make sense, because type attributes may change in variants and pointers should be considered compatible. We did not get any trouble from this only because we do not really use c

Re: [patch, testsuite] don't specify "dg-do run" explicitly for vect test cases

On 05/21/2015 03:08 AM, Richard Biener wrote: On Thu, May 21, 2015 at 7:12 AM, Sandra Loosemore wrote: On targets such as ARM, some arches are compatible with options needed to enable compilation with vectorization, but the specific hardware (or simulator or BSP) available for execution tests m

Fix hashing of basetypes of methods

Hi, this patch drops TYPE_METHOD_BASETYPE from hash_canonical_type. It is not compared by gimple_canonical_types_compatible_p and thus it can only corrupt the hashtable by having two entries that are equal but having different hash. Theoretically we may want later distinguish the method pointer b

[PATCH 3/3][Aarch64] Add tests for __sync_builtins.

This patch adds tests for the code generated by the Aarch64 backend for the __sync builtins. Tested aarch64-none-linux-gnu with check-gcc. Ok for trunk? Matthew gcc/testsuite/ 2015-05-21 Matthew Wahab * gcc.target/aarch64/sync-comp-swap.c: New. * gcc.target/aarch64/sync-comp

[AArch64][PATCH 2/3] Strengthen barriers for sync-compare-swap builtins.

This patch changes the code generated for __sync_type_compare_and_swap to ldxr reg; cmp; bne label; stlxr; cbnz; label: dmb ish; mov .., reg This removes the acquire-barrier from the load and ends the operation with a fence to prevent memory references appearing after the __sync operation from

[PATCH 1/3][AArch64] Strengthen barriers for sync-fetch-op builtins.

On Aarch64, the __sync builtins are implemented using the __atomic operations and barriers. This makes the the __sync builtins inconsistent with their documentation which requires stronger barriers than those for the __atomic builtins. The difference between __sync and __atomic builtins is that t

Re: [PATCH] Fix (ocvt (icvt@1 @0)) simplification (PR tree-optimization/66233)

On May 21, 2015 5:28:14 PM GMT+02:00, Jakub Jelinek wrote: >Hi! > >We ICE on the following testcase at -O3 on x86_64-linux, because >gimple folding attempts to simplify FLOAT_EXPR conversion of >signed V4SI to V4SF feeding FIX_TRUNC_EXPR to unsigned V4SI >into a FIX_TRUNC_EXPR with unsigned V4SI l

Re: [gomp4] Lack of OpenACC NVPTX devices is not an error during scanning

Hi Julian! On Tue, 19 May 2015 11:36:58 +0100, Julian Brown wrote: > This patch fixes an oversight whereby if the CUDA libraries are > available for some reason on a system that doesn't actually contain an > nVidia card, an OpenACC program will raise an error if the NVPTX > backend is picked as

Re: [PATCH] Fix memory orders description in atomic ops built-ins docs.

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 operations. The "memory model" to "memory order" change does improve things but I

Re: Cleanup and improve canonical type construction in LTO

> On Wed, 20 May 2015, Jan Hubicka wrote: > > > Richard, > > this is my attempt to make sense of TYPE_CANONICAL at LTO. My > > undrestanding is > > that gimple_canonical_types_compatible_p needs to return true for all pairs > > of > > types that are considered compatible across compilation unit

Re: Don't dump low gimple functions in gimple dump

Hi! It's just been a year. ;-P In early March, I (hopefully correctly) adapted Tom's patch to apply to then-current GCC trunk sources; posting this here. Is the general approach OK? On Tue, 20 May 2014 10:16:45 +0200, Tom de Vries wrote: > Honza, > > Consider this program: > ... > int > main

[committed] Tweak inform_declaration

See for the rationale. Bootstrapped/regtested on x86_64-linux, applying to trunk. 2015-05-21 Marek Polacek * c-typeck.c (inform_declaration): Use DECL_IS_BUILTIN instead of DECL_BUILT_IN. diff --git gcc/c/c-typeck.c g

[PATCH] Fix (ocvt (icvt@1 @0)) simplification (PR tree-optimization/66233)

Hi! We ICE on the following testcase at -O3 on x86_64-linux, because gimple folding attempts to simplify FLOAT_EXPR conversion of signed V4SI to V4SF feeding FIX_TRUNC_EXPR to unsigned V4SI into a FIX_TRUNC_EXPR with unsigned V4SI lhs and signed V4SI rhs1, which is invalid GIMPLE. All the other si

[RFA] Fix combine to canonicalize (mult X pow2)) more often

When combine needs to split a complex insn, it will canonicalize a simple (mult X (const_int Y)) where Y is a power of 2 into the expected (ashift X (const_int Y')) if the (mult ...) is selected as a split point. However if the split point is (plus (mult (X (const_int Y)) Z) combine fails to

Re: [PATCH] PR target/66224 _GLIBC_READ_MEM_BARRIER

On Wed, 2015-05-20 at 14:40 -0400, David Edelsohn wrote: > The current definition of _GLIBC_READ_MEM_BARRIER in libstdc++ is too > weak for an ACQUIRE FENCE, which is what it is intended to be. The > original code emitted an "isync" instead of "lwsync". > > All of the guard acquire and set code ne

v3 PATCH to avoid -Wsized-deallocation warnings with C++14 compiler

When GCC defaults to C++14, it gives -Wsized-deallocation warnings for the non-sized operator deletes. We dealt with this for the sized ones by passing -Wno-sized-deallocation on the command line, but using #pragma GCC diagnostic seems cleaner to me. Applying to trunk. commit 35cc1a3b6855a3e2

Re: RFA: PATCH to use -std=c++98 in stage 1 of bootstrap

On 05/20/2015 06:11 PM, Alexandre Oliva wrote: The only serious problem with the patch is that it changes Makefile.in, but not the corresponding part of Makefile.tpl from which it is generated. Ok with that change. Now, if you'd also update the comments just before it, that still suggest we bui

Re: [C++ PATCH] Minor fix for warn_args_num

On Thu, May 21, 2015 at 10:11:41AM -0400, Jason Merrill wrote: > On 05/21/2015 09:44 AM, Marek Polacek wrote: > >+ if (!DECL_BUILT_IN (fndecl)) > > I think you want DECL_IS_BUILTIN. OK with that change. Right. With DECL_IS_BUILTIN we print q.c:1:5: note: declared here int printf (const c

[PATCH][AArch64] Add __extension__ and __always_inline__ to crypto intrinsics

Hi all, The crypto intrinsics are missing an __extension__ and an __always_inline__ attribute that all the other intrinsics have. I don't see any reason for them to be different and the always_inline attribute will be needed if we decide to wrap the intrinsics inside a target SIMD pragma. Test

Re: [PATCH, fixincludes] AIX headers and extern "C"

OK. You might consider updating autogen. It seems 5.18 doesn't handle the version test quite right. Any 5.18.n should do fine. I guess I didn't test the version test with older versions. :) On Thu, May 21, 2015 at 6:58 AM, David Edelsohn wrote: > The AIX port of GCC is one of the few ports th

Re: PING^3: [PATCH]: New configure options that make the compiler use -fPIE and -pie as default option

"H.J. Lu" writes: > Here is the complete patch. Tested on Linux/x86-64. It is also > available on hjl/pie/master branch in git mirror. As always, please keep generated files like configure and config.in out of the submission: it simplifies review. diff --git a/gcc/Makefile.in b/gcc/Makefile.i

Re: [C++ PATCH] Minor fix for warn_args_num

On 05/21/2015 09:44 AM, Marek Polacek wrote: + if (!DECL_BUILT_IN (fndecl)) I think you want DECL_IS_BUILTIN. OK with that change. Jason

[PATCH, fixincludes] AIX headers and extern "C"

The AIX port of GCC is one of the few ports that does not define NO_IMPLICIT_EXTERN_C. A user reported a problem that we tracked to an AIX header that explicitly used C++ features (bracketed by #ifdef __cplusplus). AIX headers have included some C++ features, mostly protected by #if defined (__c

Re: Fix alignment propagation

Hi, I have not managed to ping this, get it approved and commit it in time for gcc 5 but it is a useful cleanup that clarifies a number of things and something I'd like to base further cleanups on. It still applies cleanly and I have re-tested and re-bootstrapped the patch on x86_64-linux without

[PATCH[2/n] Reduction vectorization improvements

This is part #2, fixes wrong-code because of bogus reduction op used and factors out common code (which I'd otherwise need to duplicate once more...). Bootstrap and regtest running on x86_64-unknown-linux-gnu. Richard. 2015-05-21 Richard Biener * tree-vect-loop.c (get_reduction_op):

Re: [RFA] Restore combine.c split point for multiply-accumulate instructions

On 05/21/2015 07:40 AM, Segher Boessenkool wrote: On Wed, May 20, 2015 at 11:38:44PM -0600, Jeff Law wrote: I've also verified this is one of the changes ultimately necessary to resolve the code generation regressions caused by Venkat's combine.c change on the PA across my 300+ testfiles for a P

[PATCH][1/n] Reduction vectorization improvements

I'm at the moment tearing apart a large patch that adds support for vectorizing reductions in basic-blocks as well as making loop vectorizing reduction chains with patterns work. This is a first piece - allow the reduction patterns be detected when reduction detection didn't run and remove an ass

Re: [gomp4] Vector-single predication

On Thu, May 21, 2015 at 02:38:19PM +0100, Julian Brown wrote: > > All functions will behave that way, or just some using some magic > > attribute etc.? Say will newlib functions behave this way (math > > functions, printf, ...)? > > It's actually unclear at this point if "regular" functions are

[C++ PATCH] Minor fix for warn_args_num

I've just noticed that we print "note: declared here" even for builtins. E.g.: void foo (void) { __builtin_return (); } q.cc: In function ‘void foo()’: q.cc:4:21: error: too few arguments to function ‘void __builtin_return(void*)’ __builtin_return (); ^ : note: declared

Re: [gomp4] Vector-single predication

On Thu, 21 May 2015 14:38:19 +0100 Julian Brown wrote: > On Thu, 21 May 2015 15:21:54 +0200 > Jakub Jelinek wrote: > > > On Thu, May 21, 2015 at 02:05:12PM +0100, Julian Brown wrote: > > > OpenACC handles function calls specially (calling them "routines" > > > -- of varying sorts, gang, worker,

Re: [RFA] Restore combine.c split point for multiply-accumulate instructions

On Wed, May 20, 2015 at 11:38:44PM -0600, Jeff Law wrote: > I've also verified this is one of the changes ultimately necessary to > resolve the code generation regressions caused by Venkat's combine.c > change on the PA across my 300+ testfiles for a PA cross compiler. How much does it help, do

Re: [gomp4] Vector-single predication

On Thu, 21 May 2015 15:21:54 +0200 Jakub Jelinek wrote: > On Thu, May 21, 2015 at 02:05:12PM +0100, Julian Brown wrote: > > OpenACC handles function calls specially (calling them "routines" > > -- of varying sorts, gang, worker, vector or seq, affecting where > > they can be invoked from). The pl

Re: [PATCH] PR target/66232: -fPIC -fno-plt -mx32 fails to generate indirect branch via GOT

On Thu, May 21, 2015 at 6:11 AM, Uros Bizjak wrote: > On Thu, May 21, 2015 at 2:59 PM, H.J. Lu wrote: >> X32 doesn't support indirect branch via 32-bit memory slot since >> indirect branch will load 64-bit address from 64-bit memory slot. >> Since x32 GOT slot is 64-bit, we should allow indirect

Re: [patch, libgomp] Re-factor GOMP_MAP_POINTER handling

On Thu, May 21, 2015 at 03:00:16PM +0200, Thomas Schwinge wrote: > Jakub, for avoidance of doubt, the proposed refactoring makes sense to > me, but does need your approval: This is ok for trunk. Jakub

[Ada] Allow constants in SPARK contracts

This patch permits constants to appear in the following SPARK annotations: Depends Global Initializes Part_Of Refined_Depends Refined_Global Refined_State -- Source -- -- legal_usage.ads package Legal_Usage with SPARK_Mode, Abstract_State

Re: [gomp4] Vector-single predication

On Thu, May 21, 2015 at 02:05:12PM +0100, Julian Brown wrote: > OpenACC handles function calls specially (calling them "routines" -- of > varying sorts, gang, worker, vector or seq, affecting where they can be > invoked from). The plan is that all threads will call such routines -- > and then some

[PATCH] Fix PR66211

The following papers over the C++ FE issue that it doesn't track lvalueness before folding stuff. Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk. Richard. 2015-05-21 Richard Biener PR c++/66211 * match.pd: Guard pattern optimzing (int)(float)int

Re: [PATCH, PR target/65103, 2/3] Propagate address constants into loops for i386

Ping 2015-05-05 14:05 GMT+03:00 Ilya Enkovich : > 2015-04-21 8:52 GMT+03:00 Jeff Law : >> On 04/17/2015 02:34 AM, Ilya Enkovich wrote: >>> >>> On 15 Apr 14:07, Ilya Enkovich wrote: 2015-04-14 8:22 GMT+03:00 Jeff Law : > > On 03/15/2015 02:30 PM, Richard Sandiford wrote: >> >>

Re: [PATCH] PR target/66232: -fPIC -fno-plt -mx32 fails to generate indirect branch via GOT

On Thu, May 21, 2015 at 2:59 PM, H.J. Lu wrote: > X32 doesn't support indirect branch via 32-bit memory slot since > indirect branch will load 64-bit address from 64-bit memory slot. > Since x32 GOT slot is 64-bit, we should allow indirect branch via GOT > slot for x32. > > I am testing it on x32.

  1   2   >