INPUT for broken name-lookup in gcc4.0.0

ith fgrep 50 times in name-lookup.c ) I have browsed the GNU GCC 4.0.0 bug list and found that name-lookup is broken. The build was not stopped by above mentioned warnings (that could be the reason why it didn't get recognized). Maybe above information can help fixing the problem. kind regards Daniel Wyss

Re: Tracking down source of libgcc_s.so compatibility?

On Wed, Jun 08, 2005 at 05:05:58PM -0700, Daniel Kegel wrote: > Daniel Jacobowitz wrote: > >Daniel Kegel wrote: > >>Can somebody suggest a place to start looking for > >>why the libgcc_s.so built by crosstool's gcc-3.4 can't handle > >>exception

Re: Use of check_vect() in vectorizer testsuite

lue to compile if we can not run the test. I thought we already did that, but I appear to be mistaken. -- Daniel Jacobowitz CodeSourcery, LLC

re: A Suggestion for Release Testing

Scott wrote: > Given the recent problems with the 4.0.0 release and major packages like > KDE and the kernel, has anyone considered testing releases by completely > compiling a Linux system? It's kind of hard to do for a new major release, since the apps and kernel might not be ported yet, but 4.

Re: Fw: Can't bootstrap mainline on powerpc64-linux

odd on this, Adrian changed the name of prototype and then later Daniel came along and fixed prototype of "old" name. 2005-06-09 Daniel Berlin <[EMAIL PROTECTED]> * config/rs6000/rs6000.c: (rs6000_insn_valid_within_doloop): Fix prototype. Before i committed this,

Re: Big differences on SpecFP results for gcc and icc

On Sun, 2005-06-12 at 11:21 +0200, Uros Bizjak wrote: > Hello! > > There is an interesting comparison of SPEC scores between gcc and icc: > http://people.redhat.com/dnovillo/spec2000.i686/gcc/individual-run-ratio.html > . A quick look at the graphs shows a big differences in achieved scores > b

Re: GCC 4.0.1 Status (2005-06-13)

Scott Robert Ladd wrote: Mark Mitchell wrote: 2. Jakub Jelinek reports that we're miscompiling GLIBC. [I think this is http://gcc.gnu.org/PR22043 ] The latter problem seems to me to be as severe as the KDE bug that was the impetus for this release. ... Agreed. I've had mixed reports from

Re: Tracking down source of libgcc_s.so compatibility?

Mike Hearn wrote: On Thu, 09 Jun 2005 15:47:31 +0200, Marcin Dalecki wrote: NTPL vers. non NTPL signal handling differences. The FC3 compiler contains some "backward compatibility" shims at quite a few places, which are allowing old binaries to execute. However stuff compiled with the FC3 versi

Re: PATCH: Explicitly pass --64 to assembler on AMD64 targets

icit, an x86_64-linux compiler would Just Work. Which would be nice since that's what config.guess says to build :-) -- Daniel Jacobowitz CodeSourcery, LLC

Re: x86 Q: why aren't the SSE intrinsics always_inline?

riori you'd > decide which ones. It'd be better to handle this in gdb than in gcc, sure. There's two parts: better support for inline functions, which is already on the gdb roadmap, and then some way of selecting which ones to ignore. And for that latter, I have no idea how it should look... -- Daniel Jacobowitz CodeSourcery, LLC

Re: PATCH: Explicitly pass --64 to assembler on AMD64 targets

ag, CODE_64BIT}, > > but they only switch ASM encoding, not the output ELF file format as > they are intended for stuff where you really mix 32bit and 64bit code, > such as in the boot loader. So, we would need different directives for this purpose. I like the idea, though it woul

Bug in transparent union handling?

It seems the structure aliasing patch exposed what appears to be a bug in the C FE. Our docs on transparent union say "@item transparent_union This attribute, attached to a function parameter which is a union, means that the corresponding argument may have the type of any union member, but the arg

Re: [Gdb-discuss] Re: x86 Q: why aren't the SSE intrinsics always_inline?

[Redirecting off gdb-discuss again] On Tue, Jun 14, 2005 at 09:12:39PM -0400, Fred Fish wrote: > On Tuesday 14 June 2005 10:55, Daniel Jacobowitz wrote: > > better support for inline functions, which is already on the gdb > > roadmap > > Where's the roadmap? I'

Re: Visual C++ style inline asms

. Not all of us use Microsoft compilers. > Didn't RTH objected the last time? You can find plenty of information about this in the archives. I recall Stan Shebs discussing it at length. -- Daniel Jacobowitz CodeSourcery, LLC

Re: GCC 4.0.1 Status (2005-06-13)

R Hill <[EMAIL PROTECTED]> wrote: > Dan Kegel wrote: (Interestingly, the fixes in glibc-cvs seem to have been made in such a way that the new glibc won't be compilable by older versions of gcc, like gcc-3.4.4. I guess the thinking is that everyone should be using the latest gcc?) Hmm, do you

Re: Reporting bugs: there is nothing to gain in frustrating reporters

On Wed, 2005-06-15 at 12:13 -0400, Scott Robert Ladd wrote: > Richard Guenther wrote: > > On 6/15/05, Scott Robert Ladd <[EMAIL PROTECTED]> wrote: > >>But an objection from one of the bugmasters *is* enough to keep people > >>from presenting a patch. > > > > How do you come to this conclusion? Fr

Re: Reporting bugs: there is nothing to gain in frustrating reporters

On Thu, 16 Jun 2005, Vincent Lefevre wrote: On 2005-06-16 07:43:17 -0400, Daniel Berlin wrote: Again, please point to specific examples. GCC developers don't want examples. I'm sorry to interrupt your trolling, but you'll note 1. I'm a GCC developer 2. I asked for s

Re: Reporting bugs: there is nothing to gain in frustrating reporters

On Thu, 2005-06-16 at 14:03 +0200, Vincent Lefevre wrote: > On 2005-06-16 07:43:17 -0400, Daniel Berlin wrote: > > Again, please point to specific examples. > > GCC developers don't want examples. > I should also note that *you* seem to equate "disagreement with

Re: Reporting bugs: there is nothing to gain in frustrating reporters

On Thu, 2005-06-16 at 14:08 +0200, Vincent Lefevre wrote: > On 2005-06-15 18:18:23 -0400, Andrew Pinski wrote: > > But if you look how old it is, it is before really any bugmaster > > started. Also a main developer, RTH, closed it and he has been > > working on GCC since before 1999. > > I'm answe

Re: Reporting bugs: there is nothing to gain in frustrating reporters

On Thu, 2005-06-16 at 13:35 +0100, Haren Visavadia wrote: > --- Daniel Berlin wrote: > > Again, this is a place where you disagree that this > > should be considered > > a "bug", but refuse to believe that reasonable > > people can disagree on > >

Re: Reporting bugs: there is nothing to gain in frustrating reporters

On Thu, 2005-06-16 at 10:13 -0400, Scott Robert Ladd wrote: > Daniel Berlin wrote: > > Maybe you should start naming names, so we can take stock of the > > problem. > > Because of Acovea and my reviews of GCC (there are two more coming, one > in a print magazine),

Re: Reporting bugs: there is nothing to gain in frustrating reporters

On Thu, 2005-06-16 at 10:51 -0400, Scott Robert Ladd wrote: > Dan Kegel wrote: > > And then there's the GCC summit, if you're really serious. > > I'd certainly love to attend, but can't afford it with the medical bills > we've accumulated. Hospitalizing both the primary bread-winners has a > drama

Re: Fixing Bugs (Was: A Suggestion for Release Testing)

On Thu, 2005-06-16 at 10:30 -0400, Scott Robert Ladd wrote: > Aaron W. LaFramboise wrote: > > Boosters, FreeBSD hackers, and I'm sure tons of others are calling this > > the "Bicycle shed effect." > > > > > > If I'

Re: Reporting bugs: there is nothing to gain in frustrating reporters

On Thu, 2005-06-16 at 10:58 -0400, Scott Robert Ladd wrote: > Daniel Berlin wrote: > > Again, *please* provide examples other than "The bugmasters are mean". > > Don't invent quotes. I never said anyone was "mean." And other people > have provided ex

Re: Major regression in 4.1.

On Fri, 17 Jun 2005 [EMAIL PROTECTED] wrote: Does this look familiar to anyone? It certainly was happening a few days ago. Shouldn't a bootstrap and regression of all frontend be required before someone checks in a patch to the back-end? Indeed. The last working GCC-4.1 compiler for both M

Re: Bugzilla queries extremely slow

I cannot make sourceware faster, unfortunately :) I can make sure all the queries are using the right indexes, etc, which i do. (I monitor index/key efficiency on the server, as well as number of temp tables created, scanned, blah blah blah) On Sun, 2005-06-19 at 15:04 +0200, Paolo Carlini wrot

Getting to the gcc summit

For those who are attending the gcc summit for the first time, here's a page with a bit more detail about how to get from the airport to the hotel, etc. http://kegel.com/gcc/summit2005.html It's pretty easy, but I remember figuring it out the first time was harder, so I figured a page of notes

Re: Someone introduced a libiberty crashing bug in the past week

On Mon, 2005-06-20 at 16:05 +, Joseph S. Myers wrote: > On Mon, 20 Jun 2005, Daniel Berlin wrote: > > > The crash line is > > 3729 if (pedantic && !DECL_IN_SYSTEM_HEADER (fundecl)) > > > > Here, fundecl is null. > > Any pr

Re: -fprofile-arcs changes the structure of basic blocks

On Thu, 23 Jun 2005, Liu Haibin wrote: Hi, I want to use profiling information. I know there're two relevent fields in each basic block, count and frequency. I want to use frequency because the compiled program is for another architecture so it cannot run on the host. Besides the fact that, a

Re: toplevel bootstrap (stage 2 project)

On Tue, 2005-06-28 at 11:43 +0200, Giovanni Bajo wrote: > Gerald Pfeifer <[EMAIL PROTECTED]> wrote: > > >> It would help also if you add to the wiki explanation of what exactly all > >> these options do. Especially bubblestrap vs quickstrap vs restrap. > > > > Why to the WIki?? This should be par

Re: Do C++ signed types have modulo semantics?

was naive in assuming that this wouldn't have a big optimization impact. Reiterating my response to Daniel, if it is in fact the case that this is a major loss for optimization, then I would have to retract my claim. I've got some notes in to various XLC people to get info if they

Re: GCC-4.1.0 size optimization bug for MIPS architecture...

On Wed, 2005-06-29 at 07:44 -0500, Steven J. Hill wrote: > Richard Henderson wrote: > > > > Not a bug. The inline marker is merely suggestive. You told > > the compiler to optimize for size, and it is doing that. > > > > If you absolutely have to have the function inlined, then you > > need to

Re: Do CO++ signed types have modulo semantics?

> Overall, I guess I still simply believe the the first rule of optimization > is to preserve existing semantics unless explicitly authorized otherwise, > and then only if accompanied with corresponding warnings for all potentially > behavior altering assumptions applied. It is, you just believe

Re: named address spaces (update)

name. BTW, you may get more comments if all of your text is before all of the patches; I nearly missed three quarters of your message :-) -- Daniel Jacobowitz CodeSourcery, LLC

Re: Statement expression with function-call variable lifetime

; lifetime of the statement expression? Yes, that's correct (and the only way to do this). -- Daniel Jacobowitz CodeSourcery, LLC

Re: Do C++ signed types have modulo semantics?

On Wed, 2005-06-29 at 18:46 +0200, Steven Bosscher wrote: > On Tuesday 28 June 2005 14:09, Steven Bosscher wrote: > > On Tuesday 28 June 2005 14:02, Ulrich Weigand wrote: > > > Steven Bosscher wrote: > > > > Anyway, I've started a SPEC run with "-O2" vs. "-O2 -fwrapv". Let's > > > > see how big th

PARM_DECL of DECL_SIZE 0, but TYPE_SIZE of 96 bits

Why is that C++ can't create normal DECL's like everyone else? Case in point: (gdb) unit size ... addressable used BLK file minimal.c line 194 size unit size $11 = void (gdb) y So we've got a parm decl that if you ask it for the DECL_SIZE, says 0, but has a TYPE_SIZE of 12 by

Re: PARM_DECL of DECL_SIZE 0, but TYPE_SIZE of 96 bits

On Wed, 2005-06-29 at 16:55 -0700, Richard Henderson wrote: > On Wed, Jun 29, 2005 at 06:57:12PM -0400, Daniel Berlin wrote: > > I'm going to work around this by using TYPE_SIZE, but it would be nice > > if somebody could explain the purpose for this behavior (if it's a

Re: Pro64-based GPLed compiler

On Wed, 2005-06-29 at 14:01 -0400, Vladimir Makarov wrote: > Marc Gonzalez-Sigler wrote: > > > Hello everyone, > > > > > > I've taken PathScale's source tree (they've removed the IA-64 code > > generator, and added an x86/AMD64 code generator), and tweaked the > > Makefiles. > > > > I thought so

Re: PARM_DECL of DECL_SIZE 0, but TYPE_SIZE of 96 bits

On Thu, 2005-06-30 at 20:47 +0200, Giovanni Bajo wrote: > Daniel Berlin <[EMAIL PROTECTED]> wrote: > > > So we've got a parm decl that if you ask it for the DECL_SIZE, says 0, > > but has a TYPE_SIZE of 12 bytes, and we access fields in it, etc. > > > I a

Re: Pro64-based GPLed compiler

On Thu, 2005-06-30 at 18:23 -0400, Vladimir Makarov wrote: > James E Wilson wrote: > > > Daniel Berlin wrote: > > > >> A bunch of random code #ifdef KEY'd > > > > > > FYI Pathscale was formerly known as Key Research. So the KEY probably > >

Re: updating libtool, etc.

Do you mean "do mind" or "don't mind" there? If you want to update libtool, you get to play the all-of-src-uses-it game. I have been updating src directories to more recent autoconf versions in the hope of getting rid of our outdated libtool someday. I believe the only remaining holdout is newlib, but I didn't check everything. -- Daniel Jacobowitz CodeSourcery, LLC

Re: [C++] Re: PARM_DECL of DECL_SIZE 0, but TYPE_SIZE of 96 bits

On Thu, 2005-06-30 at 14:11 -0700, Geoffrey Keating wrote: > Richard Henderson <[EMAIL PROTECTED]> writes: > > > On Wed, Jun 29, 2005 at 09:17:07PM -0400, Daniel Berlin wrote: > > > 1. In require_complete_types_for_parms, in the C++ FE, reset DECL_SIZE > > > t

Re: Pro64-based GPLed compiler

't well tuned for 32-bit performance and/or > Intel parts. Anyways, from what Daniel Berlin mentioned, it may be that > the tree-ssa stuff in gcc4.x has negated much of their earlier advantage. I would not be surprised if they kick the crap out of us when it comes to numerical fortran o

Re: Should GCC publish a general rule/warning due to it's default presumption of undefined signed integer overflow semantics?

On Fri, 2005-07-01 at 03:39 +0200, Gabriel Dos Reis wrote: > Joe Buck <[EMAIL PROTECTED]> writes: > > | On Thu, Jun 30, 2005 at 09:02:48PM -0400, Andrew Pinski wrote: > | > But the reason question is why make it an undefined behavior instead of > | > an implementation defined? This would have mad

Re: updating libtool, etc.

ch over one at a time. Somebody who cares really has to update newlib soon, though! -- Daniel Jacobowitz CodeSourcery, LLC

Re: var_tracking question

On Fri, 2005-07-01 at 11:50 +0200, Jakub Jelinek wrote: > On Thu, Jun 30, 2005 at 09:25:47PM -0400, DJ Delorie wrote: > > > > My m32c port is generating tracking notes that look like this: > > > > (var_location 0x2a95758dd0 (parallel [ > > (expr_list:REG_DEP_TRUE (reg/v:SI 0 r0 [orig:

SVN test repo updated and call for help

The svn test repo has been updated on dberlin.org. Please don't rape my bandwidth or my disk i/o :) svn://www.dberlin.org/ Commits to the hooks dir will be reflected in the actual repository hooks through the nice sync script. If people help convert the contrib scripts and the current cvs repos

Re: Bugzilla does not let me in

On Mon, 2005-07-04 at 15:03 +0400, Ilya Mezhirov wrote: > Hi, > > > I've got a problem: bugzilla sends me no registration e-mails. > I tried two times with different e-mail addresses and got nothing. > So I cannot report a gcj bug :( I verified the emails were getting sent to your address (or at

Re: The origin of scalar evolutions?

On Mon, 2005-07-04 at 12:31 -0400, Robert van Engelen wrote: > Hi, > > I am interested in the recent work in gcc 4.0 with respect to "scalar > evolutions". The students in my compiler laboratory studied the > algorithm implemented in gcc 4.0. We are considering extending this > work based on ou

Re: A trouble with libssp in one-tree builds

come up with a way to build the compiler and libraries at different times. -- Daniel Jacobowitz CodeSourcery, LLC

Re: PARM_DECL of DECL_SIZE 0, but TYPE_SIZE of 96 bits

On Tue, 2005-07-05 at 08:35 -0700, Mark Mitchell wrote: > Daniel Berlin wrote: > > > 3. Not call layout_decl on the template types until they are completed. > > In the abstract, this is the best choice. Although we need to know that > types are complete (which

gcc-4.1-20050702 ICE in cgraph_early_inlining, at ipa-inline.c:990

I get this error compiling linux-2.6.11.3 with gcc-4.1-20050702 on many targets: drivers/char/random.c: In function 'extract_entropy': drivers/char/random.c:634: sorry, unimplemented: inlining failed in call to 'add_entropy_words': function not considered for inlining drivers/char/random.c:1325:

Re: gcc-4.1-20050702 ICE in cgraph_early_inlining, at ipa-inline.c:990

Jan Hubicka <[EMAIL PROTECTED]> wrote: I get this error compiling linux-2.6.11.3 with gcc-4.1-20050702 on many targets: drivers/char/random.c:1813: internal compiler error: in cgraph_early_inlining, at ipa-inline.c:990 I don't have the preprocessed source handy, but I can provide it if this h

Re: help:how to get the Nth argument stmt from CALL_EXPR stmt tree

On Tue, 2005-07-05 at 23:18 +0800, alert7 wrote: > hi,all > > > I don't know how to get the Nth argument stmt from CALL_EXPR stmt tree? assuming TREE_CODE (call) == CALL_EXPR: GetCallArgOperand(tree call, int i) { int j = 0; tree arg; for (arg = TREE_OPERAND (

Re: [PR22319] Ada broken with ICE in tree-ssa-structalias...

Try the attached patch. On Wed, 2005-07-06 at 06:54 -0400, Geert Bosch wrote: > This is http://gcc.gnu.org/PR22319. > > On Jul 6, 2005, at 06:17, Andreas Schwab wrote: > > Andreas Jaeger <[EMAIL PROTECTED]> writes: > > > > > >> Building ada with the patch for flag_wrapv fails now with a new > >

Re: Existing tree functionality?

Most of this can be found in the cgraph nodes. The rest requires scanning the IL. Ken Zadeck should have code to do this. On Wed, 2005-07-06 at 08:32 -0400, Michael Tegtmeyer wrote: > Hello, > > Is there existing functionality somewhere to sweep a function and collect > all externally visible

Re: Existing tree functionality?

On Wed, 2005-07-06 at 08:46 -0400, Daniel Berlin wrote: > Most of this can be found in the cgraph nodes. The rest requires > scanning the IL. > Ken Zadeck should have code to do this. > Oh, i assumed you were trying to work at an interprocedural level. If you only ever care to

Re: Existing tree functionality?

On Wed, 2005-07-06 at 09:40 -0400, Michael Tegtmeyer wrote: > Thanks-intraprocedural is all I need. > > Sorry, bit new to gcc internals (coming from SUIF), is anything missing > from referenced_vars list or is it complete? It is a complete list of variables *referenced from this function*. > d

Re: [PR22319] Ada broken with ICE in tree-ssa-structalias...

On Wed, 2005-07-06 at 10:35 -0400, Richard Kenner wrote: > Try the attached patch. > > In the case where I saw this ICE, the tree generated by Ada was not valid > (had a type mismatch on a MODIFY_EXPR). So the patch you sent may not > necessarily be needed. Well, it's actually still needed i

Re: Re: help:how to get the Nth argument stmt from CALL_EXPR stmt tree

On Wed, 2005-07-06 at 23:30 +0800, alert7 wrote: > Daniel Berlin,您好！ > > I'am gcc beginner,thank your answer . > > Is it the return Value of GetCallArgOperand function that u given stmt > tree? No. > > I pass return value--ops to funct

Re: Building cross-compilers with sibling package trees

Joe Buck wrote: On Wed, Jul 06, 2005 at 12:49:52PM -0700, Doug Evans wrote: Building a cross compiler from scratch "just works" (as in all one has to do is "configure, make all install") if all of binutils, gcc, newlib, libgloss, libstdc++, etc. are siblings. [At least this use to "just work".]

Re: Existing tree functionality?

On Thu, 2005-07-07 at 09:31 -0400, Michael Tegtmeyer wrote: > I'm using gcc initially to do some static analysis with the resuts being > sent somewhere else for the time being. I basically just need to gather > the variables with visibility outside of the current function. In addition > I need a

Re: Existing tree functionality?

On Thu, 2005-07-07 at 12:40 -0400, Michael Tegtmeyer wrote: > > pass_init_datastructures is still necessary. > > That was the problem-thanks. > > New question (or still the original rather), is there existing > functionality to obtain the variables used in a function with external > visibility

4.1 news item

I was thinking we maybe should just copy the checked in project list from the wiki, remove the duplicates (IE struct aliasing part I and II, etc), and add a news item saying: "GCC 4.1 stage 2 is now closed. The following projects were contributed: . Thank you to all contributors, testers, and ev

Re: move specs documentation to internals manual?

someone should compare the two existing bits of documentation first, since IIRC I've seen people add to one but not the other. -- Daniel Jacobowitz CodeSourcery, LLC

Re: x86 build is broken

On Fri, 2005-07-08 at 17:13 -0700, Fariborz Jahanian wrote: > Tried building fsf mainline on x86-darwin. Syntax error compiling c- > common.c. The preprocessed file shows the following: > as of when? I bootstrapped and tested x86_64-unknown-linux-gnu and x86-linux-gnu and powerpc-linux-gnu in t

Re: 4.1 news item

On Fri, 2005-07-08 at 23:39 +0200, Gerald Pfeifer wrote: > On Fri, 8 Jul 2005, Daniel Berlin wrote: > > I was thinking we maybe should just copy the checked in project list > > from the wiki, remove the duplicates (IE struct aliasing part I and II, > > etc), and a

Re: gcc 4.1 compile time and memory usage graphs

On Sun, 2005-07-10 at 16:46 +0400, Serge Belyshev wrote: > Hi, > > I have measured compilation time and memory usage of mainline on x86_64 > from 2005-02-25 to 2005-07-10 with one day interval. So does Jan, and to be honest, his tester is better than your graphs, because it knows the difference be

Re: Some notes on the Wiki (was: 4.1 news item)

On Sun, 2005-07-10 at 19:31 +0200, Gerald Pfeifer wrote: > I noticed that the Wiki is getting more and more of a third place where > to find documentation in addition of gcc/doc and wwwdocs, and a parallel > universe at that, with quite some duplication and inconsistencies. Have you not yet discov

Re: Some notes on the Wiki (was: 4.1 news item)

we provide and how to make use of provided alias info, data dependence info, immediate uses, etc) F. Reference guide for analysis providers in RTL. On Sun, 2005-07-10 at 13:53 -0400, Daniel Berlin wrote: > On Sun, 2005-07-10 at 19:31 +0200, Gerald Pfeifer wrote: > > I noticed that the Wiki is g

Re: Some notes on the Wiki (was: 4.1 news item)

On Sun, 2005-07-10 at 20:14 +0200, Gabriel Dos Reis wrote: > Daniel Berlin <[EMAIL PROTECTED]> writes: > > | On Sun, 2005-07-10 at 19:31 +0200, Gerald Pfeifer wrote: > | > I noticed that the Wiki is getting more and more of a third place where > | > to find documenta

Broke swim interchange through aliasing

It looks like we are now giving type tags to global that didn't use to have type tags, and are *not* pointers. before: Variable: pcheck, UID 511, real8, is an alias tag, is addressable, call clobbered, default def: pcheck_83 ... Variable: TMT.68, UID 1386, real8, is addressable, is global, call

Re: Broke swim interchange through aliasing

On Sun, 2005-07-10 at 15:49 -0400, Daniel Berlin wrote: > It looks like we are now giving type tags to global that didn't use to > have type tags, and are *not* pointers. > As a followup, it looks like alias grouping went crazy and turned on here, when it didn't before. It

Re: Some notes on the Wiki (was: 4.1 news item)

> It appears to me that you're relating unrelated effects and causes. Not really. People don't contribute to the current docs for the following main reasons, AFAICT and have heard from people, *in order of number of complaints i've heard from people*: 1. They don't want to send continual incompl

Re: Some notes on the Wiki (was: 4.1 news item)

On Sun, 2005-07-10 at 22:50 +0200, Gerald Pfeifer wrote: > On Sun, 10 Jul 2005, Daniel Berlin wrote: > > I find it sad that you are complaining that people have created > > a resource *they* find useful, instead of one that *we think they > > should find useful*. > > I&

Re: why are there many copies of function_decls that have the same information including the same uid?

On Mon, 2005-07-11 at 08:40 -0400, Kenneth Zadeck wrote: > Is this a bug or a feature? Bug. where is it occurring?

Re: Some notes on the Wiki

On Mon, 2005-07-11 at 16:22 +0200, Steven Bosscher wrote: > On Monday 11 July 2005 16:19, Diego Novillo wrote: > > Would a blanket statement at the start of the wiki be enough? > > Who gets to decide this? > > I guess that, apart from the legal discussion of whether this enough, > such a statement

Re: Some notes on the Wiki

On Mon, 2005-07-11 at 15:19 +, Joseph S. Myers wrote: > On Mon, 11 Jul 2005, Steven Bosscher wrote: > > > On Monday 11 July 2005 16:50, Bernd Schmidt wrote: > > > Steven Bosscher wrote: > > > > I guess that, apart from the legal discussion of whether this enough, > > > > such a statement would

Bugzilla is temporarily down

While we free some space on the server. Sorry about that.

Bugzilla back up (was Re: Bugzilla is temporarily down)

On Mon, 2005-07-11 at 12:55 -0400, Daniel Berlin wrote: > While we free some space on the server. > Sorry about that. > > And now it's back up

Re: Some notes on the Wiki

On Mon, 2005-07-11 at 13:09 -0700, Robert Thorpe wrote: > > I believe the Wiki is an invaluable documentation tool, precisely > > because it allows such an unencumbered contribution process. > > > > I agree. I wasn't suggesting that the Wiki has no value, but rather > > that it's not a

Re: Some notes on the Wiki

On Mon, 2005-07-11 at 22:47 +0200, Gabriel Dos Reis wrote: > Daniel Berlin <[EMAIL PROTECTED]> writes: > > [...] > > | > Also, a web-browser is much slower than an info-browser, especially when > doing searchs. > | > | You must be close to the only user i

Re: Some notes on the Wiki

On Mon, 11 Jul 2005, Nicholas Nethercote wrote: On Mon, 11 Jul 2005, Daniel Berlin wrote: Also, a web-browser is much slower than an info-browser, especially when doing searchs. You must be close to the only user i've met who uses the info browser :) I use it. Info pages suck in

Re: Some notes on the Wiki

On Mon, 11 Jul 2005, Andreas Schwab wrote: Daniel Berlin <[EMAIL PROTECTED]> writes: Most people i've met can't undertand the commands for info (pinfo is nicer in this regard). There exist many alternative info browsers (this includes konqueror). Yet the amount of docs a

Re: Some notes on the Wiki

> > > > > I just had a quick quiz in the C++ IRC channel I was in, and very few > people there like info, and very few are comfortable using it. There was > a general agreement HTML, PDF and docbook are the best ways to recieve > documentation. > > Chris It's possible these people ride the shor

Re: Some notes on the Wiki (was: 4.1 news item)

On Mon, 2005-07-11 at 15:21 -0700, Joe Buck wrote: > On Tue, Jul 12, 2005 at 12:07:01AM +0200, Gerald Pfeifer wrote: > > On Mon, 11 Jul 2005, Steven Bosscher wrote: > > > Another idea that was coined on IRC is to have reviewing and commit > > > after approval rules for the user manual, but to allow

Re: Reducing debug info for C++ ctors/dtors

te instances. That is probably what you want for stabs: have one of the base/complete ctors, but not both. The effect on dwarf output might be more interesting. GDB just ignores all but one of each set in stabs anyway. -- Daniel Jacobowitz CodeSourcery, LLC

Re: Reducing debug info for C++ ctors/dtors

t it is a useful option to have available. Thanks for the explanation. That makes more sense. Personally, if you're going to do this, I don't see why you're keeping debug info for methods; either ditch all artificial methods (including defaulted constructors but not manually specified constructors), or ditch all methods. -- Daniel Jacobowitz CodeSourcery, LLC

Re: Pointers in comparison expressions

> I think that even if the use of relational operators other than '==' and '!=' > is legal with pointers, the compiler should issue a warning (when the option > -Wall is used), as it does for assignment, used as truth values, not > surrounded with parentheses. Why? It's legal, it's useful, and

Bugzilla

may go up and down the next few hours while i attempt to figure out what is going on. It looks like some of the actual data got very out of whack with the mysql indexes when we ran out of space on sourceware, and while the data is still fine, every time someone changes a bug, it seems to cause the

How to make an application look somewhere other than /lib for ld-linux.so.2

"Mark Cuss" <[EMAIL PROTECTED]> wrote: I'm trying to get myself a group of libraries that I can distribute > with my program so that they'll run on any distro. > I run into problems all the time when different distros have different versions of system libraries like libstdc++, libgcc, libc, etc

Re: [toplevel] Update COPYING.LIB from FSF

e change of "Library" to "Lesser" in the name. Yes - Joe, I believe you're thinking of the latest revisions of the GPL, which do only differ in the address. LGPL 2.0 -> 2.1 predates the move by a while. -- Daniel Jacobowitz CodeSourcery, LLC

Re: volatile semantics

On Sat, 2005-07-16 at 12:50 -0400, D. Hugh Redelmeier wrote: > Sorry for the very late response. It is actually triggered by the > bugzilla entry > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22278 > > The motivating example, abstracted from a misbehaving part of X, is: > void test (c

Re: volatile semantics

object volatile). I don't understand your point. given void Foo (char const * a) { *(char *)a = 5; } the compiler generates code to store 5 through the pointer 'a'. It doesn't turn this into a call to 'abort', because it thinks you're writing to const storage. Is this *always* the cas

Re: volatile semantics

> In other words, we're asked to agree that the type of an object > changes depending on how it is accessed. > For the benefit of readers, only the first sentence of this para is > the language of the standard; the rest isn't. > > That an object referred to through a volatile pointer must > "te

Re: volatile semantics

On Sat, 2005-07-16 at 19:35 +0100, Nathan Sidwell wrote: > Daniel Berlin wrote: > >>> object volatile). > >> > >> > >> I don't understand your point. given > >> void Foo (char const * a) { *(char *)a = 5; } > >> the compiler ge

Re: volatile semantics

> | There is no point in type qualifiers if they can be simply changed at > | will. Do not lie about your objects, and you will not be screwed over. > > only if the language you're implementing the compiler for says so, no > matter what nifty transformation you could have done. > Except that n

Re: volatile semantics

On Sat, 2005-07-16 at 23:23 +0200, Gabriel Dos Reis wrote: > Daniel Berlin <[EMAIL PROTECTED]> writes: > > | > | There is no point in type qualifiers if they can be simply changed at > | > | will. Do not lie about your objects, and you will not be screwed over. > | &g

Re: volatile semantics

On Sat, 2005-07-16 at 23:23 +0200, Gabriel Dos Reis wrote: > Daniel Berlin <[EMAIL PROTECTED]> writes: > > | > | There is no point in type qualifiers if they can be simply changed at > | > | will. Do not lie about your objects, and you will not be screwed over. > | &g

<    1   2   3   4   5   6   7   8   9   10   >