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 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 selects
> > initial-exec or local-exec fo
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?
> > >
> > > Please see the end of [2], where the offset to
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
32 matches
Mail list logo
