Re: Target deprecations for 4.6

[David Edelsohn]

On Fri, Feb 11, 2011 at 9:15 PM, Joseph S. Myers
 wrote:

> I can't quite figure out what the score people are up to, but it doesn't
> appear to involve a simultaneously maintained set of upstream components
> that are usable together in their current upstream forms; they got Linux
> kernel support upstream in 2009 (and don't seem to have maintained it much
> since then), some time after they got GCC support upstream (and then
> stopped maintaining it).

The SCORE port was accepted and maintainers appointed with the
understanding that lack of maintenance would lead to rapid deprecation
and removal.

I would suggest directly sending a message to the last contacts and
any other contact email address for SCORE that the port must function
and test results posted or it will be deprecated and removed.  That
the GCC community needs to see action, not future promises.

- David

X32 psABI status

[H.J. Lu]

Hi,

We made lots of progresses on x32 pABI:

https://sites.google.com/site/x32abi/

1. Kernel interface with syscall is close to be finalized.
2. GCC x32 branch is stabilizing.
3. The Bionic C library works with the syscall kernel interface.

The next major milestone will be x32 glibc port.

-- 
H.J.

Release candidate for mpc-0.9 available

[Andreas Enge]

A release candidate for the next version 0.9 of mpc is available at
   http://www.multiprecision.org/mpc/download/mpc-0.9-rc2.tar.gz
We would be grateful if you could report any problems you experience
with installation, in particular on more exotic platforms.

The following excerpt of the NEWS file describes the changes since
release 0.8.2:
  - New functions:
- mpc_set_dc, mpc_set_ldc, mpc_get_dc, mpc_get_ldc for converting
  between mpc type variables and C variables of type double _Complex
  or long double _Complex
- mpc_sin_cos, computing simultaneously the sine and cosine
  - Speed-ups:
- mpc_pow_si through binary exponentiation
- mpc_pow_z when the exponent fits in a long
- mpc_tan through the use of mpc_sin_cos
  - Bug fixes:
- trigonometric functions: infinite loop due to overflow for large arguments
- exp: close to infinite loop for argument close to 0
- sqrt: close to infinite loop for argument close to 1
- add_si: replaced macro by function, since the macro evaluated the same
  expression twice
  - Logging feature for debugging:
  ./configure --enable-logging
  #include "mpc-log.h" instead of #include "mpc.h"
  - Minimally required library versions: gmp 4.3.2, mpfr 2.4.2

Andreas

Re: X32 psABI status

[Florian Weimer]

* H. J. Lu:

> We made lots of progresses on x32 pABI:
>
> https://sites.google.com/site/x32abi/
>
> 1. Kernel interface with syscall is close to be finalized.
> 2. GCC x32 branch is stabilizing.
> 3. The Bionic C library works with the syscall kernel interface.
>
> The next major milestone will be x32 glibc port.

It is a bit difficult to extract useful information from these
resources.

Is off_t 32 bits?  Why is the ia32 compatiblity kernel interface used?
I'm sure a lot of people want to get rid of that in cases where they
control the whole software stack.

Is stack alignment to 16 bytes beneficial for X32?

Re: X32 psABI status

[H.J. Lu]

On Sat, Feb 12, 2011 at 1:10 PM, Florian Weimer  wrote:
> * H. J. Lu:
>
>> We made lots of progresses on x32 pABI:
>>
>> https://sites.google.com/site/x32abi/
>>
>> 1. Kernel interface with syscall is close to be finalized.
>> 2. GCC x32 branch is stabilizing.
>> 3. The Bionic C library works with the syscall kernel interface.
>>
>> The next major milestone will be x32 glibc port.
>
> It is a bit difficult to extract useful information from these
> resources.

That is true. Contributions are more than welcome.

> Is off_t 32 bits?  Why is the ia32 compatiblity kernel interface used?

Yes.

> I'm sure a lot of people want to get rid of that in cases where they
> control the whole software stack.

That is debatable. The current thought is the x32 user space API
is the same as is ia32.  time_t is also an issue.

> Is stack alignment to 16 bytes beneficial for X32?
>

Even ia32 uses 16byte stack alignment and we will make it
official soon via an amendment to the i386 psABI.

-- 
H.J.

Re: X32 psABI status

[Matt Thomas]

On Feb 12, 2011, at 1:29 PM, H.J. Lu wrote:

> On Sat, Feb 12, 2011 at 1:10 PM, Florian Weimer  wrote:
>> * H. J. Lu:
>> 
>>> We made lots of progresses on x32 pABI:
>>> 
>>> https://sites.google.com/site/x32abi/
>>> 
>>> 1. Kernel interface with syscall is close to be finalized.
>>> 2. GCC x32 branch is stabilizing.
>>> 3. The Bionic C library works with the syscall kernel interface.
>>> 
>>> The next major milestone will be x32 glibc port.
>> 
>> It is a bit difficult to extract useful information from these
>> resources.
> 
> That is true. Contributions are more than welcome.
> 
>> Is off_t 32 bits?  Why is the ia32 compatiblity kernel interface used?
> 
> Yes.

off_t is not part of the psABI since it's OS dependent.

>> I'm sure a lot of people want to get rid of that in cases where they
>> control the whole software stack.
> 
> That is debatable. The current thought is the x32 user space API
> is the same as is ia32.  time_t is also an issue.

Any system call method is beyond the scope of the psABI since it's
OS dependent and user-code should never care.

gcc-4.6-20110212 is now available

[gccadmin]

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

This snapshot has been generated from the GCC 4.6 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 170092

You'll find:

 gcc-4.6-20110212.tar.bz2 Complete GCC (includes all of below)

  MD5=da7b101eb789f85c771ed4e4c7c68aa1
  SHA1=c5136111eee7af72b301119d465abd878bac7ff9

 gcc-core-4.6-20110212.tar.bz2C front end and core compiler

  MD5=fbf601786cc6aeb1a1936fcc8fbe3d10
  SHA1=59fac0d6cccba994cc089f287a6a2131c502fc29

 gcc-ada-4.6-20110212.tar.bz2 Ada front end and runtime

  MD5=bc9984ca0a089ada33d221b4544968fc
  SHA1=50f1abcc33aca767d7829152100ef9719c7c9e57

 gcc-fortran-4.6-20110212.tar.bz2 Fortran front end and runtime

  MD5=0a2b39216efd58cbdb7f44f10b9dc4e1
  SHA1=90ab693aa2bc68fb33c31e9a073a0f618f9f3850

 gcc-g++-4.6-20110212.tar.bz2 C++ front end and runtime

  MD5=b92e052422c59c15022538012d34d384
  SHA1=efa3d25a944253591781181c6fb80c5ded057432

 gcc-go-4.6-20110212.tar.bz2  Go front end and runtime

  MD5=79e1249200083e91c3da0bb7c5ea4e41
  SHA1=62641880da0921666073e8075a4813bbeabd3615

 gcc-java-4.6-20110212.tar.bz2Java front end and runtime

  MD5=4460ec1d71723ee8b93d808104f2f85a
  SHA1=10fef3aa04464cb6d9fca9aae0d3bfa80d7dbf95

 gcc-objc-4.6-20110212.tar.bz2Objective-C front end and runtime

  MD5=e29718c23e8b1637bbeec6843578604b
  SHA1=a7153548eeacf8c96f0603090d1477fc92edd3df

 gcc-testsuite-4.6-20110212.tar.bz2   The GCC testsuite

  MD5=139a7f8c19798918235b8f19190d83ff
  SHA1=0589ee2c4fbe99bc6b5b1f49a1ce93ae3869513a

Diffs from 4.6-20110205 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.6
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: [Mpc-discuss] Release candidate for mpc-0.9 available

[Brian Gladman]

From: Andreas Enge
Sent: Saturday, February 12, 2011 8:43 PM
To: mpc-disc...@lists.gforge.inria.fr ; gcc@gcc.gnu.org
Subject: [Mpc-discuss] Release candidate for mpc-0.9 available

A release candidate for the next version 0.9 of mpc is available at
  http://www.multiprecision.org/mpc/download/mpc-0.9-rc2.tar.gz
We would be grateful if you could report any problems you experience
with installation, in particular on more exotic platforms.

===
I recognise that MPC built with Visual Studio is beyond your officially 
supported environments but you may still be interested to know that, when 
built with Visual Studio 2010, MPC builds and passes all tests for both 
static and DLL libraries and for both win32 and x64 Windows systems.   The 
wider environment I used is:


MPIR: include 2.2.0, lib 2.2.0
MPFR: include 3.1.0-dev, lib 3.1.0-dev
MPC: include 0.9-rc2, lib 0.9-rc2

Congratulations to all on a first class library.

   Brian Gladman

Re: X32 psABI status

[H. Peter Anvin]

On 02/12/2011 01:10 PM, Florian Weimer wrote:
> Why is the ia32 compatiblity kernel interface used?

Because there is no way in hell we're designing in a second
compatibility ABI in the kernel (and it has to be a compatibility ABI,
because of the pointer size difference.)

-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

Question about static code analysis features in GCC

[sa...@hederstierna.com]

Hi

I would like to have some advice regarding static code analysis and GCC.
I've just reviewed several tools like Klocwork, Coverity, CodeSonar and 
PolySpace.
These tools offer alot of features and all tools seems to find different types 
of defects.
The tool that found most bugs on our code was Coverity, but it is also the most 
expensive tool.

But basically I would most like just to find very "simple" basic errors like 
NULL-dereferences and buffer overruns.
I attach a small example file with some very obvious errors like 
NULL-dereferences and buffer overruns.

This buggy file compiles fine though without any warnings at all with GCC as 
expected

gcc -o example example.c -W -Wall -Wextra

I tried to add checking with mudflap:

gcc -fmudflap -o example example.c -W -Wall -Wextra -lmudflap

Then I found all defects in run-time, but I had to run the program so I could 
not find all potential errors in compile-time.
Also Valgrind could be used to check run-time bugs, but I'm not 100% sure I can 
cover all execution paths in my tests (I also tried gcov).

I tried to analyze my example file with CLANG, then I found "uninitialized" 
issues and NULL-pointers, but not buffer overruns:

clang --analyze example.c
example.c:7:3: warning: Dereference of null pointer loaded from variable 'a'
example.c:41:3: warning: Undefined or garbage value returned to caller  

About NULL-checks and buffer-overruns, is there any possible path to get such 
checkers into a standard GCC, maybe in just some very limited level?
I've checked the "MyGCC" (http://mygcc.free.fr) patch on Graphite, but it has 
been rejected, could it be rewritten somehow as a standard opt_pass to just 
find NULL-derefs?

I've also checked TreeHydra in Mozilla project 
(https://developer.mozilla.org/en/Treehydra) that gives JavaScript interface to 
GIMPEL.
Is the GCC4.5.x plugin API something that is recommended to use to implement 
such features, is performance okey to not have it as a core opt-pass?

I'm willing to put some free time into this matter if it turns out its possible 
to add some tree SSA optimization pass that could find some limited set of 
errors.
Example given if some value is constant NULL and dereferenced, or some element 
if accessed outside a constant length buffer using a constant index.
What is your recommended path to move forward using GCC and basic static code 
analysis?

About un-initialized values I found some additional info, it seems to be hard 
to solve...
  http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18501
  http://lists.cs.uiuc.edu/pipermail/cfe-dev/2011-February/013170.html

Thanks and Best Regards
/Fredrik

--
#include 

// Example1: null pointer de-reference
int f1(void)
{
  int* a = NULL;
  *a = 1;
  return *a;
}

// Example2: buffer overrun global variable
char v2[1];
char* f2(void)
{
  v2[-1] = 1;
  v2[0]  = 1;
  v2[1]  = 1;
  return (char*)v2;
}

// Example3: buffer overrun local variable
int f3(void)
{
  char v3[1];
  v3[-1] = 1;
  v3[0]  = 1;
  v3[1]  = 1;
  return v3[-1] + v3[0] + v3[1] + v3[2];
}

// Example4: uninitialized memory access
int f4(void)
{
  char v4[1];
  return v4[0];
}

// Examples NULL dereference and buffer overruns
int main(void)
{
  int t1 = f1();
  printf("test1 %d\n", t1);

  void *t2 = f2();
  printf("test2 %08x\n", (unsigned int)t2);

  int t3 = f3();
  printf("test3 %d\n", t3);

  int t4 = f4();
  printf("test4 %d\n", t4);

  return 0;
}

Re: X32 psABI status

[Andrew Pinski]

On Sat, Feb 12, 2011 at 3:04 PM, H. Peter Anvin  wrote:
> On 02/12/2011 01:10 PM, Florian Weimer wrote:
>> Why is the ia32 compatiblity kernel interface used?
>
> Because there is no way in hell we're designing in a second
> compatibility ABI in the kernel (and it has to be a compatibility ABI,
> because of the pointer size difference.)

I think he is asking why not create a new ABI layer for the kernel
like it is done for n32 for MIPS.

-- Andrew

gcc 4.5.2-6 - internal compiler: Segmentation fault

[David C. Rankin]

Guys,

I need some help on what information will be wanted with the bug report 
for the
following Segmentation fault encountered when compiling Trinity on Arch Linux
with gcc 4.5.2-6? I haven't encountered a gcc segfault before, so I'm not quite
sure what will be needed. The error received was the following:

[18%] Building CXX object
kcontrol/konq/CMakeFiles/kcm_konq-module.dir/fontopts.cpp.o
cd /home/david/tbld/kdebase/src/kcontrol/konq && /usr/bin/c++
-Dkcm_konq_module_EXPORTS -DHAVE_CONFIG_H -DUSE_QT3 -DQT_NO_ASCII_CAST
-DQT_CLEAN_NAMESPACE -DQT_NO_STL -DQT_NO_COMPAT -DQT_NO_TRANSLATION
-DQT_THREAD_SUPPORT -D_REENTRANT -march=i686 -mtune=generic -O2 -pipe -include
tqt.h -fPIC -I/home/david/tbld/kdebase/src/kcontrol/konq
-I/home/david/tbld/kdebase/src -I/home/david/tbld/kdebase/libkonq
-I/opt/trinity/include -I/opt/qt/include -I/opt/qt/include/tqt   -o
CMakeFiles/kcm_konq-module.dir/fontopts.cpp.o -c
/home/david/tbld/kdebase/kcontrol/konq/fontopts.cpp
In file included from /home/david/tbld/kdebase/kcontrol/konq/fontopts.cpp:387:0:
/home/david/tbld/kdebase/src/kcontrol/konq/fontopts.moc: In member function
virtual void KonqFontOptions::load(bool):
/home/david/tbld/kdebase/src/kcontrol/konq/fontopts.moc:136:93: internal
compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[2]: *** [kcontrol/konq/CMakeFiles/kcm_konq-module.dir/fontopts.cpp.o] 
Error 1
make[2]: Leaving directory `/home/david/tbld/kdebase/src'
make[1]: *** [kcontrol/konq/CMakeFiles/kcm_konq-module.dir/all] Error 2
make[1]: Leaving directory `/home/david/tbld/kdebase/src'
make: *** [all] Error 2
Aborting...

I figured if I knew what was needed before opening the bug it would cut 
down on
the need-info requests. Thanks.

-- 
David C. Rankin, J.D.,P.E.

Re: gcc 4.5.2-6 - internal compiler: Segmentation fault

[Eric Botcazou]

>   I figured if I knew what was needed before opening the bug it would cut
> down on the need-info requests. Thanks.

The instructions are available on the http://gcc.gnu.org/bugs/ page.

-- 
Eric Botcazou

Re: X32 psABI status

[Matt Thomas]

On Feb 12, 2011, at 7:02 PM, Andrew Pinski wrote:

> On Sat, Feb 12, 2011 at 3:04 PM, H. Peter Anvin  wrote:
>> On 02/12/2011 01:10 PM, Florian Weimer wrote:
>>> Why is the ia32 compatiblity kernel interface used?
>> 
>> Because there is no way in hell we're designing in a second
>> compatibility ABI in the kernel (and it has to be a compatibility ABI,
>> because of the pointer size difference.)
> 
> I think he is asking why not create a new ABI layer for the kernel
> like it is done for n32 for MIPS.

The kernel syscall ABI needs to be able to be pass 64-bit quantities
in a single register (since that's what the calling ABI is capable
of doing but I don't think the ia32 kernel interface can do)?

Maybe it's me, but I expected X32 to be the X86-64 ABI with 32-bit longs
and pointers (converted to 64-bit arguments when passed in register or
on the stack).  That allows the same syscall argument marshalling that
currently exists but just need a different set of syscall vectors.