http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53246
Bug #: 53246
Summary: failure building cross compiler for arm7tdmi
(arm-none-eabi) in libgcc (multilib)
Classification: Unclassified
Product: gcc
Version: 4.7.1
Statu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37215
--- Comment #13 from patriciak784-gccmainling at yahoo dot de 2012-01-15
14:27:00 UTC ---
(In reply to comment #12)
> On inspecting this more closely, I agree with patriciak784. The issue isn't
> directly related to the fix of
--- Comment #11 from patriciak784-gccmainling at yahoo dot de 2009-02-01
11:44 ---
I am sorry that I was a bit unclear - 4.0.0 @ 95634 works for PR20239 but
doesn't for this problem.
But the patch from PR20239 fixed both problems on 3.4.4, so both bugs are no
duplicates,
--- Comment #10 from patriciak784-gccmainling at yahoo dot de 2009-02-01
11:22 ---
(In reply to comment #6)
> read_original_filename lexes a token, which hits EOF, which
> causes the buffer to be popped.
>
> This is sort of an odd scenario.
> Perhaps worki
--- Comment #9 from patriciak784-gccmainling at yahoo dot de 2009-01-05
08:43 ---
I don't think it's good to apply the workaround mainly because 3.4.5 works for
me on mingw and the code that triggers the error hasn't changed since its
initial commit which was more than
--- Comment #8 from patriciak784-gccmainling at yahoo dot de 2009-01-04
20:53 ---
(In reply to comment #7)
> does indeed fix or work around (with gcc 4.3 branch revision somewhere around
> rev143000) the original problem ('gcc -E -dM -fpreprocessed - < /dev/null'
--- Comment #7 from patriciak784-gccmainling at yahoo dot de 2009-01-04
20:26 ---
(In reply to comment #6)
> read_original_filename lexes a token, which hits EOF, which
> causes the buffer to be popped.
>
> This is sort of an odd scenario.
> Perhaps worki
--- Comment #5 from patriciak784-gccmainling at yahoo dot de 2008-09-07
14:41 ---
Sorry, my "patch" doesn't always fix the problem. It is just strange. Sometimes
it works, sometimes not...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37215
--- Comment #4 from patriciak784-gccmainling at yahoo dot de 2008-09-04
16:38 ---
Now I know why gcc complains about a misformed pch file nul.gch!
Checking if a file named NUL plus any extension exists, will always return that
it exists because I did this on windows! open will not open
--- Comment #3 from patriciak784-gccmainling at yahoo dot de 2008-09-04
13:35 ---
I did examine both problems a bit further.
If I understand correctly what is happening, there is the object parse_in which
is, during program flow, passed to preprocess_file as argument pfile.
An object
--- Comment #7 from patriciak784-gccmainling at yahoo dot de 2008-09-04
09:50 ---
(In reply to comment #6)
> (In reply to comment #5)
> > (In reply to comment #4)
> > > (In reply to comment #3)
> > > > ... a self compiled gcc 4.3.1 ...
> > >
--- Comment #5 from patriciak784-gccmainling at yahoo dot de 2008-09-03
12:21 ---
(In reply to comment #4)
> (In reply to comment #3)
> > ... a self compiled gcc 4.3.1 ...
>
> Scary ;)
>
What did you expect, Paolo?
Well, I just compiled gcc-4_3-branch @ rev 137894
--- Comment #3 from patriciak784-gccmainling at yahoo dot de 2008-09-03
10:46 ---
(In reply to comment #2)
> Most likely the same issue as PR 37215.
>
I don't know. This problem is totally strange...
I checked my linux machine and some debian gcc 4.3.1-xx works correctly
--- Comment #1 from patriciak784-gccmainling at yahoo dot de 2008-09-02
14:37 ---
Please be aware that compiling /dev/null is used in glibc to produce empty
object files!
So it seems not to be a crazy thing to do...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37331
ummary: ICE trying to compile /dev/null
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: patriciak784-gccmainling at ya
15 matches
Mail list logo
