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:
> 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, 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 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 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 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 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 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 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
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 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,
Suppose a user builds a non-PIC shared object for x86 target with gcc by
passing -shared but not -fPIC. This works, but internally GCC will not set
flag_shlib (as flag_shlib == flag_pic && !flag_pie).
Suppose further the user loads that shared object at runtime with dlopen. For
that to
On Fri, 19 Jul 2013, Jakub Jelinek wrote:
> Furthermore, on Linux you can dlopen even libraries with initial-exec TLS
> model in it (as long as they don't use too big TLS sections).
This is the failure I'm referring to ("cannot load any more object ..."):
http://repo.or.cz/w/glibc.git/blob/HEAD:/e
On Fri, 19 Jul 2013, Jakub Jelinek wrote:
> If user code has __attribute__((tls_model ("global-dynamic"))) and the
> compiler determines that it is not going to be used in a shared library,
> then it of course optimizes it to a better code
I see your point, but that's not how tls_model attribute w
On Fri, 19 Jul 2013, Jakub Jelinek wrote:
> The change of memory models based on flag_shlib is completely intentional,
> it is similar to the linker TLS optimizations but at the compiler level,
> so if you want to ad some comment to documentation, that is fine, but
> I don't see anything to fix.
T
Hello,
On Mon, 2 Apr 2012, Ludovic Courtès wrote:
> Hello,
>
> The GRAPHITE-OpenCL work published a couple of years ago looks
> interesting [0].
>
> What’s the status of the code? Is it accessible on-line?
The code has been merged into graphite branch; it can be obtained via:
svn co svn://gc
Hi,
This is a case when ivopts pass makes too many induction variables, exceeding
the number of available registers. If you want to debug it, see
ivopts_global_cost_for_size in tree-ssa-loop-ivopts.c and its callers;
perhaps, the issue is that it fails to account for IVs created in inner loops
wh
On Wed, 2 May 2012, Ben Morgan wrote:
> Hello,
>
> In a course at my university (Universität Würzburg, Germany) we have
> created a 32-bit RISC CPU architecture -- the HaDesXI-CPU -- (in VHDL)
> which we then play onto a FPGA (the Xilinx Spartan-3AN) to use. So far
> if we want to do anything wi
On Wed, 2 May 2012, Ian Lance Taylor wrote:
> It's worth looking at Anthony Green's blog about implementing moxie at
> http://moxielogic.org/ , as he described the process of doing a full GCC
> port.
Let me clarify that Anthony described porting in his "GGX patch archives",
linked in my other r
> As a consequence inside sel_remove_empty_bb I hit on the following assert:
> gcc_assert (in_current_region_p (merge_bb));
Sounds like your GCC tree does not have Andrey's fix for PR 52250 (SVN
revision 184975).
Alexander
On Tue, Jul 17, 2012 at 8:39 PM, Alex Turjan wrote:
>
> Hi,
> I tried the patch but it doesnt solve my problem.
> The patch addresses the problem on the else branch but my problem is on the
> if:
> if (can_merge_blocks_p (bb->prev_bb, bb))
> sel_merge_blocks ...
I don't understand. You said
On Wed, Jul 18, 2012 at 1:05 AM, Alex Turjan wrote:
> I found the patch from the following link:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52250
See comment 9. The patch pasted in the audit trail is not what has
been committed.
Alexander
On Mon, 18 Feb 2013, Michael Matz wrote:
> Automatic variables, as they are on the stack, are unlikely to usually get
> the value 0 out of pure luck, so an option to initialize them to 0xDEADBEAF
> doesn't make much sense.
Hm, but the following comment from init-regs.c indicates that GCC will set
(mem/c:DI (plus:DI (reg/f:DI 111 r119)
(const_int -1456 [0xfa50])) [64 ivtmp.1640+0 S8 A64])
Does IRA support stack slot sharing described in the comment?
Thanks.
--
Alexander Monakov
hanks in advance for comments
--
Alexander Monakov
diff -puN trunk/gcc/cfgexpand.c export-ddg/gcc/cfgexpand.c
--- trunk/gcc/cfgexpand.c 2007-06-22 20:19:52.0 +0400
+++ export-ddg/gcc/cfgexpand.c 2007-06-29 17:34:20.0 +0400
@@ -1988,6 +1988,7 @@ tree_expand_cfg (void)
/* T
ported data, or discarding the irrelevant
information?
I mentioned before that I would need to take care of basic block
duplication on tree level, but I have seen no example of that
happening after iv-opts so far. Does anyone know offhand whether it
is possible?
Thanks
--
Alexander Monakov
---
your answers will provide helpful directions for other
students who want a GCC-related term/graduation project.
Thanks.
--
Alexander Monakov
#x27;no', but
just in case :) Again, this is needed to support data speculation before
register allocation: register that is speculatively loaded must be same
for speculative load and check.
Thanks.
Alexander Monakov
On Fri, 07 Dec 2007 23:49:28 +0300, Daniel Berlin <[EMAIL PROTECTED]>
wrote:
On 12/7/07, Alexander Monakov <[EMAIL PROTECTED]> wrote:
Hi.
Attached is the patch that allows to save dependence info obtained on
tree
level by data-reference analysis for usage on RTL level (fo
e, and operand_equal_p
will discard that (since trees will look the same after out-of-SSA). I do
not see a better way to provide flow-sensitive annotations for MEMs.
DDR will mark them as data refs
Come again? :)
Thanks.
--
Alexander Monakov
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 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 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, 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 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, 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 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 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 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 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, 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 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 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...
>
> 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 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'
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 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:
> > 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, 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, 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 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 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 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 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 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 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 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, 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 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 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 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
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 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
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 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 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 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 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 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
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 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,
>
101 - 172 of 172 matches
Mail list logo
