--- Additional Comments From aoliva at gcc dot gnu dot org 2005-02-17
16:17 ---
Subject: [PR c++/20008, middle-end] handle switch with all cases out-of-range
Sure enough, the testcase relied on undefined behavior, but that's no
reason for us to ICE at compile time. I suppose it might b
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-02-21
19:30 ---
Subject: [PR tree-optimization/19786] fix alias grouping lossage
The problem here was that we added type tags to other tag's may-alias
lists without adding them to the corresponding bitmaps. Later on,
when
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-03-01
22:27 ---
Subject: [PR libgcj/20160] rename archive members with duplicate basenames
The archives created for libjava are broken, in that some of the
object files that should go into it are missing. That's because AR
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-03-03
07:42 ---
Subject: [PR c++/20103] failure to gimplify constructors for addressable types
In the reduced testcase from the bug report, included in the patch
file below, we fail to gimplify the CONSTRUCTOR created for t
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-03-03
07:51 ---
Subject: [PR c++/20280] hoist indirect_ref out of addressable cond_exprs
When passing an lvalue cond_expr to a function taking a reference that
binds directly to either operand of ?:, we'd fail gimplificatio
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-03-04
06:01 ---
Subject: Re: [PR c++/20280] hoist indirect_ref out of addressable cond_exprs
On Mar 3, 2005, Mark Mitchell <[EMAIL PROTECTED]> wrote:
> Alexandre Oliva wrote:
> \
>> I went ahead and verified that I didn't
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-03-04
06:34 ---
Subject: Re: [PR c++/20280] hoist indirect_ref out of addressable cond_exprs
On Mar 3, 2005, Andrew Pinski <[EMAIL PROTECTED]> wrote:
> On Mar 3, 2005, at 2:50 AM, Alexandre Oliva wrote:
>> I'm bootstrapp
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-03-04
06:59 ---
Subject: Re: [PR c++/20280] hoist indirect_ref out of addressable cond_exprs
On Mar 4, 2005, Alexandre Oliva <[EMAIL PROTECTED]> wrote:
>> we should be doing the same for all types (well except for
>> bitf
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-03-04
19:08 ---
Subject: [PR c++/19199] don't turn cond_expr lvalue into min_expr rvalue
(continued from PR c++/20280)
On Mar 4, 2005, Mark Mitchell <[EMAIL PROTECTED]> wrote:
> Actually, looking at this more clos
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-03-04
19:23 ---
Subject: Re: [PR c++/20280] hoist indirect_ref out of addressable cond_exprs
On Mar 4, 2005, Mark Mitchell <[EMAIL PROTECTED]> wrote:
> Your reading is logical, but it depends on exactly what "lvalue for a
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-03-04
23:22 ---
Subject: Re: [PR c++/20103] failure to gimplify constructors for addressable
types
On Mar 3, 2005, Andrew Pinski <[EMAIL PROTECTED]> wrote:
> I think this is the wrong approach. The front-end and not
> t
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-03-05
13:36 ---
Subject: Re: [PR c++/20103] failure to gimplify constructors for addressable
types
On Mar 4, 2005, Mark Mitchell <[EMAIL PROTECTED]> wrote:
>> +foo ((B){x});
> I don't think (B){x} should be an lvalu
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-03-05
14:03 ---
Subject: Re: [PR c++/20103] failure to gimplify constructors for addressable
types
On Mar 5, 2005, Alexandre Oliva <[EMAIL PROTECTED]> wrote:
> On Mar 4, 2005, Mark Mitchell <[EMAIL PROTECTED]> wrote:
>>
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-03-06
07:29 ---
Subject: Re: [PR c++/20103] failure to gimplify constructors for addressable
types
On Mar 5, 2005, Mark Mitchell <[EMAIL PROTECTED]> wrote:
> Alexandre Oliva wrote:
>> Testing now. I was a bit surprised
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-03-07
03:26 ---
Subject: Re: [PR c++/20103] failure to gimplify constructors for addressable
types
On Mar 6, 2005, Mark Mitchell <[EMAIL PROTECTED]> wrote:
> Alexandre Oliva wrote:
>> +case TARGET_EXPR:
>> + {
>
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-03-07
03:28 ---
Subject: Re: [PR c++/19199] don't turn cond_expr lvalue into min_expr rvalue
(continued from PR c++/20280)
On Mar 5, 2005, Mark Mitchell <[EMAIL PROTECTED]> wrote:
> Roger has objected to this change in t
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-03-07
14:44 ---
Subject: Re: [PR c++/20103] failure to gimplify constructors for addressable
types
On Mar 7, 2005, Mark Mitchell <[EMAIL PROTECTED]> wrote:
> Alexandre Oliva wrote:
>>> This doesn't look quite right. Fir
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-03-07
17:05 ---
Subject: Re: [PR c++/20103] failure to gimplify constructors for addressable
types
On Mar 7, 2005, Mark Mitchell <[EMAIL PROTECTED]> wrote:
> Are you sure that we can use TARGET_EXPR as a type-conversion
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-03-07
21:57 ---
Subject: [PR target/20126, RFC] loop DEST_ADDR biv replacement may fail
loop attempts to eliminate a biv represented by a pseudo in favor of a
giv represented by (plus (reg) (const_int -1)). Unfortunately,
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-03-07
21:58 ---
Subject: Re: [PR c++/20103] failure to gimplify constructors for addressable
types
On Mar 7, 2005, Mark Mitchell <[EMAIL PROTECTED]> wrote:
>>> The games that you want to play with type-equality are just
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-03-08
07:24 ---
Subject: Re: [PR c++/20103] failure to gimplify constructors for addressable
types
On Mar 7, 2005, Mark Mitchell <[EMAIL PROTECTED]> wrote:
> (a) we should never use "==" to compare types, because there's
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-03-08
20:44 ---
Subject: Re: [PR c++/20103] failure to gimplify constructors for addressable
types
On Mar 8, 2005, Mark Mitchell <[EMAIL PROTECTED]> wrote:
> No, because there would be no TARGET_EXPR. In a template, you
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-03-08
21:55 ---
Subject: Re: [PR c++/20103] failure to gimplify constructors for addressable
types
On Mar 8, 2005, Alexandre Oliva <[EMAIL PROTECTED]> wrote:
> Okie dokie, how about this?
> The change to the gimplify.c
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-03-08
23:23 ---
Subject: Re: [3.3/3.4/4.0/4.1 Regression] Wrong warning about returning a
reference to a temporary
On Mar 7, 2005, Roger Sayle <[EMAIL PROTECTED]> wrote:
> For example, I believe that Alex's proposed sol
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-03-09
04:02 ---
Subject: Re: [PR target/20126, RFC] loop DEST_ADDR biv replacement may fail
On Mar 8, 2005, Jakub Jelinek <[EMAIL PROTECTED]> wrote:
> Unfortunately, it seems to break ada bootstrap on at least x86-64 and
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-03-09
04:11 ---
Subject: Re: [3.3/3.4/4.0/4.1 Regression] Wrong warning about returning a
reference to a temporary
On Mar 8, 2005, Roger Sayle <[EMAIL PROTECTED]> wrote:
> On 8 Mar 2005, Alexandre Oliva wrote:
>>
>> *
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-03-09
10:30 ---
Subject: [PR middle-end/18628] do not fold to label load from tablejump to reg
This patch is meant to implement suggestion #3 proposed to fix the bug
by Roger Sayle and selected by RTH in bugzilla. So far,
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-03-10
11:44 ---
Subject: Re: [PR target/20126, RFC] loop DEST_ADDR biv replacement may fail
On Mar 9, 2005, Jakub Jelinek <[EMAIL PROTECTED]> wrote:
> On Wed, Mar 09, 2005 at 01:02:08AM -0300, Alexandre Oliva wrote:
>> On
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-03-10
20:38 ---
Subject: Re: [PR middle-end/18628] do not fold to label load from tablejump to
reg
On Mar 10, 2005, Richard Henderson <[EMAIL PROTECTED]> wrote:
> On Wed, Mar 09, 2005 at 07:26:37AM -0300, Alexandre Oliva
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-03-11
14:29 ---
Subject: Re: [PR target/20126, RFC] loop DEST_ADDR biv replacement may fail
On Mar 10, 2005, Alexandre Oliva <[EMAIL PROTECTED]> wrote:
> + ??? Should this should search new for new volatile MEMs and reje
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-03-11
19:29 ---
Subject: Re: [PR c++/20103] failure to gimplify constructors for addressable
types
On Mar 11, 2005, Richard Henderson <[EMAIL PROTECTED]> wrote:
> On Tue, Mar 08, 2005 at 05:42:57PM -0300, Alexandre Oliva
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-03-17
10:36 ---
Subject: Re: [PR c++/20103] failure to gimplify constructors for addressable
types
On Mar 11, 2005, Alexandre Oliva <[EMAIL PROTECTED]> wrote:
> gimplify_and_add calls gimplify_stmt for the stmt list, that
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-03-18
05:38 ---
Subject: Re: [PR c++/20103] failure to gimplify constructors for addressable
types
On Mar 17, 2005, Richard Henderson <[EMAIL PROTECTED]> wrote:
> On Thu, Mar 17, 2005 at 05:11:08AM -0300, Alexandre Oliva
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-03-18
10:14 ---
Subject: Re: [PR c++/20103] failure to gimplify constructors for addressable
types
On Mar 18, 2005, Alexandre Oliva <[EMAIL PROTECTED]> wrote:
> On Mar 17, 2005, Richard Henderson <[EMAIL PROTECTED]> wrote
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-03-20
18:34 ---
Subject: [PR rtl-optimization/20290] loop body doesn't run in every iteration
if exit test is the loop entry point
Tree loop optimizations transform the second loop in main() in the
attached testcase in a l
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-03-23
02:41 ---
Subject: [PR rtl-optimization/20532] plus(ashift,ashift) -> mult may overflow
In the sample testcase, if HOST_WIDE_INT is 32-bits wide, we ended up
trying to simplify the two shifts into a single multiply.
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-03-24
09:25 ---
Subject: [PR middle-end/20491] combine generates bad subregs
Combine doesn't ensure the subregs it generates are valid. In most
cases, insn recog will reject the invalid subregs, or reload will
somehow make
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-03-24
10:46 ---
Subject: Re: [PR middle-end/20491] combine generates bad subregs
On Mar 24, 2005, Alexandre Oliva <[EMAIL PROTECTED]> wrote:
> Combine doesn't ensure the subregs it generates are valid. In most
> cases, in
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-03-25
13:41 ---
Subject: Re: [PR middle-end/20491] combine generates bad subregs
On Mar 24, 2005, [EMAIL PROTECTED] (Richard Kenner) wrote:
> Combine doesn't ensure the subregs it generates are valid. In most
> ca
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-03-29
21:48 ---
Subject: Re: [PR middle-end/20491] combine generates bad subregs
On Mar 28, 2005, Richard Henderson <[EMAIL PROTECTED]> wrote:
> On Thu, Mar 24, 2005 at 07:45:44AM -0300, Alexandre Oliva wrote:
>> * combine
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-03-30
05:56 ---
Subject: [PR tree-optimization/20460] add phi args to dests of dce-redirected
edges
When remove_dead_stmt() redirects a control stmt, the edge redirection
reserves space for the phi arg for the new incoming
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-03-30
19:28 ---
Subject: Re: [PR middle-end/20491] combine generates bad subregs
On Mar 29, 2005, Alexandre Oliva <[EMAIL PROTECTED]> wrote:
> On Mar 28, 2005, Richard Henderson <[EMAIL PROTECTED]> wrote:
>> On Thu, Mar 24
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-03-31
08:28 ---
Subject: Re: [PR tree-optimization/20640] add phi args to dests of
dce-redirected edges
On Mar 31, 2005, Alexandre Oliva <[EMAIL PROTECTED]> wrote:
> I have a gut feeling that we'll always get a PHI arg fr
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-03-31
08:41 ---
Subject: Re: [PR tree-optimization/20640] add phi args to dests of
dce-redirected edges
On Mar 30, 2005, Jeffrey A Law <[EMAIL PROTECTED]> wrote:
> - PENDING_STMT (EDGE_SUCC (bb, 0)) = NULL;
> +
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-03-31
20:47 ---
Subject: [PR debug/19345] remap TYPE_STUB_DECL during inlining
TYPE_STUB_DECL was NULL in the testcase given in the bug report
because tree inlining failed to remap TYPE_STUB_DECL. This patch
reverts the pa
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-04-01
00:37 ---
Subject: Re: [PR debug/19345] remap TYPE_STUB_DECL during inlining
On Mar 31, 2005, Daniel Berlin <[EMAIL PROTECTED]> wrote:
> Did i check it in, or someone else?
You did, along with the patch mentioned in
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-04-02
16:57 ---
Subject: Re: [PR middle-end/20491] combine generates bad subregs
On Mar 31, 2005, Richard Henderson <[EMAIL PROTECTED]> wrote:
> On Wed, Mar 30, 2005 at 04:27:50PM -0300, Alexandre Oliva wrote:
>> - el
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-04-02
16:59 ---
Subject: Re: [PR tree-optimization/20640] add phi args to dests of
dce-redirected edges
On Mar 31, 2005, Jeffrey A Law <[EMAIL PROTECTED]> wrote:
> On Thu, 2005-03-31 at 05:26 -0300, Alexandre Oliva wrote:
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-04-02
17:22 ---
Subject: Re: [PR target/20126, RFC] loop DEST_ADDR biv replacement may fail
On Mar 11, 2005, Alexandre Oliva <[EMAIL PROTECTED]> wrote:
> On Mar 10, 2005, Alexandre Oliva <[EMAIL PROTECTED]> wrote:
>> + ?
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-04-02
17:27 ---
Subject: Re: [PR c++/20103] failure to gimplify constructors for addressable
types
On Mar 18, 2005, Alexandre Oliva <[EMAIL PROTECTED]> wrote:
> Index: gcc/ChangeLog
> from Alexandre Oliva <[EMAIL PROTEC
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-04-02
17:29 ---
Subject: Re: [3.3/3.4/4.0/4.1 Regression] Wrong warning about returning a
reference to a temporary
On Mar 9, 2005, Alexandre Oliva <[EMAIL PROTECTED]> wrote:
> PR c++/19199
> * fold-const.c (
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-04-04
13:32 ---
Subject: Re: [Committed] PR c++/19199: Preserve COND_EXPR lvalueness in fold
On Apr 4, 2005, Roger Sayle <[EMAIL PROTECTED]> wrote:
> (fold_cond_expr_with_comparison): Preserve lvalue-ness for the
>
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-04-04
13:50 ---
Subject: Re: [Committed] PR c++/19199: Preserve COND_EXPR lvalueness in fold
On Apr 4, 2005, Alexandre Oliva <[EMAIL PROTECTED]> wrote:
> On Apr 4, 2005, Roger Sayle <[EMAIL PROTECTED]> wrote:
>> long-te
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-04-04
15:02 ---
Subject: Re: [Committed] PR c++/19199: Preserve COND_EXPR lvalueness in fold
On Apr 4, 2005, Alexandre Oliva <[EMAIL PROTECTED]> wrote:
> + result. We may still return other expressions that would be
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-04-04
20:18 ---
Subject: Re: [Committed] PR c++/19199: Preserve COND_EXPR lvalueness in fold
On Apr 4, 2005, Roger Sayle <[EMAIL PROTECTED]> wrote:
> My apologies yet again for not being more explicit about all of the
> t
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-04-08
16:34 ---
Subject: Re: [PR target/20126, RFC] loop DEST_ADDR biv replacement may fail
On Mar 11, 2005, Alexandre Oliva <[EMAIL PROTECTED]> wrote:
> On Mar 10, 2005, Alexandre Oliva <[EMAIL PROTECTED]> wrote:
>> + ?
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-04-08
20:51 ---
Subject: Re: [PR target/20126, RFC] loop DEST_ADDR biv replacement may fail
On Apr 8, 2005, Roger Sayle <[EMAIL PROTECTED]> wrote:
> Ahh, I now see the misunderstanding; you changed/fixed the other
> "safe
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-04-10
02:43 ---
Subject: Re: [PR target/20126, RFC] loop DEST_ADDR biv replacement may fail
On Apr 8, 2005, Roger Sayle <[EMAIL PROTECTED]> wrote:
> ++ /* If there isn't a volatile MEM, there's nothing we can do. */
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-04-11
03:51 ---
Subject: Re: [PR target/20126, RFC] loop DEST_ADDR biv replacement may fail
On Apr 10, 2005, Mark Mitchell <[EMAIL PROTECTED]> wrote:
> Thanks for alerting me to this one; it does look relatively
> serious.
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-04-12
03:35 ---
Subject: Re: [PR target/20126, RFC] loop DEST_ADDR biv replacement may fail
On Apr 11, 2005, Josh Conner <[EMAIL PROTECTED]> wrote:
> I'm now getting a ICE building the mainline (please ignore the
> "3.4.3"
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-04-12
06:58 ---
Subject: Re: [PR target/20126, RFC] loop DEST_ADDR biv replacement may fail
On Apr 12, 2005, Alexandre Oliva <[EMAIL PROTECTED]> wrote:
> On Apr 11, 2005, Josh Conner <[EMAIL PROTECTED]> wrote:
>> I'm now g
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-04-12
08:19 ---
Subject: Re: [PR target/20126, RFC] loop DEST_ADDR biv replacement may fail
On Apr 12, 2005, Alexandre Oliva <[EMAIL PROTECTED]> wrote:
> They are optimized away, but if I can figure out what the
> conditio
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-04-14
17:03 ---
Subject: Re: [PR middle-end/20739] lvalue cond-expr gimplification may crash on
cv-qual diffs
On Apr 4, 2005, Alexandre Oliva <[EMAIL PROTECTED]> wrote:
> If the operands of a cond-expr used as an lvalue
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-04-14
17:21 ---
Subject: Re: [PR target/20126, RFC] loop DEST_ADDR biv replacement may fail
On Apr 12, 2005, Roger Sayle <[EMAIL PROTECTED]> wrote:
> ! v->ignore = 1;
What's the point of the statement above?
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-04-15
02:32 ---
Subject: Re: [PR middle-end/20739] lvalue cond-expr gimplification may crash on
cv-qual diffs
On Apr 14, 2005, Alexandre Oliva <[EMAIL PROTECTED]> wrote:
> Bootstrap and regtest pased on amd64-linux-gnu, a
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-04-15
03:31 ---
Subject: Re: [PR target/20126, RFC] loop DEST_ADDR biv replacement may fail
On Apr 12, 2005, Roger Sayle <[EMAIL PROTECTED]> wrote:
> I still like your fallbacks, that by trying harder we perform better
> o
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-04-15
05:56 ---
Subject: [PR tree-optimization/21029, RFC] harmful chrec type conversions
I started out by handling the specific case that the Ada front-end
triggers, reduced to function f() in the attached testcase. Later
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-04-16
21:48 ---
Subject: Re: [PR target/20126, RFC] loop DEST_ADDR biv replacement may fail
On Apr 15, 2005, Roger Sayle <[EMAIL PROTECTED]> wrote:
> Sure. Your patch in comment #28 of bugzilla PR20126 is OK for mainline
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-04-16
21:58 ---
Subject: Re: [PR target/20126, RFC] loop DEST_ADDR biv replacement may fail
On Apr 15, 2005, Roger Sayle <[EMAIL PROTECTED]> wrote:
> I agree with your proposed game plan of keeping the hard failure in
> pl
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-04-16
21:58 ---
Subject: Re: [PR middle-end/20739] lvalue cond-expr gimplification may crash on
cv-qual diffs
On Apr 15, 2005, Jeffrey A Law <[EMAIL PROTECTED]> wrote:
> On Thu, 2005-04-14 at 14:02 -0300, Alexandre Oliva
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-04-17
02:37 ---
Subject: Re: [PR target/20126, RFC] loop DEST_ADDR biv replacement may fail
On Apr 16, 2005, Roger Sayle <[EMAIL PROTECTED]> wrote:
> Does this clear things up? Do you agree?
Yup, for both questions. Tha
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-04-17
03:59 ---
Subject: Re: [PR c++/20103] failure to gimplify constructors for addressable
types
Mark, did you give up on COMPOUND_LITERAL_EXPRs in C++ for 4.0? The
C++ portion of the patch at http://gcc.gnu.org/PR20103
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-04-17
04:00 ---
Subject: Re: [PR c++/17805] limit operator overload candidates for enum operands
On Apr 2, 2005, Alexandre Oliva <[EMAIL PROTECTED]> wrote:
> On Mar 18, 2005, Alexandre Oliva <[EMAIL PROTECTED]> wrote:
>>
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-04-17
06:24 ---
Subject: Re: [PR c++/20103] failure to gimplify constructors for addressable
types
On Apr 17, 2005, Mark Mitchell <[EMAIL PROTECTED]> wrote:
> Alexandre Oliva wrote:
>> Mark, did you give up on COMPOUND_LI
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-04-19
17:08 ---
Subject: [PR target/16888] clear reg names of unavailable regs
We used to crash at print_operand time, because the register asm
variable named a REX register, not available in 32-bit mode.
This patch arrang
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-04-19
21:45 ---
Subject: [PR c++/21087] don't keep builtin anticipated decl, override it with
actual declaration
When push_overloaded_decl() was passed a new declaration that matches
a builtin decl, it would verify that th
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-04-23
02:47 ---
Subject: Re: [PR c++/21087] don't keep builtin anticipated decl, override it
with actual declaration
On Apr 21, 2005, Mark Mitchell <[EMAIL PROTECTED]> wrote:
> Alexandre Oliva wrote:
>> When push_overload
--- Additional Comments From aoliva at redhat dot com 2004-12-29 08:04
---
Subject: Re: New: [4.0 regression] ICE on invalid template parameter
On Dec 23, 2004, "reichelt at gcc dot gnu dot org" <[EMAIL PROTECTED]> wrote:
> The following invalid code snippet
--- Additional Comments From aoliva at redhat dot com 2004-04-12 17:23 ---
Subject: Re: 'make install' fails on grepjar.1, not included in tarball [v2]
On Apr 12, 2004, Kelley Cook <[EMAIL PROTECTED]> wrote:
> Now also tested under GCC 3.4 with and without
> --
79 matches
Mail list logo
