--
echristo at redhat dot com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #3 from echristo at redhat dot com 2005-10-25 21:49 ---
Not a duplicate
--
echristo at redhat dot com changed:
What|Removed |Added
Status
Summary: preprocessor eats whitespace at end of line
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: preprocessor
AssignedTo: echristo at gcc dot gnu dot org
ReportedBy: echris
--- Additional Comments From echristo at redhat dot com 2005-06-17 20:21
---
Here are the 4 testcases that I've been using to test, the first two you've
seen. (and no, the dg stuff isn't done yet, but that's merely to make the
testsuite happy.)
test1:
/* { dg-do
--- Additional Comments From echristo at redhat dot com 2005-06-15 21:58
---
Did you happen to catch where the .space 0 were being emitted from?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22006
--- Additional Comments From echristo at redhat dot com 2005-06-15 20:49
---
OK. This diff works, and passes bootstrap with no regressions for both
--enable-intermodule and normally on x86-linux. The --enable-intermodule bits
are why we split this out in the first place, but
--- Additional Comments From echristo at redhat dot com 2005-06-15 18:25
---
I'll take this. I've got a patch just completing testing.
--
What|Removed
--- Additional Comments From echristo at redhat dot com 2005-06-14 01:11
---
Joseph,
So, what you're saying is that we should accept this:
extern inline int foo (void) { return 0; }
inline int foo (void) { return 1; }
unless we're in strict c99 mode.
And reject this:
sta
al
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: echristo at redhat dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet:
--- Additional Comments From echristo at redhat dot com 2005-06-06 05:14
---
http://gcc.gnu.org/ml/gcc-patches/2005-06/msg00433.html
--
What|Removed |Added
--- Additional Comments From echristo at redhat dot com 2005-06-06 05:04
---
oh, I see. Didn't think BRANCH_COST could ever be negative...?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21927
--- Additional Comments From echristo at redhat dot com 2005-06-06 04:54
---
Hunh. Saw the warning, no idea how my patch caused it, but I'll look.
--
What|Removed |
--- Additional Comments From echristo at redhat dot com 2005-05-17 18:20
---
After talking with jason I think this is a legitimate request.
--
What|Removed |Added
--- Additional Comments From echristo at redhat dot com 2005-04-11 19:54
---
OK. I'm willing to fix up the mips backend for this if you hand me the patch
ahead of time (and it's accepted as a good idea by the middle-end maintainers).
--
http://gcc.gnu.org/bugzilla/show_
--- Additional Comments From echristo at redhat dot com 2005-04-10 19:02
---
I think I'm ok with this, but I'd like a bit more info. What changes to the
backend do you forsee this needing? The one patch that you applied to the 4.1 sh
branch was too big to just get that particu
--- Additional Comments From echristo at redhat dot com 2005-04-06 18:57
---
There's also the problem that the current mechanism for doing unaligned
loads/stores are not valid mips16 instructions, and therefore we couldn't rely
upon the patterns unless we knew that the addr
--- Additional Comments From echristo at redhat dot com 2005-04-05 21:36
---
No response. Cleaning up old prs.
--
What|Removed |Added
Status|WAITING
--- Additional Comments From echristo at redhat dot com 2005-04-05 21:35
---
Since I don't have a 6.2 box (and neither does Richard afaik), I'm not certain
there's anything we can do about this. You'll either need to debug the
differences on your platform bet
--- Additional Comments From echristo at redhat dot com 2005-04-05 21:26
---
Richard,
I think we should probably close this one unless we actually get a chip part
that has this failing :)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13309
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |echristo at redhat dot com
|dot org |
Status|WAITING
--- Additional Comments From echristo at redhat dot com 2005-04-05 21:23
---
The point of mips16 is smaller code, why would you expect inline memcpy calls at
any point?
-eric
--
What|Removed |Added
--- Additional Comments From echristo at redhat dot com 2005-04-05 21:05
---
fixed quite a while ago.
--
What|Removed |Added
Status|WAITING
--- Additional Comments From echristo at redhat dot com 2005-03-16 01:15
---
Fairly certain the REG_DEAD note is wrong since I can't see a way for 136 to die
in that insn (on read?).
Where'd the note get set?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20177
--- Additional Comments From echristo at redhat dot com 2005-02-15 23:45
---
I suppose I could apply the patch there too.
--
What|Removed |Added
Status|REOPENED
--- Additional Comments From echristo at redhat dot com 2005-02-15 23:18
---
Fixed.
--
What|Removed |Added
Status|ASSIGNED|RESOLVED
--- Additional Comments From echristo at redhat dot com 2005-02-12 01:43
---
Ran it through valgrind to track down the memory errors and then started
hunting. Testing a patch currently. valgrind returns no errors after patch.
-eric
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- Additional Comments From echristo at redhat dot com 2005-02-08 05:02
---
Everytime I try to guess what an XFAIL is for other than a "not implemented yet"
failure I get in trouble. I'm willing to go with this if the 3.3 branch manager
approves though (and I can figure
--- Additional Comments From echristo at redhat dot com 2005-02-08 03:12
---
It's a legitimate failure, we don't often xfail those - even when there is a
known fix.
--
What|Removed
--- Additional Comments From echristo at redhat dot com 2005-02-08 03:11
---
cpplib isn't my component and I'd prefer not to implement anything before
knowing that the general idea is ok. reassigning to unassigned.
--
What|Removed
--- Additional Comments From echristo at redhat dot com 2005-02-01 04:25
---
[EMAIL PROTECTED] ~/tmp]$ /dzur/sourceware/builds-gcc/build-dzur/gcc/xgcc
-B/dzur/sourceware/builds-gcc/build-dzur/gcc/ bug.c -c -save-temps -g3
*** glibc detected *** malloc(): memory corruption: 0x08ca4ba8
--- Additional Comments From echristo at redhat dot com 2005-02-01 03:06
---
Deprecating -mint64.
http://gcc.gnu.org/ml/gcc-patches/2005-02/msg00019.html
--
What|Removed |Added
--- Additional Comments From echristo at redhat dot com 2005-02-01 02:21
---
The best I can get without major surgery to cpp is this:
#include "test.h"
/* comment from include line */
Which is likely insufficient for any good needs. I think what we need
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |echristo at redhat dot com
|dot org |
Status|NEW
--- Additional Comments From echristo at redhat dot com 2005-01-29 00:26
---
The previous was because i'm an idiot.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13726
--- Additional Comments From echristo at redhat dot com 2005-01-29 00:25
---
Current mainline does this:
[EMAIL PROTECTED] ~/tmp]$ /dzur/sourceware/builds-gcc/build-dzur/gcc/cc1 -dI -C
test.c
In file included from test.c:1:
test.h:1: internal compiler error: in c_lex_with_flags, at c
--- Additional Comments From echristo at redhat dot com 2005-01-28 23:33
---
I just tried this in mainline and it appears to be fixed (at least the testcase
works without error).
--
What|Removed |Added
--- Additional Comments From echristo at redhat dot com 2005-01-20 00:37
---
The discussion was held offline between Richard Sandiford and I.
Having a -mint64 option changes the abi for anything that is built with that
option and in no abi defined for mips is int defined to 64. You
--- Additional Comments From echristo at redhat dot com 2005-01-15 07:31
---
Thought I did last time.. otherwise I'm not sure what the question is.
--
What|Removed |
--
What|Removed |Added
Status|ASSIGNED|WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19370
--- Additional Comments From echristo at redhat dot com 2005-01-13 02:38
---
-mint64 is being deprecated in 4.0 and will be removed after branching. What are
you using it for anyhow?
--
What|Removed |Added
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |echristo at redhat dot com
|dot org |
Status|UNCONFIRMED
--- Additional Comments From echristo at redhat dot com 2004-12-22 19:48
---
I thought I did on the 7th. I'm not sure there's anything we can do about this.
The behavior is correct and the previous behavior was proved to be not correct.
If someone has an idea that's g
--- Additional Comments From echristo at redhat dot com 2004-12-10 20:55
---
I just retried the attached patch and get a different failure in:
#1 0x080f188d in gimple_add_tmp_var (tmp=0xf6d5cba0)
at /lyorn/sourceware/combined/gcc/gimplify.c:531
531 gcc_assert (!TREE_CHAIN
--
What|Removed |Added
Status|WAITING |ASSIGNED
Last reconfirmed|2004-10-26 18:30:20 |2004-12-08 00:48:03
date|
--- Additional Comments From echristo at redhat dot com 2004-12-07 23:30
---
Can reopen if still a problem.
--
What|Removed |Added
Status|WAITING
--
Bug 18744 depends on bug 18442, which changed state.
Bug 18442 Summary: [4.0 Regression] Rejects attribute((mode(SI))) when using
-mint64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18442
What|Old Value |New Value
---
--
Bug 18404 depends on bug 18442, which changed state.
Bug 18442 Summary: [4.0 Regression] Rejects attribute((mode(SI))) when using
-mint64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18442
What|Old Value |New Value
---
--- Additional Comments From echristo at redhat dot com 2004-12-07 22:21
---
Fixed with above.
--
What|Removed |Added
Status|ASSIGNED
--- Additional Comments From echristo at redhat dot com 2004-12-07 19:54
---
The patch was put in to stop erroneous REG_DEAD notes from being created where
they shouldn't IIRC. Now, we may be able to rerun cfg as Paolo suggests, but I
don't know for certain. Unless we can prov
--- Additional Comments From echristo at redhat dot com 2004-12-07 08:25
---
This came about with the scalar_mode_supported_p work. Patch in testing.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18442
--- Additional Comments From echristo at redhat dot com 2004-12-07 07:27
---
I doubt that Jan's patch is likely to be backported to 3.3 so I think we can
resolve the bug with an "upgrade" or "wontfix" for 3.3.
--
What|Removed
--- Additional Comments From echristo at redhat dot com 2004-12-07 07:21
---
http://gcc.gnu.org/ml/gcc-patches/2004-12/msg00438.html
--
What|Removed |Added
--- Additional Comments From echristo at redhat dot com 2004-12-07 06:50
---
Ken,
The only 32-bit irix I can remember is irix5, what's odd about your machine that
you don't have the 64-bit libraries installed?
--
What|Removed
--- Additional Comments From echristo at redhat dot com 2004-12-01 20:40
---
I doubt this is still a problem, but I'm going through bugs.
--
What|Removed |
--
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed||1
Last reconfirmed|-00-00 00:00:00 |200
--
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed||1
Last reconfirmed|-00-00 00:00:00 |200
--- Additional Comments From echristo at redhat dot com 2004-10-11 23:45 ---
Not a big fan of Andrew's patch. I don't think it will cover all the cases where
we have a problem. Basically, afaict, we're folding the toplevel call into
something else. In this case a builti
--- Additional Comments From echristo at redhat dot com 2004-10-07 06:48 ---
Subject: Re: [4.0 regression]
gcc.dg/c99-intconst-1.c compilation is very slow
On Thu, 2004-10-07 at 00:44, Joern Rennecke wrote:
> >
> >
> > --- Additional Comments From giov
58 matches
Mail list logo
