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
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 ...):
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 works
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.
The
On Wed, 28 May 2014, Kyrill Tkachov wrote:
Hi all,
The documentation for TARGET_MACRO_FUSION_PAIR says that it can be used to
tell the scheduler that two insns should not be scheduled apart. It doesn't
specify what kinds of insns those can be.
Yet from what I can see in sched-deps.c it
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)
/* Tag the blocks
your answers will provide helpful directions for other
students who want a GCC-related term/graduation project.
Thanks.
--
Alexander Monakov
:) 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 (for RTL memory
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 Sat, 31 Dec 2011, Matt Davis wrote:
Hi,
I am having an RTL problem trying to make a function call from a
COND_EXEC rtx. The reload pass has been called, and very simply I
want to compare on an 64bit x86 %rdx with a specific integer value,
and if that value is true, my function call
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
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
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 with
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
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 atur...@yahoo.com 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.
On Wed, Jul 18, 2012 at 1:05 AM, Alex Turjan atur...@yahoo.com 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
/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
Hi,
On Tue, 27 Oct 2009, Markus L wrote:
Hi,
I recently read the articles about the selective scheduling
implementation and found it quite interesting, I especially liked the
idea of how neatly software pipelining is integrated. The target I am
working on is a VLIW DSP so obviously these
(libgomp only includes the latter).
This can be fixed by making configure use -Werror (I believe that
adding --with-pthread= option is out of the question).
Bootstraps on affected systems should probably use
make CFLAGS_FOR_TARGET='-g -O2 -I/usr/include/nptl'
as a clean workaround.
--
Alexander
.
No, at present SMS is not able to schedule any loops on x86 at all. This
is due to implementation detail: SMS operates on loops that end with
decrement-and-branch instruction, and GCC does not generate such
instructions on x86.
Sorry.
Alexander Monakov
regards,
Alexander Monakov
/ . Posting bug reports to gcc-bugs@ does
not register them in the bugzilla, and thus is not recommended.
Thanks.
Alexander Monakov
On Tue, 11 May 2010, Revital1 Eres wrote:
Hello,
I have a question regarding the process of bundling and NOPs insertion for
VLIW architecture
and I appreciate your answer:
I am calling the second scheduler from the machine reorg pass; similar to
what is done for IA64.
I now want to
Hi,
On Fri, 25 Jun 2010, Jan Hubicka wrote:
I would be also very interested to know how profile feedback works in this
case
(and why it does not work in previous releases).
Profiling multi-threading programs needs -fprofile-correction that appeared
only in 4.4 (but I have no idea whether
On Tue, 6 Jul 2010, Alex Turjan wrote:
Hi,
Is there functionality in gcc based on which the CFG can be traversed in
such a way that a node gets visited once all of its predecessors have been
visited?
(Assuming you mean when there are no loops)
Yes, see post_order_compute in cfganal.c. It
On Mon, 26 Jul 2010, Revital1 Eres wrote:
Hello,
Doloop optimization fails to be applied on the following kernel from
tescase sms-4.c with mainline (-r 162294) due to 'Possible infinite
iteration
case' message; taken from the loop2_doloop dump. (please see below).
With an older
On Mon, 2 Aug 2010, Bingfeng Mei wrote:
Hi,
I ran a small test to see how the trunk/4.5 works
with the rewritten restrict qualified pointer code. But it doesn't
seem to work on both x86-64 and our port.
tst.c:
void foo (int * restrict a, int * restrict b,
int * restrict c,
On Tue, 3 Aug 2010, Bingfeng Mei wrote:
Thanks, I can reproduce it with trunk compiler but not 4.5.0.
Do you know how alias set are represented and used now.
I'm not aware of any changes regarding alias sets.
It used to
be each alias set is assigned a unique number and there won't
be
hope I will have a chance to ask you for
help in the frame of GSoC project.
--
Alexander Monakov
.
--
Alexander Monakov
On Fri, 26 Jun 2009, Joe Buck wrote:
On Fri, Jun 26, 2009 at 03:38:31AM -0700, Alexander Monakov wrote:
1. Add bool field `modified_p' in bitmap structure.
2. Make iterator setup functions (e.g. bmp_iter_set_init) reset it to
false.
3. Make functions that modify the bitmap set it to true.
4
On Thu, 11 Nov 2010, Ian Lance Taylor wrote:
roy rosen roy.1ro...@gmail.com writes:
If I have two insns:
r2 = r3
r3 = r4
It seems to me that the dependency analysis creates a dependency
between the two and prevent parallelization. Although there is a
dependency (because of r3) I
On Fri, 11 Feb 2011, Bernd Schmidt wrote:
Suppose I have two insns, one reserving (A|B|C), and the other reserving
A. I'm observing that when the first one is scheduled in an otherwise
empty state, it reserves the A unit and blocks the second one from being
scheduled in the same cycle. This
On Tue, 13 Jan 2015, Pengfei Yuan wrote:
I use perf with rbf88:k,rff88:k events (Haswell specific) to profile
the taken rate of conditional branches in the kernel. Here are the
results:
[...]
The results are very strange because all the taken rates are greater
than 50%. Why not reverse the
There's a pending patch for glibc that addresses this issue among others:
https://sourceware.org/ml/libc-alpha/2014-11/msg00469.html
([BZ#17090/17620/17621]: fix DTV race, assert, and DTV_SURPLUS Static TLS
limit)
Alexander
Given that info...and in spite of my aforementioned limited knowledge I
went back to take another look at the source and found this in
libfakechroot.c
/bld/fakechrt/fakechroot-2.16 $ grep -C 4 dlsym src/libfakechroot.c
/* Lazily load function */
LOCAL fakechroot_wrapperfn_t
On Sun, 15 Feb 2015, Cyd Haselton wrote:
On Sun, Feb 15, 2015 at 11:53 AM, Alexander Monakov amona...@ispras.ru
wrote:
Given that info...and in spite of my aforementioned limited knowledge I
went back to take another look at the source and found this in
libfakechroot.c
/bld
On Sun, 15 Feb 2015, Cyd Haselton wrote:
On Sun, Feb 15, 2015 at 12:41 PM, Cyd Haselton chasel...@gmail.com wrote:
*snip*
So to obtain the pointer to
dlopen the code like above can use dlsym(RTLD_DEFAULT, dlopen), but not
RTLD_NEXT (the loader precedes the fakeroot library in the
Hello,
Last year's x86 sibcall improvements added a currently xfailed test:
/* { dg-do compile { target ia32 } } */
/* { dg-options -O2 } */
extern int doo1 (int);
extern int doo2 (int);
extern void bar (char *);
int foo (int a)
{
char s[256];
bar (s);
return (a 0 ?
Ah. I realize it's most likely for testing sibcall_[value]_pop_memory
peepholes, right? In which case the testcase might look like this:
/* { dg-do compile } */
/* { dg-options -O2 } */
void foo (int a, void (**doo1) (void), void (**doo2) (void))
{
char s[16] = {0};
do s[a] =
Hello,
A couple of comments below.
On Mon, 18 May 2015, Nick Clifton wrote:
val |= ~0 loaded;// Generates warning
val |= (unsigned) ~0 loaded; // Does not warn
To reduce verbosity, '~0u' can be used here instead of a cast.
* GCC supports a new option: -fno-plt
On Fri, 25 Sep 2015, Eric Botcazou wrote:
> > First, a belated follow-up to https://gcc.gnu.org/PR66512 . The bug is
> > asking why attribute-const appears to have a weaker effect in C++, compared
> > to C. The answer in that bug is that GCC assumes that attribute-const
> > function can terminate
Hello,
I'd like to ask for community input regarding __attribute__((const)) (and
"pure", where applicable). My main goal is to clarify unclear cases and
improve existing documentation, if possible.
First, a belated follow-up to https://gcc.gnu.org/PR66512 . The bug is asking
why attribute-const
Hello,
Can anyone quickly confirm whether "whining" feature in the GCC Bugzilla is
supposed to be functioning at the moment?
The lastest thread I could find indicates that it is actually supposed to be
working: https://gcc.gnu.org/ml/gcc/2010-09/msg00569.html .
However I've tried to setup a
On Wed, 24 Feb 2016, DJ Delorie wrote:
> The real question is: are stack arguments call-clobbered or
> call-preserved? Does the answer depend on the "pure" attribute?
Stack area holding stack arguments should belong to the callee for tail-calls
to work (the callee will trash that area when
On Tue, 16 Feb 2016, Marek Polacek wrote:
> Well, it's just that "s" has the nonnull attribute so the compiler thinks it
> should never be null in which case comparing it to null should be redundant.
> Doesn't seem like a false positive to me, but maybe someone else feels
> otherwise.
Please look
Hi,
On Thu, 24 Mar 2016, Bernd Schmidt wrote:
> On 03/24/2016 11:17 AM, Aldy Hernandez wrote:
> > On 03/23/2016 10:25 AM, Bernd Schmidt wrote:
> > > It looks like this block of code is written by a helper function that is
> > > really intended for other purposes than for maximal_insn_latency.
On Wed, 30 Mar 2016, Bernd Schmidt wrote:
> On 03/25/2016 04:43 AM, Aldy Hernandez wrote:
> > If Bernd is fine with this, I'm happy to retract my patch and any
> > possible followups. I'm just interested in having no path causing a
> > possible out of bounds access. If your patch will do that,
On Wed, 27 Jul 2016, Thorsten Glaser wrote:
First of all, I think option -malign-data=abi (new in GCC 5) addresses your
need: it can be used to reduce the default (excessive) alignment to just the
psABI-dictated value (you can play with this at https://gcc.godbolt.org even if
you can't install
On Fri, 17 Feb 2017, Thomas Schwinge wrote:
> On Fri, 17 Feb 2017 14:00:09 +0100, I wrote:
> > [...] for "normal" functions there is no reason to use the
> > ".param" space for passing arguments in and out of functions. We can
> > then get rid of the boilerplate code to move ".param %in_ar*" into
Hello,
On Tue, 29 Nov 2016, Sebastian Huber wrote:
> * env.c: Split out ICV definitions into...
> * icv.c: ...here (new file) and...
> * icv-device.c: ...here. New file.
>
> the env.c contains now only local symbols (at least for target *-rtems*-*):
>
[...]
>
> Thus the
On Wed, 7 Dec 2016, Richard Biener wrote:
> >Agreed, that's what I've been using in the past for glibc test cases.
> >
> >If that doesn't work, we'll need something else. Separate compilation
> >of test cases just to thwart compiler optimizations is a significant
> >burden, and will stop working
On Fri, 9 Dec 2016, Richard Biener wrote:
> Right, 'used' thwarts IPA on the callee side only. noclone and noinline are
> attributes affecting the caller side but we indeed miss attributes for the
> properties you mention above. I suppose adding a catch-all attribute for
> caller side effects
On Thu, 15 Dec 2016, Jakub Jelinek wrote:
> So here is a proof of concept of an attribute that disables inlining,
> cloning, ICF, IPA VRP, IPA bit CCP, IPA RA, pure/const/throw discovery.
> Does it look reasonable? Anything still missing?
I'd like to suggest some additions to the extend.texi
[adding gcc@ for the compiler-testsuite-related discussion, please drop either
gcc@ or gcc-help@ from Cc: as appropriate in replies]
On Wed, 7 Dec 2016, Segher Boessenkool wrote:
> > For example, this might have impact on writing test for GCC:
> >
> > When I am writing a test with noinline +
On Tue, 10 Jan 2017, Richard Biener wrote:
> In general I think they should match. But without seeing concrete
> examples of where they do not I can't comment on whether such exceptions
> make sense. For example if you adjust a DECLs alignment and then
> re-layout it I'd expect you might get a
On Wed, 11 Jan 2017, Richard Biener wrote:
> > WPA re-streams packed function bodies as-is, so anything referred to
> > from within just the body won't be subject to mode remapping; I think
> > only modes of toplevel declarations and functions' arguments will be
> > remapped. And I believe it
Hello, Richard, Jakub, community,
May I join/restart the old discussion about machine mode remapping at LTO
stream-in time. To recap, when offloading to NVPTX was introduced, there
was a problem due to differences in the set of supported modes (e.g. there
was no 'XFmode' on NVPTX that would
On Mon, 2 Jan 2017, Jakub Jelinek wrote:
> On Mon, Jan 02, 2017 at 09:49:55PM +0300, Alexander Monakov wrote:
> > On Mon, 2 Jan 2017, Jakub Jelinek wrote:
> > > If the host has long double the same as double, sure, PTX can use its
> > > native
> > > DFmode
On Mon, 2 Jan 2017, Jakub Jelinek wrote:
> If the host has long double the same as double, sure, PTX can use its native
> DFmode even for long double. But otherwise, the storage must be
> transferable between accelerator and host.
Hm, sorry, the 'must' is not obvious to me: is it known that the
On Mon, 2 Jan 2017, Jakub Jelinek wrote:
> In my view mode is essential part of the type system. It (sadly, but still)
> participates in many ABI decisions, but more importantly especially for
> floating point types it is the main source of information of what the type
> actually is, as just size
On Wed, 4 Jan 2017, Richard Biener wrote:
> My suggestion at that time isn't likely working in practice due to the
> limitations Jakub outlines below. The situation is a bit unfortunate
> but expect to run into more host(!) dependences in the LTO bytecode.
> Yes, while it would be nice to LTO
On Sun, 9 Apr 2017, Markus Trippelsdorf wrote:
> The minimum size heuristic for the garbage collector's heap, before it
> starts collecting, was last updated over ten years ago.
> It currently has a hard upper limit of 128MB.
> This is too low for current machines where 8GB of RAM is normal.
>
On Mon, 6 Mar 2017, Richard Biener wrote:
> >I am not a lawyer and this is not legal advice.
> >
> >Generating SPIR-V output would not cause that output to become GPLv3
> >licensed. However, linking the result against the GCC support
> >libraries, as is normally required for any program generated
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
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
On Sun, 16 Jul 2017, Segher Boessenkool wrote:
> I am well aware, and that is not what I asked. If we would use stable
> sorts everywhere
How? There's no stable sort in libc and switching over to std::stable_sort
would be problematic. The obvious approach is adding an implementation of
a stable
On Fri, 14 Jul 2017, Yuri Gribov wrote:
> I've also detect transitiveness violation compare_assert_loc
> (tree-vrp.c), will send fix once tests are done.
There are more issues still, see the thread starting at
https://gcc.gnu.org/ml/gcc-patches/2017-07/msg00899.html
Alexander
On Sat, 15 Jul 2017, Segher Boessenkool wrote:
> Would it hurt us to use stable sorts *everywhere*?
Stability (using the usual definition: keeping the original order of
elements that compare equal) is not required to achieve reproducibility [*].
GCC could import or nih any non-randomized
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
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
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 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
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
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
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 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
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
>
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 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
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 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
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
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
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
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,
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
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 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
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
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
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
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
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
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
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
1 - 100 of 1133 matches
Mail list logo
