# core-i7 cflags not working for alienware m15x [/SOLVED]

## dustfinger

I have an Alienware m15x. The link shows the relevant hardware specs. I just did a stage3 no-multilib install with with CONFIG_IA32_EMULATION not set. My CFLAGS were as follows:

```
CFLAGS="-march=native -02 -pipe"

CHOST="x86_64-pc-linux-gnu"

MAKEOPTS="-j5"

```

gcc-4.6.3 supports -march corei7

So after building the system and world I had gcc-4.5.4 installed. I then unmasked gcc-4.6.3 and emerged it. I followed the gcc upgrade guide and selected gcc-4.6.3 as active. Next I changed the CFLAGS to:

```
CFLAGS="-march=corei7 -02 -pipe"
```

I then ran:

```

# emerge -e system && emerge -e system && emerge -e world && emerge -e world

```

When it got to building gcc-4.5.4 it failed. config.log for libgcc complained under Core Tests that:

```
error: bad value (corei7) for -march= switch
```

I know that I can put -march=native back and the system will attempt to use the cpu flags that most closely match my architecture, but it seems to me that corei7 flag should have worked for my system. According to gcc.gnu.org:

```
corei7

    Intel Core i7 CPU with 64-bit extensions, MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1 and SSE4.2 instruction set support.
```

Any thoughts as to why corei7 did not work in my case? What is the correct cflags for my particular cpu if not core-i7. For now I am going to rebuild with native.

sincerely,

dustfinger

----------

## ppurka

IIRC, gcc gets built twice. First, it gets built with the already installed gcc, and then it gets built with the newly built gcc. So, if you are right about 4.5 not supporting corei7, it will fail in the second phase since it has no support for corei7.

----------

## dustfinger

Hi ppurka,

Thank you for the reply. I was wondering if that was happening, but I am not convinced that it is. Only one gcc can be active:

```

 $ gcc-config -l

 [1] x86_64-pc-linux-gnu-4.5.4

 [2] x86_64-pc-linux-gnu-4.6.3 *

```

So I would expect that both gcc versions would compile via the active x86_64-pc-linux-gnu-gcc-4.6.3. The reason being is that I know you can build system/world with only one gcc installed, so that one gcc must build itself.

Would there be anyway to confirm in the logs what version of gcc was running during the failure? Everywhere I look the logs seem to just refer to the gcc command being run, but not the version of the gcc being run. I suppose I could always try to emerge -C gcc 4.5.4 and then build again with the corei7 cflags. I will have to wait until later today to do that though. My system is still building and I am heading out the door for the day now.

Am I right, isn't it possible to build system/world with only one version of gcc installed. Shouldn't only the active version build both installed versions of gcc in my case?

Sincerely,

dustfinger

----------

## ppurka

What I meant is the the built gcc rebuilds itself. So, the process would be

1. gcc-4.6 builds gcc-4.5 with corei7 flag

2. NOTE: gcc-4.5 is not installed yet, only built in /var/tmp/portage

3. the gcc-4.5 that is now already built and resides in /var/tmp/portage, now builds itself again with corei7 flag

4. if the compile is successful, then the final binaries are installed in /usr

This is my understanding of the compilation process of gcc. The Gentoo overlords - feel free to correct me if I am wrong.   :Razz: 

----------

## dustfinger

Hi ppurka,

I unmerged gcc-4.5.4, set march to corei7 then rebuilt system/world twice with success. I am still confused as to why gcc-4.5.4 builds itself when gcc-4.6.3 is the active gcc, but I guess I need to read up on the gcc build process to understand. Thank you for your insight.

Sincerely,

dustfinger

----------

