Hi Dave,
On Mon, Jul 08, 2024 at 06:48:51PM GMT, David Malcolm wrote:
> > restrict, as of the formal definition of ISO C is useless crap. The
> > more I read it, the more I agree.
>
> Please note that "useless crap" was your wording, not mine.
Yup. :)
>
> >
> > restrict, as of what -Wrestri
On Tue, Jul 09, 2024 at 11:07:59AM +0200, Alejandro Colomar wrote:
> > > restrict, as of what -Wrestrict warns about, seems a reasonable
> > > thing.
> > >
> > > How about a [[gnu::restrict()]] attribute, similar to
> > > [[gnu::access()]],
> > > which is simpler than the qualifier? Since restric
Hi Martin,
On Tue, Jul 09, 2024 at 07:58:40AM GMT, Martin Uecker wrote:
> Am Montag, dem 08.07.2024 um 22:17 +0200 schrieb Alejandro Colomar:
> > Hi Martin,
> >
> > On Mon, Jul 08, 2024 at 06:05:08PM GMT, Martin Uecker wrote:
> > > Am Montag, dem 08.07.2024 um 17:01 +0200 schrieb Alejandro Coloma
Hi Jakub,
On Tue, Jul 09, 2024 at 11:18:11AM GMT, Jakub Jelinek wrote:
> On Tue, Jul 09, 2024 at 11:07:59AM +0200, Alejandro Colomar wrote:
> > Yup, I was thinking that maybe noalias is a better name.
>
> Name is one thing, but you'd also need to clearly define what it means.
> When restrict is a
On Tue, Jul 09, 2024 at 12:28:18PM GMT, Alejandro Colomar wrote:
> Hi Jakub,
>
> On Tue, Jul 09, 2024 at 11:18:11AM GMT, Jakub Jelinek wrote:
> > On Tue, Jul 09, 2024 at 11:07:59AM +0200, Alejandro Colomar wrote:
> > > Yup, I was thinking that maybe noalias is a better name.
> >
> > Name is one t
On 7/8/24 00:52, Alejandro Colomar wrote:
> a small set of functions
> accept pointers that alias each other, but one of them is never
> accessed; in those few cases, restrict was added to the parameters in
> ISO C, but I claim it would be better removed.
Are these aliasing pointers the nptr and
Hi all,
I'm currently trying to implement Native TLS on a platform that gcc uses
emutls for at the moment, but I can't seem to figure out where and how to
implement it. I have a rough idea of the assembly required for TLS on this
platform, but I don't know where to plug it in to the compiler to ma
Is it possible to specify a default value in
define_code_attr resp. define_mode_attr ?
I had a quick look at read-rtl, and it seem to be not the case.
Or am I missing something?
Johann
Hi Paul,
On Tue, Jul 09, 2024 at 02:09:24PM GMT, Paul Eggert wrote:
> On 7/8/24 00:52, Alejandro Colomar wrote:
> > a small set of functions
> > accept pointers that alias each other, but one of them is never
> > accessed; in those few cases, restrict was added to the parameters in
> > ISO C, but
Georg-Johann Lay writes:
> Is it possible to specify a default value in
> define_code_attr resp. define_mode_attr ?
>
> I had a quick look at read-rtl, and it seem to be not the case.
Yeah, that's right. I'd assumed the attributes would be used
in cases where an active choice has to be made for
Hi Daniel,
On Sun, Jul 07, 2024 at 03:46:48PM GMT, Daniel Plakosh wrote:
> Alex,
>
> Your document number is below:
>
> n3294 - strtol(3) et al. shouldn't have a restricted first parameter
>
> Please return the updated document with this number
Am I allowed to retitle the paper?
n3294 - [[n
Alejandro,
Sure please remind me when you submit
Best regards,
Dan
Technical Director - Enabling Mission Capability at Scale
Principal Member of the Technical Staff
Software Engineering Institute
Carnegie Mellon University
4500 Fifth Avenue
Pittsburgh, PA 15213
WORK: 412-268-7197
CELL: 412-427-
Here's a proposal for adding a function attribute for replacing
the restrict restrict qualifier. It's v0.3 of n3294 (now we have a
document number).
I was going to name it [[noalias()]], but I thought that it would be
possible to mark several pointers as possibly referencing the same
object, and
Friday July 12, 16:00 UTC
https://bbb.sfconservancy.org/b/mar-aom-dmo-fko
Using #overseers on irc.libera.chat as backup.
To get the right time in your local timezone:
$ date -d "Fri Jul 12 16:00 UTC 2024"
Sourceware relies on cooperation among a broad diversity of core
toolchain and developer too
Hi Mark,
David Malcolm wrote:
> On Tue, 2024-07-02 at 22:39 +0200, Mark Wielaard wrote:
> > Is there an "optimal" optimization level for -fanalyzer (like having
> > -Og for debugging)?
>
> There isn't, sorry.
What I do is compile several times in a loop, with all optimization
levels, to maximize
15 matches
Mail list logo
