Re: [RFC] GCC caret diagnostics

[Chris Lattner]

On Mar 12, 2008, at 11:21 PM, Manuel López-Ibáñez wrote:

On 13/03/2008, Chris Lattner <[EMAIL PROTECTED]> wrote:

There is no right answer, and this topic has been the subject of much
debate on the GCC list in the past.  I really don't care to debate  
the

merits of one approach vs the other with you, I just answered your
question about what clang does.


Of course. I didn't want to get into a debate. I was just trying to
figure out how clang addressed the problem of false positives (or
alternatively the problem of users complaining about them). Thanks for
taking the time to elaborate.


I won't claim that we have a lot of "in the trenches" experience with  
this.  Clang is still quite immature and we've been focusing mostly on  
source-level analysis/transformation stuff so far (with a small amount  
of JITing C code), and not using it much as a drop-in static compiler  
yet.  As such, it hasn't been foisted on tons of unsuspecting users  
(*yet*, ), so they haven't had time to complain.  That  
said, clang has successfully parsed and type checked millions of lines  
of code, so the front-end is in good shape - we just haven't put much  
emphasis on the codegen-through-llvm component yet.


That said, despite much experience, I strongly believe this is the  
right approach.  If you take the example you pasted, even if the  
compiler emits a false positive, it's obvious to the user *why* the  
compiler thinks it is a bug, and they can disable the warning in a  
trivial way that doesn't affect codegen (the 'int x = x;' hack).


The problem with the current GCC approach is that false positives are  
often really bizarre and difficult to understand.  Ones we have hit in  
LLVM (i.e. when building the LLVM codebase with GCC) have to do with  
multiple levels of inlining, etc.  This is *not* a good end-user  
experience IMO.



I have no opinion about the approach that you take in GCC.  In
practice, we have been able to do this analysis very quickly and get
good results, and will continue to refine them as clang continues to
mature.


Hum, that is very interesting because doing these warnings in the
middle-end causes so many false positives/negatives anyway that
perhaps a limited static analysis in the front-end achieves better
results. And the only argument then would be the overhead of the
static analysis. If that is not an issue either, then it seems a very
attractive approach indeed.


The design of clang makes these things potentially cheaper to compute  
than GCC, so I can't claim that it will be 'cheap' to do in GCC.   
However, if you give up on the "goal" of providing a perfect answer,  
you can get good results with low cost.  For example, there is no need  
to build SSA for this stuff.  Bitvector dataflow is a proven and  
extremely cheap way to compute these properties.  It's hard to beat  
doing analysis of 64 variables in parallel with one "or" instruction :).


The real disadvantage of clang doing this is that it requires  
duplicating infrastructure in the front-end.  This means we have to  
build source level CFGs and provide source level dataflow, etc.  The  
compile-time cost of this is not high, but it does take engineering  
effort to implement this.  As it turns out, this same infrastructure  
is needed for other interesting clients (refactoring, static analysis,  
etc) so we needed it anyway.



Do you use the static analysis for other things (other warnings, early
optimizations/folding)? There are many other warnings that would be
noticeably enhanced by some dataflow in the front-end.


All optimizations are done by the optimizer, the only optimizations we  
do in the front-end are the language-required folding of constant  
expressions.  Clang does have a static analysis engine in development  
(which uses a lot of this infrastructure), and it can do things like  
report path sensitive ref counting bugs, null pointer deferences etc.   
However, this is not enabled by default as you compile code, it is a  
stand-alone tool.


I personally think that it is a major problem that GCC doesn't  
produce

these diagnostics unless optimizations are enabled, and I continue to
think that having diagnostics change depending on what optimization
level is enabled is bad.


I think everybody agrees on both. Yet the alternatives to these issues
right now in GCC are building SSA at -O0 and moving the warnings
earlier in the pipeline, respectively. The former results in
slower/bigger -O0 compiler. Both would generate much more false
positives, and there have been a few patches proposing moving them
even later to avoid some false positives.

I guess the static analysis in the front-end was discarded because of
compile-time concerns, but if you don't see that (and clang seems to
be much faster than GCC), then it may be worth reconsidering it.


Clang's architecture is quite different than GCC's: what makes sense  
for it does not necessarily transplant into GCC.  Also, clang is  
already several times f

Re: RFC: adding knowledge of the int_fastN_t types to the compiler

[FX Coudert]

I suggest runtime-variable values depending on a
target-independent macro such as LONG_TYPE_SIZE.  Also remember the
various GNU/Linux targets that do not use config/linux.h (alpha,  
rs6000,

sparc).


Thanks for both hints, I'll update the patch.

Note that the size is not enough for implementing , you  
need the

actual type as well to get C++ mangling right.  So I suggest using
type-name strings as is done for the other standard typedefs


That raises a question: darwin has, for example, in its system headers:

typedef signed char   int8_t;
[...]
/* 7.18.1.3 Fastest-width integer types */
typedef int8_tint_fast8_t;
typedef int16_t  int_fast16_t;

To do the right thing, do I have to #define INT_FAST8_TYPE in  
darwin.h to be "int8_t", or "signed char"? I'd go for the second, but  
as I know nothing about C++, I'd like to be sure :)


Thanks,
FX

--
François-Xavier Coudert
http://www.homepages.ucl.ac.uk/~uccafco/

Re: RFC: adding knowledge of the int_fastN_t types to the compiler

[FX Coudert]

it's just targets that might have them but haven't
had the relevant information recorded in GCC that I think should  
not have
the types defined by default in GCC.  (How this relates to Fortran  
is up

to the Fortran maintainers.)


Fortran requires that a negative value be returned if the  
"int_fastN_t type isn't defined in the companion C compiler" (quoting  
from memory). Thus, of the three cases:


  1. on targets that do have int_fastN_t types defined, we register  
the information in the compiler (for Fortran, but maybe other uses)  
but don't override stdint.h
  2. on targets that don't have int_fastN_t types, we provide a  
stdint.h and give the corresponding values in Fortran
  3. on targets that have int_fastN_t types but the compiler wasn't  
updated to know, we either provide our own defaults in Fortran and  
hope they match; a carefully crafted testcase in the testsuite might  
help checking that and adding information about these targets when we  
see the testcase FAILing.


FX

--
François-Xavier Coudert
http://www.homepages.ucl.ac.uk/~uccafco/

Re: Official GCC git repository

[Tobias Grosser]

On Wed, 2008-03-12 at 16:38 +0100, Bernardo Innocenti wrote:
> Hello,
> 
> many people seem to be finding our git mirror of the GCC repo
> useful:

Sure, I am using it since several weeks and it is a great
improvement in many areas.

For me it seems that the git mirror does not hurt in any way. Sure,
this mail can be seen as the beginning of a discussion about the
best VCS for gcc. And therefore as a final decision to use git
exclusively.
But I think it is not necessary to decide at this moment.
Let's just give more developers the opportunity to try and use a
different VCS, which has some great advantages.

> At this time, the repository is being synch'd every quarter
> hour (actually 03,18,33,48 * * * *), and carries all branches
> (although only a few are displayed).  If people think it would be
> useful, we could install a commit hook on gcc.gnu.org to mirror
> each commit immediately.

Should be quite useful. A post commit hook, does not slow down svn
commit operations, right?

Tobi

Re: Could someone please check if FSF received papers for Intel engineers?

[David Edelsohn]

The engineers currently are not listed in the FSF copyrights
assignment file.

David

Could someone please check if FSF received papers for Intel engineers?

[H.J. Lu]

Hi,

We are almost ready to submit patches for stack branch. I'd like to
verify that FSF has received all necessary papers for our team members

Jinyun (Joey) Ye <[EMAIL PROTECTED]>
Xuepeng Guo <[EMAIL PROTECTED]>
Weiliang Lin <[EMAIL PROTECTED]>

Could someone please check if there are any forms missing?  If yes,
please send those forms to me. I will forward to them.

Thanks.


H.J.

Re: testsuite run-time test for sse2 support

[Uros Bizjak]

On Thu, Mar 13, 2008 at 2:35 PM, Joel Sherrill
<[EMAIL PROTECTED]> wrote:

>  I hacked on that test program to get the attached
>  program.  I ran it multiple times on qemu.
>
>  ext=0x0 sig=0x756e6547
>  0x781abfd YES on SSE2
>
>  I ran the same program natively and got this:
>
>  ext=0x0 sig=0x756e6547
>  0xbfebfbff YES on SSE2
>
>  I wonder if qemu is just reporting things wrong. :(
>  I searched the qemu manual and googled some but
>  didn't see anything that jumped out.
>
>  Does this look like qemu reporting a bogus cpuid or
>  gcc not parsing it correctly?

This all depends on the return value of __get_cpuid_max(). It returns
max value of base cpuid level (5 in my case), and shoould return 0 if
cpuid is not supported. This follows the procedure outlined in
http://download.intel.com/design/processor/applnots/24161832.pdf,
section 2: "Detecting the CPUID Instruction".

It is true, that this is not the most maintained code on the planet,
so some bitrot is possible. The return value of __get_cpuid_max() on
your target will tell...

Thanks,
Uros.

Re: testsuite run-time test for sse2 support

[Joel Sherrill]

Uros Bizjak wrote:

On Thu, Mar 13, 2008 at 2:35 PM, Joel Sherrill
<[EMAIL PROTECTED]> wrote:

  

 I hacked on that test program to get the attached
 program.  I ran it multiple times on qemu.

 ext=0x0 sig=0x756e6547
 0x781abfd YES on SSE2



I am now printing the return value from __get_cpuid_max()


ext=0x0 sig=0x756e6547 returned=0x2
0x781abfd YES on SSE2

Isn't the "sig" supposed to be >= 0x8000?

 I ran the same program natively and got this:

 ext=0x0 sig=0x756e6547
 0xbfebfbff YES on SSE2

 I wonder if qemu is just reporting things wrong. :(
 I searched the qemu manual and googled some but
 didn't see anything that jumped out.

 Does this look like qemu reporting a bogus cpuid or
 gcc not parsing it correctly?



This all depends on the return value of __get_cpuid_max(). It returns
max value of base cpuid level (5 in my case), and shoould return 0 if
cpuid is not supported. This follows the procedure outlined in
http://download.intel.com/design/processor/applnots/24161832.pdf,
section 2: "Detecting the CPUID Instruction".

  

I added a print before the return on !__get_cpuid and it is returning
non-zero.

It is true, that this is not the most maintained code on the planet,
so some bitrot is possible. The return value of __get_cpuid_max() on
your target will tell...

  

The call to __get_cpuid is checking against level 1 and this is a level 2.

--joel

Thanks,
Uros.
  



--
Joel Sherrill, Ph.D. Director of Research & Development
[EMAIL PROTECTED]On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
  Support Available (256) 722-9985

Re: testsuite run-time test for sse2 support

[Uros Bizjak]

Joel Sherrill wrote:


 I hacked on that test program to get the attached
 program.  I ran it multiple times on qemu.

 ext=0x0 sig=0x756e6547
 0x781abfd YES on SSE2



I am now printing the return value from __get_cpuid_max()


ext=0x0 sig=0x756e6547 returned=0x2
0x781abfd YES on SSE2

Isn't the "sig" supposed to be >= 0x8000?


No, it says "uneG" in Intel speak, as in "_Genu_ine Intel"


 I ran the same program natively and got this:

 ext=0x0 sig=0x756e6547
 0xbfebfbff YES on SSE2

 I wonder if qemu is just reporting things wrong. :(
 I searched the qemu manual and googled some but
 didn't see anything that jumped out.

 Does this look like qemu reporting a bogus cpuid or
 gcc not parsing it correctly?



This all depends on the return value of __get_cpuid_max(). It returns
max value of base cpuid level (5 in my case), and shoould return 0 if
cpuid is not supported. This follows the procedure outlined in
http://download.intel.com/design/processor/applnots/24161832.pdf,
section 2: "Detecting the CPUID Instruction".

  
I added a print before the return on !__get_cpuid and it is returning 
non zero.


So, this is qemu bug. It advertises CPUID support with %eax=2, and when 
queried with cpuid, it returns SSE2 support. Either SSE2 should be fully 
fixed in quemu, or it should stop advertising SSE2 (and other levels) 
support.



It is true, that this is not the most maintained code on the planet,
so some bitrot is possible. The return value of __get_cpuid_max() on
your target will tell...

  

The call to __get_cpuid is checking against level 1 and this is a level 2.


This is cpuid level, not SSE level. We want cpuid information indexed 
with %eax=1.


Uros.

Re: RFC: adding knowledge of the int_fastN_t types to the compiler

[Joseph S. Myers]

On Thu, 13 Mar 2008, FX Coudert wrote:

> > Note that the size is not enough for implementing , you need the
> > actual type as well to get C++ mangling right.  So I suggest using
> > type-name strings as is done for the other standard typedefs
> 
> That raises a question: darwin has, for example, in its system headers:
> 
> typedef signed char   int8_t;
> [...]
> /* 7.18.1.3 Fastest-width integer types */
> typedef int8_tint_fast8_t;
> typedef int16_t  int_fast16_t;
> 
> To do the right thing, do I have to #define INT_FAST8_TYPE in darwin.h to be
> "int8_t", or "signed char"? I'd go for the second, but as I know nothing about
> C++, I'd like to be sure :)

Typedefs are always just another name for the same type, so "signed char".  
tm.texi's description of SIZE_TYPE describes the format of strings used 
for the type names.  (Perhaps enums would be better than strings with 
particular forms of the C type names, but that's a completely independent 
matter.)

-- 
Joseph S. Myers
[EMAIL PROTECTED]

Re: RFC: adding knowledge of the int_fastN_t types to the compiler

[Joseph S. Myers]

On Thu, 13 Mar 2008, FX Coudert wrote:

> Fortran requires that a negative value be returned if the "int_fastN_t type
> isn't defined in the companion C compiler" (quoting from memory). Thus, of the
> three cases:

The "fast" and "least" types for 8, 16, 32, 64 are always present, 
according to C99; only the exact-width types may not be present (and 
intptr_t/uintptr_t), if there is no type with those properties.

>  1. on targets that do have int_fastN_t types defined, we register the
> information in the compiler (for Fortran, but maybe other uses) but don't
> override stdint.h

There are targets with at least some of the types in  but no 
, e.g. some Solaris versions; clearly we should provide stdint.h 
there.

We can have appropriate C testcases that at least make sure that the 
compiler's internal definitions are consistent with those from  
and  and with the macros defined for limits and constants.  
These would show up buggy system  for fixincluding on targets 
where we don't install our own.

-- 
Joseph S. Myers
[EMAIL PROTECTED]

Re: GCC 4.3 - Error: Link tests are not allowed after GCC_NO_EXECUTABLES

[Hans Kester]

Thanks for your understandable summary.

On Tue, Mar 11, 2008 at 2:22 PM, Brian Dessent <[EMAIL PROTECTED]> wrote:
> There was one additional solution discussed: disable libtool's checking
> of dlopen() for newlib targets:
>   I think
> everyone agreed that this was a suitable compromise, and that the way
> forward was to revert the libgloss hacks, implement the config.cache
> idea as an optional alternative, and commit the patch to disable
> dlopen() checking on newlib.

That works. After replacing AC_LIBTOOL_DLOPEN with

  if test "x${with_newlib}" != "xyes"; then
AC_LIBTOOL_DLOPEN
  fi

and running autoconf I was able to build six different newlib targets.

> However nothing seemed to ever actually get committed: neither that
> above patch nor the config.cache one seem to have made it into the
> tree.  I think the thread had diverged somewhat into people discussing
> if and how it would be possible to make other target libraries more like
> libstdc++ so that they could more easily build for bare metal newlib
> targets too.  In all of that noise, nobody seems to have committed
> anything, and it looks like 4.3.0 went out the door meanwhile.

Can anybody put at least one patch in? The above one works fine for me.

Too bad GCC 4.3.0 fails to inline functions correctly. Only O0 and O1
work, O2 and O3 produce erroneous code.
So I will stick with 4.2.3 for a while.

Hans

Re: Official GCC git repository

[Daniel Berlin]

On Thu, Mar 13, 2008 at 8:17 AM, Tobias Grosser <[EMAIL PROTECTED]> wrote:
> On Wed, 2008-03-12 at 16:38 +0100, Bernardo Innocenti wrote:
>  > Hello,
>  >
>  > many people seem to be finding our git mirror of the GCC repo
>  > useful:
>
>  Sure, I am using it since several weeks and it is a great
>  improvement in many areas.
>
>  For me it seems that the git mirror does not hurt in any way. Sure,
>  this mail can be seen as the beginning of a discussion about the
>  best VCS for gcc. And therefore as a final decision to use git
>  exclusively.
Well, no.
We will never use git exclusively as long as it requires as many
workflow changes for people as it currently does.  This is not me
speaking for the gcc community, this is me telling it like it is based
on experience moving us to svn.
Even simple things, like having to do git diff -rHEAD instead of git
diff to see added files, etc.
Regardless of how fast it is, until the UI is something people don't
have to think about to work with, it's not going to fly.
Sad but true.

>  But I think it is not necessary to decide at this moment.
>  Let's just give more developers the opportunity to try and use a
>  different VCS, which has some great advantages.

If someone on overseers wants to set up a gcc git mirror, that is fine
(fche may do it for you, in fact). However, we don't (for various
reasons, some technical, some political), allow offsite things to be
considered official parts of our infrastructure.
Thus, I am opposed to adding a link to git.infradead.org, but not
opposed to a link to a git repo on gcc.gnu.org.

>
>
>  > At this time, the repository is being synch'd every quarter
>  > hour (actually 03,18,33,48 * * * *), and carries all branches
>  > (although only a few are displayed).  If people think it would be
>  > useful, we could install a commit hook on gcc.gnu.org to mirror
>  > each commit immediately.
>
>  Should be quite useful. A post commit hook, does not slow down svn
>  commit operations, right?

Sadly, it does in most cases (which is why i don't have an hgpullsvn
hook in post-commit) due to the requirement that it trap errors and
output.

I'm not sure it matters if the repo is 15 minutes behind for any real
work, however, and if a repo was put on gcc.gnu.org, ther ewould be no
problem having a cron job that syncs it

--Dan

Re: [RFC] GCC caret diagnostics

[Tom Tromey]

> "Manuel" == Manuel López-Ibáñez <[EMAIL PROTECTED]> writes:

>> I tend to favor this, provided that the performance is not too awful.
>> But maybe this is painful due to iconv translation?

Manuel> How should a file be properly opened within GCC? I find the
Manuel> code in libcpp/files.c pretty confusing and also I am not
Manuel> interested in parsing the file, so some of the conversions it
Manuel> makes are probably superflous (or perhaps even impossible when
Manuel> calling from expand_location).

Yeah, it is pretty confusing.

I think we should bypass most of the libcpp machinery in the reopen
case.  A lot of that code is for searching the include path, and stuff
like that -- but once we have read the file, we know exactly where it
is.

So, I would say, just reopen it like you would any file.

I think you will still need to dig through the charset translation
stuff a bit and handle that.  Otherwise you may end up printing
garbage.

>> How about -fshow-caret instead of -fdiagnostics-show-caret?
>> (By analogy with -fshow-column.)

Manuel> Well, we have -fdiagnostics-show-option and
Manuel> -fdiagnostics-show-location. So 2 versus 1. ;-) That said, I would
Manuel> also prefer -fshow-option and -fshow-location.

Yeah.  "diagnostics" is too long to type, and "ambiguously plural", if
you know what I mean.

Manuel> I agree that switching cpp to use gcc's diagnostics will avoid
Manuel> code duplication and ensure consistency, yet that is an
Manuel> orthogonal issue, it shouldn't be a prerequisite for caret
Manuel> diagnostics.

Yes, I agree.

Tom

Re: Official GCC git repository

[David Woodhouse]

On Thu, 2008-03-13 at 12:47 -0400, Daniel Berlin wrote:
> We will never use git exclusively as long as it requires as many
> workflow changes for people as it currently does.  This is not me
> speaking for the gcc community, this is me telling it like it is based
> on experience moving us to svn.
> Even simple things, like having to do git diff -rHEAD instead of git
> diff to see added files, etc.
> Regardless of how fast it is, until the UI is something people don't
> have to think about to work with, it's not going to fly.

Surely you jest? Isn't GCC using something really weird at the moment
like Subversion? 

-- 
dwmw2

Re: [RFC] GCC caret diagnostics

[Tom Tromey]

> "Ian" == Ian Lance Taylor <[EMAIL PROTECTED]> writes:

>> Why? Isn't the operator available at that point?

Ian> The location information, if present, is technically available, but it
Ian> would require some surgery to actually get it.

I think the high-level decision to be made here is whether we want to
support "full" diagnostics through the whole compiler pipeline.

If yes, then one consequence is that someone will have to modify code
like this to use proper location information.

We might even have to do that if the answer is "no", if the messages
are coming from something that is called by the front end.

Ian> As we move to tuples, we will have even less location information at
Ian> this point.  We will almost certainly not have the location of any
Ian> operators.  This is in general a good thing, as we won't be paying the
Ian> memory space to carry them through the whole middle-end.

I'm not certain that this is the tradeoff I prefer, but I haven't
exactly done a survey of what diagnostics are emitted where.  My
general worry is that these more distant (from the FE) diagnostics
will also be the ones where having good location information would be
the most useful.

Tom

Re: Official GCC git repository

[Daniel Berlin]

On Thu, Mar 13, 2008 at 1:27 PM, David Woodhouse <[EMAIL PROTECTED]> wrote:
>
>  On Thu, 2008-03-13 at 12:47 -0400, Daniel Berlin wrote:
>  > We will never use git exclusively as long as it requires as many
>  > workflow changes for people as it currently does.  This is not me
>  > speaking for the gcc community, this is me telling it like it is based
>  > on experience moving us to svn.
>  > Even simple things, like having to do git diff -rHEAD instead of git
>  > diff to see added files, etc.
>  > Regardless of how fast it is, until the UI is something people don't
>  > have to think about to work with, it's not going to fly.
>
>  Surely you jest? Isn't GCC using something really weird at the moment
>  like Subversion?

If by "really weird" you mean "nobody has any real complaints about
the way it works and are happy it is close to what they were using
before", then yes, they are using something "really weird".

Re: testsuite run-time test for sse2 support

[Joel Sherrill]

Uros Bizjak wrote:

Joel Sherrill wrote:

  

 I hacked on that test program to get the attached
 program.  I ran it multiple times on qemu.

 ext=0x0 sig=0x756e6547
 0x781abfd YES on SSE2




I am now printing the return value from __get_cpuid_max()


ext=0x0 sig=0x756e6547 returned=0x2
0x781abfd YES on SSE2

Isn't the "sig" supposed to be >= 0x8000?



No, it says "uneG" in Intel speak, as in "_Genu_ine Intel"

  

 I ran the same program natively and got this:

 ext=0x0 sig=0x756e6547
 0xbfebfbff YES on SSE2

 I wonder if qemu is just reporting things wrong. :(
 I searched the qemu manual and googled some but
 didn't see anything that jumped out.

 Does this look like qemu reporting a bogus cpuid or
 gcc not parsing it correctly?



This all depends on the return value of __get_cpuid_max(). It returns
max value of base cpuid level (5 in my case), and shoould return 0 if
cpuid is not supported. This follows the procedure outlined in
http://download.intel.com/design/processor/applnots/24161832.pdf,
section 2: "Detecting the CPUID Instruction".


  

I added a print before the return on !__get_cpuid and it is returning
non zero.



So, this is qemu bug. It advertises CPUID support with %eax=2, and when
queried with cpuid, it returns SSE2 support. Either SSE2 should be fully
fixed in quemu, or it should stop advertising SSE2 (and other levels)
support.
  

This is with the Fedora 8 qemu 0.90 RPM.  There was a 0.91
release in January and the ChangeLog mentions a new cpu model
command line option.  It looks like it might be better although
another command line I was using broke. 

Just to be sure this looks OK in qemu 0.9.1, here is the output
of the test program with the supported cpu models:

-cpu 486 results in

   ext=0x0 sig=0x756e6547 returned=0x0
   __get_cpuid returned 0

-cpu pentium results in
   ext=0x0 sig=0x756e6547 returned=0x1
   0x8001bf NO on SSE2

-cpu pentium2 results in
   ext=0x0 sig=0x756e6547 returned=0x2
   0x183f9ff NO on SSE2

-cpu pentium3 results in
   ext=0x0 sig=0x756e6547 returned=0x2
   0x383f9ff NO on SSE2

And this one just to keep things weird.  Does it make sense?

-cpu qemu32 results in
   ext=0x0 sig=0x756e6547 returned=0x2
   0x781abfd YES on SSE2


I think it looks like I need to start using qemu 0.9.1
and add the -cpu 486 option.
  

It is true, that this is not the most maintained code on the planet,
so some bitrot is possible. The return value of __get_cpuid_max() on
your target will tell...


  

The call to __get_cpuid is checking against level 1 and this is a level 2.



This is cpuid level, not SSE level. We want cpuid information indexed
with %eax=1.

Uros.

  



--
Joel Sherrill, Ph.D. Director of Research & Development
[EMAIL PROTECTED]On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
  Support Available (256) 722-9985

Re: Official GCC git repository

[David Woodhouse]

On Thu, 2008-03-13 at 13:35 -0400, Daniel Berlin wrote:
> If by "really weird" you mean "nobody has any real complaints about
> the way it works and are happy it is close to what they were using
> before", then yes, they are using something "really weird".

To be honest, I find it weird that Subversion even exists. Precisely
because it _is_ so close to what people were using before, as you point
out. I've never really understood why anyone would bother to change from
CVS to SVN -- it just seems to be part of the 'one VCS per project'
insanity.

At least with distributed version control systems, you get a real
benefit and not just change for the sake of it. But again there seems to
be a multitude of contenders because everyone wants to write their own,
rather than settling on one.

I've mostly given up on learning to use different version control
systems. Subversion was the last one I tried, and as soon as I stopped
banging my head against the wall, I just gave up on the project I was
trying to work on and did something else instead. There's plenty of
projects out there which need contributors and which _don't_ make life
harder for developers by requiring them to learn some new and
pointlessly different VCS. 

Later I learned about git-svn and just starting mirroring stuff from all
kinds of other VCSs into git, and life got a whole lot easier.

-- 
dwmw2

Re: Official GCC git repository

[Bernardo Innocenti]

Daniel Berlin wrote:


Well, no.
We will never use git exclusively as long as it requires as many
workflow changes for people as it currently does.  This is not me
speaking for the gcc community, this is me telling it like it is based
on experience moving us to svn.


lol!  Maybe you should ask the Xorg maintainers how much "pain"
it was dropping a centralized scm for a distributed one.

My personal experience of migrating from svn to git, for what
is worth, is 100% positive: I can't think of even one use case
that got worse.

But here we weren't (yet) talking of migrating to git.  We were
just going to serve many GCC developers with a better tool
alongside the official one.



Even simple things, like having to do git diff -rHEAD instead of git
diff to see added files, etc.


LOL!  You can't be serious: why would *compiler* *developers*
be unable to grasp a few command line syntax changes such as
these? Aren't you underestimating your users perhaps?

Again, ask the Xorg developers.  IIRC, all they did was writing
a quick cheatsheet to map cvs commands to their git equivalents.



Regardless of how fast it is, until the UI is something people don't
have to think about to work with, it's not going to fly.
Sad but true.


You have never used git recently, have you?

The easy things are as easy as svn/cvs (just different sometimes).
The hard things (new repo, merging, branching) are fundamentally
easier.  And the totally crazy things become possible.



If someone on overseers wants to set up a gcc git mirror, that is fine
(fche may do it for you, in fact). However, we don't (for various
reasons, some technical, some political), allow offsite things to be
considered official parts of our infrastructure.

Thus, I am opposed to adding a link to git.infradead.org, but not
opposed to a link to a git repo on gcc.gnu.org.


Fair enough.  I hereby volunteer to setup and maintain the git
mirror on gcc.gnu.org if someone provides me a shell account
there.



 Should be quite useful. A post commit hook, does not slow down svn
 commit operations, right?


Sadly, it does in most cases (which is why i don't have an hgpullsvn
hook in post-commit) due to the requirement that it trap errors and
output.


I bet pushing a changeset to git is not going to add
noticeable delay.



I'm not sure it matters if the repo is 15 minutes behind for any real
work, however, and if a repo was put on gcc.gnu.org, ther ewould be no
problem having a cron job that syncs it


Yeah, it's absolutely not bothering me.

If we host it on gcc.gnu.org, it would be interesting to let
people with ssh keys just commit to git to get the changeset
automatically pushed back to svn.  This is a documented
feature of "git svn", although I never tested it myself.

--
\___/
|___|   Bernardo Innocenti - http://www.codewiz.org/
 \___\  One Laptop Per Child - http://www.laptop.org/

Re: Official GCC git repository

[Paul Koning]

> "David" == David Woodhouse <[EMAIL PROTECTED]> writes:

 David> On Thu, 2008-03-13 at 13:35 -0400, Daniel Berlin wrote:
 >> If by "really weird" you mean "nobody has any real complaints
 >> about the way it works and are happy it is close to what they were
 >> using before", then yes, they are using something "really weird".

 David> To be honest, I find it weird that Subversion even
 David> exists. Precisely because it _is_ so close to what people were
 David> using before, as you point out. I've never really understood
 David> why anyone would bother to change from CVS to SVN -- it just
 David> seems to be part of the 'one VCS per project' insanity.

I suspect you haven't looked at Subversion at all.  It's vastly
superior to CVS.  As the book puts it, Subversion has "look and feel
similar to CVS" while "attempting to fix most of CVS's noticeable
flaws".

To list just a few of the fixes: atomic checkouts and commits, instant
branching/tagging, support for file rename, ability to reliably obtain
any previous state of the source repository.  Those are a few of the
very good reasons why GCC switched.  The unfortunate thing is that
other FSF projects haven't yet switched -- it baffles me that this is
so.

At work we switched from CVS to Subversion around the same time GCC
did, and for the same sort of reasons.  Having used both, I can tell
you now that I will NEVER willingly use CVS again.  Never.

paul

Re: Official GCC git repository

[Andrew Haley]

David Woodhouse wrote:
> On Thu, 2008-03-13 at 13:35 -0400, Daniel Berlin wrote:
>> If by "really weird" you mean "nobody has any real complaints about
>> the way it works and are happy it is close to what they were using
>> before", then yes, they are using something "really weird".
> 
> To be honest, I find it weird that Subversion even exists. Precisely
> because it _is_ so close to what people were using before, as you point
> out. I've never really understood why anyone would bother to change from
> CVS to SVN -- it just seems to be part of the 'one VCS per project'
> insanity.

Well, there are some real advantages, but I guess you never found out
what they were.  It was a boost for gcc.

> At least with distributed version control systems, you get a real
> benefit and not just change for the sake of it. 

Well, it's a real difference, for sure.  It may be a benefit in some
circumstances.

> But again there seems to be a multitude of contenders because everyone
> wants to write their own, rather than settling on one.

That's true.

> I've mostly given up on learning to use different version control
> systems. Subversion was the last one I tried, and as soon as I stopped
> banging my head against the wall, I just gave up on the project I was
> trying to work on and did something else instead. There's plenty of
> projects out there which need contributors and which _don't_ make life
> harder for developers by requiring them to learn some new and
> pointlessly different VCS. 

It's not possible for a VCS to be "different" -- it can only be different
from some other VCS.  And from that POV, git is "pointlessly different"
from other VCS.

> Later I learned about git-svn and just starting mirroring stuff from all
> kinds of other VCSs into git, and life got a whole lot easier.

I guess so, as long as semantically important stuff doesn't break when
you do that.

Andrew.

Re: Official GCC git repository

[Harvey Harrison]

On Thu, 2008-03-13 at 18:59 +0100, Bernardo Innocenti wrote:
> Daniel Berlin wrote:

> Fair enough.  I hereby volunteer to setup and maintain the git
> mirror on gcc.gnu.org if someone provides me a shell account
> there.
> 

Feel free to include me if you need any help.  Before you move it to
gcc.gnu.org it would be nice to do a better import...add proper
committer names, clean up some of the dead branchesetc.

> 
> >>  Should be quite useful. A post commit hook, does not slow down svn
> >>  commit operations, right?
> > 
> > Sadly, it does in most cases (which is why i don't have an hgpullsvn
> > hook in post-commit) due to the requirement that it trap errors and
> > output.
> 
> I bet pushing a changeset to git is not going to add
> noticeable delay.

Well, compared to subversion, I doubt you'll even notice it happened.

Cheers,

Harvey

Re: Official GCC git repository

[Manuel López-Ibáñez]

On 13/03/2008, David Woodhouse <[EMAIL PROTECTED]> wrote:
> On Thu, 2008-03-13 at 13:35 -0400, Daniel Berlin wrote:
>  > If by "really weird" you mean "nobody has any real complaints about
>  > the way it works and are happy it is close to what they were using
>  > before", then yes, they are using something "really weird".
>
>
> To be honest, I find it weird that Subversion even exists. Precisely
>  because it _is_ so close to what people were using before, as you point
>  out. I've never really understood why anyone would bother to change from
>  CVS to SVN -- it just seems to be part of the 'one VCS per project'
>  insanity.

[Pointless and million times rehashed discussion about VCS deleted]

Please, this is not the forum to discuss VCSs. Subversion is easier to
understand than GIT is an empirical fact. Subversion being easier to
understand for CVS users than GIT is obvious. Even if neither were
true we are not going to force GIT on nobody. Moving to something else
must be proposed and favoured by the people that are actually using it
the most. When the 20 top committers of GCC are using git, please
bring back this issue. Meanwhile, completely forget about it, you are
wasting yours and everybody else's time.

BTW, you can plug your sync script to gcc-cvs mailing list and sync
for every email received. Easy and does not depend on GCC setting up
something for you.

If you really want to help GCC, help us move to Bugzilla 3.0:

http://gcc.gnu.org/ml/gcc/2008-03/msg00276.html

Let's drop this thread.

Cheers,

Manuel.

Re: Official GCC git repository

[Joe Buck]

On Thu, Mar 13, 2008 at 02:01:46PM -0400, Paul Koning wrote:
>  David> using before, as you point out. I've never really understood
>  David> why anyone would bother to change from CVS to SVN -- it just
>  David> seems to be part of the 'one VCS per project' insanity.
> 
> I suspect you haven't looked at Subversion at all.  It's vastly
> superior to CVS.  As the book puts it, Subversion has "look and feel
> similar to CVS" while "attempting to fix most of CVS's noticeable
> flaws".
> 
> To list just a few of the fixes: atomic checkouts and commits, instant
> branching/tagging, support for file rename, ability to reliably obtain
> any previous state of the source repository.  Those are a few of the
> very good reasons why GCC switched.  The unfortunate thing is that
> other FSF projects haven't yet switched -- it baffles me that this is
> so.

The real issue is centralization vs. decentralization.  If you're going
centralized, then subversion seems to be the best solution available.
But there are substantial advantages to the decentralized model.

RMS has decided to back bzr for Emacs, and to encourage other GNU projects
to switch to it by declaring it to be the official GNU distributed VCS
(the bzr people have agreed to play this role).  I haven't used bzr so I
won't offer any opinions on this.

However, if GCC proposes an official switch to a dVCS, RMS will push bzr.
That doesn't mean he gets his way; he wasn't happy with the svn switch
because svn clearly isn't GNU (it's Apache-licensed).

Test Harness and SPARC VIS Instructions

[Joel Sherrill]

Hi,

Moving on the SPARC, I see a lot of similar
unsupported instruction failures.  I only
see a single sparc feature test.  It is for
"-multrasparc -mvis" and it is actually
passing on the sparc instruction simulator in
gdb. It doesn't make me feel good that this
part passes since I thought SIS was a vanilla
V7 simulator. I think this test isn't tight enough:

proc check_effective_target_ultrasparc_hw { } {
   return [check_runtime ultrasparc_hw {
   int main() { return 0; }
   } "-mcpu=ultrasparc"]
}

For sure though, SIS does NOT support VIS and
there is no test for that.  This leads to this:

Starting program: 
/home/joel/work-gnat/svn/b-gcc1-sparc/gcc/testsuite/gcc/pr18400.exe

Unexpected trap (0x 2) at address 0x02001318
illegal instruction

Program exited normally.
(gdb) disassemble 0x02001318
Dump of assembler code for function check_vect:
...
0x02001318 : impdep1  62, %g0, %g0, %g0
...

Can someone familiar with VIS provide an instruction
that is OK to do a run-time test with to check if
it is supported?

This appears to be the root of as high as ~80% of
sparc-rtems4.9 test failures.

Thanks.

--
Joel Sherrill, Ph.D. Director of Research & Development
[EMAIL PROTECTED]On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
  Support Available (256) 722-9985

Re: [RFC] GCC caret diagnostics

[Ian Lance Taylor]

Tom Tromey <[EMAIL PROTECTED]> writes:

> I'm not certain that this is the tradeoff I prefer, but I haven't
> exactly done a survey of what diagnostics are emitted where.  My
> general worry is that these more distant (from the FE) diagnostics
> will also be the ones where having good location information would be
> the most useful.

As Chris and others have argued, we can do uninitialized warnings in
the frontend.  It has a downside: Chris commented that the optimizers
can emit confusing uninitialized warnings with many layers of
inlining.  I've seen that myself.  But I've seen correct warnings that
way--the variable really was uninitialized.  So moving the warnings to
the tradeoff has a simple tradeoff: you miss some correct warnings.

The warnings we can not do in the frontend are the warnings about
aliasing violations and reliance on undefined overflow.  At least, I
don't see any way to do those reliably without using the optimization
machinery.  I think most other warnings could move to the frontend if
we so desired.

I agree in general that for middle-end warnings having good location
information is useful.  The problem is that for warnings like the
undefined overflow warnings good location information is quite
difficult.  As you know the optimizers can pull together information
from all over the place.  The actual warning can be issued for code
which looks very different from anything the user actually wrote.
Translating back to the problem in the user code can be complicated.
I don't think gcc is going to be able to do that translation.

Ian

Re: Could someone please check if FSF received papers for Intel engineers?

[J.C. Pizarro]

On Thu, 13 Mar 2008 09:44:29 -0400, David Edelsohn wrote:
>   The engineers currently are not listed in the FSF copyrights
> assignment file.
>
> David

Why they've to be listed in FSF copyrights assignment file?

Intel released original x86 hardware.
AMD released original x86-64 hardware.

Intel cloned AMD's x86-64 hardware calling it x64.
AMD cloned Intel's x86 hardware doing it compatible.

The software on hardware needs the hexadecimal specification
of the hardware for the working of this pair software-hardware.
It's the ASM description of the hardware.
Otherwise, this pair won't work without knowledge of the hardware.

The problem is when it will start that the hardware company want
not to transfer its copyrights of hardware documents to software
organization because the hardware company wants to live of the
businesses of licenses and copyrightes, and of the lawyers
against any software organization who didn't dealed with it.

I don't understand how it's made the U.S. law. I'm paranoid in it.

I did read IBM suitcases in around 198x about the separation of
hardware-software. Wintel cases too.

   J.C.Pizarro

Re: Official GCC git repository

[Daniel Berlin]

On Thu, Mar 13, 2008 at 1:59 PM, Bernardo Innocenti <[EMAIL PROTECTED]> wrote:
>  > Even simple things, like having to do git diff -rHEAD instead of git
>  > diff to see added files, etc.
>
>  LOL!  You can't be serious: why would *compiler* *developers*
>  be unable to grasp a few command line syntax changes such as
>  these? Aren't you underestimating your users perhaps?

It's not about grasping, it's about not wanting to waste their time doing it.
What don't you grasp about this?

>  You have never used git recently, have you?

Actually, I tried it for 2 months ending a few weeks ago.

But it is typical of git people to claim that anyone who finds they
have to waste their time learning new workflows to achieve the same
results must not have tried it.

Re: Official GCC git repository

[Daniel Berlin]

On Thu, Mar 13, 2008 at 2:17 PM, Joe Buck <[EMAIL PROTECTED]> wrote:
> On Thu, Mar 13, 2008 at 02:01:46PM -0400, Paul Koning wrote:

>
>  However, if GCC proposes an official switch to a dVCS, RMS will push bzr.
>  That doesn't mean he gets his way; he wasn't happy with the svn switch
>  because svn clearly isn't GNU (it's Apache-licensed).

bzr is simply unusable for a repository the size of gcc (though they
sometimes claim otherwise).
It couldn't even convert the gcc repository from scratch last time i
tried it, and what it left me with (30k revisions) took *forever* to
perform any operation on (IE literally hours to run log commands).

They could have made massive strides since then (this was a little
over a year ago), but I wouldn't trust anything with that large of a
scaling issue to have solved it in such a short time.

Re: Official GCC git repository

[Daniel Berlin]

>
>  Fair enough.  I hereby volunteer to setup and maintain the git
>  mirror on gcc.gnu.org if someone provides me a shell account
>  there.
>

Email [EMAIL PROTECTED] and ask what kind of sponsorship they want
to require for a shell account (for write access to repositories, we
usually only require 1 sponsor, but these do not give you shell
access).
I am happy to sponsor you if it helps.

Re: Test Harness and SPARC VIS Instructions

[Seongbae Park (박성배, 朴成培)]

On Thu, Mar 13, 2008 at 11:31 AM, Joel Sherrill
<[EMAIL PROTECTED]> wrote:
> Hi,
>
>  Moving on the SPARC, I see a lot of similar
>  unsupported instruction failures.  I only
>  see a single sparc feature test.  It is for
>  "-multrasparc -mvis" and it is actually
>  passing on the sparc instruction simulator in
>  gdb. It doesn't make me feel good that this
>  part passes since I thought SIS was a vanilla
>  V7 simulator. I think this test isn't tight enough:
>
>  proc check_effective_target_ultrasparc_hw { } {
> return [check_runtime ultrasparc_hw {
> int main() { return 0; }
> } "-mcpu=ultrasparc"]
>  }
>
>  For sure though, SIS does NOT support VIS and
>  there is no test for that.  This leads to this:
>
>  Starting program:
>  /home/joel/work-gnat/svn/b-gcc1-sparc/gcc/testsuite/gcc/pr18400.exe
>  Unexpected trap (0x 2) at address 0x02001318
>  illegal instruction
>
>  Program exited normally.
>  (gdb) disassemble 0x02001318
>  Dump of assembler code for function check_vect:
>  ...
>  0x02001318 : impdep1  62, %g0, %g0, %g0
>  ...
>
>  Can someone familiar with VIS provide an instruction
>  that is OK to do a run-time test with to check if
>  it is supported?

I don't think there's any user level instruction/register to do that.
You'll have to catch the illegal instruction trap :(

Seongbae

Re: Test Harness and SPARC VIS Instructions

[Joel Sherrill]

Seongbae Park (박성배, 朴成培) wrote:
> On Thu, Mar 13, 2008 at 11:31 AM, Joel Sherrill
> <[EMAIL PROTECTED]> wrote:
>   
>> Hi,
>>
>>  Moving on the SPARC, I see a lot of similar
>>  unsupported instruction failures.  I only
>>  see a single sparc feature test.  It is for
>>  "-multrasparc -mvis" and it is actually
>>  passing on the sparc instruction simulator in
>>  gdb. It doesn't make me feel good that this
>>  part passes since I thought SIS was a vanilla
>>  V7 simulator. I think this test isn't tight enough:
>>
>>  proc check_effective_target_ultrasparc_hw { } {
>> return [check_runtime ultrasparc_hw {
>> int main() { return 0; }
>> } "-mcpu=ultrasparc"]
>>  }
>>
>>  For sure though, SIS does NOT support VIS and
>>  there is no test for that.  This leads to this:
>>
>>  Starting program:
>>  /home/joel/work-gnat/svn/b-gcc1-sparc/gcc/testsuite/gcc/pr18400.exe
>>  Unexpected trap (0x 2) at address 0x02001318
>>  illegal instruction
>>
>>  Program exited normally.
>>  (gdb) disassemble 0x02001318
>>  Dump of assembler code for function check_vect:
>>  ...
>>  0x02001318 : impdep1  62, %g0, %g0, %g0
>>  ...
>>
>>  Can someone familiar with VIS provide an instruction
>>  that is OK to do a run-time test with to check if
>>  it is supported?
>> 
>
> I don't think there's any user level instruction/register to do that.
> You'll have to catch the illegal instruction trap :(
>
>   
I have learned a lot the past few days so let me see if I can explain
what I have learned. :-D

Depending upon the test and target architecture, there are various
mechanisms to prevent the execution of code which is clearly not
supported on a particular target board/cpu (as opposed to the compiler
target).

+ many architectures check that a multilib flag is supported
+ Some do a run-time check. x86 uses cpuid and feature check
to avoid things at run-time
+ Some run a test and let it die on the target board. This is used
by Altivec and ARM Neon.

The last alternative is what will have to be done here. I just
need the single easiest VIS instruction to force the failure.
> Seongbae
>   


-- 
Joel Sherrill, Ph.D. Director of Research & Development
[EMAIL PROTECTED]On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available (256) 722-9985

Re: Official GCC git repository

[Joe Buck]

On Thu, Mar 13, 2008 at 02:46:12PM -0400, Daniel Berlin wrote:
> On Thu, Mar 13, 2008 at 2:17 PM, Joe Buck <[EMAIL PROTECTED]> wrote:
> > On Thu, Mar 13, 2008 at 02:01:46PM -0400, Paul Koning wrote:
> 
> >
> >  However, if GCC proposes an official switch to a dVCS, RMS will push bzr.
> >  That doesn't mean he gets his way; he wasn't happy with the svn switch
> >  because svn clearly isn't GNU (it's Apache-licensed).
> 
> bzr is simply unusable for a repository the size of gcc (though they
> sometimes claim otherwise).
> It couldn't even convert the gcc repository from scratch last time i
> tried it, and what it left me with (30k revisions) took *forever* to
> perform any operation on (IE literally hours to run log commands).

Thanks for the data; that will be a good answer for RMS if he asks us
to switch to it.

> They could have made massive strides since then (this was a little
> over a year ago), but I wouldn't trust anything with that large of a
> scaling issue to have solved it in such a short time.

It might be interesting to repeat the experiment, but what we have with
subversion isn't broken, so there's no need to fix it.

Re: Test Harness and SPARC VIS Instructions

[Uros Bizjak]

Hello!


Can someone familiar with VIS provide an instruction
that is OK to do a run-time test with to check if
it is supported?


Perhaps this fragment from testsuite/gcc.dg/vect/tree-vect.h may help:

#elif defined(__sparc__)
 asm volatile (".word\t0x81b007c0");

Uros.

Re: Test Harness and SPARC VIS Instructions

[Seongbae Park (박성배, 朴成培)]

2008/3/13 Joel Sherrill <[EMAIL PROTECTED]>:
>
> Seongbae Park (박성배, 朴成培) wrote:
>  > On Thu, Mar 13, 2008 at 11:31 AM, Joel Sherrill
>  > <[EMAIL PROTECTED]> wrote:
>  >
>  >> Hi,
>  >>
>  >>  Moving on the SPARC, I see a lot of similar
>  >>  unsupported instruction failures.  I only
>  >>  see a single sparc feature test.  It is for
>  >>  "-multrasparc -mvis" and it is actually
>  >>  passing on the sparc instruction simulator in
>  >>  gdb. It doesn't make me feel good that this
>  >>  part passes since I thought SIS was a vanilla
>  >>  V7 simulator. I think this test isn't tight enough:
>  >>
>  >>  proc check_effective_target_ultrasparc_hw { } {
>  >> return [check_runtime ultrasparc_hw {
>  >> int main() { return 0; }
>  >> } "-mcpu=ultrasparc"]
>  >>  }
>  >>
>  >>  For sure though, SIS does NOT support VIS and
>  >>  there is no test for that.  This leads to this:
>  >>
>  >>  Starting program:
>  >>  /home/joel/work-gnat/svn/b-gcc1-sparc/gcc/testsuite/gcc/pr18400.exe
>  >>  Unexpected trap (0x 2) at address 0x02001318
>  >>  illegal instruction
>  >>
>  >>  Program exited normally.
>  >>  (gdb) disassemble 0x02001318
>  >>  Dump of assembler code for function check_vect:
>  >>  ...
>  >>  0x02001318 : impdep1  62, %g0, %g0, %g0
>  >>  ...
>  >>
>  >>  Can someone familiar with VIS provide an instruction
>  >>  that is OK to do a run-time test with to check if
>  >>  it is supported?
>  >>
>  >
>  > I don't think there's any user level instruction/register to do that.
>  > You'll have to catch the illegal instruction trap :(
>  >
>  >
>  I have learned a lot the past few days so let me see if I can explain
>  what I have learned. :-D
>
>  Depending upon the test and target architecture, there are various
>  mechanisms to prevent the execution of code which is clearly not
>  supported on a particular target board/cpu (as opposed to the compiler
>  target).
>
>  + many architectures check that a multilib flag is supported
>  + Some do a run-time check. x86 uses cpuid and feature check
>  to avoid things at run-time
>  + Some run a test and let it die on the target board. This is used
>  by Altivec and ARM Neon.
>
>  The last alternative is what will have to be done here. I just
>  need the single easiest VIS instruction to force the failure.

I see. What I meant was the second bullet item above doesn't exist for SPARC.
But you can use, e.g. "fzero" instruction (which is VIS 1.0)
for the third bullet, assuming the target board will correctly trigger illtrap.

Seongbae

Re: Official GCC git repository

[Ralf Wildenhues]

* Joe Buck wrote on Thu, Mar 13, 2008 at 07:17:18PM CET:
> On Thu, Mar 13, 2008 at 02:01:46PM -0400, Paul Koning wrote:
[ switching to SVN ]
> > The unfortunate thing is that other FSF projects haven't yet
> > switched -- it baffles me that this is so.

> RMS has decided to back bzr for Emacs, and to encourage other GNU projects
> to switch to it by declaring it to be the official GNU distributed VCS
> (the bzr people have agreed to play this role).

Not to state any opinion, but see 
for a list of FSF projects, most of which have switched to git.

Cheers,
Ralf

Re: testsuite run-time test for sse2 support

[Uros Bizjak]

Joel Sherrill wrote:


This is with the Fedora 8 qemu 0.90 RPM.  There was a 0.91
release in January and the ChangeLog mentions a new cpu model
command line option.  It looks like it might be better although
another command line I was using broke. 

Just to be sure this looks OK in qemu 0.9.1, here is the output
of the test program with the supported cpu models:

-cpu 486 results in

   ext=0x0 sig=0x756e6547 returned=0x0
   __get_cpuid returned 0

-cpu pentium results in
   ext=0x0 sig=0x756e6547 returned=0x1
   0x8001bf NO on SSE2

-cpu pentium2 results in
   ext=0x0 sig=0x756e6547 returned=0x2
   0x183f9ff NO on SSE2

-cpu pentium3 results in
   ext=0x0 sig=0x756e6547 returned=0x2
   0x383f9ff NO on SSE2

And this one just to keep things weird.  Does it make sense?


Yes, these make sense.



-cpu qemu32 results in
   ext=0x0 sig=0x756e6547 returned=0x2
   0x781abfd YES on SSE2

I never heard of x86 processor named qemu32. ;)

Uros.

Re: Could someone please check if FSF received papers for Intel engineers?

[Joe Buck]

On Thu, 13 Mar 2008 09:44:29 -0400, David Edelsohn wrote:
> > The engineers currently are not listed in the FSF copyrights
> > assignment file.

On Thu, Mar 13, 2008 at 07:43:49PM +0100, J.C. Pizarro wrote:
> Why they've to be listed in FSF copyrights assignment file?

Because that is the policy.  In any case, I'm sure that this will be
cleaned up soon; it presumably just means that the paperwork hasn't
been completed yet (paper forms have to be mailed back and signed).

Debating the merits of the policy is off-topic for this list; argue
with RMS if you want, but he doesn't read this list.

Re: Could someone please check if FSF received papers for Intel engineers?

[J.C. Pizarro]

On 2008/3/13, Robert Dewar <[EMAIL PROTECTED]> wrote:
> J.C. Pizarro wrote:
>  > On Thu, 13 Mar 2008 09:44:29 -0400, David Edelsohn wrote:
>  >>  The engineers currently are not listed in the FSF copyrights
>  >> assignment file.
>  >>
>  >> David
>  >
>  > Why they've to be listed in FSF copyrights assignment file?
>  >
>  > Intel released original x86 hardware.
>  > AMD released original x86-64 hardware.
>  >
>  > Intel cloned AMD's x86-64 hardware calling it x64.
>  > AMD cloned Intel's x86 hardware doing it compatible.
>  >
>  > The software on hardware needs the hexadecimal specification
>  > of the hardware for the working of this pair software-hardware.
>  > It's the ASM description of the hardware.
>  > Otherwise, this pair won't work without knowledge of the hardware.
>  >
>  > The problem is when it will start that the hardware company want
>  > not to transfer its copyrights of hardware documents to software
>  > organization because the hardware company wants to live of the
>  > businesses of licenses and copyrightes, and of the lawyers
>  > against any software organization who didn't dealed with it.
>  >
>  > I don't understand how it's made the U.S. law. I'm paranoid in it.
>  >
>  > I did read IBM suitcases in around 198x about the separation of
>  > hardware-software. Wintel cases too.
>  >
>  >J.C.Pizarro
>
>
> This is complete nonsense, I suggest you do a bit
>  of homework before sending messages to this list,
>  which are entirely off topic anyway.

$ grep -iR "intel\.com" . | sed 's/^[^<]*<\([^>]*\)>.*$/\1/g' | sort -u
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
$

Are they listed in FSF copyrights assignment file?

   J.C.Pizarro

Re: Test Harness and SPARC VIS Instructions

[Joel Sherrill]

Uros Bizjak wrote:

Hello!

  

Can someone familiar with VIS provide an instruction
that is OK to do a run-time test with to check if
it is supported?



Perhaps this fragment from testsuite/gcc.dg/vect/tree-vect.h may help:

#elif defined(__sparc__)
  asm volatile (".word\t0x81b007c0");
  

Thanks. That helped a lot.  Now I only see these cases on vect.exp

==

This one looks like another test slipping another unsupported
instruction by.

0x020012b8 :   bne,pn   %icc, 0x200138c 

Is this UltraSPARC and not V7?  Do we need two bad instructions
in the test case?

Executing on host: /home/joel/work-gnat/svn/b-gcc1-sparc/gcc/xgcc 
-B/home/joel/work-gnat/svn/b-gcc1-sparc/gcc/ 
/home/joel/work-gnat/svn/gcc/gcc/testsuite/gcc.dg/vect/vect-align-2.c 
gcc_tg.o   -ftree-vectorize -fno-vect-cost-model -mcpu=ultrasparc -mvis 
-O2 -fdump-tree-vect-details -DSTACK_SIZE=2048 -fno-show-column 
-B/home/joel/work-gnat/svn/bsp-install/sparc-rtems4.9/sis/lib/ -specs 
bsp_specs -qrtems -mcpu=cypress 
/home/joel/work-gnat/svn/b-gcc1-sparc/rtems_gcc_main.o  -Wl,-wrap,exit 
-Wl,-wrap,_exit -Wl,-wrap,main -Wl,-wrap,abort -lm   -o 
./vect-align-2.exe(timeout = 300)

PASS: gcc.dg/vect/vect-align-2.c (test for excess errors)
Unexpected trap (0x 2) at address 0x020012B8^M
illegal instruction^M
FAIL: gcc.dg/vect/vect-align-2.c execution test
==

Is there an option to disable these? These l

PASS: gcc.dg/vect/vect-align-2.c scan-tree-dump-times vect "Alignment of 
access forced using peeling" 0
PASS: gcc.dg/vect/vect-align-2.c scan-tree-dump-times vect "Alignment of 
access forced using versioning" 1
PASS: gcc.dg/vect/vect-align-2.c scan-tree-dump-times vect "vectorized 1 
loops" 1

dg-skip-if was Re: gcc 4.3.0 i386 default question

[Joel Sherrill]

Joseph S. Myers wrote:

On Wed, 12 Mar 2008, David Edelsohn wrote:

  

Joel Sherrill writes:
  

Joel> FAIL: gcc.target/powerpc/405-mullhw-1.c scan-assembler mullhw

Joel> Are those things which would be expected to fail on a vanilla
Joel> 603e target without networking or disk?

Joel> Is this another category of tests to avoid somehow?

  405-mullhw-1.c is invoked with -mcpu=405 and directly scans the
assembly language output -- does not try to create an object file or run
an executable.  If that fails, you should check if the RTEMS configuration
somehow is inhibiting generation of the mullhwX instruction and
TARGET_MULHW flag.



Also, if you use a multilib option in testing, that option goes on the
command line *after* the options specified in dg-options.  The tests may
need to use dg-skip-if to skip them if any CPU option other than the one
in the test is explicitly specified (so it would be tested if no explicit
-mcpu option is used, or if -mcpu=405 is the multilib option being
tested).
  


Are you thinking of something roughly like this?

/* { dg-skip-if "" { { !-mcpu=405 } } { "*" } { "" } } */

Would that work if somehow two -mcpu flags were on the line?

This is the command line in question:

Executing on host: /home/joel/work-gnat/svn/b-gcc1-powerpc/gcc/xgcc 
-B/home/joel/work-gnat/svn/b-gcc1-powerpc/gcc/ 
/home/joel/work-gnat/svn/gcc/gcc/testsuite/gcc.target/powerpc/405-nmaclhw-2.c 
-O2 -mcpu=405 -DSTACK_SIZE=2048 -fno-show-column -S 
-B/home/joel/work-gnat/svn/bsp-install/powerpc-rtems4.9/psim/lib/ -specs 
bsp_specs -qrtems -mcpu=603e -o 405-nmaclhw-2.s (timeout = 300)


FWIW This seems pretty tedious. My grep didn't turn up that
many under gcc.target and I know I have more failures of this
type than I saw uses of dg-skip-if. If the above is what you think
is right, I can take the exact CPU option tested and then make the
test only valid if that CPU option is used. OK?

--joel


--
Joseph S. Myers
[EMAIL PROTECTED]
  



--
Joel Sherrill, Ph.D. Director of Research & Development
[EMAIL PROTECTED]On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
  Support Available (256) 722-9985

Re: testsuite run-time test for sse2 support

[Joel Sherrill]

Thank you.  I will rerun the tests on this target overnight
with this change along with disabling profiling tests
for *-*-rtems*.

It looks like the wheat and chafe are separating a bit. :)

--joel

Uros Bizjak wrote:

Joel Sherrill wrote:

  

This is with the Fedora 8 qemu 0.90 RPM.  There was a 0.91
release in January and the ChangeLog mentions a new cpu model
command line option.  It looks like it might be better although
another command line I was using broke. 

Just to be sure this looks OK in qemu 0.9.1, here is the output
of the test program with the supported cpu models:

-cpu 486 results in

   ext=0x0 sig=0x756e6547 returned=0x0
   __get_cpuid returned 0

-cpu pentium results in
   ext=0x0 sig=0x756e6547 returned=0x1
   0x8001bf NO on SSE2

-cpu pentium2 results in
   ext=0x0 sig=0x756e6547 returned=0x2
   0x183f9ff NO on SSE2

-cpu pentium3 results in
   ext=0x0 sig=0x756e6547 returned=0x2
   0x383f9ff NO on SSE2

And this one just to keep things weird.  Does it make sense?



Yes, these make sense.

  

-cpu qemu32 results in
   ext=0x0 sig=0x756e6547 returned=0x2
   0x781abfd YES on SSE2


I never heard of x86 processor named qemu32. ;)

Uros.

  



--
Joel Sherrill, Ph.D. Director of Research & Development
[EMAIL PROTECTED]On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
  Support Available (256) 722-9985

Re: Test Harness and SPARC VIS Instructions

[Seongbae Park (박성배, 朴成培)]

On Thu, Mar 13, 2008 at 12:32 PM, Joel Sherrill
<[EMAIL PROTECTED]> wrote:
>
> Uros Bizjak wrote:
>  > Hello!
>  >
>  >
>  >> Can someone familiar with VIS provide an instruction
>  >> that is OK to do a run-time test with to check if
>  >> it is supported?
>  >>
>  >
>  > Perhaps this fragment from testsuite/gcc.dg/vect/tree-vect.h may help:
>  >
>  > #elif defined(__sparc__)
>  >   asm volatile (".word\t0x81b007c0");
>  >
>  Thanks. That helped a lot.  Now I only see these cases on vect.exp
>
>  ==
>
>  This one looks like another test slipping another unsupported
>  instruction by.
>
>  0x020012b8 :   bne,pn   %icc, 0x200138c 
>
>  Is this UltraSPARC and not V7?  Do we need two bad instructions
>  in the test case?

Branc with prediction is v9. Even v8 doesn't have it. No v8 processor has VIS,
so actually this test is sufficient. If you really want v7 check (not v8 check),
then you should use something else like, umul,
which is only available on v8 and up.

Seongbae

Re: Test Harness and SPARC VIS Instructions

[Uros Bizjak]

Hello!


This one looks like another test slipping another unsupported
instruction by.

0x020012b8 : bne,pn %icc, 0x200138c 

Is this UltraSPARC and not V7?  Do we need two bad instructions
in the test case?

Executing on host: /home/joel/work-gnat/svn/b-gcc1-sparc/gcc/xgcc 
-B/home/joel/work-gnat/svn/b-gcc1-sparc/gcc/ 
/home/joel/work-gnat/svn/gcc/gcc/testsuite/gcc.dg/vect/vect-align-2.c 
gcc_tg.o -ftree-vectorize -fno-vect-cost-model -mcpu=ultrasparc -mvis 
-O2 -fdump-tree-vect-details -DSTACK_SIZE=2048 -fno-show-column 
-B/home/joel/work-gnat/svn/bsp-install/sparc-rtems4.9/sis/lib/ -specs 
bsp_specs -qrtems -mcpu=cypress 
/home/joel/work-gnat/svn/b-gcc1-sparc/rtems_gcc_main.o -Wl,-wrap,exit 
-Wl,-wrap,_exit -Wl,-wrap,main -Wl,-wrap,abort -lm -o 
./vect-align-2.exe (timeout = 300)

PASS: gcc.dg/vect/vect-align-2.c (test for excess errors)
Unexpected trap (0x 2) at address 0x020012B8^M
illegal instruction^M
FAIL: gcc.dg/vect/vect-align-2.c execution test


This is not-guarded runtime test. The problem is fixed by the attached 
patch.


2008-03-13  Uros Bizjak  <[EMAIL PROTECTED]>

   * gcc.dg/vect/vect-align-2.c: Remove dg-do run directive.
   (main): Call check_vect.

Tested on x86_64-pc-linux-gnu, committed to mainline.

Uros.

Index: vect-align-2.c
===
--- vect-align-2.c  (revision 133190)
+++ vect-align-2.c  (working copy)
@@ -1,5 +1,4 @@
/* { dg-require-effective-target vect_int } */
-/* { dg-do run } */

#include 
#include 
@@ -36,6 +35,8 @@
{
  struct foo  *fp = (struct foo *) malloc (2*sizeof (struct foo));

+  check_vect ();
+
  fbar(fp);
  return 0;
}

Re: [RFC] GCC caret diagnostics

[Manuel López-Ibáñez]

On 13/03/2008, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
> Tom Tromey <[EMAIL PROTECTED]> writes:
>
>
> > I'm not certain that this is the tradeoff I prefer, but I haven't
>  > exactly done a survey of what diagnostics are emitted where.  My
>  > general worry is that these more distant (from the FE) diagnostics
>  > will also be the ones where having good location information would be
>  > the most useful.
>
>
> As Chris and others have argued, we can do uninitialized warnings in
>  the frontend.

Chris also commented that clang has a call graph, dataflow and static
analysis in the front-end. This is a fundamental difference and
explains why their uninitialized warnings wouldn't be annoyingly
noisy. That is not the case in GCC. Our warnings will be very noisy
because we would warn for things like:

int foo()
{
  int i;
  int j;
  do {

j = bar (i);
i++;
  } while (i < j);

  return j;
}

And countless other examples. GCC itself would need to initialize a
bunch of variables (I think they were around 100), last time I tried
to bootstrap with such change. We would better remove -Wuninitialized
from -Wall in that case.

>  I agree in general that for middle-end warnings having good location
>  information is useful.  The problem is that for warnings like the
>  undefined overflow warnings good location information is quite
>  difficult.  As you know the optimizers can pull together information
>  from all over the place.  The actual warning can be issued for code
>  which looks very different from anything the user actually wrote.
>  Translating back to the problem in the user code can be complicated.
>  I don't think gcc is going to be able to do that translation.

Well, we will have to live with that then. But currently we are giving
a line number (and a column number if -fshow-column) and that is
pointing to something, so I guess that we can always display a caret
for that thing.

Cheers,

Manuel.

Re: Could someone please check if FSF received papers for Intel engineers?

[Daniel Berlin]

On Thu, Mar 13, 2008 at 3:14 PM, J.C. Pizarro <[EMAIL PROTECTED]> wrote:
> On 2008/3/13, Robert Dewar <[EMAIL PROTECTED]> wrote:
>
>
> > J.C. Pizarro wrote:
>  >  > On Thu, 13 Mar 2008 09:44:29 -0400, David Edelsohn wrote:
>  >  >>  The engineers currently are not listed in the FSF copyrights
>  >  >> assignment file.
>  >  >>
>  >  >> David
>  >  >
>  >  > Why they've to be listed in FSF copyrights assignment file?
>  >  >
>  >  > Intel released original x86 hardware.
>  >  > AMD released original x86-64 hardware.
>  >  >
>  >  > Intel cloned AMD's x86-64 hardware calling it x64.
>  >  > AMD cloned Intel's x86 hardware doing it compatible.
>  >  >
>  >  > The software on hardware needs the hexadecimal specification
>  >  > of the hardware for the working of this pair software-hardware.
>  >  > It's the ASM description of the hardware.
>  >  > Otherwise, this pair won't work without knowledge of the hardware.
>  >  >
>  >  > The problem is when it will start that the hardware company want
>  >  > not to transfer its copyrights of hardware documents to software
>  >  > organization because the hardware company wants to live of the
>  >  > businesses of licenses and copyrightes, and of the lawyers
>  >  > against any software organization who didn't dealed with it.
>  >  >
>  >  > I don't understand how it's made the U.S. law. I'm paranoid in it.
>  >  >
>  >  > I did read IBM suitcases in around 198x about the separation of
>  >  > hardware-software. Wintel cases too.
>  >  >
>  >  >J.C.Pizarro
>  >
>  >
>  > This is complete nonsense, I suggest you do a bit
>  >  of homework before sending messages to this list,
>  >  which are entirely off topic anyway.
>
>  $ grep -iR "intel\.com" . | sed 's/^[^<]*<\([^>]*\)>.*$/\1/g' | sort -u
>  [EMAIL PROTECTED]
>  [EMAIL PROTECTED]
>  [EMAIL PROTECTED]
>  [EMAIL PROTECTED]
>  [EMAIL PROTECTED]
>  [EMAIL PROTECTED]
>  [EMAIL PROTECTED]
>  [EMAIL PROTECTED]
>  [EMAIL PROTECTED]
>  $
>
>  Are they listed in FSF copyrights assignment file?

yes.
>
>J.C.Pizarro
>

Re: Official GCC git repository

[David Woodhouse]

On Thu, 2008-03-13 at 18:04 +, Andrew Haley wrote:
> It's not possible for a VCS to be "different" -- it can only be
> different from some other VCS. 

That's true. For a non-distributed VCS, the 'norm' is generally
considered to be CVS. Subversion is "different from CVS", for a limited
number of minor reasons which, although real, just don't ever seem to be
worth the pain of the difference in my experience.

>  And from that POV, git is "pointlessly different" from other VCS.

People were trying to make distributed version control systems workable
for a long time before git came along, but without much success. For
_distributed_ version control systems, many people consider git to be
the 'norm', just as CVS was for non-distributed VCS, and all the others
are "pointlessly different".

I could never understand why anyone would use anything but CVS (if that
works for them), or git. The VCS-du-jour craze just confuses me.

But I don't hack on gcc very often, and when I do I'm perfectly capable
of shadowing it into a normal version control system -- so my opinion
doesn't really matter much.

-- 
dwmw2

Re: Could someone please check if FSF received papers for Intel engineers?

[J.C. Pizarro]

On 2008/3/13, Joe Buck <[EMAIL PROTECTED]> wrote:
> This is off-list, because you are wasting the time of the list readership.

No, it's the readership that has to waste its little time if he wants to read
the short lines mails.

>  On Thu, Mar 13, 2008 at 08:14:38PM +0100, J.C. Pizarro wrote:
>  > $ grep -iR "intel\.com" . | sed 's/^[^<]*<\([^>]*\)>.*$/\1/g' | sort -u
>  > [EMAIL PROTECTED]
>  > [EMAIL PROTECTED]
>  > [EMAIL PROTECTED]
>  > [EMAIL PROTECTED]
>  > [EMAIL PROTECTED]
>  > [EMAIL PROTECTED]
>  > [EMAIL PROTECTED]
>  > [EMAIL PROTECTED]
>  > [EMAIL PROTECTED]
>  > $
>  >
>  > Are they listed in FSF copyrights assignment file?
>
>
> Yes.  Of course.  Each individual needs to file paperwork.  Without
>  paperwork, contributions aren't accepted.

Ohh, contributions aren't accepted because they had not assigned
the copyrights to FSF.

Then, are we not doing it due to "GPL license" instead of
"GPL licence + own FSF's policy"?

Well, if they want not to accept those contributions of another authors
then the another authors can fork their works for them self.

Here there is more from intel.com excluding the search in GCC's ADA:
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]

   J.C.Pizarro

Re: [RFC] GCC caret diagnostics

[Chris Lattner]

On Mar 13, 2008, at 11:37 AM, Ian Lance Taylor wrote:

 As you know the optimizers can pull together information
from all over the place.  The actual warning can be issued for code
which looks very different from anything the user actually wrote.
Translating back to the problem in the user code can be complicated.
I don't think gcc is going to be able to do that translation.


While this is absolutely true, think about what you're saying here.   
Roughly categorized, there are two cases that happen:


1. The problem is relatively simple and doesn't require deep analysis  
to identify and explain to the user.
2. The problem is subtle, requiring multiple levels of optimizer to  
interact correctly to find the problem.


In case #1, you can have good location info and use cheap techniques  
for finding the problem.  If you do this and tell the user, they are  
likely to understand and fix the problem.


In case #2, even if you find an obscure (and real!) bug, without  
*really* good location info, there is a very low likelihood that the  
user will understand it.  It's more likely that they will turn off the  
warning or file a GCC bug.


-Chris

Re: Could someone please check if FSF received papers for Intel engineers?

[Andrew Pinski]

On Thu, Mar 13, 2008 at 2:38 PM, J.C. Pizarro <[EMAIL PROTECTED]> wrote:
>  Ohh, contributions aren't accepted because they had not assigned
>  the copyrights to FSF.
>
>  Then, are we not doing it due to "GPL license" instead of
>  "GPL licence + own FSF's policy"?

No, please go and understand why the FSF likes to have the copyright
of the file.  It is easier for them to defend where the sources came
from when it comes to patents and copyright disputes.

-- Pinski

Re: Could someone please check if FSF received papers for Intel engineers?

[J.C. Pizarro]

On 2008/3/13, Andrew Pinski <[EMAIL PROTECTED]> wrote:
> On Thu, Mar 13, 2008 at 2:38 PM, J.C. Pizarro <[EMAIL PROTECTED]> wrote:
>  >  Ohh, contributions aren't accepted because they had not assigned
>  >  the copyrights to FSF.
>  >
>  >  Then, are we not doing it due to "GPL license" instead of
>  >  "GPL licence + own FSF's policy"?
>
>
> No, please go and understand why the FSF likes to have the copyright
>  of the file.  It is easier for them to defend where the sources came
>  from when it comes to patents and copyright disputes.
>
>
>  -- Pinski

Patents? => It says in the seventh term of GPL.
Copyrightes => From authors's contributions, why FSF only?

Re: [RFC] GCC caret diagnostics

[Ian Lance Taylor]

Chris Lattner <[EMAIL PROTECTED]> writes:

> On Mar 13, 2008, at 11:37 AM, Ian Lance Taylor wrote:
>>  As you know the optimizers can pull together information
>> from all over the place.  The actual warning can be issued for code
>> which looks very different from anything the user actually wrote.
>> Translating back to the problem in the user code can be complicated.
>> I don't think gcc is going to be able to do that translation.
>
> While this is absolutely true, think about what you're saying here.
> Roughly categorized, there are two cases that happen:
>
> 1. The problem is relatively simple and doesn't require deep analysis
> to identify and explain to the user.
> 2. The problem is subtle, requiring multiple levels of optimizer to
> interact correctly to find the problem.
>
> In case #1, you can have good location info and use cheap techniques
> for finding the problem.  If you do this and tell the user, they are
> likely to understand and fix the problem.
>
> In case #2, even if you find an obscure (and real!) bug, without
> *really* good location info, there is a very low likelihood that the
> user will understand it.  It's more likely that they will turn off the
> warning or file a GCC bug.

Yes.

We implemented the undefined overflow warning because some people were
concerned about gcc's behaviour with regard to optimizing based on
undefined overflow.  That is, it was done at user request.  Users who
do not know how to deal with the warning should correctly turn it off
and use -fwrapv to avoid the problem in their code.  In fact, in
general I think that is true even without really good location info.

As I said, right now we have a statement location for these sorts of
warnings.  The question here is how much more helpful it will be, in
the simple cases, if the warning can point to a precise location
within the statement.

I'm a little bit skeptical because I don't think that for most people
this warning is nearly incomprehensible (the warning was put in at
user request, under the threat of having autoconf disable some gcc
optimizations if the warning was not present).

That said, I'm certainly not opposed to doing some work to get better
location information if possible.  In the tuples world we have to
think seriously about whether we want to carry that additional
location information through the middle-end.  It's a real cost; is it
worth it?

Ian

Re: Could someone please check if FSF received papers for Intel engineers?

[Daniel Jacobowitz]

People keep asking you to take this off the list.  Please do so.

-- 
Daniel Jacobowitz
CodeSourcery

Re: [RFC] GCC caret diagnostics

[Joe Buck]

On Thu, Mar 13, 2008 at 02:39:25PM -0700, Chris Lattner wrote:
> On Mar 13, 2008, at 11:37 AM, Ian Lance Taylor wrote:
> > As you know the optimizers can pull together information
> >from all over the place.  The actual warning can be issued for code
> >which looks very different from anything the user actually wrote.
> >Translating back to the problem in the user code can be complicated.
> >I don't think gcc is going to be able to do that translation.
> 
> While this is absolutely true, think about what you're saying here.   
> Roughly categorized, there are two cases that happen:
> 
> 1. The problem is relatively simple and doesn't require deep analysis  
> to identify and explain to the user.
> 2. The problem is subtle, requiring multiple levels of optimizer to  
> interact correctly to find the problem.
> 
> In case #1, you can have good location info and use cheap techniques  
> for finding the problem.  If you do this and tell the user, they are  
> likely to understand and fix the problem.
> 
> In case #2, even if you find an obscure (and real!) bug, without  
> *really* good location info, there is a very low likelihood that the  
> user will understand it.  It's more likely that they will turn off the  
> warning or file a GCC bug.

In the case of an unitialized variable, accurate warnings require good
dataflow analysis that can handle correlated variables; something like
gated SSA might be needed to prevent false warnings about paths that
are infeasible because of flags in the code.  But once the issue is
found, simply naming the variable and the file/line where it is declared
suffices to inform the user.

gcc-4.3-20080313 is now available

[gccadmin]

Snapshot gcc-4.3-20080313 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20080313/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 4.3 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_3-branch 
revision 133196

You'll find:

gcc-4.3-20080313.tar.bz2  Complete GCC (includes all of below)

gcc-core-4.3-20080313.tar.bz2 C front end and core compiler

gcc-ada-4.3-20080313.tar.bz2  Ada front end and runtime

gcc-fortran-4.3-20080313.tar.bz2  Fortran front end and runtime

gcc-g++-4.3-20080313.tar.bz2  C++ front end and runtime

gcc-java-4.3-20080313.tar.bz2 Java front end and runtime

gcc-objc-4.3-20080313.tar.bz2 Objective-C front end and runtime

gcc-testsuite-4.3-20080313.tar.bz2The GCC testsuite

Diffs from 4.3-20080306 are available in the diffs/ subdirectory.

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

Re: Official GCC git repository

[Ben Elliston]

> David Woodhouse wrote:

> > To be honest, I find it weird that Subversion even exists. Precisely
> > because it _is_ so close to what people were using before, as you point
> > out. I've never really understood why anyone would bother to change from
> > CVS to SVN -- it just seems to be part of the 'one VCS per project'
> > insanity.

I remember seeing a talk by Jim Blandy on Subversion around 2001.  At
the time, the CVS-using community in the audience were (vocally)
impressed by what a huge step forward it was in addressing the
limitations of CVS.

There are indeed other choices out there these days, but at the time it
began, Subversion made a lot of sense.

Ben

Re: Official GCC git repository

[Bernardo Innocenti]

Daniel Berlin wrote:
> Bernardo Innocenti wrote:

 Fair enough.  I hereby volunteer to setup and maintain the git
 mirror on gcc.gnu.org if someone provides me a shell account
 there.


Email [EMAIL PROTECTED] and ask what kind of sponsorship they want
to require for a shell account (for write access to repositories, we
usually only require 1 sponsor, but these do not give you shell
access).


As stated above, I'd like to request shell access to gcc.gnu.org to 
setup a git mirror of the GCC svn repository.  I'd also suggest Harvey 
Harrison as a co-maintainer of the mirror, as he helped setting it up on 
git.infradead.org.


At this time, the repository and git-svn metadata take up 2.5GB of disk 
space.  CPU usage is minimal.  I will just have to install a shell 
script running from my user crontab.


We don't require root access for ordinary maintenance, but someone would 
have to install and configure at least git-daemon and gitweb to make the 
mirror publicly accessible.


If it seems too much hassle for the benefit, we'll keep going with the 
existing git mirror on infradead.org, but I feel it would better serve 
our users and developers to at least mention it as an official mirror on 
our web site.




I am happy to sponsor you if it helps.


Thanks, Daniel!

--
 \___/
 |___|   Bernardo Innocenti - http://www.codewiz.org/
  \___\  One Laptop Per Child - http://www.laptop.org/

Re: Official GCC git repository

[Angela Marie Thomas]

[EMAIL PROTECTED] wrote:

> Daniel Berlin wrote:
>  > Bernardo Innocenti wrote:
> >>  Fair enough.  I hereby volunteer to setup and maintain the git
> >>  mirror on gcc.gnu.org if someone provides me a shell account
> >>  there.
> > 
> > Email [EMAIL PROTECTED] and ask what kind of sponsorship they want
> > to require for a shell account (for write access to repositories, we
> > usually only require 1 sponsor, but these do not give you shell
> > access).
> 
> As stated above, I'd like to request shell access to gcc.gnu.org to 
> setup a git mirror of the GCC svn repository.  I'd also suggest Harvey 
> Harrison as a co-maintainer of the mirror, as he helped setting it up on 
> git.infradead.org.
> 
> At this time, the repository and git-svn metadata take up 2.5GB of disk 
> space.  CPU usage is minimal.  I will just have to install a shell 
> script running from my user crontab.
> 
> We don't require root access for ordinary maintenance, but someone would 
> have to install and configure at least git-daemon and gitweb to make the 
> mirror publicly accessible.
> 
> If it seems too much hassle for the benefit, we'll keep going with the 
> existing git mirror on infradead.org, but I feel it would better serve 
> our users and developers to at least mention it as an official mirror on 
> our web site.

If this happens and it needs to get backed up, I'll need to know where
it lives.  I just installed a beefier server in a colo for backups so
I have the space and bandwidth.

--Angela

Re: [RFC] GCC caret diagnostics

[Manuel López-Ibáñez]

On 13/03/2008, Joe Buck <[EMAIL PROTECTED]> wrote:
> On Thu, Mar 13, 2008 at 02:39:25PM -0700, Chris Lattner wrote:
>
> In the case of an unitialized variable, accurate warnings require good
>  dataflow analysis that can handle correlated variables; something like
>  gated SSA might be needed to prevent false warnings about paths that
>  are infeasible because of flags in the code.  But once the issue is
>  found, simply naming the variable and the file/line where it is declared
>  suffices to inform the user.

I would say that for me it is insufficient (and for those reporting
bugs in -Wuninitialized seems to be insufficient as well) to find out
why GCC thinks the variable may be used uninitialized. You typically
need to look to a dump of the SSA form to actually find out.

Anyway, I think we moved slightly off topic here. Getting the
locations right is in general a much complex task than simply
providing caret diagnostics that show whatever location we happen to
have at hand.

Cheers,

Manuel.

Re: [RFC] GCC caret diagnostics

[Ian Lance Taylor]

"Manuel López-Ibáñez" <[EMAIL PROTECTED]> writes:

> Anyway, I think we moved slightly off topic here. Getting the
> locations right is in general a much complex task than simply
> providing caret diagnostics that show whatever location we happen to
> have at hand.

But let's start with what we have, and see what happens.  We're
arguing about uncommon cases.

Ian

Re: [RFC] GCC caret diagnostics

[Manuel López-Ibáñez]

On 13/03/2008, Tom Tromey <[EMAIL PROTECTED]> wrote:
>
>  >> How about -fshow-caret instead of -fdiagnostics-show-caret?
>  >> (By analogy with -fshow-column.)
>
> Manuel> Well, we have -fdiagnostics-show-option and
>  Manuel> -fdiagnostics-show-location. So 2 versus 1. ;-) That said, I would
>  Manuel> also prefer -fshow-option and -fshow-location.
>
>  Yeah.  "diagnostics" is too long to type, and "ambiguously plural", if
>  you know what I mean.

Chris,

Does clang have a -fno-show-caret or -fno-diagnostics-show-caret
options? Compatibility with clang may incline the balance towards one
or another for me. If not, I think I will go for -fshow-caret.

Cheers,

Manuel.

Re: [RFC] GCC caret diagnostics

[Chris Lattner]

On Mar 13, 2008, at 4:58 PM, Manuel López-Ibáñez wrote:


On 13/03/2008, Tom Tromey <[EMAIL PROTECTED]> wrote:



How about -fshow-caret instead of -fdiagnostics-show-caret?
(By analogy with -fshow-column.)


Manuel> Well, we have -fdiagnostics-show-option and
Manuel> -fdiagnostics-show-location. So 2 versus 1. ;-) That said,  
I would

Manuel> also prefer -fshow-option and -fshow-location.

Yeah.  "diagnostics" is too long to type, and "ambiguously plural",  
if

you know what I mean.


Chris,

Does clang have a -fno-show-caret or -fno-diagnostics-show-caret
options? Compatibility with clang may incline the balance towards one
or another for me. If not, I think I will go for -fshow-caret.


clang has these two.  I think GCC has the second one already:

   -fno-caret-diagnostics  - Do not include source line and caret  
with diagnostics
   -fno-show-column- Do not include column number on  
diagnostics


-Chris

Re: dg-skip-if was Re: gcc 4.3.0 i386 default question

[Joseph S. Myers]

On Thu, 13 Mar 2008, Joel Sherrill wrote:

> > Also, if you use a multilib option in testing, that option goes on the
> > command line *after* the options specified in dg-options.  The tests may
> > need to use dg-skip-if to skip them if any CPU option other than the one
> > in the test is explicitly specified (so it would be tested if no explicit
> > -mcpu option is used, or if -mcpu=405 is the multilib option being
> > tested).
> >   
> 
> Are you thinking of something roughly like this?
> 
> /* { dg-skip-if "" { { !-mcpu=405 } } { "*" } { "" } } */

I'm thinking of

/* { dg-skip-if "" { *-*-* } { "-mcpu=*" } { "-mcpu=405" } } */

but I don't guarantee that will work as expected.  (There are some tests 
in gcc.target/cris skipping on "-march*", which seems similar.)

-- 
Joseph S. Myers
[EMAIL PROTECTED]

Re: Official GCC git repository

[Harvey Harrison]

On Thu, 2008-03-13 at 23:47 +0100, Bernardo Innocenti wrote:
> Daniel Berlin wrote:
>  > Bernardo Innocenti wrote:
> >>  Fair enough.  I hereby volunteer to setup and maintain the git
> >>  mirror on gcc.gnu.org if someone provides me a shell account
> >>  there.
> > 
> > Email [EMAIL PROTECTED] and ask what kind of sponsorship they want
> > to require for a shell account (for write access to repositories, we
> > usually only require 1 sponsor, but these do not give you shell
> > access).
> 
> As stated above, I'd like to request shell access to gcc.gnu.org to 
> setup a git mirror of the GCC svn repository.  I'd also suggest Harvey 
> Harrison as a co-maintainer of the mirror, as he helped setting it up on 
> git.infradead.org.
> 
> At this time, the repository and git-svn metadata take up 2.5GB of disk 
> space.  CPU usage is minimal.  I will just have to install a shell 
> script running from my user crontab.

Actually, the newer git-svn's finally switched metadata format, so once
I get done moving it over, it will be ~350MB of git data and 50MB or so
of git-svn metadata. (rev_db vs rev_map format)

Cheers,

Harvey

Re: Official GCC git repository

[Harvey Harrison]

On Thu, 2008-03-13 at 23:47 +0100, Bernardo Innocenti wrote:
> Daniel Berlin wrote:
>  > Bernardo Innocenti wrote:
> >>  Fair enough.  I hereby volunteer to setup and maintain the git
> >>  mirror on gcc.gnu.org if someone provides me a shell account
> >>  there.
> > 
> > Email [EMAIL PROTECTED] and ask what kind of sponsorship they want
> > to require for a shell account (for write access to repositories, we
> > usually only require 1 sponsor, but these do not give you shell
> > access).
> 
> As stated above, I'd like to request shell access to gcc.gnu.org to 
> setup a git mirror of the GCC svn repository.  I'd also suggest Harvey 
> Harrison as a co-maintainer of the mirror, as he helped setting it up on 
> git.infradead.org.

A few things I'd like to clean up if we move a copy over:

1) generate a author's file so the commits have better than just a login
name as the commiter/author.

2) change the layout so it can be cloned just like any other git repo


Cheers,

Harvey