On Tue, 1 Apr 2025, Richard Biener via Gcc wrote:
> In C++ there could be runtime initializers for a const qualified
> object. I think all
> you need to do is make sure the logic that places the object in .const
> vs. .global
> is consistent with the logic deciding how to access it.
I think it
On Sat, 1 Mar 2025, Martin Uecker via Gcc wrote:
> > > What was the reason to disallow those optimizations that
> > > could be allowed by default?
> >
> > -fallow-store-data-races guards transforms that we know to be incorrect
> > for source code that may become a part of a multithreaded progr
On Sat, 1 Mar 2025, Martin Uecker via Gcc wrote:
> Sorry for being a bit slow. This is still not clear to me.
>
> In vect/pr65206.c the following loop can be vectorized
> with -fallow-store-data-races.
>
> #define N 1024
>
> double a[N], b[N];
>
> void foo ()
> {
> for (int i = 0; i < N;
On Fri, 28 Feb 2025, Martin Uecker via Gcc wrote:
>
> I have one follow-up question: What is the reason
> that we have stronger semantics for stores by default (i.e.
> when not using -fallow-store-data-races) than for reads
> given that the standard would allow more freedom.
Why would it? On
On Tue, 24 Dec 2024, Florian Weimer wrote:
> * Alexander Monakov:
>
> > Well, the first paragraph in your initial mail was talking very explicitly
> > about making a tailcall from the wrapper, so I guess the goalpost has moved.
>
> Uhm, I meant a tailcall from the tra
On Mon, 23 Dec 2024, Florian Weimer via Gcc wrote:
> * Alexander Monakov:
> >> Does this work on all primary GCC targets?
> >
> > Yes? I'm not sure why you think it might not work. What are your
> > concerns?
>
> Targets not setting up REGISTER_NAMES,
On Mon, 23 Dec 2024, Florian Weimer via Gcc wrote:
> * Alexander Monakov:
>
> > On Mon, 16 Dec 2024, Florian Weimer via Gcc wrote:
> >
> >> I would like to provide a facility to create wrapper functions without
> >> lots of argument shuffling. To ach
On Mon, 16 Dec 2024, Florian Weimer via Gcc wrote:
> I would like to provide a facility to create wrapper functions without
> lots of argument shuffling. To achieve that, the wrapping function and
> the wrapped function should have the same prototype. There will be a
> trampoline that puts add
On Sun, 1 Dec 2024, Gerald Pfeifer wrote:
> I tried to delete it via
>
> # git push origin --delete remotes/origin/python-formatting
>
> alas just get
>
> error: unable to delete 'remotes/origin/python-formatting': remote ref does
> not exist
>
> Any idea how to drop that branch again f
On Sun, 10 Nov 2024, Jonathan Wakely via Gcc wrote:
> But 1 - (10 * 0.1) won't, and so the warning is pointing out that any exact
> equality comparisons can be affected by this kind of problem. If you don't
> like the warning, don't enable it.
I think OP's questions are in good faith and your l
On Thu, 29 Aug 2024, Richard Biener via Gcc wrote:
> On Thu, Aug 29, 2024 at 1:49 PM Allan Sandfeld Jensen
> wrote:
> >
> > Hi GCC
> >
> > I wanted to report one or more bugs, unfortunately they are not consistently
> > reproducable, which is odd. It happens when compiling the chromium part of
Hello,
I vaguely remember there was a recent, maybe within last two months, discussion
about semantics of union initialization where sizeof(first member) is less than
sizeof(union). The question was whether it's okay to initialize just that first
member and leave garbage bits in the other, larger,
On Mon, 8 Apr 2024, Florian Weimer wrote:
> * Alexander Monakov:
>
> >> There is quite a bit of variance in how the kernel is entered. On
> >> x86-64, one once popular mechanism is longer present in widely-used
> >> kernels.
> >
> > I assu
On Mon, 8 Apr 2024, Florian Weimer via Gcc wrote:
> * Matheus Afonso Martins Moreira via Gcc:
>
> > + It's stable
> >
> > This is one of the things which makes Linux unique
> > in the operating system landscape: applications
> > can target the kernel directly. Unlike i
On Thu, 14 Mar 2024, Andrew Cooper via Gcc wrote:
> I suppose that what I'm looking for is something a little like
> __builtin_constant_p() which can either be used in a straight if(), or
> in a __builtin_choose_expr().
>
> Anyway - is there a way of doing this that I've managed to overlook?
I
On Tue, 12 Dec 2023, Jonathan Wakely via Gcc wrote:
> On Mon, 11 Dec 2023, 17:08 Jingwen Wu via Gcc, wrote:
>
> > Hello, I'm sorry to bother you. And I have some gcc compiler optimization
> > questions to ask you.
> > First of all, I used csmith tools to generate c files randomly. Meanwhile,
>
Greetings,
the definitions for NOP_EXPR and CONVERT_EXPR in tree.def, having survived
all the way from 1992, currently say:
/* Represents a conversion of type of a value.
All conversions, including implicit ones, must be
represented by CONVERT_EXPR or NOP_EXPR nodes. */
DEF
On Fri, 1 Dec 2023, Richard Biener via Gcc wrote:
> On Fri, Dec 1, 2023 at 9:57 AM Florian Weimer wrote:
> >
> > * Richard Biener:
> >
> > > On Fri, Dec 1, 2023 at 9:04 AM Florian Weimer via Gcc
> > > wrote:
> > >>
> > >> I've received a report of a mingw build failure:
> > >>
> > >> ../../..
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
On Mon, 18 Sep 2023, Florian Weimer wrote:
> Okay, you meant “changing the result” as in “changing the result in a
> permitted way”. Sorry, was confused. So this is a bad example all
> around. Are there better ones (that don't involve FMA)?
If you're looking for something similar to your ori
On Mon, 18 Sep 2023, Martin Uecker wrote:
> > The hardest part would be popping the pragma state when leaving a block,
> > which didn't seem difficult (at least for C).
>
> It is fairly restricted where it can appear, it essentially operates
> on the level of compound statements (!= blocks).
On Mon, 18 Sep 2023, Florian Weimer via Gcc wrote:
> But the contraction would still be valid after an isfinite check
> (something that ranger might catch these days), or with with
> -ffinite-math-only in general. Right?
Nope, still not valid for negative zero ('x + x - x' would yield
positive
On Mon, 18 Sep 2023, Jakub Jelinek wrote:
> Perhaps we should add some initial hammer approach for the pragma, like
> if you ever use the pragma to turn it somewhere off, it is turned off
> globally, or ditto per function. Might be far easier than trying to
> make it precise that contraction is
On Mon, 18 Sep 2023, Florian Weimer via Gcc wrote:
> x - x is different because replacing it with 0 doesn't seem to be a
> valid contraction because it's incorrect for NaNs. x + x - x seems to
> be different in this regard, but in our implementation, there might be a
> quirk about sNaNs and qNa
Hi Florian,
On Thu, 14 Sep 2023, Alexander Monakov wrote:
>
> On Thu, 14 Sep 2023, Florian Weimer via Gcc wrote:
>
> > While rebuilding CentOS Stream with -march=x86-64-v3, I rediscovered
> > several packages had test suite failures because x86-64 suddenly gained
&g
On Thu, 14 Sep 2023, Florian Weimer via Gcc wrote:
> While rebuilding CentOS Stream with -march=x86-64-v3, I rediscovered
> several packages had test suite failures because x86-64 suddenly gained
> FMA support. I say “rediscovered” because these issues were already
> visible on other architectu
On Mon, 19 Jun 2023, Mikael Pettersson via Gcc wrote:
> (Note I'm reading the gcc mailing list via the Web archives, which
> doesn't let me create "proper" replies. Oh well.)
(there's a public-inbox instance at https://inbox.sourceware.org/gcc/
but some messages are not available there)
Alexan
On Wed, 14 Jun 2023, Julian Waters via Gcc wrote:
> Hi all,
>
> Would it be acceptable for a changeset that applies the parsing of string
> literals in extended assembly blocks to the assembly templates inside basic
> asm to be mailed here? As I see it, there is no reason to keep this
> behavio
On Tue, 16 May 2023, Florian Weimer wrote:
> > (FWIW: no, this should not be an error, a warning is fine, and I actually
> > think the current state of it not being in Wall is the right thing as
> > well)
(this is mixed up, -Wpointer-sign is in fact enabled by -Wall)
> I don't understand why
On Fri, 12 May 2023, Gabriel Ravier via Gcc wrote:
> On 5/12/23 19:52, Florian Weimer wrote:
> > I think we have another problem.
> >
> > We do not warn by default for:
> >
> >int x;
> >unsigned *p;
> >
> >p = &x;
> >
> > Isn't that a conformance issue because the pointers are incomp
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
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
On Tue, 6 Dec 2022, Richard Biener via Gcc wrote:
> Implementation-wise one could do a similar trick as we have for
> global_options vs. global_options_set - add a global_options_error copy (ick!)
> (and global_options_error_set!?) and have the logic that decides whether
> a warning is an error
Greetings, David, community,
I'd like to get your input on how GCC command line interface should support
making a "tiered" warning like -Warray-bounds={1,2} an error for "tier 1"
where fewer false positives are expected, and a plain warning otherwise.
There was a recent thread mentioning the curr
On Wed, 16 Nov 2022, Michael Matz via Gcc wrote:
> I sympathize, and I would think a compiler emitting an error (not a
> warning) in the situation at hand (in absence of -Werror) is overly
> pedantic. But, could autoconf perhaps avoid the problem? AFAICS the
> ac_fn_c_check_func really does
On Thu, 25 Aug 2022, Mark Wielaard wrote:
> Hi gcc-hackers,
>
> Given that gcc is part of the sourceware family the mailinglists are
> now also available through the public-inbox instance at
> https://inbox.sourceware.org/
Thanks for this. At the moment something seems broken with a few lists
On Thu, 28 Jul 2022, David Malcolm via Gcc wrote:
> Is there documentation on setting up text editors to work with our
> coding style? A lot of the next generation of developers aren't using
> vi or emacs; they's using VS Code, CLion, and other editors. Does
> anyone have docs on e.g. how to s
On Wed, 20 Jul 2022, Sebastian Huber wrote:
> On 20/07/2022 13:41, Alexander Monakov wrote:
> > On Wed, 20 Jul 2022, Sebastian Huber wrote:
> >
> >> How does Ada get its default TLS model?
> > You shouldn't need to do anything special, GCC automatically sel
On Wed, 20 Jul 2022, Sebastian Huber wrote:
> How does Ada get its default TLS model?
You shouldn't need to do anything special, GCC automatically selects
initial-exec or local-exec for non-PIC (including PIE).
Alexander
On Wed, 23 Jun 2021, Martin Jambor wrote:
> Hi,
>
> On Wed, Jun 23 2021, Erick Ochoa via Gcc wrote:
> > Hello,
> >
> > I know that some BUILT_IN functions are treated in a special way by
> > the points-to analysis. Those functions are those that take pointers
> > as arguments or return them but d
On Fri, 23 Apr 2021, Josh Haberman via Gcc wrote:
> On Fri, Apr 23, 2021 at 1:10 PM Iain Sandoe wrote:
> > I did try to use it this ^ for GCC coroutines (where such a guarantee is
> > pretty important)
> >
> > However, the issue there is that not all targets support indirect tailcalls.
>
> I'm n
On Mon, 8 Feb 2021, Benoît De Dinechin wrote:
> Hello,
>
> Is there a way to activate control speculation of loads in GCC, starting with
> the ia64 target? For a loop as simple as on GCC 7.5, I could not get any:
I think in that loop cost modeling in sel-sched estimates that load speculation
On Tue, 29 Dec 2020, Richard Biener via Gcc wrote:
> >I think clang follows gcc and uses the type of the first operand.
>
> The desired behavior is the one that OpenCL specifies. If it is implementation
> defined we should document behavior. I agree symmetry is nice but eventually
> the current C
On Sat, 26 Dec 2020, Andrew Pinski via Gcc wrote:
> Two things, this should really be on the binutils mailing list rather
> than the GCC mailing list. Second you can't generate a flat binary
> which has a GOT as it requires relocations and there is no way to
> represent relocations in flat binary
On Fri, 11 Dec 2020, Andrew Haley via Gcc wrote:
> On 11/12/2020 07:12, Marc Glisse wrote:
> > On Thu, 10 Dec 2020, Lucas de Almeida via Gcc wrote:
> >
> >> when performing (int64_t) foo / (int32_t) bar in gcc under x86, a call to
> >> __divdi3 is always output, even though it seems the use of
On Thu, 10 Dec 2020, Lucas de Almeida via Gcc wrote:
> Hello,
> when performing (int64_t) foo / (int32_t) bar in gcc under x86, a call to
> __divdi3 is always output, even though it seems the use of the idiv
> instruction could be faster.
> This seems to remain even under -Ofast and other availa
On Thu, 5 Nov 2020, Alexander Monakov via Gcc wrote:
> On Thu, 5 Nov 2020, Uros Bizjak via Gcc wrote:
>
> > > No, this is not how LEA operates. It needs a memory input operand. The
> > > above will report "operand type mismatch for 'lea'" error.
>
On Thu, 5 Nov 2020, Uros Bizjak via Gcc wrote:
> > No, this is not how LEA operates. It needs a memory input operand. The
> > above will report "operand type mismatch for 'lea'" error.
>
> The following will work:
>
> asm volatile ("lea (%1), %0" : "=r"(addr) : "r"((uintptr_t)&x));
This is th
On Thu, 5 Nov 2020, Uros Bizjak wrote:
> On Thu, Nov 5, 2020 at 12:38 PM Alexander Monakov wrote:
> >
> > On Thu, 5 Nov 2020, Uros Bizjak via Gcc wrote:
> >
> > > > What is the usecase for stripping the address space for asm operands?
> > >
> >
On Thu, 5 Nov 2020, Uros Bizjak via Gcc wrote:
> > What is the usecase for stripping the address space for asm operands?
>
> Please see the end of [2], where the offset to is passed in %rsi
> to the call to this_cpu_cmpxchg16b_emu. this_cpu_cmpxchg16b_emu
> implements access with PER_CPU_VAR((%r
On Thu, 5 Nov 2020, Uros Bizjak via Gcc wrote:
> > Looks like writing
> >
> > typeof((typeof(_var))0) tmp__;
> >
> > makes it work. Assumes there's a literal zero for the type of course.
>
> This is very limiting assumption, which already breaks for the following test:
To elaborate Richard'
> I obtained perf stat results for following benchmark runs:
>
> -O2:
>
> 7856832.692380 task-clock (msec) #1.000 CPUs utilized
> 3758 context-switches #0.000 K/sec
> 40 cpu-migrations #0
On Wed, 2 Sep 2020, Richard Biener via Gcc wrote:
> > Or we could decide that the extra multiplication is not that bad if it
> > saves an addition, simplifies the expression, possibly gains more insn
> > parallelism, etc, in which case we could just drop the existing hard
> > single_use check...
>
On Fri, 28 Aug 2020, Prathamesh Kulkarni via Gcc wrote:
> I wonder if that's (one of) the main factor(s) behind slowdown or it's
> not too relevant ?
Probably not. Some advice to make your search more directed:
Pass '-n' to 'perf report'. Relative sample ratios are hard to reason about
when they
On Mon, 24 Aug 2020, Richard Biener via Gcc wrote:
> Whether or not the conditional branch sequence is faster depends on whether
> the branch is well-predicted which very much depends on the data you
> feed the isWhitespace function with but I guess since this is the
> c == ' ' test it _will_ be a
On Mon, 16 Mar 2020, Martin Liška wrote:
> It's probably related to the following email tag:
> Content-Transfer-Encoding: quoted-printable
>
> The format is problematic when copying a patch.
> Email example:
> https://gcc.gnu.org/pipermail/gcc-patches/2020-March/542053.html
I'm surprised it's an
On Mon, 2 Mar 2020, Richard Biener wrote:
> PR90348 is certainly entertaining. But I guess for a GSoC project
> we need a more elaborate implementation plan. The above suggesting
> of a "lifetime start" is IMHO a no-go btw. Instead I think the
> only feasible way is to make all references indir
Hi,
following the conversation in PR 90348, I wonder if it would make sense
to suggest the idea presented there as a potential GSoC topic? Like this:
**Enhance GIMPLE IR to represent lifetimes explicitly** At the moment,
GCC internal representation GIMPLE lacks precise lifetime information
for a
On Mon, 24 Feb 2020, Andreas Schwab wrote:
> On Feb 24 2020, Petr Tesarik wrote:
>
> > On Mon, 24 Feb 2020 12:29:40 +0100
> > Andreas Schwab wrote:
> >
> >> On Feb 24 2020, Petr Tesarik wrote:
> >>
> >> > This works great ... until there's some inline asm() statement, for
> >> > which gcc canno
On Thu, 6 Feb 2020, Moritz Strübe wrote:
> Why is this so hard optimize? As it's quite a common pattern I'd expect that
> there would be at least some hand-coded special case optimizer. (This isn't
> criticism - I'm honestly curious.) Or is there a reason gcc shouldn't optimize
> this / Why it does
On Mon, 3 Feb 2020, Richard Earnshaw (lists) wrote:
> Upper case is what glibc has, though it appears that it's a rule that is not
> strictly followed. If we change it, then it becomes another friction point
> between developer groups. Personally, I'd leave it as is, then turn a blind
> eye to s
On Mon, 3 Feb 2020, Richard Earnshaw (lists) wrote:
> I've not seen any follow-up to this version. Should we go ahead and adopt
> this?
Can we please go with 'committed' (lowercase) rather than all-caps COMMITTED?
Spelling this with all-caps seems like a recent thing on gcc-patches, before
every
On Fri, 10 Jan 2020, Siddhesh Poyarekar wrote:
> I spent some time thinking about this and while it's trivial to fix by
> disabling ifuncs for static glibc, I wanted a solution that wasn't such
> a big hammer. The other alternative I could think of is to have an
> exported alias (called __builtin
On Mon, 6 Jan 2020, Martin Liška wrote:
> You are right, we do not leverage multi-byte NOPs. Note that the support
> depends
> on a CPU model (-march) and the similar code is quite complex in binutils:
> https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob;f=gas/config/tc-i386.c;h=d0b8f
On Wed, 21 Aug 2019, Paul Koning wrote:
> I agree, but if the new approach generates a warning for code that was written
> to the old rules, that would be unfortunate.
FWIW I don't know which GCC versions accepted 'packed' on a scalar type.
Already in 2006 GCC 3.4 would issue a warning:
$ echo '
On Tue, 20 Aug 2019, "Markus Fröschle" wrote:
> Thank you (and others) for your answers. Now I'm just as smart as before,
> however.
>
> Is it a supported, documented, 'long term' feature we can rely on or not?
>
> If yes, I would expect it to be properly documented. If not, never mind.
I thin
On Mon, 19 Aug 2019, Richard Earnshaw (lists) wrote:
> Correct, but note that you can only pack structs and unions, not basic types.
> there is no way of under-aligning a basic type except by wrapping it in a
> struct.
I don't think that's true. In GCC-9 the doc for 'aligned' attribute has been
s
On Mon, 22 Jul 2019, Jozef Lawrynowicz wrote:
> This would have to be caught at the point that an optimization pass
> first considers inserting a CALL to the interrupt, i.e., if the machine
> description tries to prevent the generation of a call to an interrupt function
> once the RTL has been gen
On Fri, 19 Jul 2019, Jozef Lawrynowicz wrote:
> For MSP430, the folding of identical functions marked with the "interrupt"
> attribute by -fipa-icf-functions results in wrong code being generated.
> Interrupts have different calling conventions than regular functions, so
> inserting a CALL from on
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 +=
On Wed, 20 Feb 2019, Warren D Smith wrote:
> but if I try to replace that with the nicer (since more portable)
>c = __builtin_shuffle(a, b);
> then
> error: use of unknown builtin '__builtin_shuffle'
> [-Wimplicit-function-declaration]
Most likely you're on OS X and the 'gcc' command actually
On Sat, 29 Dec 2018, Bin.Cheng wrote:
> tracer-1.c: Assembler messages:
> tracer-1.c:16: Error: symbol `foo_label' is already defined
>
> Root cause is in tracer.c which duplicates basic block without
> checking if any GIMPLE_ASM defines labels.
> Is this a bug or invalid code?
This is invalid co
On Thu, 11 Oct 2018, Jason A. Donenfeld wrote:
>
> I realize this is probably a fairly trivial matter, but I am very
> curious if somebody knows which heuristic gcc is applying here, and
> why exactly. It's not something done by any other compiler I could
> find, and it only started happening with
On Tue, 9 Oct 2018, Richard Biener wrote:
>
> then we cannot set the alignment of i_1 at/after k = *i_1 because doing so
> would
> affect the alignment test which we'd then optimize away. We'd need to
> introduce
> a SSA copy to get a new SSA name but that would be optimized away quickly.
We p
On Tue, 9 Oct 2018, Richard Biener wrote:
> >This had worked as Paul expects until GCC 4.4 IIRC and this was perfectly OK
> >for every language on strict-alignment platforms. This was changed only
> >because of SSE on x86.
>
> And because we ended up ignoring all pointer casts.
It's not quite o
On Mon, 8 Oct 2018, Michael Matz wrote:
> > Ok, but why is that not a bug? The whole point of passing alignment to
> > the movmem pattern is to let it generate code that takes advantage of
> > the alignment. So we get a missed optimization.
>
> Only if you somewhere visibly add accesses to *i
On Mon, 1 Oct 2018, Jeff Law wrote:
> To add a bit more context for Cory.
>
> Generally backports are limited to fixing regressions and serious code
> generation bugs. While we do make some exceptions, those are good
> general guidelines.
>
> I don't think the qsort changes warrant an exception.
Hello,
Here's the promised "libgcov summary"; sorry about the delay.
So libgcov has a bit unusual design where:
- on the one hand, the library is static-only, has PIC code and may be linked
into shared libraries,
- almost all gcov symbols have "hidden" visibility so they don't participa
On Thu, 13 Sep 2018, Wilco Dijkstra wrote:
> What do people think? Ideally I'd like to support this in a generic way so
> all targets can
> benefit, but it's also feasible to enable it on a per-target basis. Also
> since not all libraries
> will support the new interface, there would have to be a
On Mon, 27 Aug 2018, Martin Liška wrote:
> Hi.
>
> Recently I've noticed that I have wrongly set up my editor and
> I installed quite some changes where my changelog entries
> have 8 spaces instead of a tabular.
>
> I grepped that for all ChangeLog files (ignoring ChangeLog-{year} files)
> and I
Hello,
For the upcoming Cauldron, I've registered a BoF on treatment of undefined
behavior in GCC. To "promote" the BoF, collect some input prior to the
event, and indirectly indicate my interests, I am offering the following
light-hearted questionnaire.
I would ask to mail responses directly to
On Fri, 3 Aug 2018, Martin Liška wrote:
> I'm attaching current patch, so any comment is welcomed.
Please consider passing -Wl,-z,now when linking the new shared library:
gcov has a few thread-local variables that may be accessed in async-signal
context, and Glibc has bugs related to lazy binding
On Fri, 27 Jul 2018, keshav tilak wrote:
> This leads to GCC compiler issuing a call to `memcpy@PLT()' in function bar1.
>
> I want to create a position independent executable from this source
> and run this on
> a secure environment which implements ASLR and the loader disallows any binary
> whic
On Tue, 24 Jul 2018, Fredrik Hederstierna wrote:
> So my question is how to approach this problems when doing benchmarking,
> ofcourse we want the benchmark to mirror as near as 'real life' code as
> possible. But if code contains real bugs, and issues that could cause
> unpredictable code genera
On Mon, 23 Jul 2018, Segher Boessenkool wrote:
> For example for .md files you can use
>
> [diff "md"]
> xfuncname = "^\\(define.*$"
>
> in your local clone's .git/config
>
> and
>
> *.md diff=md
>
> in .gitattributes (somewhere in the source tree).
Not necessarily in the source tre
On Thu, 5 Jul 2018, Richard Kenner wrote:
> > After 20 years of hacking on GCC I feel like I have literally wasted
> > days of my life typing out ChangeLog entries that could have easily been
> > generated programmatically.
> >
> > Can someone refresh my memory here, what are the remaining argu
On Wed, 4 Jul 2018, Kugan Vivekanandarajah wrote:
> We noticed a difference in the code generated for aarch64 gcc 7.2
> hosted in Linux vs mingw. AFIK, we are supposed to produce the same
> output.
>
> For the testacse we have (quite large and I am trying to reduce), the
> difference comes from sc
On Fri, 13 Apr 2018, Vivek Kinhekar wrote:
> The mfence instruction with memory clobber asm instruction should create a
> barrier between division and printf instructions.
No, floating-point division does not touch memory, so the asm does not (and
need not) restrict its motion.
Alexander
On Fri, 2 Mar 2018, Peter Bergner wrote:
> But currently ira-lives.c:process_bb_node_lives() has:
>
> /* Don't allocate allocnos that cross setjmps or any
> call, if this function receives a nonlocal
> goto. */
> if (cfun->has_nonlocal_label
> || find_reg_note (insn, REG_SETJ
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 a big problem,
if not for backwards compatibility c
On Mon, 26 Feb 2018, Ruslan Nikolaev via gcc wrote:
> Well, if libatomic is already doing it when corresponding CPU feature is
> available (i.e., effectively implementing operations using cmpxchg16b), I do
> not see any problem here. mcx16 implies that you *have* cmpxchg16b, therefore
> other code
Hello,
Although I wouldn't like to fight defending GCC's design change here, let me
offer a couple of corrections/additions so everyone is on the same page:
On Mon, 26 Feb 2018, Ruslan Nikolaev via gcc wrote:
>
> 1. Not consistent with clang/llvm which completely supports double-width
> atomics
On Fri, 12 Jan 2018, Joseph Myers wrote:
> On Fri, 12 Jan 2018, Alexander Monakov wrote:
>
> > No. The qsort_chk effort was limited to catching instances where comparators
> > are invalid, i.e. lack anti-commutativity (may indicate A < B < A) or
> > transitivity pr
On Fri, 12 Jan 2018, Jeff Law wrote:
> THe key here is the results can differ if the comparison function is not
> stable. That's inherent in the qsort algorithms.
I'm afraid 'stable' is unclear/ambiguous in this context. I'd rather say
'if the comparator returns 0 if and only if the items being c
On Fri, 12 Jan 2018, Jakub Jelinek wrote:
> The qsort checking failures are tracked in http://gcc.gnu.org/PR82407
> meta bug, 8 bugs in there are fixed, 2 known ones remain.
Note that qsort_chk only catches really bad issues where the compiler
invokes undefined behavior by passing an invalid compa
On Fri, 20 Oct 2017, Torvald Riegel wrote:
> On Thu, 2017-10-19 at 15:31 +0300, Alexander Monakov wrote:
> > On Thu, 19 Oct 2017, Andrew Haley wrote:
> > > No, you did not. This looks like a bug. Please report it.
> >
> > This bug is fixed on trunk, so should wor
On Thu, 19 Oct 2017, Andrew Haley wrote:
> On 19/10/17 12:58, Mattias Rönnblom wrote:
> > Did I misunderstand the semantics of
> > atomic_thread_fence+memory_order_release?
>
> No, you did not. This looks like a bug. Please report it.
This bug is fixed on trunk, so should work from gcc-8 onwar
On Tue, 12 Sep 2017, Wilco Dijkstra wrote:
> * Make -fno-math-errno the default - this mostly affects the code generated
> for
> sqrt, which should be treated just like floating point division and not set
> errno by default (unless you explicitly select C89 mode).
(note that this can be selec
On Thu, 3 Aug 2017, Richard Biener wrote:
> Btw., I did this once to represent constrained expressions on
> multi-dimensional arrays in SSA form. There control (aka loop) structure was
> also implicit. Google for 'middle-end array expressions'. The C interface
> was builtins and VLAs.
The descr
On Sun, 16 Jul 2017, Segher Boessenkool wrote:
> > How? There's no stable sort in libc and switching over to std::stable_sort
> > would be problematic.
>
> Why?
- you'd need to decide if the build time cost of extra 8000+ lines
lines brought in by (per each TU) is acceptable;
- you'd need to
1 - 100 of 172 matches
Mail list logo
