Re: Query regarding unusual behaviour for tail padding with different c++ standards
On Mon, 13 Dec 2021 at 05:14, Andrew Pinski wrote:
>
> On Sun, Dec 12, 2021 at 9:04 PM Nayan Deshmukh via Gcc
> wrote:
> > #include
> > #include
> > #include
> > struct A {
> > int a;
> > uint64_t b;
> > int c = -1;
> > };
>
> The question becomes is the above a standard layout class or not. I
> Noticed clang does not change the rules for layout between C++11 and
> C++14 but GCC does.
> I don't know the exact rules in the ABI to help you there but I do
> think you should file a bug because it definitely looks unexpected
> really.
The C++14 behaviour started with https://gcc.gnu.org/r216750
Implement N3653 (Member initializers and aggregates) and fix
references to 'this' in constexpr cons
tructors.
Implement N3653 (Member initializers and aggregates) and fix
references to 'this' in constexpr constructors.
* class.c (check_field_decls): In C++14 an NSDMI does not make the
class non-aggregate.
But I think the layout should be using "POD for the purpose of
layout", which means the C++98 POD rules. Please do report it to
bugzilla.
RE: Re: Query regarding unusual behaviour for tail padding with different c++ standards
> On Mon, 13 Dec 2021 at 05:14, Andrew Pinski wrote:
> >
> > On Sun, Dec 12, 2021 at 9:04 PM Nayan Deshmukh via Gcc
> >wrote:
> > > #include
> > > #include
> > > #include
> > > struct A {
> > > int a;
> > > uint64_t b;
> > > int c = -1;
> > > };
> >
> > The question becomes is the above a standard layout class or not. I
> > Noticed clang does not change the rules for layout between C++11 and
> > C++14 but GCC does.
> > I don't know the exact rules in the ABI to help you there but I do
> > think you should file a bug because it definitely looks unexpected
> > really.
>
> The C++14 behaviour started with https://gcc.gnu.org/r216750
>
> Implement N3653 (Member initializers and aggregates) and fix
> references to 'this' in constexpr cons
> tructors.
>
> Implement N3653 (Member initializers and aggregates) and fix
> references to 'this' in constexpr constructors.
> * class.c (check_field_decls): In C++14 an NSDMI does not make the
> class non-aggregate.
>
> But I think the layout should be using "POD for the purpose of
> layout", which means the C++98 POD rules. Please do report it to
> bugzilla.
I file a bug for this issue in bugzilla:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103681
Thanks,
Nayan
Re: gccadmin hooks: make it a public git repo
Hello. I would like to ping this as Joel wrote that we'll be switching to Python3. I know there are some scripts that are definitely in Python 2 and I would like to port it. Having a git repo seems to me the only reasonable way doing that. Can we please set it up? Cheers, Martin On 5/24/21 09:11, Martin Liška wrote: PING^1 On 1/14/21 10:02 AM, Martin Liška wrote: On 1/13/21 6:00 PM, Joseph Myers wrote: I'm fine with having it set up with a public repository. Ok, can you please do it Joseph? If you have a public (bare) repository that would of course need to have its own hooks to update the (non-bare) hooks-bin checkout after a push. I can imagine a cron job similar to which one we use for 'Daily bump'. Would it be feasible? Thanks, Martin
[power-ieee128] Which options for libquadmath / native ieee128
Hi, looking at what the REAL(KIND=17) numbers should be compiled for, I see the following options that should be considered: a) xsaddqp and friends are not supported by the CPU; libquadmath should be called for all operations, including simple arithmetic. b) xsaddqp and friends are supported, but glibc is too old and lacks the *ieee128 functions. libquadmath should be called for these functions. c) xsaddqp and friends are supported, and glibc is new enough. Call the *ieee128 functions. What is the best way to check in the library config files that the quad precision instructions are supported (to differentiate between a) on the one hand and b) and c) on the other? And which options to the compiler make sure the libquadmath library is called? Regards Thomas
Re: gccadmin hooks: make it a public git repo
On Mon, 13 Dec 2021, Martin Liška wrote: > I would like to ping this as Joel wrote that we'll be switching > to Python3. I know there are some scripts that are definitely in Python 2 > and I would like to port it. Scripts in hooks-bin are executed in separate processes, not imported into the same Python interpreter as the main hooks, so I don't think there is any dependency involved on what Python version the main hooks use (make sure nothing is setting PATH or PYTHONPATH in a way that would affect those scripts and make them not find any system packages they depend on, directly or via the /home/gccadmin/.local/lib/python3.6/site-packages reference in commit_checker, however). The only one that's Python 2 appears to be email_to.py, which is trivial and should work with Python 3 with no changes other than to the #! line. > Having a git repo seems to me the only reasonable way doing that. There is a repository (/home/gccadmin/hooks-bin/.git), it's just not a bare one (so not suitable for pushing to) and not public (but anyone in the gcc group should be able to clone it, read-only, over ssh). > Can we please set it up? If someone with the relevant access wishes to set up a public, bare repository with appropriate post-receive hook to update the hooks-bin checkout that gets used, they are welcome to do so. -- Joseph S. Myers jos...@codesourcery.com
Re: [power-ieee128] Which options for libquadmath / native ieee128
On Mon, Dec 13, 2021 at 09:29:16PM +0100, Thomas Koenig wrote: > > Hi, > > looking at what the REAL(KIND=17) numbers should be compiled for, I see > the following options that should be considered: > > a) xsaddqp and friends are not supported by the CPU; libquadmath should >be called for all operations, including simple arithmetic. Note, we do not use the emulator in libquadmath. Libgcc has support for doing software emulation of the IEEE 128-bit basic support. > b) xsaddqp and friends are supported, but glibc is too old and lacks the >*ieee128 functions. libquadmath should be called for these >functions. Yes, this would be the place to call libquadmath. Or possibly don't use libquadmath at all and don't allow KIND=17. It is probably better for the users if we use libquadmath instead of disabling it all together. > c) xsaddqp and friends are supported, and glibc is new enough. Call >the *ieee128 functions. The necessary support is in the little endian GLIBC 2.32 or newer. I don't recall if you also need Elf abi V2 (which is default on little endian). You could check via: #if (((__GLIBC__ * 1000) + __GLIBC_MINOR__) >= 2032 && \ (__BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__) \ (_CALL_ELF == 2)) If you are writing C code for the library, and using _Float128 for the type instead of using long double and using the -mabi=ieeelongdouble switch, you want to define the following macros before math.h or other system include files are included: #define __STDC_WANT_IEC_60559_TYPES_EXT__ 1 #define __STDC_WANT_IEC_60559_FUNCS_EXT__ 1 > What is the best way to check in the library config files that the quad > precision instructions are supported (to differentiate between a) on the > one hand and b) and c) on the other? You can check whether long double is IEEE 128-bit via: #if defined(__LONG_DOUBLE_IEEE128__)/* or */ #if __LONG_DOUBLE_IEEE128__ and similarly to check for IBM 128-bit long double: #if defined(__LONG_DOUBLE_IBM128__) /* or */ #if __LONG_DOUBLE_IBM128__ To check whether IEEE 128-bit instructions are enabled: #if defined(__FLOAT128_HARDWARE__) /* or */ #if __FLOAT128_HARDWARE__ To check whether the _Float128 or __float128 keywords are available (whether or not the hardware supports the instructions): #if defined(__FLOAT128_TYPE__) /* or */ #if __FLOAT128_TYPE__ Note, that C++ does not support the _Float128 type (which is in one of the IEC papers), but it does support the non-standard __float128 keyword. Unfortunately, __float128 _Complex does not work. There is a GLIBC macro that gives the appropriate _Complex type for __float128 use in C++, but I don't remember what it is. Alternatively, it might be simpler to build the library parts using long double and build those modules with the appropriate options. > > And which options to the compiler make sure the libquadmath library > is called? The libqaudmath library should always be linked in if it is built. I had actually meant to turn off building it once all of the 2.32 support went in, but I never did. Note, I haven't tested libquadmath in a long time. To compile C/C++ code where long double is IEEE 128-bit use: -mabi=ieeelongdouble -Wno-psabi -mno-gnu-attribute For Fortran code, I think you have to remove the -Wno-psabi. But it may be buggy. Similarly to force long double to be IBM 128-bit, no matter what the defaults are use: -mabi=iibmlongdouble -Wno-psabi -mno-gnu-attribute The no-gnu-attribute says to disable setting the GNU attribute that says what the default long double type is. It is necessary when building libraries with both 128-bit types. -- Michael Meissner, IBM PO Box 98, Ayer, Massachusetts, USA, 01432 email: meiss...@linux.ibm.com
VU#930724: Apache Log4j CVE-2021-44228 tracking
Hello, This case is primarily to collect and track vulnerability status for CVE-2021-44228, the Apache Log4j JNDI remote code execution vulnerability. We will be collecting public advisories and other information, but as usual would appreciate status updates and public references. View Online: https://kb.cert.org/vince/comm/case/310/ Access to the case requires a VINCE account. If you do not have an account, please create an account: https://kb.cert.org/vince/comm/signup/ Thank you, The CERT/CC Vulnerability Coordination Team This e-mail was sent to you as a user of our VINCE service, in accordance with our privacy policy. Please advise us if you believe you have received this e-mail in error.
