[Bug target/95450] [10/11 regression] Wrong long double folding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95450
Carlos O'Donell changed:
What|Removed |Added
CC||carlos at redhat dot com
--- Comment #4 from Carlos O'Donell ---
(In reply to Andreas Schwab from comment #0)
> $ cat test-float.c
> #include
> #include
>
> union gl_long_double_union
> {
> struct { double hi; double lo; } dd;
> long double ld;
> };
>
> const union gl_long_double_union gl_LDBL_MAX =
> { { DBL_MAX, DBL_MAX / (double)134217728UL / (double)134217728UL } };
> # undef LDBL_MAX
> # define LDBL_MAX (gl_LDBL_MAX.ld)
>
> int
> main ()
> {
> volatile long double m = LDBL_MAX;
>
> assert (m + m > m);
> }
> $ gcc -O2 test-float.c
> $ ./a.out
> a.out: test-float.c:20: main: Assertion `m + m > m' failed.
> Aborted
>
> test-float.c.234t.optimized contains:
>
> m ={v} 1.79769313486231580793728971405302307166001572487e+308;
>
> but that evaluates to Inf. DBL_MAX is
> 1.79769313486231570814527423731704e+308L.
This comes from gnulib's use of lib/float.h.
My question is why is gnulib using float.h on power? What makes the system
float.h unsuable?
Even if you fix this for your package including gnulib, the next failure you
run into is this one:
test-float.c:324: assertion 'x + x == x' failed
Aborted (core dumped)
Extracting from the test case:
#include
#include
#include
#include
int
main (void)
{
int n = 107;
volatile long double m = LDBL_MAX;
volatile long double pow2_n = powl (2, n);
volatile long double x = m + (m / pow2_n);
printf ("n = %d\n", n);
printf ("m = %Lf (%La)\n", m, m);
printf ("pow2_n = %Lf (%La)\n", pow2_n, pow2_n);
printf ("m / pow2_n = %Lf (%La)\n", (m / pow2_n), (m / pow2_n));
printf ("x = %Lf (%La)\n", x, x);
if (x > m)
assert (x + x == x);
return 0;
}
gcc -o ~/test-ldbl-max ~/test-ldbl-max.c -lm
~/test-ldbl-max
n = 107
m =
179769313486231580793728971405301199252069012264752390332004544495176179865349768338004270583473493681874097135387894924752516923758125018237039690323659469736010689648748751591634331824498526377862231967249520608291850653495428451067676993116107021027413767397958053860876625383538022115414866471826801819648.00
(0x1.f78p+1023)
pow2_n = 162259276829213363391578010288128.00 (0x1p+107)
m / pow2_n =
1107913932560222581216724223049124694376931327937918798971295069363205703164244740389102844506567402654244799528342026118673562844811584683014545030137100678976901567468093855075985516353544747282849589098225960074532039651619564827101237983225846137075291097947344654582153216.00
(0x1.f78p+916)
x =
179769313486231580793728971405301199252069012264752390332004544495176179865349768338004270583473493681874097135387894924752516923758125018237039690323659469736010689648748751591634331824498526377862231967249520608291850653495428451067676993116107021027413767397958053860876625383538022115414866471826801819648.00
(0x1.f7cp+1023)
test-ldbl-max: /root/test-ldbl-max.c:21: main: Assertion `x + x == x' failed.
Aborted (core dumped)
Is this just a function of double double?
That there is something representable that is larger than LDBL_MAX, but isn't
valid given the double-double rules?
[Bug middle-end/96200] Implement __builtin_thread_pointer() and __builtin_set_thread_pointer() if TLS is supported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96200 --- Comment #2 from Carlos O'Donell --- (In reply to Florian Weimer from comment #1) > __builtin_set_thread_pointer has little value from a glibc perspective > because when used in application code, it will always result in undefined > behavior. Correct, but it's useful for a C library implemetnation. In glibc the aarch64 tls.h is made quite clean by the use of __builtin_thread_pointer and __builtin_set_thread_pointer.
[Bug middle-end/96200] New: Implement __builtin_thread_pointer() and __builtin_set_thread_pointer() if TLS is supported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96200 Bug ID: 96200 Summary: Implement __builtin_thread_pointer() and __builtin_set_thread_pointer() if TLS is supported Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: carlos at redhat dot com Target Milestone: --- In glibc we implement the equivalent of __builtin_thread_pointer() and __builtin_set_thread_pointer() to access data that is at a constant offset from the thread pointer. For many of the architectures that have the builtins their tls.h implementation in glibc is greatly simplified because they can use the builtin. We have some ABIs that are defined as having data of a certain size and alignment at a fixed offset from the thread pointer e.g. stack_guard, pointer_guard, TM ABI, __private_ss (split stack) etc. In relation to restartable sequences in the linux kernel it was discussed that it might be interesting to have an ABI that also uses TP + offset, where glibc provides the "offset" via an API, but the user is left to do the "TP + offset" calculation on their own. https://lore.kernel.org/linux-api/2452161.11491.1594732791558.javamail.zim...@efficios.com/ "Is there an arch-agnostic way to get the thread pointer from user-space code ? That would be needed by all rseq critical section implementations." We should support these two builtins for all targets that support TLS.
[Bug libstdc++/95048] wstring-constructor of std::filesystem::path throws for non-ASCII characters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95048
Carlos O'Donell changed:
What|Removed |Added
CC||carlos at redhat dot com
--- Comment #2 from Carlos O'Donell ---
(In reply to Jonathan Wakely from comment #1)
> This happens because glibc won't convert the wide string to UTF-8:
>
> #include
> #include
>
> int main()
> {
> const wchar_t wstr[] = L"ä";
> const wchar_t* from = wstr;
> char to[10];
> mbstate_t s;
> size_t res = wcsnrtombs(to, , 1, sizeof(to), );
> assert(res != (size_t)-1);
> }
>
> I'm not yet sure why glibc refuses to convert that.
ISO C says:
"At program startup, the equivalent of
setlocale(LC_ALL, "C");
is executed."
Which means you are trying to convert UTF-8 to ASCII.
You should call setlocale with a non-ASCII character set to make this work.
[Bug d/91628] libdruntime uses glibc internal symbol on s390
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91628 --- Comment #14 from Carlos O'Donell --- My preference for would be a distinct *.S file as Florian suggests, it's the most robust solution. The only other alternative I would consider is a new __builtin_get_tls_offset() that does what you want, and then use the builtin. It complicates backporting but solves the problem for all runtimes that want access to a __tls_get_addr() equivalent for the architecture.
[Bug d/91628] libdruntime uses glibc internal symbol on s390
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91628 Carlos O'Donell changed: What|Removed |Added CC||carlos at redhat dot com --- Comment #1 from Carlos O'Donell --- If the D runtime, or libphobos in particular, has a need to get a lower-level view of the TLS runtime then we should work together to formalize what's required and provide a low-level TLS ABI. Note that is also the case for Rust which uses __pthread_get_minstack@@GLIBC_PRIVATE, and this has prevented us from doing valid and meaningful cleanup of the libpthread internals to remove this function. The related glibc bug is here: https://sourceware.org/bugzilla/show_bug.cgi?id=16291 It would be great to get feedback on the required API and needs.
[Bug c/70082] Attribute ifunc marked functions should not be allowed to call other functions.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70082 --- Comment #7 from Carlos O'Donell --- (In reply to Martin Sebor from comment #6) > Carlos, do you still feel diagnosing some of the [mis]uses would be helpful, > e.g., by a warning? (I ask because I've been doing some work in this area > -- pr81824 -- and I might be able to take care of this at some point as > well, perhaps for GCC 10). I do still believe that detection and warning of misuses of IFUNC would be helpful. The glibc solutions required to make IFUNC robust are not in place, and so we should do what we can to warn users that it might break. They can then disable the warnings with pragmas (in the case of -Werror) or ignore them.
[Bug target/84829] -mieee-fp causes to link with -lieee but that is no longer available
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84829 --- Comment #8 from Carlos O'Donell --- (In reply to Florian Weimer from comment #6) > (In reply to Jakub Jelinek from comment #5) > > -mieee-fp does affect code generation on x86 and m68k, but I don't see how > > it is related to any changes in glibc. > > And besides code generation changes it affects whether -lieee is linked in > > or not. > > It matters from the users' point of view. I think it's better to give them > a build error when they use unsupported functionality, rather than giving > the wrong results at run time. The overloaded nature of -mieee-fp makes > this difficult to achieve, though. I agree. My own opinion is that I would rather see a link-time failure for user applications that use any interfaces that are no longer supported for building new programs. Therefore it is that -mieee-fp is no longer supported with glibc 2.27, you cannot use it, and it will not work. You must XFAIL any such tests if you are using a glibc with the obsoleted matherr, _LIB_VERSION, and libieee.a functionality. Opinions vary though, since -mieee-fp is intended to require IEEE semantics, and that is now the default in glibc, we could just keep silently supporting -mieee-fp as the default. I think that Joseph will need to comment on thoughts about the behaviour of using deprecated interfaces.
[Bug sanitizer/71445] libsanitizer build failure on aarch64-linux-gnu with recent glibc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71445 Carlos O'Donell changed: What|Removed |Added CC||carlos at redhat dot com --- Comment #13 from Carlos O'Donell --- (In reply to Adhemerval Zanella from comment #12) > After checking the work required for enable symbol versioning wrapper on > libsanitizer I am more inclined to go with always ignore the high bits (at > least for backports). The versioning enablement will require some changes > and I foresee it will generate some discussion in sanitizer side before a > settle solution is used. Any suggestions? +1 That sounds like the most sensible course of action. The real solution IMO is for the interposer to provide all the various versions of a function and sanitize them each as needs be. There is no other way around this and this was a problem that was going to happen some day, we are just having it happen today because of the changes in glibc.
[Bug c++/66830] Problem with C++ unique symbols in plugins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66830 Carlos O'Donell changed: What|Removed |Added CC||carlos at redhat dot com --- Comment #4 from Carlos O'Donell --- (In reply to pleuba from comment #3) > Is this problem/behavior referenced or documented somewhere? I did not find > any explanation on the internet. > > It take me some time to understand it, and if we can avoid others to spend > this time too. > > Are they any plans to fix this or disable unique symbols by default ? The dynamic loader could mark all users of an STB_GNU_UNIQUE symbol as RTLD_NODELETE. It seems like the only answer. That would mean you can't unload any of your plugins, and would make using C++ for dynamic plugin work very difficult. A long-running process could never change these plugins. The author of the plugins would have to understand intimate ABI details to write unloadable plugins or use another language that doesn't have these problems.
[Bug c/70082] Attribute ifunc marked functions should not be allowed to call other functions.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70082 --- Comment #5 from Carlos O'Donell --- Would it be a better solution to: (a) Fix PLT initialization on arm and ppc64 (allows some function calls to be made). (b) Document safe functions in glibc manual. (c) Have gcc manual reference glibc manual safe functions list. This way we avoid the compiler enforcement and allow developers, particularly compiler developers, to continue using ifunc in ways which are known to work (particularly look at the i386 multiversioning support which uses ifunc to call out to libgcc's __cpu_indicator_init).
[Bug c/70082] Attribute ifunc marked functions should not be allowed to call other functions.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70082 --- Comment #4 from Carlos O'Donell --- (In reply to Jakub Jelinek from comment #3) > I don't think the compiler should do the policeman here, it is enough if > glibc documents what it does and doesn't support in ifunc (which is of > course generally arch dependent, it really depends on if you need e.g. > RELATIVE relocations relocated in the current library/binary already, or if > you need other data relocations, etc. E.g. calling hidden function or even > non-hidden, as long as you hide it in symbol version script, is fine. > Calling function from other library very likely not. The compiler is already a policeperson :-) The compiler enforces language standards. The compiler enforces that ifunc attribute functions can't be declared weak or weakref. Why not enforce the rest of the safe behaviour of the IFUNC extension? Is it hard to enforce the rest of the requirements? Are we worried that because we haven't enforced these rules over the last 6 years (typo, the implementation was added in 2010 not 2005 for IFUNC attribute usage) that people are using attribute ifunc with all their caveats in ways which we will now restrict? I don't particularly see how this is any different from tightening a language standard. However, I agree it's a concern. Packages are only just starting to use IFUNC, and we should improve what we have at both the documentation and implementation level. Filed this glibc bug to bring i386 and x86_64 up the level of all the other arches: "Bug 19766 - All machines should pass dl_hwcap to ifunc resolvers." https://sourceware.org/bugzilla/show_bug.cgi?id=19766 With bug 19766 fixed the x86_64 ifunc resolvers should be able to do something safely (though it will require a gcc change to generate the dep on a glibc version to ensure it works without error).
[Bug c/70082] Attribute ifunc marked functions should not be allowed to call other functions.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70082 --- Comment #2 from Carlos O'Donell --- There might be the case where it is argued that documentation is all that is needed, but that doesn't yield a robust implementation. My biggest worry after seeing gperftools/tcmalloc use IFUNC is that it works on x86_64 by chance, but nowhere else. This poses a serious portability problem for ARM and IBM architectures which differ in the order of relocation processing. Thus I'd like to see ifunc attribute support the common case of code which does some computation based on AT_HWCAP (we'll pass this to all x86_64 ifunc resolvers like newer arches do) and then return a result.
[Bug c/70082] Attribute ifunc marked functions should not be allowed to call other functions.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70082 --- Comment #1 from Carlos O'Donell --- ... and non-local variable access should be disallowed, as well as TLS variables, and anything that needs a constructor to be initialized (non-POD).
[Bug c/70082] New: Attribute ifunc marked functions should not be allowed to call other functions.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70082 Bug ID: 70082 Summary: Attribute ifunc marked functions should not be allowed to call other functions. Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: carlos at redhat dot com Target Milestone: --- In 2005 the GNU IFUNC support was documented and added to GCC via the ifunc attribute. To be honest this was a mistake, the feature is not documented and the implementation has so many caveats that it is incredibly difficult to use. Recently gperftools added IFUNC usage in tcmalloc and they did a lot of things which break the IFUNC implementation in general, but happy to work by luck on x86_64. I have documented some of this here: https://sourceware.org/glibc/wiki/GNU_IFUNC The IFUNC support is salvageable, but will require some reworking across the various architectures to organize the relocations in a sensible way, and even then it's going to be hard to allow everything. Particularly with -Wl,-z,now which needs to complete all relocations early. To that end, and until we fix IFUNC, the use of the ifunc attribute in a function should immediately cause compilation to fail if that function calls any other function. There is simply no way to guarantee you can make that function call safely at early ld.so startup. You might allow calls to functions in the same translation unit, but then you'd have to make sure those functions don't also call other external functions. It's simply safer to limit the use to something that works. Is such a fix feasible?
[Bug libstdc++/68921] [5/6 Regression] std::future::wait() makes invalid futex calls and spins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68921 Carlos O'Donell changed: What|Removed |Added CC||carlos at redhat dot com --- Comment #2 from Carlos O'Donell --- (In reply to Jonathan Wakely from comment #1) > This fixes it: > > --- a/libstdc++-v3/src/c++11/futex.cc > +++ b/libstdc++-v3/src/c++11/futex.cc > @@ -52,7 +52,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION > // we will fall back to spin-waiting. The only thing we could do > // here on errors is abort. > int ret __attribute__((unused)); > - ret = syscall (SYS_futex, __addr, futex_wait_op, __val); > + ret = syscall (SYS_futex, __addr, futex_wait_op, __val, nullptr); > _GLIBCXX_DEBUG_ASSERT(ret == 0 || errno == EINTR || errno == EAGAIN); > return true; >} That is correct. futex.2 from draft_futex upstream branch of linux man pages project: ~~~ If the timeout argument is non-NULL, its contents specify a relative timeout for the wait, measured according to the CLOCK_MONOTONIC clock. (This inter‐ val will be rounded up to the system clock granularity, and is guaranteed not to expire early.) If timeout is NULL, the call blocks indefinitely. ~~~ I assume you want to block indefinitely.
[Bug c/66825] New: RFE: Add attributes for symbol versioning.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66825
Bug ID: 66825
Summary: RFE: Add attributes for symbol versioning.
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: carlos at redhat dot com
Target Milestone: ---
At present gcc supports alias, weak, section, optimize, used, visibility,
tls_model, and that lets user application do a lot of things with functions,
particularly with respect to creating aliases, changing their visibility and
linkage properties (weak vs. strong). I expect that some of these attributes
apply only to ELF support in the toolchain as a whole.
What we are missing is symbol versioning for ELF, and the alias attribute can't
be used for this (treats the target as the function name without understanding
versions).
At present in glibc we need to do the following:
# define _symbol_version(real, name, version) \
__asm__ (.symver #real , #name @ #version)
# define _default_symbol_version(real, name, version) \
__asm__ (.symver #real , #name @@ #version)
It would be nice if symbol versioning did not require __asm__ directives which
in general hide such information from the compiler and potential plugins.
I have no requirements as to how it should or could be implemented, and I leave
that up to the gcc developers to think about.
My suggestion is that at a minimum it needs a name, version, and default flag
(to avoid conflating @ or @@ into the version name), and it might look like
this:
version_def (target, version, default)
* The attribute may only be applied to a function definition. The attribute
creates a definition of a versioned symbol. The function is aliased under the
symbol TARGET with version VERSION. The symbol TARGET is the default symbol,
resolves other references without versions, only if DEFAULT is true.
Example:
int foo (void) __attribute__ ((version (bar, BARLIB_1.0, true)))
{
return 0;
}
int foo2 (void) __atttribute__ ((version (bar, BARLIB_0.9, false)))
{
return 2;
}
These functions will be available for linking and if that is not what you want
then you must use the features of your linker to limit the set of exported
functions. For GNU ld the link map nodes will correspond to the versions and a
link map will be required.
e.g.
BARLIB_1.0 {
global: bar;
local: *;
}
BARLIB_0.9 {
global: bar;
local: *;
}
Implementation note:
- Use `.symver` to implement the attribute, and if default is true you use @@
otherwise one @ for the symbol version.
Notes:
- After implementing this we could make gcc us it also and update the wiki
page:
https://gcc.gnu.org/wiki/SymbolVersioning
- A follow-up to this is version_ref attribute which allows you to create a
declaration of a function e.g. extern int memcpy (void) __attribute__
((version_ref (memcpy, GLIBC_2.2.5, false))); at a particular version/default
(for symmetry with version_def) and then all callers in the compilation unit
will call through that version (the version you want to reference, hence
version_ref). This can be used to create test applications that call old
versions of symbols without needing the old DSOs to link against. This again
works using .symver, but requires that memcpy not be implemented in the present
object file. The .symver without a definition of the function causes the object
to reference the alias at that particular version and thus lets you link
against old versions of functions. This is limited in scope to just the single
file you compiled. So you could for example write tests that test each of the
new and old symbol versions without using asm inlines and the compiler could be
aware of function versions (for some future purpose).
[Bug target/60925] [4.9/5 Regression] hppa: can't find a register in class 'R1_REGS' while reloading 'asm'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60925 Carlos O'Donell carlos at redhat dot com changed: What|Removed |Added CC||carlos at redhat dot com --- Comment #13 from Carlos O'Donell carlos at redhat dot com --- For the record I made glibc use %r5 and saved/restored %r1 as required around the syscall. I also added more clobbers in the event of future changes to the kernel interface. This works around the can't find a register in class FOO while reloading 'asm' error from the compiler. The real culprit here is atomic.h in glibc and the asm in question is the atomic compare and exchange that is being done via the light-weight kernel syscall.
[Bug other/56955] documentation for attribute malloc contradicts itself
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56955 Carlos O'Donell carlos at redhat dot com changed: What|Removed |Added CC||carlos at redhat dot com --- Comment #7 from Carlos O'Donell carlos at redhat dot com --- (In reply to Paul Eggert from comment #6) Created attachment 32831 [details] Clarify documentation for __attribute__ ((malloc)). This topic recently came up on the glibc mailing list and there's clearly a lot of confusion about it. See, for example, https://sourceware.org/ml/libc-alpha/2014-05/msg00519.html. Attaching a proposed patch to the documentation to try to help clear this up. s/Ussing/Using/g, otherwise the patch in attachment #32831 looks great to me.
[Bug other/59920] [4.9 Regression] build doesn't terminate (at least after an hour)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59920 Carlos O'Donell carlos at redhat dot com changed: What|Removed |Added CC||carlos at redhat dot com --- Comment #3 from Carlos O'Donell carlos at redhat dot com --- (In reply to Jakub Jelinek from comment #2) Is it valid to longjmp to a setjmp where the containing function hasn't terminated yet, but the scope in which the setjmp has been declared has been left already? IMO this is undefined behaviour. I can't convince myself that can be anything but that. However, as written ISO C allows this, but it's allowance would require that the entire state of the scope should be kept around for the duration of the function just to satisfy the wording of setjmp/longjmp in the standard. I can't justify that to myself. An implementation might detect a setjmp in the scope, along with volatile or non-automatic variables and then making sure the state of the scope is never reused so a longjmp can return to it.
[Bug middle-end/51255] Using -fwhole-program breaks code which puts values in .ctors or .init_array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51255 Carlos O'Donell carlos at redhat dot com changed: What|Removed |Added CC||carlos at redhat dot com --- Comment #7 from Carlos O'Donell carlos at redhat dot com --- (In reply to Krisztian Kocsis from comment #6) I currently know that glibc uses it but don't know who else use it. In my projects I always use constructor/destructor attributes because with them I can control the exection order. Internally glibc uses attribute used to mark any special .init_array sections as used. It is only in our configure check and some tests that we don't use the used attribute (bug in glibc). Building the library with -fwhole-program has never been tested and likely won't succeed without a lot of additional work.
