Hi Ulrich,
In http://gcc.gnu.org/ml/gcc-patches/2004-07/msg01557.html, you
changed the return value of find_reloads_address to be tristate, in the
process modifying the meaning of a win from LEGITIMIZE_RELOAD_ADDRESS.
Prior to your change, a win meant that LEGITIMIZE_RELOAD_ADDRESS had
guaranteed
I've been quietly watching the conversation, largely as an interested
user as opposed to a GCC developer. One of my concerns lies with:
GENERIC -> GIMPLE -> LLVM -> GIMPLE -> RTL
That design adds two phases (GIMPLE -> LLVM, LLVM -> GIMPLE) here --
perhaps simple one, perhaps not. The l
Kaveh R. Ghazi wrote:
> On Sat, 2005-11-19 at 10:14 -0500, Kaveh R. Ghazi wrote:
> > Hi Dan,
> >
> > (BTW, sorry for the reposted messages.)
> >
> > While I was waiting for some svn commands to finish (cleanup,
> > update) on my solaris2.7 box, which has a slow filesystem, I
> > happen
Snapshot gcc-4.0-20051124 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.0-20051124/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.0 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
In http://gcc.gnu.org/ml/gcc/2005-11/msg01163.html, Ian Lance Taylor wrote:
Either way, register elimination can cause addresses which were valid
to become invalid, typically because valid offsets from the frame
pointer become invalid offsets from the stack pointer. So that needs
to be cleaned
> I am currently bootstraping the trunk with the patch applied.
bootstraped and tested...
> Thanks,
> Rafael
"Giovanni Bajo" <[EMAIL PROTECTED]> writes:
| Gabriel Dos Reis <[EMAIL PROTECTED]> wrote:
|
| >> Fixing a PR introducing a regression is not a proper fix for any bug,
| >> *especially* for a bug which is not a regression itself.
| >
| > Thanks for the lecture.
| >
| > Not just because this is not
Gabriel Dos Reis <[EMAIL PROTECTED]> wrote:
>> Fixing a PR introducing a regression is not a proper fix for any bug,
>> *especially* for a bug which is not a regression itself.
>
> Thanks for the lecture.
>
> Not just because this is not a regression does not mean it does not
> need fixing.
I jus
"Giovanni Bajo" <[EMAIL PROTECTED]> writes:
| Gabriel Dos Reis <[EMAIL PROTECTED]> wrote:
|
| > Once I'm finished, I'll post the patch and I would probably ask you
| > help in the testing department and suggest better concrete
| > solution. That PR needs to be fixed.
|
|
| Fixing a PR introduci
Gabriel Dos Reis <[EMAIL PROTECTED]> wrote:
> Once I'm finished, I'll post the patch and I would probably ask you
> help in the testing department and suggest better concrete
> solution. That PR needs to be fixed.
Fixing a PR introducing a regression is not a proper fix for any bug,
*especially*
"Giovanni Bajo" <[EMAIL PROTECTED]> writes:
| Gabriel Dos Reis <[EMAIL PROTECTED]> wrote:
|
| > template struct X { };
| >
| >void fu(int a, X) { } // #1
|
| I gave a look to PR 17395 and you are probably right. This testcase requires
| us to build PARM_DECLs even for function decla
This patch makes --with-gmp and --with-mpfr similar to --with-as and
others, where you don't need to have the as program in your PATH if
explicitly specified.
I now understood what you are looking for.
A good solution would be to use the macros AC_LIB_LINKFLAGS and friends,
which were first
If we do this, then anyone else testing for asprintf needs the same
logic. If libiberty uses a more naive test, it would provide
substitutes for other modules that are also naive.
Rafael Ávila de Espíndola wrote:
I noticed that in the config.h generated for libiberty has HAVE_DECL_ASPRINTF
defined as 0. This hapens because _GNU_SOURCE is not used when running the
test programs.
Another long-staying bug in the libiberty configure system is that it
claims newlib missing
Hi,
I am stuck with PR libfortran/22097 because currently, the libgfortran
configury isn't clever enough to get cabsl (among others) right on
mips-irix6.5. config.h has
#define HAVE_CABSF 1
and
/* #undef HAVE_COMPLEX_H */
while the correct definition of cabsl is provided in complex.h. Can
someon
Gabriel Dos Reis <[EMAIL PROTECTED]> wrote:
> template struct X { };
>
>void fu(int a, X) { } // #1
I gave a look to PR 17395 and you are probably right. This testcase requires
us to build PARM_DECLs even for function declarations. That's really too
bad.
You should though measure me
On Thu, 24 Nov 2005, Uros Bizjak wrote:
> Attached (untested) diff should update the required version of texinfo.
It also need updating everywhere in install.texi that mentions a required
Texinfo version.
--
Joseph S. Myers http://www.srcf.ucam.org/~jsm28/gcc/
[EMAIL PROTECTE
On 11/24/05, Uros Bizjak <[EMAIL PROTECTED]> wrote:
> Hello!
>
> > Mark Mitchell's @file documentation change adds a @set directive to
> > gcc-vers.texi in the build directory, but that file only depends on
> > DEV-PHASE and BASE-VER, so it will never be correctly rebuilt using
> > the new make rul
I noticed that in the config.h generated for libiberty has HAVE_DECL_ASPRINTF
defined as 0. This hapens because _GNU_SOURCE is not used when running the
test programs.
Coping the test that enables _GNU_SOURCE from gcc/configure.ac to
libiberty/configure.ac results in HAVE_DECL_ASPRINTF being
Hello!
> Mark Mitchell's @file documentation change adds a @set directive to
> gcc-vers.texi in the build directory, but that file only depends on
> DEV-PHASE and BASE-VER, so it will never be correctly rebuilt using
> the new make rule. Just deleting it will remedy the problem.
Another problem
On Wed, 2005-11-23 at 21:13, Ludovic Brenta wrote:
> I've read the wiki page that explains how to mirror GCC's repository
> using SVK, and I would like to pick up just the parts I need so I can
> keep the size of the mirror below 4 Gb due to limited disk space.
>
> Specifically, I need just a few
Gabriel Dos Reis <[EMAIL PROTECTED]> writes:
[...]
| | > The obvious place is on the DECL_INITIAL of the PARM_DECLs, but I
| | > don't think they exist until the function is defined.
| |
| |
| | I heard once that there was some long-term project of storing function
| | declarations (without co
"Giovanni Bajo" <[EMAIL PROTECTED]> writes:
| Nathan Sidwell <[EMAIL PROTECTED]> wrote:
|
| >>> In the C++ front end, default arguments are recorded in
| >>> FUNCTION_TYPEs intead of being part of the FUNCTION_DECLs. What are
| >>> the reasons for that?
| >>
| >>
| >> There used to be an extens
Nathan Sidwell <[EMAIL PROTECTED]> wrote:
>>> In the C++ front end, default arguments are recorded in
>>> FUNCTION_TYPEs intead of being part of the FUNCTION_DECLs. What are
>>> the reasons for that?
>>
>>
>> There used to be an extension that allowed default arguments on
>> function pointer typ
Hi,
I'm having a lot of problems bootstrapping this compiler on said target.
What I did so far:
from the build dir (which I located in the extracted source dir)
../configure --srcdir=.. --enable-languages="c c++" --with-gnu-as
--with-as=/usr/sfw/bin/gas --without-gnu-ld --with-ld=/usr/ccs/bin/ld
Nathan Sidwell <[EMAIL PROTECTED]> writes:
| Gabriel Dos Reis wrote:
|
| > Assuming the extension was gone, do you see a reason we not move the
| > default arguments to FUNCTION_DECLs and have FUNCTION_TYPEs use
| > TREE_VEC instead of TREE_LIST to hold the parameter-type list?
|
| you could pro
===
> >
> >
> > Running target unix
> >
> > === gas Summary ===
> >
> > # of expected passes117
> > # of expected failures 1
> > === ld tests ===
> >
> >
> > Running target un
27 matches
Mail list logo
