Re: -Wfloat-equal and comparison to zero

Hello, On Tue, 12 Nov 2024, Thomas Koenig via Gcc wrote: > Am 12.11.24 um 17:25 schrieb Michael Matz via Gcc: > > > If you think of float as > > approximated reals, then yes, division by zero is undefined (not > > somewhat undefined!). > > Depends on how you look

Re: -Wfloat-equal and comparison to zero

Hello, On Tue, 12 Nov 2024, Sad Clouds via Gcc wrote: > > I don't think this has anything to do with whether one operand of the > > comparison is a constant. It's still the case when comparing with 0.0 > > that it's OK if your algorithm is designed such that the other operand > > is exact, an

Re: How to avoid some built-in expansions in gcc?

Hey, On Wed, 5 Jun 2024, David Brown wrote: > The ideal here would be to have some way to tell gcc that a given > function has the semantics of a different function. For example, a > programmer might have several implementations of "memcpy" that are > optimised for different purposes based on

Re: How to avoid some built-in expansions in gcc?

Hello, On Tue, 4 Jun 2024, Jakub Jelinek wrote: > On Tue, Jun 04, 2024 at 07:43:40PM +0200, Michael Matz via Gcc wrote: > > (Well, and without reverse-recognition of isfinite-like idioms in the > > sources. That's orthogonal as well.) > > Why? If isfinite is bet

Re: How to avoid some built-in expansions in gcc?

Hello, On Sat, 1 Jun 2024, Richard Biener via Gcc wrote: > >>> You have a pointer how to define a target optab? I looked into optabs > >>> code but found no appropriate hook. For isinf is seems is is > >>> enough to provide a failing expander, but other functions like isnan > >>> don't have a

Re: Sourceware mitigating and preventing the next xz-backdoor

Hello, On Wed, 3 Apr 2024, Jonathon Anderson wrote: > Of course, this doesn't make the build system any less complex, but > projects using newer build systems seem easier to secure and audit than > those using overly flexible build systems like Autotools and maybe even > CMake. IMHO using a la

Re: Sourceware mitigating and preventing the next xz-backdoor

Hello, On Wed, 3 Apr 2024, Martin Uecker wrote: > The backdoor was hidden in a complicated autoconf script... Which itself had multiple layers and could just as well have been a complicated cmake function. > > (And, FWIW, testing for features isn't "complex". And have you looked at > > other

Re: Sourceware mitigating and preventing the next xz-backdoor

Hello, On Wed, 3 Apr 2024, Martin Uecker via Gcc wrote: > > > Seems reasonable, but note that it wouldn't make any difference to > > > this attack. The liblzma library was modified to corrupt the sshd > > > binary, when sshd was linked against liblzma. The actual attack > > > occurred via a con

Re: Improvement of CLOBBER descriptions

Hello, On Wed, 21 Feb 2024, Daniil Frolov wrote: > >> Following the recent introduction of more detailed CLOBBER types in GCC, a > >> minor > >> inconsistency has been identified in the description of > >> CLOBBER_OBJECT_BEGIN: > >> > >> /* Beginning of object lifetime, e.g. C++ constructor.

Re: Calling convention for Intel APX extension

Hello, On Sun, 30 Jul 2023, Thomas Koenig wrote: > > I've recently submitted a patch that adds some attributes that basically > > say "these-and-those regs aren't clobbered by this function" (I did them > > for not clobbered xmm8-15). Something similar could be used for the new > > GPRs as well.

Re: Calling convention for Intel APX extension

Hey, On Thu, 27 Jul 2023, Thomas Koenig via Gcc wrote: > Intel recommends to have the new registers as caller-saved for > compatibility with current calling conventions. If I understand this > correctly, this is required for exception unwinding, but not if the > function called is __attribute__(

Re: [PATCH] Basic asm blocks should always be volatile

Hello, On Thu, 29 Jun 2023, Julian Waters via Gcc wrote: > int main() { > asm ("nop" "\n" > "\t" "nop" "\n" > "\t" "nop"); > > asm volatile ("nop" "\n" > "\t" "nop" "\n" > "\t" "nop"); > } > > objdump --disassemble-all -M intel -M in

Re: types in GIMPLE IR

Hello, On Thu, 29 Jun 2023, Krister Walfridsson wrote: > > The thing with signed bools is that the two relevant values are -1 (true) > > and 0 (false), those are used for vector bool components where we also > > need them to be of wider type (32bits in this case). > > My main confusion comes fro

Re: types in GIMPLE IR

Hello, On Wed, 28 Jun 2023, Krister Walfridsson via Gcc wrote: > Type safety > --- > Some transformations treat 1-bit types as a synonym of _Bool and mix the types > in expressions, such as: > >_2; > _Bool _3; > _Bool _4; > ... > _4 = _2 ^ _3; > > and similarly mixing _Bool

Re: [PATCH] Basic asm blocks should always be volatile

Hello, On Wed, 28 Jun 2023, Julian Waters via Gcc wrote: > On the contrary, code compiled with gcc with or without the applied patch > operates very differently, with only gcc with the applied patch producing a > fully correctly operating program as expected. Even if the above inline > assembly b

Re: [gimple-ssa] Get the gimple corresponding to the definition of a VAR_DECL

Hello, On Tue, 27 Jun 2023, Pierrick Philippe wrote: > My main problem is regarding uninitialized definition, but still not being > considered undefined behavior. > For example, the following code: > >int x; >int *y = &x; >*y = 6; > > What I'm doing is basically looking at each gimp

Re: Different ASM for ReLU function between GCC11 and GCC12

Hello, On Tue, 20 Jun 2023, Jakub Jelinek via Gcc wrote: > ce1 pass results in emit_conditional_move with > (gt (reg/v:SF 83 [ x ]) (reg:SF 84)), (reg/v:SF 83 [ x ]), (reg:SF 84) > operands in the GCC 11 case and so is successfully matched by > ix86_expand_fp_movcc as ix86_expand_sse_fp_minmax. >

Re: gcc tricore porting

rs to https://kristerw.blogspot.com/2017/08/writing-gcc-backend_4.html which is something not too old. For concrete questions this mailing list is a good place to ask. Good luck, Michael. > > Ciao > Claudio > > Il giorno lun 19 giu 2023 alle ore 16:16 Michael Matz ha &g

Re: gcc tricore porting

Hello, On Mon, 19 Jun 2023, Richard Biener via Gcc wrote: > On Sun, Jun 18, 2023 at 12:00 PM Claudio Eterno via Gcc > wrote: > > > > Hi, this is my first time with open source development. I worked in > > automotive for 22 years and we (generally) were using tricore series for > > these product

Re: Passing the complex args in the GPR's

Hey, On Tue, 6 Jun 2023, Umesh Kalappa via Gcc wrote: > Question is : Why does GCC choose to use GPR's here and have any > reference to support this decision ? You explicitely used -m32 ppc, so https://www.polyomino.org.uk/publications/2011/Power-Arch-32-bit-ABI-supp-1.0-Unified.pdf applies.

Re: More C type errors by default for GCC 14

Hello, On Fri, 12 May 2023, Florian Weimer wrote: > * Alexander Monakov: > > > This is not valid (constraint violation): > > > > unsigned x; > > > > int *p = &x; > > > > In GCC this is diagnosed under -Wpointer-sign: > > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25892 > > Thanks fo

Re: More C type errors by default for GCC 14

Hello, On Fri, 12 May 2023, Jakub Jelinek via Gcc wrote: > On Fri, May 12, 2023 at 11:33:01AM +0200, Martin Jambor wrote: > > > One fairly big GCC-internal task is to clear up the C test suite so that > > > it passes with the new compiler defaults. I already have an offer of > > > help for that,

Re: MIN/MAX and trapping math and NANs

Hello, On Tue, 11 Apr 2023, Richard Biener via Gcc wrote: > In the case we ever implement conforming FP exception support > either targets would need to be fixed to mask unexpected exceptions > or we have to refrain from moving instructions where the target > implementation may rise exceptions ac

Re: [RFC PATCH] driver: unfilter default library path [PR 104707]

Hello, On Thu, 6 Apr 2023, Shiqi Zhang wrote: > Currently, gcc delibrately filters out default library paths "/lib/" and > "/usr/lib/", causing some linkers like mold fails to find libraries. If linkers claim to be a compatible replacement for other linkers then they certainly should behave in

Re: [Tree-SSA] Question from observation, bogus SSA form?

Hello, On Fri, 17 Mar 2023, Pierrick Philippe wrote: > > This means that global variables, volatile variables, aggregates, > > variables which are not considered aggregates but are nevertheless > > partially modified (think insertion into a vector) or variables which > > need to live in memory (m

Re: access to include path in front end

Hey, On Fri, 2 Dec 2022, James K. Lowden wrote: > > > 3. Correct the entries in the default_compilers array. Currently I > > > have in cobol/lang-specs.h: > > > > > > {".cob", "@cobol", 0, 0, 0}, > > > {".COB", "@cobol", 0, 0, 0}, > > > {".cbl", "@cobol", 0, 0, 0}, > > > {".CBL

Re: access to include path in front end

Hey, On Thu, 1 Dec 2022, James K. Lowden wrote: > > E.g. look in gcc.cc for '@c' (matching the file extension) how that > > entry uses '%(cpp_unique_options)', and how cpp_unique_options is > > defined for the specs language: > > > > INIT_STATIC_SPEC ("cpp_unique_options", &cpp_unique_op

Re: access to include path in front end

Hello, On Tue, 29 Nov 2022, James K. Lowden wrote: > I don't understand how to access in a front end the arguments to the -I > option on the command line. > > Cobol has a feature similar to the C preprecessor, known as the > Compiler Directing Facility (CDF). The CDF has a COPY statement that

Re: [PATCH] Various pages: SYNOPSIS: Use VLA syntax in function parameters

Hey, On Tue, 29 Nov 2022, Uecker, Martin wrote: > It does not require any changes on how arrays are represented. > > As part of VM-types the size becomes part of the type and this > can be used for static or dynamic analysis, e.g. you can  > - today - get a run-time bounds violation with the san

Re: [PATCH] Various pages: SYNOPSIS: Use VLA syntax in function parameters

Hey, On Tue, 29 Nov 2022, Alex Colomar via Gcc wrote: > How about the compiler parsing the parameter list twice? This _is_ unbounded look-ahead. You could avoid this by using "." for your new syntax. Use something unambiguous that can't be confused with other syntactic elements, e.g. with a

Re: How can Autoconf help with the transition to stricter compilation defaults?

Hello, On Wed, 16 Nov 2022, Paul Eggert wrote: > On 2022-11-16 06:26, Michael Matz wrote: > > char foobar(void); > > int main(void) { > >return &foobar != 0; > > } > > That still has undefined behavior according to draft C23, This is correct (and also h

Re: How can Autoconf help with the transition to stricter compilation defaults?

Hello, On Wed, 16 Nov 2022, Jonathan Wakely wrote: > > > Unrelated but I was a bit tempted to ask for throwing in > > > -Wbuiltin-declaration-mismatch to default -Werror while Clang 16 was at > > > it, but I suppose we don't want the world to burn too much, > > > > :-) It's IMHO a bug in the sta

Re: How can Autoconf help with the transition to stricter compilation defaults?

Hello, On Wed, 16 Nov 2022, Sam James wrote: > Unrelated but I was a bit tempted to ask for throwing in > -Wbuiltin-declaration-mismatch to default -Werror while Clang 16 was at > it, but I suppose we don't want the world to burn too much, :-) It's IMHO a bug in the standard that it misses "i

Re: How can Autoconf help with the transition to stricter compilation defaults?

Hey, On Wed, 16 Nov 2022, Alexander Monakov wrote: > > The idea is so obvious that I'm probably missing something, why autoconf > > can't use that idiom instead. But perhaps the (historic?) reasons why it > > couldn't be used are gone now? > > Ironically, modern GCC and LLVM optimize '&foobar

Re: How can Autoconf help with the transition to stricter compilation defaults?

Hi, On Tue, 15 Nov 2022, Paul Eggert wrote: > On 2022-11-15 11:27, Jonathan Wakely wrote: > > Another perspective is that autoconf shouldn't get in the way of > > making the C and C++ toolchain more secure by default. > > Can you cite any examples of a real-world security flaw what would be > f

Re: Local type inference with auto is in C2X

Hello, On Thu, 3 Nov 2022, Florian Weimer via Gcc wrote: > will not have propagated widely once GCC 13 releases, so rejecting > implicit ints in GCC 13 might be too early. GCC 14 might want to switch > to C23/C24 mode by default, activating auto support, if the standard > comes out in 2023 (whic

Re: Counting static __cxa_atexit calls

Hello, On Wed, 24 Aug 2022, Florian Weimer wrote: > > On Wed, 24 Aug 2022, Florian Weimer wrote: > > > >> > Isn't this merely moving the failure point from exception-at-ctor to > >> > dlopen-fails? > >> > >> Yes, and that is a soft error that can be handled (likewise for > >> pthread_create). >

Re: Counting static __cxa_atexit calls

Hello, On Wed, 24 Aug 2022, Florian Weimer wrote: > > Isn't this merely moving the failure point from exception-at-ctor to > > dlopen-fails? > > Yes, and that is a soft error that can be handled (likewise for > pthread_create). Makes sense. Though that actually hints at a design problem with

Re: Counting static __cxa_atexit calls

Hello, On Tue, 23 Aug 2022, Florian Weimer via Gcc wrote: > We currently have a latent bug in glibc where C++ constructor calls can > fail if they have static or thread storage duration and a non-trivial > destructor. The reason is that __cxa_atexit (and > __cxa_thread_atexit_impl) may have to a

Re: DWARF question about size of a variable

Hello, On Wed, 8 Jun 2022, Carl Love via Gcc wrote: > Is there dwarf information that gives the size of a variable? Yes, it's in the type description. For array types the siblings of it give the index types and ranges. If that range is computed at runtime DWARF will (try to) express it as an

Re: reordering of trapping operations and volatile

Hello, On Sat, 15 Jan 2022, Martin Uecker wrote: > > Because it interferes with existing optimisations. An explicit > > checkpoint has a clear meaning. Using every volatile access that way > > will hurt performance of code that doesn't require that behaviour for > > correctness. > > This is w

Re: git hooks: too strict check

Hello, On Fri, 14 Jan 2022, Martin Liška wrote: > Hello. > > I'm working on a testsuite clean-up where some of the files are wrongly named. > More precisely, so files have .cc extension and should use .C. However there's > existing C test-case and it leads to: > > marxin@marxinbox:~/Programming

Re: reordering of trapping operations and volatile

Hello, On Thu, 13 Jan 2022, Martin Uecker wrote: > > > > Handling all volatile accesses in the very same way would be > > > > possible but quite some work I don't see much value in. > > > > > > I see some value. > > > > > > But an alternative could be to remove volatile > > > from the observ

Re: reordering of trapping operations and volatile

Hello, On Tue, 11 Jan 2022, Martin Uecker via Gcc wrote: > > Handling all volatile accesses in the > > very same way would be possible but quite some work I don't > > see much value in. > > I see some value. > > But an alternative could be to remove volatile > from the observable behavior in

Re: environment register / ABI

Hello, On Wed, 13 Oct 2021, Martin Uecker wrote: > > [... static chain ...] > > If you mean that, then it's indeed psABI specific, and possibly not > > al ABIs specify it (in which case GCC will probably have set a de- > > facto standard at least for unixy systems).  The x86-64 psABI for > > inst

Re: environment register / ABI

Hello, On Wed, 13 Oct 2021, Martin Uecker wrote: > does anybody know if all architectures support passing > an environment pointer in their function call ABI? Define "environment pointer". I can imagine two things you could mean: the custom to pass envp as third argument to main() in hosted C

Re: S390 should change the meaning of -m31

Hello, On Wed, 29 Sep 2021, Jesus Antonio via Gcc wrote: > m31 is semantically the same as the m32 option. > > > The m31 option allows for 32 bit addressing and that is confusing since > the m31 option in S390 would mean 2 GiB space addressing Indeed that's exactly what it means, and what it'

Re: More aggressive threading causing loop-interchange-9.c regression

Hello, On Thu, 9 Sep 2021, Aldy Hernandez wrote: > > Here there's no simple latch block to start with (the backedge comes > > directly out of the loop exit block). So my suggested improvement > > (testing if the latch was empty and only then reject the thread), would > > solve this. > > Well, t

Re: More aggressive threading causing loop-interchange-9.c regression

Hello, On Thu, 9 Sep 2021, Aldy Hernandez wrote: > The ldist-22 regression is interesting though: > > void foo () > { > int i; > >: > goto ; [INV] > >: > a[i_1] = 0; > if (i_1 > 100) > goto ; [INV] > else > goto ; [INV] > >: > b[i_1] = i_1; > >: > i_8 =

Re: More aggressive threading causing loop-interchange-9.c regression

Hello, On Thu, 9 Sep 2021, Richard Biener wrote: > > I believe something like below would be appropriate, it disables > > threading if the path contains a latch at the non-last position (due > > to being backwards on the non-first position in the array). I.e. it > > disables rotating the loop

Re: More aggressive threading causing loop-interchange-9.c regression

Hello, [lame answer to self] On Wed, 8 Sep 2021, Michael Matz wrote: > > > The forward threader guards against this by simply disallowing > > > threadings that involve different loops. As I see > > > > The thread in question (5->9->3) is all within the sa

Re: More aggressive threading causing loop-interchange-9.c regression

Hello, On Wed, 8 Sep 2021, Aldy Hernandez wrote: > > The forward threader guards against this by simply disallowing > > threadings that involve different loops. As I see > > The thread in question (5->9->3) is all within the same outer loop, > though. BTW, the backward threader also disallows

Re: More aggressive threading causing loop-interchange-9.c regression

Hello, On Tue, 7 Sep 2021, Aldy Hernandez via Gcc wrote: > The regression comes from the simple_reduc_1() function in > tree-ssa/loop-interchange-9.c, and it involves the following path: > > === BB 5 > Imports: n_10(D) j_19 > Exports: n_10(D) j_13 j_19 > j_13 : j

Re: post-commit hook failure

Hello, On Wed, 25 Aug 2021, Martin Liška wrote: > > remote: File "hooks/post_receive.py", line 47, in post_receive_one > > remote: update.send_email_notifications() > > remote: File > > "/sourceware1/projects/src-home/git-hooks/hooks/updates/__init__.py", ... > > remote: UnicodeDecodeErro

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

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: Optional machine prefix for programs in for -B dirs, match ing Clang

Hello, On Wed, 4 Aug 2021, John Ericson wrote: > On Wed, Aug 4, 2021, at 10:48 AM, Michael Matz wrote: > > ... the 'as' and 'ld' executables should be simply found within the > > version and target specific GCC libexecsubdir, possibly by being symlinks &

Re: Re: Optional machine prefix for programs in for -B dirs, match ing Clang

Hello, On Wed, 4 Aug 2021, John Ericson wrote: > > Doesn't GCC automatically look for those commands in the --prefix > > directory that you configure GCC with? Or is that only for native > > compilers? > > It will search only if --with-*=... was not passed, and it will never > prefix the quer

Re: Disabling TLS address caching to help QEMU on GNU/Linux

Hello, On Thu, 22 Jul 2021, Richard Biener via Gcc wrote: > But how does TLS usage transfer between threads? On the gimple level > the TLS pointer is not visible and thus we'd happily CSE its address: Yes. All take-address operations then need to be encoded explicitely with a non-CSE-able in

Re: [PATCH] Port GCC documentation to Sphinx

Hello, On Thu, 1 Jul 2021, Martin Liška wrote: > On 7/1/21 3:33 PM, Eli Zaretskii wrote: > > > Cc: jos...@codesourcery.com, gcc@gcc.gnu.org, gcc-patc...@gcc.gnu.org > > > From: Martin Liška > > > Date: Thu, 1 Jul 2021 14:44:10 +0200 > > > > > > > It helps some, but not all of the issues disappe

Re: [llvm-dev] RFC: Add GNU_PROPERTY_UINT32_AND_XXX/GNU_PROPERTY_UINT32_OR_XXX

Hello, On Tue, 22 Jun 2021, H.J. Lu wrote: > > > The issue is that libfoo.so used in link-time can be different from > > > libfoo.so at run-time. The symbol, foobar, in libfoo.so at link-time > > > has the default visibility. But foobar in libfoo.so at run-time can be > > > protected. ld.so sh

Re: [llvm-dev] RFC: Add GNU_PROPERTY_UINT32_AND_XXX/GNU_PROPERTY_UINT32_OR_XXX

t; > > gold and ld.lld just emit an error unconditionally. I think non-x86 > > GNU ld ports which never support "copy relocations on protected data > > symbols" may want to make the diagnostic unconditional as well. > > Well, while (Michael Matz and ) I think compatibility che

Re: git gcc-commit-mklog doesn't extract PR number to ChangeLog

Hello, On Thu, 17 Jun 2021, Martin Sebor via Gcc wrote: > > The original problem is that the PR wasn't _in the body_ of the commit > > But I see [PR100085] right there at the end of the _summary line_: Emphasis mine. Ciao, Michael.

Re: GCC documentation: porting to Sphinx

Hello, On Tue, 1 Jun 2021, Martin Liška wrote: > On 5/31/21 5:49 PM, Michael Matz wrote: > > Hello Martin, > > > > On Mon, 31 May 2021, Martin Liška wrote: > > > >> I've made quite some progress with the porting of the documentation and > >&g

Re: GCC documentation: porting to Sphinx

Hello Martin, On Mon, 31 May 2021, Martin Liška wrote: > I've made quite some progress with the porting of the documentation and > I would like to present it to the community now: > https://splichal.eu/scripts/sphinx/ > > Note the documentation is automatically ([1]) generated from texinfo with

Re: Successive hoisting and AVAIL_OUT in at least one successor heuristic

Hello, On Thu, 6 May 2021, Prathamesh Kulkarni via Gcc wrote: > Well, I was thinking of this test-case: > > int f(int cond1, int cond2, int cond3, int x, int y) > { > void f1(); > void f2(int); > void f3(); > > if (cond1) > f1 (); > else > { > if (cond2) > f2 (x

Re: 'walk_stmt_load_store_addr_ops' for non-'gimple_assign_single_p (stmt)'

Hello, On Wed, 17 Mar 2021, Richard Biener wrote: > > The walk_gimple functions are intended to be used on the SSA form of > > gimple (i.e. the one that it is in most of the time). > > Actually they are fine to use pre-SSA. Structurally, sure. > They just even pre-SSA distinguish between regi

Re: 'walk_stmt_load_store_addr_ops' for non-'gimple_assign_single_p (stmt)'

Hello, On Tue, 16 Mar 2021, Thomas Schwinge wrote: > >>Indeed, given (Fortran) 'zzz = 1', we produce GIMPLE: > >> > >>gimple_assign > >> > >>..., and calling 'walk_stmt_load_store_addr_ops' on that, I see, as > >>expected, the 'visit_store' callback invoked, with 'rhs' and 'arg': > >>''. > >

RE: [EXTERNAL] Re: DWARF Debug Info Relocations (.debug_str STRP references)

Hello, On Tue, 1 Dec 2020, Bill Messmer via Gcc wrote: > Thank you very much for the help. I was so fixated on the fact that the > .rela.debug* sections were there that I didn't pay attention to the > e_type in the ELF header. Apparently, neither did the library that I > was using to parse t

Re: [RFC] Increase libstdc++ line length to 100(?) columns

Hello, On Mon, 30 Nov 2020, Allan Sandfeld Jensen wrote: > > > On Sonntag, 29. November 2020 18:38:15 CET Florian Weimer wrote: > > > > * Allan Sandfeld Jensen: > > > > > If you _do_ change it. I would suggest changing it to 120, which is > > > > > next > > > > > common step for a lot of C++ proj

Re: [RFC] Increase libstdc++ line length to 100(?) columns

Hello, On Sun, 29 Nov 2020, Allan Sandfeld Jensen wrote: > On Sonntag, 29. November 2020 18:38:15 CET Florian Weimer wrote: > > * Allan Sandfeld Jensen: > > > If you _do_ change it. I would suggest changing it to 120, which is next > > > common step for a lot of C++ projects. > > > > 120 can be

Re: [libgcc2.c] Implementation of __bswapsi2()

Hello, On Thu, 12 Nov 2020, Stefan Kanthak wrote: > Does GCC generate (unoptimised) code there, similar to the following i386 > assembly, using 4 loads, 4 shifts, 2 ands plus 3 ors? Try for yourself. '-m32 -O2 -march=i386' is your friend. Ciao, Michael. Spoiler: it's generating: mov

Re: Problems with changing the type of an ssa name

Hello, On Sat, 25 Jul 2020, Gary Oblock via Gcc wrote: > if ( TYPE_P ( type) ) > { >TREE_TYPE ( ssa_name) = TYPE_MAIN_VARIANT ( type); >if ( ssa_defined_default_def_p ( ssa_name) ) > { > // I guessing which I know is a terrible thing to do... >

RE: New x86-64 micro-architecture levels

Hello, On Wed, 22 Jul 2020, Mallappa, Premachandra wrote: > > That's deliberate, so that we can use the same x86-* names for 32-bit > > library selection (once we define matching micro-architecture levels there). > > Understood. > > > If numbers are out, what should we use instead? > > x86-sse

Re: New mklog script

Hello, On Tue, 19 May 2020, Jakub Jelinek wrote: > On Tue, May 19, 2020 at 05:21:16PM +0100, Richard Earnshaw wrote: > > This is really a wart in the GNU coding style. And one reason why I > > tend to indent such labels by a single space. It particularly affects > > things like class definition

Re: New mklog script

Hello, On Tue, 19 May 2020, Martin Liška wrote: > > The common problems I remember is that e.g. when changing a function comment > > above some function, it is attributed to the previous function rather than > > following, labels in function confusing it: > > void > > foo () > > { > > .

Re: Should ARMv8-A generic tuning default to -moutline-atomics

Hello, On Wed, 29 Apr 2020, Florian Weimer via Gcc wrote: > Distributions are receiving requests to build things with > -moutline-atomics: > > > > Should this be reflected in the GCC upstream defaults for ARMv8-A > generic tuning? It

Re: GCC optimizations with O3

Hello, On Wed, 22 Apr 2020, Erick Ochoa wrote: > in order for me to debug my issue, I'm going to have to refactor passes > which directly reference optimize. For debugging you can also work backwards: use -O3 and add -fno-xy options. At least you then know (after disabling all O3 passes) that

Re: Not usable email content encoding

Hello, On Mon, 13 Apr 2020, Christopher Faylor wrote: > On Wed, Apr 08, 2020 at 04:15:27PM -0500, Segher Boessenkool wrote: > >On Wed, Apr 08, 2020 at 01:50:51PM +, Michael Matz wrote: > >>On Wed, 8 Apr 2020, Mark Wielaard wrote: > >>>Earlier versions of Mainma

Re: Not usable email content encoding

Hello, On Wed, 8 Apr 2020, Mark Wielaard wrote: > On Tue, 2020-04-07 at 11:53 +0200, Florian Weimer via Overseers wrote: > > Gmail can drop mail for any reason. It's totally opaque, so it's a > > poor benchmark for any mailing list configuration changes because it's > > very hard to tell if a pa

Re: Not usable email content encoding

Hello, On Tue, 7 Apr 2020, Frank Ch. Eigler wrote: > > I find that unconvincing, because even googlegroup email lists don't > > mangle From: from sender domains that are now mangled by sourceware.org > > :-/ > > It turns out receiving mail FROM google-groups mail is itself > sometimes at risk

Re: Not usable email content encoding

Hello, On Tue, 7 Apr 2020, Jonathan Wakely via Gcc wrote: > On Mon, 6 Apr 2020 at 23:00, Maciej W. Rozycki via Gcc > wrote: > > And can certainly score a positive though not a definite rating in spam > > qualification. I don't think we ought to encourage bad IT management > > practices by try

Re: Question about undefined functions' parameters during LTO

Hello, On Tue, 7 Apr 2020, Erick Ochoa wrote: > > So, when you want to compare types use useless_type_conversion_p (for > > equivalence you need useless(a,b) && useless(b,a)). In particular, > > for record types T it's TYPE_CANONICAL(T) that needs to be > > pointer-equal. (I.e. you could hard

Re: Question about undefined functions' parameters during LTO

Hello, On Tue, 7 Apr 2020, Erick Ochoa wrote: > Thanks for this lead! It is almost exactly what I need. I do have one more > question about this. It seems that the types obtained via > FOR_EACH_FUNCTION_ARGS and TREE_TYPE are different pointers when compiled with > -flto. > > What do I mean by t

Re: Not usable email content encoding

Hello, On Wed, 18 Mar 2020, Frank Ch. Eigler via Gcc wrote: > > > The From: header rewriting for DMARC participants is something sourceware > > > is doing now. > > > > Out of curiousity, is this rewriting you are talking about the cause for a > > lot of mails showing up as "From: GCC List" rathe

Re: Not usable email content encoding

Hi, On Wed, 18 Mar 2020, Frank Ch. Eigler via Gcc wrote: > > > The key here is to realize that the raw message is not what you get > > > back from the mailing list reflector, and also not the raw message > > > that was sent by the sender. In this day of mta intermediaries, > > > proxies, reflect

Re: Question about undefined functions' parameters during LTO

Hello, On Fri, 13 Mar 2020, Erick Ochoa wrote: > +for (tree parm = DECL_ARGUMENTS (undefined_function->decl); parm; parm = > DECL_CHAIN (parm)) > + { > + tree type = TREE_TYPE(parm); > + if (dump_file) fprintf(dump_file, "I want the type, do I have it? > %s\n", type ? "true" :

Re: [PATCH, v3] wwwdocs: e-mail subject lines for contributions

Hello, On Mon, 3 Feb 2020, Richard Earnshaw (lists) wrote: > Well, I'd review a patch differently depending on whether or not it was > already committed, a patch requiring review or an RFC looking for more > general comments, so I *do* think such an email prefix is useful. As I said: a very go

Re: [PATCH, v3] wwwdocs: e-mail subject lines for contributions

Hello, On Mon, 3 Feb 2020, Jakub Jelinek wrote: > > > The idea is that the [...] part is NOT part of the commit, only part of > > > the email. > > > > I understand that, but the subject line of this thread says "e-mail > > subject lines", so I thought we were talking about, well, exactly that;

Re: [PATCH, v3] wwwdocs: e-mail subject lines for contributions

Hi, On Mon, 3 Feb 2020, Richard Earnshaw (lists) wrote: > The idea is that the [...] part is NOT part of the commit, only part of > the email. I understand that, but the subject line of this thread says "e-mail subject lines", so I thought we were talking about, well, exactly that; and I see

Re: [PATCH, v3] wwwdocs: e-mail subject lines for contributions

Hello, On Mon, 3 Feb 2020, Richard Earnshaw (lists) wrote: > Where does your '50 chars' limit come from? It's not in the glibc text, > and it's not in the linux kernel text either. AFAICT this is your > invention and you seem to be the only person proposing it. Nope, it's fairly common, so m

Re: [RFC] Characters per line: from punch card (80) to line printer (132) (was: [Patch][OpenMP/OpenACC/Fortran] Fix mapping of optional (present|absent) arguments)

Hello, (oh a flame bait :) ) On Thu, 5 Dec 2019, Thomas Schwinge wrote: > So, I formally propose that we lift this characters per line restriction > from IBM punch card (80) to mainframe line printer (132). > > Tasks: > > - Discussion. I object to cluttering code in excuse for using sensibl

Re: Use predicates for RTL objects

Hi, On Wed, 7 Aug 2019, Arvind Sankar wrote: > => x->is_a (REG) Oh god, please no. Currently at least the RTL parts of GCC still have mostly a consistent and obvious style, which is a good thing. I have no idea why anyone would think the above is easier to read than REG_P (x). Ciao,

Re: Can LTO minor version be updated in backward compatible way ?

Hi, On Wed, 17 Jul 2019, Romain Geissler wrote: > However at scale, I think this can become a problem. What will happen > when in gcc 9.3 we change the version to 8.2 ? Will Tumbleweed recompile > 100% of the static libraris it ships ? Every compiler change causes the whole distro to be rebuilt.

Re: [PATCH] Do not warn with warn_unused_result for alloca(0).

Hi, On Thu, 13 Jun 2019, Jeff Law wrote: > > (In fact I think our builtin_alloca implementation could benefit when we > > added that behaviour as well; it's a natural wish to be able to free > > memory that you allocated). > > Also note that simply sprinkling alloca(0) calls won't magically re

Re: [PATCH] Do not warn with warn_unused_result for alloca(0).

Hi, On Wed, 12 Jun 2019, Martin Sebor wrote: > > Otherwise LGTM as the patch, but I'd like to hear from others whether > > it is kosher to add such a special case to the warn_unused_result > > attribute warning. And if the agreement is yes, I think it should be > > documented somewhere that a

Re: alloca (0) in include/libiberty.h

Hi, On Tue, 11 Jun 2019, Martin Liška wrote: > I see 3 occurrences of the alloca (0) in libiberty/regex.c, but there are > properly > guarded within: > > # ifdef C_ALLOCA > alloca (0); > # endif > > and then I noticed 2 more occurrences in gdb that break build right now: > > gdb/regcach

Re: Fixing inline expansion of overlapping memmove and non-overlapping memcpy

Hi, On Wed, 15 May 2019, Jakub Jelinek wrote: > Just one thing to note, our "memcpy" expectation is that either there is > no overlap, or there is 100% overlap (src == dest), both all the current > movmem == future cpymem expanders and all the supported library > implementations do support tha

Re: Fixing inline expansion of overlapping memmove and non-overlapping memcpy

how do we move from the existing movmem pattern > (which Michael Matz tells us should be renamed cpymem anyway) to this > new thing. Are you proposing that we still have both movmem and cpymem > optab entries underneath to call the patterns but introduce this new > memmove_with_hin

Re: Fixing inline expansion of overlapping memmove and non-overlapping memcpy

Hi, On Tue, 14 May 2019, Aaron Sawdey wrote: > memcpy -> expand with movmem pattern > memmove (no overlap) -> transform to memcpy -> expand with movmem pattern > memmove (overlap) -> remains memmove -> glibc call ... > However in builtins.c expand_builtin_memmove() does not actually do the > exp

  1   2   3   4   5   >