modulo scheduling improvement. In
case this is not possible, I will seek guidance from Maxim Kuvyrkov.
Please feel free to share your thoughts and suggestions.
[1] Alias export patch by Dmitry Melnik:
http://gcc.gnu.org/ml/gcc-patches/2005-11/msg01518.html
--
Alexander Monakov
ur attention. I hope I will have a chance to ask you for
help in the frame of GSoC project.
--
Alexander Monakov
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 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 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, 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
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, 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
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
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
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
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 laying
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 whin
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. Migh
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, I'
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 GCC
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
[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 + nocl
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 o
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 (li
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 entr
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 corre
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 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 O
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 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-dep
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
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 fakechro
On Sun, 15 Feb 2015, Cyd Haselton wrote:
> On Sun, Feb 15, 2015 at 12:41 PM, Cyd Haselton 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 lookup
On Sun, 15 Feb 2015, Cyd Haselton wrote:
> On Sun, Feb 15, 2015 at 11:53 AM, Alexander Monakov
> 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
> >&g
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: -fn
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
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 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.
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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 x86_
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 n
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 woul
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
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 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.
> So,
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 implement
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 s
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 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 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, 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 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, 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, 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, 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 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 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 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 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 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 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 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 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 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
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, 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
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. T
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
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 thing
(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.
--
, 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
o tell whether you
tested it.
Best regards,
Alexander Monakov
bed in http://gcc.gnu.org/bugs/ . Posting bug reports to gcc-bugs@ does
not register them in the bugzilla, and thus is not recommended.
Thanks.
Alexander Monakov
break, which IMHO is fine.
--
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 tr
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 no
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.
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 * restr
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
>
On Thu, 11 Nov 2010, Ian Lance Taylor wrote:
> roy rosen 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 want GC
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
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 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
1 - 100 of 172 matches
Mail list logo
