Re: MSVC hook function prologue

[Stefan Dösinger]

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. 
Ideally I'd like gcc to generate efficient code for this, since we use this 
on OSX, but I can live with the current situation for now - very few of the 
functions we have to make hookable are performance critical.

> > *) What other changes are needed to get a functionality like this into
> > mainline?
>
> I think right now I'd make only two cosmetic adjustments:
I'll look into them - the 2nd one seems to make sense to me, for the first one 
I have to look.

> > as otherwise for 64-bit target warning would be shown always?

> 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. Maybe 
I'll just switch to git-svn.

Thanks for your help!

Re: MSVC hook function prologue

[Paolo Bonzini]

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. Maybe
I'll just switch to git-svn.


You can use "svn diff -x -p" or put a script like this in ~/bin/svn-diff

#! /bin/sh

p=p
format=u

for i
do
  case "$i" in -*[uUcCy]*) format= ;; esac
  case "$i" in -*W*) format=y ;; esac
  case "$i" in -*p*) p= ;; esac
  case "$i" in --|[!-]*) break ;; esac
done

test -n "$format$p" && set -- -$format$p "$@"
exec diff "$@"


... and place this in ~/.subversion/config:

[helpers]
diff-cmd = /path/to/bin/svn-diff

You're welcome!

Paolo

Re: libstdc++.so.6.0.*-gdb.py might be installed at the wrong place

[Jakub Jelinek]

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  ELF libraries?  Wouldn't a gdb specific
> > Basile> subdirectory be a more appropriate place?
> > 
> > Perhaps.  It is a problem of several parts.  Basically, gdb and all
> > possible users of this interface must agree on where to install such
> > "hook" files.
> > 
> > I chose to name the .py files after the libraries and install them
> > alongside the libraries because it is simple and will not result in any
> > naming clash.
> > 
> > There is also the option of installing these files underneath the
> > separate debug directory.  However, gcc has no knowledge of that.  I
> > assume that distros will solve this themselves by moving the file after
> > make install.
> 
> 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 currently
> installed; ldconfig is far too noisy about it:
> 
>   /sbin/ldconfig: 
> /usr/lib/gcc/x86_64-unknown-linux-gnu/4.5.0-pre/libstdc++.so.6.0.14-gdb.py
>  is not an ELF file - it has the wrong magic bytes at the start.
>   /sbin/ldconfig: 
> /usr/lib/gcc/x86_64-unknown-linux-gnu/4.5.0-pre/32/libstdc++.so.6.0.14-gdb.py
>  is not an ELF file - it has the wrong magic bytes at the start.

ldconfig by default certainly doesn't search gcc private directories, if you
let ldconfig search there by adding it to its configuration, it would be
admin error.

Jakub

bootstrap fail on powerpc-apple-darwin8

[IainS]

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 --enable-version-specific-runtime-libs --enable-threads -- 
enable-checking=yes --program-suffix=-4.5.0 --with-dwarf2 --with- 
libiconv-prefix=/usr --with-system-zlib --enable-stage1-languages=c,c++


output:

[address=03d770b0 pc=002cabf8]
../../gcc-4-5-regtest/gcc/config/rs6000/altivec.md: In function  
'recog_48':
../../gcc-4-5-regtest/gcc/config/rs6000/altivec.md:1864:1: internal  
compiler error: Segmentation Fault

Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[3]: *** [insn-recog.o] Error 1
make[2]: *** [all-stage2-gcc] Error 2
make[1]: *** [stage2-bubble] Error 2
make: *** [bootstrap] Error 2

what other output would hep diagnose this?
(151057 was my last successful bootstrap)
Iain

Re: ARM wmmx instructions from gcc ?

[Paul Brook]

> > 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 sure what you've told me and why.
> Could you expand a little ?
>
> Don't do what ? Use WMMX instructions in GCC ?
> or
> Don't try to use the current implementation with WMMX ?

iwmmxt instructions require doubleword data alignment . Your target 
[apparently] can't provide that. You loose.

Paul

Regression fixes only

[Richard Guenther]

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 your targets.

Thanks,
Richard.

Re: LTO and adding extra information from extra passes

[Diego Novillo]

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 additional
> pass to profit of LTO infrastructure to add some extra data into LTO stuff
> (which is probably DWARF related inside ELF object files, but I am not sure)
> and to retrieve it. I remember that the answer was of course not.

Note that the gimple streamer does not use dwarf encoding.  It uses
its own bytecode format.  There is no dwarf in the ELF files, unless
you use -g.

> Now we have a working plugin infrastructure, and I believe it would be very
> sensible for some plugin to register passes which add persistent information
> (as does LTO with its Gimple related representation) into object files and
> to retrieve it.

Yes.  That's been my plan all along.  Once LTO is merged in trunk, we
should add some plugin events to allow interaction with the streamer
as it writes and reads the callgraph.

> Even the mere ability to add inside the LTO data a chunk of bytes identified
> by the name of the plugin would be great. Of course, some more features
> could be welcome (e.g. the ability to add data specific to each compiled
> function or cgraph_node or whatever, or even to each gimple...).

Passes can add their own data to the bytecode.  A couple of IPA passes
are already doing that in the branch (notably, the inliner).

> A dream case example would be a plugin for whole program static analysis.

Note that gimple may not be an appropriate IL to do some kinds of
static analysis.  In gimple we have lost many front end attributes
that a static analyzer may want to use.  However, combined with -g,
this could be partially reconstructed.

Regardless, I agree that there are some analyses that are still
possible and useful that can be done right after the compiler has
built the complete callgraph.


Diego.

Re: Regression fixes only

[Basile STARYNKEVITCH]

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 hope that does not mean that gcc has switched mysteriously from stage 
1 to stage 3 (or even stage 2).


I am extremly interested in having the gengtype plugin patch accepted - 
that is the gengtype.[ch] part of

http://gcc.gnu.org/ml/gcc-patches/2009-09/msg00047.html

I would be very sad if I have to wait six months for it to go into the 
trunk (and as several people did notice, it is necessary for any plugins 
 needing GGC).


So Richard, can we understand that GCC is in regression and 
documentation fixes only mode for only a few days? Or did you decide a 
stage 1 end? [I hope you did not].


Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***

Re: Regression fixes only

[Diego Novillo]

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 accepted - that
> is the gengtype.[ch] part of
> http://gcc.gnu.org/ml/gcc-patches/2009-09/msg00047.html

I have it in my review queue.  When approved, you'll be able to commit
it whether or not we crossed to stage3.


Diego.

VTA merge broke i386-apple-darwin bootstrap (a primary platform)

[FX]

Filed as PR 41245.

FX

Reloading is going wrong?

[Mohamed Shafi]

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 instruction but only in store instruction.

 To implement this i added constrains for all supported memory
operations in QImode. So the pattern is as follows

(define_insn "movqi"
  [(set (match_operand:QI 0 "nonimmediate_operand"
 "=b,b,d,t,d, b,Ss0, Ss1, a,Se1, Sb2,  b,Sd3,  d,Se0")
(match_operand:QI 1 "general_operand"
  "I,  L,d,d,t, Ss0,b,  b,Se1,a,  b, Sd3,b,  Se0,d"))]

where
d is data registers
a is address registers
b is data and address registers
Sb2 is Rn + offset addressing mode
Sd3 is SP + offset addressing mode

Se0 - (Rn), (Rn)+, (Rn)-, (Rn + Ri) and Post modify register addressing mode
Se1 - Se0 excluding Post modify register addressing mode

I believe that there are enough combinations available for the reload
to try for alternate addressing mode if it encounters the restrictive
addressing mode. But I am still getting the following error

main1.c:11: error: insn does not satisfy its constraints:
(insn 30 29 7 2 main1.c:9 (set (reg:QI 2 d2 [orig:61 .a+1 ] [61])
(mem/s/j:QI (plus:SI (reg:SI 16 r0)
(const_int 1 [0x1])) [0 .a+1 S1 A8])) 41
{movqi} (nil))
main1.c:11: internal compiler error: in reload_cse_simplify_operands,
at postreload.c:396


So what am i doing wrong?
Cant this scenario be solved by the reload pass?
How can generate instructions with the QImode restriction?

Regards,
Shafi

Re: [RFC] Eliminate NESTED_ATTR_FUNC

[Vladimir 'phcoder' Serbinenko]

> 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 Gerards
(maintainer) in 2003. He added a workaround but I don't believe such
behaviour to be correct. We're both GNU projects. IMO the correct
action would have been to report the bug to gcc-devel and refuse to
compile unless bug is fixed. This way users would update to newer gcc
patchlevel (e.g. 4.2.(X+1) instead of 4.2.X) instead of compiling with
buggy compiler. One GNU project shouldn't have expensive workaround
(we had bugs because of NESTED_FUNC_ATTR misuse)
Now we're in feature freeze but I hope in the future we'll be able to
change to correct behaviour when freeze is over.
>
> #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()
> {
>  qq (10);
> }
>
> Compile with:
> gcc -m32 -mregparm=3 -Os test.c
>
> ./a.out
> 10 31 -6674368
>
> gcc is 4.3.4 from debian.
> ---
> Bean
>
> gitgrub home: http://github.com/grub/grub/
> my fork page: http://github.com/bean123/grub/
>
>
> ___
> Grub-devel mailing list
> grub-de...@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>



-- 
Regards
Vladimir 'phcoder' Serbinenko

Personal git repository: http://repo.or.cz/w/grub2/phcoder.git

What is -gtoggle useful for?

[Diego Novillo]

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 this being useful in general.

If it's really useful, could you add a rationale in the documentation?
 If it's only useful for the very limited application of
-fcompare-debug, I'd say we should toss both out and make them
internal and/or --param.  Anything that hides them from users.

In fact, it'd be nice to hide some other flags, but that's another problem.


Diego.

Re: Reloading is going wrong?

[Dave Korn]

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 follows
> 
> (define_insn "movqi"
>   [(set (match_operand:QI 0 "nonimmediate_operand"
>  "=b,b,d,t,d, b,Ss0, Ss1, a,Se1,  Sb2,  b,Sd3,  d,Se0")
> (match_operand:QI 1 "general_operand"
>   "I,L,d,d,t, Ss0,b,  b,  Se1,a,  b,Sd3,b,  Se0,d"))]
> 
> where
> d is data registers
> a is address registers
> b is data and address registers
> Sb2 is Rn + offset addressing mode
> Sd3 is SP + offset addressing mode
> 
> Se0 - (Rn), (Rn)+, (Rn)-, (Rn + Ri) and Post modify register addressing mode
> Se1 - Se0 excluding Post modify register addressing mode
> 
> I believe that there are enough combinations available for the reload
> to try for alternate addressing mode if it encounters the restrictive
> addressing mode. But I am still getting the following error
> 
> main1.c:11: error: insn does not satisfy its constraints:
> (insn 30 29 7 2 main1.c:9 (set (reg:QI 2 d2 [orig:61 .a+1 ] [61])
> (mem/s/j:QI (plus:SI (reg:SI 16 r0)
> (const_int 1 [0x1])) [0 .a+1 S1 A8])) 41
> {movqi} (nil))
> main1.c:11: internal compiler error: in reload_cse_simplify_operands,
> at postreload.c:396

  This approach can't work.  There has to be a combination of constraints to
accept any and every combination of operands permitted by the predicates
"nonimmediate_operand" and "general_operand".  Since neither of these exclude
base registers beside the SP, they make it through to recog which punts when
it can't find a which_alternative set to use.  In this case general_operand
has allowed an operand of type (mem (plus (reg) (const)), equivalent to your
Sb2 constraint, but there is no constraint for operand 1 that permits that.

  You can't use constraints to filter the initial selection performed by
predicates.  What I think you need to do is to have a variant version of
general_operand that refuses Sb2 types.

cheers,
  DaveK

Re: Reloading is going wrong?

[Jeff Law]

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 in QImode. So the pattern is as follows

(define_insn "movqi"
   [(set (match_operand:QI 0 "nonimmediate_operand"
  "=b,b,d,t,d, b,Ss0, Ss1, a,Se1,  Sb2,  b,Sd3,  d,Se0")
 (match_operand:QI 1 "general_operand"
   "I,L,d,d,t, Ss0,b,  b,  Se1,a,  b,Sd3,b,  Se0,d"))]

where
d is data registers
a is address registers
b is data and address registers
Sb2 is Rn + offset addressing mode
Sd3 is SP + offset addressing mode

Se0 - (Rn), (Rn)+, (Rn)-, (Rn + Ri) and Post modify register addressing mode
Se1 - Se0 excluding Post modify register addressing mode

I believe that there are enough combinations available for the reload
to try for alternate addressing mode if it encounters the restrictive
addressing mode. But I am still getting the following error

main1.c:11: error: insn does not satisfy its constraints:
(insn 30 29 7 2 main1.c:9 (set (reg:QI 2 d2 [orig:61.a+1 ] [61])
 (mem/s/j:QI (plus:SI (reg:SI 16 r0)
 (const_int 1 [0x1])) [0.a+1 S1 A8])) 41
{movqi} (nil))
main1.c:11: internal compiler error: in reload_cse_simplify_operands,
at postreload.c:396
 

   This approach can't work.  There has to be a combination of constraints to
accept any and every combination of operands permitted by the predicates
"nonimmediate_operand" and "general_operand".  Since neither of these exclude
base registers beside the SP, they make it through to recog which punts when
it can't find a which_alternative set to use.  In this case general_operand
has allowed an operand of type (mem (plus (reg) (const)), equivalent to your
Sb2 constraint, but there is no constraint for operand 1 that permits that.

   You can't use constraints to filter the initial selection performed by
predicates.  What I think you need to do is to have a variant version of
general_operand that refuses Sb2 types.
   
Also note that reload does not distinguish between a load and a store 
when verifying the legitimacy of an address, meaning that reload doesn't 
handle cases where a particular addressing mode is available for loads, 
but not stores (or vice-versa).


This can be worked around with careful selection of operand predicates, 
secondary reloads, sometimes additional patterns.It's been a long 
time since I worked on a port with this kind of characteristic, so I 
can't offhand give a recipe to make it work.


Obviously looking at how other ports with these characteristics handle 
this case would be useful.  The PA for example has integer indexed 
loads, but no integer indexed stores.  There's likely other ports with 
similar characteristics as well.



Jeff

Re: [RFC] Eliminate NESTED_ATTR_FUNC

[Paolo Bonzini]

#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()
{
  qq (10);
}

Compile with:
gcc -m32 -mregparm=3 -Os test.c

./a.out
10 31 -6674368


Ok, this was the only important part of the message to us GCC hackers. :-)

Can you please report a bug in bugzilla, saying which versions work and 
which fail?  Also can you write in the report what was your analysis 
with respect to regparm?


Thanks!

Paolo

Re: What is -gtoggle useful for?

[Dominique Dhumieres]

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

Re: [RFC] Eliminate NESTED_ATTR_FUNC

[Vladimir 'phcoder' Serbinenko]

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)
>>>    {
>>>      printf ("%d %d %d\n", a, aa + bb, cc);
>>>    }
>>>
>>>  foo (a, a + 1, q1);
>>> }
>>>
>>> int main()
>>> {
>>>  qq (10);
>>> }
>>>
>>> Compile with:
>>> gcc -m32 -mregparm=3 -Os test.c
>>>
>>> ./a.out
>>> 10 31 -6674368
>
> Ok, this was the only important part of the message to us GCC hackers. :-)
>
> Can you please report a bug in bugzilla, saying which versions work and
> which fail?  Also can you write in the report what was your analysis with
> respect to regparm?
Done by Robert Millan here: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41246
>
> Thanks!
>
> Paolo
>



-- 
Regards
Vladimir 'phcoder' Serbinenko

Personal git repository: http://repo.or.cz/w/grub2/phcoder.git

Re: libstdc++.so.6.0.*-gdb.py might be installed at the wrong place

[Ralf Wildenhues]

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 currently
> > installed; ldconfig is far too noisy about it:
> > 
> >   /sbin/ldconfig: 
> > /usr/lib/gcc/x86_64-unknown-linux-gnu/4.5.0-pre/libstdc++.so.6.0.14-gdb.py
> >  is not an ELF file - it has the wrong magic bytes at the start.

> ldconfig by default certainly doesn't search gcc private directories, if you
> let ldconfig search there by adding it to its configuration, it would be
> admin error.

'libtool --mode=install' will invoke 'ldconfig -n' on the directory
it installs libraries in (e.g., in order to fix symlinks), which will
cause this complaint as well.

Cheers,
Ralf

Re: What is -gtoggle useful for?

[Alexandre Oliva]

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.texi: Document them.

While looking into this, I realized I messed up the ChangeLog for the
latest config/bootstrap-debug-*.mk changes (wrong ChangeLog dir), fixed
with the patch below.

> 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.

It's mostly useful as one of the options for -fcompare-debug testing.
Say, you can set GCC_COMPARE_DEBUG=-gtoggle in your environment, and
from then on, anything you compile with a -fcompare-debug-capable
compiler will be compiled twice, with and without -g, and compared to
check for codegen differences.  Having -gtoggle means you can set it
once, rather than having to figure out whether a compilation would be
performed with -g, and should thus be recompiled with -g0, or
vice-versa.  In theory, a wrapper could implement this, but it would
have to duplicate all the complex -g* handling that GCC performs,
emulating all the overriding, overlapping and even the extraneous -g*
flags that GNAT uses for purposes unrelated with -g.

Sure enough, this is not the only use for -fcompare-debug, otherwise we
could do away with the -gtoggle option and just use
-fcompare-debug-second for this purpose.  But there is
-fvar-tracking-assignments-toggle, and one could use various other
debug-info-related options (debug info level, kind, etc) or even other
debug info-unrelated options (say warnings), to check for codegen
stability, or even nothing whatsoever (to check for stability against
randomized address spaces).

> I've seen it used during bootstraps and the documentation claims
> something about -fcompare-debug.  But I cannot imagine this being
> useful in general.

Imagine you're trying to debug an optimized program.  You had no debug
info at first, and it failed.  So you recompile, and then you can't
duplicate the problem any more.  This shouldn't happen, because GDB is
supposed to generate the same code with and without -g.  However, we've
neglected this property for too long.  Now, -fcompare-debug=-gtoggle
provides you with a way to pinpoint exactly where the bug in GCC is that
causes codegen differences, that presumably hide the bug you're looking
into.  Once you know that, besides filing a GCC bug report, you might
have better luck tracking your own bug down.

> If it's really useful, could you add a rationale in the documentation?

Would the above serve as motivation for -fcompare-debug (and thus for
-gtoggle)?


Index: config/ChangeLog
===
--- config/ChangeLog	(revision 151387)
+++ config/ChangeLog	(working copy)
@@ -1,3 +1,10 @@
+2009-09-03  Alexandre Oliva  
+
+	* bootstrap-debug-big.mk (STAGE2_CFLAGS): Drop -gtoggle.
+	* bootstrap-debug-lean.mk: Update comments.
+	(STAGE2_CFLAGS): Likewise.
+	(do-compare): Don't override.
+
 2009-09-01  Alexandre Oliva  
 
 	* bootstrap-debug.mk: Add comments.
Index: contrib/ChangeLog
===
--- contrib/ChangeLog	(revision 151387)
+++ contrib/ChangeLog	(working copy)
@@ -1,10 +1,3 @@
-2009-09-03  Alexandre Oliva  
-
-	* bootstrap-debug-big.mk (STAGE2_CFLAGS): Drop -gtoggle.
-	* bootstrap-debug-lean.mk: Update comments.
-	(STAGE2_CFLAGS): Likewise.
-	(do-compare): Don't override.
-
 2009-09-01  Alexandre Oliva  
 
 	* compare-debug: Look for .gkd files and compare them.

-- 
Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/   FSF Latin America board member
Free Software Evangelist  Red Hat Brazil Compiler Engineer

Re: libstdc++.so.6.0.*-gdb.py might be installed at the wrong place

[Tom Tromey]

> "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 uses to find these files.

Tom

Udvozollek !

[hajdu . aniko . iwhrd]

Az alabbi linket kuldtek Neked:

http://useurl.us/6ab

gcc-4.5-20090903 is now available

[gccadmin]

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 revision 151396

You'll find:

gcc-4.5-20090903.tar.bz2  Complete GCC (includes all of below)

gcc-core-4.5-20090903.tar.bz2 C front end and core compiler

gcc-ada-4.5-20090903.tar.bz2  Ada front end and runtime

gcc-fortran-4.5-20090903.tar.bz2  Fortran front end and runtime

gcc-g++-4.5-20090903.tar.bz2  C++ front end and runtime

gcc-java-4.5-20090903.tar.bz2 Java front end and runtime

gcc-objc-4.5-20090903.tar.bz2 Objective-C front end and runtime

gcc-testsuite-4.5-20090903.tar.bz2The GCC testsuite

Diffs from 4.5-20090827 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.5
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

[ada] help debugging acats failure

[Richard Henderson]

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/gcc/testsuite/ada/acats0/support c35502i.adb -largs 
--GCC="/home/rth/work/gcc/bld-sjlj/gcc/xgcc -B/home/rth/work/gcc/bld-sjlj/gcc/"
/home/rth/work/gcc/bld-sjlj/gcc/xgcc -c -B/home/rth/work/gcc/bld-sjlj/gcc/ 
-gnatws -O2 -I/home/rth/work/gcc/bld-sjlj/gcc/testsuite/ada/acats0/support 
c35502i.adb
gnatbind -I/home/rth/work/gcc/bld-sjlj/gcc/testsuite/ada/acats0/support -x 
c35502i.ali
gnatlink c35502i.ali --GCC=/home/rth/work/gcc/bld-sjlj/gcc/xgcc 
-B/home/rth/work/gcc/bld-sjlj/gcc/
./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 what command to issue from the command 
line to reproduce this.  Cut and paste from the dejagnu log doesn't 
work, which is more than annoying...



r~

Re: enable-build-with-cxx bootstrap compare broken by r149964

[Alexandre Oliva]

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 it's related, but I started getting -fcompare-debug failures
a while ago, and eventually I tracked it down to -frandom-seed -derived
mangled symbol names.

-- 
Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/   FSF Latin America board member
Free Software Evangelist  Red Hat Brazil Compiler Engineer

Re: [ada] help debugging acats failure

[Dave Korn]

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/" -gnatws -O2
>> -I/home/rth/work/gcc/bld-sjlj/gcc/testsuite/ada/acats0/support
>> c35502i.adb -largs --GCC="/home/rth/work/gcc/bld-sjlj/gcc/xgcc
>> -B/home/rth/work/gcc/bld-sjlj/gcc/"
>> /home/rth/work/gcc/bld-sjlj/gcc/xgcc -c
>> -B/home/rth/work/gcc/bld-sjlj/gcc/ -gnatws -O2
>> -I/home/rth/work/gcc/bld-sjlj/gcc/testsuite/ada/acats0/support
>> c35502i.adb
>> gnatbind
>> -I/home/rth/work/gcc/bld-sjlj/gcc/testsuite/ada/acats0/support -x
>> c35502i.ali
>> gnatlink c35502i.ali --GCC=/home/rth/work/gcc/bld-sjlj/gcc/xgcc
>> -B/home/rth/work/gcc/bld-sjlj/gcc/
>> ./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 what command to issue from the command
> line to reproduce this.  Cut and paste from the dejagnu log doesn't
> work, which is more than annoying...

  If you hack the last line ("exec $testdir/run_all.sh ") off of a copy of
gcc/testsuite/ada/acats/run_acats, you could probably source it into a shell
to get all the variables set right.  You might also want to hack run_all.sh
(or a copy thereof) to add some "--save-temps" flags in strategic locations.

cheers,
  DaveK

Re: [ada] help debugging acats failure

[Geert Bosch]

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 "gnatchop  
35502i.ada"

to get the various units split out in their own files.
You might need to specifically include the "support" directory,
which appears to be /home/rth/work/gcc/bld-sjlj/gcc/testsuite/ada/acats0
from your report.

Hope this helps.

  -Geert

On Sep 3, 2009, at 19:00, 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/" -gnatws -O2 -I/home/rth/work/gcc/bld-sjlj/ 
gcc/testsuite/ada/acats0/support c35502i.adb -largs --GCC="/home/ 
rth/work/gcc/bld-sjlj/gcc/xgcc -B/home/rth/work/gcc/bld-sjlj/gcc/"
/home/rth/work/gcc/bld-sjlj/gcc/xgcc -c -B/home/rth/work/gcc/bld- 
sjlj/gcc/ -gnatws -O2 -I/home/rth/work/gcc/bld-sjlj/gcc/testsuite/ 
ada/acats0/support c35502i.adb
gnatbind -I/home/rth/work/gcc/bld-sjlj/gcc/testsuite/ada/acats0/ 
support -x c35502i.ali
gnatlink c35502i.ali --GCC=/home/rth/work/gcc/bld-sjlj/gcc/xgcc -B/ 
home/rth/work/gcc/bld-sjlj/gcc/

./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 what command to issue from the  
command line to reproduce this.  Cut and paste from the dejagnu log  
doesn't work, which is more than annoying...



r~

verify_ssa failed on cygwin and in ada

[Christian Joensson]

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 -Wall
-gnatpg   a-direct.adb -o a-direct.o
a-direct.adb: In function 'Ada.Directories.Start_Search':
a-direct.adb:1178:4: error: expected an SSA_NAME object
a-direct.adb:1178:4: error: in statement
# DEBUG ada__directories__start_search__TTS840bSP1___L => L839b
+===GNAT BUG DETECTED==+
| 4.5.0 20090904 (experimental) [trunk revision 151408]
(i686-pc-cygwin) GCC error:|
| verify_ssa failed|
| Error detected around a-direct.adb:1178:4|
| Please submit a bug report; see http://gcc.gnu.org/bugs.html.|
| Use a subject line meaningful to you and us to track the bug.|
| Include the entire contents of this bug box in the report.   |
| Include the exact gcc or gnatmake command that you entered.  |
| Also include sources listed below in gnatchop format |
| (concatenated together with no headers between files).   |
+==+

Please include these source files with error report
Note that list may not be accurate in some cases,
so please double check that the problem can still
be reproduced with the set of files listed.
Consider also -gnatd.n switch (see debug.adb).


I'm on this system:

Windows XP Pro/SP3 cygwin Intel Core2 Duo t9...@2.80ghz system with packages:

binutils 2.19.51-1  2.19.51.20090704
bison2.3-1  2.3
cloog-ppl0.15.3-1
cygwin   1.7.0-60
dejagnu  20021217-2 1.4.2.x
expect   20030128-1 5.26
gcc-ada  3.4.4-999
gcc-core 3.4.4-999
gcc-g++  3.4.4-999
gmp  4.3.1-3
libcloog-devel   0.15.3-1
libgmp-devel 4.3.1-3
libmpfr-devel2.4.1-4
libppl   0.10.2-1
make 3.81-2
mpfr 2.4.1-4
ppl  0.10.2-1
ppl-devel0.10.2-1
tcltk20080420-1 8.4
w32api   3.13-1

-- 
Cheers,

/ChJ

Re: [ada] help debugging acats failure

[Arnaud Charlet]

>> ./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 what command to issue from the command 
> line to reproduce this.  Cut and paste from the dejagnu log doesn't work, 
> which is more than annoying...

After a make install, you can use something like

cd /home/rth/work/gcc/bld-sjlj/gcc/testsuite/tests/c3
gnatmake c35502i.adb 
-I/home/rth/work/gcc/bld-sjlj/gcc/testsuite/ada/acats0/support

The command line used by the test suite is very complex and requires
env vars just because it needs to use the uninstalled compiler.

Once your compiler is installed, using it is a simple matter of doing
gnatmake with appropriate -I switches if needed.

Arno