> We've made some progress over the past couple of weeks. Kudos to all
> who have been contributing and reviewing patches! In particular,
>we've made a dent in P2s, and are now down to 134 total regressions
> open.
This numbers are from the link of the main page:
http://gcc.gnu.org/bugzilla/bug
On Nov 27, 2007 4:19 PM, Mark Mitchell <[EMAIL PROTECTED]> wrote:
> 1. I noticed that there are quite a few P2 ICE reports regarding
>variadic templates. Doug Gregor, would you please look into these?
There are patches for a few of these issues (two P2s and a P3) that
still need review; see t
On Tue, 27 Nov 2007, Mark Mitchell wrote:
> > If only static libraries are being built, it may be possible to build them
> > without linking, and in such cases it may be possible to define a generic
> > set of libc symbols considered to be present, as libstdc++-v3/configure.ac
> > does with newlib.
On Nov 27, 2007 8:42 PM, mofomojo <[EMAIL PROTECTED]> wrote:
> P.S. I sent the same help info to the [EMAIL PROTECTED] address as
> well and have yet to receive any response after about 3 hours. Thank
> you very much for reading this.
That is outrageous! 3 Hours? I will send an immediate TPS rep
Joseph S. Myers wrote:
> On Tue, 27 Nov 2007, Mark Mitchell wrote:
>
>> Yes, that makes sense to me. Bare metal systems are of course somewhat
>> different. What do you think about that?
>
> I think it's well established that at least some bare-metal systems
> default to not linking with any p
Alexandre Oliva <[EMAIL PROTECTED]> writes:
> On Nov 26, 2007, Tom Tromey <[EMAIL PROTECTED]> wrote:
>
> > I do wonder if there is a platform out there that acts as if -rdynamic
> > were the default.
>
> I'm pretty sure I was surprised when I first ran into the need for
> -rdynamic on GNU/Linux,
On 2007/11/28, Ismail DAnmez <[EMAIL PROTECTED]> wrote:
> > $ svn -q co svn://gcc.gnu.org/svn/gcc/trunk gcc
> > $ du -s .
> > 1044451 .
> > $
> >
> > It's 1'069'517'824 characters made from keyboards and generators!!!
> >
> > That massive!!! And slower checkout after several minutes!!!
> >
> > Is n
On Wed, Nov 28, 2007 at 03:04:18AM +0100, J.C. Pizarro wrote:
> $ svn -q co svn://gcc.gnu.org/svn/gcc/trunk gcc
> $ du -s .
> 1044451 .
> $
>
> It's 1'069'517'824 characters made from keyboards and generators!!!
Divide by at least 2, since your svn checkout has the files, plus
a database containi
Wednesday 28 November 2007 Tarihinde 04:04:18 yazmıştı:
> $ svn -q co svn://gcc.gnu.org/svn/gcc/trunk gcc
> $ du -s .
> 1044451 .
> $
>
> It's 1'069'517'824 characters made from keyboards and generators!!!
>
> That massive!!! And slower checkout after several minutes!!!
>
> Is not there any another
$ svn -q co svn://gcc.gnu.org/svn/gcc/trunk gcc
$ du -s .
1044451 .
$
It's 1'069'517'824 characters made from keyboards and generators!!!
That massive!!! And slower checkout after several minutes!!!
Is not there any another solution to reduce this massive quantity
for the most recent part of the
When I compile any program with GCC, specifying that it is a .c file
and that I want to compile it as a C-file to produce a binary, I get -
with any file - something like this :
"*any source file here* :stdio.h: No such file or directory"
I have the libraries installed, and EVEN if I specify t
> (Dependencies on native or not are a bad idea. It's much better
> always to do the same thing for a GNU/Linux target - or any other
> target that can also be native - than to do things differently
> depending on whether the same target is native or cross.)
Agreed.
When we have a staged build
On Tue, 27 Nov 2007, Mark Mitchell wrote:
> Yes, that makes sense to me. Bare metal systems are of course somewhat
> different. What do you think about that?
I think it's well established that at least some bare-metal systems
default to not linking with any particular start-files (etc.).
> >
Bernd Schmidt wrote:
> If you wish to approve Jie's original patch, I'm not stopping you.
Do you have a pointer? Otherwise, I'll poke around and find it. I
don't have a preconceived notion here, and I'm not trying to kick up a
big fuss; I'm just trying to understand the situation better.
> Wha
Joseph S. Myers wrote:
> On Tue, 27 Nov 2007, Mark Mitchell wrote:
>
>> In any case, I think this is something that ought to be decided as a
>> global policy for GCC and its run-time libraries, not something that
>> differs between ports. In particular, if run-time libraries are allowed
>> to dep
On Tue, 27 Nov 2007, Benjamin Kosnik wrote:
> > if there is a rule that
> > libstdc++ configure shouldn't try to link anything, it doesn't appear
> > to be well enforced.
>
> The rule is that libstdc++ shouldn't do link tests unless it knows it
> is native. Not "libstdc++ configure shouldn't try
On Tue, 27 Nov 2007, Bernd Schmidt wrote:
> We have two uses for the bfin-elf compiler - building standalone
> applications, and bootstrapping uClibc for
> bfin-uclinux/bfin-linux-uclibc. For the latter, we need -mfdpic and
> -mid-shared-library multilibs, to at least get a libgcc. This always
>
> if there is a rule that
> libstdc++ configure shouldn't try to link anything, it doesn't appear
> to be well enforced.
The rule is that libstdc++ shouldn't do link tests unless it knows it
is native. Not "libstdc++ configure shouldn't try to link anything."
This means that there is a huge bias
On Tue, 27 Nov 2007, Mark Mitchell wrote:
> In any case, I think this is something that ought to be decided as a
> global policy for GCC and its run-time libraries, not something that
> differs between ports. In particular, if run-time libraries are allowed
> to depend on linking in their configu
2007/11/28, Joe Buck <[EMAIL PROTECTED]> wrote:
> On Wed, Nov 28, 2007 at 01:43:48AM +0100, J.C. Pizarro wrote:
> > I'd read "GCC 4.3.0 Status Report (2007-11-27)" from
> > http://gcc.gnu.org/ml/gcc/2007-11/msg00753.html
> >
> > I suppose that there is not time to eliminate many bugs from
> > open
On Wed, Nov 28, 2007 at 01:43:48AM +0100, J.C. Pizarro wrote:
> I'd read "GCC 4.3.0 Status Report (2007-11-27)" from
> http://gcc.gnu.org/ml/gcc/2007-11/msg00753.html
>
> I suppose that there is not time to eliminate many bugs from
> open regressions & others.
>
> Could not we to use "Code covera
Mark Mitchell wrote:
> Bernd Schmidt wrote:
>
>> "libstdc++-v3/configure.ac" AM_PROG_LIBTOOL -> "libtool.m4" LT_INIT ->
>> _LT_SETUP -> _LT_LANG_C_CONFIG -> LT_SYS_DLOPEN_SELF
>>
>> which leads to
>> checking for shl_load... configure: error: Link tests are not allowed
>> after GCC_NO_EXECUTABLES.
Hello.
I'd read "GCC 4.3.0 Status Report (2007-11-27)" from
http://gcc.gnu.org/ml/gcc/2007-11/msg00753.html
I suppose that there is not time to eliminate many bugs from
open regressions & others.
Could not we to use "Code coverage" of the GCC snapshot
during its bootstrapping or testsuite time?
Status
==
We are in Stage 3. When we reach 100 open regressions, we will go to
regression-only mode. When we approach the 4.3.0 release, we will
create a branch, and open Stage 1 for 4.4.0.
Issues
==
1. I noticed that there are quite a few P2 ICE reports regarding
variadic template
Bernd Schmidt wrote:
> "libstdc++-v3/configure.ac" AM_PROG_LIBTOOL -> "libtool.m4" LT_INIT ->
> _LT_SETUP -> _LT_LANG_C_CONFIG -> LT_SYS_DLOPEN_SELF
>
> which leads to
> checking for shl_load... configure: error: Link tests are not allowed
> after GCC_NO_EXECUTABLES.
> make[1]: *** [configure-tar
On Tue, 2007-11-27 at 00:25 +0530, Karthik Kumar wrote:
> I'm not saying we don't use flex/bison. I am only saying we can remove
> that as a build dependancy; Many people have to use specific versions
> of lex (flex) and yacc (bison) if they wish to compile gcc.
I agree with you: end users should
Mark Mitchell wrote:
> Note that libstdc++/configure.ac carefully avoids linking except for
> $GLIBCXX_IS_NATIVE. It's a design property that you should not need to
> link. Where in libstdc++ is it requiring linking?
Jie started the thread back in September, and posted the following call
trace:
Bernd Schmidt wrote:
>> Most targets just do the usual dance of building compilers and libraries
>> interleaved appropriately. For example, we build ARM uClinux compilers
>> without ever building an ARM ELF compiler. Why can't you do that for
>> Blackfin?
>
> It sounds more complicated than wha
Mark Mitchell wrote:
>> We have two uses for the bfin-elf compiler - building standalone
>> applications, and bootstrapping uClibc for
>> bfin-uclinux/bfin-linux-uclibc.
>
> Most targets just do the usual dance of building compilers and libraries
> interleaved appropriately. For example, we buil
Bernd Schmidt wrote:
>>> But why isn't that a problem with the target libraries or the way in
>>> which GCC is being configured? Why don't we have that problem for MIPS
>>> or Power, given that they don't link with a target board by default either?
>
> That's not something I can answer, being un
Mark Mitchell wrote:
>> Bernd Schmidt wrote:
>>
If -mfdpic doesn't make sense for Blackfin, shouldn't it just be an
error? Why accept it, but make it imply the simulator?
>>> Because all the target libraries fail to build if the configure tests
>>> don't link.
>>
>> But why isn't that
Bernd Schmidt wrote:
>> If -mfdpic doesn't make sense for Blackfin, shouldn't it just be an
>> error? Why accept it, but make it imply the simulator?
>
> Because all the target libraries fail to build if the configure tests
> don't link.
But why isn't that a problem with the target libraries or
Mark Mitchell wrote:
> Bernd Schmidt wrote:
>
>> I've committed the following to take care of this. Neither -mfdpic nor
>> -mid-shared-library are actually useful with bfin-elf toolchains, but by
>> making them imply -msim, we can at least get these kinds of configure
>> test executables to link.
Bernd Schmidt wrote:
> I've committed the following to take care of this. Neither -mfdpic nor
> -mid-shared-library are actually useful with bfin-elf toolchains, but by
> making them imply -msim, we can at least get these kinds of configure
> test executables to link.
My impression was that we'd
On Tuesday 27 November 2007 15:50, Andreas Schwab wrote:
> Stephane Hockenhull <[EMAIL PROTECTED]> writes:
> > now, if only someone actually knew where in the g++ source code the
> > special case for std::string is
>
> grep is your friend. Look for find_substitution in cp/mangle.c.
>
> Andreas.
*
On Tuesday 27 November 2007 15:40, Andrew Pinski wrote:
> On 11/27/07, Stephane Hockenhull <[EMAIL PROTECTED]> wrote:
> > no, it would not.
> > because for one simple fact: COFF format lacks many features of ELF.
>
> What features are missing? COFF is not used for Windows 32 anyways,
> it is PE-CO
Stephane Hockenhull <[EMAIL PROTECTED]> writes:
> now, if only someone actually knew where in the g++ source code the special
> case for std::string is I could fix that, provide a patch, and make the world
> a little bit better.
Actually I think you rather want to look for places that use
USER_
Stephane Hockenhull <[EMAIL PROTECTED]> writes:
> now, if only someone actually knew where in the g++ source code the special
> case for std::string is
grep is your friend. Look for find_substitution in cp/mangle.c.
Andreas.
--
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products
On Tue, Nov 27, 2007 at 12:19:40PM -0800, Bruce Korb wrote:
> > To do anything about a bug, the developers will need a complete test
> > case that produces the bug. Changes to the test case that *don't*
> > produce a bug are not interesting.
>
> If it is worth chasing. It is not worth chasing if
On 11/27/07, Stephane Hockenhull <[EMAIL PROTECTED]> wrote:
> no, it would not.
> because for one simple fact: COFF format lacks many features of ELF.
What features are missing? COFF is not used for Windows 32 anyways,
it is PE-COFF. I am just wondering what exactly is missing that you
think you
On Tuesday 27 November 2007 14:00, Dave Korn wrote:
> On 27 November 2007 18:47, 'Daniel Jacobowitz' wrote:
> > On Tue, Nov 27, 2007 at 06:39:09PM -, Dave Korn wrote:
> >>> joking aside, we need to generate ELF object files for running on
> >>> windows.
> >>
> >> OK, you are now attempting so
On Nov 27, 2007 12:03 PM, Joe Buck <[EMAIL PROTECTED]> wrote:
> gcc-3.3 is quite old and is no longer maintained, though if the bug you
> found is still present in current sources, it should be reported.
I know. Debian's fresh releases are always full of really old stuff.
Anyway, 4.1 too:
$ /usr/
On Tue, Nov 27, 2007 at 11:51:18AM -0800, Bruce Korb wrote:
> $ /usr/bin/gcc-3.3 -I../../tpd-include -E -DKERNEL_26 emlib.c -o emlib.i
> cc1: internal compiler error: Segmentation fault
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See http://gcc.gnu.org/bugs.htm
On Nov 26, 2007, Tom Tromey <[EMAIL PROTECTED]> wrote:
> I do wonder if there is a platform out there that acts as if -rdynamic
> were the default.
I'm pretty sure I was surprised when I first ran into the need for
-rdynamic on GNU/Linux, because other platforms I'd used didn't need
that. I'd gu
J.C. Pizarro wrote:
For your Opteron, try with this option
-O3 -fomit-frame-pointer -march=k8 -funroll-loops -finline-functions
-fpeel-loops \
-mno-sse3 -msse2 -msse -mno-mmx -mno-3dnow
The Opteron hardware said that it's better to use SSE2 than SSE3.
The MMX and 3DNow!+ instructions are shorte
$ /usr/bin/gcc-3.3 -I../../tpd-include -E -DKERNEL_26 emlib.c -o emlib.i
cc1: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
For Debian GNU/Linux specific bug reporting instr
On Nov 27, 2007, Michael Matz <[EMAIL PROTECTED]> wrote:
> Hi,
> On Mon, 26 Nov 2007, Alexandre Oliva wrote:
>> >> And then, you have to tweak everything else to keep the note that
>> >> replaced the set up to date as you further optimize the code.
>>
>> > No. remove_insn() would replace the SE
On 27 November 2007 18:47, 'Daniel Jacobowitz' wrote:
> On Tue, Nov 27, 2007 at 06:39:09PM -, Dave Korn wrote:
>>> joking aside, we need to generate ELF object files for running on windows.
>>
>> OK, you are now attempting something very very wrong indeed. The win32
>> version of the assem
On Tue, Nov 27, 2007 at 06:39:09PM -, Dave Korn wrote:
> > joking aside, we need to generate ELF object files for running on windows.
>
> OK, you are now attempting something very very wrong indeed. The win32
> version of the assembler will not generate ELF files, and even if it did,
> wind
On 27 November 2007 17:35, Stephane Hockenhull wrote:
> On Tuesday 27 November 2007 11:09, you wrote:
>> On 27 November 2007 15:49, Stephane Hockenhull wrote:
>>> on the win32 platform all C symbols requires a leading underscore
>>
>> Yes, that is the case on almost all platforms.
>>
>> And
Rask Ingemann Lambertsen wrote:
I have a simple loop over the defs of an INSN, looking for the def of a
specific register X:
Should I just compare register numbers instead?
I think so, or maybe even use reg_overlap_mentioned_p. It depends what
you're doing. For 4.4, it may be worth mo
Joseph S. Myers wrote:
On Tue, 27 Nov 2007, Michael Eager wrote:
I think that there is a pervasive understanding that SImode is
single precision integer, 32-bits long.
Only among contributors not considering non-8-bit bytes. SImode is 4
times QImode, 4*BITS_PER_UNIT bits, and may not exist
On 11/26/07, Joseph S. Myers <[EMAIL PROTECTED]> wrote:
> On Mon, 26 Nov 2007, Paolo Bonzini wrote:
>
> > On the other hand, if it is meant for human usage the file list is already a
> > clue to spot "wrong" commits. Then, an equivalent but more versatile
> > feature
> > request would be to have
On Tue, 27 Nov 2007, Michael Eager wrote:
> I think that there is a pervasive understanding that SImode is
> single precision integer, 32-bits long.
Only among contributors not considering non-8-bit bytes. SImode is 4
times QImode, 4*BITS_PER_UNIT bits, and may not exist (or at least not be
pa
Joseph S. Myers wrote:
On Mon, 26 Nov 2007, Michael Eager wrote:
Well, can't do that. This is not target dependent.
DImode gets defined, and used, for long long in unwind-dw2.c.
Is it defined what DWARF unwind information looks like when made up of
bytes wider than 8 bits? Certainly GCC's
On Tuesday 27 November 2007 11:09, you wrote:
> On 27 November 2007 15:49, Stephane Hockenhull wrote:
> >> But why are you using -fleading-underscore?
> >
> > on the win32 platform all C symbols requires a leading underscore
>
> Yes, that is the case on almost all platforms.
>
> And the compile
Hi,
On Mon, 26 Nov 2007, Alexandre Oliva wrote:
> >> And then, you have to tweak everything else to keep the note that
> >> replaced the set up to date as you further optimize the code.
>
> > No. remove_insn() would replace the SET with a note.
>
> What information would this note convey?
Oh
I have a simple loop over the defs of an INSN, looking for the def of a
specific register X:
struct df_ref **defs;
for (defs = DF_INSN_DEFS (insn);
*defs && !rtx_equal_p (DF_REF_REG (*defs), x);
defs++)
;
It doesn't work because the modes don't match:
(gdb) call debug
Andi Kleen writes:
> Andrew Haley <[EMAIL PROTECTED]> writes:
>
> > Howard Chu writes:
> >
> > > A bit of a minor mystery. Not a problem, just a curiosity. If
> > > someone knew off the top of their head a reason for it, that'd be
> > > cool, but otherwise no sweat.
> >
> > It's possib
On 27 November 2007 16:10, Dave Korn wrote:
> Yes, but as you yourself explain, the symbols already have leading
> underscores, and when you use -fleading-underscore, because it fails to
^
... when you use -fleading-underscores, *a problem
Richard Guenther wrote:
On Nov 27, 2007 2:23 PM, Howard Chu <[EMAIL PROTECTED]> wrote:
A bit of a minor mystery. Not a problem, just a curiosity. If someone knew off
the top of their head a reason for it, that'd be cool, but otherwise no sweat.
I'd try -Os, you might run into ICache limitation
On 27 November 2007 15:49, Stephane Hockenhull wrote:
>> But why are you using -fleading-underscore?
>
> on the win32 platform all C symbols requires a leading underscore
Yes, that is the case on almost all platforms.
And the compiler *automatically* puts leading underscores on symbols on a
On Monday 26 November 2007 22:48, Daniel Jacobowitz wrote:
> It's the default for a lot of targets. I'd still like to see a
> concrete example of the problem...
we're cross-compiling to win32, everything works fine until we use the
std::string template,
the special case name mangling for std::s
Andrew Haley <[EMAIL PROTECTED]> writes:
> Howard Chu writes:
>
> > A bit of a minor mystery. Not a problem, just a curiosity. If
> > someone knew off the top of their head a reason for it, that'd be
> > cool, but otherwise no sweat.
>
> It's possible, although unlikley, that the optimized code
On Monday 26 November 2007 19:29, Joe Buck wrote:
> On Mon, Nov 26, 2007 at 04:02:48PM -0500, Stephane Hockenhull wrote:
> > On Monday 26 November 2007 14:01, Daniel Jacobowitz wrote:
> > > On Mon, Nov 26, 2007 at 10:40:35AM -0800, Joe Buck wrote:
> > > > On Mon, Nov 26, 2007 at 01:33:54PM -0500, S
On Mon, 26 Nov 2007, Michael Eager wrote:
> Well, can't do that. This is not target dependent.
> DImode gets defined, and used, for long long in unwind-dw2.c.
Is it defined what DWARF unwind information looks like when made up of
bytes wider than 8 bits? Certainly GCC's code won't allow for it
On Nov 27, 2007 7:42 PM, Praveen D V <[EMAIL PROTECTED]> wrote:
> hi,
> I was earlier using 3.x.x version where I used -fdump-translation-unit to dump
> "typedef" tree. Recently I upgraded to 4.1.x version, unfortunately,
> that doesn't
> dump the tree any more. From documentation, it mentions i
Richard Guenther wrote:
> On Nov 27, 2007 2:23 PM, Howard Chu <[EMAIL PROTECTED]> wrote:
>> A bit of a minor mystery. Not a problem, just a curiosity. If someone knew
>> off
>> the top of their head a reason for it, that'd be cool, but otherwise no
>> sweat.
>
> I'd try -Os, you might run into I
hi,
I was earlier using 3.x.x version where I used -fdump-translation-unit to dump
"typedef" tree. Recently I upgraded to 4.1.x version, unfortunately,
that doesn't
dump the tree any more. From documentation, it mentions it is for
"C++". I need it
for "C".
It is a very useful utility. Are ther
For your Opteron, try with this option
-O3 -fomit-frame-pointer -march=k8 -funroll-loops -finline-functions
-fpeel-loops \
-mno-sse3 -msse2 -msse -mno-mmx -mno-3dnow
The Opteron hardware said that it's better to use SSE2 than SSE3.
The MMX and 3DNow!+ instructions are shorter and older than SSE2/
Howard Chu writes:
> A bit of a minor mystery. Not a problem, just a curiosity. If
> someone knew off the top of their head a reason for it, that'd be
> cool, but otherwise no sweat.
It's possible, although unlikley, that the optimized code has worse
cache behaviour. No way to know better wit
Richard Guenther wrote:
With a "scripted pass manager" I of course ment a pass manager that
allows re-configuration of the pass pipeline without re-compiling. For
example by embeding LUA (or another tiny scripting language).
Regarding such configurability of the pass manager the GCC ICI pro
On Nov 27, 2007 2:23 PM, Howard Chu <[EMAIL PROTECTED]> wrote:
> A bit of a minor mystery. Not a problem, just a curiosity. If someone knew off
> the top of their head a reason for it, that'd be cool, but otherwise no sweat.
I'd try -Os, you might run into ICache limitations.
Richard.
>
A bit of a minor mystery. Not a problem, just a curiosity. If someone knew off
the top of their head a reason for it, that'd be cool, but otherwise no sweat.
Original Message
Subject: Re: commit: ldap/servers/slapd connection.c daemon.c proto-slap.h
syncrepl.c
Date: Tue, 27 N
Hi,
2007/11/27, Brian Dessent <[EMAIL PROTECTED]>:
> Cygwin is not a target where libgomp is enabled by default, though it
> probably should be since it strives for POSIX. You have to
> --enable-libgomp explicitly if you want to build it.
Thanks. Now it works.
Joerg
--
http://www.joerg.froch
Jie Zhang wrote:
> Bernd Schmidt wrote:
>> Jie Zhang wrote:
>>> Bernd Schmidt wrote:
Jie Zhang wrote:
> But by design if gcc_no_link = no, link tests should be avoided.
??? I would have thought gcc_no_link = yes means link tests are
avoided.
>>> Oops, I meant gcc_no_lin
Michael Eager <[EMAIL PROTECTED]> writes:
> Ross Ridge wrote:
>> Miceal Eagar writes:
>>> I'm working with a target that has 32-bit word addressing,
>>> so there is a define of BITS_PER_UNIT = 32.
>>
>> According to the documentation, this changes the size of a byte to 32
>> bits, instead of the m
77 matches
Mail list logo
