Hi!
On 2025-03-17T20:03:48+, Iain Sandoe via Gcc wrote:
>> On 17 Mar 2025, at 19:43, Toon Moene wrote:
>>
>> I was eager to try the new rust updates ...
>>
>> But I got this:
>>
>> error[E0554]: `#![feature]` may not be used on the stab
> On 17 Mar 2025, at 19:43, Toon Moene wrote:
>
> I was eager to try the new rust updates ...
>
> But I got this:
>
> error[E0554]: `#![feature]` may not be used on the stable release channel
> --> src/lib.rs:19:1
> |
I was eager to try the new rust updates ...
But I got this:
error[E0554]: `#![feature]` may not be used on the stable release channel
--> src/lib.rs:19:1
|
19 | #![feature(extern_types)]
| ^
For more information about this error, try `rustc --explain E0
On Fri, Feb 9, 2024 at 10:36 AM Georg-Johann Lay wrote:
>
> We have this (rare?) wrong code bug
>
> https://gcc.gnu.org/PR101188
>
> which Jeff fixed for v14:
>
> https://gcc.gnu.org/r14-1738
>
> The fix doesn't fit 100% for v13 but the PR has a backport for v1
We have this (rare?) wrong code bug
https://gcc.gnu.org/PR101188
which Jeff fixed for v14:
https://gcc.gnu.org/r14-1738
The fix doesn't fit 100% for v13 but the PR has a backport for v13
in comment #16. Would be great if this could be part of v13.3,
but I don't have the resources t
Hi all,
Tommorrow's meeting will be canceled, since there are few new topics to discuss.
The next RISC-V GNU Toolchain meeting is collecting topics:
https://docs.google.com/document/d/1JSs-BSlPJ3QYbAb-Add1TlbYx0nOT1ur3jcsITIJ01U/edit?usp=sharing
Please add what want to discuss i
>>>> }
>>>>
>>>> After compiling this via `-O3 -flto`, the else block isn't been
>>>> optimized and still exists.
>>>>
>>>> Even it's so obvious that the function will return '1', can't the
>>>
gt; > > optimized and still exists.
> > >
> > > Even it's so obvious that the function will return '1', can't the
> > > compiler see that? Does gcc only get this information by inlining the
> > > function? Or is that what the gcc does?
>
> > return 0;
> > }
> >
> > After compiling this via `-O3 -flto`, the else block isn't been
> > optimized and still exists.
> >
> > Even it's so obvious that the function will return '1', can't the
> > compiler see th
gt; Even it's so obvious that the function will return '1', can't the
> compiler see that? Does gcc only get this information by inlining the
> function? Or is that what the gcc does?
>
> If so, how to make a change to let gcc get this information then?
I think
Hi, I'm a little confused about the behavior of gcc when the function
is not inlined.
Here is an example code:
int __attribute__((noinline)) foo() {
return 1;
}
int main() {
if (foo()) {
printf("foo() returned 1\n");
} else {
printf("foo() returned 0\n");
}
re
Hi all,
Today's meeting will be canceled, since people plan going to the GNU Cauldron.
The next RISC-V GNU Toolchain meeting is collecting topics:
https://docs.google.com/document/d/1JSs-BSlPJ3QYbAb-Add1TlbYx0nOT1ur3jcsITIJ01U/edit?usp=sharing
Please add what want to discuss in the
Hi all,
Today's meeting will be canceled, since during the China RISC-V Summit.
The next RISC-V GNU Toolchain meeting is collecting topics:
https://docs.google.com/document/d/1JSs-BSlPJ3QYbAb-Add1TlbYx0nOT1ur3jcsITIJ01U/edit?usp=sharing
Please add what want to discuss in the next me
On Tue, 8 Aug 2023 at 10:09, Helmut Zeisel via Gcc wrote:
>
> GCC13, c++, cygwin 64:
>
> auto x = 9223372036854775808L
>
> gives the warning: "integer constant is so large that it is unsigned"
>
> But actually the type is signed __int128:
>
> std::cout << x;
>
> gives the error: "ambiguous overlo
GCC13, c++, cygwin 64:
auto x = 9223372036854775808L
gives the warning: "integer constant is so large that it is unsigned"
But actually the type is signed __int128:
std::cout << x;
gives the error: "ambiguous overload for ‘operator<<’ (operand types are
‘std::ostream’ {aka ‘std::basic_ostre
t; copy/move.
>
> I'm trying to stay abstracted from heap allocated regions, and to
> rather
> work with "resources",
>
> so that the state machine could be easily further extended.
>
> However, the whole concern of ownership is really C++-like, and most
>
Hi all,
Is there a way to make the format attribute when passed ms_printf recognise
ISO C99 and above format specifiers? Currently on Windows gcc always
assumes that printf doesn't recognise specifiers such as %z and %T for
strftime, but for gcc that links against the newer C Runtime from Microsof
Hi,
On 13/07/2023 10:48, David Malcolm wrote:
(apologies for top-posting; I'm on vacation and don't have my usual email setup)
Sounds interesting, but I'm having difficulty imagining exactly what
you have in mind.
Can you post one or more concrete examples of buggy code that wou
(apologies for top-posting; I'm on vacation and don't have my usual email setup)
Sounds interesting, but I'm having difficulty imagining exactly what
you have in mind.
Can you post one or more concrete examples of buggy code that would be
caught by such a warning?
Why wouldn'
,
so that the state machine could be easily further extended.
However, the whole concern of ownership is really C++-like, and most of the
checks would require
things unheard of in vanilla C, such as copy/move operators, ctors & dtors
...
Using those constructs, it is really doable to gues
7 ec ff ffcall 140001500 <__main>
> >1400028c9: 90nop
> >1400028ca: 90nop
> >1400028cb: 90nop
> >1400028cc: 31 c0 xoreax,eax
> &g
28
>1400028c4: e8 37 ec ff ffcall 140001500 <__main>
>1400028c9: 90nop
>1400028ca: 90nop
>1400028cb: 90nop
>1400028cc: 31 c0 xor
call 140001500 <__main>
1400028c9: 90nop
1400028ca: 90nop
1400028cb: 90nop
1400028cc: 31 c0 xoreax,eax
1400028cd: 48 83 c4 28 addrsp,0x28
1400028ce: c
ucing a
> > fully correctly operating program as expected. Even if the above inline
> > assembly blocks never worked due to other optimizations however, the
> > failure mode of the program would be very different from how it fails now:
> > It should fail noisily with an
gt; assembly blocks never worked due to other optimizations however, the
> failure mode of the program would be very different from how it fails now:
> It should fail noisily with an access violation exception due to
> the malformed assembly, but instead all the assembly which installs a
, the
failure mode of the program would be very different from how it fails now:
It should fail noisily with an access violation exception due to
the malformed assembly, but instead all the assembly which installs an
exception handler never makes it into the final program because with
anything higher
-> long {
> return EXCEPTION_EXECUTE_HANDLER;
> }();
>
> asm ("pop r15" "\n"
> "\t" "pop rbp" "\n"
> "\t" "ret" "\n"
> "\t" "nop" &qu
ed]] () -> long {
return EXCEPTION_EXECUTE_HANDLER;
}();
asm ("pop r15" "\n"
"\t" "pop rbp" "\n"
"\t" "ret" "\n"
"\t" "nop" "\n"
&qu
ote:
>>
>> Hi Andrew,
>>
>> That can't be right, on my system a test of asm vs asm volatile with -O3 and
>> -flto=auto yields very different results, with only the latter being
>> correct. The patch fixed it and caused gcc to emit correct assembly
>>
>&
On Tue, Jun 27, 2023 at 9:15 AM Julian Waters wrote:
>
> Hi Andrew,
>
> That can't be right, on my system a test of asm vs asm volatile with -O3 and
> -flto=auto yields very different results, with only the latter being correct.
> The patch fixed it and caused gcc to emi
Perhaps this only affects compilation when GIMPLE isn't being used?
On Wed, Jun 28, 2023 at 12:15 AM Julian Waters
wrote:
> Hi Andrew,
>
> That can't be right, on my system a test of asm vs asm volatile with -O3
> and -flto=auto yields very different results, with
Hi Andrew,
That can't be right, on my system a test of asm vs asm volatile with -O3
and -flto=auto yields very different results, with only the latter being
correct. The patch fixed it and caused gcc to emit correct assembly
best regards,
Julian
On Wed, Jun 28, 2023 at 12:08 AM Andrew P
9fefde6b5 Mon Sep 17 00:00:00 2001
> From: TheShermanTanker
> Date: Tue, 27 Jun 2023 23:56:38 +0800
> Subject: [PATCH] asm not using extended syntax should always be volatile
>
> ---
> gcc/cp/parser.cc | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/gcc/cp/pars
My apologies, I sent this to the wrong list. I have already resent
it to the correct one
regards,
Julian
nt is called
>From 3094be39e3e65a6a638f05fafd858b89fefde6b5 Mon Sep 17 00:00:00 2001
From: TheShermanTanker
Date: Tue, 27 Jun 2023 23:56:38 +0800
Subject: [PATCH] asm not using extended syntax should always be volatile
---
gcc/cp/parser.cc | 3 +++
1 file changed, 3 insertions(+)
diff --git
Hi all,
Tomorrow's meeting will be canceled, since there were few new topics to discuss.
The next RISC-V GNU Toolchain meeting is collecting topics:
https://docs.google.com/document/d/1JSs-BSlPJ3QYbAb-Add1TlbYx0nOT1ur3jcsITIJ01U/edit?usp=sharing
Please add what want to discuss i
Hi,
I agree with you that C would benefit from a new type qualifier to
indicate pointer nullability, although not with your suggestion that
such a qualifier should indicate the property cannot-be-null.
If you just want a syntax for declaring that a function parameter is
not a null pointer, C
I am not C expert, so be polity. I do not see something similar in C world,
but similar techniques in other languages, such like Vala.
I suggest to create two new pointer type:
1. can-be-null
2. cannot-be-null
(You must find other words to describe it behavior).
First enforces to compiler
like:
> >
> > When a pointer to a sockaddr_storage structure is first aliased as a
> > pointer to a protocol-specific address structure, the effective type
> > of the object will be set to the protocol-specific structure.
I'll add that as a comment to the Austin Group pa
On 4/21/23 16:58, Alejandro Colomar wrote:
> Hi Eric,
>
> On 4/14/23 18:08, Zack Weinberg via Libc-alpha wrote:
>> On 2023-04-06 3:37 PM, Eric Blake wrote:
>>> Since Issue 7 is tied to C99, and Issue 8 will be tied to C17, both of
>>> which use the same section
Hi Eric,
On 4/14/23 18:08, Zack Weinberg via Libc-alpha wrote:
> On 2023-04-06 3:37 PM, Eric Blake wrote:
>> Since Issue 7 is tied to C99, and Issue 8 will be tied to C17, both of
>> which use the same section number despite being a different edition of
>> the C standard, be
Hi all,
Tomorrow's meeting will be canceled, since there were few new topics to discuss.
The next RISC-V GNU Toolchain meeting is collecting topics:
https://docs.google.com/document/d/1JSs-BSlPJ3QYbAb-Add1TlbYx0nOT1ur3jcsITIJ01U/edit?usp=sharing
Please add what want to discuss i
something to POSIX without
>> enough eyes checking it. So this will be a long email.
>
> Because your mail landed in a publicly archived mailing list, the
> POSIX folks saw it anyways ;)
:)
>
> ...
>>>
>>> Whether gcc already has all the attributes you need
On Wed, Apr 05, 2023 at 02:42:04AM +0200, Alejandro Colomar wrote:
> Hi Eric,
>
> I'm going to reply both your emails here so that GCC is CCed, and they can
> suggest better stuff. I'm worried about sending something to POSIX without
> enough eyes checking it. So
Hi Eric,
I'm going to reply both your emails here so that GCC is CCed, and they can
suggest better stuff. I'm worried about sending something to POSIX without
enough eyes checking it. So this will be a long email.
On 3/30/23 20:36, eblake wrote:
> On Thu, Mar 30, 2023 at 06:
On Thu, Mar 30, 2023 at 07:13:11PM +0200, Alejandro Colomar wrote:
> POSIX.1 Issue 8 will fix the long-standing issue with sockaddr APIs,
> which inevitably caused UB either on user code, libc, or more likely,
> both. sockaddr_storage has been clarified to be implemented in a mann
POSIX.1 Issue 8 will fix the long-standing issue with sockaddr APIs,
which inevitably caused UB either on user code, libc, or more likely,
both. sockaddr_storage has been clarified to be implemented in a manner
that aliasing it is safe (suggesting a unnamed union, or other compiler
magic).
Link
Hi all,
Tomorrow's meeting will be canceled, since there were few new topics to discuss.
The next RISC-V GNU Toolchain meeting is collecting topics:
https://docs.google.com/document/d/1JSs-BSlPJ3QYbAb-Add1TlbYx0nOT1ur3jcsITIJ01U/edit?usp=sharing
Please add what want to discuss i
st member.
>>> +This is Undefined Behavior.
>>> +However, there is no way to use these APIs without invoking Unedfined
>>> Behavior,
>>
>> Undefined
>>
>>> +either in the user program or in libc,
>>> +so it is still recommended to use t
without invoking Unedfined
> > Behavior,
>
> Undefined
>
> > +either in the user program or in libc,
> > +so it is still recommended to use this method.
> > +The only correct way to use different types in an API is through a union.
> > +However,
> > +tha
Hi all,
Tomorrow's meeting will be canceled, since there were few new topics to discuss.
The next RISC-V GNU Toolchain meeting is collecting topics:
https://docs.google.com/document/d/1JSs-BSlPJ3QYbAb-Add1TlbYx0nOT1ur3jcsITIJ01U/edit?usp=sharing
Please add what want to discuss i
these APIs without invoking Unedfined Behavior,
Undefined
+either in the user program or in libc,
+so it is still recommended to use this method.
+The only correct way to use different types in an API is through a union.
+However,
+that union must be implemented in the library,
+since the type must
owever, there is no way to use these APIs without invoking Unedfined
> Behavior,
Undefined
> +either in the user program or in libc,
> +so it is still recommended to use this method.
> +The only correct way to use different types in an API is through a union.
> +However,
> +that union
On Mon, Feb 06, 2023 at 03:11:10PM +0100, Alejandro Colomar wrote:
> Hi Rich,
>
> On 2/6/23 14:38, Rich Felker wrote:
> >There is absolutely not any need to declare the union for application
> >code calling the socket APIs. You declare whatever type you will be
> >using
Hi Rich,
On 2/6/23 14:38, Rich Felker wrote:
There is absolutely not any need to declare the union for application
code calling the socket APIs. You declare whatever type you will be
using. For binding or connecting a unix socket, sockaddr_un. For IPv6,
sockaddr_in6. Etc. Then you cast the
int bind(int fd, const struct sockaddr *addr, socklen_t addrlen)
> >{
> > if (addrlen < sizeof(struct sockaddr) {
> > errno = EINVAL;
> > return -1;
> > }
> >
> > /* cannot use "addr->sa_family" directly: it wi
family" directly: it will be an UB */
sa_family_t sa_family;
memcpy(&sa_family, addr, sizeof(sa_family));
switch (sa_family) {
case AF_INET:
return _do_bind_in(fd, (struct sockaddr_in *)addr, addrlen);
case AF_INET6:
return
t sockaddr) {
> errno = EINVAL;
> return -1;
> }
>
> /* cannot use "addr->sa_family" directly: it will be an UB */
> sa_family_t sa_family;
> memcpy(&sa_family, addr, sizeof(sa_family));
>
> switch (sa_family) {
>
. };
struct sockaddr_in { ... };
struct sockaddr_in6 { ... };
int bind(int fd, const struct sockaddr *addr, socklen_t addrlen)
{
if (addrlen < sizeof(struct sockaddr) {
errno = EINVAL;
return -1;
}
/* cannot use "addr->sa_family" directly: it will be an UB *
addr_{in,in6,un}. And if you defined
> >differently-tagged structures with the same contents, it would not do
> >any good; accessing the members with the wrong-tagged struct type
> >would still be UB.
>
> I'm not sure. ISO C has that restriction that a header can onl
sockaddr_{in,in6,un}. And if you defined
differently-tagged structures with the same contents, it would not do
any good; accessing the members with the wrong-tagged struct type
would still be UB.
I'm not sure. ISO C has that restriction that a header can only define what the
standard sa
to expose sockaddr_{in,in6,un}. And if you defined
differently-tagged structures with the same contents, it would not do
any good; accessing the members with the wrong-tagged struct type
would still be UB.
Really, there is no action needed here. Nothing is wrong on libc's
side. The problem is
union. However, that union must be implemented in the li‐
brary, since the type must be shared between the library and user code,
so libc should be fixed by implementing sockaddr_storage as a union.
--
<http://www.alejandro-colomar.es/>
GPG key finge
hese APIs without invoking Unedfined Behavior,
+either in the user program or in libc,
+so it is still recommended to use this method.
+The only correct way to use different types in an API is through a union.
+However,
+that union must be implemented in the library,
+since the type must be shared betwee
Hi all,
Tomorrow's RISC-V GNU Toolchain meeting will be canceled, since during the
Spring Festival holiday.
The next RISC-V GNU Toolchain meeting is collecting topics.
Please let me know if you have any topics want to discuss in the next meeting.
BR
Jiawei
Hi all,
Tomorrow's RISC-V GNU Toolchain meeting will be canceled, since there are few
new topics to discuss.
The next RISC-V GNU Toolchain meeting is collecting topics.
Please let me know if you have any topics want to discuss in the next meeting.
BR
Jiawei
What is going on out there these days? I've added more addresses from
the GCC mailing list to my killfile in the last week than in the
previous two years combined.
Yeesh.
Seriously? You UNIX folks are completely clueless about usability! It would
have been far easier to supply a built-in or separate utility to
automatically collect all the pertinent source files with the option of
mailing them to you. It also wouldn't be half as backward if you didn't
ma
Hi all,
Tomorrow's meeting will be canceled, since there was few new topics to discuss.
The next RISC-V GNU Toolchain meeting is collecting.
Please let me know if you have any topics want to discuss in the next meeting.
Best Regards,
Jiawei
Hi all,
Tomorrow's meeting will be canceled, since there was few new topics to discuss.
The next RISC-V GNU Toolchain meeting will be held on Dec 1.
Please let me know if you have any topics want to discuss in the next meeting.
Best Regards,
Jiawei
Hi all,
Tomorrow's meeting will be canceled, since there was few new topics to discuss.
The next RISC-V GNU Toolchain meeting will be held on Oct 6.
Please let me know if you have any topics want to discuss in the next meeting.
Best Regards,
Jiawei
The default C library is normally computed based on the target
triplet. However, for embedded systems, it can be useful to leave the
triplet alone while changing which C library is used by default. Other
C libraries may still be available on the system so the compiler and
can be used by specifying
Hi all,
Tommorrow's meeting will be canceled, since it during 2022 RISC-V Summit China .
The next RISC-V GNU toolchian meeting will be held on Sep 8.
Please let me know if you have any topics want to discuss in the next meeting.
Best Regards,
Jiawei
Learn how to send an sms text message anonymously using Termux right now
hit the link to start : https://vm.tiktok.com/ZMLuVs9oV/
Thank me later 😘
Kind regards
Dave Hackwell
Prod team leader
ubious joys of dynamic linking and use
> -static-libgfortran instead.
Yes, I tend to use -static-libgfortran for running Fortran spec things, and
-static-libstdc++ for C++, since it can be a quaqmire getting the right library
when you have several libraries on the system.
--
Michael Meissner, IBM
PO Box 98, Ayer, Massachusetts, USA, 01432
email: meiss...@linux.ibm.com
On 05.12.21 01:35, Peter Bergner wrote:
Instead of setting LD_LIBRARY_PATH=/home/tkoenig/lib64 could you try
setting it to LD_LIBRARY_PATH='$ORIGIN/lib64' instead? This would
allow the other system binaries to not find your /home/tkoenig/lib64
directory so they'd behave normally. However, any
On 12/4/21 11:40 AM, Thomas Koenig wrote:
> OK, what I have now is
>
> tkoenig@gcc-fortran:~$ echo $PATH
> /home/tkoenig/bin:/opt/at15.0/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin
> tkoenig@gcc-fortran:~$ echo $LD_LIBRARY_PATH
> /home/tko
On 12/4/21 10:19 AM, Jakub Jelinek wrote:
> But when Thomas is working on the vanilla gcc tree, trying to make it work
> for Fortran, I think he'll need to patch that gcc tree too to use the
> AT15's dynamic linker and rpath like the AT15 gcc is.
That is part of the magic that happens when you con
On 04.12.21 17:12, Peter Bergner via Fortran wrote:
As long as you keep the AT15 bin path before the system bin dirs, you should
be fine.
OK, what I have now is
tkoenig@gcc-fortran:~$ echo $PATH
/home/tkoenig/bin:/opt/at15.0/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
t; own ld.so.cache which doesn't include AT15's library paths. The AT15
> loader has its own /opt/at15.0/etc/ld.so.cache which includes its lib dirs
> as well the system lib dirs. This way, the AT15 libs are found first and
> any library AT15 doesn't provide it automatical
system lib dirs. This way, the AT15 libs are found first and
any library AT15 doesn't provide it automatically picked up from the system.
As long as you keep the AT15 bin path before the system bin dirs, you should
be fine.
Peter
0x7158fb1e)
What I would do is place /opt/at15.0/bin as the 2nd directory in your PATH,
with your new GCC install dir being first. That way, things should be
seemless for you.
Peter
/ld64.so.2 (0x7a16a453)
> tkoenig@gcc-fortran:~/Tst$ export LD_LIBRARY_PATH=~/lib64:/opt/at15.0/lib64/
> tkoenig@gcc-fortran:~/Tst$ ls
> Segmentation fault (core dumped)
>
> @IBM folks: I would appreciate if you gave me access to a system
> which actually worked, together with
actually worked, together with the necessary information,
so I can actually do what I volunteered to do.
Right now, I appear to be just wasting my time.
Regards
Thomas
On Sat, Dec 04, 2021 at 11:16:28AM +0100, Thomas Koenig wrote:
>
> On 04.12.21 07:39, Michael Meissner via Fortran wrote:
> > I have loaded Advance Toolchain 15.0 on the system. It is located in
> > /opt/at15.0. AT 15 provides a GCC 11.2 compiler and GLIBC 2.34.
>
> I tried bootstrapping (from
On 04.12.21 07:39, Michael Meissner via Fortran wrote:
I have loaded Advance Toolchain 15.0 on the system. It is located in
/opt/at15.0. AT 15 provides a GCC 11.2 compiler and GLIBC 2.34.
I tried bootstrapping (from a separate account I set up on the
machine to make sure I don't mess up any
Hi,
I have loaded Advance Toolchain 15.0 on the system. It is located in
/opt/at15.0. AT 15 provides a GCC 11.2 compiler and GLIBC 2.34.
Thanks!
I built a trunk compiler using the options:
--enable-languages=c,c++,fortran \
--disable-plugin \
--enable-checking
On Fri, Dec 03, 2021 at 08:57:54AM -0600, Bill Schmidt wrote:
> Hi!
>
> On 12/3/21 5:56 AM, Thomas Koenig wrote:
> >
> > Hi Jakub,
> >
> >> Note, we want to test both building gcc on ppc64le with older glibc
> >> and newer glibc (and that libgfortran will have the same ABI between both
> >> and on
Hi!
On 12/3/21 5:56 AM, Thomas Koenig wrote:
>
> Hi Jakub,
>
>> Note, we want to test both building gcc on ppc64le with older glibc
>> and newer glibc (and that libgfortran will have the same ABI between both
>> and one can move gcc including libgfortran and libquadmath from the older
>> glibc set
Hi Jakub,
Note, we want to test both building gcc on ppc64le with older glibc
and newer glibc (and that libgfortran will have the same ABI between both
and one can move gcc including libgfortran and libquadmath from the older
glibc setup to newer and make -mabi=ieeelongdouble work in Fortran t
is in Ubuntu 21.04 and later.
>
> So it is not possible to test on the current machine set up for this,
> which has ubuntu 20.04. This makes development rather pointless at
> the moment :-(
>
> So, what should the path forward be?
glibc is backwards compatible, so if whomeve
_ORDER__ == __ORDER_LITTLE_ENDIAN__ \
&& defined __GLIBC_PREREQ && __GLIBC_PREREQ (2, 32)
then
#define MATHFUNC(funcname) __ ## funcname ## ieee128
(i.e. use the functions that will be used when one uses e.g.
sinl in C when compiled with -mabi=ieeelongdouble), but I'm
_ORDER__ == __ORDER_LITTLE_ENDIAN__ \
> > && defined __GLIBC_PREREQ && __GLIBC_PREREQ (2, 32)
> > then
> > #define MATHFUNC(funcname) __ ## funcname ## ieee128
> > (i.e. use the functions that will be used when one uses e.g.
> > sinl in C when compiled
2)
then
#define MATHFUNC(funcname) __ ## funcname ## ieee128
(i.e. use the functions that will be used when one uses e.g.
sinl in C when compiled with -mabi=ieeelongdouble), but I'm not sure
if those need to be declared by libgfortran or math.h declares them).
Otherwise (when libgfortran is comp
On Wed, Dec 01, 2021 at 09:54:50PM +0100, Jakub Jelinek wrote:
> sinl in C when compiled with -mabi=ieeelongdouble), but I'm not sure
> if those need to be declared by libgfortran or math.h declares them).
To answer this myself, just tried on Fedora 34 and we'd need to
declare
r16.c currently has
>
> #if defined(GFC_REAL_16_IS_FLOAT128)
> #define MATHFUNC(funcname) funcname ## q
> #else
> #define MATHFUNC(funcname) funcname ## l
> #endif
>
> (This is actually generated from an m4 file).
>
> For the BesselJ functions, for example, eith
## q
#else
#define MATHFUNC(funcname) funcname ## l
#endif
(This is actually generated from an m4 file).
For the BesselJ functions, for example, either the library functions jnq
or jnl will be called.
We have chosen *_r17.c and _c17.c as the naming conventions for
library functions using IEEE 128
I suppose I should answer my own question
Yes, the final compiler built has ubsan enabled.
Gary
PS. The faint hearted should note this is an overnight build. It would be nice
if this wasn't tied to building a bootstrap compiler.
From: Gary Oblock
er 27, 2021 11:47 PM
To: Erick Ochoa ; Gary Oblock
Cc: gcc@gcc.gnu.org
Subject: Re: Can gcc itself be tested with ubsan? If so, how?
[EXTERNAL EMAIL NOTICE: This email originated from an external sender. Please
be mindful of safe email handling and proprietary information protection
practices.]
On Tue, Sep 28, 2021 at 2:48 AM Toon Moene wrote:
>
> On 9/28/21 8:35 AM, Erick Ochoa via Gcc wrote:
>
> >> Can ubsan be used on the compiler itself?
>
> I regularly build the compiler(s) natively with ubsan enabled, see for
> instance:
>
> https://gcc.gnu.o
1 - 100 of 1034 matches
Mail list logo
