On 2005-08-25, at 13:57, Paolo Bonzini wrote:
Marcin Dalecki wrote:
On 2005-08-25, at 09:14, Christoph Hellwig wrote:
That's what I meant with my comment btw. It's a horrible idea to
put in all the junk to support inferior OSes into gcc and all other
other programs, and with
During a build attempt of gcc-20051001 and more secnt on darwin 10.8
I have discovered that apparently for some unknown reason
make_exports.pl get's called during th libstdc++ build and fails
miserably:
> libstdc++-symbol.explist || (rm -f libstdc++-symbol.explist ;
exit 1)
nm -P .libs/b
On 2005-10-02, at 23:45, Paolo Bonzini wrote:
2) Why do you think that symbol versioning is exclusive to glibc?
I don't. I look at the the results of it.
3) You can of course think that glibc is evil, but how is it related?
Oh no... I got just immersed by the GLIBCXX prefixing over there
On 2005-10-03, at 00:26, Andrew Pinski wrote:
6) Is this whining reporting significant information, for the
person that wants to fix the bug?
Well on the system in question ppc-apple-darwin-7.8.0 the perl script
in question simply doesn't work. Since there doesn't appear to be
much in the wa
On 2005-10-03, at 00:42, Marcin Dalecki wrote:
I'm not quite sure if this is correct since guessing the GCC
version interpretation here I would expect this to came out as:
ppc-apple-darwin7.9.2
aka: Tiger darwin 10.4.2
Trying to find out where the actual name mangling occured I
On 2005-10-03, at 00:49, Shantonu Sen wrote:
You're making a lot of terrible assumptions and drawing several
incorrect conclusions. xnu-792 is not the same as "darwin7.9.2",
and no configure script in the last 6 years should be detecting a
Mac OS X system as "ppc-apple-darwin" (it should b
On 2005-10-03, at 00:26, Andrew Pinski wrote:
This perl script works just fine for me on powerpc-darwin7.9.0 I
don't
see why are we piping the output to nm when it should be piping nm's
output to c++filt.
Also this perl script works fine on powerpc-darwin7.4.0 also.
Turns out it was rpm
On 2005-10-03, at 06:05, Peter O'Gorman wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Marcin Dalecki wrote:
|
| On 2005-10-03, at 00:26, Andrew Pinski wrote:
|
|>
|> This perl script works just fine for me on powerpc-darwin7.9.0
I don't
|> see why are we pipi
On 2005-10-12, at 04:42, Daniel Berlin wrote:
Checkouts will be about 30% slower with svn, just because it has to
write more data out to disk because of the working copy
Yes. Indeed. One suggestions comes immediately to my mind. Why don't
you provide some kind of COW (Copy on Write)? Or may
On 2005-10-13, at 03:26, Mike Stump wrote:
On Oct 12, 2005, at 5:55 PM, Marcin Dalecki wrote:
On 2005-10-12, at 04:42, Daniel Berlin wrote:
Checkouts will be about 30% slower with svn, just because it has to
write more data out to disk because of the working copy
Yes. Indeed. One
On 2005-10-20, at 11:45, Arnaud Charlet wrote:
Note that I found it a real pain to have to install so much
dependency package
on my linux system, so I suspect building the whole dependency
packages under
non linux systems might be slghtly of a pain.
This is not the case. This is only due t
On 2005-10-20, at 16:57, Richard Kenner wrote:
Sorry about that, but let's not remember of the other dozens which
works on branches and can do a merge in seconds instead of
literally
*hours*, and so on.
Yes, but how often do even those who work on branches a lot do merges?
If no
I have been looking closer at the following C front-end global
variables:
current_function_returns_value
current_function_returns_null
current_function_returns_abnormally
Which are declared in c-decl.c. They are basically used as a way to
communicate with c-typeck.c.
All have to be in
I just took a closer look at this host OS configuration macro
variable and it's usage.
It turns out that the variable is only used in gcc/gcc.c under the guide
of the verbose flag to confuse the corresponding notice output with
what is actually used
by the compiler driver. The threading model
FWIW I personally think this toplevel bootstrap thing is a step
backward, now
typing "make" triggers such a complex machinery that nobody seems
to able to
understand what it does.
Please forgive my ginorace but I didn't consider the autoconf/
automake/gnumake mechanism
to be entierly trasp
On 2006-01-13, at 23:59, Richard Kenner wrote:
Remind me why it's a good idea to force me to mess with
bootstrapping
at all, when all I want is to build a copy of the compiler that
I can
use for debugging problems?
Well install.texi explains in full lenght the wonders of the b
Except that host tools (fastjar mostly) are made with the *new* GCC
rather than the old one.
And the reason is what? I don't see even any theoretical merit in the
whole staging thing:
1. Bugs can theoretically cancel them self out.
2. The compiler isn't stressing himself more then the targ
On 2006-01-16, at 14:37, Richard Kenner wrote:
So the stage1 compiler is built as a 32-bit object, from the
second
stage on they're built as 64-bit objects.
Very bad idea! I don't think we should support that.
Yeep. That's not a bootstrap. It's cross compilation.
On 2006-01-16, at 15:24, Richard Kenner wrote:
The point of --disable-bootstrap is to disable bootstrapping.
Why would somebody ever want to *disable* it? If you don't want to
bootstrap, you just don't *do* it!
The most important of these is libgcc and the crt startup
files, which
More like "(cd gcc; make gnatlib_and_tools)", i.e. the current
directory
is the same.
That matters?
$(PWD)
On 2006-01-16, at 18:38, Daniel Jacobowitz wrote:
As a heavy debugger of cross compilers I strongly disagree with this
sentiment. Host dependencies of any sort are a bug.
Amen to that. Independence from the host is paramount to
guarantee *reproducibility* of results over any on trivial time
On 2006-01-16, at 19:18, DJ Delorie wrote:
A cross compiler and a native compiler targeting the same CPU chip,
that's a different story.
No it isn't. The results should still be the same.
On 2006-01-16, at 20:35, DJ Delorie wrote:
No it isn't. The results should still be the same.
You aren't considering call ABI or PIC issues. Natives might have
different call-saved registers, or global fixed register (like the TLS
pointers), that affect optimization in different ways than
Looking at gcc/toplev.h and gcc/toplev.c I have found the following
two variants of the same
function once in the header and once in the definition fine.
extern inline int
floor_log2 (unsigned HOST_WIDE_INT x)
{
return x ? HOST_BITS_PER_WIDE_INT - 1 - (int) CLZ_HWI (x) : -1;
}
and again the
OK. Looking closer I have just found that in gcc/toplev.c
#if GCC_VERSION < 3004
...
#endif
Is missing around the floor_log2() and exact_log2() functions.
On 2006-01-22, at 04:17, Andrew Pinski wrote:
OK. Looking closer I have just found that in gcc/toplev.c
#if GCC_VERSION < 3004
...
#endif
Is missing around the floor_log2() and exact_log2() functions.
You are mssing the fact that the ones in the headers are declared
as extern inline.
Yes
On 2006-01-22, at 04:35, Andrew Pinski wrote:
OK. Looking closer I have just found that in gcc/toplev.c
#if GCC_VERSION < 3004
...
#endif
Is missing around the floor_log2() and exact_log2() functions.
You are mssing the fact that the ones in the headers are declared
as extern inline.
Yes
abing this option is going to crash the compiler miserable.
Looking at the use of flag_brnach_target_load_optmize2 I think all of
the
associated code should be simply deleted.
Marcin Dalecki
On 2006-01-22, at 17:08, Daniel Jacobowitz wrote:
On Sun, Jan 22, 2006 at 05:00:34PM +0100, Marcin Dalecki wrote:
Inside gcc/target.h we have the declaration of
struct gcc_target { struct asm_out { struct sched { ...
there is a function refernce field named
int
On 2006-01-23, at 21:36, Zack Weinberg wrote:
Also, if you have access to valgrind (I can't remember if it works
on x86-64 yet?)
you could run both programs under it and report what it says, since
this seems
to be a bad-memory-access issue.
Inside genautomata.c there is a function gen_re
The following:
2006-01-23 Volker Reichelt <[EMAIL PROTECTED]>
* cp-tree.h (do_poplevel): Remove prototype.
* semantics.c (do_poplevel): Add prototype. Make static.
Is a plain mistake due to:
../.././gcc/objcp/objcp-decl.c: In function 'tree_node*
objcp_end_compound_stmt(t
The following removal of global default_conversion inside the C++
frontend:
2006-01-25 Volker Reichelt <[EMAIL PROTECTED]>
(default_conversion): Likewise.
Is junk due to the fact that it gets used for example in rs6000/rs6000.c
The results in *actual* build failure on Darwin/PowerPC
I think is should read as NE_EXPR insead...
tree dummy_cond = build2 (NE_EXPR, boolean_type_node,
integer_zero_node, integer_zero_node);
Marcin Dalecki
On 2006-02-17, at 23:43, Joern RENNECKE wrote:
Has anybody done timings for gcc bootstrap / cross builds and
regtests with modern multi-core processors? I wonder what a
sensible modern configuration would be for gcc development, but the
the multimedia and games benchmarks I found on the w
On 2006-02-18, at 15:23, Joern Rennecke wrote:
In http://gcc.gnu.org/ml/gcc/2006-02/msg00357.html, you wrote:
In fact the "gamer" benchmarks you are dissing are quite well
reflecting the
very kind
of coding excessively found in GCC itself. Some observations suggest
the you should aim at th
therefore that the value REG_DEP_TRUE should be assed as
first argument
to gen_rtx_INSN_LIST there. I think only the fact that the code in
question
isn't likely to trigger didn't make this occur immediately as a bug.
Is this analysis correct?
Marcin Dalecki
On 2006-02-22, at 05:41, Ian Lance Taylor wrote:
Marcin Dalecki <[EMAIL PROTECTED]> writes:
Looking at the regor.c code I came across the function
try_merge_delay_insns().
There around the line 1488 we will find the following code:
merged_insns = gen_rtx_INSN_LIST (
On 2005-02-11, at 02:19, Daniel Berlin wrote:
Uh, why do you want the server stuff for gcc purposes?
Just curious. Why not? If I want to try it out I want to try it out on
my own
repos too. Maybe I was just too optimistic about it. And then I simply
didn't know up front what I will get - just the
On 2005-02-11, at 04:23, Daniel Berlin wrote:
It was perfectly fair. He's complaining the source has dependencies,
and
uses configure to find out what is available, and complains when it
can't find the things it absolutely depends on.
Because apr and apr-util are providing things subversion doesn
On 2005-02-11, at 04:51, Daniel Berlin wrote:
Against my better judgement, i'll respond anyway.
On Fri, 2005-02-11 at 03:50 +0100, Marcin Dalecki wrote:
On 2005-02-11, at 02:19, Daniel Berlin wrote:
Uh, why do you want the server stuff for gcc purposes?
Just curious. Why not? If I want to t
On 2005-02-11, at 05:43, Daniel Berlin wrote:
In fact, if you look at the web page for APR, you can discover exactly
why it was created, and what it does, and then if you look at the
history of subversion, you can discover why apr was used for these
things, instead of reimplementing the wheel again
On 2005-02-14, at 19:47, Mike Stump wrote:
On Monday, February 14, 2005, at 04:04 AM, Richard Earnshaw wrote:
Fine, i'll just keep all the non-snapshot tags for now.
There's no reason why we have to keep all the tags in one place.
Further, we can import them all, and then later remove, move or ren
During my efforts to compile the whole gcc with a C++ compiler I
noticed that
the gmp library is somehow problematic with regard to this. The gmp.h
header
is using the __cplusplus define at will not just to specify the linkage
class of
the symbols provided there (extern "C"), but to define the C
On 2005-02-16, at 12:32, Vincent Lefevre wrote:
Do not use the MPFR version that comes with GMP. It is too old.
Remember that you can override the default by setting CFLAGS.
The documentation doesn't say this. The configure scripts don't check
for it.
On 2005-02-16, at 19:03, Serguei Kouratov wrote:
Could somebody inform about status of ObjC++ branch ?
The biggest obstacle to merging the current ObjC++ code from
apple-ppc-patch is the recent invention of objc_info field to the
struct lang_tree for C. There are some comments there but apparently
On 2005-02-22, at 00:25, Steve Kargl wrote:
On Tue, Feb 22, 2005 at 12:22:37AM +0100, Tobias Schl?ter wrote:
Gerald Pfeifer wrote:
On Mon, 21 Feb 2005, Tobias Schl?ter wrote:
To add a concrete example, unlike g77 in earlier versions of GCC,
gfortran
is not and will not be part of the standard gcc4
On 2005-02-23, at 18:40, Gabriel Dos Reis wrote:
ndards for error messages, etc.)
That certainly would require changing many things, e.g. Emacs support
and like. That is a reason why I approach this issue conservatively.
Factually the support for error handling by integration in to external
tools
On 2005-02-23, at 20:25, Gabriel Dos Reis wrote:
of source code in the diagnostic. That is based on the GNU standard
for diagnostics. Other people seem to have built tools on top of that
too.
Please note that there exists only a GNU *convention* for error
reporting.
A not particularly well tough
On 2005-02-25, at 12:22, Joseph S. Myers wrote:
I intend to commit my new C parser to mainline today once it is
confirmed
that the 4.0 branch has been created and after final testing against
today's mainline on x86_64-unknown-linux-gnu,
powerpc64-unknown-linux-gnu
and ia64-hp-hpux11.23.
The vers
On 2005-02-25, at 05:04, Sam Lauber wrote:
(1) -> Don't say that I'm crazy.
(2) -> Some of us would like
This cheap joke wouldn't be worth the environmental pollution caused
by the requirement to transfer the additional bytes in the common
compiler
distribution. There is enough code baggage GCC i
On 2005-02-26, at 19:53, Daniel Berlin wrote:
In the next week, i'll be posting a test repo with all tags but
snapshots and the 3 tags with rtag -F issues.
Just a few words of encouragement: Keep up the fine work!
More cancellation points have been added for those who have complained
about ctrl-c n
101 - 151 of 151 matches
Mail list logo
