You might want to file a bug at http://gcc.gnu.org/bugzilla/ for this.
Ganesh wrote:
I work in a company where we have been using gcc-2.95.4 (based cross
compiler) for compiling our code. Most of the code is written in c++
and makes extensive use of the stl libraries. We would not be changing
our operating system or processor architecture (so portability is not
a ve
[EMAIL PROTECTED] wrote:
I compiled unexec.c from Emacs 21.3 with -O2, and I got the
error from GNU as on line 1498:
Fatal error: C_EFCN symbol out of scope
I'm on the x86. This only happens if all three of the
following are satisfied
1) -gcoff debugging information is being generated
2) -fu
I tried building glibc-2.3.4 for m68k-unknown-linux-gnu with gcc-4.0-20050305,
and the compiler fell over in iconv/skeleton.c:
In file included from iso-2022-cn-ext.c:657:
../iconv/skeleton.c: In function 'gconv':
../iconv/skeleton.c:801: internal compiler error: output_operand: invalid
expression
Moving an installed gcc/glibc crosstoolchain
to a different directory was not allowed
for gcc-2.96 and below, I seem to recall,
but became permissible around gcc-3.0.
(Sure, there are still embedded paths,
but they don't seem to be used in practice.
I don't really trust it, but that's what I observ
Daniel Jacobowitz wrote:
On Tue, Mar 29, 2005 at 10:37:33PM -0800, Dan Kegel wrote:
Since I need to handle old versions of gcc, I'm
going to code up a little program to fix all
the embedded paths anyway, but I was surprised
by the paths in the pch file. Guess I shouldn't
have been, but
Nick Rasmussen <[EMAIL PROTECTED]> wrote:
I'm running into an ICE in the prerelease, that is proving to be
very difficult in reducing to a small testcase. If I preprocess
the source (via -E or -save-temps) the code successfully compiles.
> ...
Does this bug look familiar? 20629 is ICEing in the s
"zouq" <[EMAIL PROTECTED]> wrote:
first i download the release the version of gcc-2.95.3, binutils 2.15,
and i use the o32 lib, include of gcc3.3.3 .
1. compile the binutils and install it
mkdir binutils-build;
cd binutils-build;
../../binutils-2.15/configure --prefix=/opt/gcc --target=mipsel-linux
Mike Hearn <[EMAIL PROTECTED]> wrote:
I have a copy of Inkscape compiled with GCC 3.3, running on a GCC 3.4
based system. All of the C++ libraries it links directly against, like
GTKmm, are statically linked. In other words, it dynamically links
against no C++ libraries.
Inkscape dlopens libgtkspel
Steven J. Hill wrote:
While I am getting closer to full toolchain build, GCC-4.1.0 is still
not behaving the way it should. Below is the output that I am running
up against. I attempted to define a stack variable to hold the value
of zero and tried using that instead of the actual value, but nothin
Daniel Berlin wrote:
I am working on interprocedural data flow analysis(IPDFA) and need some
feedback on scalability issues in IPDFA. Firstly since one file is
compiled at a time, we can do IPDFA only within a file.
For starters, we're working on this.
(I was curious, so I searched a bit. I
Peter Barada wrote:
The alternative of course is to do only crossbuilds. Is it reasonable
to say that, for platforms where a bootstrap is no longer feasible, a
successful crossbuild is an acceptable test procedure to use instead?
A successful crossbuild is certainly the minimum concievable standa
Peter Barada wrote:
Unfortunately for some of the embedded targets(like the ColdFire V4e
work I'm doing), a bootstrap is impossible due to limited memory and
no usable mass-storage device on the hardware I have available, so
hopefully a successful crossbuild will suffice.
How about a successful cro
[EMAIL PROTECTED] wrote:
> [ Things break horribly when I compile them
> with a compiler built against glibc-2.3.x
> and try to run them on a glibc-2.2.x system. ]
This is expected and normal. gcc and glibc have
circular dependencies. A gcc tainted with a newer
glibc is expected to produce bi
Scott Robert Ladd wrote:
Mark has a valid concern: Why aren't bugs being fixed? One answer is:
The GCC community is often less than welcoming, friendly, and helpful.
You may not like or believe the answer, but if you want more people to
help GCC for free, an attitude adjustment may be required
Scott Robert Ladd wrote:
I have ample evidence that
many people feel that the GCC developer community is not very welcoming.
I haven't found this to be the case. Perhaps that's because
I try to control my urge to post frequently (oops, guess
I'm screwing up here!), and because I try hard to co
We are a group of undergrads at Portland State University who accepted as our
senior capstone software engineering project a proposed tool for use with gcov
for summarizing gcov outputs for a given piece of source code tested on
multiple architecture/OS platforms. A summary of the initial propo
Daniel Jacobowitz wrote:
I think we need to finally come up with a way to build the compiler and
libraries at different times.
Don't tease me.
--
Trying to get a job as a c++ developer? See
http://kegel.com/academy/getting-hired.html
I can't build gcc-4.1-20050709 for target arm; it fails with
gcc-4.1-20050709/libiberty/cp-demangle.c: In function 'd_print_comp':
gcc-4.1-20050709/libiberty/cp-demangle.c:3342: internal compiler error: in
loop_givs_rescan, at loop.c:5517
Compiling the same version of gcc for i686 manages
to av
Falk Hueffner wrote:
Dan Kegel <[EMAIL PROTECTED]> writes:
Likewise, compiling that version of gcc for alpha
dies while building the linux kernel, but for a different reason:
{standard input}:496: Error: macro requires $at register while noat in effect
make[1]: *** [arch/alpha/
Falk Hueffner wrote:
Dan Kegel <[EMAIL PROTECTED]> writes:
Likewise, compiling that version of gcc for alpha
dies while building the linux kernel, but for a different reason:
{standard input}:496: Error: macro requires $at register while noat in effect
make[1]: *** [arch/alpha/
Dan Kegel wrote:
sparc-gcc-4.1-20050709-glibc-2.3.2:
arch/sparc/kernel/process.c:204: internal compiler error: in
compare_values, at tree-vrp.c:445
Filed as
http://gcc.gnu.org/PR22398
--
Trying to get a job as a c++ developer? See
http://kegel.com/academy/getting-hired.html
Paul Koning wrote:
"Falk" == Falk Hueffner <[EMAIL PROTECTED]> writes:
>> $ alpha-unknown-linux-gnu-gcc -fno-common -ffreestanding -O2 \
>> -mno-fp-regs -ffixed-8 -msmall-data -mcpu=ev5 -Wa,-mev6 -c
>> core_cia.i
Falk> I don't see any fault on gcc's side here. You could argue that
Falk>
Richard Henderson wrote:
On Mon, Jul 11, 2005 at 08:54:34AM -0400, Paul Koning wrote:
More appropriate would be to make the command line consistent with the
code. If there's inline assembly that requires ev6, then -mcpu=ev6 is
appropriate.
No, this code is protected by various system checks
Richard Henderson wrote:
On Mon, Jul 11, 2005 at 09:52:22AM -0700, Dan Kegel wrote:
No, this code is protected by various system checks.
We want -mcpu=ev5 such that the kernel as a whole will run everywhere,
but we require these specific instructions on specific ev56/ev6 systems
for i/o
Jonathan Wakely wrote:
The minimum binutils for libstdc++ is now 2.15.90.0.1.1, I don't know
about the rest of GCC.
...
and IMHO testresults look quite good except abi_check, don't they? i.e. do
you mean updating binutils will resolve abi_check issue in libstdc++
testsuite?
I'd assume yes, b
I'm seeing the following two instances of the same ICE
building a large app with gcc-4.1-20050702 for i686-linux:
bits/stl_list.h:396: internal compiler error: in force_decl_die, at
dwarf2out.c:12618
ext/rope:1469: internal compiler error: in force_decl_die, at dwarf2out.c:12618
If it still hap
I'm seeing the following ICE
building a large app with gcc-4.1-20050702 for i686-linux:
ext/mt_allocator.h:450: internal compiler error: in write_template_arg_literal,
at cp/mangle.c:2228
If it still happens with the next snapshot, I'll
submit a bug (unless someone tells me not to bother).
- Da
[resending - forgot to finish subject line before]
I'm seeing the following ICE
building a large app with gcc-4.1-20050702 for i686-linux:
ext/mt_allocator.h:450: internal compiler error: in write_template_arg_literal,
at cp/mangle.c:2228
If it still happens with the next snapshot, I'll
submit
"Paul C. Leopardi" <[EMAIL PROTECTED]> wrote:
> So I seem to be left with a large ( >2.5MB ) preprocessed source file. Should
> I try to report the bug using this large file as a test case?
Sure. But you might want to try using an automated tool
to reduce the test case first. There's one called
Geez, 'delta' from http://www.cs.berkeley.edu/~dsw
really does seem to make it easy to track down
near-minimal testcases for ICEs.
It's tempting to continually beat the crap out of gcc-4.1 snapshots by
compiling all the sources I can find,
then for each ICE that occurs,
using delta to find a mini
Sebastian Pop wrote:
> [http://gcc.gnu.org/wiki/Omega%20data%20dependence%20test]
> ...
I can't understand a word of the proposal.
Mabe you were trying to be funny, but it ended up being obscure.
If the average gcc developer can understand it, then
it doesn't matter that I can't, but I have a feel
Peter Zijlstra <[EMAIL PROTECTED]> wrote:
On this controversial subject, could somebody please - pretty please
with a cherry on top - tell me what the current status is:
- in general,
- as implemented in the 3.4 series and
- as implemented in the 4.0 series.
At work we're using 3.4 and we hav
For fun, I counted the number of open missed-optimization issues:
all versions: 423
gcc-3.4.x: 55
gcc-4.0.x: 170
gcc-4.1-x: 93
It looks like many of them, even those filed four
years ago, are getting some recent attention,
which is encouraging. Thanks to everyone
pushing these along.
- Dan
--
> i am currently working on a project of building M16C programs. i have an IRA
> M16C/I8C C/C++ compiler on hand, but it is for Windows and i just can not live
> w/o my Linux box.
Could you perhaps run the compiler under Wine?
Ronny Peine wrote:
>> > -ftree-loop-linear is removed from the testingflags in gcc-4.0.2 because
>> > it leads to an endless loop in neural net in nbench.
>>
>> Could you fill a bug report for this one?
>
>Done.
Your PR is a bit short on details. For instance, it'd be nice to
include a link to th
[EMAIL PROTECTED] wrote:
> [ Why doesn't dynamic_cast work when I dlopen a shared library? ]
I think the right place for this question might have been
gcc-help (http://gcc.gnu.org/ml/gcc-help/).
Nevertheless, I think http://gcc.gnu.org/faq.html#dso
should answer your question.
- Dan
--
Wine for W
Hi Eric!
I agree, moving warnings on benign conversions to -Wconversion
would help groups porting large codebases from earlier versions of gcc.
As long as you're in that area, got any opinion on
http://gcc.gnu.org/PR9072
?
--
Wine for Windows ISVs: http://kegel.com/wine/isv
Some projects have a time-based release strategy
(e.g. "we release once every six months").
Would it make sense for gcc to do that
for all maintenance releases? e.g.
leave the current process the same for .0
versions, which users are scared of anyway,
but coordinate all other releases
to occur on
Gerald wrote:
>On Wed, 1 Feb 2006, H. J. Lu wrote:
>> My memory hog patch for make has 2 typos. This patch fixes them.
>Thanks, H. J. What's the upstream status of your patches?
I think they're in upstream (hopefully H.J. will confirm that).
I know that the O(N^2) bug that Jeff Evarts found and f
gcc-4.1-rc1 seems nice so far - it's the first version of gcc
that can beat gcc-2.95.3 on one particular app -
but it seems to be slow at preprocessing C++ source.
This matters quite a bit when running distcc.
In fact, it seems to take three times as long to
build large C++ apps as gcc-2.95.3 did.
On 2/24/06, Mike Stump <[EMAIL PROTECTED]> wrote:
> On Feb 23, 2006, at 9:05 PM, Dan Kegel wrote:
> > it seems to be slow at preprocessing C++ source.
> > This matters quite a bit when running distcc.
>
> One way to mitigate this would be to use a precompiled header,
On 2/24/06, Mike Stump <[EMAIL PROTECTED]> wrote:
> On Feb 24, 2006, at 1:25 PM, Dan Kegel wrote:
> > That's painful to set up, though (it requires changing the
> > application's source to be effective, doesn't it?)
>
> No.
After reading
http://gcc.gn
The crossgcc mailing list really needs some moderator lovin'.
e.g. an address on the crossgcc mailing list is bouncing,
and needs removal. Worse, the blurb at the bottom of each
post has needed updating for the last four years or so.
I seem to be one of the main players on that list these days,
a
Mark wrote:
> 1. GNU TAR 1.14 is required to unpack the source releases. Other
> versions of tar are likely to report errors or silently unpack the
> file incorrectly.
Now hold on there, bubaloo.
I thought the warnings from older versions of tar were benign.
The warnings I'm seeing from tar-1
On 3/1/06, Daniel Jacobowitz <[EMAIL PROTECTED]> wrote:
> > > 1. GNU TAR 1.14 is required to unpack the source releases. Other
> > > versions of tar are likely to report errors or silently unpack the
> > > file incorrectly.
>
> The problem has nothing to do with warnings from tar, which are ne
http://gcc.gnu.org/gcc-4.0/changes.html#4.0.3
is missing a link to
http://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED&resolution=FIXED&target_milestone=4.0.3
with text
This is the list of problem reports (PRs) from GCC's bug tracking
system that are known to be fixed in the 4.0.3 release.
Is there a bugzilla entry describing the bug Richard is fixing?
If not, it'd be nice to have, if for no other reason than
it would show up naturally when people look for bugs fixed in gcc-4.1.1.
I can create one, but it'd be better if someone actually
involved in the action did.
- Dan
--
Wine for
Mike Hearn wrote:
> [So, what does
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24660
> Versioning weak symbols in libstdc++
> mean for ISVs? Will it solve the backwards compatibility problems
> mentioned in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21405 ? How?]
I'd love to know, too. I
Hi Dave.
I hope you find and squash the relocation bug the right way,
but until then, perhaps you could use my cheezy program
that fixes embedded paths in gcc toolchains. It's at
http://kegel.com/crosstool/current/fix-embedded-paths.c
I haven't tested it on mingw toolchains, so some assembly may
b
Eder wrote:
Partial Transitions[http://gcc.gnu.org/wiki/Partial%20Transitions]
called my attention.
I am very interested in submitting a project for the SoC in this category.
I read the general ideas and have a project in my mind to execute the
task listed in the wiki.
You might want to start
On 4/29/06, Eder L. Marques <[EMAIL PROTECTED]> wrote:
> You might want to start by picking just one of the "Partial Transitions"
> tasks and trying to work on it, even before submitting a proposal; that
> will help you write a better proposal...
Its a good idea Dan. :)
May be I can start with d
Ginil wrote:
code that compiled easily with gcc-3.2.1 would not compile with gcc-4.0.1.
... The major errors are with
template, name lookup but there are also certain errors with finding
definitions from header files which are included and are in include path.
Your code is probably not C++ stan
Thanks! I put an updated page up at
http://kegel.com/gcc/summit2006.html
I won't be attending myself this year (I needed a break from travel),
but if anyone's blogging the event, please let me know and I'll
link to their blog from my page.
- Dan
On 6/23/06, Andrey Belevantsev <[EMAIL PROTECTE
Is it time to create a GCC_4.3_Projects page
like http://gcc.gnu.org/wiki/GCC_4.2_Projects ?
I imagine several projects are already in progress,
but not yet mentioned on the wiki...
- Dan
On Wed, Aug 28, 2013 at 5:52 PM, Samuel Mi wrote:
>> This looks like a SSH connector for the Jenkins server side, no?
> No. Actually, Jenkins implements a built-in SSH server within itself.
Doesn't really help platforms that can boot linux but that don't have
a sufficient
version of Java/python.
Please don't crosspost.
It would probably also help if you posted just one bug per message,
and included the commandline, source, and error message
for your smallest test case inline, and used a more descriptive
subject line.
On Sat, Nov 2, 2013 at 10:26 AM, Mischa Baars wrote:
> Hi,
>
> I found
Stephen M. Kenton asked:
> Should specifiying newlib in the absence of the newlib source continue
> to be treated as meaning "force inhibit_libc" in some cases, or should
> inhibit_libc just be exposed if that is desirable?
FWIW, crosstool.sh has this little snippet in it:
# Building the boot
58 matches
Mail list logo
