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" "=
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
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 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 *__
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 ~/
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
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
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
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
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 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
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, 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
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
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 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
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 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
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
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
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
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
[ 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
>
> 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
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
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
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
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
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 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
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
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
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
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
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 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
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
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
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
[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
> "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
> "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
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
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
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, 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
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 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 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
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.
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
When GCC will include a front end for D?
www.digitalmars.com/d
[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
Christian Hartung wrote:
When GCC will include a front end for D?
www.digitalmars.com/d
when you or someone else writes one :-)
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
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
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
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
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
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
60 matches
Mail list logo
