On Thu, Jul 28, 2005 at 08:36:11PM -0700, David Daney wrote:
> I can detect this special case in _bfd_mips_elf_add_symbol_hook() and
> cause it to be ignored, thus solving the problem.
>
> Does this seem like a reasonable course of action?
Yes. That does cost a strcmp on every symbol in every i
Kurt Wall wrote:
> On Thu, Jul 28, 2005 at 11:09:17PM -0300, Christian Hartung took 3 lines to
> write:
>
>>When GCC will include a front end for D?
>>
>>www.digitalmars.com/d
>
>
> Presumably when someone writes one and submits it and signs the
> paperwork and agrees to maintain it going forwa
David Daney <[EMAIL PROTECTED]> writes:
> I have a a mipsel-linux cross compiler (gcc-3.4.3/binutils-2.16.1) and
> whenever I compile even the simplest hello-world.c libgcc_s.so is linked.
FWIW, I'm seeing the same thing with a similar native setup.
I hope to have a look at it soon.
Richard
Daniel Jacobowitz wrote:
On Thu, Jul 28, 2005 at 07:39:57PM -0700, David Daney wrote:
It seems that the linker thinks that any shared object that references
the magic _gp_disp symbol actually provides it. Since all mips objects
reference _gp_disp, ld thinks that all shared objects are require
On Thu, Jul 28, 2005 at 07:39:57PM -0700, David Daney wrote:
> It seems that the linker thinks that any shared object that references
> the magic _gp_disp symbol actually provides it. Since all mips objects
> reference _gp_disp, ld thinks that all shared objects are required to
> resolve all th
On Thu, Jul 28, 2005 at 11:09:17PM -0300, Christian Hartung took 3 lines to
write:
> When GCC will include a front end for D?
>
> www.digitalmars.com/d
Presumably when someone writes one and submits it and signs the
paperwork and agrees to maintain it going forward and...
Kurt
--
Don't let you
Christian Hartung wrote:
When GCC will include a front end for D?
www.digitalmars.com/d
when you or someone else writes one :-)
[EMAIL PROTECTED] wrote:
ddaney wrote:
I have a a mipsel-linux cross compiler (gcc-3.4.3/binutils-2.16.1)
and whenever I compile even the simplest hello-world.c libgcc_s.so is
linked.
Just curious -- how did you build your cross-compiler?
I have a bunch of rpm build scripts, but they pret
When GCC will include a front end for D?
www.digitalmars.com/d
ddaney wrote:
> I have a a mipsel-linux cross compiler (gcc-3.4.3/binutils-2.16.1)
> and whenever I compile even the simplest hello-world.c libgcc_s.so is
linked.
Just curious -- how did you build your cross-compiler?
Do toolchains built by crosstool have this problem?
(I'm away from home, or I'd
H. J. Lu wrote:
On Thu, Jul 28, 2005 at 01:54:40PM -0700, David Daney wrote:
Do you know of a patch to binutils since 2.16.1 that would fix the problem?
I remember there were some patches for as needed. But I don't know if
they are in 2.16.1 or not.
HEAD also seems to fail.
David Daney.
On Thu, Jul 28, 2005 at 12:31:05PM -0700, James E Wilson wrote:
> Mark Cuss wrote:
> >[EMAIL PROTECTED] helloworldsun]$ g++ -b sparc-sun-solaris2.9 hello.cxx
> >/cdl/apps/.software/linux/gcc-3.4.4-x86-sparc/lib/gcc/sparc-sun-solaris2.9/3.4.4/../../../../sparc-sun-solaris2.9/bin/ld:
> >
> >values-X
On Thursday 28 July 2005 08:22 pm, James E Wilson wrote:
> On Thu, 2005-07-28 at 16:58, Greg Schafer wrote:
> > Glibc headers ARE provided -> inhibit_libc NOT defined -> optimal
> > Glibc headers ARE NOT provided -> inhibit_libc IS defined -> suboptimal
>
> This is basically what I meant, but I d
On Thu, Jul 28, 2005 at 01:54:40PM -0700, David Daney wrote:
>
> Do you know of a patch to binutils since 2.16.1 that would fix the problem?
>
I remember there were some patches for as needed. But I don't know if
they are in 2.16.1 or not.
H.J.
On Thu, 2005-07-28 at 16:58, Greg Schafer wrote:
> Glibc headers ARE provided -> inhibit_libc NOT defined -> optimal
> Glibc headers ARE NOT provided -> inhibit_libc IS defined -> suboptimal
This is basically what I meant, but I don't want to get in a debate
about what is optimal and what isn't
Snapshot gcc-4.0-20050728 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.0-20050728/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.0 CVS branch
with the following options: -rgcc-ss-4_0-20050728
You'll
On Thu, Jul 28, 2005 at 02:26:16PM -0700, James E Wilson wrote:
> It looks like you forgot to check the crt*.o files for undefined
> references.
>
> If the gcc/glibc toolchain wasn't built the optimal way, it is possible
> for crtbegin.o to have register_frame_info and deregister_frame_info
> cal
Geoffrey,
Well the gcc4.info for the package containing gfortran in fink has...
Depends: gmp-shlibs (>= 4.1.3-11), cctools (>= 576-1) | odcctools (>= 576-200503
27), %N-shlibs, libiconv
BuildDepends: gmp (>= 4.1.3-11), libiconv-dev
which is a tad confusing since I guess it implies that cctools
> "Jim" == James E Wilson <[EMAIL PROTECTED]> writes:
Jim> Appropriate info should be added here:
Jim> http://gcc.gnu.org/codingconventions.html#upstream
Jim> This is where we keep track of such things.
Thanks, I'll fix this when I get back from my trip.
Tom
> "Joe" == Joe Buck <[EMAIL PROTECTED]> writes:
Joe> Cool; does this mean that the amount of code built by a gcc bootstrap
Joe> will decrease? Or will the combined libgjc/Classpath code still be all
Joe> included in the gcc distribution.
It will all still be in there. It is just a differenc
[EMAIL PROTECTED] (Jack Howarth) writes:
> Since gfortran is making such good progress at this point, it
> would seem like a really good idea for Apple to add the gfortran build
> to its builds on regress. It would make is easier for Mac users to
> tell what the expected status is of gfortran
David Daney wrote:
Recently we experienced the Big-Classpath-Merge. Now most of the source
code for libgcj is maintained in the Classpath project and periodically
copied into the GCC CVS repository.
Appropriate info should be added here:
http://gcc.gnu.org/codingconventions.html#upstream
James E Wilson <[EMAIL PROTECTED]> writes:
> Ian Lance Taylor wrote:
> > -Wstrict-aliasing=2. It warns about more possible problems than
> > -Wstrict-aliasing, but it does not warn about all possible problems.
>
> This is the important point that I was trying to get across, though I
> do see tha
On Thu, Jul 28, 2005 at 10:41:48AM -0700, Steve Kargl wrote:
> On Thu, Jul 28, 2005 at 07:26:22PM +0200, Fran?ois-Xavier Coudert wrote:
> >
> > PR 22619 and PR 22509 are two examples of recent 4.1 regressions that
> > showed up in gfortran, due to middle-end or optimization bugs (only
> > happen a
On Thu, Jul 28, 2005 at 12:17:26PM -0700, David Daney wrote:
> Recently we experienced the Big-Classpath-Merge. Now most of the source
> code for libgcj is maintained in the Classpath project and periodically
> copied into the GCC CVS repository.
Cool; does this mean that the amount of code bui
Hi,
On Thu, 2005-07-28 at 12:17 -0700, David Daney wrote:
> The consensus from the gcj IRC seems to be that a copyright assignment
> for Classpath is now necessary for contributions to the parts of libgcj
> that are maintained by Classpath. This also means that said patches
> should be checked
On Thu, Jul 28, 2005 at 02:26:16PM -0700, James E Wilson wrote:
> On Thu, 2005-07-28 at 12:48, David Daney wrote:
> > Also you can see that neither hello-world.o nor my libc-2.3.3.so have
> > any undefined symbols that would be satisfied by libgcc_s.so.
>
> It looks like you forgot to check the c
On Thu, 2005-07-28 at 12:48, David Daney wrote:
> Also you can see that neither hello-world.o nor my libc-2.3.3.so have
> any undefined symbols that would be satisfied by libgcc_s.so.
It looks like you forgot to check the crt*.o files for undefined
references.
If the gcc/glibc toolchain wasn't b
Since gfortran is making such good progress at this point, it
would seem like a really good idea for Apple to add the gfortran build
to its builds on regress. It would make is easier for Mac users to
tell what the expected status is of gfortran on Darwin. Thanks in
advance for considering this
Hi
I updated my function call creating statement based on how
gomp_parallel_end is inserted in the gomp branch. It still breaks. I
have provided the function declaration in the file, just want to
insert the call. Any further suggestions. My whole objective is to
mark a few particular
tree s
On Jul 28, 2005, at 12:42 PM, Kean Johnston wrote:
[ cough ] "always_inline" [ cough ]
HA!
I *knew* there was a solution. Thank you Mike.
So now I guess the question remains, for the cases where
you want a function to behave differently depending on
pre-processor conditionals, whats the best w
H. J. Lu wrote:
On Thu, Jul 28, 2005 at 12:48:31PM -0700, David Daney wrote:
I am not sure if this is a GCC problem or a binutils problem.
I have a a mipsel-linux cross compiler (gcc-3.4.3/binutils-2.16.1) and
whenever I compile even the simplest hello-world.c libgcc_s.so is linked.
When I
On Thu, Jul 28, 2005 at 12:48:31PM -0700, David Daney wrote:
> I am not sure if this is a GCC problem or a binutils problem.
>
> I have a a mipsel-linux cross compiler (gcc-3.4.3/binutils-2.16.1) and
> whenever I compile even the simplest hello-world.c libgcc_s.so is linked.
>
> When I do the sa
So, can I summarize your question as a way of trying to make "open"
and alias for open32 or open63 and not having to get into the trap of
different function address? If yes, does glibc's weak_alias would
work for you without creating new problems?
Yeah thats pretty much it, but I dont think weak
Kean Johnston <[EMAIL PROTECTED]> writes:
| > [ cough ] "always_inline" [ cough ]
| HA!
|
| I *knew* there was a solution. Thank you Mike.
|
| So now I guess the question remains, for the cases where
| you want a function to behave differently depending on
| pre-processor conditionals, whats the
I am not sure if this is a GCC problem or a binutils problem.
I have a a mipsel-linux cross compiler (gcc-3.4.3/binutils-2.16.1) and
whenever I compile even the simplest hello-world.c libgcc_s.so is linked.
When I do the same thing natively on my i686/FC3, libgcc_s.so is not linked.
If if exp
>
> Hi all,
>
> PR 22619 and PR 22509 are two examples of recent 4.1 regressions that
> showed up in gfortran, due to middle-end or optimization bugs (only
> happen at -O3). Since these are regressions, they should be treated
> before a long time passes, but since both source codes are Fortran, I
[ cough ] "always_inline" [ cough ]
HA!
I *knew* there was a solution. Thank you Mike.
So now I guess the question remains, for the cases where
you want a function to behave differently depending on
pre-processor conditionals, whats the best way of doing
it? The particularly interesting case is
Mark Cuss wrote:
[EMAIL PROTECTED] helloworldsun]$ g++ -b sparc-sun-solaris2.9 hello.cxx
/cdl/apps/.software/linux/gcc-3.4.4-x86-sparc/lib/gcc/sparc-sun-solaris2.9/3.4.4/../../../../sparc-sun-solaris2.9/bin/ld:
values-Xa.o: No such file: No such file or directory
collect2: ld returned 1 exit st
Ian Lance Taylor wrote:
-Wstrict-aliasing=2. It warns about more possible problems than
-Wstrict-aliasing, but it does not warn about all possible problems.
This is the important point that I was trying to get across, though I do
see that using "all" can be misconstrued here. How about somet
Recently we experienced the Big-Classpath-Merge. Now most of the source
code for libgcj is maintained in the Classpath project and periodically
copied into the GCC CVS repository.
In the old days if you had copyright assignments for GCC you could
contribute code to libgcj.
The consensus fro
Liu Haibin wrote:
to "c". However, it seems very difficult here. The old insn patterns
are all general registers, but the new insn patterns are defined as
custom registers.
The peephole pass does not do register allocation. So you can't use it
to magically change "r" registers to "c" register
On Jul 28, 2005, at 9:12 AM, Kean Johnston wrote:
extern int stat (const char *__p, stat_t *__s);
extern __inline__ int
stat(const char *__p, stat_t *__s)
{
return _xstat(_STAT_VER, __p, __s);
}
However, it caused a problem bootstrapping the compiler, becuase
the first stage do
On Thu, Jul 28, 2005 at 11:31:55AM -0700, Kean Johnston wrote:
> >>However, I *think* I like the semantics of 'extern inline'
> >>better: use the inline version for the most part but if,
> >>for example, you take the address of the function, use the
> >>actual symbol stat(). But I see that most oth
On Jul 27, 2005, at 7:04 PM, Paul C. Leopardi wrote:
OK. Looks like a long term project.
Should be as easy as debugging three lines of code. Insert a couple
of printf's and voila.
Wild ass guess, did you type make -k check?
Yes. Is there something wrong with that?
No, that is the righ
However, I *think* I like the semantics of 'extern inline'
better: use the inline version for the most part but if,
for example, you take the address of the function, use the
actual symbol stat(). But I see that most other fixincs
use static inline.
Huh? This paragraph conflicts with the previ
On Thu, Jul 28, 2005 at 01:15:22PM -0400, drizzle drizzle wrote:
> I am inserting a call stmt in linear_transform_loops. Al though
> the call statement gets inserted , the compilation breaks. Can some
> one help me identify if I am missing some information in the call
> node that I create
On Thu, 2005-07-28 at 19:26 +0200, François-Xavier Coudert wrote:
> Hi all,
>
> PR 22619 and PR 22509 are two examples of recent 4.1 regressions that
> showed up in gfortran, due to middle-end or optimization bugs (only
> happen at -O3). Since these are regressions, they should be treated
> before
Hello all
Can anyone shed any light on this problem for me? I've built gcc 3.4.4 as a
Linux (on x86) to Solaris (on SPARC) cross compiler. When I do the make
install, I get 2 sets of binaries:
1) $prefix/bin - this contains all of the binaries with
'sparc-sun-solaris2.9' in front of them
On Thu, Jul 28, 2005 at 09:12:21AM -0700, Kean Johnston wrote:
> to:
> extern int stat (const char *__p, stat_t *__s);
> extern __inline__ int
> stat(const char *__p, stat_t *__s)
> {
> return _xstat(_STAT_VER, __p, __s);
> }
...
> From reading teh docs it seems like 'extern __inlin
I've long come to the conclulsion that "static inline" is the most
palatable form of the whole thingy -- its semantics does not depend on
optimization level. It is also the form that suits needs for people
who need to write C++ codes that use or interface with C codes.
Thanks for the advice Gaby
On Thu, Jul 28, 2005 at 07:26:22PM +0200, Fran?ois-Xavier Coudert wrote:
>
> PR 22619 and PR 22509 are two examples of recent 4.1 regressions that
> showed up in gfortran, due to middle-end or optimization bugs (only
> happen at -O3). Since these are regressions, they should be treated
> before a
Hi all,
PR 22619 and PR 22509 are two examples of recent 4.1 regressions that
showed up in gfortran, due to middle-end or optimization bugs (only
happen at -O3). Since these are regressions, they should be treated
before a long time passes, but since both source codes are Fortran, I
guess people d
Hi
I am inserting a call stmt in linear_transform_loops. Al though
the call statement gets inserted , the compilation breaks. Can some
one help me identify if I am missing some information in the call
node that I create (thanks Daniel for all the help until now)
here is the set of s
Kean Johnston <[EMAIL PROTECTED]> writes:
[...]
| However, I *think* I like the semantics of 'extern inline'
| better: use the inline version for the most part but if,
| for example, you take the address of the function, use the
| actual symbol stat(). But I see that most other fixincs
| use stat
On Fri, Jul 29, 2005 at 01:46:12AM +1000, Paul C. Leopardi wrote:
> Hi all,
> I've solved this. Thanks to Ian Lance Taylor, H. J. Lu and Mike Stump.
> See below.
> Best regards, Paul
>
> I checked the output of make check-c++ RUNTESTFLAGS="-v" and noticed the line:
> Found ~/.dejagnurc
>
> In ~/
Hi everyone,
I've run into a little SNAFU with my porting work. In my
fixincludes changes I changed all forms in the header files
of (using stat as an example):
static int
stat(const char *__p, stat_t *__s)
{
return _xstat(_STAT_VER, __p, __s);
}
to:
extern int stat (const char *__
Hi all,
I've solved this. Thanks to Ian Lance Taylor, H. J. Lu and Mike Stump.
See below.
Best regards, Paul
I checked the output of make check-c++ RUNTESTFLAGS="-v" and noticed the line:
Found ~/.dejagnurc
In ~/.dejagnurc I found:
set GXX_UNDER_TEST "g++"
Judging form the modification date of
Hi Ian, My replies are below, Best regards. Paul
On Thu, 28 Jul 2005 11:05 am, Ian Lance Taylor wrote:
> "Paul C. Leopardi" <[EMAIL PROTECTED]> writes:
> > [EMAIL PROTECTED]:~/src/gcc/gcc-4.0.1-obj> ../gcc-4.0.1/configure
> > --prefix=/usr/local/gcc/gcc-4.0.1 --enable-threads=posix
> > --disable-l
Thanks. I modified the related macros, like reg_class,
REG_CLASS_FROM_LETTER(CHAR) and so on. But I have a problem on
define_peephole2.
After I modified the related macros, I replaced the "r" in
"custom_inii" with "c".
(define_insn "custom_inii"
[(set (match_operand:SI 0 "register_operand" "=
60 matches
Mail list logo
