where tokens are generated

[anshul goel]

hi
i am Anshul goel doing MS in VLSI.


 i am not getting in which file tokens are generated in c - gcc.
 Please send me file name with complete path , as soon as possible.

thank you...

Strange timings on nocona/prescott with indirect jumps/calls

[Marco Manfredini]

I have a Pentium-4 HT 521 running in 64 bit mode here, which seems to have a 
branch prediction or prefetch misfeature. Here is an example: 

// stall.c

typedef int (*fn)(void*); 
int nop(void* ip) 
{
fn *next=((fn*)ip)+1; 
#ifdef HEIMLICH
// choked?
if (ip==0) abort(); 
#endif
#ifdef NOSC
return 1+(*next)(next);
#else
return (*next)(next); 
#endif
}
int ret(void* ip)
{
return 0; 
}

int main()
{
int i; 
fn prog[]={&nop,&nop,&nop,&nop,&nop,&nop,&nop,&nop,&nop,&ret}; 
for (i=0;i<1;i++) 
{
(*prog)(prog); 
}
}

// eof

(gcc is 4.0.3, gcc-4.3 from svn isn't different) 

gcc -march=nocona -fomit-frame-pointer -O3 stall.c
./a.out runtime: 5.75 sec

gcc -march=nocona -fomit-frame-pointer -O3 -DHEIMLICH stall.c
./a.out runtime: 1.92 sec

gcc -m32 -march=prescott -fomit-frame-pointer -O3 stall.c
./a.out runtime: 7.06 sec

gcc -m32 -march=prescott -fomit-frame-pointer -DHEIMLICH -O3 stall.c
./a.out runtime: 2.67 sec

It looks like the extra branch involved in the "if (*ip==0) abort();" line 
shakes something up in a healthy way, bringing performance back to the 
regions of a core duo cpu. In fact, a simple "jz 0" somewhere before the 
generated sibling call has the same effect. A similar result can be obtained 
with -DNOSC (which will result in an indirect call). 

Since this behaviour affects all kinds of dispatching code (switch, goto 
label, interpreter), I would like to know if this is specific to my stepping 
or a more general problem of the precott core. That is I'd like to ask if you 
people can reproduce this with other models/steppings, in order to find out 
if it's considerable enough to file a enhancement report for the optimizer.

Here's my relevant data (using http://www.etallen.com/cpuid.html): 

   version information (1/eax):
  processor type  = primary processor (0)
  family  = Intel Pentium 4/Pentium D/Pentium Extreme 
Edition/Celeron/Xeon/Xeon MP/Itanium2, AMD Athlon 64/Athlon 
XP-M/Opteron/Sempron/Turion (15)
  model   = 0x4 (4)
  stepping id = 0x1 (1)
  extended family = 0x0 (0)
  extended model  = 0x0 (0)
  (simple synth)  = Intel Pentium 4 (Prescott E0) / Xeon (Nocona E0) / 
Xeon MP (Cranford A0 / Potomac C0) / Celeron D (Prescott E0 ) / Mobile 
Pentium 4 (Prescott E0), 90nm

Bootstrap comparison differnce(s) on cygwin with 4.2.0 RC3: ./ada/exp_aggr.o differs

[Christian Joensson]

On cygwin, with D. Korn's proposed patch to cygwin's (i.e., newlib's)
stdio.h, I get a bootstrap failure do to comparison difference(s):

Comparing stages 2 and 3
warning: ./cc1-checksum.o differs
warning: ./cc1obj-checksum.o differs
warning: ./cc1objplus-checksum.o differs
warning: ./cc1plus-checksum.o differs
warning: ./libgcc/_chkstk.o differs
Bootstrap comparison failure!
./ada/exp_aggr.o differs
make[2]: *** [compare] Error 1
make[2]: Leaving directory `/usr/local/src/branch/objdir'
make[1]: *** [stage3-bubble] Error 2
make[1]: Leaving directory `/usr/local/src/branch/objdir'
make: *** [bootstrap] Error 2


--
Cheers,

/ChJ

Re: Bootstrap comparison differnce(s) on cygwin with 4.2.0 RC3: ./ada/exp_aggr.o differs

[Andrew Haley]

Christian Joensson writes:
 > On cygwin, with D. Korn's proposed patch to cygwin's (i.e., newlib's)
 > stdio.h, I get a bootstrap failure do to comparison difference(s):

Did you do a total rebuild of all gcc in a clean directory?  You need
to.

Andrew.

Re: Bootstrap comparison differnce(s) on cygwin with 4.2.0 RC3: ./ada/exp_aggr.o differs

[Christian Joensson]

2007/5/2, Andrew Haley <[EMAIL PROTECTED]>:

Christian Joensson writes:
 > On cygwin, with D. Korn's proposed patch to cygwin's (i.e., newlib's)
 > stdio.h, I get a bootstrap failure do to comparison difference(s):

Did you do a total rebuild of all gcc in a clean directory?  You need
to.


yep, started from scratch with the tarball...

here's how I configured it:

$ ./stage3-gcc/xgcc.exe -v
Using built-in specs.
Target: i686-pc-cygwin
Configured with: ../gcc/configure --disable-nls
--without-included-gettext --enable-version-specific-runtime-libs
--without-x --enable-libgcj --with-system-zlib --enable-threads=posix
--enable-languages=c,ada,c++,fortran,java,objc,obj-c++,treelang
Thread model: posix
gcc version 4.2.0 20070501 (prerelease)

[EMAIL PROTECTED] /usr/local/src/branch/objdir
$

btw, did it work for you?


--
Cheers,

/ChJ

Re: where tokens are generated

[Ian Lance Taylor]

"anshul goel" <[EMAIL PROTECTED]> writes:

>   i am not getting in which file tokens are generated in c - gcc.
>   Please send me file name with complete path , as soon as possible.

Please do not send e-mail to both [EMAIL PROTECTED] and
[EMAIL PROTECTED]  This kind of question is appropriate for
[EMAIL PROTECTED] only.  Thanks.

Unfortunately I don't really understand your question.  If you are
asking about the parser, then look at c-lex.c and c-parser.c.

Ian

__ffssi2 not exported in libgcc_s.so

[Andreas Krebbel]

Hi,

java is currently not bootstrapping on s390.  The problem appears
to be that the __ffssi libgcc function is not exported since it is
not listed in libgcc-std.ver.


Here are the details:

Building the gcj-dbtool linking against libgcj.so the following error
is reported:

/build2/gcc-4.3-build/gcc/gcj 
-B/build2/gcc-4.3-build/s390-ibm-linux-gnu/libjava/ 
-B/build2/gcc-4.3-build/gcc/ -g -O2 -o .libs/gcj-dbtool 
--main=gnu.gcj.tools.gcj_dbtool.Main -shared-libgcc 
gnu/gcj/tools/gcj_dbtool/natMain.o gnu/gcj/tools/.libs/gcj_dbtool.o  
-L/build2/gcc-4.3-build/s390-ibm-linux-gnu/libjava 
-L/build2/gcc-4.3-build/s390-ibm-linux-gnu/libjava/.libs ./.libs/libgcj.so 
-L/build2/gcc-4.3-build/s390-ibm-linux-gnu/libstdc++-v3/src 
-L/build2/gcc-4.3-build/s390-ibm-linux-gnu/libstdc++-v3/src/.libs -lpthread 
-lrt -ldl -lz -L/build2/gcc-4.3-build/./gcc -lgcc_s -lc -lgcc_s -Wl,--rpath 
-Wl,/build2/gcc-4.3-install/lib

/usr/bin/ld: .libs/gcj-dbtool: hidden symbol `__ffssi2' in 
/build2/gcc-4.3-build/./gcc/libgcc.a(_ffssi2.o) is referenced by DSO
/usr/bin/ld: final link failed: Nonrepresentable section on output



The symbol __ffssi2 is used by closure.o in libffi_convenience.a.  Which is 
linked into
libgcj.so as well as the shared version of libgcc.

Compared to the __ffsdi2 variant __ffssi2 is not exported in libgcc_s.so:

14: 23cc   176 FUNCGLOBAL DEFAULT   11 __ffsdi2@@GCC_3.0
   200: 2334   152 FUNCLOCAL  DEFAULT   11 __ffssi2
   212: 23cc   176 FUNCGLOBAL DEFAULT   11 __ffsdi2



To solve this I would simply add that symbol to libgcc-std.ver to have it 
exported in libgcc_s.so.

What I'm curious about is why this didn't occur earlier?!  The symbol is 
available since 2003 and
I can hardly imagine that no platform was ever in need of it till now.

If it is ok to simply add that symbol to libgcc-std.ver in which category it 
would belong?
I see "# libgcc1 integer symbols" in that file.  Would that be appropriate?

Bye,

-Andreas-

Re: __ffssi2 not exported in libgcc_s.so

[Joseph S. Myers]

On Wed, 2 May 2007, Andreas Krebbel wrote:

> If it is ok to simply add that symbol to libgcc-std.ver in which category it 
> would belong?
> I see "# libgcc1 integer symbols" in that file.  Would that be appropriate?

You add it in the symbol versions for the next release, i.e. under 
GCC_4.3.0.  (If it's needed for 4.2 then under 4.2.0 or 4.2.1 depending on 
when it goes in 4.2 branch.)

-- 
Joseph S. Myers
[EMAIL PROTECTED]

RE: Information about LTO

[Sjodin, Jan]

> -Original Message-
> From: Steven Bosscher [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, May 01, 2007 4:09 PM
> To: Sjodin, Jan
> Cc: Diego Novillo; Joseph S. Myers; Ian Lance Taylor; gcc@gcc.gnu.org
> Subject: Re: Information about LTO
> 
> On 5/1/07, Sjodin, Jan <[EMAIL PROTECTED]> wrote:
> > Can someone give similar information about LTO? How many people
> > (full/part time) and how long time it will take? How much work is
LTO
> > compared to the tuple representation?
> 
> A vast amount more if we're going to work on LTO with the current
> GIMPLE representation, because we'll end up rewriting almost all of it
> when the tuples representation is merged.
> 
> ;-)
> 
> More seriously: LTO is, by my uneducated guess, about the same amount
> of work as the tuples work.  I'm assuming single-language LTO here,
> because cross-language LTO is far harder (by the time we get there,
> we'll be talking about fixing the Fortran front end to play nice with
> the call graph, defining some kind of type system, etc.).
> 
> Personally, I think the most useful thing you could do at this point,
> is helping with the tuples repesentation, or helping with the
> preparations for LTO such as removing lang_hooks and perhaps some
> intermediate representation oddities like early uses of DECL_RTL (for
> e.g. register variables).  I think Kenny has shown that an IL
> reader/writer is not an awful lot of work, but IMHO it will be corner
> cases like the ones I just mention that will take a little while to
> resolve.  So, better start early, to make work easier later on.
> 
> But as I said, that's just my uneducated guess.  I haven't done any
> LTO work myself yet ;-)
> 
> Gr.
> Stevem
> 

Thanks for all the responses. It seems like LTO will have to wait for
the tuples or there will be a lot of throw-away code.

- Jan

Successful build of 4.2.0 RC2 for target=avr host=mingw

[Eric Weddington]

...well sort of.

If I use the releases straight, I get this:

In file included from ../../gcc-4.2.0-20070430/gcc/libgcc2.c:35:
./tm.h:5:29: error: config/avr/avr.h: No such file or directory
./tm.h:6:28: error: config/dbxelf.h: No such file or directory
./tm.h:7:31: error: config/tm-dwarf2.h: No such file or directory
./tm.h:8:23: error: defaults.h: No such file or directory
In file included from ../../gcc-4.2.0-20070430/gcc/libgcc2.c:65:
../../gcc-4.2.0-20070430/gcc/libgcc2.h:255:3: error: #error "expand the
table"
../../gcc-4.2.0-20070430/gcc/libgcc2.c: In function '__mulhi3':
../../gcc-4.2.0-20070430/gcc/libgcc2.c:536: error: 'BITS_PER_UNIT'
undeclared (first use in this function)
../../gcc-4.2.0-20070430/gcc/libgcc2.c:536: error: (Each undeclared
identifier is reported only once
../../gcc-4.2.0-20070430/gcc/libgcc2.c:536: error: for each function it
appears in.)
make[3]: *** [libgcc/./_muldi3.o] Error 1
make[3]: Leaving directory `/c/avrdev/gcc/build/gcc'
make[2]: *** [stmp-multilib] Error 2
make[2]: Leaving directory `/c/avrdev/gcc/build/gcc'
make[1]: *** [all-gcc] Error 2
make[1]: Leaving directory `/c/avrdev/gcc/build'
make: *** [all] Error 2

However, this is just the "trailing forward slash not allowed in include
path" on MinGW bug, #22133, which is still not fixed:

(See comment trail for link to patch.)

After patching GCC to fix that bug, it builds successfully with the
following configuration:

Using built-in specs.
Target: avr
Configured with: ../gcc-4.2.0-20070430/configure
--prefix=/c/WinAVR-GCC-4.2.0 --target=avr --enable-languages=c,c++
--with-dwarf2 --enable-win32-registry=WinAVR-2007xxyy --disable-nls
--with-gmp=/usr/local --with-mpfr=/usr/local --enable-doc --disable-libssp
Thread model: single
gcc version 4.2.0 20070430 (prerelease) (WinAVR 2007xxyy)

This is building from the "core" .bz2 and "c++" .bz2 packages.

Eric Weddington 

Re: GCC 4.2 RC2 Available

[Paweł Sikora]

On Tuesday 01 of May 2007 20:08:25 Mark Mitchell wrote:
> GCC 4.2 RC2 is now available from:
>
>   ftp://gcc.gnu.org/pub/gcc/prerelease-4.2.0-20070430
>
> There is a known serious problem with RC2: Ada does not build.
> Therefore, there will be an RC3 shortly.

there're two more 4.2-only problems with aliasing: PR30052, PR30252.

Re: Backport fix for spurious anonymous ns warnings PR29365 to 4.2?

[Mark Mitchell]

Seongbae Park wrote:
> On 5/1/07, Andrew Pinski <[EMAIL PROTECTED]> wrote:
>> On 01 May 2007 14:28:07 -0700, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
>> > I agree that it would be appropriate to backport the patch to gcc 4.2.
>>
>> Lets first get the patch which fixes the ICE regression that this
>> patch causes approved :).
>>
>> Which can be found at:
>> http://gcc.gnu.org/ml/gcc-patches/2007-04/msg01746.html

This patch is OK for mainline.

As for backporting to 4.2, this isn't a regression, so the default
answer would be "no".  I'm unconvinced that this is a sufficiently
serious problem to merit violating that policy; after all, we're only
talking about a spurious warning.  (However, the other bug here is that
we don't have a warning option for this, so users can't use
-Wno- to turn this off.)

In any case, we're not going to do this for 4.2.0.  As per the policy I
posted recently on PRs, please find a C++ maintainer who wants to argue
for backporting this and ask them to mark the PR as P3 with an argument
as to why this is important to backport.

Thanks,

-- 
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713

GCC 4.2.0 RC3 Available

[Mark Mitchell]

GCC 4.2.0 RC3 is now available from:

  ftp://gcc.gnu.org/pub/gcc/prerelease-4.2.0-20070501

This build now contains the fixes for the Ada build problem present in RC2.

At this point, I have no plans for an RC4.  However, I am reviewing the
various open issues, and available patches, so I might change my mind
about that.

Please see:

  http://gcc.gnu.org/ml/gcc/2007-05/msg00032.html

for information about reporting problems.

Thanks,

-- 
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713

Always generate warning/error for assignment as truth value

[Ching, Jimen \(US SSA\)]

Hi,

I was wondering if there's an option to gcc/g++ to make it generate a
warning/error when an assignment is used as a truth value in an
expression.
The -Wall option does this.  But it can be silenced with parentheses.
The problem is, macros often use parentheses around expressions.  Thus,
this warning is silenced for macros.

Perhaps, in a macro, double parentheses are needed could solve this
problem.

--jc
--
BAE Systems NS I&S
810 Richards Street, Ste. 124
Honolulu, HI  96813
Phone:  808 441-2563

Re: GCC 4.2.0 RC3 Available

[Joel Sherrill]

The RTEMS community is still building and trying to test RC2.
We always build with newlib.

Ralf encountered problems on the avr and bfin during the tool
build and has filed or updated PRs for those. 


I am now building the complete RTEMS source tree and tests
for every board and multilib.  The build is probably about 1/3
of the way through and so far, I have not encountered any problems.

I have a lot left to build though and haven't actually run an executable 
yet.


--joel


Mark Mitchell wrote:

GCC 4.2.0 RC3 is now available from:

  ftp://gcc.gnu.org/pub/gcc/prerelease-4.2.0-20070501

This build now contains the fixes for the Ada build problem present in RC2.

At this point, I have no plans for an RC4.  However, I am reviewing the
various open issues, and available patches, so I might change my mind
about that.

Please see:

  http://gcc.gnu.org/ml/gcc/2007-05/msg00032.html

for information about reporting problems.

Thanks,

  

Re: GCC 4.2.0 RC3 Available

[Mark Mitchell]

Joel Sherrill wrote:

> Ralf encountered problems on the avr and bfin during the tool
> build and has filed or updated PRs for those.

Understood, and thnanks for testing!

I should make clear that I don't see release candidates as opportunities
for general testing; they're final release candidates, not alpha
releases.  The open nature of GCC development means that testing by
stakeholders can (and should) be done well before this point.  The
testing of release candidates should be generally to confirm expected
behavior: do the results that you saw the last time you ran tests,
against an SVN checkout, match what you see today, with a release tarball?

This is in no way a criticism, or a comment on RETMS testing (about
which I know almost nothing), etc.; just a general comment, which your
message gave me the excuse to make. :-)

Thanks,

-- 
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713

Re: GCC 4.2.0 RC3 Available

[Joel Sherrill]

Mark Mitchell wrote:

Joel Sherrill wrote:

  

Ralf encountered problems on the avr and bfin during the tool
build and has filed or updated PRs for those.



Understood, and thnanks for testing!

I should make clear that I don't see release candidates as opportunities
for general testing; they're final release candidates, not alpha
releases.  The open nature of GCC development means that testing by
stakeholders can (and should) be done well before this point.  The
testing of release candidates should be generally to confirm expected
behavior: do the results that you saw the last time you ran tests,
against an SVN checkout, match what you see today, with a release tarball?

  

To be honest we did a lot more testing against pre 4.1 SVN code than against
pre 4.2. All the talk about 4.2 being in bad shape on primary targets
made us leary.  Plus we had our own project's fish to fry. :)

I don't see any problems at this point though except on the avr and bfin.

This is in no way a criticism, or a comment on RETMS testing (about
which I know almost nothing), etc.; just a general comment, which your
message gave me the excuse to make. :-)

  

No criticism taken.  If someone wants to volunteer to help us improve our
testing of gcc, we have ideas which would be mutually beneficial to both
RTEMS and gcc.  If there is bandwidth and a volunteer to help, it would
be a good candidate for the Compile Farm.

It just takes a lot of build time for us to get a test toolset in place 
and test it.

We build gcc C/C++ RPMs for about 10-12 targets including newlib.
That ends up generating 70 libc.a instances once installed.  Then we build
RTEMS, common add-on packages, and examples for over 100
multilib and board specific configurations.  wc reports that source base
as about 915K lines of code.

It's just a matter of human time and machine time. Both are in short 
supply. :)


--joel

Thanks,

  

Re: Backport fix for spurious anonymous ns warnings PR29365 to 4.2?

[Seongbae Park]

On 5/2/07, Mark Mitchell <[EMAIL PROTECTED]> wrote:

Seongbae Park wrote:
> On 5/1/07, Andrew Pinski <[EMAIL PROTECTED]> wrote:
>> On 01 May 2007 14:28:07 -0700, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
>> > I agree that it would be appropriate to backport the patch to gcc 4.2.
>>
>> Lets first get the patch which fixes the ICE regression that this
>> patch causes approved :).
>>
>> Which can be found at:
>> http://gcc.gnu.org/ml/gcc-patches/2007-04/msg01746.html

This patch is OK for mainline.


Attached is the patch I commited just now.


As for backporting to 4.2, this isn't a regression, so the default
answer would be "no".  I'm unconvinced that this is a sufficiently
serious problem to merit violating that policy; after all, we're only
talking about a spurious warning.  (However, the other bug here is that
we don't have a warning option for this, so users can't use
-Wno- to turn this off.)

In any case, we're not going to do this for 4.2.0.  As per the policy I
posted recently on PRs, please find a C++ maintainer who wants to argue
for backporting this and ask them to mark the PR as P3 with an argument
as to why this is important to backport.

Thanks,


My guess is that this will be big enough nuisance to be worth backporting,
but I agree that this isn't a regression
- I won't bother other c++ maintainers for this.
--
#pragma ident "Seongbae Park, compiler, http://seongbae.blogspot.com";
Index: gcc/testsuite/g++.dg/warn/anonymous-namespace-2.h
===
--- gcc/testsuite/g++.dg/warn/anonymous-namespace-2.h   (revision 0)
+++ gcc/testsuite/g++.dg/warn/anonymous-namespace-2.h   (revision 0)
@@ -0,0 +1,3 @@
+namespace {
+  struct bad { };
+}
Index: gcc/testsuite/g++.dg/warn/anonymous-namespace-2.C
===
--- gcc/testsuite/g++.dg/warn/anonymous-namespace-2.C   (revision 0)
+++ gcc/testsuite/g++.dg/warn/anonymous-namespace-2.C   (revision 0)
@@ -0,0 +1,29 @@
+// Test for the warning of exposing types from an anonymous namespace
+// { dg-do compile }
+//
+#include "anonymous-namespace-2.h"
+
+namespace {
+struct good { };
+}
+
+struct g1 {
+good * A;
+};
+struct b1 { // { dg-warning "uses the anonymous namespace" }
+bad * B;
+};
+
+struct g2 {
+good * A[1];
+};
+struct b2 { // { dg-warning "uses the anonymous namespace" }
+bad * B[1];
+};
+
+struct g3 {
+good (*A)[1];
+};
+struct b3 { // { dg-warning "uses the anonymous namespace" }
+bad (*B)[1];
+};
Index: gcc/cp/decl2.c
===
--- gcc/cp/decl2.c  (revision 124362)
+++ gcc/cp/decl2.c  (working copy)
@@ -1856,7 +1856,7 @@ constrain_class_visibility (tree type)
   for (t = TYPE_FIELDS (type); t; t = TREE_CHAIN (t))
 if (TREE_CODE (t) == FIELD_DECL && TREE_TYPE (t) != error_mark_node)
   {
-   tree ftype = strip_array_types (TREE_TYPE (t));
+   tree ftype = strip_pointer_or_array_types (TREE_TYPE (t));
int subvis = type_visibility (ftype);
 
if (subvis == VISIBILITY_ANON)
Index: gcc/c-common.c
===
--- gcc/c-common.c  (revision 124362)
+++ gcc/c-common.c  (working copy)
@@ -3894,6 +3894,15 @@ strip_pointer_operator (tree t)
   return t;
 }
 
+/* Recursively remove pointer or array type from TYPE. */
+tree
+strip_pointer_or_array_types (tree t)
+{
+  while (TREE_CODE (t) == ARRAY_TYPE || POINTER_TYPE_P (t))
+t = TREE_TYPE (t);
+  return t;
+}
+
 /* Used to compare case labels.  K1 and K2 are actually tree nodes
representing case labels, or NULL_TREE for a `default' label.
Returns -1 if K1 is ordered before K2, -1 if K1 is ordered after
Index: gcc/c-common.h
===
--- gcc/c-common.h  (revision 124362)
+++ gcc/c-common.h  (working copy)
@@ -727,6 +727,7 @@ extern bool c_promoting_integer_type_p (
 extern int self_promoting_args_p (tree);
 extern tree strip_array_types (tree);
 extern tree strip_pointer_operator (tree);
+extern tree strip_pointer_or_array_types (tree);
 extern HOST_WIDE_INT c_common_to_target_charset (HOST_WIDE_INT);
 
 /* This is the basic parsing function.  */