https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114007
--- Comment #30 from Jakub Jelinek ---
Should be now fixed for GCC 13.3+ too, though in that case I've committed a
simplified version, which just parses the adjacent :: in __has_*attribute
argument, but yields in that case 0 in the strict
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114007
--- Comment #29 from GCC Commits ---
The releases/gcc-13 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:051cd2a3ee9ba9f47d640a10e96c79b6c5124736
commit r13-8392-g051cd2a3ee9ba9f47d640a10e96c79b6c5124736
Author: Jakub Jelinek
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114007
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114007
--- Comment #27 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:37127ed975e09813eaa2d1cf1062055fce45dd16
commit r14-9139-g37127ed975e09813eaa2d1cf1062055fce45dd16
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114007
--- Comment #26 from Iain Sandoe ---
but from your initial post it's also guarded by:
#ifndef __has_cpp_attribute
#define __has_cpp_attribute(x) 0
#endif
so it will always be 0 for clang in C mode, since that does not define
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114007
--- Comment #25 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #24 from Jakub Jelinek ---
> (In reply to fxcoud...@gmail.com from comment #19)
>> I haven’t yet tested Xcode 13.3 myself, and have only followed the PRs from
>> far
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114007
--- Comment #24 from Jakub Jelinek ---
(In reply to fxcoud...@gmail.com from comment #19)
> I haven’t yet tested Xcode 13.3 myself, and have only followed the PRs from
> far away. Are there any issues (SDK, linker, or otherwise) that we need to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114007
--- Comment #23 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #22 from Iain Sandoe ---
> (In reply to r...@cebitec.uni-bielefeld.de from comment #21)
>> > --- Comment #19 from fxcoudert at gmail dot com > com> ---
>
>
>> The only
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114007
--- Comment #22 from Iain Sandoe ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #21)
> > --- Comment #19 from fxcoudert at gmail dot com > com> ---
> The only issue left (the gcc.dg/framework-1.c failure) so far seems to
> be an
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114007
--- Comment #21 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #19 from fxcoudert at gmail dot com
> ---
> Hi Rainer,
>
>> Thanks a lot for the patch. I've now re-bootstrapped trunk on macOS 14
>> with it applied instead of the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114007
--- Comment #19 from fxcoudert at gmail dot com ---
Hi Rainer,
> Thanks a lot for the patch. I've now re-bootstrapped trunk on macOS 14
> with it applied instead of the local (incomplete)
> workaround.
I haven’t yet tested Xcode 13.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114007
--- Comment #19 from fxcoudert at gmail dot com ---
Hi Rainer,
> Thanks a lot for the patch. I've now re-bootstrapped trunk on macOS 14
> with it applied instead of the local (incomplete)
> workaround.
I haven’t yet tested Xcode 13.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114007
--- Comment #18 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #17 from Jakub Jelinek ---
> Created attachment 57483
> --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57483=edit
> gcc14-pr114007.patch
>
> So far very lightly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114007
Jakub Jelinek changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114007
--- Comment #16 from Joseph S. Myers ---
I think it's clear that __has_c_attribute(gnu::unused) should only return 1 if
the [[gnu::unused]] syntax is actually parsed. (An unavoidable limitation if it
might return 1 in pre-C23 modes is that if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114007
--- Comment #15 from Jakub Jelinek ---
(In reply to Richard Sandiford from comment #14)
> I might have misunderstood the suggestion and so be arguing against
> something that no-one is suggesting, but I think [[__extension__ …]] should
> accept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114007
--- Comment #14 from Richard Sandiford ---
I might have misunderstood the suggestion and so be arguing against something
that no-one is suggesting, but I think [[__extension__ …]] should accept the
same things for all standard versions (C23,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114007
Jakub Jelinek changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114007
Iain Sandoe changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114007
--- Comment #11 from Iain Sandoe ---
looking at n2176 - C18 there is no mention of __has_c*
looking at n3047 - C23 there is mention only of __has_c_attribute
OTOH, there is no prohibition in declaring __has_cpp_attribute (c.f. an actual
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114007
--- Comment #10 from Iain Sandoe ---
indeed, it seems clang does not define __has_cpp_attribute for -std=c11 c
compilations, whereas GCC does.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114007
--- Comment #9 from Jakub Jelinek ---
Ah, but they accept the version with __has_cpp_attribute only.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114007
--- Comment #8 from Jakub Jelinek ---
Anyway,
#ifdef __has_c_attribute
#if __has_c_attribute (clang::unsafe_buffer_usage)
int i;
#endif
#endif
#ifdef __has_cpp_attribute
#if __has_cpp_attribute (clang::unsafe_buffer_usage)
int j;
#endif
#endif
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114007
--- Comment #7 from Jakub Jelinek ---
Well, my testcase didn't have those
#ifdef __has_c_attribute
and likewise for __has_cpp_attribute guards.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114007
--- Comment #6 from Iain Sandoe ---
(In reply to Iain Sandoe from comment #5)
> perhaps this is also a clang regression - for Jakub's example with Xcode
> 15.1 :
(xcode clang, that is, I did not test with upstream clang yet).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114007
--- Comment #5 from Iain Sandoe ---
perhaps this is also a clang regression - for Jakub's example with Xcode 15.1 :
$ clang --version
Apple clang version 15.0.0 (clang-1500.1.0.2.5)
Target: x86_64-apple-darwin23.3.0
master-wip-short-queue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114007
--- Comment #4 from Jakub Jelinek ---
Not to mention that predefining __has_cpp_attribute in such a public header
isn't a good idea.
They should take example from xxhash which does
#ifdef __has_attribute
# define XXH_HAS_ATTRIBUTE(x)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114007
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114007
--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #1 from Iain Sandoe ---
> Is this a clang extension (handling clang::x with -std= < c23)?
I can't tell: I was waiting for the preprocessor maintainers to comment.
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114007
Iain Sandoe changed:
What|Removed |Added
CC||fxcoudert at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114007
Rainer Orth changed:
What|Removed |Added
Target Milestone|--- |14.0
31 matches
Mail list logo
