On 3/9/23 14:40, Jakub Jelinek wrote:
Hi!
The following testcase FAILs, because starting with r12-6028
the S class has only 2 bytes, not enough to hold one 7-bit bitfield, one 8-bit
bitfield and one 8-bit char field.
The reason is that when end_of_class attempts to compute dsize, it simply
adds
Hi!
The following testcase FAILs, because starting with r12-6028
the S class has only 2 bytes, not enough to hold one 7-bit bitfield, one 8-bit
bitfield and one 8-bit char field.
The reason is that when end_of_class attempts to compute dsize, it simply
adds byte_position of the field and DECL_SIZ
On Fri, 30 Sep 2022, Nathan Sidwell wrote:
> Hi,
> I've discovered some mangling problems with lambdas. (a) divergence from
> clang and (b) manglings that incorrectly demangle. With #a I'm not yet sure
> who is correct. for #b g++ is definitely wrong.
>
> From the docs, it doesn't appear to ha
On 9/30/22 09:43, Nathan Sidwell wrote:
Hi,
I've discovered some mangling problems with lambdas. (a) divergence
from clang and (b) manglings that incorrectly demangle. With #a I'm not
yet sure who is correct. for #b g++ is definitely wrong.
From the docs, it doesn't appear to have been bu
Hi,
I've discovered some mangling problems with lambdas. (a) divergence
from clang and (b) manglings that incorrectly demangle. With #a I'm not
yet sure who is correct. for #b g++ is definitely wrong.
From the docs, it doesn't appear to have been bumped this cycle. Is
that correct, and I
On 9/2/21 4:49 AM, Jakub Jelinek wrote:
On Thu, Sep 02, 2021 at 12:19:03AM +0200, Jakub Jelinek via Gcc-patches wrote:
Ah, thanks for the archeology. So it indeed seems like in theory an ABI change
between GCC 3.4 and 4.0 for C then on some of the targets like x86_64 which
already existed in 3.
On Thu, Sep 02, 2021 at 12:19:03AM +0200, Jakub Jelinek via Gcc-patches wrote:
> Ah, thanks for the archeology. So it indeed seems like in theory an ABI
> change
> between GCC 3.4 and 4.0 for C then on some of the targets like x86_64 which
> already existed in 3.2-ish era. I actually couldn't se
On Wed, Sep 01, 2021 at 05:32:07PM -0400, Jason Merrill wrote:
> On 8/31/21 5:15 AM, Richard Biener wrote:
> > On Tue, 31 Aug 2021, Jakub Jelinek wrote:
> >
> > > On Tue, Aug 31, 2021 at 09:57:44AM +0200, Richard Biener wrote:
> > > > Just to clarify - in the C++ FE these fields are meaningful for
On 8/31/21 5:15 AM, Richard Biener wrote:
On Tue, 31 Aug 2021, Jakub Jelinek wrote:
On Tue, Aug 31, 2021 at 09:57:44AM +0200, Richard Biener wrote:
Just to clarify - in the C++ FE these fields are meaningful for
layout purposes but they are only supposed to influence layout
but not ABI (but wh
On Tue, 31 Aug 2021, Jakub Jelinek wrote:
> On Tue, Aug 31, 2021 at 09:57:44AM +0200, Richard Biener wrote:
> > Just to clarify - in the C++ FE these fields are meaningful for
> > layout purposes but they are only supposed to influence layout
> > but not ABI (but why does the C++ FE say that?) and
On Tue, Aug 31, 2021 at 09:57:44AM +0200, Richard Biener wrote:
> Just to clarify - in the C++ FE these fields are meaningful for
> layout purposes but they are only supposed to influence layout
> but not ABI (but why does the C++ FE say that?) and thus the
> 'DECL_FIELD_ABI_IGNORED' is a good term
On Tue, 31 Aug 2021, Richard Biener wrote:
> On Tue, 31 Aug 2021, Jakub Jelinek wrote:
>
> > Hi!
> >
> > The removal of remove_zero_width_bitfields function and its call from
> > C++ FE layout_class_type (which I've done in the P0466R5
> > layout-compatible helper intrinsics patch, so that the F
On Tue, 31 Aug 2021, Jakub Jelinek wrote:
> Hi!
>
> The removal of remove_zero_width_bitfields function and its call from
> C++ FE layout_class_type (which I've done in the P0466R5
> layout-compatible helper intrinsics patch, so that the FE can actually
> determine what is and isn't layout-compat
Hi!
The removal of remove_zero_width_bitfields function and its call from
C++ FE layout_class_type (which I've done in the P0466R5
layout-compatible helper intrinsics patch, so that the FE can actually
determine what is and isn't layout-compatible according to the spec)
unfortunately changed the A
this a round of testing myself (also noticing the corresponding
trunk patch isn't in yet)
So if you can manage to push it before this time that would be great,
otherwise I guess I'm going to push it to 10.
Richard.
> > commit 123f254cce416a4d50445465b88af6d8e754dc5e
> > Auth
he
> process.
>
> Does this make sense to you?
LGTM, thanks.
> commit 123f254cce416a4d50445465b88af6d8e754dc5e
> Author: Jakub Jelinek
> Date: Thu Jan 7 17:47:18 2021 +0100
>
> c++, abi: Fix abi_tag attribute handling [PR98481]
>
> In GCC10 cp_walk_subtrees has
/-fabi-compat-version handle this case,
but that would require a bunch of new code unsuitable for this point in
the process.
Does this make sense to you?
commit 123f254cce416a4d50445465b88af6d8e754dc5e
Author: Jakub Jelinek
Date: Thu Jan 7 17:47:18 2021 +0100
c++, abi: Fix abi_tag
On Fri, Jan 08, 2021 at 02:22:59PM -0500, Jason Merrill wrote:
> I like the idea to use *walk_subtrees to distinguish between walking
> syntactic subtrees and walking type-identity subtrees. But it should be
> more general; how does this look to you?
LGTM, thanks.
> diff --git a/gcc/cp/class.c b
On 1/7/21 11:47 AM, Jakub Jelinek wrote:
In GCC10 cp_walk_subtrees has been changed to walk template arguments.
As the following testcase, that changed the mangling of some functions.
Argh.
I believe the previous behavior that find_abi_tags_r doesn't recurse into
template args has been the co
Hi!
In GCC10 cp_walk_subtrees has been changed to walk template arguments.
As the following testcase, that changed the mangling of some functions.
I believe the previous behavior that find_abi_tags_r doesn't recurse into
template args has been the correct one, but setting *walk_subtrees = 0
for th
Having noticed this in some other case I went through all of our
pages and found this this instance in the GCC 10 release notes where
.
commit f1d2be6c9fcc52d676266e7ede123953d150aaf3
Author: Jonathan Wakely
Date: Thu May 7 11:24:04 2020 +0100
Document C++17 ABI changes in GC
On 07/05/20 11:08 +0200, Jakub Jelinek wrote:
Hi!
This is my humble attempt to document the C++ ABI changes.
Or do you have something better?
Not sure e.g. how C++ calls the TREE_ADDRESSABLE types which are
passed/returned by invisible reference, perhaps it would be nice
to make it clear that
Hi!
This is my humble attempt to document the C++ ABI changes.
Or do you have something better?
Not sure e.g. how C++ calls the TREE_ADDRESSABLE types which are
passed/returned by invisible reference, perhaps it would be nice
to make it clear that those aren't affected.
As the release tar
On 12/03/20 10:13 +, Jonathan Wakely via Libstdc++ wrote:
Please CC libstd...@gcc.gnu.org for all libstdc++ patches, as per
https://gcc.gnu.org/lists.html
On 11/03/20 21:24 -0700, Fangrui Song wrote:
Alternatively, we can delete it, because no user code should call it.
It may be weird that
Please CC libstd...@gcc.gnu.org for all libstdc++ patches, as per
https://gcc.gnu.org/lists.html
On 11/03/20 21:24 -0700, Fangrui Song wrote:
Alternatively, we can delete it, because no user code should call it.
It may be weird that libc is expected to define this function.
This function is a la
Alternatively, we can delete it, because no user code should call it.
It may be weird that libc is expected to define this function.
This function is a language runtime interface that has nothing to do
with a libc.
---
libstdc++-v3/libsupc++/cxxabi.h | 2 +-
1 file changed, 1 insertion(+), 1 dele
This fixes a problem with the GCC implementation of the ABI, where we are
accidentally emitting different code for the same struct when compiled by the
C and C++ compilers. This was found by LLVM developers comparing the LLVM ABI
to the GCC ABI.
This affects any struct with one or more zero-lengt
This patch does not affect the behavior of Ada-only code but improves
consistency with the code generated by the C++ compiler.
Tested on x86_64-pc-linux-gnu, committed on trunk
2018-09-26 Javier Miranda
gcc/ada/
* sem_res.adb (Resolve_Actuals): If the formal is a class-wide
t
On Thu, 26 Jul 2018, Jakub Jelinek wrote:
> Hi!
>
> I've noticed that while Jason documented the -fabi-version=13/-Wabi=12
> 8.2 fix in the C++ section, there is no mention of it in the 8.2 section,
> so if people just quickly look at what significant has changed in 8.2,
> they will not notice th
Hi!
I've noticed that while Jason documented the -fabi-version=13/-Wabi=12
8.2 fix in the C++ section, there is no mention of it in the 8.2 section,
so if people just quickly look at what significant has changed in 8.2,
they will not notice that.
This patch fixes the markup in Jason's changes et
it ed7eeb361974a8c64803b617bd760612060cc3ab
Author: Jonathan Wakely
Date: Wed Apr 19 17:45:42 2017 +0100
Rationalise ABI links in libstdc++ manual
* doc/xml/manual/abi.xml: Rephrase one of the references to the
Itanium C++ ABI.
* doc/xml/manual/test.xml: Document DejaGnu 1.5.3
me this document moves. :-}
(Also, if you could regenerate and upload the docs?)
Gerald
2017-04-12 Gerald Pfeifer
* doc/xml/faq.xml: Update reference link to C++ ABI for Itanium.
* doc/xml/manual/abi.xml. Ditto (thrice).
Index:
rg.au";>t...@melbpc.org.au>.
- http://mentorembedded.github.io/cxx-abi/";>
+ https://itanium-cxx-abi.github.io/cxx-abi/";>
The V3 multi-vendor standard C++ ABI is used in GCC releases 3.0 and
above.
lease read the http://mentorembedded.github.io/cxx-abi/";>C++ ABI specification.
+href="https://itanium-cxx-abi.github.io/cxx-abi/";>C++ ABI specification.
Note the std::type_info objects which must be
resolved all begin with "_ZTS". Refer to ld's
documentation fo
relatively
stable and common C++ ABI for GNU/Linux and BSD usage, following
the documentation at
-http://mentorembedded.github.io/cxx-abi/";>http://sourcery.mentor.com/public/cxx-abi/.
+http://mentorembedded.github.io/cxx-abi/";>http://mentorembedded.g
to
> > GCC 6 and possibly GCC 5 later.
> >
> > Gerald
> >
> > 2017-01-01 Gerald Pfeifer
> >
> > * doc/xml/faq.xml: Update address of C++ ABI link.
> > * doc/xml/manual/abi.xml: Ditto.
>
> Pushed to the GCC 6 and GCC 5 branche
2017-01-01 Gerald Pfeifer
>
> * doc/xml/faq.xml: Update address of C++ ABI link.
> * doc/xml/manual/abi.xml: Ditto.
Pushed to the GCC 6 and GCC 5 branches now.
Jonathan, this is the last one I had in my list of backports touching
libstdc++ docs; there likely will be more I&#x
When I updated those URLs in June 2015, I must have missed these
references in libstdc++ land.
Fixed thusly (via revision 244001), and I plan on backporting to
GCC 6 and possibly GCC 5 later.
Gerald
2017-01-01 Gerald Pfeifer
* doc/xml/faq.xml: Update address of C++ ABI link
1.7
diff -u -r1.7 c++-abi.html
--- gcc-3.2/c++-abi.html26 Aug 2012 10:40:09 - 1.7
+++ gcc-3.2/c++-abi.html28 Jun 2015 14:43:23 -
@@ -10,7 +10,7 @@
The main point of the GCC 3.2 release is to have a relatively
stable and common C++ ABI for GNU/Linux and BSD us
27 Jun 2015 19:25:29 -
@@ -429,7 +429,7 @@
For more details about the way that GCC implements these and other
C++ features, please read the http://mentorembedded.github.com/cxx-abi/";>C++ ABI specification.
+href="http://mentorembedded.github.io/cxx-abi/";>C++ ABI specifi
On Sun, Aug 26, 2012 at 11:55 AM, Ian Lance Taylor wrote:
> On Sun, Aug 26, 2012 at 3:43 AM, Gerald Pfeifer wrote:
>> On Tue, 7 Aug 2012, Ian Lance Taylor wrote:
>>> The official link at http://codesourcery.com/cxx-abi/ (note trailing
>>> slash) still works.
>>
>> It used to be http://sourcery.me
g
> Subject: Re: [wwwdocs] Update links to C++ ABI
>
> On Sun, 26 Aug 2012, Ian Lance Taylor wrote:
> >> It used to be http://sourcery.mentor.com/public/cxx-abi/ as of
> >> lately, and now redirects to http://mentorembedded.github.com/cxx-
> abi/ .
> >>
> >&g
On Sun, 26 Aug 2012, Ian Lance Taylor wrote:
>> It used to be http://sourcery.mentor.com/public/cxx-abi/ as of lately,
>> and now redirects to http://mentorembedded.github.com/cxx-abi/ .
>>
>> I went ahead and updated all our references per the patch below.
> I don't think that is wise. The docume
On Sun, Aug 26, 2012 at 3:43 AM, Gerald Pfeifer wrote:
> On Tue, 7 Aug 2012, Ian Lance Taylor wrote:
>> The official link at http://codesourcery.com/cxx-abi/ (note trailing
>> slash) still works.
>
> It used to be http://sourcery.mentor.com/public/cxx-abi/ as of lately,
> and now redirects to http
e http://sourcery.mentor.com/public/cxx-abi/";>C++ ABI specification.
+href="http://mentorembedded.github.com/cxx-abi/";>C++ ABI specification.
Note the std::type_info objects which must be
resolved all begin with "_ZTS". Refer to ld's
documentation for a desc
45 matches
Mail list logo
