Re: [PATCH] target/58065 ARM MALLOC_ABI_ALIGNMENT is wrong

On 08/07/13 08:10, Bernd Edlinger wrote: Hello, in the discussion about the PR middle-end/57748 it became obvious that the ARM target architecture should define a value for MALLOC_ABI_ALIGNMENT, because otherwise the default is simply word aligned, which causes sub-optimal code, at least for

[PING][PATCH ARM]Extend thumb1_reorg to save more comparison instructions

Ping this patch, http://gcc.gnu.org/ml/gcc-patches/2013-04/msg01057.html Thanks. bin

RE: [PATCH][tree-optimization] Fix PR58088

> Ok for trunk? > > Bootstrapped on x86_64-linux-gnu and tested arm-none-eabi on qemu. > > > Thanks, > Kyrill > * gcc.c-torture/compile/pr58088.c: New test. Also, the ChangeLog entries should be: 2013-08-08 Kyrylo Tkachov PR tree-optimization/58088 * gcc/fold-const.c

[Ping] Re: [PATCH, ARM] Fix unrecognizable vector comparisons

Ping? Is it OK for 4.8 and trunk? Thanks! -Zhenqiang On 1 August 2013 10:04, Zhenqiang Chen wrote: > Thank you all for the comments. The patch is updated as: > 1) Revert it to the original one. > 2) For the testcase, replace the dg-options with > /* { dg-do compile } */ > /* { dg-require-effecti

Re: [PATCH, ARM] Fix unrecognizable vector comparisons

On 08/01/13 03:04, Zhenqiang Chen wrote: Thank you all for the comments. The patch is updated as: 1) Revert it to the original one. 2) For the testcase, replace the dg-options with /* { dg-do compile } */ /* { dg-require-effective-target arm_neon } */ /* { dg-add-options arm_neon } */ /* { dg-opt

Re: [PATCH][tree-optimization] Fix PR58088

> Also, the ChangeLog entries should be: > > 2013-08-08 Kyrylo Tkachov > > PR tree-optimization/58088 > * gcc/fold-const.c (mask_with_trailing_zeros): New function. > (fold_binary_loc): Make sure we don't recurse infinitely > when the X in (X & C1) | C2 is a tree of the

Re: [buildbot] r201508: Build failures after pass C++ conversion

> Sorry. How does the attached look? (am bootstrapping now) Thanks for devising the patch. However, we are in the process of fixing the issue on the Ada side so please do not apply it for now. -- Eric Botcazou

Re: [Patch] Whole regex refactoring and current status

Tim Shen writes: > As metioned in this[1] email, I here propose a refactored version of > regex, and show the status: This patch broke Solaris bootstrap: In file included from /usr/include/ctype.h:18:0, from /var/gcc/regression/trunk/10-gcc-gas/build/i386-pc-solaris2.10/libstd

RE: [Patch] Whole regex refactoring and current status

> -Original Message- > From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches- > ow...@gcc.gnu.org] On Behalf Of Rainer Orth > Sent: 08 August 2013 11:02 > To: Tim Shen > Cc: libstdc++; gcc-patches > Subject: Re: [Patch] Whole regex refactoring and current status > > Tim Shen writes: >

Re: [Patch] Whole regex refactoring and current status

Hi, >This is already documented: > >http://gcc.gnu.org/onlinedocs/libstdc++/manual/source_code_style.html#coding_style.bad_identifiers Indeed. As a simple to remember rule never use single underscore + single uppercase. Usually we add a p, like _Cp, etc. Plenty of examples everywhere. At the

Re: [PATCH/Merge Request] Vtable Verification feature.

Caroline, your libgcc ChangeLog entries are all broken: they lack the initial "* " as can easily be seen in Emacs' Change Log Mode. Please fix. As an aside, I had a very quick look at libvtv to determine what's required for a port to a non-Linux platform. It would be good if the requirements (c

Re: [PATCH/Merge Request] Vtable Verification feature.

Hi Caroline, On 8 Aug 2013, at 11:27, Rainer Orth wrote: > > As an aside, I had a very quick look at libvtv to determine what's > required for a port to a non-Linux platform. Likewise.. > It would be good if the > requirements (currently, ELF, dl_iterate_phdr, __fortify_fail, certainly > sever

Re: [PATCH, i386, MPX 1/X] Support of Intel MPX ISA

2013/8/8 Joseph S. Myers : > On Fri, 2 Aug 2013, Ilya Enkovich wrote: > >> Hi All, >> >> I've updated MPX Wiki page >> (http://gcc.gnu.org/wiki/Intel%20MPX%20support%20in%20the%20GCC%20compiler). >> I added instrumentation description, programming model description, >> differences with other checke

Re: PING: Re: [patch] implement simd loops in trunk (OMP_SIMD)

+ hash_table simduid_to_vf_htab; + hash_table decl_to_simduid_htab; Why two hashes? Seems like you can map from decl to vf directly. At what point do you have a simduid integer, but not the decl from whence it came? decl_to_simduid seems to be a misnomer. What it really is, is a "omp

Re: [PATCH, i386, MPX 1/X] Support of Intel MPX ISA

2013/8/8 Ilya Enkovich : > 2013/8/8 Joseph S. Myers : >> On Fri, 2 Aug 2013, Ilya Enkovich wrote: >> >>> Hi All, >>> >>> I've updated MPX Wiki page >>> (http://gcc.gnu.org/wiki/Intel%20MPX%20support%20in%20the%20GCC%20compiler). >>> I added instrumentation description, programming model description

Re: [Patch] Whole regex refactoring and current status

Hi Paolo, >>This is already documented: >> >>http://gcc.gnu.org/onlinedocs/libstdc++/manual/source_code_style.html#coding_style.bad_identifiers > > Indeed. As a simple to remember rule never use single underscore + single > uppercase. Usually we add a p, like _Cp, etc. Plenty of examples > everywh

Re: [Patch] Whole regex refactoring and current status

Hi, >I wasn't certain about the right convention. The following patch >allowed bootstrap to finish on i386-pc-solaris2.10 and >x86_64-unknown-linux-gnu. I'll commit the patch once Solaris testing >has finished. Thanks a lot. >E.g. the first one is > >FAIL: 28_regex/algorithms/regex_match/bas

Re: [PATCH/Merge Request] Vtable Verification feature.

On 08/06/13 22:39, Benjamin De Kosnik wrote: +# Filter out unsupported systems. +case "${target}" in + x86_64-*-linux* | i?86-*-linux*) + VTV_SUPPORTED=yes + ;; + powerpc*-*-linux*) + ;; + sparc*-*-linux*) + ;; + arm*-*-linux*) + ;; What about powerpc, sparc and arm? Why are they mention

RE: [Patch] Whole regex refactoring and current status

> Hi Paolo, > > >>This is already documented: > >> > >>http://gcc.gnu.org/onlinedocs/libstdc++/manual/source_code_style.html#c > oding_style.bad_identifiers > > > > Indeed. As a simple to remember rule never use single underscore + > single > > uppercase. Usually we add a p, like _Cp, etc. Plenty

[PATCH, ARM] Fix handling of function arguments with excess alignment

PR target/56979 is a bug where a parameter to a function has an alignment that is larger than its natural alignment. In this case this causes the mid-end to generate a mode for the argument that is incompatible with the registers that are assigned for it. We then end up creating invalid RTL and s

[PATCH, ARM] Fix ICE when using Neon vld1_dup_[su]64()

PR 57431 is an ICE when compiling for Neon intrinsics. For completeness vld1_dup_u64 is defined to fill a single element vector from a single element of data, but this is in reality degenerate. Unfortunately, by expanding this into a vec_duplicate operation we confuse the mid-end of the compiler,

Re: [Patch] Whole regex refactoring and current status

On Thu, Aug 8, 2013 at 8:53 PM, Paolo Carlini wrote: > Tim, please address this ASAP, otherwise we have to revert the whole thing. I'm trying to reproduce the compilation failures. -- Tim Shen

Re: [Patch] Whole regex refactoring and current status

On Thu, Aug 8, 2013 at 10:04 PM, Tim Shen wrote: > On Thu, Aug 8, 2013 at 8:53 PM, Paolo Carlini > wrote: >> Tim, please address this ASAP, otherwise we have to revert the whole thing. > > I'm trying to reproduce the compilation failures. There's a typedef in regex_constants.h: `typedef unsign

Symtab cleanups 10/17 - ipa ref verifier

Hi, this patch implements (very basic) IPA REF verifier. It only checks if all references corresopnds to a real statement. It does not yet check if all statements have proper references attached to them. Even this simple testing found quite few positives where we leave stale references in callg

Re: [buildbot] r201508: Build failures after pass C++ conversion

> This break Ada. Fixed thusly, bootstrapped and regtested on x86_64-suse-linux, applied. 2013-08-08 Eric Botcazou * gcc-interface/Makefile.in (TOOLS_LIBS): Pick C object files from the compiler build and use standard library variables. (../../vxaddr2line$(exeext): Do

Re: [buildbot] r201508: Build failures after pass C++ conversion

On Thu, 2013-08-08 at 16:36 +0200, Eric Botcazou wrote: > > This break Ada. > > Fixed thusly, bootstrapped and regtested on x86_64-suse-linux, applied. Thanks; sorry again about the breakage.

[PATCH][ARM] FAIL: gcc.target/arm/pr58041.c scan-assembler ldrb

Hi all, The recently added gcc.target/arm/pr58041.c test exposed a bug in the backend. When compiling for NEON and with -mno-unaligned-access we end up generating the vld1.64 and vst1.64 instructions instead of doing the accesses one byte at a time like -mno-unaligned-access expects. This patch fi

Re: [buildbot] r201508: Build failures after pass C++ conversion

On Thu, 2013-08-08 10:43:53 -0400, David Malcolm wrote: > On Thu, 2013-08-08 at 16:36 +0200, Eric Botcazou wrote: > > > This break Ada. > > > > Fixed thusly, bootstrapped and regtested on x86_64-suse-linux, applied. > > Thanks; sorry again about the breakage. Build Robot (http://toolchain.lug-o

Re: [Patch, Fortran] PR 58058: [4.7/4.8/4.9 Regression] Memory leak with transfer function

ping! 2013/8/3 Janus Weil : > Hi all, > > the attached patch plugs a memory leak of the TRANSFER intrinsic, > which can occur when transferring to CHARACTER strings. For details > see the PR. > > Regtested on x86_64-unknown-linux-gnu. Ok for trunk/4.8/4.7? > > Cheers, > Janus > > > 2013-08-03 Jan

Re: [Patch] Whole regex refactoring and current status

Hi, >There's a typedef in regex_constants.h: > >`typedef unsigned int syntax_option_type;` > >Which is a little bit naive. It possibly conflicts with size_t under >i386 when overloading. I'm trying to change it to a bitset. Or is >there any better solution? In my humble opinion involving the wh

Re: New parameters to control stringop expansion libcall strategy

On Wed, 7 Aug 2013, Xinliang David Li wrote: > Updated patch attached (fixed header, buffer overflow, and warning --> > error problems). You still have diagnostics starting with a capital letter, contrary to the GNU Coding Standards. -- Joseph S. Myers jos...@codesourcery.com

Re: [Patch] Whole regex refactoring and current status

On Thu, Aug 8, 2013 at 11:14 PM, Paolo Carlini wrote: > In my humble opinion involving the whole std::bitset container for a syntax > option is way overkill. Do you really have to do overloading between size_t > and that type? Or maybe you can use a type *smaller* than unsigned int. The n3376 s

Re: [PATCH, i386, MPX 1/X] Support of Intel MPX ISA

On Thu, 8 Aug 2013, Ilya Enkovich wrote: > > That is not a big issue to rename generic names. But I'm just still > > trying to choose proper names. I looked into -fbounds-check but its > > description already mention C/C++ and its semantics differs from what > > new instrumentation does. I conside

Re: [PATCH/Merge Request] Vtable Verification feature.

On Thu, 8 Aug 2013, Ramana Radhakrishnan wrote: > I spent some time this morning looking into what it would take to enable this > for arm*-*-linux* today and the first thing that I noticed is that the > testsuite is essentially driven by a shell script that caters to native > testing on the only p

Re: [Patch] Whole regex refactoring and current status

Paolo Carlini writes: > In my humble opinion involving the whole std::bitset container for a > syntax option is way overkill. It's already used for match_flag_type anyway. Andreas. -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA

Re: Request to merge Undefined Behavior Sanitizer in

On Fri, 26 Jul 2013, Marc Glisse wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57324 > (that is using llvm's sanitizer) > > and for a first patch (unreviewed): > > http://gcc.gnu.org/ml/gcc-patches/2013-06/msg01466.html > (started at http://gcc.gnu.org/ml/gcc-patches/2013-05/msg01402.html

Re: [PATCH] Add vtable verification feature announcement to news on main page...

On 07/08/13 18:19, Caroline Tice wrote: > As requested, here is the patch to announce the vtable verification > feature on the main gcc.gnu.org web page. Is this ok to commit? > Please don't put this in until the issues that the patch have introduced have been resolved. R.

Re: [Patch] Whole regex refactoring and current status

Hi, >So flag_type shall not be the same as size_t. I don't know if when I >switch flag_type from unsigned int to, say, unsigned short, conflicts >will appear in 16bit archtectures. Well 16-bit archs aren't really supported these days, as long as the c++ runtime is concerned. Thus if unsigned s

Re: [Patch] Whole regex refactoring and current status

Hi, >> In my humble opinion involving the whole std::bitset container for a >> syntax option is way overkill. > >It's already used for match_flag_type anyway. Indeed, I noticed it a few days ago, and seemed overkill ;) Really, we already have implementation experience about these flags, eg in

Re: [PATCH/Merge Request] Vtable Verification feature.

On Thu, Aug 8, 2013 at 5:55 AM, Ramana Radhakrishnan wrote: > On 08/06/13 22:39, Benjamin De Kosnik wrote: >> >> +# Filter out unsupported systems. +case "${target}" in + x86_64-*-linux* | i?86-*-linux*) + VTV_SUPPORTED=yes + ;; + powerpc*-*-linux*) + ;; +

Re: New parameters to control stringop expansion libcall strategy

Updated. thanks, David On Thu, Aug 8, 2013 at 8:18 AM, Joseph S. Myers wrote: > On Wed, 7 Aug 2013, Xinliang David Li wrote: > >> Updated patch attached (fixed header, buffer overflow, and warning --> >> error problems). > > You still have diagnostics starting with a capital letter, contrary to

Re: [PATCH/Merge Request] Vtable Verification feature.

On Thu, Aug 8, 2013 at 3:27 AM, Rainer Orth wrote: > Caroline, > > your libgcc ChangeLog entries are all broken: they lack the initial "* " > as can easily be seen in Emacs' Change Log Mode. > > Please fix. > Wow, I'm really sorry about that! I don't know how that happened. I'll fix it immediat

Re: PING: Re: [patch] implement simd loops in trunk (OMP_SIMD)

On 08/08/2013 02:06 AM, Aldy Hernandez wrote: > The hash is not really mapping the simd DECL to the simduid, since that's just > a matter of DECL_UID(simduid), but the OMP simd array to the index used to > reference it (simduid), like thus: > > _7 = GOMP_SIMD_LANE (simduid.0) > ...

Re: [PATCH][ARM] FAIL: gcc.target/arm/pr58041.c scan-assembler ldrb

On 08/08/13 15:44, Kyrylo Tkachov wrote: Hi all, The recently added gcc.target/arm/pr58041.c test exposed a bug in the backend. When compiling for NEON and with -mno-unaligned-access we end up generating the vld1.64 and vst1.64 instructions instead of doing the accesses one byte at a time like -

Re: [Patch] Whole regex refactoring and current status

On Fri, Aug 9, 2013 at 12:15 AM, Paolo Carlini wrote: > Indeed, I noticed it a few days ago, and seemed overkill ;) Really, we > already have implementation experience about these flags, eg in iostream, and > I dont think we want std::bitset everywhere. So here's the change. It's under testing

Re: [PING] [PATCH, AArch64] Skip gcc.dg/lower-subreg-1.c

Ping~ Thanks, Yufeng On 07/26/13 12:06, Yufeng Zhang wrote: Hi, This patch changes to skip gcc.dg/lower-subreg-1.c for aarch64*-*-*. The word mode in aarch64 is 64-bit so the lower-subreg pass won't happen in this test case. The test is currently skipped on aarch64 with lp64 due to the direct

Re: [Patch] Whole regex refactoring and current status

On 08/08/2013 06:51 PM, Tim Shen wrote: On Fri, Aug 9, 2013 at 12:15 AM, Paolo Carlini wrote: Indeed, I noticed it a few days ago, and seemed overkill ;) Really, we already have implementation experience about these flags, eg in iostream, and I dont think we want std::bitset everywhere. So h

Re: [C++ Patch / RFC] PR 46206

I'm now seeing a new testsuite failure: FAIL: g++.dg/lookup/typedef2.C -std=c++98 (test for excess errors) Excess errors: /nasfarm/edelsohn/src/src/gcc/testsuite/g++.dg/lookup/typedef2.C:8:12: error: using typedef-name 'Foo1::Bar' after 'struct' /nasfarm/edelsohn/src/src/gcc/testsuite/g++.dg/looku

Re: [C++ Patch / RFC] PR 46206

On 08/08/2013 07:35 PM, David Edelsohn wrote: I'm now seeing a new testsuite failure: FAIL: g++.dg/lookup/typedef2.C -std=c++98 (test for excess errors) Excess errors: /nasfarm/edelsohn/src/src/gcc/testsuite/g++.dg/lookup/typedef2.C:8:12: error: using typedef-name 'Foo1::Bar' after 'struct' /nas

Re: [C++ Patch / RFC] PR 46206

Why does the patch and fix have any architecture or OS-dependency? - David On Thu, Aug 8, 2013 at 1:57 PM, Paolo Carlini wrote: > On 08/08/2013 07:35 PM, David Edelsohn wrote: >> >> I'm now seeing a new testsuite failure: >> >> FAIL: g++.dg/lookup/typedef2.C -std=c++98 (test for excess errors) >

Re: [C++ Patch / RFC] PR 46206

On 08/08/2013 08:18 PM, David Edelsohn wrote: Why does the patch and fix have any architecture or OS-dependency? It's tricky, but it depends on the way are internally stored and handled *multiple* TYPE_DECL for essentially the same typedef. The class layout must involve both such typedef and a

Re: [PATCH/Merge Request] Vtable Verification feature.

arm*-*-linux* is broken currently for what looks like the same reasons as the powerpc port. Have you tried Benjamin Kosnik's patch? Does it fix the problem? I hadn't but that seems to have fixed the issue. Thanks. I spent some time this morning looking into what it would take to enabl

Re: [patch, mips] Add nan2008 multilibs to mips-mti-* targets.

"Steve Ellcey " writes: > I would like to add new variations to the mips-mti-elf and mips-mti-linux > targets to support the new NaN format on MIPS (mnan=2008 for IEEE 754-2008). > While I was doing this I noticed that I was handling mips16 and micromips > in a dumb manner. I had them in MULTILIB

Re: PING: Re: [patch] implement simd loops in trunk (OMP_SIMD)

On 08/08/13 18:42, Richard Henderson wrote: On 08/08/2013 02:06 AM, Aldy Hernandez wrote: The hash is not really mapping the simd DECL to the simduid, since that's just a matter of DECL_UID(simduid), but the OMP simd array to the index used to reference it (simduid), like thus: _7 = GO

Re: [C++ Patch / RFC] PR 46206

On 08/08/2013 08:31 PM, Paolo Carlini wrote: On 08/08/2013 08:18 PM, David Edelsohn wrote: Why does the patch and fix have any architecture or OS-dependency? It's tricky, but it depends on the way are internally stored and handled *multiple* TYPE_DECL for essentially the same typedef. The clas

[C++ RFC / Patch] PR 54080, PR 52875 and more (aka SFINAE vs template recursion depth)

Hi, this is, IMHO, a rather interesting issue. I was working on PR 54080, where currently with ICE pretty badly for Error reporting routines re-entered without producing any sensible error message. Figured out that the core of the issue are the error messages in push_tinst_level about templat

patch for correct mode use by LRA for save/restore generation

The following patch implements correct mode use for save/restore generation. The patch was successfully bootstrapped and tested on x86/x86-64, ppc64, s390. The patch also makes some tuning in alternative matching and adds more debugging printing. Committed as rev. 201611. 2013-08-08 Vladi

[patch][PR/42955] Don't install $(target)/bin/gcc, gfortran, etc.

As discussed in PR/42955, when GCC is built as a cross-compiler, it will install "gcc", "g++", "c++", and "gfortran" binaries in $(target)/bin, as well as installing the $target-gcc and so forth in bin. However, these binaries in $(target)/bin do not work; they cannot find libexec. More to the po

[PATCH, vtv update] Add documentation for --enable-vtable-verify configure option...

The attached patch adds documentation for the --enable-vtable-verify configure option to install.texi. Is this ok to commit? -- Caroline TIce cmt...@google.com 2013-08-08 Caroline Tice * doc/install.texi: Add documentation for the --enable-vtable-verify configure option. v

[PATCH, vtv update] Fix /tmp directory issues in libvtv

This patch changes where the logging file mechanism in libvtv tries to write its log files. Instead of trying to use /tmp, it now first looks for an environment variable "VTV_LOGS_DIR". If it can't find that it looks for the environment variable "HOME". If it can't find that either, it uses the

Re: [PATCH, vtv update] Add documentation for --enable-vtable-verify configure option...

On Thu, 8 Aug 2013, Caroline Tice wrote: > The attached patch adds documentation for the --enable-vtable-verify > configure option to install.texi. Is this ok to commit? Could you please answer the questions I raised in the first four paragraphs of

[PATCH, vtv update] Change fixed size array to a vector; fix diagnostic messages.

This patch replaces the fixed sized array that was holding vtable pointers for a particular class hierarchy with a vector, allowing for dynamic resizing. It also fixes issues with the warning diagnostics. I am in the process of running regression tests with this patch; assuming they all pass, is t

Re: [PATCH, vtv update] Fix /tmp directory issues in libvtv

On Aug 8, 2013, at 3:09 PM, Caroline Tice wrote: > This patch changes where the logging file mechanism in libvtv tries to > write its log files. Instead of trying to use /tmp, it now first > looks for an environment variable "VTV_LOGS_DIR". If it can't find > that it looks for the environment va

Re: [FIXED] Generic lambda symbol table bug

On 07.08.2013 20:56, Adam Butcher wrote: On 07.08.2013 16:59, Jason Merrill wrote: On 08/07/2013 03:52 AM, Adam Butcher wrote: But a cleaner way might be to extend the "processing template declaration" state from lambda declarator all the way to the end of the lambda body. This would match wi

Re: [PATCH/Merge Request] Vtable Verification feature.

On Wed, Aug 7, 2013 at 6:03 PM, Joseph S. Myers wrote: > Looking at the patch as committed, there seems to be some confusion about > the nature of the --enable-vtable-verify configure option. Yes, there is a bit. > > It's documented only for libstdc++. Now, I still consider the existence > of s

Re: [PATCH, vtv update] Fix /tmp directory issues in libvtv

On Thu, Aug 8, 2013 at 3:26 PM, Mike Stump wrote: > On Aug 8, 2013, at 3:09 PM, Caroline Tice wrote: >> This patch changes where the logging file mechanism in libvtv tries to >> write its log files. Instead of trying to use /tmp, it now first >> looks for an environment variable "VTV_LOGS_DIR".

Fix PHI IDs in LTO streaming

Hi, LTO streaming renumbers gimple statements. It however forgets about PHIs that causes duplicated gimple ids and later fun everywhere (especially for me when I want to use them for reference streaming). This patch assign numbers to SSA names too. Since virtual PHIs are not stored, we have to i

Re: [PATCH/Merge Request] Vtable Verification feature.

On Thu, 8 Aug 2013, Caroline Tice wrote: > Actually if you ever want to use the feature with your compiler you > should build your compiler with --enable-vtable-verify. This will, as > you noted, insert calls in libstdc++ to build the verification data > structures and to verify the virtual call

Re: [PATCH] Sanitize block partitioning under -freorder-blocks-and-partition

On Thu, Aug 8, 2013 at 3:23 PM, Jan Hubicka wrote: > Hi, > Martin Liska was kind enough to generate disk seeking graph of gimp statrup > with his function reordering. > His code simply measures time of firest execution of a function and orders > functions in the given order. > The functions stay

Re: [PATCH] Fix PR48493

In the below, the test case tries to write to the stack outside the bounds of the s variable? I can't imagine any good coming from this, and indeed, would be nice for the compiler to complain about such code. If S had a few more bytes at the end, at least the code would not be wildly bad. Tho

Re: [PATCH/Merge Request] Vtable Verification feature.

On 08/08/2013 06:34 PM, Caroline Tice wrote: Actually if you ever want to use the feature with your compiler you should build your compiler with --enable-vtable-verify. This will, as you noted, insert calls in libstdc++ to build the verification data structures and to verify the virtual calls i

Re: [C++ RFC / Patch] PR 54080, PR 52875 and more (aka SFINAE vs template recursion depth)

On 08/08/2013 03:54 PM, Paolo Carlini wrote: the really interesting one is decltype28.C, which we don't reject anymore, we simply accept it. What is happening is that the overload which leads to excessive template instantiation depth is SFINAE-ed away and the other one "wins"! Thus, this is the c

Re: [PATCH] Fix expansion issues on type changing MEM_REFs on LHS (PR middle-end/48335)

On Mar 30, 2011, at 9:05 AM, Jakub Jelinek wrote: > MEM_REFs which can represent type punning on lhs don't force > non-gimple types to be addressable. This causes various problems > in the expander, which wasn't prepared to handle that. > > This patch tries to fix what I've found and adds a bunc

Re: [PATCH/Merge Request] Vtable Verification feature.

Which version gets used depends on their ordering in the link line. When -fvtable-verify=std or -fvtable-verify=preinit is used, the gcc driver inserts -lvtv very early into the link line (earlier than -lstdc++), so this happens "automatically". -- Caroline cmt...@google.com On Thu, Aug 8, 2013

Re: [PATCH 3/5] Atomic type qualifier - front end changes

Observations on this patch: * build_qualified_type sets the qualifiers to exactly the set specified. Thus, it looks like your handle_atomic_attribute will remove existing qualifiers when adding "atomic". * c-aux-info.c is meant to be generating actual valid C declarations, I think, meaning _A

Re: [PATCH] Fix expansion issues on type changing MEM_REFs on LHS (PR middle-end/48335)

On Mar 30, 2011, at 9:05 AM, Jakub Jelinek wrote: > + else if (bitpos >= mode_bitsize / 2) > + result = store_field (XEXP (to_rtx, 1), bitsize, > + bitpos - mode_bitsize / 2, mode1, from, > + TREE_TYPE (tem), get_alias_set (

Re: [C++ Patch / RFC] PR 46206

On 08/08/2013 02:31 PM, Paolo Carlini wrote: On 08/08/2013 08:18 PM, David Edelsohn wrote: Why does the patch and fix have any architecture or OS-dependency? Probably the same reason that subtle changes in the testcase changed whether the bug appeared on x86_64-linux. I guess we should figur

Re: [vtv] fix default configure

More patches to fix disable issus on non-linux. > Here's a patch for the build failure on darwin. Will check in when testing completes. tested x86/linux tested x86_64/darwin12 -benjamin2013-08-08 Benjamin Kosnik Michael Meissner * configure.tgt : Simplify, just use VTV_SUPPORTED.

Re: [PATCH, vtv update] Fix /tmp directory issues in libvtv

On Aug 8, 2013, at 3:34 PM, Caroline Tice wrote: > On Thu, Aug 8, 2013 at 3:26 PM, Mike Stump wrote: >> On Aug 8, 2013, at 3:09 PM, Caroline Tice wrote: >>> This patch changes where the logging file mechanism in libvtv tries to >>> write its log files. Instead of trying to use /tmp, it now firs

Re: [C++ Patch / RFC] PR 46206

On Thu, Aug 8, 2013 at 8:24 PM, Jason Merrill wrote: > On 08/08/2013 02:31 PM, Paolo Carlini wrote: >> >> On 08/08/2013 08:18 PM, David Edelsohn wrote: >>> >>> Why does the patch and fix have any architecture or OS-dependency? > > > Probably the same reason that subtle changes in the testcase chan

Re: [FIXED] Generic lambda symbol table bug

On 08/08/2013 06:28 PM, Adam Butcher wrote: So all seems to be okay with both versions. Any ideas why? Hmm, it sounds like processing_template_decl is being set after all, even without your change. Jason

Re: [Patch] Whole regex refactoring and current status

On Fri, Aug 9, 2013 at 12:51 AM, Tim Shen wrote: > So here's the change. It's under testing now, but could took several > hours. If someone has a faster machine, please tell the result :) Unfortuantely using `unsigned int => unsigned short` cannot work. Instead, I create a enum and do some operat

Re: [C++ RFC / Patch] PR 54080, PR 52875 and more (aka SFINAE vs template recursion depth)

Hi, >Yes, that is intended. Changing that could mean that the meaning of >code depends on what max depth the user selected. Indeed. Yesterday I wondered what would happen if the front-end had a way to detect, in some very specific and special cases only of course, really infinite recursions,

Re: [C++ Patch / RFC] PR 46206

Hi Jason Merrill ha scritto: >Probably the same reason that subtle changes in the testcase changed >whether the bug appeared on x86_64-linux. I guess we should figure >that >out instead of just saying "hunh, that's odd." For sure. Let's see if I can in a reasonable amount of time on x86_64-l