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
> > to whatever you want. That's at least
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
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
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
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
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
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 same outer loop,
> > though. BTW, the b
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
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 =
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
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'
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
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
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
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
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
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
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
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
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
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).
>
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
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
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
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
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
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 holds for the actually working variant
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
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
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
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
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
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
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
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
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,
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
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.
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
Hello,
note that I know next to nothing about Tricore in particular, so take
everything with grains of salt. Anyway:
On Mon, 19 Jun 2023, Claudio Eterno wrote:
> in your reply you mentioned "DSP". Do you want to use the DSP instructions
> for final assembly?
It's not a matter of me wanting or
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.
>
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
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
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
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
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
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__(
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.
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.
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
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
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
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
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
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
55 matches
Mail list logo
