Synopsis: -I/usr/include change compiler behavior to something like -pedantic-errors
State-Changed-From-To: open->closed
State-Changed-By: aoliva
State-Changed-When: Mon Jul 30 13:58:07 2001
State-Changed-Why:
Look for -I/usr/include in the GCC manual. This is documented behavior.
h
--- 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
--- 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,
--- 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 be
--- 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
--- 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
--- 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 a
--- 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
--- 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 (wel
--- 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, lookin
--- 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 &q
--- 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-en
--- 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
--- 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 PROTE
--- 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
--- 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:
>> +c
--- 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
--- 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&
--- 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-c
--- 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-eq
--- 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 com
--- 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
--- 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 th
--- 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&#
--- 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 x
--- 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 Ol
--- 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 Ol
--- 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, Alexan
--- 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
--- 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, Alexan
--- 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
--- 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, Alexan
--- 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 <[EMA
--- 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
--- 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 multi
--- 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
so
--- 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. I
--- 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.
--- 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 Ol
--- 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
--- 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:
--- 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
--- 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
--- 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
--- 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
--- 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 Ol
--- 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 Ol
--- 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 PROTE
--- 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 Ol
--- 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
> *
--- 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-nes
--- 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]>
--- 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
--- 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 a
--- 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 PROTE
--- 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
--- 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'
--- 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
--- 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 ignor
--- 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]> wr
--- 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
--- 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
--- 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 th
--- 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-
--- 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 perfo
--- 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
--- 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
--- 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 f
--- 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, Alexan
--- 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
--- 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
--- 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 PROTE
--- 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
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: aoliva at gcc dot gnu.org
CC: segher at kernel dot crashing.org
Target Milestone: ---
The emulation of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94812
Alexandre Oliva changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |aoliva at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95456
Alexandre Oliva changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |aoliva at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95456
Alexandre Oliva changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63426
Bug 63426 depends on bug 95456, which changed state.
Bug 95456 Summary: [11 Regression] gcc/gcc.c:6035:16: runtime error: null
pointer passed as argument 2, which is declared to never be null
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95456
||2020-06-08
Status|UNCONFIRMED |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |aoliva at gcc dot
gnu.org
--- Comment #2 from Alexandre Oliva ---
Created attachment 48706
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48706&
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95224
--- Comment #2 from Alexandre Oliva ---
That's not expected, but it seems highly suspicious indeed. I'll have a look.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95224
Alexandre Oliva changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95365
Alexandre Oliva changed:
What|Removed |Added
Resolution|--- |WONTFIX
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95538
--- Comment #2 from Alexandre Oliva ---
More likely we've just always missed these lto dump files: IIRC they used to be
created in tmpdir, even during -save-temps builds.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87600
Alexandre Oliva changed:
What|Removed |Added
CC||aoliva at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95577
Alexandre Oliva changed:
What|Removed |Added
CC||aoliva at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95577
--- Comment #5 from Alexandre Oliva ---
but is .dSYM ever generated when no -g is present?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95416
Alexandre Oliva changed:
What|Removed |Added
URL||https://gcc.gnu.org/piperma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95577
Alexandre Oliva changed:
What|Removed |Added
URL||https://gcc.gnu.org/piperma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95720
Alexandre Oliva changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #3 from Alexandre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95720
--- Comment #5 from Alexandre Oliva ---
that's because of the second input gcc_tg.o
can you tell where that comes from?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95720
--- Comment #6 from Alexandre Oliva ---
In case that's from some board config file, I suggest prefixing it with -Wl, so
that it doesn't count as an additional input.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95720
--- Comment #7 from Alexandre Oliva ---
now, if it is from the board config file, maybe it had better be moved to
ldflags or libs; both of them undergo some -Wl, treatment of object files and
libs already.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95416
Alexandre Oliva changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95577
Alexandre Oliva changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95458
Alexandre Oliva changed:
What|Removed |Added
CC||aoliva at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95720
--- Comment #10 from Alexandre Oliva ---
Created attachment 48886
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48886&action=edit
patch that hopefully fixes the problem
Does this fix the problem in your testglue-requiring test runs?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95720
Alexandre Oliva changed:
What|Removed |Added
Attachment #48886|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95720
Alexandre Oliva changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
1 - 100 of 1710 matches
Mail list logo
