On Wed, Mar 11, 2009 at 2:54 PM, Toon Moene wrote:
> ... and it had to be "fixed" 3-4 times by H.J.Lu before it went so obscure
> to only hit people like me.
>
> I run a weather forecasting system 4 times daily to test it out.
>
> Because GCC would-be-4.4 is in regression fixes only during the las
On Wed, Mar 11, 2009 at 4:20 PM, Toon Moene wrote:
> H.J. Lu wrote:
>
>> If you can provide a testcase, I can take a look. If it isn't easy to find
>> a testcase, please disable the second pattern:
>>
>> (define_peephole2
>> [(set (match_operand 0 "register_operand" "")
>> (match_operand 1
H.J. Lu wrote:
If you can provide a testcase, I can take a look. If it isn't easy to find
a testcase, please disable the second pattern:
(define_peephole2
[(set (match_operand 0 "register_operand" "")
(match_operand 1 "register_operand" ""))
(set (match_dup 0)
(m
> Timothy Madden wrote:
> > Hello
> >
> > Is -mfpmath=both for i386 and x86-64 still experimental in gcc 4.3, as
> > the in the online manual page ?
>
> Yes. It might (*might*) be better in GCC 4.4 thanks to the new register
> allocator, but it's unlikely that the manual page will be changed bef
On Wed, Mar 11, 2009 at 4:00 PM, Toon Moene wrote:
> Steven Bosscher wrote:
>
>> On Wed, Mar 11, 2009 at 11:20 PM, Toon Moene wrote:
>>>
>>> I will abide by the rules - but the rules also say that this is not the
>>> sort
>>> of "fix" that goes in at phase 4.
>>
>> Which rule where says so? Not i
Steven Bosscher wrote:
On Wed, Mar 11, 2009 at 11:20 PM, Toon Moene wrote:
I will abide by the rules - but the rules also say that this is not the sort
of "fix" that goes in at phase 4.
Which rule where says so? Not intended in an offensive manner -- just
curious. I'm not aware of any rules
On Wed, Mar 11, 2009 at 3:03 PM, Steven Bosscher wrote:
> On Wed, Mar 11, 2009 at 10:54 PM, Toon Moene wrote:
>> Unless a very good reason is in my inbox in the next 48 hours, I'll revert
>> this change under the obvious rule.
>
> It was a regression fix.
> See http://gcc.gnu.org/ml/gcc-patches/2
Snapshot gcc-4.2-20090311 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.2-20090311/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.2 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
On Wed, Mar 11, 2009 at 11:20 PM, Toon Moene wrote:
> I will abide by the rules - but the rules also say that this is not the sort
> of "fix" that goes in at phase 4.
Which rule where says so? Not intended in an offensive manner -- just
curious. I'm not aware of any rules that specify what kind o
On Wed, Mar 11, 2009 at 11:17 PM, Toon Moene wrote:
> Pffft - it was only a regression on optimization - note how many times HJL
> had to fix the fix before it became so obscure that only I could run into
> it.
>
> *This is not a regression fix, period.*
Well, the PR it was supposed to fix was ma
On Wed, Mar 11, 2009 at 11:20 PM, Toon Moene wrote:
> Richard Guenther wrote:
>
>> On Wed, Mar 11, 2009 at 10:54 PM, Toon Moene wrote:
>>>
>>> Unless a very good reason is in my inbox in the next 48 hours, I'll
>>> revert
>>> this change under the obvious rule.
>>
>> It doesn't work this way. Yo
Richard Guenther wrote:
On Wed, Mar 11, 2009 at 10:54 PM, Toon Moene wrote:
Unless a very good reason is in my inbox in the next 48 hours, I'll revert
this change under the obvious rule.
It doesn't work this way. You would need to start the 48h clock and have two
maintainers of the area app
Steven Bosscher wrote:
On Wed, Mar 11, 2009 at 10:54 PM, Toon Moene wrote:
Unless a very good reason is in my inbox in the next 48 hours, I'll revert
this change under the obvious rule.
It was a regression fix.
See http://gcc.gnu.org/ml/gcc-patches/2009-02/msg00299.html
Pffft - it was on
On Wed, Mar 11, 2009 at 10:54 PM, Toon Moene wrote:
> Unless a very good reason is in my inbox in the next 48 hours, I'll revert
> this change under the obvious rule.
It doesn't work this way. You would need to start the 48h clock and have two
maintainers of the area approve the revert after tha
On Wed, Mar 11, 2009 at 10:54 PM, Toon Moene wrote:
> Unless a very good reason is in my inbox in the next 48 hours, I'll revert
> this change under the obvious rule.
It was a regression fix.
See http://gcc.gnu.org/ml/gcc-patches/2009-02/msg00299.html
This took 2 minutes to find out. although it
... and it had to be "fixed" 3-4 times by H.J.Lu before it went so
obscure to only hit people like me.
I run a weather forecasting system 4 times daily to test it out.
Because GCC would-be-4.4 is in regression fixes only during the last
four months, I thought I could use it with impunity.
Un
Andreas Schwab writes:
> Etienne Lorrain writes:
>
>> Well, do I have any chance to have the 'asm (" %c0 ": : "" );' and
>> 'asm (" %a0 ": : "" );' documented if I submit a bug report?
>
> Those are already documented (*note (gccint)Output Template::).
But they aren't documented in the user ma
On Sun, 2009-03-08 at 22:45 +0100, Richard Guenther wrote:
> On Sun, Mar 8, 2009 at 10:19 PM, Laurent GUERBY wrote:
> > Hi,
> >
> > Trunk on armv5tel-linux-gnueabi (compile farm gcc50) currently fails
> > about 1000 C tests:
> >
> > http://gcc.gnu.org/ml/gcc-testresults/2009-03/msg00810.html
> >
>
Etienne Lorrain writes:
> Well, do I have any chance to have the 'asm (" %c0 ": : "" );' and
> 'asm (" %a0 ": : "" );' documented if I submit a bug report?
Those are already documented (*note (gccint)Output Template::).
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint =
Manuel López-Ibáñez wrote:
> Anything not documented there is likely to change or be removed in the
> future, so you should not rely on it. On the other hand, if you find
> some behaviour that you feel should be documented and it is not,
> please submit a documentation patch (or at least open a b
Hi, I'll be posting soon a series of patches labeled [cond-optab].
The aim of the series is to have all ports use cbranch+cstore+cmov
optabs instead of cmp/bcc/scc/movcc. As a starter, the first patches
I'll post will be cleaning up and centralizing the generation of cmp,
scc and bcc opcodes.
The
Stelian Pop wrote:
> Ok, so I ended up with (omitting the jump lengths for now):
>
> (define_insn "*jump"
> [(set (pc)
> (label_ref (match_operand 0 "" "")))
>(clobber (match_scratch:QI 1 "=&r"))]
> ""
> {
> return "ldih %1,hi(%l0)\n\t\n\tldil %1,lo(%l0)\n\tijmp (%1)";
>
Seongbae Park ??? ??? wrote:
This is the intended behavior, though now I see that the documentation
isn't very clear.
Can you fix the documentation? As it stands now, it is easy for a user
to be misguided into thinking -fprofile-arcs and fbranch-probabilities
combination would work.
Just out
On Wed, Mar 11, 2009 at 11:03:10AM +0100, Joel Porquet wrote:
> By default, the chosen tls model is "initial-exec", which causes one
> relocation for "b" (R_MIPS_TLS_TPREL32). If I specify "local-exec",
> the behavior is as expected, I get no relocation at all. But whenever
> I choose a dynamic mod
On Wed, 11 Mar 2009, Paul Brook wrote:
> PR23623 (I suspect the status on that bug is incorrect, it's nt actually
> fixed). The ARM EABI defines semantics for volatile bitfields, and gcc gets
> this wrong.
If the ARM EABI really documents the semantics for that,
implement-c.texi:Qualifiers does ne
Stelian Pop wrote:
> However, I didn't find a way to say to gcc that it cannot use the "direct"
> jump in some cases, and force it to use the "indirect_jump" instead.
>
>> I don't think it'll work to have a jump insn that is sometimes direct,
>> sometimes indirect.
>
>> Looking at how the rs
On Wed, 2009-03-11 at 01:05 -0400, DJ Delorie wrote:
> > Can you provide example code? I'm confused enough to believe
> > that you *should* get this effect with PCC_BITFIELD_TYPE_MATTERS
> > (modulo current bugs).
>
> Imagine a device with four 8-bit registers followed by a 32-bit
> register with
Tobias Grosser wrote on 10/03/2009 16:54:41:
> Hi Razya
>
> great to hear these Graphite plans. Some short comments.
Thanks :)
>
> On Tue, 2009-03-10 at 16:13 +0200, Razya Ladelsky wrote:
> > [...]
> >
> > The first step, as we see it, will teach Graphite that parallel code
needs
> > to be
On Tuesday 10 March 2009, DJ Delorie wrote:
> One of our customers has a chip with memory-mapped peripheral
> registers that need to be accessed in a specific mode. The registers
> represent bitfields within the hardware, so a volatile struct is an
> obvious choice to represent them in C.
>
> Comm
Dear GCC-list and Daniel,
Lately, I continued working on TLS for mips and a few things bother me.
Firstly, it seems the "-ftls-model" option for gcc is not completely
respected when compiling Position-Independent Executable ("-fpie").
Here is a sample of code for "app.c":
__thread int a = 0;
ext
On Wed, Mar 11, 2009 at 08:33:34AM +0100, Georg-Johann Lay wrote:
> Stelian Pop schrieb:
>> On Tue, Mar 10, 2009 at 10:18:10PM +0100, Georg-Johann Lay wrote:
>>
>>
>>> Note that no one is generating an insn that looks like "*jump". Maybe
>>> insn combine and peep2 would try to build such a patte
On Tuesday 10 March 2009 22:55:12 Joseph S. Myers wrote:
> On Tue, 10 Mar 2009, Mike Frysinger wrote:
> > On Tuesday 10 March 2009 21:44:23 Joseph S. Myers wrote:
> > > On Tue, 10 Mar 2009, Mike Frysinger wrote:
> > > > perhaps we need to extend the libgcc.map function to allow people to
> > > > in
Stelian Pop schrieb:
On Tue, Mar 10, 2009 at 10:18:10PM +0100, Georg-Johann Lay wrote:
Note that no one is generating an insn that looks like "*jump". Maybe
insn combine and peep2 would try to build such a pattern, but that is
not what helpd you out here. Write the expander as parallel of a
33 matches
Mail list logo
