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 mjbaars1...@gmail.com
On Wed, Aug 28, 2013 at 5:52 PM, Samuel Mi samuel.mi...@gmail.com 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
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
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
You might want to file a bug at http://gcc.gnu.org/bugzilla/ for this.
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
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
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++
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
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
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
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
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
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=RESOLVEDresolution=FIXEDtarget_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.
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
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 neither
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,
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, and
use -fpch-preprocess with distcc
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.gnu.org/onlinedocs/gcc-4.0.2/gcc/Precompiled-Headers.html
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.
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
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
[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
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 the source
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?
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
--
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 have
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
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 delta
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
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).
-
[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
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,
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 the command
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
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
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/kernel
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
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
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
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
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
[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
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
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
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.
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
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
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
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 now I'm
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
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
[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)
53 matches
Mail list logo
