Re: Question about generating vpmovzxbd instruction without using the interfaces in immintrin.h

On Fri, May 31, 2024 at 4:59 AM Hanke Zhang via Gcc wrote: > > Hi, > I've recently been trying to hand-write code to trigger automatic > vectorization optimizations in GCC on Intel x86 machines (without > using the interfaces in immintrin.h), but I'm running into a proble

Re: Question about generating vpmovzxbd instruction without using the interfaces in immintrin.h

On Fri, May 31, 2024 at 10:58 AM Hanke Zhang via Gcc wrote: > > Hi, > I've recently been trying to hand-write code to trigger automatic > vectorization optimizations in GCC on Intel x86 machines (without > using the interfaces in immintrin.h), but I'm running into a pro

Question about generating vpmovzxbd instruction without using the interfaces in immintrin.h

Hi, I've recently been trying to hand-write code to trigger automatic vectorization optimizations in GCC on Intel x86 machines (without using the interfaces in immintrin.h), but I'm running into a problem where I can't seem to get the concise `vpmovzxbd` or similar instructions. My

Re: libgcov, fork, and mingw (and other targets without the full POSIX set)

What about removing the _gcov_fork object file from the list of object files in Makefile.in (Named LIBGCOV_INTERFACE last I remember) if the target doesn't support fork? Seems cleaner in my opinion. best regards, Julian

Re: libgcov, fork, and mingw (and other targets without the full POSIX set)

* LIU Hao via Gcc: > 在 2023/12/8 21:59, Florian Weimer via Gcc 写道: >>[PATCH] libgcov: Call __builtin_fork instead of fork >> >> > > May I ask why it's not something like this? > > Even though there may be p

Re: libgcov, fork, and mingw (and other targets without the full POSIX set)

在 2023/12/8 21:59, Florian Weimer via Gcc 写道: [PATCH] libgcov: Call __builtin_fork instead of fork May I ask why it's not something like this? Even though there may be people who define `fork()` in globa

Re: libgcov, fork, and mingw (and other targets without the full POSIX set)

* Mark Wielaard: > BTW. The gcc-fedora-mingw buildbot has been broken because of this > issue for the last week: > > https://builder.sourceware.org/buildbot/#/builders/gcc-fedora-mingw > ../../../gcc/libgcc/libgcov-interface.c: In function '__gcov_fork': > ../../../gcc/libgcc/libgcov-interface.c:1

Re: libgcov, fork, and mingw (and other targets without the full POSIX set)

I think the most reasonable thing to do is to remove _gcov_fork from LIBGCOV_INTERFACE in libgcc's Makefile.in when the target is Windows. best regards, Julian

Re: libgcov, fork, and mingw (and other targets without the full POSIX set)

Hi, On Fri, 2023-12-01 at 13:09 +0100, Jakub Jelinek via Gcc wrote: > On Fri, Dec 01, 2023 at 01:03:01PM +0100, Jan Hubicka via Gcc wrote: > > > On Dez 01 2023, Richard Biener via Gcc wrote: > > > > > > > Hmm, so why's it then referenced and not "GCed"? > > > > > > This has nothing to do with ga

Re: libgcov, fork, and mingw (and other targets without the full POSIX set)

On Fri, Dec 01, 2023 at 01:03:01PM +0100, Jan Hubicka via Gcc wrote: > > On Dez 01 2023, Richard Biener via Gcc wrote: > > > > > Hmm, so why's it then referenced and not "GCed"? > > > > This has nothing to do with garbage collection. It's just the way > > libgcc avoids having too many source fil

Re: libgcov, fork, and mingw (and other targets without the full POSIX set)

> On Dez 01 2023, Richard Biener via Gcc wrote: > > > Hmm, so why's it then referenced and not "GCed"? > > This has nothing to do with garbage collection. It's just the way > libgcc avoids having too many source files. It would be exactly the > same if every function were in its own file. THe

Re: libgcov, fork, and mingw (and other targets without the full POSIX set)

On Dez 01 2023, Richard Biener via Gcc wrote: > Hmm, so why's it then referenced and not "GCed"? This has nothing to do with garbage collection. It's just the way libgcc avoids having too many source files. It would be exactly the same if every function were in its own file. -- Andreas Schwab

Re: libgcov, fork, and mingw (and other targets without the full POSIX set)

在 2023/12/1 17:09, Richard Biener via Gcc 写道: Hmm, so why's it then referenced and not "GCed"? The classical "solution" is to make the reference weak via sth like extern typeof(fork) fork () __attribute__((weak)); There are issues about weak symbols on mingw targets. Calls to weak functions c

Re: libgcov, fork, and mingw (and other targets without the full POSIX set)

is is wrapped inside > > > > > > #ifdef L_gcov_fork > > > #endif > > > > > > grepping didn't find me what defines this, but it suggests the solution > > > lies there ... > > > > That's just the general libgcc/ coding style, which put

Re: libgcov, fork, and mingw (and other targets without the full POSIX set)

On Fri, 1 Dec 2023, LIU Hao via Gcc wrote: > >> What's the best way to fix this? I expect it's going to impact other > >> targets (perhaps for different functions) because all of > >> libgcov-interface.c is built unconditionally. I don't think we run > >> configure for the target, so we can't

Re: libgcov, fork, and mingw (and other targets without the full POSIX set)

at's just the general libgcc/ coding style, which puts multiple > related functions into one C source file. The file is compiled multiple > times with different -D options using Makefile rules like this one: > > $(libgcov-interface-objects): %$(objext): $(srcdir)/libgcov-interfac

Re: libgcov, fork, and mingw (and other targets without the full POSIX set)

在 2023/12/1 16:19, Eli Zaretskii via Gcc 写道: As far as I understand it, mingw doesn't have fork and doesn't declare it in , so it's not clear to me how this has ever worked. I would expect a linker failure. Maybe that doesn't happen because the object containing a reference to fork is only ever

Re: libgcov, fork, and mingw (and other targets without the full POSIX set)

s this, but it suggests the solution > lies there ... That's just the general libgcc/ coding style, which puts multiple related functions into one C source file. The file is compiled multiple times with different -D options using Makefile rules like this one: $(libgcov-interface

Re: libgcov, fork, and mingw (and other targets without the full POSIX set)

On Fri, Dec 1, 2023 at 9:04 AM Florian Weimer via Gcc wrote: > > I've received a report of a mingw build failure: > > ../../../gcc/libgcc/libgcov-interface.c: In function '__gcov_fork': > ../../../gcc/libgcc/libgcov-interface.c:185:9: error: implicit declaration of > function 'fork' [-Wimplicit-f

Re: libgcov, fork, and mingw (and other targets without the full POSIX set)

> Cc: Jonathan Yong <10wa...@gmail.com>, Jan Hubicka , Nathan > Sidwell > Date: Fri, 01 Dec 2023 09:02:55 +0100 > X-Spam-Status: No, score=-4.6 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, > DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, > RCVD_IN_MSPIKE_H3, RCVD_IN_

libgcov, fork, and mingw (and other targets without the full POSIX set)

I've received a report of a mingw build failure: ../../../gcc/libgcc/libgcov-interface.c: In function '__gcov_fork': ../../../gcc/libgcc/libgcov-interface.c:185:9: error: implicit declaration of function 'fork' [-Wimplicit-function-declaration] 185 | pid = fork (); | ^~~~ make[2

Re: Reporitng libstdc++ bug without account to Bugzilla

On Mon, 20 Nov 2023 at 14:23, Palmu, Miro M wrote: > > Hi > > I think I found libstdc++ bug and I tried to report to Bugzilla but "user > account creation has been restricted". > > So I'm going to report it here in hope that someone with a account could > report it to Bugzilla if they seem it fit

Reporitng libstdc++ bug without account to Bugzilla

Hi I think I found libstdc++ bug and I tried to report to Bugzilla but "user account creation has been restricted". So I'm going to report it here in hope that someone with a account could report it to Bugzilla if they seem it fit. Using gcc 13.2 with -std=c++23 code below (https://godbolt.org

Re: Is it possible to enable data sections and function sections without explicitly giving flags "-fdata-sections" and "-ffunction-sections"?

rt these flags so GCC will generate bigger binaries. Is it possible to enable this feature without  giving any command line flags manually? Just to be clear here - removing unused sections is only beneficial if you have a significant amount of unused code and data compiled in the build. That ca

Re: Is it possible to enable data sections and function sections without explicitly giving flags "-fdata-sections" and "-ffunction-sections"?

27;t support these flags so > GCC will generate bigger binaries. > Is it possible to enable this feature without  giving any command line > flags manually? All (at least decent) build systems support passing extra flags to the compiler and linker (e.g. CXXFLAGS="-ffunction-sections&q

Is it possible to enable data sections and function sections without explicitly giving flags "-fdata-sections" and "-ffunction-sections"?

ries. Is it possible to enable this feature without  giving any command line flags manually?

Re: Difficulty in implementing a GCC plugin for [[invariant]] contract functions in classes/structs without prior experience?

Hey all, I've continued to work on this and have it mostly finished The implementation is here GCC [[invariant]] plugin for Design by Contract (WIP) (github.com) I have posted the final remaining question to StackOverflow in ca

Re: Difficulty in implementing a GCC plugin for [[invariant]] contract functions in classes/structs without prior experience?

So I have prototyped the code here, there are two places where I am confused: GCC [[invariant]] plugin for Design by Contract (WIP) (github.com) 1. Is it proper to cast like this? tree args = NULL_TRE

Re: -minstd: Require a minimum std version, without being specific

On Wed, Dec 21, 2022 at 19:33:48 +0100, Alejandro Colomar via Gcc wrote: > I've long had this wish: an option similar to -std, but which would not > specify > the standard. Rather, mark a requirement that the standard be at least a > version. > > This would be especially useful for libraries,

Re: -minstd: Require a minimum std version, without being specific

Hi Alexander, On 12/21/22 20:12, Alexander Monakov wrote: On Wed, 21 Dec 2022, Alejandro Colomar via Gcc wrote: There's already a standard, portable way to check: #if __STDC_VERSION__ < 201710 #error C17 required #endif Hmm, not my favourite to stick that in every public header file, but y

Re: -minstd: Require a minimum std version, without being specific

On Wed, 21 Dec 2022, 19:08 Alejandro Colomar via Gcc, wrote: > > > On 12/21/22 19:53, Alejandro Colomar wrote: > > Hi Alexander, > > > > On 12/21/22 19:51, Alexander Monakov wrote: > >> > >> > >> On Wed, 21 Dec 2022, Alejandro Colomar via Gcc wrote: > >> > >>> Hi, > >>> > >>> I've long had this w

Re: -minstd: Require a minimum std version, without being specific

On Wed, 21 Dec 2022, Alejandro Colomar via Gcc wrote: > > There's already a standard, portable way to check: > > > > #if __STDC_VERSION__ < 201710 > > #error C17 required > > #endif > > Hmm, not my favourite to stick that in every public header file, but yes, it's > portable. I don't see why

Re: -minstd: Require a minimum std version, without being specific

On 12/21/22 19:53, Alejandro Colomar wrote: Hi Alexander, On 12/21/22 19:51, Alexander Monakov wrote: On Wed, 21 Dec 2022, Alejandro Colomar via Gcc wrote: Hi, I've long had this wish: an option similar to -std, but which would not specify the standard.  Rather, mark a requirement that t

Re: -minstd: Require a minimum std version, without being specific

Hi Alexander, On 12/21/22 19:51, Alexander Monakov wrote: On Wed, 21 Dec 2022, Alejandro Colomar via Gcc wrote: Hi, I've long had this wish: an option similar to -std, but which would not specify the standard. Rather, mark a requirement that the standard be at least a version. This would

Re: -minstd: Require a minimum std version, without being specific

On Wed, 21 Dec 2022, Alejandro Colomar via Gcc wrote: > Hi, > > I've long had this wish: an option similar to -std, but which would not > specify the standard. Rather, mark a requirement that the standard be at > least a version. > > This would be especially useful for libraries, which might

-minstd: Require a minimum std version, without being specific

Hi, I've long had this wish: an option similar to -std, but which would not specify the standard. Rather, mark a requirement that the standard be at least a version. This would be especially useful for libraries, which might for example require C99 or C11 to work. They would be able to spec

Re: what is the difference with and without crc extension support

On 03/03/2022 13:41, Dongjiu Geng via Gcc wrote: Hi, My program does not use CRC instructions，but I find the compiled binary has much difference between using "-march=armv8-a+crc" and using "-march=armv8-a". Even stranger, when I use "-march=armv8-a+crc", I find my compiled binary can not r

Re: what is the difference with and without crc extension support

On 3/3/22 14:52, Dongjiu Geng wrote: Thanks for the answer, my source file is complex，it is not convenient attach, because it is company code. I see. So then you can try -fdump-tree-optimized and compare the corresponding dump file. Or you can use -fdump-tree-all -fdump-rtl-all and do the sam

Re: what is the difference with and without crc extension support

Thanks for the answer, my source file is complex，it is not convenient attach, because it is company code. According to your experience， what is the reason about it? Martin Liška 于2022年3月3日周四 21:48写道： > > On 3/3/22 14:41, Dongjiu Geng via Gcc wrote: > > Hi, > > My program does not use CRC

Re: what is the difference with and without crc extension support

On 3/3/22 14:41, Dongjiu Geng via Gcc wrote: Hi, My program does not use CRC instructions，but I find the compiled binary has much difference between using "-march=armv8-a+crc" and using "-march=armv8-a". Even stranger, when I use "-march=armv8-a+crc", I find my compiled binary can not run.

what is the difference with and without crc extension support

Hi, My program does not use CRC instructions，but I find the compiled binary has much difference between using "-march=armv8-a+crc" and using "-march=armv8-a". Even stranger, when I use "-march=armv8-a+crc", I find my compiled binary can not run. but when I change -O2 to -O0 based on "-march=ar

Re: Suboptimal code generated for __buitlin_trunc on AMD64 without SS4_4.1

On Sat, 7 Aug 2021, Stefan Kanthak wrote: > Joseph Myers wrote: > > You should be looking at TS 18661-3 / C2x Annex F for sNaN handling; > > I'll do so as soon as GCC drops support for all C dialects before C2x! > > Unless you use a time machine and fix the POSIX and ISO C standards > written i

Re: Suboptimal code generated for __buitlin_trunc on AMD64 without SS4_4.1

On 2021-08-07 14:32:32 +0200, Stefan Kanthak wrote: > Joseph Myers wrote: > > On Fri, 6 Aug 2021, Stefan Kanthak wrote: > > PLEASE DON'T STRIP ATTRIBUTION LINES: I did not write the following paragraph! > > >> > I don't know what the standard says about NaNs in this case, I seem to > >> > rememb

Re: Suboptimal code generated for __buitlin_trunc on AMD64 without SS4_4.1

Joseph Myers wrote: > On Fri, 6 Aug 2021, Stefan Kanthak wrote: PLEASE DON'T STRIP ATTRIBUTION LINES: I did not write the following paragraph! >> > I don't know what the standard says about NaNs in this case, I seem to >> > remember that arithmetic instructions typically produce QNaN when one

Re: Suboptimal code generated for __buitlin_trunc on AMD64 without SS4_4.1

On Fri, 6 Aug 2021, Stefan Kanthak wrote: > > I don't know what the standard says about NaNs in this case, I seem to > > remember that arithmetic instructions typically produce QNaN when one of > > the inputs is a NaN, whether signaling or not. > >

Re: Suboptimal code generated for __buitlin_trunc on AMD64 without SS4_4.1

Richard Biener wrote: > On August 6, 2021 4:32:48 PM GMT+02:00, Stefan Kanthak > wrote: >>Michael Matz wrote: >>> Btw, have you made speed measurements with your improvements? >> >>No. [...] >>If the constant happens to be present in L1 cache, it MAY load as fast >>as an immediate. >>BUT: on

Re: Suboptimal code generated for __buitlin_trunc on AMD64 without SS4_4.1

On August 6, 2021 4:32:48 PM GMT+02:00, Stefan Kanthak wrote: >Michael Matz wrote: > > >> Hello, >> >> On Fri, 6 Aug 2021, Stefan Kanthak wrote: >> >>> For -ffast-math, where the sign of -0.0 is not handled and the spurios >>> invalid floating-point exception for |argument| >= 2**63 is accepta

Re: Suboptimal code generated for __buitlin_trunc on AMD64 without SS4_4.1

Hello, On Fri, 6 Aug 2021, Stefan Kanthak wrote: > >> For -ffast-math, where the sign of -0.0 is not handled and the > >> spurios invalid floating-point exception for |argument| >= 2**63 is > >> acceptable, > > > > This claim would need to be proven in the wild. > > I should have left the "wh

Re: Suboptimal code generated for __buitlin_trunc on AMD64 without SS4_4.1

Gabriel Paubert wrote: > On Fri, Aug 06, 2021 at 02:43:34PM +0200, Stefan Kanthak wrote: >> Gabriel Paubert wrote: >> >> > Hi, >> > >> > On Thu, Aug 05, 2021 at 01:58:12PM +0200, Stefan Kanthak wrote: [...] >> >> The whole idea behind these implementations is to get rid of loading >> >> flo

Re: Suboptimal code generated for __buitlin_trunc on AMD64 without SS4_4.1

Michael Matz wrote: > Hello, > > On Fri, 6 Aug 2021, Stefan Kanthak wrote: > >> For -ffast-math, where the sign of -0.0 is not handled and the spurios >> invalid floating-point exception for |argument| >= 2**63 is acceptable, > > This claim would need to be proven in the wild. I should have

Re: Suboptimal code generated for __buitlin_trunc on AMD64 without SS4_4.1

Hello, On Fri, 6 Aug 2021, Stefan Kanthak wrote: > For -ffast-math, where the sign of -0.0 is not handled and the spurios > invalid floating-point exception for |argument| >= 2**63 is acceptable, This claim would need to be proven in the wild. |argument| > 2**52 are already integer, and should

Re: Suboptimal code generated for __buitlin_trunc on AMD64 without SS4_4.1

On Fri, Aug 06, 2021 at 02:43:34PM +0200, Stefan Kanthak wrote: > Gabriel Paubert wrote: > > > Hi, > > > > On Thu, Aug 05, 2021 at 01:58:12PM +0200, Stefan Kanthak wrote: > >> Gabriel Paubert wrote: > >> > >> > >> > On Thu, Aug 05, 2021 at 09:25:02AM +0200, Stefan Kanthak wrote: > > >> >>

Re: Suboptimal code generated for __buitlin_trunc on AMD64 without SS4_4.1

On Fri, Aug 6, 2021 at 2:47 PM Stefan Kanthak wrote: > > Gabriel Paubert wrote: > > > Hi, > > > > On Thu, Aug 05, 2021 at 01:58:12PM +0200, Stefan Kanthak wrote: > >> Gabriel Paubert wrote: > >> > >> > >> > On Thu, Aug 05, 2021 at 09:25:02AM +0200, Stefan Kanthak wrote: > > >> >>

Re: Suboptimal code generated for __buitlin_trunc on AMD64 without SS4_4.1

Gabriel Paubert wrote: > Hi, > > On Thu, Aug 05, 2021 at 01:58:12PM +0200, Stefan Kanthak wrote: >> Gabriel Paubert wrote: >> >> >> > On Thu, Aug 05, 2021 at 09:25:02AM +0200, Stefan Kanthak wrote: >> >> .intel_syntax >> >> .text >>

Re: Suboptimal code generated for __buitlin_trunc on AMD64 without SS4_4.1

gt; 00 00 00 00 > >> .align 16 > >> 10: ff ff ff ff .LC1: .quad ~(-0.0) > >> ff ff ff 7f > >> 18: 00 00 00 00 .quad 0.0 > >> 00 00 00 00 > >>

Re: Suboptimal code generated for __buitlin_trunc on AMD64 without SS4_4.1

00 00 .quad 0.0 00 00 00 00 .end JFTR: in the best case, the memory accesses cost several cycles, while in the worst case they yield a page fault! Properly optimized, shorter and faster code, using but only 9 instructions in just 33 bytes, WITHO

Re: Suboptimal code generated for __buitlin_trunc on AMD64 without SS4_4.1

>> .end >> >> JFTR: in the best case, the memory accesses cost several cycles, >> while in the worst case they yield a page fault! >> >> >> Properly optimized, shorter and faster code, using but only 9 i

Re: Suboptimal code generated for __buitlin_trunc on AMD64 without SS4_4.1

0 00 00 00 .quad 0.0 > > 00 00 00 00 > > .end > > > > JFTR: in the best case, the memory accesses cost several cycles, > > while in the worst case they yield a page fault! > > > > > > Pro

Re: Suboptimal code generated for __buitlin_trunc on AMD64 without SS4_4.1

ff ff .LC1: .quad ~(-0.0) > ff ff ff 7f > 18: 00 00 00 00 .quad 0.0 > 00 00 00 00 > .end > > JFTR: in the best case, the memory accesses cost several cycles, > while in the worst case they yield a pa

Suboptimal code generated for __buitlin_floor on AMD64 without SS4_4.1

imized, shorter and faster code, using only 15 instructions in just 65 bytes, WITHOUT superfluous constants, thus avoiding costly memory accesses and saving at least 16 + 48 bytes, follows: .intel_syntax .equBIAS

Re: Suboptimal code generated for __buitlin_ceil on AMD64 without SS4_4.1

1.0p0 > 00 00 f0 3f > 00 00 00 00 > 00 00 00 00 > .end > > JFTR: in the best case, the memory accesses cost several cycles, > while in the worst case they yield a page fault! > > > Properly optimized, fas

Suboptimal code generated for __buitlin_trunc on AMD64 without SS4_4.1

cycles, while in the worst case they yield a page fault! Properly optimized, shorter and faster code, using but only 9 instructions in just 33 bytes, WITHOUT any constants, thus avoiding costly memory accesses and saving at least 16 + 32 bytes, follows: .intel_

Suboptimal code generated for __buitlin_ceil on AMD64 without SS4_4.1

00 00 00 00 .end JFTR: in the best case, the memory accesses cost several cycles, while in the worst case they yield a page fault! Properly optimized, faster and shorter code, using just 15 instructions in 65 bytes, WITHOUT superfluous constants, thus av

Suboptimal code generated for __buitlin_rint on AMD64 without SS4_4.1

optimized, faster and shorter code, using just 9 instructions in only 33 bytes, WITHOUT superfluous constants, thus avoiding costly memory accesses and saving at least 16 + 32 bytes, follows: .intel_syntax .text 0: f2 48 0f 2c c0

Re: Gcov info registration without constructor?

On 10/11/2020 17:23, Sebastian Huber wrote: I am not sure how I can make the new section read-only. Currently, it is writable:     .section    .gcov_info,"aw"     .align 2     .type   .LPBX2, @object     .size   .LPBX2, 4 .LPBX2:     .long   .LPBX0 I changed the sect

Re: Gcov info registration without constructor?

Hello Martin, attached is a proof of concept. I am not sure how I can make the new section read-only. Currently, it is writable:     .section    .gcov_info,"aw"     .align 2     .type   .LPBX2, @object     .size   .LPBX2, 4 .LPBX2:     .long   .LPBX0 I probably need al

Re: Gcov info registration without constructor?

Hallo Martin, On 10/11/2020 13:05, Martin Liška wrote: On 11/9/20 6:45 PM, Sebastian Huber wrote: Hello, Hello. There was a similar need some time ago: https://gcc.gnu.org/legacy-ml/gcc/2019-11/msg9.html Please take a look for a possible inspiration. thanks for the pointer. I would

Re: Gcov info registration without constructor?

On 11/9/20 6:45 PM, Sebastian Huber wrote: Hello, Hello. There was a similar need some time ago: https://gcc.gnu.org/legacy-ml/gcc/2019-11/msg9.html Please take a look for a possible inspiration. I would like to use the -ftest-coverage -fprofile-arcs support on a bare metal system (no

Gcov info registration without constructor?

Hello, I would like to use the -ftest-coverage -fprofile-arcs support on a bare metal system (no operating system or very early stages in the system startup). In this environment I cannot use the gcov info registration via a constructor and __gcov_init(), because there may be some other (more

Without

aHenrymandigmaagmail.com

Re: How to pack small type to big type without memory load/store ?

On Tue, Aug 4, 2020 at 5:10 AM Jojo R wrote: > > Hi, > > Form My ABI, float register is used by function call, > I want to pack float a and b into double v without any memory load/store, > > The flowing is my demo: > > Typedef union { > float ff[2]; &g

How to pack small type to big type without memory load/store ?

Hi, Form My ABI, float register is used by function call, I want to pack float a and b into double v without any memory load/store, The flowing is my demo: Typedef union { float ff[2]; double v; } double_u; Double pack_float (float a, float b) { double_u tmp

Re: Accessing result data of target options without Mask or Var properties

On Sat, 11 Jul 2020, The Other via Gcc wrote: > Hi, > How would I access the result data of target options that don't have Mask > or Var properties? For example, how would I access the result ISA string in > the -march option for the RISC-V target? If an option doesn't specify somewhere to store

Accessing result data of target options without Mask or Var properties

Hi, How would I access the result data of target options that don't have Mask or Var properties? For example, how would I access the result ISA string in the -march option for the RISC-V target? Here is the relevant option code inside the .opt file: march= Target Report RejectNegative Joined -marc

Re: libsanitizer in GCC 10 is dropping symbols without bumping the soversions

On 11/29/19 12:47 PM, Jakub Jelinek wrote: __ubsan_handle_function_type_mismatch* is something we don't use (Martin, should we add such sanitizer? We have gimple_call_fntype vs. actual decl types, but it would need some inspection on what the sanitizer really does), but still e.g. clang compiled

Re: libsanitizer in GCC 10 is dropping symbols without bumping the soversions

On Fri, Nov 29, 2019 at 12:28:51PM +0100, Matthias Klose wrote: > libsanitizer on trunk only bumps the soversion for asan, but the other > libraries > drop some symbols without bumping the soname, Are these changes intended, and > should the soversions be bumped? libsanitizer libs h

Re: libsanitizer in GCC 10 is dropping symbols without bumping the soversions

On 11/29/19 12:28 PM, Matthias Klose wrote: libsanitizer on trunk only bumps the soversion for asan, but the other libraries drop some symbols without bumping the soname, Are these changes intended, and should the soversions be bumped? Hello. Yes, it's intended. We should bump the li

libsanitizer in GCC 10 is dropping symbols without bumping the soversions

libsanitizer on trunk only bumps the soversion for asan, but the other libraries drop some symbols without bumping the soname, Are these changes intended, and should the soversions be bumped? Matthias diff --git a/debian/liblsan0.symbols b/debian/liblsan0.symbols index f318d9a..5aa23a6 100644

Re: Building libssp on a system without gets()

On Sun, 5 Aug 2018, Florian Weimer wrote: >> some folks in FreeBSD-land have worked to remove all uses of gets() >> and in fact the gets() function itself. >> >> Generally GCC builds just fine in such an environment, except for >> libssp where libssp/gets-chk.c has the following: >> >>char * >

Re: GCC turns &~ into | due to undefined bit-shift without warning

proof - such as by tracing > >> execution from main(). But to generate a warning activated > >> specifically by the user, there is no such requirement. It's fine > >> to give a warning based on the code written, rather than on code > >> that the compiler knows without d

Re: GCC turns &~ into | due to undefined bit-shift without warning

On Fri, 22 Mar 2019, Andrew Pinski wrote: > "The practice of reading from a different union member than the one > most recently written to (called “type-punning”) is common. Even with > -fstrict-aliasing, type-punning is allowed, provided the memory is > accessed through the union type." > Maybe i

Re: GCC turns &~ into | due to undefined bit-shift without warning

On Fri, Mar 22, 2019 at 3:08 PM Andrew Pinski wrote: > > On Fri, Mar 22, 2019 at 7:35 AM Allan Sandfeld Jensen > wrote: > > > > On Freitag, 22. März 2019 14:38:10 CET Andrew Haley wrote: > > > On 3/22/19 10:20 AM, Allan Sandfeld Jensen wrote: > > > > On Freitag, 22. März 2019 11:02:39 CET Andrew

Re: GCC turns &~ into | due to undefined bit-shift without warning

On Fri, Mar 22, 2019 at 7:35 AM Allan Sandfeld Jensen wrote: > > On Freitag, 22. März 2019 14:38:10 CET Andrew Haley wrote: > > On 3/22/19 10:20 AM, Allan Sandfeld Jensen wrote: > > > On Freitag, 22. März 2019 11:02:39 CET Andrew Haley wrote: > > >> On 3/21/19 10:19 PM, Allan Sandfeld Jensen wrote

Re: GCC turns &~ into | due to undefined bit-shift without warning

On Freitag, 22. März 2019 14:38:10 CET Andrew Haley wrote: > On 3/22/19 10:20 AM, Allan Sandfeld Jensen wrote: > > On Freitag, 22. März 2019 11:02:39 CET Andrew Haley wrote: > >> On 3/21/19 10:19 PM, Allan Sandfeld Jensen wrote: > >>> From having fixed UBSAN warnings, I have seen many cases where u

Re: GCC turns &~ into | due to undefined bit-shift without warning

On 3/22/19 10:20 AM, Allan Sandfeld Jensen wrote: > On Freitag, 22. März 2019 11:02:39 CET Andrew Haley wrote: >> On 3/21/19 10:19 PM, Allan Sandfeld Jensen wrote: >>> From having fixed UBSAN warnings, I have seen many cases where undefined >>> behavior was performed, but where the code was aware o

Re: GCC turns &~ into | due to undefined bit-shift without warning

nges from ignoring the situation completely with unpredictable results, to behaving during translation or program execution in a documented manner characteristic of the environment (with or without the issuance of a diagnostic message), to terminating a translation or execution (with the issuance of a

Re: GCC turns &~ into | due to undefined bit-shift without warning

On 22/03/2019 11:20, Allan Sandfeld Jensen wrote: > On Freitag, 22. März 2019 11:02:39 CET Andrew Haley wrote: >> On 3/21/19 10:19 PM, Allan Sandfeld Jensen wrote: >>> From having fixed UBSAN warnings, I have seen many cases where undefined >>> behavior was performed, but where the code was aware o

Re: GCC turns &~ into | due to undefined bit-shift without warning

On Freitag, 22. März 2019 11:02:39 CET Andrew Haley wrote: > On 3/21/19 10:19 PM, Allan Sandfeld Jensen wrote: > > From having fixed UBSAN warnings, I have seen many cases where undefined > > behavior was performed, but where the code was aware of it and the final > > result of the expression was w

Re: GCC turns &~ into | due to undefined bit-shift without warning

On 3/21/19 10:19 PM, Allan Sandfeld Jensen wrote: > From having fixed UBSAN warnings, I have seen many cases where undefined > behavior was performed, but where the code was aware of it and the final > result of the expression was well defined nonetheless. Is this belief about undefined behaviou

Re: GCC turns &~ into | due to undefined bit-shift without warning

On Fri, Mar 22, 2019 at 10:27:38AM +0100, Allan Sandfeld Jensen wrote: > But getting back to the question, well GCC carry such information further, > and > thus break code that is otherwise correct behaving on all known > architectures, > just because the C standard hasn't decided on one of two

Re: GCC turns &~ into | due to undefined bit-shift without warning

On Donnerstag, 21. März 2019 23:31:48 CET Jakub Jelinek wrote: > On Thu, Mar 21, 2019 at 11:19:54PM +0100, Allan Sandfeld Jensen wrote: > > Hmm, I am curious. How strongly would gcc assume x is 0? > > If x is not 0, then it is undefined behavior and anything can happen, > so yes, it can assume x i

Re: GCC turns &~ into | due to undefined bit-shift without warning

On Thu, Mar 21, 2019 at 11:19:54PM +0100, Allan Sandfeld Jensen wrote: > Hmm, I am curious. How strongly would gcc assume x is 0? If x is not 0, then it is undefined behavior and anything can happen, so yes, it can assume x is 0, sometimes gcc does that, sometimes not, it is not required to do tha

Re: GCC turns &~ into | due to undefined bit-shift without warning

On Montag, 11. März 2019 10:14:49 CET Jakub Jelinek wrote: > On Mon, Mar 11, 2019 at 08:49:30AM +, Moritz Strübe wrote: > > Considering that C11 6.5.7#3 ("If the value of the right operand > > is negative or is greater than or equal to the width of the promoted > > left operand, the be

Re: GCC turns &~ into | due to undefined bit-shift without warning

On 3/21/19 8:53 AM, Moritz Strübe wrote: > Hey. > > Am 20.03.2019 um 18:36 schrieb Andrew Haley: >> On 3/20/19 2:08 PM, Moritz Strübe wrote: >>> Ok, I played around a bit. Interestingly, if I set >>> -fsanitize=udefined and -fsanitize-undefined-trap-on-error the >>> compiler detects that it will a

Re: GCC turns &~ into | due to undefined bit-shift without warning

Hey. Am 20.03.2019 um 18:36 schrieb Andrew Haley: > On 3/20/19 2:08 PM, Moritz Strübe wrote: >> Ok, I played around a bit. Interestingly, if I set >> -fsanitize=udefined and -fsanitize-undefined-trap-on-error the >> compiler detects that it will always trap, and optimizes the code >> accordingly (

Re: GCC turns &~ into | due to undefined bit-shift without warning

On Thu, Mar 21, 2019 at 9:25 AM Alexander Monakov wrote: > > On Thu, 21 Mar 2019, Richard Biener wrote: > > > Maybe an example would help. > > > > > > Consider this code: > > > > > > for (int i = start; i < limit; i++) { > > > foo(i * 5); > > > } > > > > > > Should GCC be entitled to turn it int

Re: GCC turns &~ into | due to undefined bit-shift without warning

On Thu, 21 Mar 2019, Richard Biener wrote: > > Maybe an example would help. > > > > Consider this code: > > > > for (int i = start; i < limit; i++) { > > foo(i * 5); > > } > > > > Should GCC be entitled to turn it into > > > > int limit_tmp = i * 5; > > for (int i = start * 5; i < limit_tmp; i +=

Re: GCC turns &~ into | due to undefined bit-shift without warning

On Wed, Mar 20, 2019 at 6:36 PM Andrew Haley wrote: > > On 3/20/19 2:08 PM, Moritz Strübe wrote: > > > > Ok, I played around a bit. Interestingly, if I set > > -fsanitize=udefined and -fsanitize-undefined-trap-on-error the > > compiler detects that it will always trap, and optimizes the code > > a

Re: GCC turns &~ into | due to undefined bit-shift without warning

On 3/20/19 2:08 PM, Moritz Strübe wrote: > > Ok, I played around a bit. Interestingly, if I set > -fsanitize=udefined and -fsanitize-undefined-trap-on-error the > compiler detects that it will always trap, and optimizes the code > accordingly (the code after the trap is removed).* Which kind of >

Re: GCC turns &~ into | due to undefined bit-shift without warning

On Wed, Mar 20, 2019 at 02:08:09PM +, Moritz Strübe wrote: > Ok, I played around a bit. Interestingly, if I set -fsanitize=udefined and > -fsanitize-undefined-trap-on-error the compiler detects that it will always > trap, and optimizes the code accordingly (the code after the trap is > remov

  1   2   3   4   >