o implement on ASTs with a strong relationship to source
code.
I'm not sure how to proceed. Are there plans to move the C and C++
front ends to more concrete ASTs? Would we be willing to accept a
slight performance hit from that?
--
Florian Weimer / Red Hat Product Security Team
d
On 05/13/2014 12:12 PM, niXman wrote:
I'm curious whether there is reason to use 'vfork()' rather than 'fork()'?
Without memory overcommitment, fork needs physical backing storage (RAM
or swap) for all copy-on-write pages in the new process. vfork doesn't.
stions are more appropriate for the gcc-help
mailing list.)
--
Florian Weimer / Red Hat Product Security Team
rom Sphinx across versions? Will this
potentially cause a lot of update churn?
--
Florian Weimer / Red Hat Product Security Team
ons of autoconf (or requiring a specific
version).
Hmm. Can virtualenv arrange for a specific sphinx version and its
dependencies? Then it's likely not a big deal, even though it's less
self-contained than autoconf.
--
Florian Weimer / Red Hat Product Security Team
r which a prototype exists (relative to the non-prototype case). It
happens on i386, too.
--
Florian Weimer / Red Hat Product Security Team
mes a
quality-of-implementation issue? I'm pretty sure the standards do not
require a particular behavior in such cases.
--
Florian Weimer / Red Hat Product Security Team
;d need to
map with PROT_NONE in order to avoid that.
At present, it is necessary to run with vm.overcommit_memory=0 (or 1),
with vm.overcommit_memory=2, there will be test suite failures. I
suspect that there is a possibility to hit this on loaded systems even
with vm.overcommit_memory=0.
--
qsort(vec.data(), vec.size(), sizeof(T), comparefn);
}
I think this is quite surprising. What can we do about it?
--
Florian Weimer / Red Hat Product Security Team
mon.
We could make vector::data() guarantee a non-null pointer with
_FORTIFY_SOURCE, but I'd rather not do so in "unfortified" code. Some
users would object to the extra check needed.
Or we could remove the nonnull attributes, so that the additional checks
are not necessary.
--
On 06/17/2014 04:24 PM, Trevor Saunders wrote:
On Tue, Jun 17, 2014 at 02:41:38PM +0200, Florian Weimer wrote:
On 06/12/2014 12:04 PM, Jonathan Wakely wrote:
What can we do about it?
How common is it to use std::vector with qsort, rather than
std::sort(vec.begin(), vec.end()), which does
On 06/17/2014 04:39 PM, Jakub Jelinek wrote:
On Tue, Jun 17, 2014 at 04:34:16PM +0200, Florian Weimer wrote:
I'm not that familiar with the exact requirements of std::vector, could
we use the same trick as
http://mxr.mozilla.org/mozilla-central/source/xpcom/glue/nsTArray.h#275
that is in
blem in C++ (I think), but the alignment is an issue.
Alignment for what? You don't specify any alignment to the C qsort,
You're returning a T *, not a void *, and C++ requires that pointers are
properly aligned even if they aren't dereferenced.
--
Florian Weimer / Red Hat Product Security Team
we have a misunderstanding. I assumed you were talking about the
data() member of std::vector.
--
Florian Weimer / Red Hat Product Security Team
ntrol flow statements have already been rewritten at this stage,
so it may not be helpful to you.
--
Florian Weimer / Red Hat Product Security
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
w" attribute on external
hyperlinks? Allegedly, it provides a disincentive to spammers.
--
Florian Weimer / Red Hat Product Security
inters”.
Nowdays, there is -fsanitize=object-size, but I don't know if it uses
VLA lengths: <https://gcc.gnu.org/ml/gcc-patches/2014-07/msg00923.html>
Historically, propagation of object sizes from malloc and VLAs to
__builtin_object_size was rather incomplete.
--
Florian Weimer / Red Hat Product Security
On 09/03/2014 05:20 PM, Joseph S. Myers wrote:
On Wed, 3 Sep 2014, Florian Weimer wrote:
On 09/02/2014 11:22 PM, James Nelson wrote:
This is error-prone because even though a size parameter is given, the code
in the function has no requirement to enforce it. With a bounded array
type, the
On 11/11/2014 11:33 AM, Prathamesh Kulkarni wrote:
Why does moving definition of simplify constructor outside the class cause
out of memory allocation ?
It's probably because you dropped the initialization of the capture_max
member.
--
Florian Weimer / Red Hat Product Security
aders look okay, so I suspect this is
a Firefox bug.
--
Florian Weimer / Red Hat Product Security
* DJ Delorie:
> pins...@gmail.com writes:
>> No because they are c++ code so capital C is correct.
>
> However, we should avoid relying on case-sensitive file systems
> (Windows) and use .cc or .cxx for C++ files
Aren't current Windows file systems case-preserving? Then they
shouldn't have no p
re. We should extend it, as a QoI
matter, and support null pointers for variable-length inputs and outputs
if the size is 0. But I suspect this is still a minority view.
--
Florian Weimer / Red Hat Product Security
when most of the design was already settled.
--
Florian Weimer / Red Hat Product Security
On 02/20/2015 12:43 PM, Jonathan Wakely wrote:
> On 20 February 2015 at 11:06, Florian Weimer wrote:
>> On 02/19/2015 09:56 PM, Sandra Loosemore wrote:
>>> H, Passing the additional option in user code would be one thing,
>>> but what about library code? E.g., usin
y correct with -fwrapv, and it passes code review.
I fear that's not going to change, ever.
--
Florian Weimer / Red Hat Product Security
__alignof__ (max_align_t) appears to be stuck at 16, even though some
AVX512 operations require 512 byte alignment.
Is this intentional? There are arguments for (more ABI compatibility)
and against (max_align_t is misleading) this behavior.
--
Florian Weimer / Red Hat Product Security
On 03/23/2015 07:34 PM, Joseph Myers wrote:
> On Mon, 23 Mar 2015, Florian Weimer wrote:
>
>> __alignof__ (max_align_t) appears to be stuck at 16, even though some
>> AVX512 operations require 512 byte alignment.
>>
>> Is this intentional? There are arguments for (
trast to other front ends, “%(cc1_options)” is missing, so
Fedora's approach to hardening flag injection does not work.
Can we just add “%(cc1_options)”, or is there a reason why it is missing?
--
Florian Weimer / Red Hat Product Security
ognized
> by gnat1.
Would it be possible to add some other injection mechanism so that it is
possible customize the gnat1 flags using the specs file mechanism?
--
Florian Weimer / Red Hat Product Security
customize the gnat1 flags using the specs file mechanism?
>
> Yes, defining a common set of base options would be welcome.
Doesn't common.opt serve this purpose? But if I understand you
correctly, the Ada front end alters semantics of flags in common.opt,
which means we are in a bit of
On 03/23/2015 07:41 PM, Florian Weimer wrote:
> Ah, I should have looked at what max_align_t actually meant. With these
> semantics, the name is a bit confusing. I agree that requiring 64 byte
> alignment from malloc does not make much sense. Thanks.
Follow-up question: Can malloc
plement
for this architecture. (dlmalloc in glibc is an exception.)
--
Florian Weimer / Red Hat Product Security
On 04/02/2015 01:06 PM, H.J. Lu wrote:
> On Thu, Apr 2, 2015 at 1:46 AM, Florian Weimer wrote:
>> On 04/02/2015 10:40 AM, Andrew Haley wrote:
>>
>>> So, max_align_t is an object type, and therefore malloc returns a
>>> pointer suitable for max_align_t.
>>
&g
On 04/02/2015 01:13 PM, H.J. Lu wrote:
> On Thu, Apr 2, 2015 at 4:08 AM, Florian Weimer wrote:
>> On 04/02/2015 01:06 PM, H.J. Lu wrote:
>>> On Thu, Apr 2, 2015 at 1:46 AM, Florian Weimer wrote:
>>>> On 04/02/2015 10:40 AM, Andrew Haley wrote:
>>>>
&g
On 04/02/2015 01:34 PM, Joseph Myers wrote:
> On Thu, 2 Apr 2015, Florian Weimer wrote:
>
>> On 04/02/2015 01:06 PM, H.J. Lu wrote:
>>> On Thu, Apr 2, 2015 at 1:46 AM, Florian Weimer wrote:
>>>> On 04/02/2015 10:40 AM, Andrew Haley wrote:
>>>>
ong double, whose size is almost certainly larger than 1)?
--
Florian Weimer / Red Hat Product Security
re heap allocation of small objects to waste extra space.
Contrary to what I thought initially, it is not possible to reduce the
alignment of max_align_t because it still has to match that of long
double, a basic type which is defined to have fundamental alignment.
So my conclusion now is that DR445 w
pted the extra 16 bytes?
What's the alignment of max_align_t on this architecture?
Although it should be possible to get a 16-byte aligned 1-byte object in
any (however misaligned) 16-byte window on the stack …
--
Florian Weimer / Red Hat Product Security
On 09/13/2018 03:27 PM, Wilco Dijkstra wrote:
Hi,
The existing sincos functions use 2 pointers to return the sine and cosine
result. In
most cases 4 memory accesses are necessary per call. This is inefficient and
often
significantly slower than returning values in registers. I ran a few
exper
* Rasmus Villemoes:
> This is something I've sometimes found myself wishing was supported. The
> idea being that one can say
>
> unsigned a[] = { [0] = 1, [1] = 3, [0] |= 4, ...}
>
> which would end up initializing a[0] to 5. As a somewhat realistic
> example, suppose one is trying to build a bitm
* Jonathan Wakely:
> On Sun, 14 Oct 2018 at 20:46, Florian Weimer wrote:
>>
>> * Rasmus Villemoes:
>>
>> > This is something I've sometimes found myself wishing was supported. The
>> > idea being that one can say
>> >
>> > unsigned
* Aaron Sawdey:
> I've previously posted a patch to add vector/vsx inline expansion of
> strcmp/strncmp for the power8/power9 processors. Here are some of the
> other items I have in the pipeline that I hope to get into gcc9:
>
> * vector/vsx support for inline expansion of memcmp to non-loop code
* Martin Sebor:
> At the same time, the following passes on x86_64:
>
> __attribute__ ((aligned (1))) void f1 (void) { }
> _Static_assert (__alignof__ (f1) == 1); // wrong alignof result
>
> __attribute__ ((aligned)) void f0 (void) { }
> _Static_assert (__alignof__ (f0) == 16);
>
> __a
* Aaron Sawdey:
> If you are aware of any real world code that is faster when built
> with -fno-builtin-strcmp and/or -fno-builtin-strncmp, please let me know
> so I can look at avoiding those situations.
Sorry, I have not tried to benchmark this.
One more question: There's a hardware erratum on
* Bill Schmidt:
> I don't think we have a real concern here. DD2.1 is used in a particular
> situation where GCC 4.8.5 is the supported compiler, and not used elsewhere.
> So I'd prefer not to cripple the compiler for this specific use case. If
> the customer with DD2.1 hardware chooses to use G
* Richard Biener:
> The cost is probably target dependent - on x86 it's simply a $fs based
> load/store.
Do you need to reserve something in the TCB for this?
Thanks,
Florian
* Richard Biener:
> On Wed, 19 Dec 2018, Florian Weimer wrote:
>
>> * Richard Biener:
>>
>> > The cost is probably target dependent - on x86 it's simply a $fs based
>> > load/store.
>>
>> Do you need to reserve something in the TCB for this?
* Richard Biener:
> Sure, if we'd ever deploy this in production placing this in the
> TCB for glibc targets might be beneifical. But as said the
> current implementation was just an experiment intended to be
> maximum portable. I suppose the dynamic loader takes care
> of initializing the TCB d
* Peter Bergner:
> On 12/19/18 7:59 AM, Florian Weimer wrote:
>> * Richard Biener:
>>
>>> Sure, if we'd ever deploy this in production placing this in the
>>> TCB for glibc targets might be beneifical. But as said the
>>> current implementation wa
Can we remove __has_include__?
Its availability results in code which is needlessly non-portable
because for some reason, people write __has_include__ instead of
__has_include. (I don't think there is any difference.)
Thanks,
Florian
* Jakub Jelinek:
> On Thu, Jan 10, 2019 at 03:20:59PM +0100, Florian Weimer wrote:
>> Can we remove __has_include__?
>
> No.
>
>> Its availability results in code which is needlessly non-portable
>> because for some reason, people write __has_include__ instead of
>
* Jakub Jelinek:
> Because the magic builtin is a preprocessor builtin, kind of macro,
> so you can't have a normal macro with the same name.
Could we turn this kind-of-macro into something that can be tested using
#ifdef?
Thanks,
Florian
* Nathan Sidwell:
> On 1/10/19 9:32 AM, Jakub Jelinek wrote:
>> On Thu, Jan 10, 2019 at 03:20:59PM +0100, Florian Weimer wrote:
>>> Can we remove __has_include__?
>>
>> No.
>>
>>> Its availability results in code which is needlessly non-porta
* Richard Biener:
>> Since the introduction of GNU Property notes this is (sadly) no longer
>> the correct way to iterate through ELF notes. The padding of names and
>> desc might now depend on the alignment of the PT_NOTE segment.
>> https://sourceware.org/ml/binutils/2018-09/msg00359.html
>
> I
Would it be possible to turn libgcc_s.so into a linker script that links
against libgcc.a and libgcc_s.so.1, and teach g++ not to link against
libgcc.a explicitly anymore?
I'm suggesting this because libtool uses -nostdlib when linking shared
objects in C++ mode, and does not link against -lgcc, o
* Joseph Myers:
> On Wed, 13 Mar 2019, Florian Weimer wrote:
>
>> Would it be possible to turn libgcc_s.so into a linker script that links
>> against libgcc.a and libgcc_s.so.1, and teach g++ not to link against
>> libgcc.a explicitly anymore?
>
> It is already a li
* Florian Weimer:
> * Joseph Myers:
>
>> On Wed, 13 Mar 2019, Florian Weimer wrote:
>>
>>> Would it be possible to turn libgcc_s.so into a linker script that links
>>> against libgcc.a and libgcc_s.so.1, and teach g++ not to link against
>>> libgc
* Justin Paston-Cooper:
> Tom Tromey suggested in that thread that this would be quite easy on
> gdb's side if gcc indicates exit locations in the DWARF data, for
> instance in the C case, it would indicate the locations of return
> statements. On a related note, he mentions that the "finish" comm
* Justin Paston-Cooper:
> On Tue, 19 Mar 2019 at 21:29, Florian Weimer wrote:
>>
>> * Justin Paston-Cooper:
>>
>> > Tom Tromey suggested in that thread that this would be quite easy on
>> > gdb's side if gcc indicates exit locations in the DWARF dat
* Justin Paston-Cooper:
> On Tue, 19 Mar 2019 at 21:52, Florian Weimer wrote:
>>
>> * Justin Paston-Cooper:
>>
>> > On Tue, 19 Mar 2019 at 21:29, Florian Weimer wrote:
>> >>
>> >> * Justin Paston-Cooper:
>> >>
>> &
* Szabolcs Nagy:
> AAELF64: in the Symbol Table section add
>
> st_other Values
> The st_other member of a symbol table entry specifies the symbol's
> visibility in the lowest 2 bits. The top 6 bits are unused in the
> generic ELF ABI [SCO-ELF], and while there are no val
* Szabolcs Nagy:
> On 22/05/2019 16:06, Florian Weimer wrote:
>> * Szabolcs Nagy:
>>
>>> AAELF64: in the Symbol Table section add
>>>
>>> st_other Values
>>> The st_other member of a symbol table entry specifies the symbol's
&
* Jeff Law:
> This is best addressed by changing GCC itself to know about the
> different ABIs. Trying to tackle in ASMs is going to be painful,
> particularly since your asms change the stack pointer and that's
> generally verboten for an ASM.
Standard practice is to use generic assembler tramp
* Segher Boessenkool:
>> <__GI___getdents64>:
>>0: addis r2,r12,0
>> 0: R_PPC64_REL16_HA .TOC.
>>4: addir2,r2,0
>> 4: R_PPC64_REL16_LO .TOC.+0x4
>>8: li r0,202
>>c: sc
>> 10: mfcr
Implicit function declarations were removed from C99, more than twenty
years ago. So far, GCC only warns about them because there were too
many old configure scripts where an error would lead to incorrect
configure check failures.
I can try to fix the remaining configure scripts in Fedora and sub
* Segher Boessenkool:
> On Thu, Jul 04, 2019 at 01:27:27PM +0200, Florian Weimer wrote:
>> Implicit function declarations were removed from C99, more than twenty
>> years ago. So far, GCC only warns about them because there were too
>> many old configure scripts where a
* Segher Boessenkool:
> Hi Florian,
>
> On Fri, Jul 05, 2019 at 07:49:21AM +0200, Florian Weimer wrote:
>> > We already have an option for that (-Werror=implicit-function-declaration),
>> > and it is an error by default with -pedantic-errors already. If you are
>>
* Jeff Law:
> On 7/17/19 11:29 AM, Andi Kleen wrote:
>> Romain Geissler writes:
>>>
>>> I have no idea of the LTO format and if indeed it can easily be updated
>>> in a backward compatible way. But I would say it would be nice if it
>>> could, and would allow adoption for projects spread on many
* Romain Geissler:
> That may fly in the open source world, however I expect some vendors
> shipping proprietary code might be fine with assembly/LTO
> representation of their product, but not source.
They can't ship LTO today anyway due to the format incompatibility, so
that's not really an argu
* Richard Biener:
> On Fri, Jul 19, 2019 at 10:30 AM Florian Weimer wrote:
>>
>> * Romain Geissler:
>>
>> > That may fly in the open source world, however I expect some vendors
>> > shipping proprietary code might be fine with assembly/LTO
>> >
* Sebastian Huber:
> Hello,
>
> On 06/06/2018 08:33, Florian Weimer wrote:
>> On 06/04/2018 07:36 PM, Jonathan Wakely wrote:
>>> On 4 June 2018 at 18:32, Marco Ippolito wrote:
>>>> Hi all,
>>>>
>>>> clang and VS2017 already support the C
* Martin Jambor:
> as you might know, Tejas is our Google Summer of Code student working on
> adding built-in functions for some new math functions added in ISO/IEC
> TS 18661.
>
> His next step is to expand "functions rounding result to narrower type"
> (so fadd, fsub and possibly fmul and fdiv d
* Richard Biener:
> On August 20, 2019 5:19:33 PM GMT+02:00, Nathan Sidwell
> wrote:
>>On 7/26/19 6:03 AM, Iain Sandoe wrote:
>>> Hello Sebastian,
>>>
>>>> On 26 Jul 2019, at 10:19, Florian Weimer wrote:
>>
>>>> C++ coroutine
* Nathan Sidwell:
> Is it time to deprecate traditional preprocessing? It's been 30
> years since C89. Are (non-compiler) tools that use it still things?
Doesn't imake still use it?
checking for cpp... /usr/bin/cpp
checking if /usr/bin/cpp requires -undef... yes
checking if /usr/bin/cpp requi
* Jakub Jelinek:
> On Thu, Sep 05, 2019 at 02:33:35PM +0200, Andreas Schwab wrote:
>> On Sep 05 2019, Nathan Sidwell wrote:
>>
>> > Is it time to deprecate traditional preprocessing? It's been 30 years
>> > since C89. Are (non-compiler) tools that use it still things?
>>
>> It's probably sti
I think since the upgrade to GCC 9.2 in Fedora, the glibc test
nptl/tst-cancelx18 (which is built with -fexceptions) fails on the Arm
32-bit architecture (and only there). I'm not 100% certain that it's
caused by the GCC update, but the patterns of failures and passes
strongly suggests that.
I do
* Florian Weimer:
> I think since the upgrade to GCC 9.2 in Fedora, the glibc test
> nptl/tst-cancelx18 (which is built with -fexceptions) fails on the Arm
> 32-bit architecture (and only there). I'm not 100% certain that it's
> caused by the GCC update, but the patterns
At Cauldron, the question came up whether the dynamic loader needs to
be taught about the new relocations for PC-relative addressing.
I think they would only matter if we supported PC-relative addressing
*and* text relocations. Is that really necessary?
These text relocations would not work reli
* Alan Modra:
> On Mon, Sep 23, 2019 at 09:42:52AM +0200, Florian Weimer wrote:
>> At Cauldron, the question came up whether the dynamic loader needs to
>> be taught about the new relocations for PC-relative addressing.
>>
>> I think they would only matter if we suppo
* Alan Modra:
> On Mon, Sep 23, 2019 at 10:37:29AM +0200, Florian Weimer wrote:
>> * Alan Modra:
>>
>> > On Mon, Sep 23, 2019 at 09:42:52AM +0200, Florian Weimer wrote:
>> >> At Cauldron, the question came up whether the dynamic loader needs to
>> >
* Alan Modra:
> On Mon, Sep 23, 2019 at 11:14:12AM +0200, Florian Weimer wrote:
>> * Alan Modra:
>>
>> > On Mon, Sep 23, 2019 at 10:37:29AM +0200, Florian Weimer wrote:
>> >> * Alan Modra:
>> >>
>> >> > On Mon, Sep 23, 201
* Gaius Mulley:
> gm2 does use GNU libpth (to create context and switch contexts).
> Although it doesn't need libpth for single process programs. I think
> the GNU libpth project is no longer maintained, so I've included it in:
>
> http://git.savannah.gnu.org/cgit/gm2.git/tree/gcc-versionno/libgm
* Gaius Mulley:
>> The question is whether this is really necessary. Obviously, there is
>> no requirement to ship all supporting code under the GPL version 3 or
>> later for GCC. See the libffi subdirectory, which has its own
>> license.
>
> sure I think it is looking sensible to stop using lib
December 2002.
>
> This means that the initialization of
> _rtld_global_ro._dl_page_size in elf/rtld.c with EXEC_PAGESIZE
> is sufficient for RISC-V.
>
> 2019-09-30 Florian Weimer
>
> riscv: Remove support for variable page sizes.
> * sysdeps/unix/sysv/linux/ris
* Steve Ellcey:
> I would like these used by default so I took some ideas from
> --with-advance-toolchain and used that to automatically add these options
> to LINK_SPEC (see attached patch). I can compile and link a program with
> this setup, but when I run the program I get:
>
> % ./x
> Inconsi
* Steve Ellcey:
> I am not sure, but my guess is that it is because I am building
> binutils (including ld) using --with-sysroot.
That could be the case. I guess there are two conflicting use cases for
sysroots, one where you want to mangle run-time paths to confine things
to the sysroot, and on
libstdc++ recently made an appearance in a glibc bug, which made me
realize that they aren't marked as NODELETE (on GNU ELF platforms).
(The bug in question was purely glibc, though.)
Are these shared objects really expected to be unloaded? Given that
libstdc++ contains many destructors, I expect
* Paul Koning:
> That's certainly a general rule. There is a reason why books aren't
> wide, and why newspapers have columns. The eye can't deal well with
> long lines. So while 132 column lines are certainly possible with
> modern computers, it doesn't mean they are desirable.
If the line sta
* J. Decker:
> Here's the gist of what I would propose...
> https://gist.github.com/d3x0r/f496d0032476ed8b6f980f7ed31280da
>
> In C, there are two operators . and -> used to access members of struct and
> union types. These operators are specified such that they are always paired
> in usage; for e
On 03/17/2017 02:30 PM, David Malcolm wrote:
Paraphrasing myself from that RFE: given that many IDEs can already
parse LANG=C output, presumably you'd want a command-line flag that
suppresses just the translation of "error" and "warning" etc, so that
instead of output of the form:
It probably s
On 04/19/2017 07:07 PM, Jonathan Wakely wrote:
I know it's a bit late, but I'd like to propose deprecating the
libstdc++ extension that allows arithmetic on std::atomic.
Currently we make it behave like arithmetic on void*, which is also a
GNU extension (https://gcc.gnu.org/onlinedocs/gcc/Pointer
On 04/20/2017 11:22 AM, Jonathan Wakely wrote:
On 20/04/17 10:18 +0100, Jonathan Wakely wrote:
On 20/04/17 08:19 +0200, Florian Weimer wrote:
On 04/19/2017 07:07 PM, Jonathan Wakely wrote:
I know it's a bit late, but I'd like to propose deprecating the
libstdc++ extension t
On 04/20/2017 11:25 AM, Jonathan Wakely wrote:
I mean, with -pedantic-errors we already error on void * arighmetics
or function pointer arithmetics. If std::atomic would use
the void * arithmetics, it would also reject it. Or does it use integer
arithmetics instead?
No, it does it on void*,
On 04/20/2017 11:39 AM, Jonathan Wakely wrote:
Or simply deprecate support for it in std::atomic. **If** the
extension for built-in types is useful then I can imagine it might be
useful to have it for std::atomic too, for a subset of the programs
relying on the original extension. But I'm unconvi
On 04/20/2017 11:52 AM, Jonathan Wakely wrote:
On 20/04/17 11:43 +0200, Florian Weimer wrote:
On 04/20/2017 11:25 AM, Jonathan Wakely wrote:
I mean, with -pedantic-errors we already error on void * arighmetics
or function pointer arithmetics. If std::atomic would use
the void * arithmetics
On 05/09/2017 01:36 AM, Daniel Santos wrote:
To further the usefulness of such techniques, I propose the addition of
a c-family attribute to declare a parameter, variable (and possibly
other declarations) as "constprop" or some similar word. The purpose of
the attribute is to:
1.) Emit a warn
* Martin Liška:
> validate(pfile.target_file.lstrip('b/'), line.target_line_no,
> line.value)
Violates line length constraint. :)
My own egrep script also checks for/switch/if/while/do on the same
line as "{", and "(" not preceded by whitespace (currently has false
positves with
On 05/15/2017 10:01 PM, David Edelsohn wrote:
Your understanding is correct. GCC never accepts patches for a
specific version / release -- even if it is the current release.
Patches for new features or support must be contributed to the current
development version.
Can't the patches be put on
* Steve Ellcey:
> I have a question about the use of IFUNCs in libatomic. I was looking at the
> arm implementation and in gcc/libatomic/config/linux/arm/host-config.h I see:
>
> extern bool libat_have_strexbhd HIDDEN;
> # define IFUNC_COND_1 libat_have_strexbhd
>
> I also see that
201 - 300 of 760 matches
Mail list logo
