Re: PR 19893 & array_ref bug

Joe Buck <[EMAIL PROTECTED]> writes: | On Tue, Mar 15, 2005 at 04:42:03PM -0800, Steve Ellcey wrote: | > The simplest solution would probably be to ignore __aligned__ attributes | > completely when we have an array. Or to do the change you suggested for | > the vector tests and have the attribute

Re: PR 19893 & array_ref bug

Mark Mitchell <[EMAIL PROTECTED]> writes: | Joe Buck wrote: | > On Tue, Mar 15, 2005 at 04:42:03PM -0800, Steve Ellcey wrote: | > | >>The simplest solution would probably be to ignore __aligned__ attributes | >>completely when we have an array. Or to do the change you suggested for | >>the vector

Re: __builtin_cpow((0,0),(0,0))

Ronny Peine <[EMAIL PROTECTED]> writes: | Hi, | | Kai Henningsen wrote: | > [EMAIL PROTECTED] (Robert Dewar) wrote on 07.03.05 in <[EMAIL PROTECTED]>: | > | >>Ronny Peine wrote: | >> | >> | >>>Sorry for this, maybe i should sleep :) (It's 2 o'clock here) | >>>But as i know of 0^0 is defined as 1

Re: PR 19893 & array_ref bug

Mark Mitchell <[EMAIL PROTECTED]> writes: | Steve Ellcey wrote: | > What do people think about this idea for changing the vect tests using | > gcc.dg/vect/vect-56.c as an example. The arguments (pa, pb, pc) would | > remain afloat type (vs. float) but the arrays would be changed from | > 'array o

Re: __builtin_cpow((0,0),(0,0))

Ronny Peine <[EMAIL PROTECTED]> writes: | Dave Korn wrote: | > Original Message | > | >>From: Ronny Peine | >>Sent: 16 March 2005 17:34 | > | >>See for example: | >>http://mathworld.wolfram.com/ExponentLaws.html | >> | > Ok, I did. | > | >> Even though, gcc returns 1 for pow(0.0,0.0) in

Re: Profile-directed feedback and remote testing

Mark Mitchell <[EMAIL PROTECTED]> writes: | When we generate data for feedback, we insert the .gcda name into the | object file as an absolute path. As a result, when we try to do | remote testing, we lose, as, in general the remote file system does | not have the same file hierarchy as the build

Re: Profile-directed feedback and remote testing

"Timothy J.Wood" <[EMAIL PROTECTED]> writes: | On Mar 24, 2005, at 11:59 PM, Mark Mitchell wrote: | | > When we generate data for feedback, we insert the .gcda name into | > the object file as an absolute path. As a result, when we try to do | > remote testing, we lose, as, in general the remote

Re: Profile-directed feedback and remote testing

mission to write his count | files, and he'd left for the day, so I couldn't get him to change the | permissions. I wound up rebuilding the whole large executable from | source, but that was an annoying waste of time. | | On Fri, Mar 25, 2005 at 10:17:22AM +0100, Gabriel Dos Reis wrote: |

Re: Profile-directed feedback and remote testing

Joe Buck <[EMAIL PROTECTED]> writes: | On Fri, Mar 25, 2005 at 08:03:55PM +0100, Gabriel Dos Reis wrote: | > Joe Buck <[EMAIL PROTECTED]> writes: | > | That wouldn't have saved me in the case described above, as the pathnames | > | are already set in the executable. A

ISO C prototype style for libiberty?

Hi, Would there be any objection to patches that convert function definitions in libiberty to use ISO C prototype style, instead of K&R style? (rationale: they are getting in the way when compiling GCC with a C++ compiler, for example). -- Gaby

Re: ISO C prototype style for libiberty?

DJ Delorie <[EMAIL PROTECTED]> writes: | > Would there be any objection to patches that convert function | > definitions in libiberty to use ISO C prototype style, instead of | > K&R style? | | I would be in support of such a patch iff it converts all the | functions, not just the ones gcc hap

Re: ISO C prototype style for libiberty?

DJ Delorie <[EMAIL PROTECTED]> writes: | > Just to make sure I understand. I was thinking of whatever was | > under $GCC/libiberty (and included). Are you thinking of something | > more? | | No. OK. | > A single patch is a huge stuff; I propose to break it into a series | > of patches. Is th

Re: gcc build is broken on powerpc-apple-darwin

Mostafa Hagog <[EMAIL PROTECTED]> writes: | I guess its due to the following patch ( | http://gcc.gnu.org/ml/gcc-cvs/2005-03/msg01320.html). | I get the following error when trying to build gcc on powerpc-apple-darwin: | gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../../gcc/libiberty/../include -W | -

Re: gcc build is broken on powerpc-apple-darwin

Mike Stump <[EMAIL PROTECTED]> writes: | On Sunday, March 27, 2005, at 09:31 AM, Gabriel Dos Reis wrote: | > Fixed with this | > | >http://gcc.gnu.org/ml/gcc-patches/2005-03/msg02450.html | > | > Please try again and let me know. | | A quick check of build's libibe

Re: RFC: #pragma optimization_level

Diego Novillo <[EMAIL PROTECTED]> writes: | On Fri, Apr 01, 2005 at 11:24:06AM -0800, Mark Mitchell wrote: | > Dale Johannesen wrote: | > | > >So I guess question 1 is, Mark, do you feel negatively enough about this | > >feature to block its acceptance in mainline? | > | > I'm not sure that I *c

Re: RFC: #pragma optimization_level

Georg Bauhaus <[EMAIL PROTECTED]> writes: | Joe Buck wrote: | | > Are you using "volatile" correctly? There are situations where "volatile" | > alone does not suffice and you need more locking, but the Linux and BSD | > kernel folks manage to optimize their device driver code. | | We have just

Re: Use Bohem's GC for compiler proper in 4.1?

Joe Buck <[EMAIL PROTECTED]> writes: | On Sat, Apr 02, 2005 at 01:10:42AM -0500, Andrew Pinski wrote: | > >Memory bloat is a problem for embedded systems. Attitudes about just | > >"buy | > >another gigabyte" is why i use C for everything for speed, portability, | > >compactness, and conciseness

Re: Bug#300945: romeo: FTBFS (amd64/gcc-4.0): invalid lvalue in assignment

Shaun Jackman <[EMAIL PROTECTED]> writes: | Can the GCC "C Extension" of "Generalized Lvalues" be enabled with a | switch in gcc-4.0? It is gone forever. -- Gaby

Re: Use Bohem's GC for compiler proper in 4.1?

Robert Dewar <[EMAIL PROTECTED]> writes: | Gabriel Dos Reis wrote: | countries with obscure machines that escaped from Middle Age. | > While I know a bit of third-wrld, I have also been working in some | > western | > European countries for a sufficiant time to say that, well

Re: 2 suggestions

Toon Moene <[EMAIL PROTECTED]> writes: | Kaveh R. Ghazi wrote: | | > If people would simply follow the directions here: | > by setting | > CONFIG_SHELL to /bin/ksh before configure;make bootstrap, | | Indeed - I stopped counting how many h

Re: Does anyone use -fprofile-use with C++?

Joe Buck <[EMAIL PROTECTED]> writes: | On Thu, Apr 07, 2005 at 06:32:26PM -0400, Andrew Pinski wrote: | > | > On Apr 7, 2005, at 6:01 PM, Daniel Kegel wrote: | > | > >Judging by http://gcc.gnu.org/PR20815, I get the feeling | > >not many people are using the -fprofile-generate | > >and -fprofile

libiberty configure mysteries

Hi, The following is from libibtery.h /* HAVE_DECL_* is a three-state macro: undefined, 0 or 1. If it is undefined, we haven't run the autoconf check so provide the declaration without arguments. If it is 0, we checked and failed to find the declaration so provide a fully

Re: libiberty configure mysteries

Daniel Jacobowitz <[EMAIL PROTECTED]> writes: | On Sun, Apr 10, 2005 at 05:02:36PM +0200, Gabriel Dos Reis wrote: | > | > Hi, | > | > The following is from libibtery.h | > | >/* HAVE_DECL_* is a three-state macro: undefined, 0 or 1. If it is | > un

Re: libiberty configure mysteries

Daniel Jacobowitz <[EMAIL PROTECTED]> writes: | On Sun, Apr 10, 2005 at 05:52:01PM +0200, Gabriel Dos Reis wrote: | > Daniel Jacobowitz <[EMAIL PROTECTED]> writes: | > | > | On Sun, Apr 10, 2005 at 05:02:36PM +0200, Gabriel Dos Reis wrote: | > | > | > | > Hi,

Re: Getting rid of -fno-unit-at-a-time [Was Re: RFC: Preserving order of functions and top-level asms via cgraph]

Nathan Sidwell <[EMAIL PROTECTED]> writes: | Andrew Haley wrote: | | > Might it still be possible for a front end to force all pending code | > to be generated, even with -fno-unit-at-a-time gone? | | I think this is a bad idea. You're essentially asking for the backend | to retain all the func

Re: Getting rid of -fno-unit-at-a-time [Was Re: RFC: Preserving order of functions and top-level asms via cgraph]

Nathan Sidwell <[EMAIL PROTECTED]> writes: | Andrew Haley wrote: | > Nathan Sidwell writes: | > > Andrew Haley wrote: | > > > > Might it still be possible for a front end to force all | > pending code | > > > to be generated, even with -fno-unit-at-a-time gone? | > > > I think this is a bad

Mainline build failure on i686-pc-linux-gnu

Build of freshly updated mainline tree fails with: /home/gdr/build/4.1/./gcc/xgcc -B/home/gdr/build/4.1/./gcc/ -B/home/gdr/i686-pc- linux-gnu/bin/ -B/home/gdr/i686-pc-linux-gnu/lib/ -isystem /home/gdr/i686-pc-lin ux-gnu/include -isystem /home/gdr/i686-pc-linux-gnu/sys-include -O2 -DIN_GCC -W

Re: Mainline build failure on i686-pc-linux-gnu

Diego Novillo <[EMAIL PROTECTED]> writes: | On Mon, Apr 11, 2005 at 10:59:46PM -0500, Gabriel Dos Reis wrote: | | >-c /home/gdr/redhat/egcs/gcc/crtstuff.c -DCRT_BEGIN \ | > -o crtbegin.o | > make[1]: *** [crtbegin.o] Aborted | > make[1]: Leaving directory `/home/gdr/build

Re: Mainline build failure on i686-pc-linux-gnu

Gabriel Dos Reis <[EMAIL PROTECTED]> writes: | Diego Novillo <[EMAIL PROTECTED]> writes: | | | On Mon, Apr 11, 2005 at 10:59:46PM -0500, Gabriel Dos Reis wrote: | | | | >-c /home/gdr/redhat/egcs/gcc/crtstuff.c -DCRT_BEGIN \ | | > -o crtbegin.o | | > make[1]: ***

Re: Mainline build failure on i686-pc-linux-gnu

Andrew Pinski <[EMAIL PROTECTED]> writes: | And what version of the compiler were you starting with? | If it was 4.1.0 between the following patches: | 2005-04-08 Diego Novillo <[EMAIL PROTECTED]> | | Merge from tree-cleanup-branch: VRP, store CCP, store | copy-prop, incre

Re: Heads-up: volatile and C++

"Michael N. Moran" <[EMAIL PROTECTED]> writes: [...] | While I'm on my soap-box ... | I would like to see some sort of alignment qualifiers | added to the C++ language for those of us that need | to deal with directly with page/cache alignment | (for both types and objects.) We just discuss (aga

Re: Heads-up: volatile and C++

Robert Dewar <[EMAIL PROTECTED]> writes: | One interesting thing to consider here is how the C++ semantics | compares with that of pragma Volatile in Ada, which is roughly | intended to be equivalent to volatile in C. The suggestion made by Hans is to improve over the existing semantics in C++ (w

Re: Heads-up: volatile and C++

Diego Novillo <[EMAIL PROTECTED]> writes: [...] | Seems to me that if C++ is all of the sudden interested in | dictating memory semantics for threaded programs, it should also | provide language capabilities for other synchronization models | and for threads (as in Java, though the memory model o

Re: Heads-up: volatile and C++

Laurent GUERBY <[EMAIL PROTECTED]> writes: | I'm including the standard annotations, they have no standard | value but sometimes do help. [...] Thanks! -- Gaby

Re: Heads-up: volatile and C++

Richard Henderson <[EMAIL PROTECTED]> writes: | On Thu, Apr 14, 2005 at 11:30:20PM +0200, Jason Merrill wrote: | > Consider Double-Checked Locking | > (http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html). | > I used DCL with explicit memory barriers to implement thread-safe | >

Re: Heads-up: volatile and C++

Gabriel Dos Reis <[EMAIL PROTECTED]> writes: | Richard Henderson <[EMAIL PROTECTED]> writes: | | | On Thu, Apr 14, 2005 at 11:30:20PM +0200, Jason Merrill wrote: | | > Consider Double-Checked Locking | | > (http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html)

Re: Heads-up: volatile and C++

Marcin Dalecki <[EMAIL PROTECTED]> writes: | On 2005-04-15, at 01:10, Richard Henderson wrote: | | > On Thu, Apr 14, 2005 at 11:30:20PM +0200, Jason Merrill wrote: | >> Consider Double-Checked Locking | >> (http://www.cs.umd.edu/~pugh/java/memoryModel/ | >> DoubleCheckedLocking.html). | >> I used

Re: Heads-up: volatile and C++

Marcin Dalecki: >> Don't accept the marketing explanation either. > > Agreed. Maybe the idea of a subset of C++ basically coming down what > would be a C with inheritance > was somehow over-hyped by too much marketing bragging as an excuse for > some defective C++ compiler > implementation at int

Re: Template and dynamic dispatching

[ I changed the title so that the main topic -- volatile and C++ -- not be diluted ] Robert Dewar: > Paul Koning wrote: >>>"Marcin" == Marcin Dalecki <[EMAIL PROTECTED]> writes: >> >> >> Marcin> On 2005-04-15, at 20:18, Mike Stump wrote: >> >> >> On Thursday, April 14, 2005, at 08:48 PM, M

Re: GCC 3.3 status

those information are right. More on that later today. | | Thanks, | Giovanni Bajo | | -- Gabriel Dos Reis [EMAIL PROTECTED] Texas A&M University -- Computer Science Depart

Re: tcc_statement vs. tcc_expression in the C++ frontend

Ian Lance Taylor writes: | The description of tcc_statement in tree.h says "A statement | expression, which have side effects but usually no interesting value." | | There are a number of entries in cp/cp-tree.def which are marked as | tcc_expression, although they seem to me to be better describ

Re: Heads-up: volatile and C++

Marcin Dalecki <[EMAIL PROTECTED]> writes: | On 2005-04-15, at 23:59, Mike Stump wrote: | | > On Friday, April 15, 2005, at 02:52 PM, Marcin Dalecki wrote: | >>> My god, you didn't actually buy into that did you? Hint, it was | >>> is, and always will be a joke. | >> | >> You dare to explain wh

Re: New gcc 4.0.0 warnings seem spurious

Vincent Lefevre <[EMAIL PROTECTED]> writes: | > Bruce Lilly <[EMAIL PROTECTED]> writes: | > > static const unsigned char AAA = 0x1U; | > > static const unsigned char BBB = 0x2U; | > | > Again, C does not work the way you think. These are not constants. | | But if they are never modified, they e

Re: New gcc 4.0.0 warnings seem spurious

Zack Weinberg <[EMAIL PROTECTED]> writes: [...] | >> Bruce Lilly <[EMAIL PROTECTED]> writes: | >> > static const unsigned char AAA = 0x1U; | >> > static const unsigned char BBB = 0x2U; | >> | >> Again, C does not work the way you think. These are not constants. | > | > But if they are never mod

Re: New gcc 4.0.0 warnings seem spurious

Vincent Lefevre <[EMAIL PROTECTED]> writes: | On 2005-04-27 03:37:15 -0700, Zack Weinberg wrote: | > Vincent Lefevre <[EMAIL PROTECTED]> writes: | > > However it is correct to store any integer to an unsigned variable, | > > even if the original value cannot be represented. | > | > If that operat

Re: New gcc 4.0.0 warnings seem spurious

Vincent Lefevre <[EMAIL PROTECTED]> writes: [...] | > > But if they are never modified, they evaluate to constants, right? | > > | > > The fact that they are not considered as constant expressions, | > > is it due to the fact that the environment is allowed to modify | > > them? | > | > It

Re: New gcc 4.0.0 warnings seem spurious

Vincent Lefevre <[EMAIL PROTECTED]> writes: | On 2005-04-27 12:29:53 +0100, Andrew Haley wrote: | > Vincent Lefevre writes: | > > The only two constraints in 6.6 are: | > > | > >[#3] Constant expressions shall not contain assignment, | > >increment, decrement, function-

Re: New gcc 4.0.0 warnings seem spurious

Vincent Lefevre <[EMAIL PROTECTED]> writes: | On 2005-04-27 12:34:14 +0100, Andrew Haley wrote: | > You said "if they are never modified, they evaluate to constants, | > right?" To which the correct answer is "no, they don't". | | Why not? I think the answer to that question was in the part you

Re: New gcc 4.0.0 warnings seem spurious

Vincent Lefevre <[EMAIL PROTECTED]> writes: | On 2005-04-27 15:41:06 +0200, Gabriel Dos Reis wrote: | > Vincent Lefevre <[EMAIL PROTECTED]> writes: | > | It is said "constant expressions", not "integer constant expressions". | > | > And an integer cons

Re: New gcc 4.0.0 warnings seem spurious

Vincent Lefevre <[EMAIL PROTECTED]> writes: | On 2005-04-27 15:30:39 +0200, Gabriel Dos Reis wrote: | > Vincent Lefevre <[EMAIL PROTECTED]> writes: | > | > [...] | > | > | > > But if they are never modified, they evaluate to constants, right? | > | > &

Re: New gcc 4.0.0 warnings seem spurious

Vincent Lefevre <[EMAIL PROTECTED]> writes: | On 2005-04-27 15:44:12 +0200, Gabriel Dos Reis wrote: | > Vincent Lefevre <[EMAIL PROTECTED]> writes: | > | > | On 2005-04-27 12:34:14 +0100, Andrew Haley wrote: | > | > You said "if they are never modified, they eval

Re: New gcc 4.0.0 warnings seem spurious

Vincent Lefevre <[EMAIL PROTECTED]> writes: | On 2005-04-27 17:30:25 +0200, Gabriel Dos Reis wrote: | > Vincent Lefevre <[EMAIL PROTECTED]> writes: | > | > | On 2005-04-27 15:30:39 +0200, Gabriel Dos Reis wrote: | > | > Vincent Lefevre

Re: New gcc 4.0.0 warnings seem spurious

Vincent Lefevre <[EMAIL PROTECTED]> writes: | > Read Zack's sentence | > | > These are not constants. | > | > from | > | >http://gcc.gnu.org/ml/gcc/2005-04/msg01436.html | > | > as | > | > These (i.e. AAA, etc.) are not constant expressions. | > | > Are you happy now? | | T

Re: GCC 3.4.4 Status (2005-04-29)

Mark Mitchell <[EMAIL PROTECTED]> writes: | Now that GCC 4.0 is out the door, I've spent some time looking at the | status of the 3.4 branch. As stated previously, I'll be doing a 3.4.4 | release, and then turning the branch over to Gaby, to focus | exclusively on 4.0/4.1. I'm happy to help the

GCC-3.3.6 release status

Hi, GCC-3.3.6 appears in pretty good shape. There were 36 PRs open against it (as of this morning, 6am, GMT-05). I wnet through all of them and the appeared to be very minor or impossible bugs to fix in 3.3.6 major restructuring (typically, they were bugs fixed in 3.4.x or 4.0.x). Two of th

GCC-3.3.6 prerelease for testing

series. Thanks, -- Gabriel Dos Reis [EMAIL PROTECTED] Texas A&M University -- Department of Computer Science 301, Bright Building -- College Station, TX 77843-3112

Re: GCC 3.4.4 Status (2005-04-29)

Mark Mitchell <[EMAIL PROTECTED]> writes: | Richard Guenther wrote: | > On 4/29/05, Mark Mitchell <[EMAIL PROTECTED]> wrote: | > | >>Joseph S. Myers wrote: | >> | >>>What's the position on closing 3.4 regression bugs which are fixed in 4.0 | >>>and where it doesn't seem worthwhile to attempt to ba

gcc-3_3-branch frozen

Consider gcc-3_3-branch as frozen. Release script is running. Thanks, -- Gaby

Re: parse bug in 4.0.0?

Paul Koning <[EMAIL PROTECTED]> writes: | This test program: | | struct bar; | | template struct bar *foo (T *p) | { | return p->t; | } | | produces an error in 4.0.0: yes, a parser bug. good candidate for bugzilla PR. -- Gaby

Re: volatile semantics

Andrew Haley <[EMAIL PROTECTED]> writes: | Nathan Sidwell writes: | > Dale Johannesen wrote: | > | > > And we don't have to document the behavior at all; it is not documented | > > now. | > I disagree. It's not documented explicitly in gcc now, because it is doing | > what the std permits

Re: volatile semantics

[EMAIL PROTECTED] (Kai Henningsen) writes: | [EMAIL PROTECTED] (Nathan Sidwell) wrote on 03.05.05 in <[EMAIL PROTECTED]>: | | > Mike Stump wrote: | > > int avail; | > > int main() { | > > while (*(volatile int *)&avail == 0) | > > continue; | > > return 0; | > > } | > > | > > | > > Ok, s

Re: How to get MIN_EXPR without using deprecated min operator

"Michael Cieslinski" <[EMAIL PROTECTED]> writes: | Consider the following short program: | | #include | | void Tst1(short* __restrict__ SrcP, short* __restrict__ MinP, int Len) | { | for (int x=0; xhttp://gcc.gnu.org/bugzilla/ for missed optimization. -- Gaby

Re: -fdump-translation-unit considered harmful

"Dams, Dennis (Dennis)" <[EMAIL PROTECTED]> writes: | | | > -Original Message- | > From: [EMAIL PROTECTED] | > [mailto:[EMAIL PROTECTED] | > Sent: Friday, May 13, 2005 12:33 PM | > To: Adam Nemet | > Cc: Ian Lance Taylor; Dams, Dennis (Dennis); [EMAIL PROTECTED] | > Subject: Re: -fdum

libiberty requirements and ISO C90

Hi, The file libiberty/xstrerror.c contains the following fragment #ifdef VMS #include #if !defined (__STRICT_ANSI__) && !defined (__HIDE_FORBIDDEN_NAMES) extern char *strerror (int,...); #define DONT_DECLARE_STRERROR #endif #endif /* VMS */ #ifndef DONT_DECL

Re: libiberty requirements and ISO C90

Ian Lance Taylor writes: [...] | I think the more conservative approach would be to simply add strerror | to AC_CHECK_DECLS, include in xstrerror.c (protected by | HAVE_STRING_H), and protect the strerror declaration with | #if !HAVE_DECL_STRERROR Thanks, that indeed makes sense. Patch pe

Re: GCC 4.1: Buildable on GHz machines only?

Ralf Corsepius <[EMAIL PROTECTED]> writes: [...] | Well, I admit I had been sarcastic/fatalistic in replying to Steven, | primarily, because I am pretty much frustrated about GCC's mainstream | developer's position/attitude on embedded targets. | Steven's answers perfectly queue-in into a long hi

Re: "No matching function" -- not finding copy constructor

Joe Buck <[EMAIL PROTECTED]> writes: | On Tue, May 17, 2005 at 12:00:59PM -0400, Paul Koning wrote: | > I'm upgrading to V4.0.0 and struggling with some code that's seriously | > into templates. One puzzling error is this one: | > | > keyed_obj.hh:159: error: no matching function for call to 'C

Re: GCC 4.1: Buildable on GHz machines only?

Ranjit Mathew <[EMAIL PROTECTED]> writes: [...] | PS: Surely this must be one of the longest threads in | recent times on the GCC list! :-) | PPS: I do not see some of the messages, for example, a | couple of messages from Robert Dewar that seem to be | referenced in other messages. same here.

Re: Mismatched types in ADDR_EXPR from c-typeck.c:build_function_call

"Joseph S. Myers" <[EMAIL PROTECTED]> writes: | On Wed, 18 May 2005, Richard Guenther wrote: | | > The following snippet | > | > /* Differs from default_conversion by not setting TREE_ADDRESSABLE | > (because calling an inline function does not mean the function | > needs

Re: Mismatched types in ADDR_EXPR from c-typeck.c:build_function_call

Paul Schlie <[EMAIL PROTECTED]> writes: | > Joseph S. Myers writes: | >> Richard Guenther wrote: | >> The following snippet | >> | >> /* Differs from default_conversion by not setting TREE_ADDRESSABLE | >> (because calling an inline function does not mean the function | >>

Re: Mismatched types in ADDR_EXPR from c-typeck.c:build_function_call

Paul Schlie <[EMAIL PROTECTED]> writes: | > From: Gabriel Dos Reis <[EMAIL PROTECTED]> | > <[EMAIL PROTECTED]>, | > Subject: Re: Mismatched types in ADDR_EXPR from c-typeck.c:build_function_call | > | > | Thereby all literal values are implied to be qualif

Re: gcc-3.3-20050518 is now available

Joe Buck <[EMAIL PROTECTED]> writes: | On Wed, May 18, 2005 at 11:53:13PM -, [EMAIL PROTECTED] wrote: | > Snapshot gcc-3.3-20050518 is now available on | > ftp://gcc.gnu.org/pub/gcc/snapshots/3.3-20050518/ | > and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. | | Is t

Re: gcc-3.3-20050518 is now available

"Joseph S. Myers" <[EMAIL PROTECTED]> writes: | On Wed, 18 May 2005, Joe Buck wrote: | | > On Wed, May 18, 2005 at 11:53:13PM -, [EMAIL PROTECTED] wrote: | > > Snapshot gcc-3.3-20050518 is now available on | > > ftp://gcc.gnu.org/pub/gcc/snapshots/3.3-20050518/ | > > and on various mirrors,

Re: [wwwdocs] Simplify release process a bit (was: GCC 3.4.4 Released)

Gerald Pfeifer <[EMAIL PROTECTED]> writes: | On Fri, 20 May 2005, Mark Mitchell wrote: | > And, I would like to ask that our webmasters, in there copious spare | > time :-), work on automatically generating more of this content. The | > bug lists and such could be automatically generated, even

basic-block and tree statement iterator enums

Hi, I've been pushing, locally, the compilation of GCC sources with g++. So far, I've gotten past libiberty, fixincludes, libcpp, the C front-end specific files, RTL files with no much pain. However, the files tree-* and associated headers seem to be the most resolutely C++ unfriendly (I guess

tree ssa and type issues

Hi again, I just hit this one from tree-ssa-into.c:rewrite_into_ssa() /* Initialize dominance frontier. */ dfs = (bitmap *) xmalloc (last_basic_block * sizeof (bitmap *));

Re: tree ssa and type issues

Andreas Jaeger <[EMAIL PROTECTED]> writes: | Gabriel Dos Reis <[EMAIL PROTECTED]> writes: | | > Hi again, | > | > I just hit this one from tree-ssa-into.c:rewrite_into_ssa() | > | > /* Initialize dominance frontier. */ | > dfs = (bitmap *) xmalloc (las

Re: tree ssa and type issues

Tom Tromey <[EMAIL PROTECTED]> writes: | >>>>> "Gabriel" == Gabriel Dos Reis <[EMAIL PROTECTED]> writes: | | Gabriel> I just hit this one from tree-ssa-into.c:rewrite_into_ssa() | Gabriel> /* Initialize dominance frontier. */ | Gabriel> dfs =

Re: tree ssa and type issues

Daniel Berlin <[EMAIL PROTECTED]> writes: | On Sat, 2005-05-21 at 18:55 +0200, Andreas Jaeger wrote: | > Gabriel Dos Reis <[EMAIL PROTECTED]> writes: | > | > > Hi again, | > > | > > I just hit this one from tree-ssa-into.c:rewrite_into_ssa() | > >

Re: tree ssa and type issues

Daniel Berlin <[EMAIL PROTECTED]> writes: [...] | > Parenthetically, I was wondering who is freeing those extensive | > regions of storage xmalloc/xcalloc()ed here and there? | | 1. The people who write the code to do the xmalloc'ing. | 2. Every couple of months, people run gcc through valgrind

Re: tree ssa and type issues

Daniel Berlin <[EMAIL PROTECTED]> writes: | On Sat, 2005-05-21 at 22:00 +0200, Gabriel Dos Reis wrote: | > Daniel Berlin <[EMAIL PROTECTED]> writes: | > | > [...] | > | > | > Parenthetically, I was wondering who is freeing those extensive | > | > regions of

Re: Some questions about FIELD_DECL

Daniel Berlin <[EMAIL PROTECTED]> writes: | While moving FIELD_DECL to it's own substruct, the following questions | have come up. I figured one of you might know: | | 1. Do we need DECL_ASSEMBLER_NAME on FIELD_DECL? I can't think of a | place where we would actually try to *output* a FIELD_DEC

Re: Some questions about FIELD_DECL

Daniel Berlin <[EMAIL PROTECTED]> writes: | On Sun, 2005-05-22 at 02:14 +0200, Gabriel Dos Reis wrote: | > Daniel Berlin <[EMAIL PROTECTED]> writes: | > | > | While moving FIELD_DECL to it's own substruct, the following questions | > | have come up. I

Compiling GCC with g++: a report

mething so that we don't run into problem. However, I do not expect this issue to dominate the discussion :-)) So, if various components maintainers (e.g. C and C++, middle-end, ports, etc.) are willing to help quickly reviewing patches we can have this

Re: Compiling GCC with g++: a report

Gabriel Dos Reis <[EMAIL PROTECTED]> writes: | Hi, | | I spent the week-end trying to get GCC -- mainline -- compilable | (i.e. those compoenents written in C) with a C++ compiler (e.g. g++). | | My summary is: It is largely doable and it is within our reach at this | point of devel

Re: Compiling GCC with g++: a report

Gabriel Dos Reis <[EMAIL PROTECTED]> writes: [...] | Attempt to get the GNU C++ compiler through the same massage is | underway (but I'm going to bed shortly ;-)). I can also report that I got the GNU C++ compiler through -- and apart form uses of C++ keywords (template, namespace,

Re: Compiling GCC with g++: a report

Zack Weinberg <[EMAIL PROTECTED]> writes: | On Mon, 2005-05-23 at 01:15 -0500, Gabriel Dos Reis wrote: | > Hi, | > | > I spent the week-end trying to get GCC -- mainline -- compilable | > (i.e. those compoenents written in C) with a C++ compiler (e.g. g++). | | Thes

Re: Compiling GCC with g++: a report

Daniel Jacobowitz <[EMAIL PROTECTED]> writes: | On Mon, May 23, 2005 at 09:01:20PM -0700, Zack Weinberg wrote: | > As a general observation: A lot of the things you have found to be | > problematic, are in fact preferred idioms for C code. For instance, | > no standard-C programmer would ever wri

Re: Compiling GCC with g++: a report

Andrew Pinski <[EMAIL PROTECTED]> writes: | On May 24, 2005, at 12:01 AM, Zack Weinberg wrote: | > Use of bare 'inline' is just plain wrong in our source code; this has | > nothing to do with C++, no two C compilers implement bare 'inline' | > alike. Patches to add 'static' to such functions (AND

Re: Compiling GCC with g++: a report

Zack Weinberg <[EMAIL PROTECTED]> writes: | Gabriel Dos Reis <[EMAIL PROTECTED]> writes: | | [...] | > The cast you're talking about is buried deep in XNEWVEC, XRESIZEVEC | > and such. It is not anything you'll find in the code directly. So, | > in fact we do no

Re: Compiling GCC with g++: a report

Zack Weinberg <[EMAIL PROTECTED]> writes: | Mark Mitchell <[EMAIL PROTECTED]> writes: | ... | > Like you, I do think these problems are surmountable; but, also like | > you, I think it would take some time to get all the problems solved. | > I don't really think, though, that this is immediately r

Re: Compiling GCC with g++: a report

Mark Mitchell <[EMAIL PROTECTED]> writes: [...] | > unrestricted use of C++ keywords; | > | > declaring structure fields with the same name as a structure tag in | > scope. | | I don't think we should be reverting patches that fall afoul of these | last two, even if they break Gaby's build-with

Re: Compiling GCC with g++: a report

Zack Weinberg <[EMAIL PROTECTED]> writes: | Gabriel Dos Reis <[EMAIL PROTECTED]> writes: | | [dropping most of the message - if I haven't responded, assume I don't | agree but I also don't care enough to continue the argument. Also, | rearranging paragraphs a bit

Re: Compiling GCC with g++: a report

Zack Weinberg <[EMAIL PROTECTED]> writes: | Gabriel Dos Reis <[EMAIL PROTECTED]> writes: | | > But we do not get any expressive power by using C++ keywords. | | Readability, readability, readability. | | (for instance, 'class' vs. 'klass' When replacing &q

Re: Compiling GCC with g++: a report

Florian Weimer <[EMAIL PROTECTED]> writes: | * Gabriel Dos Reis: | | > The first resistance seems to come from the pervasive use of the implicit | > conversion void* -> T*, mostly with storage allocating functions. | | This can be worked around on the C++ side, see the exa

Re: Compiling GCC with g++: a report

Paul Koning <[EMAIL PROTECTED]> writes: | >>>>> "Gabriel" == Gabriel Dos Reis <[EMAIL PROTECTED]> writes: | | Gabriel> http://www.gnu.org/software/gcc/codingconventions.html | | Gabriel> Avoid the use of identifiers or idioms that would prevent |

Re: Compiling GCC with g++: a report

Zack Weinberg <[EMAIL PROTECTED]> writes: | On Tue, 2005-05-24 at 10:49 +0200, Gabriel Dos Reis wrote: | > | So you don't see any value whatsoever to having (for instance) the | > | individual constants of 'enum machine_mode' be inaccessible in most of | > | GCC? &#

Re: Compiling GCC with g++: a report

Zack Weinberg <[EMAIL PROTECTED]> writes: | On Wed, 2005-05-25 at 03:03 +0200, Gabriel Dos Reis wrote: | > Zack Weinberg <[EMAIL PROTECTED]> writes: | > | > | On Tue, 2005-05-24 at 10:49 +0200, Gabriel Dos Reis wrote: | > | > | So you don't see any value whatsoe

Re: Compiling GCC with g++: a report

Russ Allbery <[EMAIL PROTECTED]> writes: | Gabriel Dos Reis <[EMAIL PROTECTED]> writes: | > Zack Weinberg <[EMAIL PROTECTED]> writes: | | > | (And I'd be less grumpy about coding to the intersection of C and C++ | > | if someone coded up warnings for the C compil

Re: Compiling GCC with g++: a report

Zack Weinberg <[EMAIL PROTECTED]> writes: | On Tue, 2005-05-24 at 20:27 -0400, DJ Delorie wrote: | > > This is still not an answer to the question I originally asked - do you | > > see any way IN C to write code which has the relevant property of the | > > class above (that is, that the FOOmode co

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