On Tue, Sep 03, 2024 at 16:53:43 +0100, Iain Sandoe wrote:
> I think that might be a misunderstanding on the part of the author;
> AFAIU both GCC and MSVC _do_ require access to the sources at BMI
> consume-time to give decent diagnostics. I think that there might be
> confusion because the compi
On Fri, Sep 06, 2024 at 00:03:23 -0500, Jeremy Rifkin wrote:
> Hello,
>
> I'm looking at #pragma once behavior among the major C/C++ compilers as
> part of a proposal paper for standardizing #pragma once. (This is
> apparently a very controversial topic)
>
> To put my question up-front: Would GCC
On Fri, 2024-09-06 at 08:44 -0400, Ben Boeckel via Gcc wrote:
> On Tue, Sep 03, 2024 at 16:53:43 +0100, Iain Sandoe wrote:
> > I think that might be a misunderstanding on the part of the author;
> > AFAIU both GCC and MSVC _do_ require access to the sources at BMI
> > consume-time to give decent di
On Fri, Sep 06, 2024 at 09:30:26 -0400, David Malcolm wrote:
> On Fri, 2024-09-06 at 08:44 -0400, Ben Boeckel via Gcc wrote:
> > Does this have (additional) implications for caching tools and
> > modules?
> > They cache diagnostic output, but if these other paths showing up or
> > disappearing affe
On 9/6/24 9:41 AM, Ben Boeckel wrote:
On Fri, Sep 06, 2024 at 09:30:26 -0400, David Malcolm wrote:
On Fri, 2024-09-06 at 08:44 -0400, Ben Boeckel via Gcc wrote:
Does this have (additional) implications for caching tools and
modules?
They cache diagnostic output, but if these other paths showing
Hi,
I'm working on optimising assignments to the AArch64 Floating-point Mode
Register (FPMR), as part of our FP8 enablement work. Claudio has already
implemented FPMR as a hard register, with the intention that FP8 intrinsic
functions will compile to a combination of an fpmr register set, followe
Paul Eggert writes:
> One possible improvement would be to append "t32" if you want 32-bit time_t,
> instead of appending "t64" for 64-bit time_t. That way, people wouldn't be
> stuck with appending that confusing "t64" for the foreseeable future, and only
> specialists concerned with 32-bit time
Snapshot gcc-13-20240906 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/13-20240906/
and on various mirrors, see https://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 13 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch
Paul Eggert wrote:
> I'd rather just switch, as Debian has.
I'd go one step further, and not only
make the ABI transition without changing the canonical triplet,
but also
make gcc and clang define -D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64
among their predefines.
Rationale:
* We want that a
Arsen Arsenović wrote:
> An alternative that I pondered was to teach the linker about some notion
> of "compatibility strings" that it would compare and reject if
> different, plus teaching the compiler how to emit those, plus teaching
> glibc to tell the compiler to emit those.. We could have key
Thanks Andrew, I appreciate the context and links. It looks like the
prior implementation failed to handle links due to being based on file
path, given cpp_simplify_pathname. Do you have thoughts on the use if
device ID + inode as a way to also accommodate symbolic links and hard
links without the
Thanks Martin,
There's some context on N2896 in the meeting minutes:
https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2941.pdf
I think the key thing about N2896 is that it left unqualified #once
implementation-defined, which is no better than the current state of
affairs. I'm trying to approach
On Fri, Sep 6, 2024 at 5:49 PM Jeremy Rifkin wrote:
>
> Thanks Andrew, I appreciate the context and links. It looks like the
> prior implementation failed to handle links due to being based on file
> path, given cpp_simplify_pathname. Do you have thoughts on the use if
> device ID + inode as a way
> Could a "uses the relative search path" fact be used to mix into the
> file's identity? This way the `once` key would see "this content looked
> for things in directory `library_a`" and would see that
> `library_b/library_main.hpp`, despite the same content (and mtime) is
> actually a different c
Hi Andrew,
Thanks for the thoughts and quick reply.
> Not always. because inodes are not always stable on some file systems.
> And also does not work with multi-mounted devices too.
Unusual filesystems and multiple mounts are indeed the failing. As I
mentioned, there's no silver bullet; they each
On Fri, Sep 6, 2024, 7:42 PM Jeremy Rifkin wrote:
> Hi Andrew,
> Thanks for the thoughts and quick reply.
>
> > Not always. because inodes are not always stable on some file systems.
> > And also does not work with multi-mounted devices too.
>
> Unusual filesystems and multiple mounts are indeed
> This is why I said what is the a same file if you can't rely on inodes
> working?
I don't have a good answer for such a case. Of course, no matter how one
approaches #pragma once there will be cases that aren't handled.
The criteria to optimize for, imo, is which has the most clear failure
mo
17 matches
Mail list logo
