Re: [PATCH][AARCH64]PR60034

>> If I understand gcc/rtl.h correctly, SYMBOL_REF_ANCHOR_P (sym) is >> required for anchor SYMBOL_REFS. SYMBOL_REF_BLOCK (sym) != NULL is >> probably redundant. This can probably become an gcc_assert >> (SYMBOL_REF_BLOCK (sym)) instead. > > I agree with your interpretation of the code and commen

Re: C++ PATCHes to run testsuite in C++14 mode

On 03/24/2014 05:06 PM, Fabien Chêne wrote: 2014-03-07 22:43 GMT+01:00 Jason Merrill : The first patch changes the C++ testsuite to run in C++14 mode as well as C++98 and C++11. As a result, specifying { target c++11 } matches c++11 and c++1y mode. { target c++1y } matches c++1y only, and { ta

Re: [PATCH] Fix PR59626, _FORTIFY_SOURCE wrappers and LTO

> > Currently a _lot_ of packages fail to build with LTO because LTO > messes up fortify wrappers by replacing the call to the alias with > the symbol itself, making the wrapper look like infinitely > recursing. > > The following patch fixes this by dropping the bodies of > DECL_EXTERN always-inl

[Patch, Fortran] PR58880 - Fix ICE with finalizers

Hi all, this patch fixes a problem with the conversion of scalars to descriptors. There one assigns the address of the scalar to the base_address field of the descriptor. The ICE occurred when the RHS (the scalar) wasn't a pointer. It does not fully solve the PR as for some reasons the final

[Patch, Fortran] PR60576 Fix out-of-bounds problem

This patch fixes part of the problems of the PR. The problem is that one assigns an array descriptor to an assumed-rank array descriptor. The latter has for BT_CLASS the size of max_dim (reason: we have first the "data" array and than "vtab"). With "true", one takes the TREE_TYPE from the LHS (

[PATCH] Fix PR c++/60626

PR c++/60626 * parser.c (cp_parser_init_declarator): Handle erroneous generic type usage in non-functions with pushed scope. PR c++/60626 * g++.dg/cpp1y/pr60626.C: New testcase. --- gcc/cp/parser.c | 9 - gcc/testsuite/g++.dg/cp

Build *PING* Re: [Build, Driver] Add -lcilkrts for -fcilkplus

*PING* for the build part as the driver part has been already approved. http://gcc.gnu.org/ml/gcc-patches/2014-03/msg00492.html Also pinging another one-line libcilkrts/Makefile.am patch: http://gcc.gnu.org/ml/gcc-patches/2014-03/msg0.html On March 11, 2014, Tobias Burnus wrote: When using

Re: C++ PATCHes to run testsuite in C++14 mode

2014-03-07 22:43 GMT+01:00 Jason Merrill : > The first patch changes the C++ testsuite to run in C++14 mode as well as > C++98 and C++11. As a result, specifying { target c++11 } matches c++11 and c++1y mode. { target c++1y } matches c++1y only, and { target c++98 } matches c++98 only. Is that cor

Re: [RFC] Remove PUSH_ARGS_REVERSED from the RTL expander.

On 03/24/2014 06:23 AM, Michael Matz wrote: > I can't say why we have the !PUSH_ARGS_REVERSED path (so I guess that's > the way that initially was there, before the distinction was made), but > the PUSH_ARGS_REVERSED==1 path is important when you have push > instructions and arguments grow in th

Re: [PATCH] Fix PR c++/60573

On 2014-03-24 17:23, Jason Merrill wrote: On 03/18/2014 10:46 PM, Adam Butcher wrote: - while (scope->kind == sk_class -&& !TYPE_BEING_DEFINED (scope->this_entity)) Does it work to just change TYPE_BEING_DEFINED to currently_open_class? No. The object referred to by

Re: [PATCH] Update libstdc++ baseline_symbols.txt for {i?86,x86_64,s390,s390x,ppc,ppc64}-linux

On 24/03/14 20:20 +0100, Jakub Jelinek wrote: Hi! This patch updates baseline_symbols.txt to what I've grabbed from trunk builds as of today on various targets. Verified the additions are the same (just sizes of some objects double from 32-bit to 64-bit targets). In addition to that, it removes

std::rethrow_exception is broken

There is a lot of code in libsupc++/eh_* that relies on __cxa_exception and __cxa_dependent_exception having similar layouts, so tricks like this work: static inline void* __gxx_caught_object(_Unwind_Exception* eo) { // Bad as it looks, this actually works for dependent exceptions too. __cxa_e

Re: [RFC] Remove PUSH_ARGS_REVERSED from the RTL expander.

On Mon, Mar 24, 2014 at 11:54:49AM +, Richard Biener wrote: > On Mon, Mar 24, 2014 at 12:44 PM, James Greenhalgh > wrote: > > > > Hi, > > > > Consider this testcase: > > > > extern void foo (int a, int b, int c, int d); > > > > void > > bar (int b, int c, int d) > > { > > foo (3,

Re: [Patch, AArch64] Fix shuffle for big-endian.

On 02/21/2014 08:30 AM, Tejas Belagod wrote: > + /* If two vectors, we end up with a wierd mixed-endian mode on NEON. > */ > + if (BYTES_BIG_ENDIAN) > + { > + if (!d->one_vector_p && d->perm[i] & nunits) > + { > + /* Extract the offset. */ > + elt

Re: [RFA jit] initialize input_location

On Mon, 2014-03-24 at 05:29 -0600, Tom Tromey wrote: > > > "Dave" == David Malcolm > > writes: > > Dave> Given this declaration in input.c: > Dave> location_t input_location; > Dave> then assigning 0 is a faithful way of resetting it to its initial state. > > Dave> That said, "0" fee

Re: [C++ PATCH] Fix -std=c++11 OpenMP UDR handling (PR c++/60331)

On 03/18/2014 11:16 AM, Jakub Jelinek wrote: Jason, do you have better ideas how to fix this? Better would be to return false from potential_constant_expression_1 for DECL_EXPR; just add another case to the various _STMT tree codes. Jason

[PATCH, DOC] Mention -free enabled by default for -O2 and above on AArch64

Hi, -free has been enabled by default for -O2 and above on AArch64 a while ago. This patch updates the relevant part of user manual to reflect the fact. OK for stage-4? Thanks, Yufeng gcc/ * doc/invoke.texi (free): Document AArch64.diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke

Re: [Patch, AArch64] Fix shuffle for big-endian.

Further to that - all looks good after one-liner http://gcc.gnu.org/ml/gcc-patches/2014-03/msg01142.html has gone in. (Without that, enabling the code in Tejas' patch causes a regression in gcc.dg/torture/vshuf-v4hi.c as loading a vector constant goes wrong). I'll send a patch to enable this a

Re: [PATCH] BZ60501: Add addptr optab

> I agree with Vlad that we're better off with Andreas' patch than without, > since > computing addresses is going to be 99% of what reload/LRA needs to do. > > I also agree with Eric that some better commentary would be nice. Ok. I've applied the following patch. Bye, -Andreas- 2014-03-24 A

Re: [PATCH, PR 59176] Mark "zombie" call graph nodes to remove verifier false positive

> Hi, > > On Fri, Mar 21, 2014 at 09:40:39PM +0100, Jan Hubicka wrote: > > > On Thu, 20 Mar 2014, Martin Jambor wrote: > > > > > > > Hi, > > > > > > > > On Thu, Mar 20, 2014 at 07:40:56PM +0100, Jakub Jelinek wrote: > > > > > On Thu, Mar 20, 2014 at 05:07:32PM +0100, Martin Jambor wrote: > > > >

Re: [PATCH] Fix PR c++/60573

On 03/18/2014 10:46 PM, Adam Butcher wrote: - while (scope->kind == sk_class -&& !TYPE_BEING_DEFINED (scope->this_entity)) Does it work to just change TYPE_BEING_DEFINED to currently_open_class? Jason

Re: [C++ patch] for C++/52369

OK, thanks. Jason

[PATCH][ARM] Handle simple SImode PLUS and MINUS operations in rtx costs

Hi all, I noticed that we don't handle simple reg-to-reg arithmetic operations in the arm rtx cost functions. We should be adding the cost of alu.arith to the costs of the operands. This patch does that. Since we don't have any cost tables yet that have a non-zero value for that field it shoul

Re: [PATCH] Fix PR59626, _FORTIFY_SOURCE wrappers and LTO

> > Currently a _lot_ of packages fail to build with LTO because LTO > messes up fortify wrappers by replacing the call to the alias with > the symbol itself, making the wrapper look like infinitely > recursing. > > The following patch fixes this by dropping the bodies of > DECL_EXTERN always-inl

[PATCH][ARM] Handle FMA code in rtx costs.

Hi all, This patch adds proper rtx costing logic for floating point fma operations on arm. It also handles the fma+neg combinations that can be expressed with vfms,vfnma or vfnms instructions. Not much else to say here... Tested and boostrapped on arm-none-linux-gnueabihf. Ok for next stage1

Re: Disable accumulate-outgoing-args for Generic and Buldozers

On Thu, Jan 23, 2014 at 3:16 PM, Jan Hubicka wrote: >> > * config/i38/x86-tune.def: Disable X86_TUNE_ACCUMULATE_OUTGOING_ARGS >> > for generic and recent AMD chips >> >> The ChangeLog reads: >> >> 2014-01-22 Jan Hubicka >> >> * config/i386/x86-tune.def (X86_TUNE_ACCUMULATE_OUTGO

Re: [PATCH] PR debug/16063. Add DW_AT_type to DW_TAG_enumeration.

> gcc/cp/ > * dwarf2out.c (gen_enumeration_type_die): Add DW_AT_type if > enum_underlying_base_type defined and DWARF version > 3. > * langhooks.h (struct lang_hooks_for_types): Add > enum_underlying_base_type. > * langhooks-def.h (LANG_HOOKS_ENUM_UNDERLYING_

Re: [PATCH] Fix PR c++/60627

OK. Jason

Re: [PATCH, doc] Mention nds32*-*-elf in the target specific installation notes.

On Mon, 24 Mar 2014, Chung-Ju Wu wrote: > +2014-03-24 Chung-Ju Wu > + > + * doc/install.texi: Document nds32le-*-elf and nds32be-*-elf. Looks good to me. (The new patch avoids "elf" which I believe should have been "ELF", by the way.) Gerald

Re: [PATCH] x86: _mm512_set1_p[sd]

Hello! > Another set of functions missing are those to set all elements of a > 512-bit vector to the same float or double value. I think the patch > below uses the optimal code sequence for that. The patch requires the > previous patch introducing _mm*_undefined_*. > > > 2014-03-19 Ulrich Drepp

Re: [PATCH] x86: _mm*_undefined_* (for real)

Hello! 2014-03-19 Ulrich Drepper * config/i386/avxintrin.h (_mm256_undefined_si256): Define. (_mm256_undefined_ps): Define. (_mm256_undefined_pd): Define. * config/i386/emmintrin.h (_mm_undefined_si128): Define. (_mm_undefined_pd): Define. * conf

Re: [committed] Fix failure of gcc.dg/tree-prof/pr59003.c on hppa*-*-hpux*

John David Anglin writes: > I already tried it. dg-additional-options isn't supported in tree-prof. Shouldn't be hard to fix. Andreas. -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely diffe

Re: [PATCH, PR 59176] Mark "zombie" call graph nodes to remove verifier false positive

Hi, On Fri, Mar 21, 2014 at 09:40:39PM +0100, Jan Hubicka wrote: > > On Thu, 20 Mar 2014, Martin Jambor wrote: > > > > > Hi, > > > > > > On Thu, Mar 20, 2014 at 07:40:56PM +0100, Jakub Jelinek wrote: > > > > On Thu, Mar 20, 2014 at 05:07:32PM +0100, Martin Jambor wrote: > > > > > in the PR, veri

Re: [committed] Skip gcc.dg/torture/pr60092.c on 32-bit hpux

John David Anglin writes: > On 3/24/2014 2:45 AM, Rainer Orth wrote: >> John David Anglin writes: >> >>> Index: gcc.dg/torture/pr60092.c >>> === >>> --- gcc.dg/torture/pr60092.c(revision 208769) >>> +++ gcc.dg/torture/pr6009

Re: [committed] Skip gcc.dg/torture/pr60092.c on 32-bit hpux

On 3/24/2014 2:45 AM, Rainer Orth wrote: John David Anglin writes: Index: gcc.dg/torture/pr60092.c === --- gcc.dg/torture/pr60092.c(revision 208769) +++ gcc.dg/torture/pr60092.c(working copy) @@ -1,5 +1,6 @@ /* { dg-do r

Re: [committed] Fix failure of gcc.dg/tree-prof/pr59003.c on hppa*-*-hpux*

John David Anglin writes: > On 3/24/2014 2:48 AM, Rainer Orth wrote: >> John David Anglin writes: >> >>> Index: gcc.dg/tree-prof/pr59003.c >>> === >>> --- gcc.dg/tree-prof/pr59003.c (revision 208769) >>> +++ gcc.dg/tree-prof/pr

Re: [committed] Fix failure of gcc.dg/tree-prof/pr59003.c on hppa*-*-hpux*

On 3/24/2014 2:48 AM, Rainer Orth wrote: John David Anglin writes: Index: gcc.dg/tree-prof/pr59003.c === --- gcc.dg/tree-prof/pr59003.c (revision 208769) +++ gcc.dg/tree-prof/pr59003.c (working copy) @@ -1,6 +1,7 @@ /* PR targ

Please revert the patches in bug #54040 and #59346 and special case x32

In reply to the thread ending with: http://gcc.gnu.org/ml/gcc-patches/2013-11/msg02069.html and bugs: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54040 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59346 Changing s-osinte-posix.adb - tv_nsec => long (Long_Long_Integer (F * 10#1#E9))); + tv_nsec

Re: [RFC] Remove PUSH_ARGS_REVERSED from the RTL expander.

Hi, On Mon, 24 Mar 2014, Richard Biener wrote: > Maybe somebody remembers why we have both paths. I'd rather make > gimplification independent of this as well, choosing either variant. I can't say why we have the !PUSH_ARGS_REVERSED path (so I guess that's the way that initially was there, be

Re: [PATCH] x86: _mm512_set1_p[sd]

On Mon, Mar 24, 2014 at 01:33:11PM +0100, Richard Biener wrote: > On Mon, Mar 24, 2014 at 1:25 PM, Uros Bizjak wrote: > > Hello! > > > >> On Mon, Mar 24, 2014 at 12:13 PM, Ulrich Drepper wrote: > Your patch is correct IMHO, but maybe it worst to add all missing > `mm512_set1*' stuff? >

Re: [PATCH] x86: _mm512_set1_p[sd]

On Mon, Mar 24, 2014 at 1:25 PM, Uros Bizjak wrote: > Hello! > >> On Mon, Mar 24, 2014 at 12:13 PM, Ulrich Drepper wrote: Your patch is correct IMHO, but maybe it worst to add all missing `mm512_set1*' stuff? According to trunk and [1] we're still missing (beside mentioned by

Re: [PATCH] x86: _mm512_set1_p[sd]

Hello! > On Mon, Mar 24, 2014 at 12:13 PM, Ulrich Drepper wrote: >>> Your patch is correct IMHO, but maybe it worst to add all missing >>> `mm512_set1*' stuff? >>> >>> According to trunk and [1] we're still missing (beside mentioned by you) >>> _mm512_set1_epi16 and _mm512_set1_epi8 broadcasts.

Re: [PATCH, doc] Add myself as NDS32 port contributor in the documentation.

On Mon, 24 Mar 2014, Chung-Ju Wu wrote: > I would like to add an item to describe myself as nds32 port contributor. > The plaintext ChangeLog and patch are as below. > Bootstrapped and the webpage can be successfully built via 'make html'. > > Is it OK for trunk? > +2014-03-24 Chung-Ju Wu > +

Re: [AArch64] Logical vector shift right conformance

On Thu, Mar 20, 2014 at 12:59:27PM +, Marcus Shawcroft wrote: > On 25 February 2014 11:58, Alex Velenko wrote: > > Hi, > > > > This patch fixes a bug in vshr_n_u64 and vshrd_n_u64 intrinsic > > behavior in case of shift by 64. Shift by 64 is strictly defined in ACLE to > > use ushr instruction

Re: [RFC] Remove PUSH_ARGS_REVERSED from the RTL expander.

On Mon, Mar 24, 2014 at 12:44 PM, James Greenhalgh wrote: > > Hi, > > Consider this testcase: > > extern void foo (int a, int b, int c, int d); > > void > bar (int b, int c, int d) > { > foo (3, b, c, d); > } > > For many ABI's we will have on entry to the function > > r0 = b >

Re: [Fortran][PATCH][gomp4]: Transform OpenACC loop directive

Hi Tobias! Thanks a lot for your review! I fixed my patch. On 20.03.2014 00:16, Tobias Burnus wrote: * !$acc cache() - parsing supported, but then aborting with a not-implemented error * OpenACC 2.0a additions. Am I right? Not exactly, in addition to cache directive there are also subarra

[RFC] Remove PUSH_ARGS_REVERSED from the RTL expander.

Hi, Consider this testcase: extern void foo (int a, int b, int c, int d); void bar (int b, int c, int d) { foo (3, b, c, d); } For many ABI's we will have on entry to the function r0 = b r1 = c r2 = d If we process arguments to the call to foo left-to-right (PUSH_ARGS_R

Re: [PATCH AArch64] Fix aarch64_simd_valid_immediate for Bigendian

On 21 March 2014 14:55, Alan Lawrence wrote: > This patch fixes a bug whereby a vector like V8QImode {1,0,1,0,1,0,1,0} can > result in an instruction like > > movi v1.4h, 0x1 > > whereas on bigendian this should be > > movi v1.4h, 0x1, lsl 8 > > Regression tested on aarch64_be-none-elf: no changes

Re: [RFA jit] initialize input_location

> "Dave" == David Malcolm > writes: Dave> Given this declaration in input.c: Dave> location_t input_location; Dave> then assigning 0 is a faithful way of resetting it to its initial state. Dave> That said, "0" feels like a magic number. Would it better to assign Dave> UNKNOWN_LOCATIO

Re: [PATCH] x86: _mm512_set1_p[sd]

On Mon, Mar 24, 2014 at 12:13 PM, Ulrich Drepper wrote: > On Mon, Mar 24, 2014 at 1:50 AM, Kirill Yukhin > wrote: >> Your patch is correct IMHO, but maybe it worst to add all missing >> `mm512_set1*' stuff? >> >> According to trunk and [1] we're still missing (beside mentioned by you) >> _mm512_

[PATCH, ARM] Enable tail call optimization for long call

This patch enables tail call optimization for long call on arm. Previously we have too strict check on arm_function_ok_for_sibcall and be lack of the support on sibcall/sibcall_value expand that long call tail oppportunities are lost. OK for next next stage 1? thanks. -- Jiong gcc/ * conf

Re: [PATCH] x86: _mm*_undefined_* (for real)

On Mon, Mar 24, 2014 at 2:31 AM, Kirill Yukhin wrote: > If list of missing intrinsics is big - maybe you could share it? I can > help you implementing it. So far only the set1 intrinsics. I'll see whether I can spot more. > In general, I think _undefined idea is correct and the patch is doing

Re: [PATCH] x86: _mm512_set1_p[sd]

On Mon, Mar 24, 2014 at 1:50 AM, Kirill Yukhin wrote: > Your patch is correct IMHO, but maybe it worst to add all missing > `mm512_set1*' stuff? > > According to trunk and [1] we're still missing (beside mentioned by you) > _mm512_set1_epi16 and _mm512_set1_epi8 broadcasts. Yes, more are missing

Re: [AArch64 testsuite] Make vect-abs.c C99 compliant

On 24/03/14 10:00, James Greenhalgh wrote: *ping* Jakub pointed out to me recently that obvious patches are OK even in Stage 4, so if I don't hear any objections in 24 hours, I'll push this. Thanks, James OK /Marcus

Re: [PATCH] PR debug/16063. Add DW_AT_type to DW_TAG_enumeration.

On Mon, 2014-03-24 at 10:26 +0100, Richard Biener wrote: > On Sun, Mar 23, 2014 at 12:18 PM, Mark Wielaard wrote: > > Add a new lang-hook that provides the underlying base type of an > > ENUMERAL_TYPE. Including implementations for C and C++. Use this > > enum_underlying_base_type lang-hook in dwa

Re: [PATCH, doc] Mention nds32*-*-elf in the target specific installation notes.

2014-03-24 14:52 GMT+08:00 Rainer Orth : > Chung-Ju Wu writes: > >> +@anchor{nds32x-x-elf} >> +@heading nds32*-*-elf >> +Andes NDS32 target. >> + >> +Use @samp{configure --target=nds32le-elf --enable-languages=c,c++} to >> configure >> +GCC@ for building a nds32 elf cross-compiler in little endia

Re: [4.8, PATCH 4/26] Backport Power8 and LE support: Libtool and configure bits 2

On Wed, 19 Mar 2014, Bill Schmidt wrote: > Hi, > > This patch (diff-le-libtool) backports changes to use a libtool.m4 that > supports powerpc64le-*linux*. Ok. Thanks, Richard. > Thanks, > Bill > > > 2014-03-19 Bill Schmidt > > Backport from mainline > 2013-11-22 Ulrich Weiga

Re: [4.8, PATCH 3/26] Backport Power8 and LE support: Configury bits 1

On Wed, 19 Mar 2014, Bill Schmidt wrote: > Hi, > > This patch (diff-le-config) backports updates to more recent > config.guess and config.sub versions to support the new powerpc64le > target. This is fine. Thanks, Richard. > Thanks, > Bill > > > 2014-03-29 Bill Schmidt > > Backport

[PATCH] Fix PR59626, _FORTIFY_SOURCE wrappers and LTO

Currently a _lot_ of packages fail to build with LTO because LTO messes up fortify wrappers by replacing the call to the alias with the symbol itself, making the wrapper look like infinitely recursing. The following patch fixes this by dropping the bodies of DECL_EXTERN always-inline functions on

Re: [AArch64 testsuite] Make vect-abs.c C99 compliant

*ping* Jakub pointed out to me recently that obvious patches are OK even in Stage 4, so if I don't hear any objections in 24 hours, I'll push this. Thanks, James On Tue, Feb 18, 2014 at 12:35:17PM +, James Greenhalgh wrote: > > Hi, > > This test fails on a linux build because it tries to u

Re: [4.8, PATCH 0/26] Backport Power8 and LE support

Hi Bill, On 21 Mar 2014, at 02:05, Bill Schmidt wrote: > For convenience of those who have kindly agreed to test the patch > series, here is the entire series as a single compressed patch. Note > that this does not include patch 15/26, which we've agreed to submit > separately. To assess this o

Re: [PATCH] Environment variables forwarding

Adding Dejagnu list this time. On 03/24/2014 12:28 PM, Maxim Ostapenko wrote: Hi all, When porting Lsan on arm, I ran into problem with testing, because almost all lsan tests require environment variables forwarding for remote targets. Unfortunately, this feature isn't implemented yet neithe

Re: [PATCH] Make some ubsan tests more robust

On Mon, Mar 24, 2014 at 10:37:46AM +0100, Marek Polacek wrote: > dg-output as it stands can't be used in a negate form, that is we can't > check that no output was produced. This is needed for ubsan: there > are testcases that when run should issue no output at all. We can, > however, use this re

[PATCH] Make some ubsan tests more robust

dg-output as it stands can't be used in a negate form, that is we can't check that no output was produced. This is needed for ubsan: there are testcases that when run should issue no output at all. We can, however, use this really ugly hack, where we output some fake stuff at the beginning and at

Re: [PATCH][AARCH64]combine "ubfiz" and "orr" with bfi when certain condition meets.

On 17/03/14 10:27, Richard Earnshaw wrote: On 16/03/14 12:30, Renlin Li wrote: Hi all, Thank you for your suggestions, Richard. I have updated the patch accordingly. This is an optimization patch which will combine "ubfiz" and "orr" insns with a single "bfi" when certain conditions meet. tmp

Re: Fix PR rtl-optimization/60452

On Sun, Mar 23, 2014 at 1:02 PM, Eric Botcazou wrote: > This is a regression present on mainline and 4.8 branch: ifcvt generates a > conditional move from an invalid location on the stack, resulting in a > segfault at runtime. The testcase is pathological and exploits the very old > RTL semantics

Re: [PATCH] PR debug/16063. Add DW_AT_type to DW_TAG_enumeration.

On Sun, Mar 23, 2014 at 12:18 PM, Mark Wielaard wrote: > Add a new lang-hook that provides the underlying base type of an > ENUMERAL_TYPE. Including implementations for C and C++. Use this > enum_underlying_base_type lang-hook in dwarf2out.c to add a DW_AT_type > base type reference to a DW_TAG_en

Re: LTO / invoke.texi: Add some words about static libraries and LTO

On Sat, Mar 22, 2014 at 3:36 PM, Tobias Burnus wrote: > Mention gcc-ar, gcc-ranlib, gcc-nm in the documentation. > > OK? Ok. Thanks, Richard. > Tobias >

Re: [PATCH] LeakSanitizer testsuite

On Thu, Mar 20, 2014 at 10:22:38AM +0400, Maxim Ostapenko wrote: > Hi, > > This patch adds initial set of tests and dg infrastructure for > LeakSanitizer runtime. > > Tested on x86_64. > > Ok to commit? Are you sure we need testsuite for something that doesn't have a GCC code generation counter

[PATCH] Environment variables forwarding

Hi all, When porting Lsan on arm, I ran into problem with testing, because almost all lsan tests require environment variables forwarding for remote targets. Unfortunately, this feature isn't implemented yet neither in Dejagnu nor in GCC. These two small patches seem to resolve this issue.