The 05/20/2020 09:02, Florian Weimer via Gcc wrote:
> * Richard Henderson:
> > On 5/19/20 3:38 AM, Florian Weimer via Gcc wrote:
> >> One minor improvement would be to document __aarch64_have_lse_atomics as
> >> interposable on the GCC side and define that directly in glibc, so that
> >> lse-init.o
On 01/07/15 16:34, Zinovy Nis wrote:
> The only idea on size difference I have is:
>
> headers text in many of FP-emulation files from compiler_rt contains lines
> like:
>
> // This file implements quad-precision soft-float addition ***with the
> IEEE-754 default rounding*** (to nearest, ties to
On 09/07/15 16:56, David Talmage wrote:
> I'm looking for a way to specify the LD_LIBRARY_PATH or LD_PRELOAD on the
> target system when running one of the DejaGNU test suites. I'm testing a gcc
> cross-compiler on a development board. I can't replace existing versions of
> libraries under test
* Zack Weinberg [2015-09-09 15:03:50 -0400]:
> On 09/09/2015 02:02 PM, paul_kon...@dell.com wrote:
> >> On Sep 9, 2015, at 1:54 PM, David Edelsohn
> >> wrote:
> >>
> >> What level of erasure of sensitive data are you trying to ensure?
> >> Assuming that overwriting values in the ISA registers a
On 25/09/15 21:16, Eric Botcazou wrote:
First, a belated follow-up to https://gcc.gnu.org/PR66512 . The bug is
asking why attribute-const appears to have a weaker effect in C++, compared
to C. The answer in that bug is that GCC assumes that attribute-const
function can terminate by throwing an ex
On 22/10/15 10:23, libin wrote:
From: Jiangjiji
Date: Sat, 10 Oct 2015 15:29:57 +0800
Subject: [PATCH] * gcc/config/aarch64/aarch64.opt: Add a new option.
* gcc/config/aarch64/aarch64.c: Add some new functions and Macros.
* gcc/config/aarch64/aarch64.h: Modify PROFILE_HOOK and FUNCTION_PROFI
On 22/10/15 11:14, AKASHI Takahiro wrote:
On 10/22/2015 06:07 PM, libin wrote:
在 2015/5/28 16:39, Maxim Kuvyrkov 写道:
Our proposal is that instead of adding -mfentry/-mnop-count/-mrecord-mcount
options to other architectures,
we should
implement a target-independent option -fprolog-pad=N, which
On 23/10/15 10:11, AKASHI Takahiro wrote:
On 10/22/2015 07:26 PM, Szabolcs Nagy wrote:
On 22/10/15 11:14, AKASHI Takahiro wrote:
I also have my own version of livepatch support for arm64 using yet-coming
"-fprolog-add=N" option :)
As we discussed before, the main difference will
* H.J. Lu [2016-02-08 11:24:53 -0800]:
> I created a mailing list to discuss Linux specific,.processor independent
> modification and extension of generic System V Application Binary Interface:
>
> https://groups.google.com/d/forum/linux-abi
>
> I will start to document existing Linux extensions
On 15/02/16 16:03, H.J. Lu wrote:
> On Mon, Feb 15, 2016 at 7:37 AM, Alexandre Oliva wrote:
>> On Feb 12, 2016, Pedro Alves wrote:
>>
>>
wonderful. I am not a big fan of google groups mailinglists, they seem
to make it hard to subscribe and don't have easy to access archives.
Havin
On 15/02/16 17:36, Mike Frysinger wrote:
> On 15 Feb 2016 16:18, Szabolcs Nagy wrote:
>> you as a group admin can do that, others cannot join
>> without creating a account at google (which requires
>> the acceptance of the google tos etc).
>
> that is annoying
i di
On 08/04/16 11:09, Ulrich Windl wrote:
> Probably I'm doing something wrong, but I have some problems comparing a
> double with NAN: The value is NAN, but the test fails. Probably I should use
> isnana().
yes, that's how ieee works, nan != nan is true.
On 19/04/16 09:20, Richard Biener wrote:
> On Tue, Apr 19, 2016 at 7:08 AM, Alan Modra wrote:
>> On Mon, Apr 18, 2016 at 07:59:50AM -0700, H.J. Lu wrote:
>>> On Mon, Apr 18, 2016 at 7:49 AM, Alan Modra wrote:
On Mon, Apr 18, 2016 at 11:01:48AM +0200, Richard Biener wrote:
> To summarize:
On 13/04/16 14:01, Cristina Georgiana Opriceana wrote:
> I bring to your attention SafeStack, part of a bigger research project
> - CPI/CPS [1], which offers complete protection against stack-based
> control flow hijacks.
i think it does not provide complete protection.
it cannot instrument the c
building gcc6 using musl based gcc6 fails with symbol poisoning error
(details at the end of the mail).
the root cause is c++: c++ headers include random libc headers with
_GNU_SOURCE ftm so all sorts of unexpected symbols are defined/declared.
since it's unlikely the c++ standard gets fixed (to
On 21/04/16 12:36, Richard Biener wrote:
> On Thu, Apr 21, 2016 at 1:11 PM, Szabolcs Nagy wrote:
>> building gcc6 using musl based gcc6 fails with symbol poisoning error
>> (details at the end of the mail).
>>
>> the root cause is c++: c++ headers include random libc
On 21/04/16 12:52, Jonathan Wakely wrote:
> On 21 April 2016 at 12:11, Szabolcs Nagy wrote:
>> the root cause is c++: c++ headers include random libc headers with
>> _GNU_SOURCE ftm so all sorts of unexpected symbols are defined/declared.
>
> Yes, I'd really like t
On 09/05/16 22:45, Michael Matz wrote:
> On Mon, 9 May 2016, Rich Felker wrote:
>
>>> Done. I never understood why they left in the hugely unuseful
>>> {sig,}{set,long}jmp() but removed the actually useful *context()
>>> (amended somehow like above).
>>
>> Because those are actually part of the
On 23/05/16 12:36, MM wrote:
> Hello,
>
> g++ (GCC) 5.3.1 20160406 (Red Hat 5.3.1-6)
> GNU gold (version 2.25-17.fc23) 1.11
> I successfully link a executable in debug mode (-std=c++11 -g) but not in
> release mode (-std=c++11 -flto -O3). All sources are compiled with the same
> option. Shared lib
On 23/05/16 14:24, MM wrote:
> On 23 May 2016 at 12:53, Szabolcs Nagy wrote:
>> On 23/05/16 12:36, MM wrote:
>>> Hello,
>>>
>>> g++ (GCC) 5.3.1 20160406 (Red Hat 5.3.1-6)
>>> GNU gold (version 2.25-17.fc23) 1.11
>>> I successfully link
On 23/06/16 12:18, Pedro Alves wrote:
> gdb doesn't put that gnulib wrapper library at the top level, mainly
> just because of history -- we didn't always have that wrapper
> library -- and the fact that gdb/gdbserver/ itself is not at top
> level either, even though it would be better moved to top
On 17/11/16 20:12, Bin Fan wrote:
>
> Although this ABI specification specifies that 16-byte properly aligned
> atomics are inlineable on platforms
> supporting cmpxchg16b, we document the caveats here for further discussion.
> If we decide to change the
> inlineable attribute for those atomics,
On 20/12/16 13:26, Ulrich Weigand wrote:
> Torvald Riegel wrote:
>> On Fri, 2016-12-02 at 12:13 +0100, Gabriel Paubert wrote:
>>> On Thu, Dec 01, 2016 at 11:13:37AM -0800, Bin Fan at Work wrote:
Thanks for the comment. Yes, the ABI requires libatomic must query the
hardware. This is
>>>
On 22/12/16 17:37, Segher Boessenkool wrote:
> We do not always have all atomic instructions. Not all processors have
> all, and it depends on the compiler flags used which are used. How would
> libatomic know what compiler flags are used to compile the program it is
> linked to?
>
> Sounds like
On 06/01/17 12:48, Jakub Jelinek wrote:
> SUSE and some other distros use a hack that omits the minor and patchlevel
> versions from the directory layout, just uses the major number, it is very
what is the benefit?
On 06/01/17 13:11, Jakub Jelinek wrote:
> On Fri, Jan 06, 2017 at 01:07:23PM +0000, Szabolcs Nagy wrote:
>> On 06/01/17 12:48, Jakub Jelinek wrote:
>>> SUSE and some other distros use a hack that omits the minor and patchlevel
>>> versions from the directory layout, jus
the weakref magic in libgcc/gthr-posix.h is not guaranteed to work
which can at least break libstdc++ with static linking and dlopen
there are several bugs here:
- fallback code (unknown posix systems) should assume multi-threaded
application instead of using a fragile threadedness test
- determ
On 13/09/18 14:52, Florian Weimer wrote:
> On 09/13/2018 03:27 PM, Wilco Dijkstra wrote:
>> Hi,
>>
>> The existing sincos functions use 2 pointers to return the sine and cosine
>> result. In
>> most cases 4 memory accesses are necessary per call. This is inefficient and
>> often
>> significantly
On 11/10/18 04:53, Alexandre Oliva wrote:
> On Oct 10, 2018, Rich Felker wrote:
>> For aarch64 at least, according to discussions I had with Szabolcs
>> Nagy, there is an intent that any new extensions to the aarch64
>> register file be treated as clobbered by tlsdesc func
On 15/11/18 10:29, Richard Biener wrote:
> In my view (I proposed the thing) the most interesting parts are
> getting GCCs global state documented and reduced. The parallelization
> itself is an interesting experiment but whether there will be any
> substantial improvement for builds that can alre
On 10/01/2019 08:19, Richard Biener wrote:
> On Wed, 9 Jan 2019, Jakub Jelinek wrote:
>
>> On Wed, Jan 09, 2019 at 11:10:25AM -0500, David Malcolm wrote:
>>> extern void vf1()
>>> {
>>>#pragma vectorize enable
>>>for ( int i = 0 ; i < 32768 ; i++ )
>>> data [ i ] = std::sqrt ( data [
Arm released an update (2019Q1.1) of the Vector Function ABI specifications for
AArch64 that uses the `declare variant` directive from OpenMP 5.0 to support
user
defined vector functions. The mechanism is introduced in chapter 4, and it is in
beta release status to allow feedback from the open sou
On 17/05/2019 14:51, Tom Horsley wrote:
> I'm trying (for reason too complex to go into) to
> locate the TLS offset of the tcache_shutting_down
> variable from malloc in the ubuntu provided
> glibc on aarch64 ubuntu 18.04.
>
> Various "normal" TLS variables appear to operate
> much like x86_64 wit
On 20/05/2019 16:59, Tom Horsley wrote:
> On Mon, 20 May 2019 15:43:53 +
> Szabolcs Nagy wrote:
>
>> you can verify that 0x152000 + 3608 == 0x152e18 is
>> indeed a GOT entry (falls into .got) and there is a
>>
>> 00152e18 R_AARCH64_TLS_TPREL64 *ABS*+
The lazy binding code of aarch64 currently only preserves q0-q7 of the
fp registers, but for an SVE call [AAPCS64+SVE] it should preserve p0-p3
and z0-z23, and for an AdvSIMD vector call [VABI64] it should preserve
q0-q23. (Vector calls are extensions of the base PCS [AAPCS64].)
A possible fix is
On 22/05/2019 16:06, Florian Weimer wrote:
> * Szabolcs Nagy:
>
>> AAELF64: in the Symbol Table section add
>>
>> st_other Values
>> The st_other member of a symbol table entry specifies the symbol's
>> visibility in the lowest 2 bi
On 22/05/2019 16:34, Florian Weimer wrote:
> * Szabolcs Nagy:
>
>> On 22/05/2019 16:06, Florian Weimer wrote:
>>> * Szabolcs Nagy:
>>>
>>>> AAELF64: in the Symbol Table section add
>>>>
>>>> st_other Values
>>>&g
On 22/05/2019 15:42, Szabolcs Nagy wrote:
> [AAELF64]: ELF for the Arm 64-bit Architecture (AArch64)
>https://developer.arm.com/docs/ihi0056/latest
> [VABI64]: Vector Function ABI Specification for AArch64
>
> https://developer.arm.com/tools-and-software/ser
On 04/07/2019 12:27, Florian Weimer wrote:
> Implicit function declarations were removed from C99, more than twenty
> years ago. So far, GCC only warns about them because there were too
> many old configure scripts where an error would lead to incorrect
> configure check failures.
>
> I can try t
On 27/09/2019 20:23, GT wrote:
> I am attempting to create a vector version of sincos for PPC64.
> The relevant discussion thread is on the GLIBC libc-alpha mailing list.
> Navigate it beginning at
> https://sourceware.org/ml/libc-alpha/2019-09/msg00334.html
>
> The intention is to reuse as much
On 30/09/2019 18:30, GT wrote:
> ‐‐‐ Original Message ‐‐‐
> On Monday, September 30, 2019 9:52 AM, Szabolcs Nagy
> wrote:
>
>> On 27/09/2019 20:23, GT wrote:
>>
>>> I am attempting to create a vector version of sincos for PPC64.
>>> The relev
On 19/11/2019 23:44, Joseph Myers wrote:
> I do think "Related to PR N (description)" or similar is a good
> summary line to insert where the present summary line is just a ChangeLog
> date/author line.
i agree.
On 07/01/2020 07:25, Fangrui Song wrote:
> On 2020-01-06, Fangrui Song wrote:
>> The addresses of NOPs are collected in a section named
>> __patchable_function_entries.
>> A __patchable_function_entries entry is relocated by a symbolic relocation
>> (e.g. R_X86_64_64, R_AARCH64_ABS64, R_PPC64_ADD
On 25/01/17 19:02, Aaro Koskinen wrote:
> Configured with: ../gcc-6.3.0/configure --with-arch=armv8-a+crc
> --with-cpu=cortex-a53 --disable-multilib --disable-nls
> --prefix=/home/aaro/gcctest/newcompiler --enable-languages=c,c++
> --host=aarch64-unknown-linux-gnu --build=aarch64-unknown-linux-g
On 20/02/17 07:49, Sebastian Huber wrote:
> Hello Gokan,
>
> you may have a look at:
>
> https://svnweb.freebsd.org/base/head/lib/libstdthreads/
note that despite the looks this is non-portable
and non-conforming implementation, it is way better
than the posted github code, but it can still clob
On 05/07/17 16:38, H.J. Lu wrote:
> On x86-64, __tls_get_addr has to realigns stack so that binaries compiled by
> GCCs older than GCC 4.9.4:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58066
>
> continue to work even if vector instructions are used by functions called
> from __tls_get_addr,
On 05/07/17 17:18, H.J. Lu wrote:
> On Wed, Jul 5, 2017 at 8:53 AM, Szabolcs Nagy wrote:
>> On 05/07/17 16:38, H.J. Lu wrote:
>>> On x86-64, __tls_get_addr has to realigns stack so that binaries compiled by
>>> GCCs older than GCC 4.9.4:
>>>
>>> https
On 15/08/17 04:10, Martin Sebor wrote:
> On 08/14/2017 04:22 PM, Eric Gallager wrote:
>> I'm emailing this manually to the list because Bugzilla is down and I
>> can't file a bug on Bugzilla about Bugzilla being down. The error
>> message looks like this:
>
> Bugzilla and the rest of gcc.gnu.org h
On 15/08/17 16:21, Ron wrote:
> On Tue, Aug 15, 2017 at 01:31:10PM +0200, Richard Biener wrote:
>> On Tue, Aug 15, 2017 at 1:28 PM, Jonathan Wakely
>> wrote:
>>> On 15 August 2017 at 11:24, Richard Biener
>>> wrote:
On Tue, Aug 15, 2017 at 6:44 AM, Ron wrote:
> On Mon, Aug 14, 2017 at
On 15/08/17 16:47, Richard Biener wrote:
> On Tue, Aug 15, 2017 at 5:21 PM, Ron wrote:
>> Is changing the cancellation state really an expensive operation?
>> Moreso than the checking which I assume already needs to be done for
>> noexcept to trap errant exceptions?
>
> The noexcept checking only
On 16/08/17 18:38, Joseph Myers wrote:
> On Wed, 16 Aug 2017, Eric Gallager wrote:
>> I see Richi redid all his 7.2 release changes; does that imply that
>> the server restore is now complete?
>
> No, there's still a search process ongoing to identify corrupted or
> missing files by comparison wi
is there a way to get vectorized math functions in fortran?
in c code there is attribute simd declarations or openmp
declare simd pragma to tell the compiler which functions
have simd variant, but i see no such thing in fortran.
some targets have -mveclibabi=type which allows vectorizing
a set of
On 01/11/17 16:26, Jakub Jelinek wrote:
> On Wed, Nov 01, 2017 at 04:23:11PM +0000, Szabolcs Nagy wrote:
>> is there a way to get vectorized math functions in fortran?
>>
>> in c code there is attribute simd declarations or openmp
>> declare simd pragma to tell the compi
On 01/11/17 16:47, Szabolcs Nagy wrote:
> On 01/11/17 16:26, Jakub Jelinek wrote:
>> On Wed, Nov 01, 2017 at 04:23:11PM +, Szabolcs Nagy wrote:
>>> is there a way to get vectorized math functions in fortran?
>>>
>>> in c code there is attribute simd dec
On 31/01/18 15:44, Cory Fields wrote:
After looking at this for quite a while, I'm afraid I'm unsure how to proceed.
As of now, static and static-pie are mutually exclusive. So given the
GNU_USER_TARGET_STARTFILE_SPEC you pasted
earlier, "static" matches before "static-pie", causing the wrong st
On 26/02/18 04:00, Ruslan Nikolaev via gcc wrote:
1. Not consistent with clang/llvm which completely supports double-width
atomics for arm32, arm64, x86 and x86-64 making it possible to write portable
code (w/o specific extensions or assembly code) across all these architectures
(which is fina
On 26/02/18 13:56, Alexander Monakov wrote:
On Mon, 26 Feb 2018, Szabolcs Nagy wrote:
rmw load is only valid if the implementation can
guarantee that atomic objects are never read-only.
OK, but that sounds like a matter of not emitting atomic
objects into .rodata, which shouldn't be
On 27/02/18 12:56, Ruslan Nikolaev wrote:
Formally speaking, either implementation satisfies C11 because the standard
allows much leeway in the interpretation here.
no,
1) your proposal would make gcc non-conforming to iso c unless it changes how
static const objects are emitted.
2) the two
i had a query earlier about libmvec vector functions in fortran:
https://gcc.gnu.org/ml/gcc/2017-11/msg7.html
but there were no simple solutions to make math functions vectorizable
in fortran, because it's hard to make libc headers with simd attributes
visible to the fortran front end.
i thi
On 10/04/18 11:14, Janne Blomqvist wrote:
As I mentioned previously in that thread you linked to, the fortran frontend never generates a direct call to libm sin(), or for that matter
ZGVbN2v_sin(). Instead it generates a "call" to __builtin_sin(). And similarly for other libm functions that have
On 10/04/18 14:27, Richard Biener wrote:
On April 10, 2018 3:06:55 PM GMT+02:00, Jakub Jelinek wrote:
On Tue, Apr 10, 2018 at 02:55:43PM +0200, Richard Biener wrote:
I wonder if it is possible for glibc to ship a "module" for fortran
instead
containing the appropriate declarations and gfortr
On 15/06/18 08:59, Florian Weimer wrote:
* Richard Biener:
'pure' makes it pure but there doesn't seem to be a way to make it const?
Does Fortran support setting the rounding mode?
yes, but vec math is only enabled with -ffast-math (so it can
assume -fno-rounding-math)
In C, sin is not c
On 11/06/18 11:05, Martin Jambor wrote:
The int rate numbers (running 1 copy only) were not too bad, GCC was
only about 2% slower and only 525.x264_r seemed way slower with GCC.
The fp rate numbers (again only 1 copy) showed a larger difference,
around 20%. 521.wrf_r was more than twice as slow
On 12/07/18 16:20, Umesh Kalappa wrote:
Hi everyone,
we have our source base ,that was compiled for armv7 on gcc8.1 with
soft-float and for following input
a=0x0010
b=0x0001
result = a - b ;
we are getting the result as "0x000e" and with
-mhard-float (dis
The 10/01/2020 12:14, Alejandro Colomar via Gcc wrote:
> Here is the rendered intmax_t:
>
> intmax_t
> Include: . Alternatively, .
>
> A signed integer type capable of representing any value of any
> signed integer type supported by the implementation. According
> to
The 11/24/2020 16:23, Siddhesh Poyarekar wrote:
> Hi,
>
> The Intel 80-bit long double format has a concept of "unnormal" numbers that
> have a non-zero exponent and zero integer bit (i.e. bit 63) in the mantissa;
> all valid long double numbers have their integer bit set to 1. Unnormal
> numbers
Last time aarch64 libmvec was discussed, the OpenMP
declare variant syntax support was not ready in gcc
and there were open questions around how simd isa
variants would be supported.
https://gcc.gnu.org/pipermail/gcc-patches/2019-October/532940.html
The vector function ABI for aarch64 allows the
The 07/12/2022 18:25, David Malcolm via Libc-alpha wrote:
> On Tue, 2022-07-12 at 18:16 -0400, David Malcolm wrote:
> > On Tue, 2022-07-12 at 23:03 +0530, Mir Immad wrote:
> > GCC's attribute syntax here:
> > https://gcc.gnu.org/onlinedocs/gcc/Attribute-Syntax.html
> > allows for a parenthesized
The 07/13/2022 12:55, David Malcolm wrote:
> On Wed, 2022-07-13 at 16:01 +0200, Florian Weimer wrote:
> > * David Malcolm:
> GCC trunk's -fanalyzer implements the new warnings via a state machine
> for file-descriptor values; it currently has rules for handling "open",
> "close", "read", and "write
The 11/28/2022 21:37, Stephen Smith via Binutils wrote:
> I am working on a project which is using an A53 core. The core does not
> raise an exception if there is a division by zero (for either integer or
> floating point division).
floating-point division by zero signals the FE_DIVBYZERO exce
The 01/13/2024 13:49, Florian Weimer wrote:
> This commit
>
> commit 8abddb187b33480d8827f44ec655f45734a1749d
> Author: Andrew Burgess
> Date: Sat Aug 5 14:31:06 2023 +0200
>
> libgcc: support heap-based trampolines
>
> Add support for heap-based trampolines on x86_64-linux, aarch
The 04/08/2024 06:19, Matheus Afonso Martins Moreira via Gcc wrote:
> __builtin_linux_system_call(long n, ...)
...
> Calling these builtins will make GCC place all the parameters
> in the correct registers for the system call, emit the appropriate
> instruction for the target architecture and r
The 04/09/2024 23:59, Matheus Afonso Martins Moreira via Gcc wrote:
> > and using raw syscalls outside of the single runtime the
> > application is using is problematic (at least on linux).
>
> Why do you say they are problematic on Linux though? Please elaborate.
because the portable c api layer
73 matches
Mail list logo
