Question about "#pragma pack(n)"

[feng qiu]

Hello!
-fpack-struct and #pragma pack(2) are contraditctory instructions.And it 
seems to be never the intent to allow both.Is there a patch for this? If I 
want to modify the gcc source code,what should I do?

Thanks in advanced,
Diterlish
_
与联机的朋友进行交流，请使用 MSN Messenger:  http://messenger.msn.com/cn  

Re: GCC 4.0 Status Report (2005-04-05)

[Mark Mitchell]

Jason Merrill wrote:
Glad to hear from you; I was afraid something worse than simply too much 
work had befallen you.

There's a patch in the comments for 19317 that just disables the offending
optimization.
Great; would you please apply that?  It seems like our best approach at 
present.

I'll try to deal with the other two tomorrow.
Thanks!
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304

Re: GCC 4.0 Status Report (2005-04-05)

[Mark Mitchell]

Andrew Pinski wrote:
On Apr 4, 2005, at 8:09 PM, Giovanni Bajo wrote:
Mark Mitchell <[EMAIL PROTECTED]> wrote:
I've attached a revised summary of the critical bugs open against
4.0. The good news is that there are fewer than last week.

Earlier today, Andrew Haley posted a small C++ snippet showing an ABI 
change
affecting gcj on PPC32:
http://gcc.gnu.org/ml/gcc/2005-04/msg00139.html

I hope he'll open a PR soon, but you probably want to consider this 
for 4.0.

Note it also effects all targets too by shown by my testcase.
Please put this into a PR.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304

Re: GCC 4.0 Status Report (2005-04-05)

[Jason Merrill]

On Mon, 04 Apr 2005 16:26:23 -0700, Mark Mitchell <[EMAIL PROTECTED]> wrote:

> There are three outstanding bugs (19317, 19312, 18604) assigned to Jason
> Merrill, but I didn't hear back from him last week.  Jason, I'm going to
> assume that you're unable to work on these.  As Nathan is on vacation, I
> suppose that means that these will fall to me to fix.  If anyone else would
> like to volunteer for 19317, which has proven particularly thorny, that
> would be helpful.

There's a patch in the comments for 19317 that just disables the offending
optimization.

I'll try to deal with the other two tomorrow.

Jason

Re: GCC 4.0 Status Report (2005-04-05)

[Mark Mitchell]

Andrew Pinski wrote:
Yes it might be a silent miscompiling but there is an easy work around, 
use a
temporary variable
In a large sourcebase, even figuring out what's been miscompiled is very 
hard.  It's much easier to deal with a compiler that ICEs than one that 
silently miscompiles code.

unlike pointer to member functions where there is no 
work around, well except for not using templates but that is just wrong.
There are lots of work-arounds.  For example:
  int A::*p = &A::a;
  blah(p);
I didn't say the pointer-to-member problem shouldn't be fixed; I just 
said it wasn't as critical.

--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304

Re: GCC 4.0 Status Report (2005-04-05)

[Andrew Pinski]

On Apr 4, 2005, at 11:48 PM, Mark Mitchell wrote:
Andrew Pinski wrote:
On Apr 4, 2005, at 7:26 PM, Mark Mitchell wrote:
20734 rejects valid pointer to member
  Not yet assigned.
How is this less Critical?
This would breaks lots of code, it is template related too as it is 
not
rejected when not in templates.
Clearly this is a judgement call.
However, I think it's less critical because pointers-to-members and, 
in particular, pointers-to-members in templates are relatively less 
common.  And, it's rejects-valid, so at least you know that you have a 
problem.  And there are workarounds.  In contrast, the top bug on the 
list is known to cause silent miscompilation of Qt, a very major 
package, and it's not easy to know where the problem is.
Yes it might be a silent miscompiling but there is an easy work around, 
use a
temporary variable, unlike pointer to member functions where there is 
no work around,
well except for not using templates but that is just wrong.

Thanks,
Andrew Pinski

Re: GCC 4.0 Status Report (2005-04-05)

[Stefan Strasser]

Mark Mitchell schrieb:
Andrew Pinski wrote:
On Apr 4, 2005, at 7:26 PM, Mark Mitchell wrote:
20734 rejects valid pointer to member
  Not yet assigned.

How is this less Critical?
This would breaks lots of code, it is template related too as it is not
rejected when not in templates.

Clearly this is a judgement call.
However, I think it's less critical because pointers-to-members and, in 
particular, pointers-to-members in templates are relatively less common. 
 And, it's rejects-valid, so at least you know that you have a problem. 
 And there are workarounds.  In contrast, the top bug on the list is 
known to cause silent miscompilation of Qt, a very major package, and 
it's not easy to know where the problem is.

what is the workaround to this?
(in the case the class the pointer target is a member of is a template 
parameter, unlike in the PR test case)

--
Stefan Strasser

Re: call for testers!

[Andreas Tobler]

Geoffrey Keating wrote:
I'd really appreciate it if people on unusual host systems (AIX, HPPA, 
cygwin, etc.) could see what the effect of the patch in 
 is on their 
bootstrap.  I've gotten no responses at all, and I presume this means 
that lots of people have tried the patch and discovered that it works 
fine, or they aren't too worried about discovering latent bugs and 
having their bootstrap fail...

The only work involved, assuming you already have a bootstrapped tree, 
would be to apply the patch and run 'make quickstrap' or even 'make 
gnucompare'; and possibly a single 'cmp' command.  This should take 
about 1 minute.
- solaris10 ok.
- hppa64-hp-hpux11.11, ok for gmake gnucompare. (with GNU as)
but:
andreast% cmp -l gcc/cc1 gcc/stage2/cc1
   894 122 114
   895  21 202
   896 251  75
   909 340 110
   910 324 277
   911 316 366
   912  20 115
117486  62  61
4822002 124 106
4822003 165 162
4822004 145 151
4822011  65  61
4822019  66  60
4822021  61  60
4822022  70  65
4822024  64  62
4822025  64  62
4822029 123 124
4822030 124  40
Andreas

Re: Using inline assembly with specific register indices

[nkavv]

Thanks Daniel!

actually my 2 messages were send back-to-back. I have just read both your
responses and I can see that i could use stringify approach to force the
assembly output of GCC to what I want.

Nikolaos Kavvadias

Re: Using inline assembly with specific register indices

[Daniel Jacobowitz]

On Tue, Apr 05, 2005 at 07:27:00AM +0300, [EMAIL PROTECTED] wrote:
> I was wondering...
> 
> why not support asm templates THAT ARE NOT string constants??? And I
> mean for static compilation cases only.
> 
> For example:
> 
> asm(instrx $%d, $%d\n",src1,src2 : "=r" (var1) : "r" (var2));
> 
> I assume printf-like formating.

Because it's unnecessary.  See my previous message; you can find many
examples on the Web of how to use CPP to stringify numbers.


-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: Using inline assembly with specific register indices

[Daniel Jacobowitz]

On Tue, Apr 05, 2005 at 07:24:44AM +0300, [EMAIL PROTECTED] wrote:
> Hi guys/ladies,
> 
> I'm currently designing an ISA add-on to the MIPS architecture. My
> intention is to use it (it is an algorithm accelerator actually) as a
> COP2 (coprocessor #2). The corresponding microarchitecture is stable
> (works at register-transfer level, not subject to change). Plus, I
> would be happy NOT TO CHANGE my ISA add-on.
> 
> My problem is that I would like to access specific indices in the data
> register file of COP2, i.e. registers c2r0 to c2r31. This should be
> done in inline assembly or else I'll have to put down probably 2k-3k
> C-lines in assembly :-)
> 
> Is it possible to write down something like this:
> 
> asm("cop2a %0, %1;", :: "r" (cp2rb(i)) : "r" (cp2rb(j)));

If GCC knows about the registers on the coprocessor, then you can use
local register variables for this:
  long c2r0 asm ("c2r0");

If it doesn't, then you should probably not be telling GCC about them.
Assuming i is constant:

  asm volatile ("cop2a c2r" STRINGIFY(i) ", c2r" STRINGIFY(j) );


-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: Using inline assembly with specific register indices

[nkavv]

I was wondering...

why not support asm templates THAT ARE NOT string constants??? And I
mean for static compilation cases only.

For example:

asm(instrx $%d, $%d\n",src1,src2 : "=r" (var1) : "r" (var2));

I assume printf-like formating.

Or else you may need either write a double-nested switch (and what
about 32x32 cases???):

switch (src1)
{
  ...
  case i:
...
switch (src2)
 case j:
asm( ... );
 break;
  break;
}

There is really not need for that. It could be constrained for static
compilation cases. So this could be replaced:

for (i=0; i

Using inline assembly with specific register indices

[nkavv]

Hi guys/ladies,

I'm currently designing an ISA add-on to the MIPS architecture. My
intention is to use it (it is an algorithm accelerator actually) as a
COP2 (coprocessor #2). The corresponding microarchitecture is stable
(works at register-transfer level, not subject to change). Plus, I
would be happy NOT TO CHANGE my ISA add-on.

My problem is that I would like to access specific indices in the data
register file of COP2, i.e. registers c2r0 to c2r31. This should be
done in inline assembly or else I'll have to put down probably 2k-3k
C-lines in assembly :-)

Is it possible to write down something like this:

asm("cop2a %0, %1;", :: "r" (cp2rb(i)) : "r" (cp2rb(j)));

where:
  i,j are indices to CP2RB, the data register file of coprocessor 2.
  %0,%1 denote the two source registers.

Is it possible to write intrinsics for accessing ***SPECIFIC***
register in the data register file of COP2??? That is for these
entries: cp2rb(i), cp2rb(j).

I'm considering writing wrappers for such cases like the following
snippet. This is a jump table in mixed C/MIPS assembly. It is an
example for the "mtc2" MIPS-I
instruction. It is not exactly the same case, since for the "cop2a"
instruction with the two source registers, IT WOULD NEED two nested
switches :-(
In addition to that, the jump tables cost 2-3 more instructions, which
would not happen if I re-write the target application in pure assembly.

- -- snippet starts --

// mtc2_wrapper
void mtc2_wrapper(unsigned int address_var, unsigned int data_var)
{
  // Copy data_var to CP2RB data register file at address address_var
  switch (address_var)
  {
...
case 5:
  asm("mtc2 %0, $5;" :: "r" (data_var) : "$5");
  break;
...
  }
}

- -- snippet ends --

This also applies when using intrinsic notation for the coprocessor data
registers (currently not for the control registers) e.g.:

register unsigned int c2r1 asm("$c2r1");
...
case 1:
  c2r1 = data_var;
...

Any help is extemely appreciated!

Best regards
Nikolaos Kavvadias (a.k.a. "kavi")
<[EMAIL PROTECTED]>

Re: GCC 4.0 Status Report (2005-04-05)

[Mark Mitchell]

Andrew Pinski wrote:
On Apr 4, 2005, at 7:26 PM, Mark Mitchell wrote:
20734 rejects valid pointer to member
  Not yet assigned.

How is this less Critical?
This would breaks lots of code, it is template related too as it is not
rejected when not in templates.
Clearly this is a judgement call.
However, I think it's less critical because pointers-to-members and, in 
particular, pointers-to-members in templates are relatively less common. 
 And, it's rejects-valid, so at least you know that you have a problem. 
 And there are workarounds.  In contrast, the top bug on the list is 
known to cause silent miscompilation of Qt, a very major package, and 
it's not easy to know where the problem is.

--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304

Re: Major bootstrap time regression on March 30

[Daniel Berlin]

On Mon, 2005-04-04 at 22:49 +0200, Steven Bosscher wrote:
> Hi,
> 
> We have a bootstrap time regression since March 30.  Bootstrap times
> on Diego Novillo's SPEC box went up from (an already high)  5500s to
> almost 8000s, see:
> http://people.redhat.com/dnovillo/spec2000/gcc/gcc-compiler-build-secs_elapsed.png
> 
> On IRC a patch possibly causing this regression was mentioned: the
> subvars correctness changes from Dan. He also posted a heuristics
> change patch a day earlier, which has not been reviewed yet, see:
> http://gcc.gnu.org/ml/gcc-patches/2005-03/msg02666.html.  If the
> subvars patch really is the problem, this heuristics patch should
> fix it.

> Could someone (hi, Diego!) review Dan's patch?  And if that patch
> does not fix this, we'll have to look for someone else to blame ;-)
After further review, i'm pretty sure i'm not the cause here.

I ran cc1 -O2 over *.i in cc1-i-files and cc1plus -O2 over *.ii with and
without the patch, and the times with the patch are only about 30
seconds lower out of 20 minutes.
Somehow, i don't remember cc1-i-files taking 20 minutes.

I also tried it with -fno-tree-salias, and it did not save time over
using the patch (IE still 20 minutes).

I suspect something more fundamental is going on here.

SPEC iteslf also didn't show a similar build time regression:

20050329:mean:CFP2000:base:build:secs_elapsed:216
20050330:mean:CFP2000:base:build:secs_elapsed:218
20050401:mean:CFP2000:base:build:secs_elapsed:216
20050329:mean:CFP2000:peak:build:secs_elapsed:221
20050330:mean:CFP2000:peak:build:secs_elapsed:226
20050401:mean:CFP2000:peak:build:secs_elapsed:221
20050329:mean:CINT2000:base:build:secs_elapsed:310
20050330:mean:CINT2000:base:build:secs_elapsed:312
20050401:mean:CINT2000:base:build:secs_elapsed:318 
20050329:mean:CINT2000:peak:build:secs_elapsed:354
20050330:mean:CINT2000:peak:build:secs_elapsed:356
20050401:mean:CINT2000:peak:build:secs_elapsed:361

(These are within the normal fluctuation range for spec build times,
AFAIK)

However, Check out a diff of build-20050329.log.gz vs
build-20050330.log.gz

and a diff build-20050330.log.gz vs build-20050331.log.gz
The latter diff consists of almost no differences (just a couple decimal
places of automata generation).
However, the former has large changes in the way libjava is being built,
though i can't quite figure out what is going on.

I suspect that is where our bootstrap time regression lies.
--Dan

Re: bootstrap compare failure in ada/targparm.o on i686-pc-linux-gnu?

[Richard Henderson]

On Mon, Apr 04, 2005 at 07:57:09PM -0300, Alexandre Oliva wrote:
> My head hurts about the GGC implications of opaque pointers in such a
> hash table, and retaining pointers in the hash table that have already
> been otherwise freed.

These are solved problems.

Joe has the correct answer to the question of whether hashing
on pointers is allowed.


r~

Re: call for testers!

[John David Anglin]

> That's probably a relative of the bug that occurs on Darwin.  It ought 
> to be possible to avoid it by using -pipe in TARGET_LIBGCC2_CFLAGS; 
> could you try that?  (I'd like to think that adding -pipe would always 
> be safe, but who knows what madness might lurk in the HPUX 
> assembler...)

This is with gas.  There is additional madness in the HP
assembler but its use is not recommended.

> I guess cc1 does use this file, so comparing the two cc1 executables 
> would fail too; but does it work if -pipe is used?

This file gets linked into all executables.  I'll try a build with
-pipe shortly.

Dave
-- 
J. David Anglin  [EMAIL PROTECTED]
National Research Council of Canada  (613) 990-0752 (FAX: 952-6602)

Re: call for testers!

[Geoffrey Keating]

On 04/04/2005, at 4:31 PM, John David Anglin wrote:
I'd really appreciate it if people on unusual host systems (AIX, HPPA,
cygwin, etc.) could see what the effect of the patch in
 is on their
bootstrap.  I've gotten no responses at all, and I presume this means
that lots of people have tried the patch and discovered that it works
fine, or they aren't too worried about discovering latent bugs and
having their bootstrap fail...
Wouldn't it be wonderful if that were the way things were.  Anyway,
comparison fails on hppa2.0w-hp-hpux11.11:
Bootstrap comparison failure!
libgcc/lib2funcs.o differs
libgcc/lib2funcs_s.o differs
make[1]: *** [gnucompare] Error 1
The problem seems to be in the $GDB_SYMBOLS$ section:
libgcc/lib2funcs.o: file format som
Symnum n_type n_othr n_desc n_value  n_strx String
-1 HdrSym 0  15 003c 1
0  SO 0  0   22 /var/tmp//ccdFfhzk.s
1  SOL0  0   43 lib2funcs.asm
stage2/libgcc/lib2funcs.o: file format som
Contents of $GDB_SYMBOLS$ section:
Symnum n_type n_othr n_desc n_value  n_strx String
-1 HdrSym 0  15 003c 1
0  SO 0  0   22 /var/tmp//ccexJisK.s
1  SOL0  0   43 lib2funcs.asm
That's probably a relative of the bug that occurs on Darwin.  It ought 
to be possible to avoid it by using -pipe in TARGET_LIBGCC2_CFLAGS; 
could you try that?  (I'd like to think that adding -pipe would always 
be safe, but who knows what madness might lurk in the HPUX 
assembler...)

I guess cc1 does use this file, so comparing the two cc1 executables 
would fail too; but does it work if -pipe is used?


smime.p7s
Description: S/MIME cryptographic signature

Re: bootstrap compare failure in ada/targparm.o on i686-pc-linux-gnu?

[Joe Buck]

On Mon, Apr 04, 2005 at 08:06:42PM -0400, Diego Novillo wrote:
> On Mon, Apr 04, 2005 at 07:21:43PM -0300, Alexandre Oliva wrote:
> 
> > Perhaps.  But the fundamental problem is that we shouldn't be hashing
> > on pointers, and tree-eh.c does just that for finally_tree and
> > throw_stmt_table.
> > 
> I've heard both versions: that hashing on pointers is no big
> deal, and that we should never do that.  The reality is that
> pointer hashing is pervasive in the compiler.

I think that the answer is "it depends".

The danger of hashing on pointers is if anything depends on the order of
traversal of the hash table, as this creates nondeterminism and Heisenbugs
(as any small disturbance or even environment variables will change the
addresses).  As long as it can be assured that the order has no effect,
there shouldn't be a problem.  If the hash table is just used for caching,
set membership etc., or if a separate mechanism is used to define the
order of processing hash table data, then the order created by the hash
does not matter.

Re: Problems using cfg_layout_finalize()

[James E Wilson]

Grzegorz B. Prokopski wrote:
If I do that I run into an infinite loop in fixup_reorder_chain()
in its first for loop at:
  while (NEXT_INSN (insn))  << HERE
insn = NEXT_INSN (insn);
It looks like there is an undocumented assumption about insn-chains and 
the rbi->header and rbi->footer fields.  Normally, all of the insns for 
a function are part of a single linked list.  Blocks are numbered 
sequentially, so it is always true that the last insn of block N is 
followed by the first insn of block N+1.  If blocks N and N+1 are 
separated, then you are supposed to split the insn chain, and set 
rbi->footer for block N, and rbi->header for block N+1.  These 
header/footer fields are used to reconnect the insn chain when the block 
movement is done.  That is from a quick look, and may not be entirely 
accurate.  I haven't done extensive work with this code.

I managed to isolate a case where moving a single BB would trigger
this behaviour.  (This is as far as I can tell by looking at the
original code and matching BB's to source code positions.  How do I get
a dump of insns of a BB into some textual form? Is there a utility
function for that?)
There are macros in the .gdbinit file that is automatically loaded by 
gdb.  You can use pr to print a single instruction.  E.g.
(gdb) print insn
(gdb) pr
You can use prl to print a list of N instructions.  E.g.
(gdb) print debug_rtx_count = 1000
(gdb) print get_insns ()
(gdb) prl
will print 1000 instructions from the beginning of the function.  This 
assumes that the insn-chain is intact, which isn't true during block 
reorg.  You probably want to use something like BB_HEAD here.
--
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

Re: GCC 4.0 Status Report (2005-04-05)

[Andrew Pinski]

On Apr 4, 2005, at 8:09 PM, Giovanni Bajo wrote:
Mark Mitchell <[EMAIL PROTECTED]> wrote:
I've attached a revised summary of the critical bugs open against
4.0. The good news is that there are fewer than last week.
Earlier today, Andrew Haley posted a small C++ snippet showing an ABI 
change
affecting gcj on PPC32:
http://gcc.gnu.org/ml/gcc/2005-04/msg00139.html

I hope he'll open a PR soon, but you probably want to consider this 
for 4.0.
Note it also effects all targets too by shown by my testcase.
Also I think it was caused by:
2004-06-21  Mark Mitchell  <[EMAIL PROTECTED]>
* cp-tree.def (NEW_EXPR): Add a fourth slot.
* cp-tree.h (PARMLIST_ELLIPSIS_P): Remove.
(TREE_PARMLIST): Likewise.

It also shows that the C and C++ ABIs for the struct I had in the 
testcase
no longer matches so it is even worse than just gcj.

Testcase:
#include 
typedef struct Parent
{
  long long m;
  int *scratch;
  void * __attribute__((aligned(8))) this$0;
}Parent;
int main (int argc, char **argv)
{
  printf ("%d\n", sizeof(Parent));
  return 0;
}
Thanks,
Andrew Pinski

Re: GCC 4.0 Status Report (2005-04-05)

[Andrew Pinski]

On Apr 4, 2005, at 7:26 PM, Mark Mitchell wrote:
20734 rejects valid pointer to member
  Not yet assigned.
How is this less Critical?
This would breaks lots of code, it is template related too as it is not
rejected when not in templates.
Thanks,
Andrew Pinski

Re: GCC 4.0 Status Report (2005-04-05)

[Giovanni Bajo]

Mark Mitchell <[EMAIL PROTECTED]> wrote:

>> I've attached a revised summary of the critical bugs open against
>> 4.0. The good news is that there are fewer than last week.

Earlier today, Andrew Haley posted a small C++ snippet showing an ABI change
affecting gcj on PPC32:
http://gcc.gnu.org/ml/gcc/2005-04/msg00139.html

I hope he'll open a PR soon, but you probably want to consider this for 4.0.

Giovanni Bajo

Re: bootstrap compare failure in ada/targparm.o on i686-pc-linux-gnu?

[Diego Novillo]

On Mon, Apr 04, 2005 at 07:21:43PM -0300, Alexandre Oliva wrote:

> Perhaps.  But the fundamental problem is that we shouldn't be hashing
> on pointers, and tree-eh.c does just that for finally_tree and
> throw_stmt_table.
> 
I've heard both versions: that hashing on pointers is no big
deal, and that we should never do that.  The reality is that
pointer hashing is pervasive in the compiler.

I have no opinion either way.


Diego.

Re: HPUX/HPPA build broken (was Re: call for testers!)

[John David Anglin]

> I didn't even have an old bootstrap of the trunk for HP-UX; I tried to do
> one and it died with
> 
> ./xgcc -B./ -B/u/jbuck/cvs.hp/trunk/hppa2.0w-hp-hpux11.00/bin/ -isystem 
> /u/jbuck/cvs.hp/trunk/hppa2.0w-hp-hpux11.00/include -isystem 
> /u/jbuck/cvs.hp/trunk/hppa2.0w-hp-hpux11.00/sys-include 
> -L/remote/atg2/jbuck/hpux.tmp/trunk/gcc/../ld -O2 -DIN_GCC-W -Wall 
> -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes 
> -Wold-style-definition  -isystem ./include  -fPIC -g  -DIN_LIBGCC2 
> -D__GCC_FLOAT_NOT_NEEDED  -I. -I. -I/u/jbuck/gnu/src/cvs/trunk/gcc/gcc 
> -I/u/jbuck/gnu/src/cvs/trunk/gcc/gcc/. 
> -I/u/jbuck/gnu/src/cvs/trunk/gcc/gcc/../include -I./../intl 
> -I/u/jbuck/gnu/src/cvs/trunk/gcc/gcc/../libcpp/include  -DL_muldi3  -c 
> /u/jbuck/gnu/src/cvs/trunk/gcc/gcc/libgcc2.c -o libgcc/./_muldi3.o
> /u/jbuck/gnu/src/cvs/trunk/gcc/gcc/libgcc2.c: In function '__muldi3':
> /u/jbuck/gnu/src/cvs/trunk/gcc/gcc/libgcc2.c:533: internal compiler error: in 
> ?, at varasm.c:4828
> 
> This is of course completely unrelated to Geoff's patch.

I believe that this is PR 20719.

Dave
-- 
J. David Anglin  [EMAIL PROTECTED]
National Research Council of Canada  (613) 990-0752 (FAX: 952-6602)

HPUX/HPPA build broken (was Re: call for testers!)

[Joe Buck]

I wrote:
> >I'll check HP-UX/HPPA and let you know; since I didn't have a recent
> >bootstrap of the trunk it will take a bit.

On Mon, Apr 04, 2005 at 03:45:26PM -0700, Geoffrey Keating wrote:
> Even a relatively old bootstrap will do, assembler/linker 
> nondeterminism is what I'm really concerned about.

I didn't even have an old bootstrap of the trunk for HP-UX; I tried to do
one and it died with

./xgcc -B./ -B/u/jbuck/cvs.hp/trunk/hppa2.0w-hp-hpux11.00/bin/ -isystem 
/u/jbuck/cvs.hp/trunk/hppa2.0w-hp-hpux11.00/include -isystem 
/u/jbuck/cvs.hp/trunk/hppa2.0w-hp-hpux11.00/sys-include 
-L/remote/atg2/jbuck/hpux.tmp/trunk/gcc/../ld -O2 -DIN_GCC-W -Wall 
-Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition 
 -isystem ./include  -fPIC -g  -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED  -I. -I. 
-I/u/jbuck/gnu/src/cvs/trunk/gcc/gcc -I/u/jbuck/gnu/src/cvs/trunk/gcc/gcc/. 
-I/u/jbuck/gnu/src/cvs/trunk/gcc/gcc/../include -I./../intl 
-I/u/jbuck/gnu/src/cvs/trunk/gcc/gcc/../libcpp/include  -DL_muldi3  -c 
/u/jbuck/gnu/src/cvs/trunk/gcc/gcc/libgcc2.c -o libgcc/./_muldi3.o
/u/jbuck/gnu/src/cvs/trunk/gcc/gcc/libgcc2.c: In function '__muldi3':
/u/jbuck/gnu/src/cvs/trunk/gcc/gcc/libgcc2.c:533: internal compiler error: in 
?, at varasm.c:4828

This is of course completely unrelated to Geoff's patch.

#0  fancy_abort (file=0x75caa8 "/u/jbuck/gnu/src/cvs/trunk/gcc/gcc/varasm.c",
line=4828, function=0x75c9b0 "?")
at /u/jbuck/gnu/src/cvs/trunk/gcc/gcc/diagnostic.c:559

The context around the abort reads

4825{
4826  /* Some object formats don't support named sections at all.  The
4827 front-end should already have flagged this as an error.  */
4828  gcc_unreachable ();
4829}

so evidently something is trying to use a named section on a platform that
does not support it.

Here's more backtrace.  I have a somewhat older gdb (6.0), so not sure if
the next message matters.  The section name is ".text.unlikely".

During symbol reading, block end address 0x2e6161 less than block start address 
0x2e6170 (patched it).
During symbol reading, block end address 0x2f10c1 less than block start address 
0x2f10e0 (patched it).
#1  0x002ef85c in default_no_named_section (name=0x40062e48 ".text.unlikely",
flags=256, decl=0x0) at /u/jbuck/gnu/src/cvs/trunk/gcc/gcc/varasm.c:4828
#2  0x002e4b6c in named_section_real (name=0x40062e48 ".text.unlikely",
flags=256, decl=0x0) at /u/jbuck/gnu/src/cvs/trunk/gcc/gcc/varasm.c:433
#3  0x002e4d68 in named_section (decl=0x0, name=0x40062e48 ".text.unlikely",
reloc=0) at /u/jbuck/gnu/src/cvs/trunk/gcc/gcc/varasm.c:484
#4  0x002e46b0 in unlikely_text_section ()
at /u/jbuck/gnu/src/cvs/trunk/gcc/gcc/varasm.c:263
#5  0x002e722c in assemble_end_function (decl=0x67daac40,
fnname=0x4008a318 "@__muldi3")
at /u/jbuck/gnu/src/cvs/trunk/gcc/gcc/varasm.c:1381
#6  0x0030a0fc in rest_of_handle_final ()
at /u/jbuck/gnu/src/cvs/trunk/gcc/gcc/passes.c:303
#7  0x0030d930 in rest_of_compilation ()
at /u/jbuck/gnu/src/cvs/trunk/gcc/gcc/passes.c:1763
#8  0x00109018 in execute_one_pass (pass=0x400154f8)
at /u/jbuck/gnu/src/cvs/trunk/gcc/gcc/tree-optimize.c:541
#9  0x00109158 in execute_pass_list (pass=0x400154f8)
at /u/jbuck/gnu/src/cvs/trunk/gcc/gcc/tree-optimize.c:578

Re: call for testers!

[John David Anglin]

> I'd really appreciate it if people on unusual host systems (AIX, HPPA, 
> cygwin, etc.) could see what the effect of the patch in 
>  is on their 
> bootstrap.  I've gotten no responses at all, and I presume this means 
> that lots of people have tried the patch and discovered that it works 
> fine, or they aren't too worried about discovering latent bugs and 
> having their bootstrap fail...

Wouldn't it be wonderful if that were the way things were.  Anyway,
comparison fails on hppa2.0w-hp-hpux11.11:

Bootstrap comparison failure!
libgcc/lib2funcs.o differs
libgcc/lib2funcs_s.o differs
make[1]: *** [gnucompare] Error 1

The problem seems to be in the $GDB_SYMBOLS$ section:

libgcc/lib2funcs.o: file format som

Symnum n_type n_othr n_desc n_value  n_strx String

-1 HdrSym 0  15 003c 1
0  SO 0  0   22 /var/tmp//ccdFfhzk.s
1  SOL0  0   43 lib2funcs.asm

stage2/libgcc/lib2funcs.o: file format som

Contents of $GDB_SYMBOLS$ section:

Symnum n_type n_othr n_desc n_value  n_strx String

-1 HdrSym 0  15 003c 1
0  SO 0  0   22 /var/tmp//ccexJisK.s
1  SOL0  0   43 lib2funcs.asm

Dave
-- 
J. David Anglin  [EMAIL PROTECTED]
National Research Council of Canada  (613) 990-0752 (FAX: 952-6602)

Re: RFC: #pragma optimization_level

[Nix]

On 4 Apr 2005, Marcin Dalecki stipulated:
> I don't agree with the argument presented by Geert Bosch. It's even more 
> difficult to
> muddle through the atrocities of autoconf/automake to find the places where 
> compiler
> switches get set in huge software projects

What's so hard about

find . \( -name 'configure.*' -o -name Makefile.am \) -print | xargs grep CFLAGS

anyway?

I think this is a straw man. Manipulating CFLAGS is just *not that
hard*. A few minutes will suffice for all but the most ludicrously
byzantine project (and I'm not talking `uses automake', here, I'm
talking `generates C code in order to compute CFLAGS to use when
compiling other code'.)

Very little goes that far (one package here out of 2,271). The *vast*
majority just set CFLAGS and/or AM_CFLAGS in one or more places, collate
the result, and that's it. Getting to grips with that is not killingly
difficult.

-- 
This is like system("/usr/funky/bin/perl -e 'exec sleep 1'");
   --- Peter da Silva

GCC 4.0 Status Report (2005-04-05)

[Mark Mitchell]

I've attached a revised summary of the critical bugs open against 4.0. 
The good news is that there are fewer than last week.  There are several 
 bugs for which it appears that all that remains to be done is apply a 
mainline patch to the 4.0 branch.  These are listed at the bottom of the 
summary.

There are three outstanding bugs (19317, 19312, 18604) assigned to Jason 
Merrill, but I didn't hear back from him last week.  Jason, I'm going to 
assume that you're unable to work on these.  As Nathan is on vacation, I 
suppose that means that these will fall to me to fix.  If anyone else 
would like to volunteer for 19317, which has proven particularly thorny, 
that would be helpful.

It would also be helpful if someone were able to review Alexandre 
Oliva's patches for 20126 and 20739.

In terms of schedule, I plan to create the first prerelease this 
weekend, in preparation for a final release on or about the 15th, as 
planned.  After I make the prerelase, the branch will be slushy, and all 
non-documentation commits will require my approval.

I will also clarify an issue about testcases that Joseph raised 
privately.  In particular, fixes to testcases (like adding a new target 
on which to skip the test) are OK for 4.0 if they are OK for mainline, 
without my approval.  In general, things that do not affect the compiler 
or the build process do not require my approval.  Indeed, fixing 
testcases so that there are fewer unexpected failures is helpful both to 
me and to users who will build the release.

--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
Truly Critical
--

19317 C++ problems with temporary return values

  This patch breaks Qt builds.  This is an NRV bug.  Assigned to Merrill.

20126 Wrong memcmp code on AMD64

  Oliva has posted a patch.

19159 Undefined vtable symbols on AIX 

  Mitchell is iterating on a fix.

20739 ICE in gimplify_addr_expr

  Oliva has posted a patch.

18853 ICE: genautomata.c:5238, error: verify_flow_info: Incorrect
  fallthru

  Needs investigation.  May or may not be truly critical.

Less Critical
-

20103 ICE in create_tmp_var with C99 style struct initializer

  Oliva has really been trying hard to fix this one.  I should
  review the C++ bits of his latest change.

17053 -frepo broken on AIX

  Edelsohn does not think fixing the functionality is very important.

19312 ICE in stabilize_call when throwing a copy

  Assigned to Merrill.

18681 template friend declaration not recognized

  Lerdsuwanakij posted a patch.

20342 ICE in reload w/ SSE/MMX

  Assigned to Henderson.

18604 Strong using lookup conflicts

  Assigned to Merrill.

20734 rejects valid pointer to member

  Not yet assigned.

17913 ICE on jumping into statement expression.

  The problematic code has undefined behavior, and J. Myers has
  mitigated the problem in the C front end.  Therefore, this is not
  particularly critical.

19475 CPP conformance issue with "#define a!"

  May be an easy fix; cpplib maintainers?

20076 __builtin_return(__builtin_apply()) inlined incorrectly

  Needs investigation.

Already Fixed
-

19199 Wrong code using ?: operator in C++

  Fixed by Sayle.  Not yet applied to 4.0.

20625 ivopts produces code that generates "unaligned access exception"

  Fixed by Dvorak.  Not yet applied to 4.0.

19225 Segmentation fault with VLAs, affects GLIBC

  Fixed by Johannsen.  Not yet applied to 4.0.

20527 Mishandling of postincrement causes bzip2 miscompilation.

  Fixed by Nilsson.  Not yet applied to 4.0.

Re: bootstrap compare failure in ada/targparm.o on i686-pc-linux-gnu?

[Alexandre Oliva]

On Apr  4, 2005, Dale Johannesen <[EMAIL PROTECTED]> wrote:

> On Apr 4, 2005, at 3:21 PM, Alexandre Oliva wrote:

>> On Apr  4, 2005, Dale Johannesen <[EMAIL PROTECTED]> wrote:
>> 
>>> On Apr 4, 2005, at 2:32 PM, Alexandre Oliva wrote:
 On Mar 26, 2005, Graham Stott <[EMAIL PROTECTED]> wrote:
> I do regular bootstraps of mainline all languages on FC3
> i686-pc-linuux-gnu and haven't seen any problemss upto Friday. I'm
> using --enable-checking=tree,misc,rtl,rtlflag which might make a
> difference.
>> 
 I'm still observing this problem every now and then.  It's not
 consistent or easily reproducible, unfortunately.  I suspect we're
 using pointers somewhere, and that stack/mmap/whatever address
 randomization is causing different results.  I'm looking into it.
>> 
>>> I've found 2 bugs over the last 6 months where the problem is exposed
>>> only if two pointers happen to hash to the same bucket.  It's occurred
>>> to me that doing a bootstrap with all hashtable sizes set to 1
>>> might be
>>> a good idea.
>> 
>> Perhaps.  But the fundamental problem is that we shouldn't be hashing
>> on pointers, and tree-eh.c does just that for finally_tree and
>> throw_stmt_table.

> Hmm.  Of the earlier bugs, in
> http://gcc.gnu.org/ml/gcc-patches/2004-12/msg01760.html
> the hash table in question is built by DOM, and in
> http://gcc.gnu.org/ml/gcc-patches/2005-03/msg01810.html
> it's built by PRE (VN).  I don't think there's general agreement
> that "we shouldn't be hashing on pointers"

Odd...  I was pretty sure there was.  Maybe it's only in binutils?  I
thought we'd been sufficiently bitten by pointer-hashing problems in
GCC to know better.

Anyhow...  The only way I can think of to enable us to hash on
pointers that doesn't involve adding an id to every tree node
(assuming the issue only shows up with tree nodes) is to create a
separate table to maps arbitrary pointers to an intptr_t counter that
gets incremented every time a pointer is added to this hash table.
Computing the hash of a pointer would then amount to looking the
pointer up in this table and obtaining its value.  We could set a
number aside (say 0 or -1) to use in NO_INSERT lookups.

My head hurts about the GGC implications of opaque pointers in such a
hash table, and retaining pointers in the hash table that have already
been otherwise freed.  It surely doesn't hurt, unless you actually
want to save/restore this table; it's perfectly ok to reuse an id for
a pointer to a recycled memory area.  But this table would spend
memory and slow things down.  Maybe we should only use it for
bootstraps (enabled with a flag in the default BOOT_CFLAGS), and
simply hash pointers if the flag is not given?

-- 
Alexandre Oliva http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer   [EMAIL PROTECTED], gcc.gnu.org}
Free Software Evangelist  [EMAIL PROTECTED], gnu.org}

Re: call for testers!

[Geoffrey Keating]

On 04/04/2005, at 3:36 PM, Joe Buck wrote:
On Mon, Apr 04, 2005 at 02:48:02PM -0700, Geoffrey Keating wrote:
I'd really appreciate it if people on unusual host systems (AIX, HPPA,
cygwin, etc.) could see what the effect of the patch in
 is on their
bootstrap.
I'll check HP-UX/HPPA and let you know; since I didn't have a recent
bootstrap of the trunk it will take a bit.
Even a relatively old bootstrap will do, assembler/linker 
nondeterminism is what I'm really concerned about.



smime.p7s
Description: S/MIME cryptographic signature

Re: call for testers!

[Joe Buck]

On Mon, Apr 04, 2005 at 02:48:02PM -0700, Geoffrey Keating wrote:
> I'd really appreciate it if people on unusual host systems (AIX, HPPA, 
> cygwin, etc.) could see what the effect of the patch in 
>  is on their 
> bootstrap.

I'll check HP-UX/HPPA and let you know; since I didn't have a recent
bootstrap of the trunk it will take a bit.

Joe

Re: bootstrap compare failure in ada/targparm.o on i686-pc-linux-gnu?

[Dale Johannesen]

On Apr 4, 2005, at 3:21 PM, Alexandre Oliva wrote:
On Apr  4, 2005, Dale Johannesen <[EMAIL PROTECTED]> wrote:
On Apr 4, 2005, at 2:32 PM, Alexandre Oliva wrote:
On Mar 26, 2005, Graham Stott <[EMAIL PROTECTED]> wrote:
I do regular bootstraps of mainline all languages on FC3
i686-pc-linuux-gnu and haven't seen any problemss upto Friday. I'm
using --enable-checking=tree,misc,rtl,rtlflag which might make a
difference.

I'm still observing this problem every now and then.  It's not
consistent or easily reproducible, unfortunately.  I suspect we're
using pointers somewhere, and that stack/mmap/whatever address
randomization is causing different results.  I'm looking into it.

I've found 2 bugs over the last 6 months where the problem is exposed
only if two pointers happen to hash to the same bucket.  It's occurred
to me that doing a bootstrap with all hashtable sizes set to 1 might 
be
a good idea.
Perhaps.  But the fundamental problem is that we shouldn't be hashing
on pointers, and tree-eh.c does just that for finally_tree and
throw_stmt_table.
Hmm.  Of the earlier bugs, in
http://gcc.gnu.org/ml/gcc-patches/2004-12/msg01760.html
the hash table in question is built by DOM, and in
http://gcc.gnu.org/ml/gcc-patches/2005-03/msg01810.html
it's built by PRE (VN).  I don't think there's general agreement
that "we shouldn't be hashing on pointers"

Re: call for testers!

[David Edelsohn]

> Geoffrey Keating writes:

Geoff> The only work involved, assuming you already have a bootstrapped tree, 
Geoff> would be to apply the patch and run 'make quickstrap' or even 'make 
Geoff> gnucompare'; and possibly a single 'cmp' command.  This should take 
Geoff> about 1 minute.

make quickstrap ; make gnucompare

succeeds with the patch on powerpc-ibm-aix5.2.0.0.

David

Re: bootstrap compare failure in ada/targparm.o on i686-pc-linux-gnu?

[Alexandre Oliva]

On Apr  4, 2005, Dale Johannesen <[EMAIL PROTECTED]> wrote:

> On Apr 4, 2005, at 2:32 PM, Alexandre Oliva wrote:
>> On Mar 26, 2005, Graham Stott <[EMAIL PROTECTED]> wrote:
>>> I do regular bootstraps of mainline all languages on FC3
>>> i686-pc-linuux-gnu and haven't seen any problemss upto Friday. I'm
>>> using --enable-checking=tree,misc,rtl,rtlflag which might make a
>>> difference.

>> I'm still observing this problem every now and then.  It's not
>> consistent or easily reproducible, unfortunately.  I suspect we're
>> using pointers somewhere, and that stack/mmap/whatever address
>> randomization is causing different results.  I'm looking into it.

> I've found 2 bugs over the last 6 months where the problem is exposed
> only if two pointers happen to hash to the same bucket.  It's occurred
> to me that doing a bootstrap with all hashtable sizes set to 1 might be
> a good idea.

Perhaps.  But the fundamental problem is that we shouldn't be hashing
on pointers, and tree-eh.c does just that for finally_tree and
throw_stmt_table.

-- 
Alexandre Oliva http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer   [EMAIL PROTECTED], gcc.gnu.org}
Free Software Evangelist  [EMAIL PROTECTED], gnu.org}

call for testers!

[Geoffrey Keating]

I'd really appreciate it if people on unusual host systems (AIX, HPPA, 
cygwin, etc.) could see what the effect of the patch in 
 is on their 
bootstrap.  I've gotten no responses at all, and I presume this means 
that lots of people have tried the patch and discovered that it works 
fine, or they aren't too worried about discovering latent bugs and 
having their bootstrap fail...

The only work involved, assuming you already have a bootstrapped tree, 
would be to apply the patch and run 'make quickstrap' or even 'make 
gnucompare'; and possibly a single 'cmp' command.  This should take 
about 1 minute.


smime.p7s
Description: S/MIME cryptographic signature

Re: bootstrap compare failure in ada/targparm.o on i686-pc-linux-gnu?

[Dale Johannesen]

On Apr 4, 2005, at 2:32 PM, Alexandre Oliva wrote:
On Mar 26, 2005, Graham Stott <[EMAIL PROTECTED]> wrote:
I do regular bootstraps of mainline all languages on FC3
i686-pc-linuux-gnu and haven't seen any problemss upto Friday. I'm
using --enable-checking=tree,misc,rtl,rtlflag which might make a
difference.
I'm still observing this problem every now and then.  It's not
consistent or easily reproducible, unfortunately.  I suspect we're
using pointers somewhere, and that stack/mmap/whatever address
randomization is causing different results.  I'm looking into it.
I've found 2 bugs over the last 6 months where the problem is exposed
only if two pointers happen to hash to the same bucket.  It's occurred
to me that doing a bootstrap with all hashtable sizes set to 1 might be
a good idea.

Re: bootstrap compare failure in ada/targparm.o on i686-pc-linux-gnu?

[Alexandre Oliva]

On Mar 26, 2005, Graham Stott <[EMAIL PROTECTED]> wrote:

> I do regular bootstraps of mainline all languages on FC3
> i686-pc-linuux-gnu and haven't seen any problemss upto Friday. I'm
> using --enable-checking=tree,misc,rtl,rtlflag which might make a
> difference.

I'm still observing this problem every now and then.  It's not
consistent or easily reproducible, unfortunately.  I suspect we're
using pointers somewhere, and that stack/mmap/whatever address
randomization is causing different results.  I'm looking into it.

-- 
Alexandre Oliva http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer   [EMAIL PROTECTED], gcc.gnu.org}
Free Software Evangelist  [EMAIL PROTECTED], gnu.org}

Major bootstrap time regression on March 30

[Steven Bosscher]

Hi,

We have a bootstrap time regression since March 30.  Bootstrap times
on Diego Novillo's SPEC box went up from (an already high)  5500s to
almost 8000s, see:
http://people.redhat.com/dnovillo/spec2000/gcc/gcc-compiler-build-secs_elapsed.png

On IRC a patch possibly causing this regression was mentioned: the
subvars correctness changes from Dan. He also posted a heuristics
change patch a day earlier, which has not been reviewed yet, see:
http://gcc.gnu.org/ml/gcc-patches/2005-03/msg02666.html.  If the
subvars patch really is the problem, this heuristics patch should
fix it.

Could someone (hi, Diego!) review Dan's patch?  And if that patch
does not fix this, we'll have to look for someone else to blame ;-)

Gr.
Steven

Re: specification for gcc compilers on sparc and powerpc

[James A. Morrison]

Marek Krzyzowski <[EMAIL PROTECTED]> writes:

> Hello
> 
> I appreciate your work and do not want to bother you, but I hope, that 
> somebody will send me some helpful answer on my question. Is anyone can send 
> me his 'specs' file (contains configuration for working compiler) ??
> (this is standard localization: 
> " /usr/lib/gcc-lib/name_of_compiler/lib/version/specs "
>  this is, in example, on my computer:
> " /gcc/lib/gcc/sparc-elf-linux/3.4.3/specs " )
 ^^^

 This looks strange.  Try configuring with --target=sparc-linux or
--target=sparc-unknown-linux-gnu .

-- 
Thanks,
Jim

http://www.student.cs.uwaterloo.ca/~ja2morri/
http://phython.blogspot.com
http://open.nit.ca/wiki/?page=jim

Re: RFC: #pragma optimization_level

[Marcin Dalecki]

On 2005-04-04, at 19:46, Dale Johannesen wrote:
On Apr 3, 2005, at 5:31 PM, Geert Bosch wrote:
On Apr 1, 2005, at 16:36, Mark Mitchell wrote:
In fact, I've long said that GCC had too many knobs.
(For example, I just had a discussion with a customer where I 
explained that the various optimization passes, while theoretically 
orthogonal, are not entirely orthogonal in practice, and that 
truning on another pass (GCSE, in this caes) avoided other bugs.  
For that reason, I'm not actually convinced that all the -f options 
for turning on and off passes are useful for end-users, although 
they are clearly useful for debugging the compiler itself.  I think 
we might have more satisfied users if we simply had -Os, -O0, ..., 
-O3.  However, many people in the GCC community itself, and in 
certain other vocal areas of the user base, do not agree.)
Pragmas have even more potential for causing problems than 
command-line options.
People are generally persuaded more easily to change optimization 
options, than
to go through hundreds of source files fixing pragmas.
I would hope so.  But the reason I'm doing this is that we've got a 
lot of customer
requests for pragma-level control of optimization.
I don't agree with the argument presented by Geert Bosch. It's even 
more difficult to
muddle through the atrocities of autoconf/automake to find the places 
where compiler
switches get set in huge software projects then doing a grep -r 
\\#pragma ./
over a source tree.

Re: Question regarding MIPS_GPREL_16 relocation

[Richard Sandiford]

"Mile Davidovic" <[EMAIL PROTECTED]> writes:
> But problem is passing G0 option, if I simple put 
> MULTILIB_OPTIONS = G0 mlong-calls msoft-float EL/EB mips32/mips64  
> building library fail.

If you add something to MULTILIB_OPTIONS, you need to add an entry
to MULTILIB_DIRNAMES as well.

(Sorry if you already knew and did that, but in that case,
how did building the library fail?)

Richard

specification for gcc compilers on sparc and powerpc

[Marek Krzyzowski]

Hello

I appreciate your work and do not want to bother you, but I hope, that 
somebody will send me some helpful answer on my question. Is anyone can send 
me his 'specs' file (contains configuration for working compiler) ??
(this is standard localization: 
" /usr/lib/gcc-lib/name_of_compiler/lib/version/specs "
 this is, in example, on my computer:
" /gcc/lib/gcc/sparc-elf-linux/3.4.3/specs " )

I didn't mention I am looking for versions created on SPARC and PowerPC 
processors. I especially desire compiler compiled for sparclite86x and IBM's 
PowerPC (but that is not indespensable condition)

In advance, thank you very much for any help !!!

I enclosure (for certainty) my mail address, please send me - 
[EMAIL PROTECTED]

--
Startuj z INTERIA.PL! >>> http://link.interia.pl/f186c 

Re: Use Bohem's GC for compiler proper in 4.1?

[Robert Dewar]

Joe Buck wrote:
$20? That does not seem to correspond to current prices:

Yes, Mike's off by a factor of roughly 5.
or n months for a not very large value of n :-)

Re: 4.0 regression: g++ class layout on PPC32 has changed

[Andrew Pinski]

On Apr 4, 2005, at 2:33 PM, Andrew Pinski wrote:
On Apr 4, 2005, at 1:01 PM, Andrew Haley wrote:
Giovanni Bajo writes:
Is __alignof__( ::java::lang::Object ) the same under 3.4 and 4.0 in 
the
first place?
Yes, 4 in both cases.

And here is the most reduced testcase (and it shows that the C and C++
front-ends don't agree any more which is bad):
Using the following compile time testcase (only for x86-pc-linux-gnu):
typedef struct Parent
{
  long long m;
  int *scratch;
  void * __attribute__((aligned(8))) this$0;
}Parent;
int f[sizeof(Parent)!=24?-1:1];
I found that this started to be rejected between 2004-06-22-trunk 
(#470) and 2004-06-24-trunk (#471).

I used Phil's regression hunter: .
Thanks,
Andrew Pinski

Re: Cross-compiling for PPC405 core...

[Mike Stump]

On Apr 4, 2005, at 11:13 AM, François Mainguy wrote:
Bonjour – I own a Mac OS X 10.3.8 loaded with gcc 3.3 on it.  I’d like
to add a gcc target so that I can also cross-compile for PowerPC 405
core CPU (as featured in a Xilinx Virtex-2 Pro FPGA).  I know I  
need to
download something from GCC website and build gcc on Darwin 7.8 with
some options for that PPC405 target, but since I never did that, can
somebody help me ?
This is the wrong list for such questions...  You can try reading the  
documentation, I think it covers stuff like this, and I think it has  
a pointer to the right list.

Re: 4.0 regression: g++ class layout on PPC32 has changed

[Andrew Pinski]

On Apr 4, 2005, at 1:01 PM, Andrew Haley wrote:
Giovanni Bajo writes:
Is __alignof__( ::java::lang::Object ) the same under 3.4 and 4.0 in 
the
first place?
Yes, 4 in both cases.

And here is the most reduced testcase (and it shows that the C and C++
front-ends don't agree any more which is bad):
#include 
typedef struct Parent
{
  long long m;
  int *scratch;
  void * __attribute__((aligned(8))) this$0;
}Parent;
int main (int argc, char **argv)
{
  printf ("%d\n", sizeof(Parent));
  return 0;
}
This is also seen on i686-pc-linux-gnu with the same results as on
ppc-darwin.  This has been broken since 20040909.
Thanks,
Andrew Pinski

Cross-compiling for PPC405 core...

[François Mainguy]

Bonjour – I own a Mac OS X 10.3.8 loaded with gcc 3.3 on it.  I’d like
to add a gcc target so that I can also cross-compile for PowerPC 405
core CPU (as featured in a Xilinx Virtex-2 Pro FPGA).  I know I need to
download something from GCC website and build gcc on Darwin 7.8 with
some options for that PPC405 target, but since I never did that, can
somebody help me ?

Regards,
François

Re: RFC: #pragma optimization_level

[Dale Johannesen]

On Apr 3, 2005, at 5:31 PM, Geert Bosch wrote:
On Apr 1, 2005, at 16:36, Mark Mitchell wrote:
In fact, I've long said that GCC had too many knobs.
(For example, I just had a discussion with a customer where I 
explained that the various optimization passes, while theoretically 
orthogonal, are not entirely orthogonal in practice, and that truning 
on another pass (GCSE, in this caes) avoided other bugs.  For that 
reason, I'm not actually convinced that all the -f options for 
turning on and off passes are useful for end-users, although they are 
clearly useful for debugging the compiler itself.  I think we might 
have more satisfied users if we simply had -Os, -O0, ..., -O3.  
However, many people in the GCC community itself, and in certain 
other vocal areas of the user base, do not agree.)
Pragmas have even more potential for causing problems than 
command-line options.
People are generally persuaded more easily to change optimization 
options, than
to go through hundreds of source files fixing pragmas.
I would hope so.  But the reason I'm doing this is that we've got a lot 
of customer
requests for pragma-level control of optimization.

As the average life of a piece of source code is far longer than the 
life-span
of a specific GCC release, users expect to compile unchanged source 
code with
many different compilers. For this reason, I think it is big mistake to
allow pragmas to turn on or off individual passes. The internal 
structure
of the compiler changes all the time, and pragmas written for one 
version
may not make sense for another version.

The effect will be that over time, user pragmas are wrong more often 
than
right, and the compiler will often do better when just ignoring them 
all together.
(This is when people will ask for a 
-fignore-source-optimization-pragmas flag.)
Pressure on GCC developers to maintain compatibility with old flags 
will increase
as well. This is a recipe for disaster.
Certainly problems can arise, but I think you're seriously overstating 
them.
The C and C++ standards require that unrecognized pragmas be ignored,
and the pragmas we're talking about don't affect correctness.  So the 
worst effect
you should see is that your code is less efficient than expected.  (The 
changes
to disallow nonconforming code which go in with every release, some of 
which
change behavior that's been stable for years, are a much bigger problem 
for users.)

But doing anything much more elaborate than optimization
(off, size, some, all, inlining) corresponding to (-O0, Os, O1, O2, O3)
on a per-function basis seems a bad idea.
Personally I have no strong opinion about this either way.

Re: 4.0 regression: g++ class layout on PPC32 has changed

[Andrew Haley]

Giovanni Bajo writes:
 > Andrew Haley <[EMAIL PROTECTED]> wrote:
 > 
 > >  > > public:
 > >  > >   long long __attribute__((aligned(__alignof__( ::java::lang::Object 
 > >  l;
 > >  >
 > >  > I don't recall the exact details, but I have fixed a couple of
 > >  > bugs about the use of __alignof__ and attribute aligned on
 > >  > members of classes (maybe templates only?). Are you positive
 > >  > this attribute declaration *does* have an effect at all in
 > >  > 3.4?
 > >
 > > It seems to be the other way around.
 > >
 > > The attribute declaration does have an effect in 3.4 -- the offset
 > > changes from 52 to 56 -- but it does not have any effect in 4.0, and
 > > this is what breaks my code.
 > 
 > 
 > Is __alignof__( ::java::lang::Object ) the same under 3.4 and 4.0 in the
 > first place?

Yes, 4 in both cases.

 > My fixes were to parse more attributes, not less. So this has to be
 > unrelated to my patches. I suggest you file a bugreport in Bugzilla, and
 > mark it as ABI breaking. It should get fixed before 4.0 gets out.

OK, I'll file a bug report.

Andrew.

Re: How is lang.opt processed?

[Devang Patel]

On Apr 3, 2005, at 1:33 PM, Gerald Pfeifer wrote:
Steve, Toon,
On Thu, 10 Mar 2005, Steve Kargl wrote:
Jim,
Thanks for the detailed explanation of how GCC options work.
On Fri, 11 Mar 2005, Toon Moene wrote:
Ditto.  Jim, are you reading from some documentation about this  
option
processing that I couldn't find ?  I've spend hours and hours to  
try to
deduce the option processing rules from debugging various parts of  
the
gcc driver, with no success.
any chance I could convince you to document Jim's explanations and  
your
new findings for "future generations"?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19180
-
Devang

Re: Use Bohem's GC for compiler proper in 4.1?

[Devang Patel]

On Apr 3, 2005, at 3:58 PM, Robert Dewar wrote:
so the question
is do similar opportunities still exist?
GCC wiki has a laundry list @ http://gcc.gnu.org/wiki/Speedup%20areas
-
Devang

Re: 4.0 regression: g++ class layout on PPC32 has changed

[Giovanni Bajo]

Andrew Haley <[EMAIL PROTECTED]> wrote:

>  > > public:
>  > >   long long __attribute__((aligned(__alignof__(
::java::lang::Object 
>  > l;
>  >
>  > I don't recall the exact details, but I have fixed a couple of bugs
about
>  > the use of __alignof__ and attribute aligned on members of classes
(maybe
>  > templates only?). Are you positive this attribute declaration *does*
have
>  an > effect at all in 3.4?
>
> It seems to be the other way around.
>
> The attribute declaration does have an effect in 3.4 -- the offset
> changes from 52 to 56 -- but it does not have any effect in 4.0, and
> this is what breaks my code.


Is __alignof__( ::java::lang::Object ) the same under 3.4 and 4.0 in the
first place?

My fixes were to parse more attributes, not less. So this has to be
unrelated to my patches. I suggest you file a bugreport in Bugzilla, and
mark it as ABI breaking. It should get fixed before 4.0 gets out.
-- 
Giovanni Bajo

Re: 4.0 regression: g++ class layout on PPC32 has changed

[Andrew Haley]

Giovanni Bajo writes:
 > Andrew Haley <[EMAIL PROTECTED]> wrote:
 > 
 > > public:
 > >   long long __attribute__((aligned(__alignof__( ::java::lang::Object 
 > l;
 > 
 > I don't recall the exact details, but I have fixed a couple of bugs about
 > the use of __alignof__ and attribute aligned on members of classes (maybe
 > templates only?). Are you positive this attribute declaration *does* have an
 > effect at all in 3.4?

It seems to be the other way around.  

The attribute declaration does have an effect in 3.4 -- the offset
changes from 52 to 56 -- but it does not have any effect in 4.0, and
this is what breaks my code.

Andrew.

Re: RFC: #pragma optimization_level

[Joe Buck]

On Sun, Apr 03, 2005 at 04:25:00PM +0200, Kai Henningsen wrote:
> Well, yes and no - I sometimes think that gcc doesn't have *enough* knobs.

Lots of knobs <=> inadequate testing and failures when users issue a
combination of knob settings that have never been tested.

That's why I find Gentoo rather frightening. :-)

Re: 4.0 regression: g++ class layout on PPC32 has changed

[Andrew Haley]

Joe Buck writes:
 > On Mon, Apr 04, 2005 at 04:07:49PM +0100, Andrew Haley wrote:
 > > I've had a gcj bug report saying that some CNI code has ceased to work
 > > on PPC 32, but I'm not sure that this is a gcj bug at all.  The bug is
 > > that gcj and g++ no longer have comptabile class layout -- members are
 > > at different offsets.
 > 
 > Which front end changed the layout between 3.4 and 4.0, gcj or g++?

The test case that I presented is entirely written in C++.  That makes
it g++, I think.

Andrew.

Re: 4.0 regression: g++ class layout on PPC32 has changed

[Giovanni Bajo]

Andrew Haley <[EMAIL PROTECTED]> wrote:

> public:
>   long long __attribute__((aligned(__alignof__( ::java::lang::Object 
l;

I don't recall the exact details, but I have fixed a couple of bugs about
the use of __alignof__ and attribute aligned on members of classes (maybe
templates only?). Are you positive this attribute declaration *does* have an
effect at all in 3.4?
-- 
Giovanni Bajo

Re: Use Bohem's GC for compiler proper in 4.1?

[Joe Buck]

On Sun, Apr 03, 2005 at 07:36:00PM +0200, Kai Henningsen wrote:
> [EMAIL PROTECTED] (Mike Stump)  wrote on 01.04.05 in <[EMAIL PROTECTED]>:
> 
> > On Friday, April 1, 2005, at 08:48  AM, Stefan Strasser wrote:
> > >  if gcc uses more memory than physically available it spends a _very_
> > > long time swapping
> >
> > Swapping, what's that?  Here's $20, go buy a gigabyte.
> 
> $20? That does not seem to correspond to current prices:

Yes, Mike's off by a factor of roughly 5.

Re: 4.0 regression: g++ class layout on PPC32 has changed

[Joe Buck]

On Mon, Apr 04, 2005 at 04:07:49PM +0100, Andrew Haley wrote:
> I've had a gcj bug report saying that some CNI code has ceased to work
> on PPC 32, but I'm not sure that this is a gcj bug at all.  The bug is
> that gcj and g++ no longer have comptabile class layout -- members are
> at different offsets.

Which front end changed the layout between 3.4 and 4.0, gcj or g++?

4.0 regression: g++ class layout on PPC32 has changed

[Andrew Haley]

I've had a gcj bug report saying that some CNI code has ceased to work
on PPC 32, but I'm not sure that this is a gcj bug at all.  The bug is
that gcj and g++ no longer have comptabile class layout -- members are
at different offsets.


If you run the appended code with g++ version 3.4.1, you get

 $ g++ -m32 thing.cc -save-temps && ./a.out
56

With 4.0, you get

 $ PATH=/local/aph/install/bin/:$PATH g++ -m32 thing.cc -save-temps 
-fabi-version=0 && ./a.out
52


So, apparently class layout has changed, but there doesn't seem to be
anything I can do with -fabi-version= to match the layout of the 3.4.1
compiler.

Does anyone understand what is going on here?

Thanks,
Andrew.


#include 

namespace java
{
  namespace lang
  {
class Object;
  }
}

namespace x
{
  class Parent;
  class Child$Nested;
  class Child;
}


class java::lang::Object
{
protected:
  virtual void finalize (void) { }
public:

  Object (void) { }
};

class x::Parent : public ::java::lang::Object
{
public:
  Parent () { }
public:
  long long __attribute__((aligned(__alignof__( ::java::lang::Object  l;
  long long m;
  long long o;
  long long p;
  long long q;
public:
  void *scratch;
};

class x::Child$Nested : public ::x::Parent
{
public:
  virtual void f ();
  Child$Nested (::x::Child *);
private:
  ::x::Child * __attribute__((aligned(__alignof__( ::x::Parent  this$0;
public:
  bool b;

  friend class x_Child$Nested;
};


void
x::Child$Nested::f ()
{
  printf ("%d\n", ((char*)&(this$0) - (char*)this));
}

::x::Child$Nested::Child$Nested(x::Child* p)
{
  this$0 = p;
}

int main (int argc, char **argv)
{
  ::x::Child$Nested inst ((::x::Child *)NULL);
  inst.f ();

  return 0;
}

gcc4, static array, SSE & alignement

[tbp]

Ok, since i've already looked like an uneducated fool today and i'm
grasping at straws...

Question: why do i get an unaligned array as soon as g++ (4.1.0
20050327, cygwin) finds out that it's static (i mean even if i try to
fool it around a bit)?
It seems to only happen with multidimensionnal arrays, or arrays large enough.

color_t is a __m128 in disguise.
color_t above[1024][2]; -> aligned
static color_t above[1024][2]; -> unaligned

I've tried countless alignement attribute variations and/or
indirections but with the same result.
Other statically allocated, but smaller, thingies in the same unit are
properly aligned.

Have i crossed some magic treshold?

Re: "personal" branch?

[Gerald Pfeifer]

On Tue, 5 Apr 2005, Ben Elliston wrote:
> I am doing some academic work on GCC and am finding it hard to manage
> my patches locally.  Would anyone have any strong objections if I were
> to indulge in creating a branch in the FSF repository for little old
> me?  The volume of my deltas will not be large.

I'm not aware of restrictions we are placing on branches in our CVS
repository, and in fact that's something we wanted to encourage with
our open development model.  Just follow the usual naming conventions
and update cvs.html accordingly, I'd say.

Gerald

"personal" branch?

[Ben Elliston]

I am doing some academic work on GCC and am finding it hard to manage
my patches locally.  Would anyone have any strong objections if I were
to indulge in creating a branch in the FSF repository for little old
me?  The volume of my deltas will not be large.

Ben



pgpBZUGqq4DUi.pgp
Description: PGP signature

Re: gcc4, namespace and template specialization problem

[Jonathan Wakely]

On Mon, Apr 04, 2005 at 01:02:59PM +0100, Jonathan Wakely wrote:

> On Mon, Apr 04, 2005 at 01:08:37PM +0200, tbp wrote:
> 
> > On Apr 4, 2005 1:04 PM, Jonathan Wakely <[EMAIL PROTECTED]> wrote:
> > > Hope that helps,
> > Yes, thanks and for once gcc warning was explicit enough (with a hint
> > about namespace) for me to fix it.
> 
> :-)
> It might be even better if the error indicated that only the definition
> needs to be in the same namespace. 

gah! ignore the sentence above, my brain wasn't firing right, this is
what I meant:

> What I mean is that GCC rejects the following code saying:
> 
> test.cc:7: error: specialization of `template void dummy::foo::f()' in 
> different namespace
> test.cc:3: error:   from definition of `template void dummy::foo::f()'
> 
> but actually the specialisation and definition are both in the global
> namespace:
> 
> namespace dummy {
> struct foo {
> template  void f();
> };
> }
> template  void dummy::foo::f() {}
> template<> void dummy::foo::f<666>() {}
> 
> The error is that the specialisation is in a different namespace from
> the declaration, not the definitionn.
> 
> Does anyone agree? Should I file a PR?
> 
> jon

Re: gcc4, namespace and template specialization problem

[Jonathan Wakely]

On Mon, Apr 04, 2005 at 01:08:37PM +0200, tbp wrote:

> On Apr 4, 2005 1:04 PM, Jonathan Wakely <[EMAIL PROTECTED]> wrote:
> > Hope that helps,
> Yes, thanks and for once gcc warning was explicit enough (with a hint
> about namespace) for me to fix it.

:-)
It might be even better if the error indicated that only the definition
needs to be in the same namespace. 

What I mean is that GCC rejects the following code saying:

test.cc:7: error: specialization of `template void dummy::foo::f()' in 
different namespace
test.cc:3: error:   from definition of `template void dummy::foo::f()'

but actually the specialisation and definition are both in the global
namespace:

namespace dummy {
struct foo {
template  void f();
};
}
template  void dummy::foo::f() {}
template<> void dummy::foo::f<666>() {}

The error is that the specialisation is in a different namespace from
the declaration, not the definitionn.

Does anyone agree? Should I file a PR?

jon

-- 
"Reality is that which, when you stop believing in it, doesn't go away."
- Phillip K. Dick

Re: gcc4, namespace and template specialization problem

[tbp]

On Apr 4, 2005 1:04 PM, Jonathan Wakely <[EMAIL PROTECTED]> wrote:
> Hope that helps,
Yes, thanks and for once gcc warning was explicit enough (with a hint
about namespace) for me to fix it.

I stand corrected.

Re: gcc4, namespace and template specialization problem

[Nathan Sidwell]

tbp wrote:
Sorry for the noise, but i don't own a copy of that byzantine standard.
np. to paraphrase another thread 'here's 18$, go get yourself one'[1]
nathan
[1] available electronically from ansi or iso or some web site.
--
Nathan Sidwell::   http://www.codesourcery.com   :: CodeSourcery LLC
[EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk

Re: gcc4, namespace and template specialization problem

[Jonathan Wakely]

On Mon, Apr 04, 2005 at 01:03:19PM +0200, tbp wrote:

> On Apr 4, 2005 12:50 PM, Jonathan Wakely <[EMAIL PROTECTED]> wrote:
> > GCC 3.4 *does* whine, and I think Intel will in strict mode.
> Can't get neither gcc 3.4.1 to whine about it (-Wall) nor icc 8.1 with
> the highest warning level enabled.

Oh, sorry! the 3.4.4 20050321 (prerelease) I tried does error, and
Comeau in strict mode does, so I thought Intel might too.

Apologies,

jon

-- 
"Neither a man nor a crowd nor a nation can be trusted to act humanely, or
 to think sanely, under the influence of a great fear."
- Bertrand Russell

Re: gcc4, namespace and template specialization problem

[Jonathan Wakely]

On Mon, Apr 04, 2005 at 12:15:07PM +0200, tbp wrote:

> On Apr 4, 2005 11:54 AM, Nathan Sidwell <[EMAIL PROTECTED]> wrote:
> > > Am i missing something obvious?
> > well, not 'obvious', but that is what [14.7.3]/2 says.
> I especially don't quite get why specialization have to be defined
> that way when non specialized version don't have to, ie that is legit:
> namespace dummy {
>   struct foo {
>   template  void f();
>   };
> } 
> template void dummy::foo::f() { }

That's not an explicit specialisation, so the same rules don't apply.
That's just a definition of the primary template.

[14.7.3]/2 says that the *declaration* of an explicit specialisation
must appear in the same namespace. The *definition* can appear in an
enclosing namespace (as with your example above,) so you can do this:

namespace dummy {
struct foo {
template  void f() {}
};
template<> void foo::f<666>();// declare specialisation
}
template<> void dummy::foo::f<666>() {}   // define specialisation

Hope that helps,

jon

-- 
Prediction is very difficult, especially about the future.
- Niels Bohr

Re: SUBTARGET_OPTIONS / SUBTARGET_SWITCHES with .opt

[Aldy Hernandez]

> A back end for a target architecture in GCC has the following parts:
> [...]
> @item
> An optional @[EMAIL PROTECTED] file in the @[EMAIL PROTECTED]
> directory, containing a list of target-specific options.  You can also
> add other option files using the @code{extra_options} variable in
> @file{config.gcc}.  @xref{Options}.
> 
> ...but as so often with gcc documentation, you can probably only find
> it if you already know what it says.

Heh.  Yes, thanks to Zack's answer I had already figured this out.
I was looking for the documentation in options.texi instead.  :)

Thanks.
Aldy

Re: gcc4, namespace and template specialization problem

[tbp]

On Apr 4, 2005 12:50 PM, Jonathan Wakely <[EMAIL PROTECTED]> wrote:
> GCC 3.4 *does* whine, and I think Intel will in strict mode.
Can't get neither gcc 3.4.1 to whine about it (-Wall) nor icc 8.1 with
the highest warning level enabled.

Re: gcc4, namespace and template specialization problem

[tbp]

On Apr 4, 2005 12:21 PM, Nathan Sidwell <[EMAIL PROTECTED]> wrote:
> That's not a declaration, it's a definition of an already declared fn.
> the case you had was a definition that was _also_ a declaration.
[...]
> See the difference?
Yes, and i know about it...

> Although it is kind of quirky that you can declare member function 
> specializations
> outside of the class, but not outside of the namespace.
.. but that's that inconsistency that puzzled/confused me.
Sorry for the noise, but i don't own a copy of that byzantine standard.

Re: gcc4, namespace and template specialization problem

[Jonathan Wakely]

On Mon, Apr 04, 2005 at 11:47:56AM +0200, tbp wrote:

> Hello,
> 
> i'm a bit puzzled by the behaviour of gcc4 (old 4.0 & recent 4.1
> snapshots) regarding how template specialization should be qualified
> wrt namespace:
[snip]
> Other compilers (gcc 3.4.x, msvc2k3, icc8.1) don't whine.

GCC 3.4 *does* whine, and I think Intel will in strict mode.

jon

-- 
"The whole problem with the world is that fools and fanatics are always
 so certain of themselves, but wiser people so full of doubts."
- Bertrand Russell

Re: gcc4, namespace and template specialization problem

[Nathan Sidwell]

tbp wrote:
On Apr 4, 2005 11:54 AM, Nathan Sidwell <[EMAIL PROTECTED]> wrote:
Am i missing something obvious?
well, not 'obvious', but that is what [14.7.3]/2 says.
I especially don't quite get why specialization have to be defined
that way when non specialized version don't have to, ie that is legit:
namespace dummy {
	struct foo {
		template  void f();
	};
} 
template void dummy::foo::f() { }
That's not a declaration, it's a definition of an already declared fn.
the case you had was a definition that was _also_ a declaration.
You can write
namespace dummy {
template<> void foo::f<666>(); // declaration
}
template<> void dummy:foo::f<666>() {} // definition
See the difference?
Although it is kind of quirky that you can declare member function 
specializations
outside of the class, but not outside of the namespace.
nathan
--
Nathan Sidwell::   http://www.codesourcery.com   :: CodeSourcery LLC
[EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk

Re: gcc4, namespace and template specialization problem

[tbp]

On Apr 4, 2005 11:54 AM, Nathan Sidwell <[EMAIL PROTECTED]> wrote:
> > Am i missing something obvious?
> well, not 'obvious', but that is what [14.7.3]/2 says.
I especially don't quite get why specialization have to be defined
that way when non specialized version don't have to, ie that is legit:
namespace dummy {
struct foo {
template  void f();
};
} 
template void dummy::foo::f() { }

But if that's the law...

Thanks for clue.

Re: gcc4, namespace and template specialization problem

[Nathan Sidwell]

tbp wrote:
Hello,
i'm a bit puzzled by the behaviour of gcc4 (old 4.0 & recent 4.1
snapshots) regarding how template specialization should be qualified
wrt namespace:

It has to be written this way:
namespace dummy {
template<> void dummy::foo::f<666>() {}
or
template<> void foo::f<666>() {}
}
correct.
Am i missing something obvious?
well, not 'obvious', but that is what [14.7.3]/2 says.
nathan
--
Nathan Sidwell::   http://www.codesourcery.com   :: CodeSourcery LLC
[EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk

gcc4, namespace and template specialization problem

[tbp]

Hello,

i'm a bit puzzled by the behaviour of gcc4 (old 4.0 & recent 4.1
snapshots) regarding how template specialization should be qualified
wrt namespace:

namespace dummy {
struct foo {
template  void f() {}
};
}
template<> void dummy::foo::f<666>() {}

testcase.cpp:30: error: specialization of 'template void
dummy::foo::f()' in different namespace
testcase.cpp:27: error:   from definition of 'template void
dummy::foo::f()'

It has to be written this way:
namespace dummy {
template<> void dummy::foo::f<666>() {}
or
template<> void foo::f<666>() {}
}

Other compilers (gcc 3.4.x, msvc2k3, icc8.1) don't whine.
Am i missing something obvious?

Re: PR 20505

[Nathan Sidwell]

James E Wilson wrote:
The testcase is not portable, as I pointed out in the PR.  Trying this
on an x86_64-linux system, I get 27 "excess errors" failures.  All of
them are
error: cast from 'int*' to 'int' loses precision
Using long works better than int, but is still not fool proof, as there
are targets where longs are smaller than pointers.  Maybe we can rely on
something like ptrdiff_t?
Here's the testcase I installed.  I also put it on mainline, as I couldn't
see one that you'd installed.
nathan
--
Nathan Sidwell::   http://www.codesourcery.com   :: CodeSourcery LLC
[EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk
2005-04-04  Nathan Sidwell  <[EMAIL PROTECTED]>

PR debug/20505
* g++.dg/debug/const2.C: New.

Index: testsuite/g++.dg/debug/const2.C
===
RCS file: testsuite/g++.dg/debug/const2.C
diff -N testsuite/g++.dg/debug/const2.C
*** /dev/null   1 Jan 1970 00:00:00 -
--- testsuite/g++.dg/debug/const2.C 4 Apr 2005 09:29:12 -
***
*** 0 
--- 1,15 
+ // Copyright (C) 2005 Free Software Foundation, Inc.
+ // Contributed by Nathan Sidwell 1 Apr 2005 <[EMAIL PROTECTED]>
+ 
+ // { dg-options "-ggdb2" }
+ // Origin: ivan <[EMAIL PROTECTED]>
+ //   [EMAIL PROTECTED]
+ // Bug 20505: ICE with -ggdb2
+ 
+ struct b
+ {
+   static const int d;
+   virtual bool IsEmpty() const=0;
+   int e,c;
+ };
+ const int b::d = ((__SIZE_TYPE__)(&((b*)1)->c) - 1);

Re: about "Alias Analysis for Intermediate Code"

[Steven Bosscher]

On Monday 04 April 2005 10:09, zouq wrote:
> i can`t find it in current gcc version.
> pleas do me the favor to tell me about it.

I can only guess that you probably mean the Debray alias analysis
proposed at the GCC summit in 2003.  Follow this link for the paper:
"http://gcc.fyxm.net/summit/2003/Alias analysis for intermediate code.pdf"

That code was never included because this analysis is *very* expensive,
and it should be possible to propagate even better alias analysis info
down from the tree optimizers to RTL.

Gr.
Steven'

about "Alias Analysis for Intermediate Code"

[zouq]

i can`t find it in current gcc version.
pleas do me the favor to tell me about it.

Re: Use Bohem's GC for compiler proper in 4.1?

[Nathan Sidwell]

Zack Weinberg wrote:
Robert Dewar <[EMAIL PROTECTED]> writes:
Zack Weinberg wrote:
Last year CodeSourcery had a contract to speed up the C++ front end at
-O0, and we found that small linear reductions in memory usage
corresponded directly to small linear reductions in time usage, at
about a 2:1 ratio (so 1% less memory -> 0.5% less time).  That
wouldn't be worth bothering with except that there are *lots* of
places where such reductions are available.  We eventually got
something like a 40% overall speedup just from this.  (Sorry, I
haven't got exact numbers.)
Right I am aware of that work, but we are talking now, so the question
is do similar opportunities still exist?

Absolutely.  Most of the memory-saving potential discussed in my and
Nathan Sidwell's paper from last GCC summit, for instance, remains
unrealized.
It's unclear whether Robert means 'similar small linear' opportunities,
or 'any memory reduction' opportunities.  IMO most of the former
opportunities have been got for unoptimized generation.  Towards the
end of the speedup work Zack mentions, we ran into more and more
non-local connections and other such entanglements.  The more ambituous
stuff Zack and my paper talked about are rather non-local and would need
coordinated effort to realize (and a more fully baked design :).
nathan
--
Nathan Sidwell::   http://www.codesourcery.com   :: CodeSourcery LLC
[EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk