Re: [PATCH 0/5] x86: CVE-2017-5715, aka Spectre

* Sandra Loosemore: > I have a general documentation issue with all the new command-line > options and attributes added by this patch set: the documentation is > very implementor-speaky and doesn't explain what user-level problem > they're trying to solve. Agreed. Ideally, the documentation

Re: [PATCH 0/5] x86: CVE-2017-5715, aka Spectre

* H. J. Lu: > This set of patches for GCC 8 mitigates variant #2 of the > speculative execution vulnerabilities on x86 processors identified > by CVE-2017-5715, aka Spectre. They convert indirect branches to > call and return thunks to avoid speculative execution via indirect > call and jmp.

Re: [PATCH 2/5] x86: Add -mindirect-branch-loop=

* H. J. Lu: > Add -mindirect-branch-loop= option to control loop filler in call and > return thunks generated by -mindirect-branch=. 'lfence' uses "lfence" > as loop filler. 'pause' uses "pause" as loop filler. 'nop' uses "nop" > as loop filler. The default is 'lfence'. Why is the loop

Re: [PATCH] [PR target/83641] Fix incorrect CFI for stack clash protected noreturn function on x86/x86_64

On 01/02/2018 09:02 PM, Jeff Law wrote: * config/i386/i386.c (ix86_adjut_stack_and_probe_stack_clash): Do not Typo: “adjut”. explicitly probe *sp in a noreturn function if there were any callee register saves. I recompiled glibc with this patch, and I can confirm it

Re: [PATCH libstdc++/66689] comp_ellint_3 and ellint_3 return garbage values

On 11/18/2017 05:49 PM, Ed Smith-Rowland wrote: I feel that distros are likely to pick up gcc-7 soon and I'd like to do *something*.  This would be something of a transition path. Historically, in glibc, we would have used symbol versioning for this, so that existing binaries retain the old

Re: 0005-Part-5.-Add-x86-CET-documentation

On 09/27/2017 05:40 AM, Sandra Loosemore wrote: +@emph{x86 implementation:} when @option{-fcf-protection} option is +specified the compiler inserts an ENDBR instruction at function's +prologue if the function's type does not have the @code{nocf_check} +attribute and addresses to which indirect

Re: [RFC][PR 67336][PING^6] Verify pointers during stack unwind

* Yuri Gribov: > I've rebased the previous patch to trunk per Andrew's suggestion. > Original patch description/motivation/questions are in > https://gcc.gnu.org/ml/gcc-patches/2017-06/msg01869.html What about the remaining TODOs? > + if (__builtin_expect (msync ((void *)page, len, MS_ASYNC),

Re: [RFC][PR 67336][PING^6] Verify pointers during stack unwind

* Jeff Law: >> If speed is not a concern, but reliability is, call fork (the system >> call, not glibc's wrapper which calls fork handlers) and do the work >> in a single-threaded copy of the process. There, you can set up >> signal handlers as you see fit, and the VM layout won't change >>

Re: [RFC][PR 67336][PING^6] Verify pointers during stack unwind

* Jeff Law: > Something like setup a signal handler when we first start unwinding that > flags the error and tear it down when we're done unwinding?Obviously > we can't do setup/tear down each time for each address. Anyway, just > thinking outloud here... Linux doesn't have per-thread

Re: RFC: stack/heap collision vulnerability and mitigation with GCC

* Jeff Law: > On 06/28/2017 12:45 AM, Florian Weimer wrote: >> * Richard Earnshaw: >> >>> I can't help but feel there's a bit of a goode olde mediaeval witch hunt >>> going on here. As Wilco points out, we can never defend against a >>> function that i

Re: [PATCH, rs6000] Modify libgcc's float128 IFUNC resolver functions to use __builtin_cpu_supports()

On 07/06/2017 11:21 PM, Peter Bergner wrote: > I will note that this patch causes issues in some tests in the GLIBC > testsiute, > which Tulio is working on fixing (it's a GLIBC issue, not a GCC issue), so if > this patch is "ok", I plan on holding off on committing this, until the GLIBC > fix is

Re: RFC: stack/heap collision vulnerability and mitigation with GCC

* Richard Earnshaw: > I can't help but feel there's a bit of a goode olde mediaeval witch hunt > going on here. As Wilco points out, we can never defend against a > function that is built without probe operations but skips the entire > guard zone. The only defence there is a larger guard zone,

Re: [PATCH][RFA] Fix -fstack-check with really big frames on aarch64

* Jeff Law: > But I still think we're going to want to explicitly test the various > cases where we want to see probes vs when we do not. That kind of > testing won't be covered unless we explicitly do so and the least > painful way to cover may be via dump messages or the unit testing >

Re: [PATCH][RFA] Fix -fstack-check with really big frames on aarch64

* Mike Stump: > On Jun 22, 2017, at 8:32 AM, Jeff Law wrote: >> >> Sure. I'll do something with 20031023-1.c to ensure it or an equivalent >> is compiled with -fstack-check. That isn't totally unexpected. I >> would have also been receptive to adding -fstack-check to the

Re: RFC: stack/heap collision vulnerability and mitigation with GCC

On 06/20/2017 11:52 PM, Jeff Law wrote: > I've also wondered if a 2 page guard would solve some of these problems. > In the event of stack overflow, the kernel maps in one of the two pages > for use by the signal handler. But changing things at this point may > not be worth the effort. I think

Re: RFC: stack/heap collision vulnerability and mitigation with GCC

On 06/20/2017 01:10 PM, Uros Bizjak wrote: > 74,99% a.outa.out [.] test_or > 12,50% a.outa.out [.] test_movb > 12,50% a.outa.out [.] test_movl Could you try notl/notb/negl/negb as well, please? Thanks, Florian

Re: RFC: stack/heap collision vulnerability and mitigation with GCC

On 06/20/2017 12:05 AM, Jeff Law wrote: > On 06/19/2017 03:56 PM, Joseph Myers wrote: >> On Mon, 19 Jun 2017, Florian Weimer wrote: >> >>> I think architectures such as aarch64 without implied stack probing as >>> part of the function call sequence would benef

Re: RFC: stack/heap collision vulnerability and mitigation with GCC

On 06/19/2017 07:50 PM, Joseph Myers wrote: > There's a platform ABI issue here. At least some kernel fixes for these > stack issues, as I understand it, increase the size of the stack guard to > more than a single page. It would be possible to define the ABI to > require such a larger guard

Re: RFC: stack/heap collision vulnerability and mitigation with GCC

On 06/19/2017 08:02 PM, Richard Biener wrote: > Oh, and using push intelligently with first bumping to SP & 4096-1 + 4095 > would solve the signal atomicity as well. Might be larger and somewhat > interfere with CPUs stack engine. Who knows... On x86-64, PUSH REG is just a single byte, so for

Re: [PATCH] Add attribute((target_clone(...))) to PowerPC

On Thu, May 25, 2017 at 8:25 PM, Michael Meissner wrote: > This patch adds the initial attribute((target_clone(...))) support to the Patch seems to be missing. Florian

Re: [PATCH] PR libstdc++/80624 satisfy invariant for char_traits::eof()

On 05/08/2017 12:24 PM, Jonathan Wakely wrote: On 08/05/17 11:53 +0200, Florian Weimer via libstdc++ wrote: On 05/05/2017 07:05 PM, Jonathan Wakely wrote: As discussed at http://stackoverflow.com/q/43769773/981959 (and kinda hinted at by http://wg21.link/lwg1200) there's a problem

Re: [PATCH] PR libstdc++/80624 satisfy invariant for char_traits::eof()

On 05/05/2017 07:05 PM, Jonathan Wakely wrote: As discussed at http://stackoverflow.com/q/43769773/981959 (and kinda hinted at by http://wg21.link/lwg1200) there's a problem with char_traits::eof() because it returns int_type(-1) which is the same value as u'\u', a valid UTF-16 code point.

Re: [PATCH] C++: Add fix-it hints for -Wold-style-cast

* David Malcolm: > gcc/testsuite/ChangeLog: > * g++.dg/other/old-style-cast-fixits.C: New test case. Would it make sense to add a test cases for the non-fixable cases? That would be: void test_1 (const void *ptr) { foo *f = (foo *)ptr; } And: const bar b_inst; foo *f =

Re: [PATCH] Add a new type attribute always_alias (PR79671)

On 04/06/2017 09:12 PM, Richard Biener wrote: Right. The kernel also has many APIs which return multiple variable-length data blocks, such as getdents64, and many more interfaces in combination with read/recv system calls. Variable length means that you cannot declare the appropriate type

Re: [PATCH] Add a new type attribute always_alias (PR79671)

On 04/06/2017 09:16 PM, Richard Biener wrote: On April 6, 2017 8:12:29 PM GMT+02:00, Bernd Edlinger wrote: But isn't the effective type changed by the assignment b[1] = 0; as described in 6.5(6): "If a value is stored into an object having no declared type through

Re: [PATCH] Add a new type attribute always_alias (PR79671)

On 04/06/2017 08:49 PM, Bernd Edlinger wrote: For instance how do you "declare an object without a declared type"? malloc and other allocation functions return pointers to objects without a declared type. Thanks, Florian

Re: [PATCH] Add a new type attribute always_alias (PR79671)

On 04/06/2017 08:12 PM, Bernd Edlinger wrote: On 04/06/17 19:47, Florian Weimer wrote: On 04/06/2017 07:39 PM, Bernd Edlinger wrote: On 04/06/17 16:17, Florian Weimer wrote: Here is what I want to write in the doc: @item typeless_storage @cindex @code{typeless_storage} type attribute A type

Re: [PATCH] Add a new type attribute always_alias (PR79671)

On 04/06/2017 07:39 PM, Bernd Edlinger wrote: On 04/06/17 16:17, Florian Weimer wrote: Here is what I want to write in the doc: @item typeless_storage @cindex @code{typeless_storage} type attribute A type declared with this attribute behaves like a character type with respect to aliasing

Re: [PATCH] Add a new type attribute always_alias (PR79671)

On 04/06/2017 05:05 PM, Jakub Jelinek wrote: On Thu, Apr 06, 2017 at 04:51:01PM +0200, Florian Weimer wrote: On 04/06/2017 04:43 PM, Jonathan Wakely wrote: On 06/04/17 16:23 +0200, Richard Biener wrote: On Thu, 6 Apr 2017, Florian Weimer wrote: On 04/06/2017 04:11 PM, Bernd Edlinger wrote

Re: [PATCH] Add a new type attribute always_alias (PR79671)

On 04/06/2017 04:43 PM, Jonathan Wakely wrote: On 06/04/17 16:23 +0200, Richard Biener wrote: On Thu, 6 Apr 2017, Florian Weimer wrote: On 04/06/2017 04:11 PM, Bernd Edlinger wrote: > I think it is not too complicated to done in the C++ FE. > The FE looks for array of std::byte and un

Re: [PATCH] Add a new type attribute always_alias (PR79671)

On 04/06/2017 04:11 PM, Bernd Edlinger wrote: I think it is not too complicated to done in the C++ FE. The FE looks for array of std::byte and unsigned char, and sets the attribute when the final type is constructed. What I am trying to do is just extend the semantic of may_alias a bit, and

Re: [PATCH] Add a new type attribute always_alias (PR79671)

On 04/05/2017 11:46 AM, Bernd Edlinger wrote: +@item always_alias +@cindex @code{always_alias} type attribute +Same as @code{may_alias}, but additionally applies to instances of +types with this attribute. As a GCC user, I have to say that this doesn't really explain what the attribute does.

PR libgcc/78064: Add missing include directive to unwind-c.c

are not affected by this). 2016-10-21 Florian Weimer <fwei...@redhat.com> PR libgcc/78064 * unwind-c.c: Include auto-target.h. Index: libgcc/unwind-c.c === --- libgcc/unwind-c.c (revision 241395) +++ libgcc/

Re: [PATCH] Implement new hook for max_align_t_align

On 10/12/2016 06:14 PM, Jeff Law wrote: If the issue is strictly limited to 32 bit hpux, then do we really care? Can we just deprecate that platform and thus make the issue go away? Are we talking about HP-XX or Linux on PA-RISC? Thanks, Florian

Re: [PATCH] Implement new hook for max_align_t_align

On 10/12/2016 09:25 AM, Jakub Jelinek wrote: No, you can just drop the aligned attributes for HPUX 32-bit, basically introduce a new ABI. If needed, you could add new symbol versions for pthread_mutex_* etc. (though, if the current code doesn't care about the alignment, perhaps you could get

Re: [PATCH] Remove .jcr registry from the crtfiles

* Jakub Jelinek: > Now that GCJ is gone, I think we should remove the the tests for .jcr > sections from the crtfiles, which slows down (by a couple of instructions > and some relocations) every gcc compiled binary/library. Why were they needed *in every DSO* in the first place? We still have

Re: [PATCH 2/2] Extend -falign-FOO=N to N[,M[,N2[,M2]]]

* Denys Vlasenko: > Example syntax is -falign-functions=64,9: "align to 64 by skipping up to > 9 bytes (not inclusive)". IOW: "after a call insn, CPU will always be able > to fetch at least 9 bytes of insns". Is it possible to set this using the optimize function attribute? For example, we

Re: Change license of filenames.h to LGPL

* Eli Zaretskii: > If my arithmetics is correct, about 70% of its files is LGPL, the > rest GPL. Which doesn't keep many GNU projects under GPL from using > Gnulib. Sorry, I don't understand. Surely anything released under the LGPL by the FSF can be upgraded to the current GPLv3? First

Re: PATCH to add more FALLTHRU markers

* Marek Polacek: > On Tue, Sep 27, 2016 at 08:58:59PM +0200, Florian Weimer wrote: >> * Marek Polacek: >> >> > @@ -11498,21 +11508,23 @@ >> > case V64QImode: >> > case V32HImode: >> >if (TARGET_AV

Re: PATCH to add more FALLTHRU markers

* Marek Polacek: > @@ -11498,21 +11508,23 @@ > case V64QImode: > case V32HImode: >if (TARGET_AVX512F) > - { > -tmp = "p"; > -ssesuffix = "q"; > -break; > - } > + { > + tmp = "p"; > +

Re: Change license of filenames.h to LGPL

* Eli Zaretskii: >> From: DJ Delorie >> Cc: gcc-patches@gcc.gnu.org, seze...@gmail.com >> Date: Tue, 27 Sep 2016 13:52:10 -0400 >> >> >> Most of the files in include/ are GPL, not LGPL. Why is this one >> different? > > Because Ozkan wants to use it in an otherwise LGPL

Re: [PATCH] Make -Wint-in-bool-context warn on suspicious shift ops

* Bernd Edlinger: >> “0 << 0” is used in a similar context, to create a zero constant for a >> multi-bit subfield of an integer. >> >> This example comes from GDB, in bfd/elf64-alpha.c: >> >> | insn = INSN_ADDQ | (16 << 21) | (0 << 16) | (0 << 0); >> > > Of course that is not a boolean context,

Re: [PATCH] Make -Wint-in-bool-context warn on suspicious shift ops

* Jason Merrill: > On Sun, Sep 25, 2016 at 3:46 AM, Bernd Edlinger > wrote: >> This patch makes -Wint-in-bool-context warn on suspicious integer left >> shifts, when the integer is signed, which is most likely some kind of >> programming error, for instance using "<<"

Re: Implement -Wimplicit-fallthrough (version 9)

* Marek Polacek: > On Tue, Sep 27, 2016 at 01:46:08PM +0200, Markus Trippelsdorf wrote: >> I'm also wondering about the situation where not a single break is used >> in all of the cases. It would be best not to warn here. > > This is tricky and I'm afraid all I can offer here is to use the

Re: [gofrontend-dev] Go patch committed: Avoid warning by using a local var for std::ofstream

* Carlos O'Donell: >> Yes, and for the warning to go away, GCC's MALLOC_ABI_ALIGNMENT needs >> to be increased as well, I think. > > This is not required. Strictly speaking, that's true. > The __attribute__((__aligned__(16))); is not required for pthread locks > to work correctly, it is simply

Re: [gofrontend-dev] Go patch committed: Avoid warning by using a local var for std::ofstream

* John David Anglin: > On Tue, Sep 20, 2016 at 09:27:17PM +0200, Florian Weimer wrote: >> * Ian Lance Taylor: >> >> > GCC PR 77625 is about a warning while compiling the Go frontend. The >> > Go frontend called `new std::ofstream()`, and the warning is "er

Re: [gofrontend-dev] Go patch committed: Avoid warning by using a local var for std::ofstream

* Ian Lance Taylor: > GCC PR 77625 is about a warning while compiling the Go frontend. The > Go frontend called `new std::ofstream()`, and the warning is "error: > ‘new’ of type ‘std::ofstream {aka std::basic_ofstream}’ with > extended alignment 16". Frankly I'm not sure how this supposed to >

Re: [PATCH] manual: _Bool has trap representations

On 09/19/2016 11:26 PM, Joseph Myers wrote: On powerpc-darwin _Bool is 4-byte not 1-byte, so saying values are represented as bytes isn't accurate for all systems supported by GCC. Interesting. Is the treatment of 0/1/the rest still the same there? Thanks, Florian

[PATCH] manual: _Bool has trap representations

Defined behavior for extraordinary values of _Bool would be preferable, but we can at least document what we have now. Thanks, Florian 2016-09-19 Florian Weimer <fwei...@redhat.com> * doc/implement-c.texi (Integers implementation): _Bool has trap representations.

Re: [PATCH] ada/77535: GNAT.Perfect_Hash_Generators for non-1-based strings

* Florian Weimer: > This patch fixes GNAT.Perfect_Hash_Generators for strings which are > not 1-based. It does this by introducing its own storage type which > fixes the first index as 1. This is also a minor optimization because > it avoids the need to store the index. > &

[PATCH] ada/77535: GNAT.Perfect_Hash_Generators for non-1-based strings

test case for this? I don't see any existing tests for this package. 2016-09-08 Florian Weimer <f...@deneb.enyo.de> PR ada/77535 Make all word strings start with 1. * g-pehage.adb (Word_Storage): New type. (Word_Type): Use Word_Storage. (Fre

Re: Make max_align_t respect _Float128 [version 2]

On 09/08/2016 02:26 PM, Bernd Schmidt wrote: On 09/08/2016 01:21 AM, Paul Eggert wrote: Sure, attached. On Fedora 24 x86-64 (GCC 6.1.1 20160621, valgrind 3.11.0), when I compile with "gcc -O2 flexouch.c" and run with "valgrind ./a.out", valgrind complains "Invalid read of size 2". This is

Re: Make max_align_t respect _Float128 [version 2]

On 09/08/2016 01:56 PM, Mark Wielaard wrote: On Wed, Sep 07, 2016 at 04:21:29PM -0700, Paul Eggert wrote: On 09/07/2016 04:52 AM, Mark Wielaard wrote: If valgrind believes the memory isn't in valid memory then it will complain about an invalid access. But if the memory is accessible but

Re: Make max_align_t respect _Float128 [version 2]

On 09/07/2016 08:32 PM, Bernd Edlinger wrote: interesting. I just tried the test case from PR 77330 with _Decimal128. result: _Decimal128 did *not* trap with gcc4.8.4, but it does trap with gcc-7.0.0. Recent GCC versions rely on struct pointer alignment for struct member access, older

Re: Make max_align_t respect _Float128 [version 2]

On 09/07/2016 07:45 PM, Joseph Myers wrote: On Wed, 7 Sep 2016, Florian Weimer wrote: The existence of such a cut-off constant appears useful, but it's not clear if it should be tied to the fundamental alignment (especially, as this discussion shows, the fundamental alignment will be somewhat

Re: Make max_align_t respect _Float128 [version 2]

On 09/06/2016 11:31 PM, Paul Eggert wrote: On 09/06/2016 01:40 PM, Joseph Myers wrote: Sounds like a defect in C11 to me - none of the examples of flexible array members anticipate needing to add to the size to allow for tail padding with unknown alignment requirements. Yes, I would prefer

Re: Make max_align_t respect _Float128 [version 2]

On 09/06/2016 10:40 PM, Joseph Myers wrote: On Tue, 6 Sep 2016, Paul Eggert wrote: One way to correct the code is to increase malloc's argument up to a multiple of alignof(max_align_t). (One cannot portably use alignof(struct s) due to Sounds like a defect in C11 to me - none of the examples

Re: Make max_align_t respect _Float128 [version 2]

On 09/06/2016 11:23 AM, Richard Biener wrote: The question then is, how can we make max_align_t more useful? If it is supposed to reflect a malloc property, it cannot be a compile-time constant because we don't know at compile time which malloc is going to be used (malloc has to remain

Re: Make max_align_t respect _Float128 [version 2]

On 09/06/2016 01:25 PM, Joseph Myers wrote: On Tue, 6 Sep 2016, Florian Weimer wrote: Why aren't there any users? The standard isn't very clear what the value of _Alignof (max_align_t) actually means. Does the phrase “all contexts” include pointers returned malloc? Even if the requested

Re: Make max_align_t respect _Float128 [version 2]

On 09/06/2016 01:59 PM, Bernd Schmidt wrote: On 09/06/2016 11:11 AM, Florian Weimer wrote: I think this change is only safe because nothing relies on it. max_align_t is a committee invention with no actual users. I tried to verify that and ran grep over all the packages in /usr/portage

Re: Make max_align_t respect _Float128 [version 2]

On 09/05/2016 07:06 PM, Joseph Myers wrote: Such an increase is of course an ABI change, but a reasonably safe one, in that max_align_t doesn't tend to appear in library interfaces (rather, it's something to use when writing allocators and similar code; most matches found on

Re: Make max_align_t respect _Float128

On 08/26/2016 10:54 PM, Joseph Myers wrote: Such an increase is of course an ABI change, but a reasonably safe one, in that max_align_t doesn't tend to appear in library interfaces (rather, it's something to use when writing allocators and similar code; most matches found on

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

On 08/24/2016 06:40 PM, Martin Sebor wrote: On 08/23/2016 05:00 PM, Joseph Myers wrote: Some observations: * Does -fprintf-return-value allow for the possibility of snprintf failing because of a memory allocation failure and so returning -1 when GCC computed bounds on what it could return if

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

On 08/20/2016 05:18 AM, Trevor Saunders wrote: Patch #5 and beyond: Further optimization work. As one of the next steps I'd like to make this feature available to user-defined sprintf-like functions decorated with attribute format. To do that, I'm thinking of adding either a fourth (optional)

Re: [PATCH] tree-optimization/71831 - __builtin_object_size poor results with no optimization

* Martin Sebor: > As requested in the review of the following patch > > https://gcc.gnu.org/ml/gcc-patches/2016-08/msg01363.html > > attached is the small enhancement to compute_builtin_object_size to > make the function usable even without optimization without the full > overhead of the

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

On 07/12/2016 11:54 AM, Jakub Jelinek wrote: On Tue, Jul 12, 2016 at 11:51:50AM +0200, Florian Weimer wrote: On 07/01/2016 08:15 PM, Martin Sebor wrote: The attached patch enhances compile-time checking for buffer overflow and output truncation in non-trivial calls to the sprintf family

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

On 07/01/2016 08:15 PM, Martin Sebor wrote: The attached patch enhances compile-time checking for buffer overflow and output truncation in non-trivial calls to the sprintf family of functions under a new option -Wformat-length=[12]. This initial patch handles printf directives with string,

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

On 07/01/2016 08:15 PM, Martin Sebor wrote: diff --git a/gcc/passes.c b/gcc/passes.c index 0565cfa..008799c 100644 --- a/gcc/passes.c +++ b/gcc/passes.c @@ -2425,8 +2425,15 @@ execute_pass_list_1 (opt_pass *pass) if (cfun == NULL) return; + + // inform (0, "executing pass:

Re: RFC (attributes): PATCH for c++/50800 to set affects_type_identity for may_alias

On 06/23/2016 09:39 PM, Jason Merrill wrote: -/* { dg-final { scan-assembler "_ZN1AIdEC1Ev" } } */ +/* { dg-final { scan-assembler "_ZN1AIU9may_aliasdEC1Ev" } } */ I find this rather worrying. In glibc, we want to use the may_alias attribute on struct sockaddr_storage for POSIX conformance.

Re: C PATCH to add -Wswitch-unreachable (PR c/49859)

On 05/23/2016 12:16 PM, Marek Polacek wrote: Can we document what a programmer needs to do to suppress the warning? My worry is that the warning will be too unpredictable to be useful. Why would you suppress the warning? Just delete the code that cannot be executed anyway. And what is

Re: Thoughts on memcmp expansion (PR43052)

On 01/15/2016 05:58 PM, Bernd Schmidt wrote: One question Richard posed in the comments: why aren't we optimizing small constant size memcmps other than size 1 to *s == *q? The reason is the return value of memcmp, which implies byte-sized operation (incidentally, the use of SImode in the

Re: C PATCH to add -Wswitch-unreachable (PR c/49859)

On 05/20/2016 06:36 PM, Marek Polacek wrote: --- gcc/gimplify.c +++ gcc/gimplify.c @@ -1595,6 +1595,32 @@ gimplify_switch_expr (tree *expr_p, gimple_seq *pre_p) gimplify_ctxp->case_labels.create (8); gimplify_stmt (_BODY (switch_expr), _body_seq); + + /* Possibly warn about

Re: [committed] Cherry-pick upstream asan fix for upcoming glibc (PR sanitizer/71160)

On 05/17/2016 04:46 PM, Jakub Jelinek wrote: On Tue, May 17, 2016 at 05:38:27PM +0300, Maxim Ostapenko wrote: Hi Jakub, thanks for backporting this! Do you have any plans to apply this patch to GCC 5 and 6 branches? AFAIK people hit on this ASan + newer Glibc bug by using GCC 5.3.1 on Fedora

Re: C++ PATCH for range-for tweak

* Jason Merrill: > On 03/14/2016 05:30 PM, Florian Weimer wrote: >> * Jason Merrill: >> >>> P08184R0: Generalizing the Range-Based For Loop >> >> How can one resolve this reference? It's obviously not a PR number in >> GCC Bugzill

Re: C++ PATCH for range-for tweak

* Jason Merrill: > P08184R0: Generalizing the Range-Based For Loop How can one resolve this reference? It's obviously not a PR number in GCC Bugzilla. I found this after some searching: But it lacks the additional

Re: [PATCH 1/2][ARM] PR/65956 AAPCS update for alignment attribute

On 11/27/2015 06:55 PM, Eric Botcazou wrote: > There is no official ABI for Ada so I guess that's not really a problem as > long as it's documented on https://gcc.gnu.org/gcc-5/changes.html. It's still surprising to make such a far-reaching change in a minor release, I think. Florian

Re: [PATCH 1/2][ARM] PR/65956 AAPCS update for alignment attribute

On 11/04/2015 02:13 PM, Jakub Jelinek wrote: > On Mon, Jul 06, 2015 at 05:38:35PM +0100, Alan Lawrence wrote: >> Trying to push these now (svn!), patch 2 is going first. >> >> I realize my second iteration of patch 1/2, dropped the testcases from the >> first version. Okay to include those as per

Re: [PATCH 7/9] i386: Add address space for tls

On 10/08/2015 06:59 AM, Richard Henderson wrote: >cpp_define (parse_in, "__SEG_FS"); >cpp_define (parse_in, "__SEG_GS"); > + cpp_define (parse_in, "__SEG_TLS"); Is there a good place to document these #defines? I looked at your glibc patch and wonder where __SEG_TLS was coming from.

Re: [patch] libstdc++/67747 Allocate space for dirent::d_name

On 10/02/2015 02:37 PM, Sebastian Huber wrote: > > > On 02/10/15 14:16, Florian Weimer wrote: >> On 09/29/2015 01:37 PM, Jonathan Wakely wrote: >>> >POSIX says that dirent::d_name has an unspecified length, so calls to >>> >readdir_r must p

Re: [patch] libstdc++/67747 Allocate space for dirent::d_name

On 10/02/2015 02:34 PM, Jonathan Wakely wrote: > On 02/10/15 14:16 +0200, Florian Weimer wrote: >> On 09/29/2015 01:37 PM, Jonathan Wakely wrote: >>> POSIX says that dirent::d_name has an unspecified length, so calls to >>> readdir_r must pass a buffer with enough trail

Re: [patch] libstdc++/67747 Allocate space for dirent::d_name

On 09/29/2015 01:37 PM, Jonathan Wakely wrote: > POSIX says that dirent::d_name has an unspecified length, so calls to > readdir_r must pass a buffer with enough trailing space for > {NAME_MAX}+1 characters. I wasn't doing that, which works OK on > GNU/Linux and BSD where d_name is a large array,

[PATCH COMMITTED] Update MAINTAINERS

Just an email address update. Index: ChangeLog === --- ChangeLog (revision 228382) +++ ChangeLog (working copy) @@ -1,3 +1,7 @@ +2015-10-02 Florian Weimer <fwei...@redhat.com> + + * MAINTAINERS: Update email address. + 2015

Re: [patch] libstdc++/67747 Allocate space for dirent::d_name

On 10/02/2015 07:37 PM, Martin Sebor wrote: > I'm not sure what you are basing this assertion on. In the man > pages I have looked at, memcpy is documented as MT-Safe. readdir > is documented as MT-Unsafe. The Unsafe definition is clear: > contains global and static data that is not protected. I

Re: [patch] libstdc++/67747 Allocate space for dirent::d_name

On 10/02/2015 07:53 PM, Martin Sebor wrote: > Here's the older page: > http://docs.oracle.com/cd/E19683-01/816-0213/6m6ne3895/index.html > > With that, I agree that using readdir is thread-safe on Solaris 11.2. > It is not safe on Solaris 9, and it would not be safe on other systems > that don't

Re: [patch] libstdc++/67747 Allocate space for dirent::d_name

On 10/02/2015 06:57 PM, Martin Sebor wrote: > Readdir isn't required to be thread-safe (it may reference global > data) so calling it in multiple threads even with a different dirp > argument is undefined. A thread-unsafe implementation can meet the > POSIX requirement and still access global

Re: [patch] Enable lightweight checks with _GLIBCXX_ASSERTIONS.

glibc level (perhaps guarded by _FORTIFY_SOURCE) because C programs would benefit as well. We'd need performance numbers to justify the change. Any ideas how to get them? Benchmark MariaDB? What's another large multi-threaded application? Qpid perhaps? -- Florian Weimer / Red Hat Product Security

Re: [patch] Enable lightweight checks with _GLIBCXX_ASSERTIONS.

s are already error-checking in that sense (self-deadlock cannot happen, and an unlock when not lock is defined to return an error), so I don't think anything like that is even needed. -- Florian Weimer / Red Hat Product Security

Re: [C++ Patch] PR 53184 ("Unnecessary anonymous namespace warnings")

tion unit because any definition in another translation unit would be an ODR violation, so they can be put into the anonymous namespace themselves. -- Florian Weimer / Red Hat Product Security

Re: [patch] Enable lightweight checks with _GLIBCXX_ASSERTIONS.

pect the libstdc++ changes to be similar. Again, my main argument is that the main users of _FORTIFY_SOURCE are distributions, and they would inject whatever preprocessor macro enables the new libstdc++ checks anyway, so saving them that work would be preferable IMHO. -- Florian Weimer / Red Hat Product Security

Re: [patch] Enable lightweight checks with _GLIBCXX_ASSERTIONS.

On 09/10/2015 06:30 PM, Martin Sebor wrote: > On 09/09/2015 09:58 AM, Florian Weimer wrote: >> On 09/08/2015 05:45 PM, Jonathan Wakely wrote: >> >>>> I doubt we can achieve the complexity goals in all cases. I expect >>>> that >>>> >>

Re: [patch] Enable lightweight checks with _GLIBCXX_ASSERTIONS.

ecision right away. I think we should try with _FORTIFY_SOURCE first. The above case looks rather artificial. If there is a visible performance impact, maybe we can get the compiler to eliminate the vector bounds checks in many cases. -- Florian Weimer / Red Hat Product Security

Re: [patch] Enable lightweight checks with _GLIBCXX_ASSERTIONS.

On 09/07/2015 09:59 PM, Jonathan Wakely wrote: > On 07/09/15 21:31 +0200, Florian Weimer wrote: >> * Jonathan Wakely: >> >>> This patch adds the "debug mode lite" we've been talking about, by >>> changing __glibcxx_assert to be activated by _GLIBC

Re: [patch] Enable lightweight checks with _GLIBCXX_ASSERTIONS.

* Jonathan Wakely: > This patch adds the "debug mode lite" we've been talking about, by > changing __glibcxx_assert to be activated by _GLIBCXX_ASSERTIONS > instead of _GLIBCXX_DEBUG (and making the latter imply the former). Interesting. Is this mode ABI-compatible with the default mode? Should

[PATCH] [Ada] Make the stack non-executable in GNAT tools

Due to PR67205, the deeply nested instantiations require trampolines, which in turn requires an executable stack for the GNAT tools on architectures such as x86_64. Bootstrapped on x86_64-redhat-linux-gnu, and make check-ada reports no unexpected failures. Okay for trunk? -- Florian Weimer

Re: [PATCH 2/9] New template fibonacci_heap class introduced.

On 11/13/2014 09:06 PM, mliska wrote: + Insert: O(2) amortized. O(1) actual. This does not make much sense. Typo? -- Florian Weimer / Red Hat Product Security

Re: Enable EBX for x86 in 32bits PIC code

__builtin_cpuid builtin and cleanup cpiud.h. It also makes writing solid inline assembly which has to use %ebx for some reason much easier. We just fixed a glibc bug related to that. -- Florian Weimer / Red Hat Product Security

Re: [PATCH] proposed fix for bug # 61144

' for z::aaa. With the patch the reference to z::aaa is not folded, but its definition is not emitted either, so a undefined reference error is produced at link time. Technically, this is not a bug (for C++03 at least). But I do think folding the constant is an important optimization. -- Florian

-finit-local-vars option

is implemented, it interferes with unused-variable warnings. I just want to archive it for posterity. -- Florian Weimer / Red Hat Product Security Team commit dbb1a7d8ee583466f00502848866fbfe5f5e2ca8 Author: Florian Weimer fwei...@redhat.com Date: Thu Jun 5 10:16:34 2014 +0200 Add -finit

Re: [PATCH] Provide inlining context in strict-overflow warnings

On 05/14/2014 11:34 AM, Richard Biener wrote: On Tue, May 13, 2014 at 9:27 PM, Florian Weimer fwei...@redhat.com wrote: Patterns that trigger the optimization and warning can form after inlining, and it can be rather difficult to figure out what exactly is causing the warning. The inlining

Re: [PATCH] Provide inlining context in strict-overflow warnings

On 05/14/2014 11:56 AM, Jakub Jelinek wrote: On Tue, May 13, 2014 at 09:27:08PM +0200, Florian Weimer wrote: Patterns that trigger the optimization and warning can form after inlining, and it can be rather difficult to figure out what exactly is causing the warning. The inlining context

<    1   2   3   4   5   6   >