Jason Merrill wrote:
On Thu, 24 Mar 2005 11:29:09 -0800, Mark Mitchell <[EMAIL PROTECTED]> wrote:
19317 C++ problems with temporary return values
This patch breaks Qt builds. One of my patches is implicated, but I
believe that the consensus is that this is an NRV bug. Jason made
several attem
On Thu, 24 Mar 2005 11:29:09 -0800, Mark Mitchell <[EMAIL PROTECTED]> wrote:
> 19317 C++ problems with temporary return values
>
> This patch breaks Qt builds. One of my patches is implicated, but I
> believe that the consensus is that this is an NRV bug. Jason made
> several attempts at f
> I'm a little concerned about the fact that (in theory) DECL_NAME could
> have spaces, or other assembler-unfriendly characters. I'm not sure
> what to do in that circumstance; it's probably impossible to do anything
> better than we do now, without the assembler providing some kind of
> special
Eric Botcazou wrote:
OK. (FWIW, you're not on the CC: list for that PR either.)
Sorry, I only wanted to explain why the patch is still pending. About your
question: am I right in thinking that the real name is the name as written
in the assembly file? If so, that's what is now implemented in
> OK. (FWIW, you're not on the CC: list for that PR either.)
No, but I'm the assignee so... :-)
> > Note that the patch has been approved by Roger for 4.x, so it should
> > already have been checked in, had I not run into technical contingencies
> > lately.
>
> Great; I shan't second-guess then.
Eric Botcazou wrote:
20263 SPARC64 ASM bug
Eric has a patch; I've asked about possible other ways to fix it.
I've answered, but probably not very constructively as your remark was not
crystal-clear either. :-) Btw, I think you should "Add CC" you when you
comment on specific PRs in order to spe
> 20263 SPARC64 ASM bug
>
> Eric has a patch; I've asked about possible other ways to fix it.
I've answered, but probably not very constructively as your remark was not
crystal-clear either. :-) Btw, I think you should "Add CC" you when you
comment on specific PRs in order to speed up the disc
Daniel Berlin wrote:
Truly Critical
--
19225 Segmentation fault with VLAs, affects GLIBC
This is the TYPE_STUB_DECL that Dan Berlin looked into for a while.
What is the current status?
I think you mean 19345.
Anyway, the long and short of it is that the real bug here is that
TYPE_NAM
Richard Henderson wrote:
On Thu, Mar 24, 2005 at 09:27:37PM +, Joseph S. Myers wrote:
Undefined behavior on execution, not on translation.
It's still a stretch on the word "valid".
It's probably reasonable to say that this is not absolutely a
showstopper, as well-written code presumably won't
On Mar 24, 2005, at 3:08 PM, James E Wilson wrote:
Richard Henderson wrote:
19255 EH bug on IA32 when using heavy optimization
Typo in pr number?
I think that is supposed to be 19225, for which I have already
suggested a solution though not a patch (disable deferred argument
popping when a call c
Richard Henderson wrote:
19255 EH bug on IA32 when using heavy optimization
Typo in pr number?
I think that is supposed to be 19225, for which I have already suggested
a solution though not a patch (disable deferred argument popping when a
call can throw). It isn't marked critical though, so I d
On Thu, Mar 24, 2005 at 09:27:37PM +, Joseph S. Myers wrote:
> Undefined behavior on execution, not on translation.
It's still a stretch on the word "valid".
r~
On Thu, 24 Mar 2005, Richard Henderson wrote:
> On Thu, Mar 24, 2005 at 11:29:09AM -0800, Mark Mitchell wrote:
> > 17855 ICE on C code that modifies call return values
> >
> > RTH and Joseph looked at this; no fix yet.
>
> I'm not sure why this is marked as ice-on-valid; the construct in
> que
On Thu, Mar 24, 2005 at 11:29:09AM -0800, Mark Mitchell wrote:
> 17855 ICE on C code that modifies call return values
>
> RTH and Joseph looked at this; no fix yet.
I'm not sure why this is marked as ice-on-valid; the construct in
question has undefined behaviour.
> 20342 ICE in reload w/ SSE/
> Truly Critical
> --
>
> 19225 Segmentation fault with VLAs, affects GLIBC
>
> This is the TYPE_STUB_DECL that Dan Berlin looked into for a while.
> What is the current status?
I think you mean 19345.
Anyway, the long and short of it is that the real bug here is that
TYPE_NAME
[If you're in the explicit CC: list for this mail, I've mentioned you
explicitly below, and I'm hoping that you'll be able to provide me
some feedback.]
I've looked through the 36 critical (i.e., wrong-code, ice-on-valid, or
rejects-valid) regressions open against 4.0. They are categorized
below
16 matches
Mail list logo
