headers
Galathaea | 1 Mar 2005 01:44
Picon
Favicon

binary reproducibility and c++ default allocators


GCC team,

At work, we use version 2.96 with Redhat Linux 7.3.  We work in an embedded industry that requires complete
binary reproducibility (BR) of compiles so regulators may verify the source code reproduces the images
they are given.  Consequently, we avoid anonymous namespaces and other known violators of reproducibility.

We have currently found a strange occurance BR breakage.  We have a file that is completely empty save for
includes of headers (many headers through one main include).  The .o produced differs each build.  Tracing
the translation unit through the build process has shown that the assembly output differs on a few lines
related to allocators.

They have the format:

.stabs "_GLOBAL_.I._S_chunk_alloc__t24__default_alloc_template2b1i0UiRiSomefilepath.cppLyTUed:f(0,21)",36,0,1256,_GLOBAL_.I._S_chunk_alloc__t24__default_alloc_template2b1i0UiRiSomefilepath.cppLyTUed

        .type    _GLOBAL_.I._S_chunk_alloc__t24__default_alloc_template2b1i0UiRiSomefilepath.cppLyTUed, <at> function

_GLOBAL_.I._S_chunk_alloc__t24__default_alloc_template2b1i0UiRiSomefilepath.cppLyTUed:

This issue appears above some assembly that sets up a stack frame, calls
__static_initialization_and_destruction_0, then resets the stack frame and returns, but I am not sure
if that is relevant (I found some older messages which approached somewhat unrelated issues with static
template members which made me think mentioning it might be helpful).

My main question is concerning the Somefilepath.cpp (fictitious here) that points to the compile path of
the almost empty cpp and, in particular, the "LyTUed" sequence appended to the end.  That is the sequence
which differs in each compile.  

I am trying to find out what is being done to cause this code to be generated so we know what to avoid in the
(Continue reading)

Permalink | Reply | 0 comments |
headers
Poburinnaia, Nina | 1 Mar 2005 13:40
Picon
Favicon

kernels appended "64" to __NR_pread and __NR_pwrite

GCC team,
Could you please inform: did the kernels (2.6.x) append "64" to
__NR_pread and __NR_pwrite on Linux ia32?  Is the adding "64" a planned
change? Or maybe a temporal change? Or maybe a bug and it will be fixed?
Thank you very much.

Details:
On machine Linux version 2.6.5-7.111.5lxset2-smp (gcc version 3.3.3
(SuSE Linux))  i686:
> cat /usr/include/bits/syscall.h |grep _pread
#define SYS_pread64 __NR_pread64
> cat /usr/include/bits/syscall.h |grep _pwrite
#define SYS_pwrite64 __NR_pwrite64

On machine Linux version 2.4.21-9.0.1.ELsmp (gcc version 3.2.3 20030502
(Red Hat Linux 3.2.3-26))   i686:
$ cat /usr/include/bits/syscall.h |grep _pread
#define SYS_pread __NR_pread
$ cat /usr/include/bits/syscall.h |grep _pwrite
#define SYS_pwrite __NR_pwrite
Permalink | Reply | 0 comments |
headers
Khem Raj | 1 Mar 2005 20:28

mcount versus _mcount

Hi

I am compiling a small example with -pg option with GCC cross-compiler 
for ARM . it generated refrence to mcount but with ppc7xx cross gcc it 
generated refrence to _mcount
why this difference is there?
compilers are created using same sources from 3.4.3 branch

TIA

Khem
Permalink | Reply | 0 comments |
headers
Khem Raj | 1 Mar 2005 20:35

GCC for xscale big-endian gives error: register specified for '__r1' isn't suitable for data type

Hi

When compiling the following example with gcc with xscale big endian I 
am getting following error.

test.c: In function `foo':
test.c:6: error: register specified for '__r1' isn't suitable for data type
test.c:6: error: register name given for non-register variable '__r1'

typedef unsigned long long u64;
int foo(unsigned long arg)
{
  u64 ullval = 0;
  const register typeof(*((u64 *)arg)) __r1 asm("r1") = (ullval << 9);
  return 0;
}

But the same example compiles fine with xscale little endian gcc.

However if I use r0 instead of r1 then the program compiles fine on both 
big and little endian.

Why is error happening and what is the right way to code the above

Thanks for your help

-Khem
Permalink | Reply | 1 comment |
headers
Khem Raj | 1 Mar 2005 20:37

Re: GCC for xscale big-endian gives error: register specified for '__r1' isn't suitable for data type

I am using gcc 3.4.3 branch

Khem Raj wrote:

> Hi
>
> When compiling the following example with gcc with xscale big endian I 
> am getting following error.
>
> test.c: In function `foo':
> test.c:6: error: register specified for '__r1' isn't suitable for data 
> type
> test.c:6: error: register name given for non-register variable '__r1'
>
>
>
> typedef unsigned long long u64;
> int foo(unsigned long arg)
> {
>  u64 ullval = 0;
>  const register typeof(*((u64 *)arg)) __r1 asm("r1") = (ullval << 9);
>  return 0;
> }
>
>
>
> But the same example compiles fine with xscale little endian gcc.
>
> However if I use r0 instead of r1 then the program compiles fine on 
> both big and little endian.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Galathaea | 2 Mar 2005 00:19
Picon
Favicon

Re: binary reproducibility and c++ default allocators


galathaea wrote:

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-

At work, we use version 2.96 with Redhat Linux 7.3.  We work in

an embedded industry that requires complete binary

reproducibility (BR) of compiles so regulators may verify the

source code reproduces the images they are given.

Consequently, we avoid anonymous namespaces and other known

violators of reproducibility.

We have currently found a strange occurance BR breakage.  We

have a file that is completely empty save for includes of

headers (many headers through one main include).  The .o

produced differs each build.  Tracing the translation unit

through the build process has shown that the assembly output

differs on a few lines related to allocators.

They have the format:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jay Foster | 2 Mar 2005 02:25
Favicon

GCC 3.4.3 Problem

I am using GCC to compile code for an arm-elf target, and have recently
changed from GCC 3.2.1 to GCC 3.4.3.  GCC is now generating a stack frame
that is about 14KB larger in one of my functions.  I have examined the code
carefully, and cannot see why this is so.

With GCC 3.2.1, the stack frame was about 1800 bytes.  With GCC 3.4.3, the
stack frame is now > 16KB.  Same source code.

Has anyone seen this kind of behavior?  I compiled the code with the '-v
-save-temps' option and examined the assembly code.  I cannot see where the
code even accesses any of the extra stack frame area.  Is there a compiler
option to generate a function stack map?

Thanks.
Jay
Permalink | Reply | 0 comments |
headers
Simeon Nifos | 2 Mar 2005 12:52
Picon
Favicon

compiling gcc-3.4.3 on a AMD quad OPTERON

I couldn't compile gcc-3.4.3 from scratch! I followed
the same procedure I am following up for years. It
stopped because it coulnd't find in my SuSE 9.2 tree
the file crti.o which does exist in /usr/lib64. It
couldn't find it though and the compilation stopped. 
That problem was solved when I installed gcc32
compatibility libraries from an FTP mirror of SuSE 9.2
x86_64. The compilation went on and I was very happy
to see that I can compile c++ programs. 

I was not so happy though when I realized that those 
programs I compiled successfully didn't run because
they couldn't load libstdc++.so.6. I could only run
statically linked programs! So what can I do for
that???

Thanks in advance!
Simeon N.

	
		
__________________________________ 
Celebrate Yahoo!'s 10th Birthday! 
Yahoo! Netrospective: 100 Moments of the Web 
http://birthday.yahoo.com/netrospective/
Permalink | Reply | 0 comments |
headers
moreau francis | 2 Mar 2005 14:01
Picon
Favicon

Basic code optimisation

Hi,

I need your help because I can't make GCC (3.4.2 with
-O2 option) optimize a simple case.
Here it is:

"""
static const struct my_struct {
    const int a;
    const int b;
} foo = { .a = 2, .b = 3};

int main(int argc, char **argv)
{
     int volatile tmp;

     tmp = foo.a * foo.b;

     return 0;
}
"""

As you notice every things are constants, so GCC
need not to generate a "imult opcode".
Equivalent code should look like:

"""
....

int main(int argc, char **argv)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Stephen Torri | 2 Mar 2005 15:50

Re: gcc build

On Wed, 2005-03-02 at 10:57 +0100, Alfredo Buttari wrote:
> Hi,
> I found this post from you:
> 
> http://gcc.gnu.org/ml/gcc-help/2005-02/msg00099.html
> 
> did you finally solve the problem? I have exactly the same problem and 
> have no idea on how to solve it.
> Can tou please help me?

I am sorry but I cannot remember what I did. It must not be that
important. I have posted your message to the general gcc-help mailing
list. Its a good place to start with build or usage problems for gcc.
You can join up at gcc.gnu.org

Stephen
Permalink | Reply | 1 comment |

Gmane