Re: [PATCH 3/4] Use class substring_loc in c-format.c (PR c/52952)

On 08/03/2016 09:45 AM, David Malcolm wrote: This patch updates c-format.c to use the new class substring_loc, added in the previous patch, replacing location_column_from_byte_offset. Hence with this patch, Wformat can underline the precise erroneous format string in many more cases. The patch a

Re: [PATCH] do not throw in std::make_exception_ptr

On Thu, Aug 04, 2016 at 07:01:45PM +0100, Jonathan Wakely wrote: > On 04/08/16 20:01 +0300, Gleb Natapov wrote: > > Instead of throwing an exception allocate its memory and initialize it > > explicitly. Makes std::make_exception_ptr more efficient since no stack > > unwinding is needed. > > > > In

Re: [PR63240] generate debug info for defaulted member functions

On Mon, Aug 1, 2016 at 10:57 PM, Alexandre Oliva wrote: > * langhooks.h (struct lang_hooks_for_decls): Add > function_decl_defaulted_inclass_p and > function_decl_defaulted_outofclass_p. Maybe one hook that returns unsigned rather than two bool hooks? Jason

Re: [C++ Patch] PR 72800

OK. On Thu, Aug 4, 2016 at 1:02 PM, Paolo Carlini wrote: > Hi, > > when back in 2014 I sent the patch for c++/61088 I noticed some cases where > we wanted to return early error_mark_node from add_capture to avoid ICEs > during error recovery when COMPLETE_TYPE_P is used on an error_mark_node. > T

Re: [PATCH 1/4] selftest.h: Add ASSERT_TRUE_AT and ASSERT_FALSE_AT

On Wed, 2016-08-03 at 10:06 -0600, Jeff Law wrote: > On 08/03/2016 09:45 AM, David Malcolm wrote: > > I split out the selftest.h changes from v2 of the kit for ease of > > review; > > here they are. > > > > Successfully bootstrapped®rtested in conjunction with the rest > > of the > > patch kit on

Re: [PATCH] do not throw in std::make_exception_ptr

On 04/08/16 21:36 +0300, Gleb Natapov wrote: On Thu, Aug 04, 2016 at 07:01:45PM +0100, Jonathan Wakely wrote: The Doxygen group that starts with @{ ends later in this file, but you haven't moved the corresponding @} to the new file. I can take care of fixing that up though (we want the contents

Re: protected alloca class for malloc fallback

How wedded are we to alloca? On 08/04/2016 12:30 PM, Aldy Hernandez wrote: > Is there a better blessed C++ way? std::string or if I'm reading gcc's vec.h correctly: auto_vec ? (or some typedef of the latter) The latter would always allocate the stack space, but my guess it that it would

Re: protected alloca class for malloc fallback

On 08/04/2016 01:06 PM, Pedro Alves wrote: How wedded are we to alloca? I would think only in the sense of existing codebase usage. Based on how often alloca usage has resulted in a security vulnerability it's clear we as developers can't use it correctly on a consistent basis, thus I'd like

Re: fix fallout of pr22051-2.c on arm

On 4 August 2016 at 12:39, Richard Biener wrote: > On Thu, 4 Aug 2016, Prathamesh Kulkarni wrote: > >> Hi, >> The attached patch fixes pr22051-2.c which regressed due to >> r238754. Matthew, could you please confirm if this patch fixes the >> test-case for you ? >> >> Bootstrapped and tested on x8

Re: [PATCH 2/4] (v3) On-demand locations within string-literals

On Thu, 2016-08-04 at 11:37 -0600, Jeff Law wrote: > On 08/03/2016 09:45 AM, David Malcolm wrote: > > Changes in v3: > > - Avoid including cpplib.h from input.h > > - Properly handle stringified macro arguments (with tests for this) > > - Minor whitespace fixes > > - Move selftest.h changes to a se

Re: protected alloca class for malloc fallback

On 08/04/2016 08:16 PM, Jeff Law wrote: > On 08/04/2016 01:06 PM, Pedro Alves wrote: >> How wedded are we to alloca? > I would think only in the sense of existing codebase usage. > > Based on how often alloca usage has resulted in a security vulnerability > it's clear we as developers can't use it

Re: protected alloca class for malloc fallback

On 08/04/2016 09:19 AM, Aldy Hernandez wrote: Particularly irritating and error prone is having to free malloc'd pointers on every function exit point. We end up with a lot of: foo(size_t len) { void *p, *m_p = NULL; if (len < HUGE) p = alloca(len); else p = m_p = malloc(le

Re: [PATCH 3/4] Use class substring_loc in c-format.c (PR c/52952)

On Thu, 2016-08-04 at 12:08 -0600, Jeff Law wrote: > On 08/03/2016 09:45 AM, David Malcolm wrote: > > This patch updates c-format.c to use the new class substring_loc, > > added > > in the previous patch, replacing location_column_from_byte_offset. > > Hence with this patch, Wformat can underline t

Re: protected alloca class for malloc fallback

On 08/04/2016 01:21 PM, Pedro Alves wrote: On 08/04/2016 08:16 PM, Jeff Law wrote: On 08/04/2016 01:06 PM, Pedro Alves wrote: How wedded are we to alloca? I would think only in the sense of existing codebase usage. Based on how often alloca usage has resulted in a security vulnerability it's

Re: protected alloca class for malloc fallback

On 08/04/2016 08:26 PM, Jeff Law wrote: > On 08/04/2016 01:21 PM, Pedro Alves wrote: >> Most allocas I've seen in my life were written to simply build >> strings at run time, while lazily avoiding to think about writing >> a "free" call, rather than having been written for optimizing >> some fast

Re: [PATCH 4/4] c-format.c: suggest the correct format string to use (PR c/64955)

On 08/03/2016 09:45 AM, David Malcolm wrote: This adds fix-it hints to c-format.c so that it can (sometimes) suggest the format string the user should have used. The patch adds selftests for the new code in c-format.c. These selftests are thus lang-specific. This is the first time we've had la

Re: [tree-ssa-ccp] modify extend_mask to extend bits based on signop

Ah, the mail failed to be delivered to gcc-patches, sorry for the double-post. On 5 August 2016 at 01:26, Prathamesh Kulkarni wrote: > Hi, > Is the attached patch OK ? > Since we want to extend based on signop, I removed ORing with wi::mask(). > Bootstrap+test passes on x86_64-unknown-linux-gnu. >

make streaming routines for widest_int non-static

Hi, This patch makes streamer_read_wi and streamer_write_wi non-static, and exports them from lto-streamer.h. I suppose this hunk could be committed independently of the ipa-bitwise-cp patch ? Bootstrap+test in progress on x86_64-unknown-linux-gnu. OK for trunk ? Thanks, Prathamesh 2016-08-05 Pra

Re: [PATCH 2/4] (v3) On-demand locations within string-literals

On 08/04/2016 01:21 PM, David Malcolm wrote: + +static enum cpp_ttype +get_cpp_ttype_from_string_type (tree string_type) +{ + gcc_assert (string_type); + if (TREE_CODE (string_type) != ARRAY_TYPE) +return CPP_OTHER; + + tree element_type = TREE_TYPE (string_type); + if (TREE_CODE (elemen

Re: [PATCH 3/4] Use class substring_loc in c-format.c (PR c/52952)

On 08/04/2016 01:24 PM, David Malcolm wrote: Do you realize that this isn't used for ~700 lines after this point? Is there any sensible way to factor some code here to avoid the coding disconnect. I realize the function was huge before you got in here, but if at all possible, I'd like to see a

Re: [PING**2] [PATCH] Fix asm X constraint (PR inline-asm/59155)

On 07/21/2016 10:29 AM, Bernd Edlinger wrote: But I think we have a use case where "X" means really more possible registers (i.e. includes ss2, mmx etc.) than "g" (only general registers). Otherwise, in the test cases of pr59155 we would not have any benefit for using "+X" instead of "+g" or "+r

Re: [PATCH 4/4] c-format.c: suggest the correct format string to use (PR c/64955)

On Thu, 2016-08-04 at 13:55 -0600, Jeff Law wrote: > On 08/03/2016 09:45 AM, David Malcolm wrote: > > This adds fix-it hints to c-format.c so that it can (sometimes) > > suggest > > the format string the user should have used. > > > > The patch adds selftests for the new code in c-format.c. These

Re: [PATCH] - improve sprintf buffer overflow detection (middle-end/49905)

On 07/21/2016 03:48 PM, Jeff Law wrote: Sorry about the delay in responding... I saw a few places in GCC itself where you increased buffer sizes. Were any of those level 1 failures? Yes. With optimization, even level 1 uses range information when it's available. The idea is that when th

Re: [PATCH, ARM] Add a new target hook to compute the frame layout

Hi, this patch introduces a new target hook that allows the target's INITIAL_ELIMINATION_OFFSET function to use cached values instead of re-computing the frame layout every time. I have updated the documentation a bit and hope it is clearer this time. It still needs a review by ARM port maintai

[PATCH, i386]: Fix wrong cast in _mm512_{,mask_}cmp_ep{i,u}32_mask intrinsics

2016-08-04 Uros Bizjak PR target/72805 * config/i386/avx512fintrin.h (_mm512_cmp_epi32_mask) [!__OPTIMIZE__]: Cast builtin function result to __mmask16 instead of __mmask8. (_mm512_cmp_epu32_mask) [!__OPTIMIZE__]: Ditto. (_mm512_mask_cmp_epi32_mask) [!__OPTIMIZE__]: Ditto.

Re: [PATCH] Replacing gcc's dependence on libiberty's fnmatch to gnulib's fnmatch

On 07/31/2016 11:50 PM, Manuel López-Ibáñez wrote: > Oh well, Ayush does not have access to different hosts, thus I > guess it is better that he focuses his limited time on functions that > he can test. There are plenty of functions that are both in gnulib and > libiberty but not in glibc. > My

Re: [PATCH] Replacing gcc's dependence on libiberty's fnmatch to gnulib's fnmatch

On 07/30/2016 02:10 AM, Manuel López-Ibáñez wrote: > What about my suggestion of forcing GCC to use the gnulib functions by > temporarily removing the system-wide functions? Would that be > equivalent testing to building on a host that requires the libiberty > version of a function? I don't think

Re: [PATCH build/doc] Replacing libiberty with gnulib

On 08/02/2016 12:38 AM, Manuel López-Ibáñez wrote: > > If there is something wrong or missing, ideally we would like to know > so that Ayush can work on fixing it before the Summer of Code is over > in less than two weeks. I couldn't see anywhere gnulib's config.h file is included. gnulib's repl

Re: [PATCH v2,rs6000] Add built-in function support for Power9 binary floating point operations

On Thu, Aug 04, 2016 at 09:27:55AM -0600, Kelvin Nilsen wrote: > The patch has been bootstrapped and tested on powerpc64le-unknown-linux > and on powerpc64-unknown-linux (big-endian) with no regressions. Is > this ok for the trunk? Just a couple more nits.. Okay for trunk with those fixed / look

Re: [RFC] ipa bitwise constant propagation

Hi Honza, On 04/08/16 23:05, Jan Hubicka wrote: I didn't look at the propagation part but eventually the IPA-CP lattice gets quite big. Also the alignment lattice is very similar to the bits lattice so why not merge those two? But This was always the original idea to replace alignment propag

Re: Ping Re: Implement C _FloatN, _FloatNx types [version 5]

On Fri, Jul 29, 2016 at 05:37:26PM +, Joseph Myers wrote: > Ping. This patch > > (non-C-front-end parts) is pending review. I'm starting to look at the patches. It will take some time to come up to speed, particularly with the othe

Re: Implement C _FloatN, _FloatNx types

In gcc/c-family/c-prettyprint.c in the function that you modified pp_c_floating_constant: It brings up a general complaint that I had when I started the whole PowerPC __float128 adventure is that we have multiple places in the compiler it goes through a list of floating point types, and only for t

Re: Ping Re: Implement C _FloatN, _FloatNx types [version 5]

On Thu, 4 Aug 2016, Michael Meissner wrote: > Or is the check at the end whether ieee_bits > (for extended tests) or == (for > normal tests) sufficient to say that SFmode, DFmode, really is IEEE? Yes. That's the semantics of ieee_bits as detailed in the comment in real.h. Note that the followi

Re: Implement C _FloatN, _FloatNx types

On Thu, 4 Aug 2016, Michael Meissner wrote: > It brings up a general complaint that I had when I started the whole PowerPC > __float128 adventure is that we have multiple places in the compiler it goes > through a list of floating point types, and only for the blessed types does it > do something.

[patch] New libstdc++ docs on testing and library versioning

I've been working on some changes to the libstdc++ manual recently. A lot of the changes are just using DocBook markup with more semantic meaning (e.g. or instead of using for everything that should use a monospace font) but there are some changes to content too. I've added a new subsection d

[RS6000] PR72802 part 1, fix constraints for lxssp/stxssp

We can't use "o" constraint for lsxxp/stxssp since those insns have a DS-form offset field, ie. the bottom two bits of the offset must be 0. So use "wY" instead, but that leads to finding another problem.. mem_operand_gpr is only suitable for gpr loads/stores since it does not enforce multiple-of-

Re: protected alloca class for malloc fallback

On 08/04/2016 05:30 AM, Aldy Hernandez wrote: Howdy! As part of my -Walloca-larger-than=life work, I've been running said pass over gcc, binutils, and gdb, and trying to fix things along the way. Particularly irritating and error prone is having to free malloc'd pointers on every function exit

Re: [PATCH] Improve forward jump threading of switch statements (PR18046)

On Thu, Jul 28, 2016 at 11:46 PM, Patrick Palka wrote: > This patch improves the forward jump threader's ability to thread > GIMPLE_SWITCHes by making the VRP simplification callback attempt to > determine which case label will be taken. > > For example, if the index operand of a switch has a valu

[PATCHv2] do not throw in std::make_exception_ptr

Instead of throwing an exception allocate its memory and initialize it explicitly. Makes std::make_exception_ptr more efficient since no stack unwinding is needed. v1->v2: - fix indentation - drop static from __dest_thunk - use static_cast instead of reinterpret_cast * libsupc++/exception (std

[RS6000] PR72802 part 2, reload ICE

After fixing the constraint problem, we hit an "insn does not satisfy its constraints" with -mno-lra on the following insn, a vector load from mem which has an invalid offset: (insn 631 630 1122 12 (set (reg:SF 108 31 [orig:260 pretmp_44 ] [260]) (mem:SF (plus:DI (reg:DI 30 30 [orig:338 ivt

RE: [ARM] mno-pic-data-is-text-relative & msingle-pic-base

Nathan, Sorry for jumping in a relatively old thread. I saw this in mailing list archives during a web search (I wasn't on this mailing list before). I decided to speak up as I would be an affected party if this patch (or some similar future patch) gets accepted or worse yet, the feature invo

Re: [PATCHv2] do not throw in std::make_exception_ptr

2016-08-05 6:49 GMT+02:00 Gleb Natapov : > Instead of throwing an exception allocate its memory and initialize it > explicitly. Makes std::make_exception_ptr more efficient since no stack > unwinding is needed. [..] > +#ifndef _CXXABI_INIT_EXCEPTION_H > +#define _CXXABI_INIT_EXCEPTION_H 1 > + > +

Re: [ARM] mno-pic-data-is-text-relative & msingle-pic-base

Ramana, I saw some correspondence between you and Nathan on his patch [https://gcc.gnu.org/ml/gcc-patches/2016-05/msg00630.html] (after I sent this email) going in a direction that may eventually result in too tight than necessary coupling between these two switches, as your response hints at: >

<    1   2