Re: Patch reviews for 4.1

Mark Mitchell wrote: This rather horrid URL: http://gcc.gnu.org/bugzilla/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=4.1&target_milestone=4.0.3&target_milestone=4.1.0&known_to_fail_type=allwordssubstr&known_to_work_type=allwordssubstr&long_desc_type=allwordssubstr

Patch reviews for 4.1

This rather horrid URL: http://gcc.gnu.org/bugzilla/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=4.1&target_milestone=4.0.3&target_milestone=4.1.0&known_to_fail_type=allwordssubstr&known_to_work_type=allwordssubstr&long_desc_type=allwordssubstr&long_desc=&bug_file_lo

Re: SH: PR target/24445

Ian Lance Taylor wrote: > In general, yes. But looking at it we should probably only call > copy_to_reg if TARGET is not itself a pseudo-register. > > And I think I would put the new code before the "TARGET and VALREG > cannot be equal" comment. > > That patch is OK if it works and passes testi

Re: svn diff branch woprking copy against mainline?

> I think RTH's suggestion of using a "+" or similar symbol to indicate the > root is a good one. Another possibility (not mutually exclusive with that > one) is to have some shorthand like using ".." in a context where a URL > is required to "do the right thing". (Obviously an issue here is in

Re: svn diff branch woprking copy against mainline?

On Wed, Nov 02, 2005 at 11:00:32PM -0500, Richard Kenner wrote: > However, I also think that some sort of shorthand mechanism would greatly > help the "verbosity problem". We have a situation where the simplest > things are very short and very complex things are very long (both of which > are quit

Re: SH: PR target/24445

Kaz Kojima <[EMAIL PROTECTED]> writes: > Like this? > > @@ -2861,6 +2861,12 @@ expand_call (tree exp, rtx target, int i > >If they refer to the same register, this move will be a no-op, >except when function inlining is being done. */ > + /* We have to copy a retu

Re: svn diff branch woprking copy against mainline?

However, before coming up with a zillion suggestions about how to make the syntax nicer, please do consider the idea that we did put a lot of thought into the diff syntax, and that covering all the uses and edge cases and is not easy. Right. And I don't think most people disagree

Re: svn diff branch woprking copy against mainline?

Joe Buck wrote: On Wed, Nov 02, 2005 at 06:28:42PM -0500, Daniel Berlin wrote: On Wed, 2005-11-02 at 14:33 -0800, Mike Stump wrote: On Nov 2, 2005, at 2:18 PM, Joern RENNECKE wrote: I tried: bash-2.05b$ svn diff Makefile.in svn+ssh://[EMAIL PROTECTED]/svn/ gcc/trunk/gcc/[EMAIL

Re: -Wuninitialized issues

On Wed, Nov 02, 2005 at 07:17:06PM -0700, Jeffrey A Law wrote: > Very true, but I don't think that's an execute to generate even more > false positives for them! :-) I disagree. The point of this set of warnings is that they would be _simple_ and _consistent_. Less likely to change across releas

Re: -Wuninitialized issues

On Wed, Nov 02, 2005 at 05:53:49PM -0800, Joe Buck wrote: > On Wed, Nov 02, 2005 at 08:44:51PM -0500, Daniel Jacobowitz wrote: > > On Wed, Nov 02, 2005 at 05:32:51PM -0800, Joe Buck wrote: > > > On Thu, Nov 03, 2005 at 02:13:05AM +0100, Gabriel Dos Reis wrote: > > > > | Have -Wuninitialized be a ve

Successful build of gcc 3.3.4

Hi all. Just reporting a successful build of GCC version 3.3.4 for the full GCC bundle on a platform not listed in your build stats. Note that this exact version is of special interest, since it is the required release for development of Maya plugins (see http://www.alias.com/eng/support/maya/q

Re: -Wuninitialized issues

On Wed, 2005-11-02 at 20:44 -0500, Daniel Jacobowitz wrote: > On Wed, Nov 02, 2005 at 05:32:51PM -0800, Joe Buck wrote: > > On Thu, Nov 03, 2005 at 02:13:05AM +0100, Gabriel Dos Reis wrote: > > > | Have -Wuninitialized be a very simple detector, which is either in the > > > front-ends > > > | or i

Re: SH: PR target/24445

Ian Lance Taylor wrote: > I don't see what this has to do with pure functions. > > It seems to me that instead you want to put something here: > > else if (target > && GET_MODE (target) == TYPE_MODE (TREE_TYPE (exp)) > && GET_MODE (target) == GET_MODE (valreg)) >

Re: -Wuninitialized issues

Jeffrey A Law wrote: > For example, if the only use was inside an unreachable hunk of > code, does that count as a use or not? Yes, the EDG front-end does this: [EMAIL PROTECTED]:~/tmp$ cat test.cpp void f() { int i; if (0) i = 3; } [EMAIL PROTECTED]:~/tmp$ eccp -A test.cpp "test.cpp", l

Re: SH: PR target/24445

> > Kaz Kojima <[EMAIL PROTECTED]> writes: > > > --- ORIG/trunk/gcc/calls.c 2005-10-29 06:52:11.0 +0900 > > +++ LOCAL/trunk/gcc/calls.c 2005-11-03 09:15:47.0 +0900 > > @@ -2774,6 +2774,17 @@ expand_call (tree exp, rtx target, int i > > emit_insn (insns); > > valreg =

Re: -Wuninitialized issues

On Wed, 2005-11-02 at 16:43 -0800, Mark Mitchell wrote: > Jeff, I'm sorry you're upset; I actually think we're closer to consensus > than we've ever been before on this issue. :-) Maybe that's what's getting under my skin! Rehashing those issues where I think we do have a consensus, namely the nee

Re: -Wuninitialized issues

On Wed, Nov 02, 2005 at 08:44:51PM -0500, Daniel Jacobowitz wrote: > On Wed, Nov 02, 2005 at 05:32:51PM -0800, Joe Buck wrote: > > On Thu, Nov 03, 2005 at 02:13:05AM +0100, Gabriel Dos Reis wrote: > > > | Have -Wuninitialized be a very simple detector, which is either in the > > > front-ends > > >

Re: SH: PR target/24445

Kaz Kojima <[EMAIL PROTECTED]> writes: > --- ORIG/trunk/gcc/calls.c2005-10-29 06:52:11.0 +0900 > +++ LOCAL/trunk/gcc/calls.c 2005-11-03 09:15:47.0 +0900 > @@ -2774,6 +2774,17 @@ expand_call (tree exp, rtx target, int i > emit_insn (insns); > valreg = temp; >

Re: -Wuninitialized issues

On Wed, 2005-11-02 at 20:35 -0500, Kaveh R. Ghazi wrote: > > Have another option to detect variables which are set but their values > > are not used (this was in one of the -Wuninitialized bugs and has been > > asked before). The EDG front-end implements this option. > > Andrew Pinski > > The

Re: [cft] aligning main's stack frame

After some more testing, I went ahead and committed this. r~

Re: -Wuninitialized issues

On Wed, Nov 02, 2005 at 05:32:51PM -0800, Joe Buck wrote: > On Thu, Nov 03, 2005 at 02:13:05AM +0100, Gabriel Dos Reis wrote: > > | Have -Wuninitialized be a very simple detector, which is either in the > > front-ends > > | or in the middle-end so it could be shared (just like -Wunused). > > | Hav

Re: svn diff branch woprking copy against mainline?

Daniel Berlin <[EMAIL PROTECTED]> writes: > > There's been talk of a DEFAULTREPO or allowing substitutions and aliases > > in the config file, or something > > > > > > Of course, the question always raised when you try to do this is "why is > this better than just using shell variables" > > if

Re: -Wuninitialized issues

> Have another option to detect variables which are set but their values > are not used (this was in one of the -Wuninitialized bugs and has been > asked before). The EDG front-end implements this option. > Andrew Pinski The sgi compiler detects this also. I'd really like gcc to have it, but

Re: -Wuninitialized issues

On Thu, Nov 03, 2005 at 02:13:05AM +0100, Gabriel Dos Reis wrote: > | Have -Wuninitialized be a very simple detector, which is either in the > front-ends > | or in the middle-end so it could be shared (just like -Wunused). > | Have -Wuninitialized=2, be the current -Wuninitialized. > > That is ba

Re: -Wuninitialized issues

> What we're in disagreement about is whether or not that class of > warnings should be triggered by -Wuninitialized. I STRONGLY believe > that -Wuninitialized should remain as-is in its documented behavior > and that we should have a distinct switch to get the new behavior. Fine, but which o

Re: -Wuninitialized issues

Andrew Pinski <[EMAIL PROTECTED]> writes: | > | > Diego Novillo wrote: | > | > > Agreed 100%. My vote is to use your proposal for -Wuninitialized and have, | > > as you said, another flag that does the analysis immediately after going | > > into SSA, before any transformations are done. | >

Re: svn diff branch woprking copy against mainline?

On Wed, Nov 02, 2005 at 06:28:42PM -0500, Daniel Berlin wrote: > On Wed, 2005-11-02 at 14:33 -0800, Mike Stump wrote: > > On Nov 2, 2005, at 2:18 PM, Joern RENNECKE wrote: > > > I tried: > > > bash-2.05b$ svn diff Makefile.in svn+ssh://[EMAIL PROTECTED]/svn/ > > > gcc/trunk/gcc/[EMAIL PROTECTED] >

Re: -Wuninitialized issues

> > Diego Novillo wrote: > > > Agreed 100%. My vote is to use your proposal for -Wuninitialized and have, > > as you said, another flag that does the analysis immediately after going > > into SSA, before any transformations are done. > > It certainly doesn't bother me to have -Wuninitialized

Re: -Wuninitialized issues

Diego Novillo wrote: > Agreed 100%. My vote is to use your proposal for -Wuninitialized and have, > as you said, another flag that does the analysis immediately after going > into SSA, before any transformations are done. It certainly doesn't bother me to have -Wuninitialized continue to mean

Re: SH: PR target/24445

Joern RENNECKE <[EMAIL PROTECTED]> wrote: >>[.expand after the patch] >>(set (reg/f:SI 160) (const:SI (unspec [(symbol_ref:SI ("baz"))] 7))) >>(set (reg:SI 161) (plus:SI (reg:SI 12 r12) (reg/f:SI 160))) >>(set (reg/f:SI 159) (mem/u/c:SI (reg:SI 161))) >>(set (reg:SI 0 r0) (call (mem:SI (symbol_ref:

Re: -Wuninitialized issues

On Wednesday 02 November 2005 19:19, Jeffrey A Law wrote: > What we're in disagreement about is whether or not that class of > warnings should be triggered by -Wuninitialized. I STRONGLY believe > that -Wuninitialized should remain as-is in its documented behavior > and that we should have a dist

Re: svn diff branch woprking copy against mainline?

> I put it in a file called "checker" and, when I need it, ./checker What I usually do is create a script called ".go" somewhere above it, and I have a ~/bin/go that locates it and runs it. I use this all over the place, so I'm used to just typing "go" or "go " to DTRT. #!/usr/bin/perl # -*-

Re: [libgfortran] Patch to handle statically linked libgfortran

On Wed, Nov 02, 2005 at 11:11:42PM +0100, FX Coudert wrote: > 2005-11-02 Francois-Xavier Coudert <[EMAIL PROTECTED]> > > PR libfortran/22298 > * gcc/testsuite/lib/target-supports.exp > (check_effective_target_static_libgfortran): New > static_libgfortran effective target.

Re: svn diff branch woprking copy against mainline?

> But I'd rather do: > svn diff Makefile.in -rgcc_4_1_1_release > > I.e. no silly naming of the path from the trunk root to the file, and no > repetition of the file name itself. $ cat `which difftag` #! /bin/sh if echo "$1" | grep '-branch$' > /dev/null ; then subdir=branches else subdir=tags

Re: -Wuninitialized issues

On Wed, 2005-11-02 at 19:04 -0500, Kaveh R. Ghazi wrote: > > I would suggest you look at our testsuite and our PR database and > > see how many PRs we've got about false-positive warnings. Achieving > > consistency will merely increase the false-positives and as a result > > make the warning l

Re: svn diff branch woprking copy against mainline?

On Wed, Nov 02, 2005 at 06:39:53PM -0500, Daniel Berlin wrote: > Of course, the question always raised when you try to do this is "why is > this better than just using shell variables" > > if you can give me a good answer to take back to [EMAIL PROTECTED], i'm > happy to If we had something to ex

Re: -Wuninitialized issues

> I would suggest you look at our testsuite and our PR database and > see how many PRs we've got about false-positive warnings. Achieving > consistency will merely increase the false-positives and as a result > make the warning less useful IMHO. I looked at meta-bug 24639, it refers to severa

Re: svn diff branch woprking copy against mainline?

Daniel Berlin wrote: Of course, the question always raised when you try to do this is "why is this better than just using shell variables" if you can give me a good answer to take back to [EMAIL PROTECTED], i'm happy to shell variable scenario: gcc.gnu.org has a special file that people can

Re: svn diff branch woprking copy against mainline?

Daniel Berlin wrote: svn needs to go on a long command line diet, True. However, it *does* need some way to differentiate between url->url, url->wc, and wc->url commands, so even if there was an SVNROOT, you'd still have to specify it on the command lines :) I can't follow that rea

Re: svn diff branch woprking copy against mainline?

> There's been talk of a DEFAULTREPO or allowing substitutions and aliases > in the config file, or something > > Of course, the question always raised when you try to do this is "why is this better than just using shell variables" if you can give me a good answer to take back to [EMAIL PROTECT

Re: SH: PR target/24445

Kaz Kojima wrote: [.expand after the patch] (set (reg/f:SI 160) (const:SI (unspec [(symbol_ref:SI ("baz"))] 7))) (set (reg:SI 161) (plus:SI (reg:SI 12 r12) (reg/f:SI 160))) (set (reg/f:SI 159) (mem/u/c:SI (reg:SI 161))) (set (reg:SI 0 r0) (call (mem:SI (symbol_ref:SI ("bar") (set (mem/c/i:S

Re: svn diff branch woprking copy against mainline?

On Wed, 2005-11-02 at 14:33 -0800, Mike Stump wrote: > On Nov 2, 2005, at 2:18 PM, Joern RENNECKE wrote: > > I tried: > > bash-2.05b$ svn diff Makefile.in svn+ssh://[EMAIL PROTECTED]/svn/ > > gcc/trunk/gcc/[EMAIL PROTECTED] > > > > But that gives me an error message: > > > > svn: Target lists to d

Re: -Wuninitialized issues

Chris Lattner wrote:- > >I think it's worth noting that we build the SSA form even when we're > >not optimizing. Which in turn with running the maybe-uninitialized > >warning code early would give you the warnings you expect without > >needing to run the optimizers. That's why I don't think we n

Re: svn diff branch woprking copy against mainline?

DJ Delorie wrote: svn needs to go on a long command line diet, The documentation does suggest the use of environment variables, but it would be nice if there were a .svnrc that let you create shortcuts for the command line. Like, if you could add alias 401 svn+ssh://gcc.gnu.org/svn/gcc/

Re: svn diff branch woprking copy against mainline?

Mike Stump wrote: svn diff --old svn+ssh://gcc.gnu.org/svn/gcc/tags/gcc_4_0_1_release/ gcc/file.c --new file.c Thanks, --old / --new does the trick. However, I must say the error message is rather misleading. svn needs to go on a long command line diet, it is seriously no fun to repea

SH: PR target/24445

Hi, I've tried to see what is gonig on for PR target/24445 which is a 4.1 regression of SH. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24445 Comparing rtl dumps for the reduced testcase in the audit trail #4 of that PR with and without Jan's patch in #10, there is no return value copy in the rt

Re: svn diff branch woprking copy against mainline?

> svn needs to go on a long command line diet, The documentation does suggest the use of environment variables, but it would be nice if there were a .svnrc that let you create shortcuts for the command line. Like, if you could add alias 401 svn+ssh://gcc.gnu.org/svn/gcc/tags/gcc_4_0_1_release

Re: svn diff branch woprking copy against mainline?

On Nov 2, 2005, at 2:18 PM, Joern RENNECKE wrote: I tried: bash-2.05b$ svn diff Makefile.in svn+ssh://[EMAIL PROTECTED]/svn/ gcc/trunk/gcc/[EMAIL PROTECTED] But that gives me an error message: svn: Target lists to diff may not contain both working copy paths and URLs This works for us: s

svn diff branch woprking copy against mainline?

How do I diff a modified working copy of a branch against a specific version of the mainline? This operation is essential when sanity-checking merges from mainline to a branch of files that have changed more in mainline than in the branch. With cvs, that was as easy as saying: bash-2.05b$ cvs

Re: [libgfortran] Patch to handle statically linked libgfortran

How does the test in check_effective_target_static_libgfortran check for use of static libgfortran? Shouldn't it pass -static or something? If it's really doing it already by a means that is not apprarent, please add a comment. That proc has a comment that was copied from another proc, please f

Re: -Wuninitialized issues

Bernhard R. Link wrote: * Chris Lattner <[EMAIL PROTECTED]> [051102 19:28]: Jeff Law wrote: >> I prefer consistency in warnings, regardless of optimization level. >I disagree and I think we have a significant contingency of >users that would disagree Jeff, I completely agree with you for som

RE: What are the differences between 2.95.3 and 3.2.3?

http://gcc.gnu.org/gcc-3.0/features.html http://gcc.gnu.org/gcc-3.0/caveats.html http://gcc.gnu.org/gcc-3.1/changes.html http://gcc.gnu.org/gcc-3.2/changes.html Regards, Ryan Mansfield -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pascal Aschwanden

What are the differences between 2.95.3 and 3.2.3?

thanks, Pascal

Re: weird installation problem on i686-pc-linux-gnu

On Nov 2, 2005, at 2:35 AM, Martin Reinecke wrote: Is this a bug in my local version of "install", or could it be interpreted as acceptable behaviour? I'd call it a bug. Free free to recraft your environment to not feature that install. If it were a popular install, a check for it could

Re: -Wuninitialized issues

On Wed, 2 Nov 2005, Jeffrey A Law wrote: Sure, running it as the first stage of the optimizers has the effect of making it have the properties I desire, without requiring the front-ends to duplicate the code. Such a feature would be great to have! I think we've all agreed it's a good feature to

Re: -Wuninitialized issues

On Wed, 2005-11-02 at 14:19 -0500, Andrew Pinski wrote: > > > However, I'll freely admit this is just my notoriously fallible memory > > > at work here; I've not reviewed the PRs. > > Mine is as fallable as yours :-) > > All of the PRs that I could find, closed or not are in the meta-bug filed >

Re: -Wuninitialized issues

On Wed, 2005-11-02 at 12:55 -0600, Chris Lattner wrote: > > I think it's worth noting that we build the SSA form even when we're > > not optimizing. Which in turn with running the maybe-uninitialized > > warning code early would give you the warnings you expect without > > needing to run the optim

Re: -Wuninitialized issues

* Chris Lattner <[EMAIL PROTECTED]> [051102 19:28]: > > Jeff Law wrote: > >> I prefer consistency in warnings, regardless of optimization level. > >I disagree and I think we have a significant contingency of > >users that would disagree -- if optimizations allow us to avoid > >false-positive warni

Re: -Wuninitialized issues

> > However, I'll freely admit this is just my notoriously fallible memory > > at work here; I've not reviewed the PRs. > Mine is as fallable as yours :-) All of the PRs that I could find, closed or not are in the meta-bug filed as PR 24639: . Thanks, Andrew Pinski

Re: -Wuninitialized issues

On Wed, 2005-11-02 at 09:58 -0800, Mark Mitchell wrote: > Jeffrey A Law wrote: > > > Again, the problem I have with the notion that we want to get > > consistent answers is that doing so, is going to give us a lot of > > false positives. That IMHO is a huge step backwards if that's how > > we mak

Re: -Wuninitialized issues

On Wed, 2 Nov 2005, Jeffrey A Law wrote: On Wed, 2005-11-02 at 12:01 -0600, Chris Lattner wrote: [ ... big snip ... ] For users like myself, I would really like to have an option to switch the unused var warning to be emitted from the *front-end* where it works when compiling with optimization d

Re: -Wuninitialized issues

On Wed, 2005-11-02 at 12:01 -0600, Chris Lattner wrote: [ ... big snip ... ] > For users like myself, I would really like to have an option to switch the > unused var warning to be emitted from the *front-end* where it works when > compiling with optimization disabled (a huge feature in itself) a

Re: -Wuninitialized issues

Jeff Law wrote: > I prefer consistency in warnings, regardless of optimization level. I disagree and I think we have a significant contingency of users that would disagree -- if optimizations allow us to avoid false-positive warnings, then we should use that information to avoid those false posi

Re: -Wuninitialized issues

Jeffrey A Law wrote: > Again, the problem I have with the notion that we want to get > consistent answers is that doing so, is going to give us a lot of > false positives. That IMHO is a huge step backwards if that's how > we make -Wuninitialized work. You're right that it's the users that matte

Re: -Wuninitialized issues

On Tue, 2005-11-01 at 12:56 -0800, Mark Mitchell wrote: > Diego Novillo wrote: > > > We won't get perfect answers, which is fine given the nature of the > > problem. However, I would like, to get *consistent* answers. > > Yes, I agree that's very important. In fact, I'd like to generalize > th

Re: -Wuninitialized issues

On Tue, 2005-11-01 at 13:26 -0500, Diego Novillo wrote: > We won't get perfect answers, which is fine given the nature of the > problem. However, I would like, to get *consistent* answers. If we > decide to re-organize the optimization pipeline, we should not be getting > different -Wuninitial

Re: [RFC] c++ template instantiation generates zero-sized array (pr 19989)

Mark Mitchell wrote: > Josh Conner wrote: > > >>I think this is consistent with my proposal -- the first example was >>non-conforming, but accepted without -pedantic (as we do with other >>zero-sized arrays). The second example was conforming and the only way >>to alter its behavior was with the

Re: [gfortran] fortran preprocessing, round 2

On Wed, Nov 02, 2005 at 12:20:36PM +0100, François-Xavier Coudert wrote: > I'll commit when 4.1 unfreezes before branching. Could that apply to > branch 4.0 as well? As you like. r~

Re: -Wuninitialized issues

On Tue, 2005-11-01 at 22:10 -0500, Kaveh R. Ghazi wrote: > > I prefer consistency in warnings, regardless of optimization level. I disagree and I think we have a significant contingency of users that would disagree -- if optimizations allow us to avoid false-positive warnings, then we should use

Re: [RFC] c++ template instantiation generates zero-sized array (pr 19989)

Josh Conner wrote: > I think this is consistent with my proposal -- the first example was > non-conforming, but accepted without -pedantic (as we do with other > zero-sized arrays). The second example was conforming and the only way > to alter its behavior was with the -fpermissive option. My po

Re: [RFC] c++ template instantiation generates zero-sized array (pr 19989)

Mark Mitchell wrote: > I understand what you're after: tolerate uses of the extension where > it's sufficiently harmless. > > I don't think your proposed solution is correct, though, because we want > to maintain the invariant that all conforming programs compile and > behave as required by the s

Re: Library commits vs Bugzilla

On Wed, 2005-11-02 at 17:20 +0100, Paolo Carlini wrote: > Daniel Berlin wrote: > > >Is this still happening? > > > >I thought i fixed this a few days ago (the perl regex for matching prs > >didn't translate perfectly into python) > > > >Can you please give me a revision number to play with? > > >

Re: Library commits vs Bugzilla

Daniel Berlin wrote: >Is this still happening? > >I thought i fixed this a few days ago (the perl regex for matching prs >didn't translate perfectly into python) > >Can you please give me a revision number to play with? > Sure: today 106379 fixed libstdc++/23425. Thanks for your quick feedback! P

Re: Library commits vs Bugzilla

Is this still happening? I thought i fixed this a few days ago (the perl regex for matching prs didn't translate perfectly into python) Can you please give me a revision number to play with? On Wed, 2005-11-02 at 16:57 +0100, Paolo Carlini wrote: > Hi, > > I noticed that library commits fixing

Library commits vs Bugzilla

Hi, I noticed that library commits fixing PRs (PR libstdc++/x) don't get notified anymore to Bugzilla and don't get logged in the audit trail. I liked that feature and probably the new behavior is not intended and the other categories work like before. Danny, can you look into that? Thanks in

Re: [gfortran] fortran preprocessing, round 2

>> PR fortran/18452 >> * gcc/c.opt: Add a -lang-fortran option. >> * gcc/c-opts.c: Add a lang_fortran flag. >> (c_common_init_options): Handling the -lang-fortran option. >> (c_common_handle_option): Add a case for Fortran options in >> preprocessing. Remove case

Re: weird installation problem on i686-pc-linux-gnu

Hi Jim, the problem lies in the command -$(INSTALL_PROGRAM) xgcc$(exeext) $(DESTDIR)$(bindir)/$(GCC_INSTALL_NAME)$(exeext) which on my machine evaluates to /afs/rzg/@sys/bin/install -c xgcc /afs/mpa/data/martin/ugcc/bin/gcc Apparently this special version of "install" in my path crea

RE: GCC 4.0.2 Canadian Cross Compile

Hi Nathanael, Yes I would like to help. At the moment my sparc-linux system has some issues (C Library/Linux Kernel) that appear to be preventing correct operation of execve. Until I have tracked down the problem, I can only test strait cross-compilation from x86 to sparc. I can however test x86

Re: weird installation problem on i686-pc-linux-gnu

Jim Wilson wrote: Martin Reinecke wrote: i.e. the "gcc" binary ends up as "xgcc" in a subdirectory called "gcc". The gcc makefile install rule just does rm -f $destdir/bin/gcc install xgcc $destdir/bin/gcc If destdir/bin/gcc is non-existant, or a plain file, then this works as expected.

Re: Shared libraries

* Softish soft | 2005-11-02 08:31:05 [+]: >What I mean with shared library is that I build a library that somehow can >dynamically be called over an ethernet cable. That's a feature that you don't want! This implied many technics that are not the tenor of gcc or another compiler! Upper tech

Re: A question about memcpy

This is the wrong list for such questions. In the future, please use gcc-help, thanks. On Nov 1, 2005, at 10:38 PM, Eric Fisher wrote: When I compile such c codes as following, int a=0x,i; int sra[32]={0x,0x,0x,0x, 0x,0x,0x,

Re: Shared libraries

On Nov 2, 2005, at 12:31 AM, Softish soft wrote: I'm wondering if it's possible to build a shared library with GCC. Yes, see the documentation. gcc-help is a more appropriate list for all your questions. Use google to read up on what a shared library is and how they work, and all the oth

Shared libraries

Hi! I'm wondering if it's possible to build a shared library with GCC. What I mean with shared library is that I build a library that somehow can dynamically be called over an ethernet cable. For example. I build my program and run it in one computer, when it needs a specific library, it dyna