undefined.
For what it's worth, it annoys me to no end that you have managed to
turn more than a day of hard work to understand and fix PR24626 into
a discussion about defining undefined behavior. I don't think I'll
ever look at HPPA bugs anymore if they don't affect me.
Gr.
Steven
s a loop versioning bug papered over with a wrong fix.
It has absolutely _noting_ to do with unitialized variables or undefined
behavior. Nothing. Zilch. Zero.
Gr.
Steven
is tracking this issue. Hope you'll add your
thoughts so far, so that we can make some progress on getting a
PR GCC 4.1 regression fixed...
Gr.
Steven
On Sat, Jul 4, 2015 at 3:45 PM, Ajit Kumar Agarwal wrote:
> I am not sure why the above optimization is not implemented in GCC.
-fsplit-ivs-in-unroller
Ciao!
Steven
ource to 1.1MB preprocessed source after running delta a few times.
- Steven
On Tue, Nov 17, 2015 at 1:09 AM, Markus Trippelsdorf
wrote:
> On 2015.11.16 at 14:18 -0800, Steven Noonan wrote:
>> Hi folks,
>>
>> (I'm not subscribed to the list, so please CC me on all responses.)
>>
>> This is using GCC 5.2 on Linux x86_64. On a project
anonical form of
if blocks, the THEN_BB is the block reached via the fallthru edge
from TEST_BB. For the noce transformations, we allow the symmetric
form as well. */
bool then_else_reversed;
Ciao!
Steven
(NONJUMP_INSN_P (insn)
> && (! reload_completed
> || (GET_CODE (PATTERN (insn)) != USE
> && GET_CODE (PATTERN (insn)) != CLOBBER;
> }
>
> It is clear that someone [Steven Bosscher] thought it needs fixing but what's
> the prob
On Tue, Jun 10, 2014 at 10:46 AM, Linus Torvalds
wrote:
> On Tue, Jun 10, 2014 at 6:23 AM, Jiri Kosina wrote:
>> We have been chasing a memory corruption bug, which turned out to be
>> caused by very old gcc (4.3.4), which happily turned conditional load into
>> a non-conditional one, and that br
Hi GCC,
My name is Steven and I work for Go-Parts, an e-commerce company. We have
resources to spare, and have a very competent server admin team helping us
mirror open-source software.
We would now like to donate some mirrors (FTP, RSYNC, HTTP) in 4 different
geographic locations. We have
n we can make.
>>> >>
>>> >> Looking forward to gcc 10.0. :-)
>>> >
>>> > So are following what sun did?
>>>
>>> What does this have to do with sun?
>>>
>>
>> It's what sun did for Java and I think Solaris
>
> Did what?
Cut the major version number. Solaris 2.9 was marketed as Solaris 9.
Likewise for Solaris 2.10 and 2.11. They simply dropped the 2 from the
version number
Ciao!
Steven
n't know
about until RTL, like CFI) should be done at link time. Things like
scoping and types are language dependent and have to be generated
before streaming.
Again, sorry for not actually being helpful - just a thought ;-)
Ciao!
Steven
es, transitioning to
custom marking should be far easier.
Ciao!
Steven
to_inc_dec including expand should not generate
> AUTOINC expressions, otherwise it will break web.
IIRC, it used to be that only push/pop could be AUTOINC before
auto_inc_dec. I'm not sure if this is still true today.
Ciao!
Steven
rocker, but it's always been my understanding that almost all passes
handle AUTOINC just fine (or at least conservatively: punt if you see
an AUTOINC), and that only CSE really doesn't know about AUTOINC at
all.
Ciao!
Steven
pe? AFAIR this still isn't the default, even on
GNU/Linux, but it is typically a lot faster than without.
Ciao!
Steven
On Wed, Sep 24, 2014 at 11:47 PM, Ian Lance Taylor wrote:
> On Wed, Sep 24, 2014 at 10:04 AM, Steven Bosscher wrote:
>> Are you using -pipe? AFAIR this still isn't the default, even on
>> GNU/Linux, but it is typically a lot faster than without.
>
> Is that true even wh
n.c:handle_optimize_attribute.
Hope this helps. Thanks for all the work you're putting into this!
Ciao!
Steven
arse_optimize_options goes through the shared
option handling, and you need to re-setup the frontend_set_flag_*
flags manually somehow. Seems backward, though, but GDB should be able
to help you out (the flags after parse_optimize_options would be
different from the settings in the initial global_options).
Unfortunately I can't find if/where there is some explanation for
these frontend_set_flag_* options -- how they're supposed to work and
who's responsible for setting them.
Ciao!
Steven
m CC’ing the maintainers who added the optimize attribute in the first
>> place, as they might have an idea how to fix this. This is way beyond my
>> league!
Perhaps Joseph can help, in his position as maintainer of the option
handling subsystem.
Ciao!
Steven
for
performance of the produced code. Heuristics and theory are often not
on the same page, even if the heuristics are "rationalized". You
should just try and see what the effects are if you change something.
Ciao!
Steven
of data
structure. The splay tree will simply degenerate to a linked list. The
right thing to do would be, not to "break" one of the key features of
splay trees (i.e. the latest lookup is always on top), but to use
another data structure.
Ciao!
Steven
re are
> enough registers for pseudos but in reality it is wrong because of
> scratches in live range of the pseudos.
Is there a reason why IRA doesn't replace scratches with pseudos, like
LRA does (and IIRC reload does, also)?
Ciao!
Steven
_USED (ptr_var) = 1;
> varpool_node::finalize_decl (ptr_var);
This is wrong for sure. You can't have DECL_RTL in GIMPLE.
You will want to set has_local_explicit_reg_vars, DECL_HARD_REGISTER,
and DECL_ASSEMBLER_NAME, and leave it to the middle end to take care
of everything else.
Ciao!
Steven
F90-style array assignments to fused loops if it notices consecutive
array assignments/operations on the same variables.
Ciao!
Steven
there should be no unconditional
jumps to labels. The only JUMP_INSNs should be unconditional,
computed, or return jumps.
If you do have unconditional jumps at this stage, something is seriously broken.
Ciao!
Steven
03-07/msg00111.html :-)
Ciao!
Steven
5: NOTE_INSN_BASIC_BLOCK 5
23: ax:QI=r90:QI
24: use ax:QI
As noted earlier, this causes RTL if-conversion to fail.
Somewhat related to PR20070, but even with -fcrossjumping, the test
case fails. (I expected cross-jumping to merge the
"r90:QI=flags:CCZ!=0" insns.)
Ciao!
Steven
[ This is FYI only. Documenting what I found with gcc 4.5.1 (but is
fixed in 4.5.4 ]
Part of my test suit is to build the kernel with a compiler before asm
goto was supported (to test jump labels without it).
Recently I noticed that the kernel started to hang when building with
it. For a while
is still necessary. E.g. Uefi firmware
use both (-flto -Os) when GCC build. Only -flto + -Os can make Uefi frimware
GCC build be competivie with MSVS in terms of code size.
Steven
Thanks
suggests that, well, it worked.
This is not the limitation of Mach-O you are looking for.
Ciao!
Steven
On Sun, Mar 13, 2011 at 9:03 PM, Jack Howarth wrote:
> On Sun, Mar 13, 2011 at 08:42:58PM +0100, Steven Bosscher wrote:
>> (sorry Chris, I forgot the list)
>>
>> On Mar 13, 2011,@11:59 AM, Chris Lattner wrote:
>>
>> > Sorry, I actually mean 255 of course,
On Sun, Mar 13, 2011 at 9:41 PM, Jack Howarth wrote:
> On Sun, Mar 13, 2011 at 09:38:06PM +0100, Steven Bosscher wrote:
>> I agree it is probably better to re-code things, but that will be
>> impossible do before GCC 4.6 goes out.
>>
>> We have to make a decision: keep
than 24 hours on
any primary target. With proper notification to everyone involved,
obviously.
Thoughts?
Ciao!
Steven
GCC (hi!) and autotesters don't care if
it's weekend or not :-) You feel mobbed and I'm sorry you feel that
way, but it shows that a lot of people tried to work on GCC in that
weekend.
Ciao!
Steven
On Tue, Apr 5, 2011 at 12:43 PM, Bernd Schmidt wrote:
> On 04/05/2011 08:26 AM, Steven Bosscher wrote:
>> On Tue, Apr 5, 2011 at 3:14 AM, Bernd Schmidt
>> wrote:
>>
>>> For i686-linux bootstraps it's hard to argue against it, but in general
>>>
try to figure out the
problem before re-committing. That's also worked reliably in the past
(Vlad did so recentlty for his IRA improvements, for example) and
that's the decent thing to do. The whole policy we're discussing here
is a last resort.
Ciao!
Steven
On Tue, Apr 5, 2011 at 1:39 PM, Bernd Schmidt wrote:
> On 04/05/2011 08:26 AM, Steven Bosscher wrote:
>> I don't understand, really, why it's such a big deal to revert a patch
>> quickly if it broke something.
>
> To answer this as well, firstly a proposal that c
t's entirely possible that the
> offender has a life and didn't work over the weekend.
Hackers with a life?! :-)
Ciao!
Steven
hat they all agree to re-license their contributions under a license that
suits your needs. For what it's worth, I have absolutely no intention to
do so. I find the whole idea offensive, especially given the history of
Pathscale and of g95.
Ciao!
Steven
probably be
> equivalently implemented via outlining and function calls
> (I assume well back at the gimple level).
I guess the ipa-split pass could easily be modified to do this, it'd
just need a few new heuristics.
Ciao!
Steven
to me, I'll have a
closer look and I'll see if I can come up with a proper patch.
Ciao!
Steven
Index: cprop.c
===
--- cprop.c (revision 179480)
+++ cprop.c (working copy)
@@ -641,9 +641,33 @@
static vo
Hi,
Can anyone explain whether GCC has implemented Auto-Vectorization
based on Polyhedral Model?
Are there any related projects shooting at this, and in progress?
Steven.
/etc...).
You should use extra target files for language specific target code.
Plenty examples in config/*/*-c.* ...
Ciao!
Steven
plugin.
Huh, wait. I don't follow binutils much, but isn't the plugin only for
the gold linker?
Ciao!
Steven
the
compiler?
One reason to bring the warnings back could be that there is now no
way for anyone bootstrapping GCC to detect this warning. If it is
still a goal that recently modern GCC's should be able to build the
latest GCC, then it would be good if the latest GCC warns about the
same things in a given C dialect as older GCC versions do.
What to do?
Ciao!
Steven
On Thu, Dec 1, 2011 at 7:42 PM, Joseph S. Myers wrote:
> On Thu, 1 Dec 2011, Steven Bosscher wrote:
>
>> Is it valid in dialects older than C99 to declare a function static
>> inline after calling it? Should the warnings be brought back in the
>> compiler?
>
> Old
[r2] 4 [r4] 5 [r5] 6 [r6] 7 [r7] 15 [r15]
So when the CFG is still valid, r15 is live-out in basic block 2 and
live-in in basic block 3 (which contains insns 32, whatever that means
for an invalid CFG). For which bb does mark_target_live_regs call
df_get_live_in?
Ciao!
Steven
o make this a
happier crowd. :-)
> Steven Bosscher wrote:
>> So when the CFG is still valid, r15 is live-out in basic block 2 and
>> live-in in basic block 3 (which contains insns 32, whatever that means
>> for an invalid CFG). For which bb does mark_target_live_regs call
>&
is (are) causing
you trouble. You can then go through the other dumps (-da, which is
the same as -fdump-rtl-all) to see where the insn comes from.
Ciao!
Steven
On Mon, Jul 27, 2009 at 6:58 PM, Tim Crook wrote:
> Hi again Steven.
>
>
>
> I found a possible compiler workaround, compiling with –mminimal-toc. Would
> I get better performance by using this, instead of turning off gcse?
I have no idea, but one of the AIX maintainers can
gt;bicne r0, r0, #42
>biceq r0, r0, #42
>bx lr
> .L8:
>.word array
>
> Should I report a bug?
This looks like my bug PR21803 (gcc.gnu.org/PR21803). Can you check if
the ce3 pass creates this code? (Compile with -fdump-rtl-all and look
at the .ce3 dump and one dump before to see if the .ce3 pass created
your funny sequence.)
If your problem is indeed caused by the ce3 pass, you should add your
problem to PR21803, change the "Component" field to "middle-end", and
adjust the bug summary to make it clear that this is not ia64
specific.
Ciao!
Steven
On 7/30/09, Steven Bosscher wrote:
> On 7/30/09, Zoltán Kócsi wrote:
> > On the ARM every instruction can be executed conditionally. GCC very
> > cleverly uses this feature:
> >
> > int bar ( int x, int a, int b )
> > {
> > if ( x )
> >
>
oo specially ;-)
Alternatively, you could add a conditional call pattern and a
post-reload splitter to the ARM backend, and disallow the
EXIT_BLOCK_PTR as the JOIN-block in ifcvt.c.
Ciao!
Steven
dly GC / GTY (and, in fact PCH) code would go away
if RTL would just live on obstacks again.
(See for example all the GTY markers in the back ends. Most of them
are there only for PCH to get a consistent memory snap-shot, but PCHs
should be written out before any RTL is generated...)
Ciao!
Steven
t's an
interesting extension...).
This extension is not presently implemented in the FSF GCC.
AFAIU there is no reason to believe Apple will contribute patches to
implement it.
Is there even a formal spec for the language extension?
Ciao!
Steven
ost of the interesting new features are not yet described
in the changes.html for the upcoming release (see
http://gcc.gnu.org/gcc-4.5/changes.html).
Ciao!
Steven
ootstrap and if nobody objects in 24 hours.
I was just wondering why this is not a -f* flag, e.g. -fuse-linker-plugin?
Ciao!
Steven
3538, with libelfg0-0.8.10, libcloog-ppl-0.15, and
libppl-0.10, and configured with "../trunk/configure --prefix=/opt/
--disable-nls --enable-gold --enable-plugins --enable-lto
--with-libelf=/opt/ --enable-languages=c,fortran
--with-build-time-tools=/opt --enable-shared".
Am I the only one seeing this problem?
Ciao!
Steven
On Sun, Oct 25, 2009 at 12:18 PM, Richard Guenther
wrote:
> On Sun, Oct 25, 2009 at 12:08 PM, Steven Bosscher
> wrote:
>> Hi,
>>
>> I tried to bootstrap gcc this morning and got the following build failure:
>>
>> /home/stevenb/devel/build/./prev-gcc/xgcc
&
to config/sh will be an
> improvement for everybody.
Actually bt-load or something similar would be useful for at least one
other target, ia64.
Ciao,
Steven
rence for putative developpers (more precisely for their bosses).
...this. If you don't like to transfer copyright to the FSF, fine.
But don't expect the FSF GCC program (i.e. us) to assist you in
subverting itself.
Plugins should add special functionality that is needed for some niche
application of GCC, but not replace internals of GCC itself.
Ciao!
Steven
of years ago. I don't
think anyone has seriously worked with that to experiment with region
based compilation. But I guess it will be the Next Big Challange for
GCC, after LTO.
Ciao!
Steven
On Sat, Nov 14, 2009 at 11:12 PM, Richard Guenther
wrote:
> I don't even remember which other passes have this kind of cut-offs ..
At least CPROP, LCM-PRE, and HOIST (i.e. all passes in gcse.c), and
variable tracking.
Ciao!
Steven
On Thu, 2009-11-19 at 15:44 +, Andrew Haley wrote:
> Thomas Gleixner wrote:
> We're aligning the stack properly, as per the ABI requirements. Can't
> you just fix the tracer?
And how do we do that? The hooks that are in place have no idea of what
happened before they were called?
-- Steve
On Thu, 2009-11-19 at 15:44 +, Andrew Haley wrote:
> We're aligning the stack properly, as per the ABI requirements. Can't
> you just fix the tracer?
Unfortunately, this is the only fix we have:
diff --git a/kernel/trace/Kconfig b/kernel/trace/Kconfig
index b416512..cd39064 100644
--- a/ker
On Thu, 2009-11-19 at 09:39 -0800, Linus Torvalds wrote:
> > This modification leads to a hard to solve problem in the kernel
> > function graph tracer which assumes that the stack looks like:
> >
> >return address
> >saved ebp
>
> Umm. But it still does, doesn't it? That
>
>
On Thu, 2009-11-19 at 18:20 +, Andrew Haley wrote:
> OK, I found it. There is a struct defined as
>
> struct entry {
> ...
> } __attribute__((__aligned__((1 << (4);
>
> and then in timer_stats_update_stats you have a local variable of type
> struct entry:
>
> void timer_stats_update_s
On Thu, 2009-11-19 at 19:47 +0100, Ingo Molnar wrote:
> * Linus Torvalds wrote:
>
> > Admittedly, anybody who compiles with -pg probably doesn't care deeply
> > about smaller and more efficient code, since the mcount call overhead
> > tends to make the thing moot anyway, but it really looks lik
On Thu, 2009-11-19 at 11:10 -0800, David Daney wrote:
> Linus Torvalds wrote:
> For the MIPS port of GCC and Linux I recently added the
> -mmcount-ra-address switch. It causes the location of the return
> address (on the stack) to be passed to mcount in a scratch register.
Hehe, scratch regist
On Thu, 2009-11-19 at 20:46 +0100, Frederic Weisbecker wrote:
> On Thu, Nov 19, 2009 at 02:28:06PM -0500, Steven Rostedt wrote:
> > :
> > call __fentry__
> > [...]
> >
> >
> > -- Steve
>
>
> I would really like
On Thu, 2009-11-19 at 11:50 -0800, H. Peter Anvin wrote:
> > Perhaps we could create another profiler? Instead of calling mcount,
> > call a new function: __fentry__ or something. Have it activated with
> > another switch. This could make the performance of the function tracer
> > even better with
On Thu, 2009-11-19 at 15:05 -0500, Steven Rostedt wrote:
> Well, other archs use a register to store the return address. But it
> would also be easy to do (pseudo arch assembly):
>
> :
> mov lr, (%sp)
> add 8, %sp
> blr __f
On Thu, 2009-11-19 at 12:36 -0800, Linus Torvalds wrote:
>
> On Thu, 19 Nov 2009, Frederic Weisbecker wrote:
> >
> > > That way the lr would have the current function, and the parent would
> > > still be at 8(%sp)
> >
> > Yeah right, we need at least such very tiny prologue for
> > archs that sto
On Thu, 2009-11-19 at 14:25 -0700, Jeff Law wrote:
> Having said all that, I don't expect to personally be looking at the
> problem, given the list of other codegen issues that need to be looked
> at (reload in particular), profiling/stack interactions would be around
> 87 millionth on my list.
an be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-2.6-trace.git
tip/tracing/urgent-2
Steven Rostedt (1):
tracing/x86: Add check to detect GCC messing with mcount prologue
kernel/trace/Kconfig|1 -
scripts/Makefile.build | 25 +++-
sc
This touches the Makefile scripts. I forgot to CC kbuild and Sam.
-- Steve
On Fri, 2009-11-20 at 00:23 -0500, Steven Rostedt wrote:
> Ingo,
>
> Not sure if this is too much for this late in the -rc game, but it finds
> the gcc bug at build time, and we don't need to disab
On Fri, 2009-11-20 at 10:57 +0100, Andi Kleen wrote:
> Steven Rostedt writes:
> >
> > And frame pointers do add a little overhead as well. Too bad the mcount
> > ABI wasn't something like this:
> >
> >
> > :
> > callmcount
&g
Ingo, Thomas and Linus,
I know Thomas did a patch to force the -mtune=generic, but just in case
gcc decides to do something crazy again, this patch will catch it.
Should we try to get this in now?
-- Steve
On Fri, 2009-11-20 at 00:23 -0500, Steven Rostedt wrote:
> com
On Fri, 2009-11-20 at 19:35 +, Andrew Haley wrote:
> Steven Rostedt wrote:
> > Ingo, Thomas and Linus,
> >
> > I know Thomas did a patch to force the -mtune=generic, but just in case
> > gcc decides to do something crazy again, this patch will catch it.
> >
On Tue, 2009-11-24 at 17:12 +, Andrew Haley wrote:
> H. Peter Anvin wrote:
> > If we're changing gcc anyway, then let's add the option of intercepting
> > the function at the point where the machine state is well-defined by
> > ABI, which is before the function stack frame is set up.
>
> Hmm.
lready existed a few years ago (IIRC Haifa had something
that Dan picked up and passed on to me). But it never brought any
benefits. I don't have the pass anymore, but perhaps Dan still has a
copy of it somewhere.
Ciao!
Steven
On Mon, Nov 30, 2009 at 12:40 AM, Daniel Berlin wrote:
> This pass may even be on the lno branch or something.
It used to be, at least, see http://gcc.gnu.org/ml/gcc-cvs/2004-08/msg00470.html
Happy hacking, Toon :-)
Ciao!
Steven
ate that the intraprocedural
version would do any good.
Ciao!
Steven
of undefined code are not going to give useful comparisons.
Ciao!
Steven
-archive.com/debian-...@lists.debian.org/msg32172.html
and from there to http://gcc.gnu.org/PR36765. But that doesn't look
like the right bug.
A search on all bugs (open and closed) in GCC bugzilla also gives no
useful results.
It looks like this was never even filed in GCC bugzilla...?
Ciao!
St
On Mon, Nov 30, 2009 at 12:10 PM, Steven Bosscher wrote:
> I'll see if I can make the intraprocedural version work again before
> Christmass.
Well, it works, but then again it really does not. For example, the
original implementation doesn't even look at the alignment of &
On Sat, Dec 19, 2009 at 11:43 PM, Daniel Berlin wrote:
> On Sat, Dec 19, 2009 at 2:48 PM, Steven Bosscher
> wrote:
>> On Mon, Nov 30, 2009 at 12:10 PM, Steven Bosscher
>> wrote:
>>> I'll see if I can make the intraprocedural version work again before
>>&
On Wed, Dec 23, 2009 at 12:49 PM, Bingfeng Mei wrote:
> Hello,
> I encounter an issue with PRE optimization, which created worse
Is this at -O2 or -O3?
Ciao!
Steven
(http://gcc.gnu.org/ml/gcc/2009-11/msg00047.html).
Could someone with experience in debugging lto1 perhaps add a HOWTO
for this on the Wiki?
Thanks,
Ciao!
Steven
On Tue, Dec 29, 2009 at 5:41 PM, Rafael Espindola wrote:
> 2009/12/29 Steven Bosscher :
>> Hi,
>>
>> I am trying to see what is going on in lto1 for PR lto/42534. I can
>> reproduce the reported ICE but I can't reproduce it inside gdb to see
>> what is ha
(gmsgid=0x4164a460 "could not parse hex
number") at ../../trunk/gcc/diagnostic.c:672
#1 0x400e5b70 in lto_parse_hex (p=0x6fe43957
"mp/cc9NtICT") at ../../trunk/gcc/lto/lto.c:268
#2 0x400f6230 in lto_elf_file_open
(filename=0x6fe43954 "@/tmp/cc9NtICT", writable=0 '\0')
at ../../trunk/gcc/lto/lto-elf.c:563
#3 0x400f1c80 in lto_read_all_file_options () at
../../trunk/gcc/lto/lto.c:1748
#4 0x400c3210 in lto_post_options
(pfilename=0x600995f8) at ../../trunk/gcc/lto/lto-lang.c:669
#5 0x40ab76b0 in process_options () at ../../trunk/gcc/toplev.c:1788
#6 0x40aba220 in do_compile () at ../../trunk/gcc/toplev.c:2371
#7 0x40aba5f0 in toplev_main (argc=11,
argv=0x6fe43698) at ../../trunk/gcc/toplev.c:2429
#8 0x400f97e0 in main (argc=11, argv=0x6fe43698) at
../../trunk/gcc/main.c:35
(gdb)
Hope this helps...
Ciao!
Steven
menting and maintainability).
>
> This is very strange. On x86_64, gcc 4.4.1 generates
>
> movl $7170, %eax
> ret
>
> This optimization is done by the first RTL cse pass. I can't understand
> why it's not being done for your target. I guess this will need a
> powerpc expert.
Known bug, see http://gcc.gnu.org/PR22141
I hope Jakub will finish this work for gcc 4.5.
Ciao!
Steven
nd src checked out yesterday
(top of src/Changelog is the fix from Kaveh and FX for gcc PR42424).
Not knowing a thing about libtool, I hope someone can tell me what's
wrong here ;-)
Ciao!
Steven
ially when y is not known at compile time, this will provide a
> significant performance increase.
I think this issue is known in Bugzilla as http://gcc.gnu.org/PR25671.
Ciao!
Steven
from VBEOUT in compute_vbeinout? Would it be OK if I teach
compute_vbeinout to eliminate expressions that may trap from VEBOUT,
if there are exception edges to successor blocks? This is similar to
what LCM-PRE does in compute_pre_data (well, more or less, sort-of,
etc.).
Hope you can help me understand this code better,
Ciao!
Steven
On Fri, Jan 29, 2010 at 11:09 AM, Richard Earnshaw wrote:
> In PR target/42894 rguenth said:
>> Only RMs may set priority.
>
> I beg your pardon? Where in the docs does it say that?
I don't know that, but it's been discussed many times on this list.
Ciao!
Steven
Hi,
Mark just made an ICE in the compiler with non-default options a P1
bug for GCC 4.5 (xf.
http://gcc.gnu.org/ml/gcc-bugs/2010-02/msg01695.html).
Can someone please explain why this kind of bug should be of
release-blocking priority?
Thanks,
Ciao!
Steven
should be on that user.
In this case of the i386 back end, that probably means changing the
default to something like pentium3.
Ciao!
Steven
401 - 500 of 1056 matches
Mail list logo
