On Thu, Jan 28, 2010 at 5:13 PM, Byron Stanoszek wrote:
> I've recently upgraded to GCC 4.3.2 from 4.2.2, and I noticed a strange
> change in how volatile bitmask structures are optimized.
>
> Consider the following code:
>
> /* 32-bit MMIO */
> struct hardware {
> int parm1:8;
> int :4;
> int
In PR target/42894 rguenth said:
> Only RMs may set priority.
I beg your pardon? Where in the docs does it say that?
R.
2010/1/18 Adam Nemet :
> fanqifei writes:
>> Paolo Bonzini said that insv instruction might be synthesized
>> later by combine. But combine only works on at most 3 instructions and
>> insv is not generated in such case.
>> So exactly when will the insv pattern be recognized and how does
>>
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
Steven Bosscher wrote:
>>> 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.
As a mere mortal I've used the priority setting combo
a few times to specify (perceived) priority, which late
On 01/29/2010 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?
>
Want to say two words about how I see these issues. Eventually, when the
time of releasing comes, only RMs, es
On 29/01/2010 10:29, Piotr Wyderski wrote:
> Anyway, speaking of reporting bugs: what's the rule of
> specifying CCs? Especially to the submitter himself?
> I would like to be aware of the status of several bugs,
> so may I add myself to the CC list? Or is it supposed
> to be used only by the fixe
On 01/29/2010 12:00 PM, Dave Korn wrote:
> I can't see any reason on earth not to CC yourself to any bug that you
> have
> even a passing interest in monitoring progress with, and regularly do it
> myself. Nobody's ever complained.
>
Sure. Maybe it's also worth reminding that submitters don't n
On 29/01/2010 10:12, Steven Bosscher wrote:
> 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 l
Paolo Carlini wrote:
> Sure. Maybe it's also worth reminding that submitters don't need to add
> explicitly themselves in CC.
It's the reason I asked -- I've been recently removed from CC.
So thanks for explanation.
Best regards
Piotr Wyderski
On Fri, Jan 29, 2010 at 11:29 AM, Piotr Wyderski
wrote:
> Steven Bosscher wrote:
>
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.
>
> As a mere mortal I've used the priority s
On 29/01/2010 11:03, Richard Guenther wrote:
> This should ideally be documented in
> http://gcc.gnu.org/bugs/management.html
Both the way that page is named, and the way the link to it is indented
under the link to the BZ frontpage in the side navbar on the gcc.gnu.org front
page, make it look
Paolo Carlini wrote:
> Thus, what's the point of submitter fiddling with those Bugzilla
> fields? Putting some sort of psychological pressure on people actually
> working on fixing the bugs?
Well, that's true when it comes to high priorities, but the
submitter should have the opportunity to speci
On Fri, Jan 29, 2010 at 12:26 PM, Dave Korn
wrote:
> On 29/01/2010 11:03, Richard Guenther wrote:
>
>> This should ideally be documented in
>> http://gcc.gnu.org/bugs/management.html
>
> Both the way that page is named, and the way the link to it is indented
> under the link to the BZ frontpage i
On Fri, 2010-01-29 at 12:24 +0100, Richard Guenther wrote:
> On Fri, Jan 29, 2010 at 12:26 PM, Dave Korn
> wrote:
> > On 29/01/2010 11:03, Richard Guenther wrote:
> >
> >> This should ideally be documented in
> >> http://gcc.gnu.org/bugs/management.html
> >
> > Both the way that page is named, a
On Fri, 2010-01-29 at 11:26 +, Dave Korn wrote:
> On 29/01/2010 11:03, Richard Guenther wrote:
>
> > This should ideally be documented in
> > http://gcc.gnu.org/bugs/management.html
>
> Both the way that page is named, and the way the link to it is indented
> under the link to the BZ front
On Fri, Jan 29, 2010 at 1:00 PM, Richard Earnshaw wrote:
>
> On Fri, 2010-01-29 at 12:24 +0100, Richard Guenther wrote:
>> On Fri, Jan 29, 2010 at 12:26 PM, Dave Korn
>> wrote:
>> > On 29/01/2010 11:03, Richard Guenther wrote:
>> >
>> >> This should ideally be documented in
>> >> http://gcc.gnu.o
On 29/01/2010 12:02, Richard Earnshaw wrote:
> We have three categories of users of BZ: RMs, Developers, and the rest.
> Developers are *not* the same as the rest and that extends beyond the
> ability to modify bug reports.
Ah, I may have overlooked something here; can the creator not adjust th
Hi,
I am working with gcc 4.4.2.
I installed the same on my machine using the following command lines.
1)To extract in a new directory,i used,
mkdir gcc1
cd gcc1
tar -xvf gcc-4.4.2.tar.gz
set srcdir = "/home/swati/gcc1/gcc-4.4.2"
set objdir = "/home/swati/gcc1/gcc-bin"
set insdir = "/home/swati
On Fri, 2010-01-29 at 12:25 +, Dave Korn wrote:
> On 29/01/2010 12:02, Richard Earnshaw wrote:
>
> > We have three categories of users of BZ: RMs, Developers, and the rest.
> > Developers are *not* the same as the rest and that extends beyond the
> > ability to modify bug reports.
>
> Ah,
2010/1/29 Richard Earnshaw :
>
> On Fri, 2010-01-29 at 12:25 +, Dave Korn wrote:
>> On 29/01/2010 12:02, Richard Earnshaw wrote:
>>
>> > We have three categories of users of BZ: RMs, Developers, and the rest.
>> > Developers are *not* the same as the rest and that extends beyond the
>> > abilit
Once my platforms are in reasonably good shape, I plan to go over old
bugzilla reports and handle them as appropriate. Due the the sheer
volume on gcc-bugs, it's impossible for me to even skim over the list.
Since any polling-based scheme to track new bug reports is doomed, I'd
like to get automat
swati raina writes:
> Now , i recompiled the gcc using following commands,
>
> 1)Changed to path to build directory,
>
> cd /home/swati/newgcc/objdir/build-i686-pc-linux-gnu/gcc/build/
>
> 2) Configured with --disable-bootstrap modification.
>
> /home/swati/newgcc/gcc-4.4.2/configure --disable-
Rainer Orth writes:
> Currently, http://gcc.gnu.org/bugs/management.html states:
>
> UNCONFIRMED
> The PR has been filed and the responsible person(s) notified.
>
> But how is this notification supposed to happen?
The theory is that the notification is based on the product and
component of t
Hey!
With my last patch, we only have 3 instances of dominator tree walks
left in the tree, all in the TM ipa pass.
I believe we can leave those as they are, since the TM ipa pass runs
early enough that nothing has altered control flow such that
code outside of a transaction ends up inside a tran
Hello everybody,
I'd like to patch gcc's sparc machine descritpion so
that the destination register of a fpu sqareroot operation fsqrts
is stored into memory after each fsqrts.
like this:
fsqrts %f2,%f4
st %f4, -4[%fp] <= add this after every fsqrts where -4[%fp] is
On Mon, Jan 25, 2010 at 8:12 PM, Ian Lance Taylor wrote:
> Timothy Madden writes:
>
>> On Fri, Jan 22, 2010 at 2:24 AM, Ian Lance Taylor wrote:
>>> Timothy Madden writes:
>>>
Why is it so hard to store template definitions (and the set of
symbols visible to them) in an
object fil
Timothy Madden writes:
> How long would it take for someone to understand how parsing works in
> g++ ? Or to understand the build system in gcc ?
I don't think you need to understand the build system to implement
export in C++. You do clearly need to understand the g++ frontend.
However, it's i
On 01/30/2010 01:14 AM, Ian Lance Taylor wrote:
> I don't think you need to understand the build system to implement
> export in C++. You do clearly need to understand the g++ frontend.
> However, it's impossible for me to estimate how long it would take
> somebody to understand it. It would depe
On Fri, Jan 29, 2010 at 8:05 PM, Paolo Carlini wrote:
> Even for implementors knowing *very* well both the details of the C++
> standard and the internals of a specific front-end, implementing export
> is an *highly* non-trivial task.
However, I have a gut feeling that at least a restricted versi
Paolo Carlini writes:
> On 01/30/2010 01:14 AM, Ian Lance Taylor wrote:
>> I don't think you need to understand the build system to implement
>> export in C++. You do clearly need to understand the g++ frontend.
>> However, it's impossible for me to estimate how long it would take
>> somebody to
On Fri, Jan 29, 2010 at 06:23:45PM -0800, Michael Witten wrote:
> On Fri, Jan 29, 2010 at 8:05 PM, Paolo Carlini
> wrote:
> > Even for implementors knowing *very* well both the details of the C++
> > standard and the internals of a specific front-end, implementing export
> > is an *highly* non-tr
32 matches
Mail list logo
