Am Thursday 03 September 2009 00:04:43 schrieb Paolo Bonzini:
>> *) The stack alignment code + msvc_prologue is used by Wine on osx though.
>> ...
> I don't think this would prevent the patch from getting the patch in.
Ok, I'll read the patch contribution guidelines again and hope for the best.
I
I don't know, I was just reworking Stefan's patch. He didn't include
function names (-p) in the patch so I don't know what function this is
part of.
It was ix86_handle_abi_attribute. I'm usually using git, and don't like cvs
and svn too much. It seems svn diff doesn't support a -p option here. M
On Wed, Sep 02, 2009 at 11:08:19PM -0600, Ryan Hill wrote:
> On Fri, 24 Jul 2009 09:51:07 -0600
> Tom Tromey wrote:
>
> > > "Basile" == Basile STARYNKEVITCH writes:
>
> > Basile> Shouldn't a python script for gdb be installed outside of a
> > directory
> > Basile> supposed to contain only
uname -prs
Darwin 8.11.0 powerpc
Updating SVN tree
At revision 151374.
config:
../gcc-4-5-regtest/configure --prefix=/Volumes/ScratchCS/gcc-4-5-
install --target=powerpc-apple-darwin8 --host=powerpc-apple-darwin8 --
build=powerpc-apple-darwin8 --enable-languages=c,objc,c++,obj-c+
+,fortran -
> > Both. By my reading the ABI you're trying to implement does not provide
> > the guarantees required to use iwmmxt instructions. There are ways around
> > this, but none of them are simple or pretty. The simplest answer is
> > "don't do that".
>
> Hi Paul,
>
> Thanks for the answer, but I'm not
As we've got quite some build problems on some targets and we clashed
with VTA, free-lang-data, expand and scheduler changes it's a good
time to slush the trunk for a short time.
Thus, starting from now the trunk is in regression and documentation
fixes only mode.
Please help sorting out issues
On Wed, Sep 2, 2009 at 16:06, Basile
STARYNKEVITCH wrote:
> Hello All,
>
> My feeling is that the Link Time Optimisation (LTO) effort should be soon
> (=is expected to be, or is already) merged inside GCC trunk (future 4.5).
>
> Several years ago, I asked if there is any possibility for an addition
Richard Guenther wrote:
As we've got quite some build problems on some targets and we clashed
with VTA, free-lang-data, expand and scheduler changes it's a good
time to slush the trunk for a short time.
Thus, starting from now the trunk is in regression and documentation
fixes only mode.
I hop
On Thu, Sep 3, 2009 at 09:09, Basile
STARYNKEVITCH wrote:
> I hope that does not mean that gcc has switched mysteriously from stage 1 to
> stage 3 (or even stage 2).
No. We freeze trunk when it crosses specific pain thresholds.
> I am extremly interested in having the gengtype plugin patch acce
Filed as PR 41245.
FX
Hello all,
I am doing a port for a 32bit target in GCC 4.4.0. Of the addressing
modes that are allowed by my target the one with (base register +
offset) is restrictive in QImode. The restriction is that if the base
register is not Stack Pointer then this kind of address cannot come in
a load inst
> Hi,
>
> Oh, I was wrong previously, gcc does respect __attribute__
> ((__regparm__ (3))) flag (I forget to add -Os so it still uses stack
> to store value). And the bug is still there ! Try this test program:
I confirm with gcc-4.4
This is a grave problem then. This check was added by Marco Gerar
Alex,
With your VTA merge, you added the -gtoggle switch. I've read the
documentation for it and while I can parse what it says, I have no
idea what this flag is useful for. I've seen it used during
bootstraps and the documentation claims something about
-fcompare-debug. But I cannot imagine th
Mohamed Shafi wrote:
> The restriction is that if the base
> register is not Stack Pointer then this kind of address cannot come in
> a load instruction but only in store instruction.
>
> To implement this i added constrains for all supported memory
> operations in QImode. So the pattern is as f
On 09/03/09 09:44, Dave Korn wrote:
Mohamed Shafi wrote:
The restriction is that if the base
register is not Stack Pointer then this kind of address cannot come in
a load instruction but only in store instruction.
To implement this i added constrains for all supported memory
operations i
#include
void foo (int a, int b, void (*hook) (int aa, int bb, int cc))
{
b += a;
hook (a, b, a + b);
}
void qq (int a)
{
auto void q1 (int aa, int bb, int cc);
void q1 (int aa, int bb, int cc)
{
printf ("%d %d %d\n", a, aa + bb, cc);
}
foo (a, a + 1, q1);
}
int main(
Diego,
> In fact, it'd be nice to hide some other flags, but that's another problem.
Absolutely, I think the user flags should be well separated from the
developer ones.
Cheers
Dominique
On Thu, Sep 3, 2009 at 5:54 PM, Paolo Bonzini wrote:
>
>>> #include
>>>
>>> void foo (int a, int b, void (*hook) (int aa, int bb, int cc))
>>> {
>>> b += a;
>>> hook (a, b, a + b);
>>> }
>>>
>>> void qq (int a)
>>> {
>>> auto void q1 (int aa, int bb, int cc);
>>> void q1 (int aa, int bb, int cc
Hello Jakub,
* Jakub Jelinek wrote on Thu, Sep 03, 2009 at 10:51:42AM CEST:
> On Wed, Sep 02, 2009 at 11:08:19PM -0600, Ryan Hill wrote:
> >
> > I was just wondering if there was any consensus among distros about where to
> > move these. We cannot keep the .py files in the location they're curre
On Sep 3, 2009, Diego Novillo wrote:
> With your VTA merge, you added the -gtoggle switch.
Not really:
gcc/ChangeLog:
2009-06-08 Alexandre Oliva
^^
* common.opt (fcompare-debug=, fcompare-debug-second): New.
(fdump-final-insns=, gtoggle): New.
* doc/invoke.te
> "Ryan" == Ryan Hill writes:
Ryan> I was just wondering if there was any consensus among distros
Ryan> about where to move these.
I suggest moving them either to the separate debug directory, or
underneath gdb's datadir. See (info "(gdb)Auto-loading") for details of
the procedure that gdb
Az alabbi linket kuldtek Neked:
http://useurl.us/6ab
Snapshot gcc-4.5-20090903 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-20090903/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.5 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/trunk
Can someone tell me how to debug this:
splitting
/home/rth/work/gcc/bld-sjlj/gcc/testsuite/ada/acats0/tests/c3/c35502i.ada into:
c35502i.adb
BUILD c35502i.adb
gnatmake --GCC="/home/rth/work/gcc/bld-sjlj/gcc/xgcc -B/home/rth/work/gcc/bld-sjlj/gcc/"
-gnatws -O2 -I/home/rth/work/gcc/bld-sjlj/g
On Aug 27, 2009, Jason Merrill wrote:
> On 08/15/2009 10:12 AM, Jerry Quinn wrote:
>> Building with --enable-build-with-cxx fails to bootstrap as follows:
>>
>> x86_64-unknown-linux-gnu/32/libstdc++-v3/libsupc++/eh_alloc.o differs
>> ...
> Do you know why r149964 makes a difference?
No idea if
Richard Henderson wrote:
> Can someone tell me how to debug this:
>
>> splitting
>> /home/rth/work/gcc/bld-sjlj/gcc/testsuite/ada/acats0/tests/c3/c35502i.ada
>> into:
>>c35502i.adb
>> BUILD c35502i.adb
>> gnatmake --GCC="/home/rth/work/gcc/bld-sjlj/gcc/xgcc
>> -B/home/rth/work/gcc/bld-sjlj/gcc
If you pass -v to gnatmake, it will output the gcc invocations.
This should be sufficient to find the problem.
Basically, just go to the directory containing c35502i.adb, and
execute the gnatmake command as listed below, with -v added in.
If you only have the 35502i.ada file available, use "gnatc
Is this a well know problem:
/usr/local/src/trunk/objdir/./gcc/xgcc
-B/usr/local/src/trunk/objdir/./gcc/
-B/usr/local/gnu/i686-pc-cygwin/bin/
-B/usr/local/gnu/i686-pc-cygwin/lib/ -isystem /
usr/local/gnu/i686-pc-cygwin/include -isystem
/usr/local/gnu/i686-pc-cygwin/sys-include-c -g -O2 -W -W
>> ./c35502i.o: In function `_ada_c35502i':
>> c35502i.adb:(.text+0x156): undefined reference to `.L47'
>> collect2: ld returned 1 exit status
>> gnatlink: error when calling /home/rth/work/gcc/bld-sjlj/gcc/xgcc
>> gnatmake: *** link failed.
>> FAIL: c35502i
>
> I haven't been able to figure out
29 matches
Mail list logo
