Re: [PATCH 1/3] Remove support for obsolete x86 -malign-foo options

On 05/06/2017 09:20 AM, Uros Bizjak wrote: On Tue, Apr 18, 2017 at 8:30 PM, Denys Vlasenko <dvlas...@redhat.com> wrote: 2017-04-18 Denys Vlasenko <dvlas...@redhat.com> * config/i386/i386-common.c (ix86_handle_option): Remove support for obsolete -malign-loops, -

Re: [PATCH 0/3] Extend -falign-FOO=N to N[,M[,N2[,M2]]] version 8

On 04/18/2017 08:30 PM, Denys Vlasenko wrote: These patches are for this bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66240 "RFE: extend -falign-xyz syntax" Ping.

[PATCH 3/3] Extend -falign-FOO=N to N[,M[,N2[,M2]]]

ns=N. No change from past behavior: Tested that "-falign-functions" uses an arch-dependent alignment. Tested that "-O2" uses an arch-dependent alignment. Tested that "-O2 -falign-functions=N" uses explicitly given alignment. 2017-04-18 Denys Vlasenko <dvlas...@

[PATCH 1/3] Remove support for obsolete x86 -malign-foo options

2017-04-18 Denys Vlasenko <dvlas...@redhat.com> * config/i386/i386-common.c (ix86_handle_option): Remove support for obsolete -malign-loops, -malign-jumps and -malign-functions options. * config/i386/i386.opt: Likewise. Index: gcc/common/config/i386/i386-co

[PATCH 2/3] Temporary remove "at least 8 byte alignment" code from x86

quot;.p2align 3" is not emitted. This behavior will be implemented differently by the next patch. The new SUBALIGN_LOG define will be used by the next patch. While we are here, avoid generating ".p2align N,,2^N-1" - it is functionally equivalent to ".p2align N". In this case, use

[PATCH 0/3] Extend -falign-FOO=N to N[,M[,N2[,M2]]] version 8

These patches are for this bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66240 "RFE: extend -falign-xyz syntax" An extended explanation is in commit message of patch 3. The test program: int g(); int f(int i) { i *= 3; while (--i > 100) { L1:if (g()) goto L1;

Re: [PATCH 3/3] Extend -falign-FOO=N to N[,M[,N2[,M2]]]

On 04/17/2017 09:54 PM, Sandra Loosemore wrote: @item -falign-functions @itemx -falign-functions=@var{n} +@itemx -falign-functions=@var{n},@var{m} +@itemx -falign-functions=@var{n},@var{m},@var{n2} +@itemx -falign-functions=@var{n},@var{m},@var{n2},@var{m2} @opindex falign-functions

[PATCH 3/3] Extend -falign-FOO=N to N[,M[,N2[,M2]]]

ns=N. No change from past behavior: Tested that "-falign-functions" uses an arch-dependent alignment. Tested that "-O2" uses an arch-dependent alignment. Tested that "-O2 -falign-functions=N" uses explicitly given alignment. 2016-09-27 Denys Vlasenko <dvlas...@

[PATCH 2/3] Temporary remove "at least 8 byte alignment" code from x86

quot;.p2align 3" is not emitted. This behavior will be implemented differently by the next patch. The new SUBALIGN_LOG define will be used by the next patch. While we are here, avoid generating ".p2align N,,2^N-1" - it is functionally equivalent to ".p2align N". In this case, use

[PATCH 1/3] Remove support for obsolete x86 -malign-foo options

2016-09-27 Denys Vlasenko <dvlas...@redhat.com> * config/i386/i386-common.c (ix86_handle_option): Remove support for obsolete -malign-loops, -malign-jumps and -malign-functions options. * config/i386/i386.opt: Likewise. Index: gcc/common/config/i386/i386-co

[PATCH 0/3] Extend -falign-FOO=N to N[,M[,N2[,M2]]] version 7

These patches are for this bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66240 "RFE: extend -falign-xyz syntax" An extended explanation is in commit message of patch 3. The test program: int g(); int f(int i) { i *= 3; while (--i > 100) { L1:if (g()) goto L1;

[PATCH 3/3] Extend -falign-FOO=N to N[,M[,N2[,M2]]]

ns=N. No change from past behavior: Tested that "-falign-functions" uses an arch-dependent alignment. Tested that "-O2" uses an arch-dependent alignment. Tested that "-O2 -falign-functions=N" uses explicitly given alignment. 2016-09-27 Denys Vlasenko <dvlas...@

[PATCH 0/3] Extend -falign-FOO=N to N[,M[,N2[,M2]]] version 4

These patches are for this bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66240 "RFE: extend -falign-xyz syntax" The test program: int g(); int f(int i) { i *= 3; while (--i > 100) { L1:if (g()) goto L1; if (g()) goto L2; } return

[PATCH 2/3] Temporary remove "at least 8 byte alignment" code from x86

quot;.p2align 3" is not emitted. This behavior will be implemented differently by the next patch. The new SUBALIGN_LOG define will be used by the next patch. While we are here, avoid generating ".p2align N,,2^N-1" - it is functionally equivalent to ".p2align N". In this case, use

[PATCH 1/3] Remove support for obsolete x86 -malign-foo options

2016-09-27 Denys Vlasenko <dvlas...@redhat.com> * config/i386/i386-common.c (ix86_handle_option): Remove support for obsolete -malign-loops, -malign-jumps and -malign-functions options. * config/i386/i386.opt: Likewise. Index: gcc/common/config/i386/i386-co

Re: New option -flimit-function-alignment

On 10/11/2016 10:14 PM, Bernd Schmidt wrote: On 10/11/2016 04:23 PM, Denys Vlasenko wrote: This is better than current behavior, but this is not what I want. 15-byte function does not need to be aligned to 16 bytes on a machine with 128-byte L1I cachelines. It needs to be aligned to 128 bytes

Re: New option -flimit-function-alignment

On 10/11/2016 04:11 PM, Bernd Schmidt wrote: Denys has submitted some patches to add more capabilities to the -falign-* options, but these still have some issues, and the original ideas seems to have been to allow for large alignments without over-aligning small functions. The following patch

Re: [PATCH 3/3] Extend -falign-FOO=N to N[,M[,N2[,M2]]]

On 10/06/2016 11:47 AM, Bernd Schmidt wrote: On 09/30/2016 07:54 PM, Denys Vlasenko wrote: +struct target_flag_state { + /* Each falign-foo can generate up to two levels of alignment: + -falign-foo=N,M[,N2,M2] */ + struct align_flags x_align_loops[2]; + struct align_flags x_align_jumps

[PATCH 2/3] Temporary remove "at least 8 byte alignment" code from x86

quot;.p2align 3" is not emitted. This behavior will be implemented differently by the next patch. The new SUBALIGN_LOG define will be used by the next patch. While we are here, avoid generating ".p2align N,,2^N-1" - it is functionally equivalent to ".p2align N". In this case, use

[PATCH 3/3] Extend -falign-FOO=N to N[,M[,N2[,M2]]]

ns=N. No change from past behavior: Tested that "-falign-functions" uses an arch-dependent alignment. Tested that "-O2" uses an arch-dependent alignment. Tested that "-O2 -falign-functions=N" uses explicitly given alignment. 2016-09-27 Denys Vlasenko <dvlas...@

[PATCH 0/3] Extend -falign-FOO=N to N[,M[,N2[,M2]]] version 4

These patches are for this bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66240 "RFE: extend -falign-xyz syntax" The test program: int g(); int f(int i) { i *= 3; while (--i > 100) { L1:if (g()) goto L1; if (g()) goto L2; } return

[PATCH 1/3] Remove support for obsolete x86 -malign-foo options

2016-09-27 Denys Vlasenko <dvlas...@redhat.com> * config/i386/i386-common.c (ix86_handle_option): Remove support for obsolete -malign-loops, -malign-jumps and -malign-functions options. * config/i386/i386.opt: Likewise. Index: gcc/common/config/i386/i386-co

Re: [PATCH 2/2] Extend -falign-FOO=N to N[,M[,N2[,M2]]]

On 09/30/2016 01:20 PM, Bernd Schmidt wrote: On 09/29/2016 07:32 PM, Denys Vlasenko wrote: On 09/29/2016 04:45 PM, Bernd Schmidt wrote: On 09/28/2016 02:57 PM, Denys Vlasenko wrote: - /* Comes from final.c -- no real reason to change it. */ -#define MAX_CODE_ALIGN 16 - case

Re: [PATCH 2/2] Extend -falign-FOO=N to N[,M[,N2[,M2]]]

On 09/29/2016 07:32 PM, Denys Vlasenko wrote: +#ifdef SUBALIGN_LOG We want to avoid adding new #defines; existing ones are being converted to target hooks. I suspect the best way is to record whether an M value was specified, and override it in the x86 option_override if required. If that's

Re: [PATCH 2/2] Extend -falign-FOO=N to N[,M[,N2[,M2]]]

On 09/29/2016 04:45 PM, Bernd Schmidt wrote: On 09/28/2016 02:57 PM, Denys Vlasenko wrote: No change from past behavior: Tested that "-falign-functions" uses an arch-dependent alignment. Tested that "-O2" uses an arch-dependent alignment. Tested that "-O2 -falign-fun

[PATCH 2/2] Extend -falign-FOO=N to N[,M[,N2[,M2]]]

ested that "-O2" uses an arch-dependent alignment. Tested that "-O2 -falign-functions=N" uses explicitly given alignment. 2016-09-27 Denys Vlasenko <dvlas...@redhat.com> * common.opt (-falign-functions=): Accept a string instead of integer. (-falign-jumps=): Likew

[PATCH 0/2] Extend -falign-FOO=N to N[,M[,N2[,M2]]] version 4

These patches are for this bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66240 "RFE: extend -falign-xyz syntax" This is version 4 of the patch set. Changes since version 3: * Improved documentation in invoke.texi * Fixed x86-specific calculation of default N2 value: previous version was

[PATCH 1/2] Temporary remove "at least 8 byte alignment" code from x86

quot;.p2align 3" is not emitted. This behavior will be implemented differently by the next patch. The new SUBALIGN_LOG define will be used by the next patch. 2016-09-27 Denys Vlasenko <dvlas...@redhat.com> * config/i386/freebsd.h (ASM_OUTPUT_MAX_SKIP_ALIGN): Remove "If N is large, do

Re: [PATCH RESEND 2/2] Extend -falign-FOO=N to N[,M[,N2[,M2]]]

On 09/27/2016 01:53 PM, Bernd Schmidt wrote: On 09/26/2016 09:08 PM, Denys Vlasenko wrote: +@gccoptlist{-faggressive-loop-optimizations @gol +-falign-functions[=@var{n}[,@var{m},[@var{n}[,@var{m} @gol +-falign-jumps[=@var{n}[,@var{m}]] @gol +-falign-labels[=@var{n}[,@var{m}]] -falign-loops

[PATCH RESEND 2/2] Extend -falign-FOO=N to N[,M[,N2[,M2]]]

ested that "-O2" uses an arch-dependent alignment. Tested that "-O2 -falign-functions=N" uses explicitly given alignment. 2016-09-26 Denys Vlasenko <dvlas...@redhat.com> * common.opt (-falign-functions=): Accept a string instead of integer. (-falign-jumps=): Likew

[PATCH RESEND 1/2] Temporary remove "at least 8 byte alignment" code from x86

quot;.p2align 3" is not emitted. This behavior will be implemented differently by the next patch. 2016-09-26 Denys Vlasenko <dvlas...@redhat.com> * config/i386/freebsd.h (ASM_OUTPUT_MAX_SKIP_ALIGN): Remove "If N is large, do at least 8 byte alignment" code. * config/i386/g

[PATCH v3 2/2] Extend -falign-FOO=N to N[,M[,N2[,M2]]]

ested that "-O2" uses an arch-dependent alignment. Tested that "-O2 -falign-functions=N" uses explicitly given alignment. 2016-08-30 Denys Vlasenko <dvlas...@redhat.com> * common.opt (-falign-functions=): Accept a string instead of integer. (-falign-jumps=): Likew

[PATCH v3 1/2] Temporary remove "at least 8 byte alignment" code from x86

quot;.p2align 3" is not emitted. This behavior will be implemented differently by the next patch. 2016-08-30 Denys Vlasenko <dvlas...@redhat.com> * config/i386/freebsd.h (ASM_OUTPUT_MAX_SKIP_ALIGN): Remove "If N is large, do at least 8 byte alignment" code. * config/i386/g

Re: [PATCH] Extend -falign-FOO=N to N[,M]: the second number is max padding

On 08/15/2016 03:30 PM, Richard Biener wrote: On Mon, Aug 15, 2016 at 1:53 PM, Denys Vlasenko <dvlas...@redhat.com> wrote: On 08/15/2016 11:45 AM, Richard Biener wrote: Thus. For this CPU, alignment of loops to 8 bytes is wrong: it helps if it happens to align a loop to 16 bytes, but

Re: [PATCH] Extend -falign-FOO=N to N[,M]: the second number is max padding

On 08/15/2016 11:45 AM, Richard Biener wrote: Thus. For this CPU, alignment of loops to 8 bytes is wrong: it helps if it happens to align a loop to 16 bytes, but it may in fact hurt performance if it happens to align a loop to 16+8 bytes and this pushes loop's body end over the next 16-byte

Re: [PATCH] Extend -falign-FOO=N to N[,M]: the second number is max padding

On 08/12/2016 05:20 PM, Denys Vlasenko wrote: Yes, I know all that. Fetching is one thing. Loop cache is for instance another (more important) thing. Not aligning the loop head increases chance of the whole loop being split over more cache lines than necessary. Jump predictors also don't

[PATCH v2] Extend -falign-FOO=N to N[,M]: the second number is max padding

ing. Testing: tested that with -falign-functions=N (tried 8, 15, 16, 17...) the alignment directives are the same before and after the patch. Tested that -falign-functions=N,N (two equal paramenters) works exactly like -falign-functions=N. 2016-08-12 Denys Vlasenko <dvlas...@redhat.com> * co

[PATCH] Remove "at least 8 byte alignment" code from x86 targets

yBridge CPU did not reveal any performance difference for a tight loop which starts at byte 7 inside 64-byte cacheline, and the same loop at byte 8. 2016-08-12 Denys Vlasenko <dvlas...@redhat.com> * config/i386/freebsd.h (ASM_OUTPUT_MAX_SKIP_ALIGN): Remove "If N is

Re: [PATCH] Extend -falign-FOO=N to N[,M]: the second number is max padding

On 08/12/2016 04:28 PM, Michael Matz wrote: Hi, On Fri, 12 Aug 2016, Denys Vlasenko wrote: Have you tested the performance impact of your patch? Note that the macro you changed is used for function and code label alignment. So, unless I misunderstand something that means that if the large

Re: [PATCH] Extend -falign-FOO=N to N[,M]: the second number is max padding

On 08/12/2016 04:00 PM, Michael Matz wrote: On Thu, 11 Aug 2016, Denys Vlasenko wrote: This change makes it possible to align function to 64-byte boundaries *IF* this does not introduce huge amount of padding. Patch drops forced alignment to 8 if requested alignment is higher than 8: before

Re: [PATCH] Extend -falign-FOO=N to N[,M]: the second number is max padding

On 08/11/2016 10:59 PM, Andrew Pinski wrote: On Thu, Aug 11, 2016 at 1:49 PM, Denys Vlasenko <dvlas...@redhat.com> wrote: falign-functions=N is too simplistic. Ingo Molnar ran some tests and it looks on latest x86 CPUs, 64-byte alignment runs fastest (he tried many other possib

Re: [PATCH] Extend -falign-FOO=N to N[,M]: the second number is max padding

On 08/11/2016 10:49 PM, Denys Vlasenko wrote: falign-functions=N is too simplistic. This change makes it possible to align function to 64-byte boundaries *IF* this does not introduce huge amount of padding. This is my first submission to gcc-patches@gcc.gnu.org Please let me know if my patch

[PATCH] Extend -falign-FOO=N to N[,M]: the second number is max padding

falign-functions=N is too simplistic. Ingo Molnar ran some tests and it looks on latest x86 CPUs, 64-byte alignment runs fastest (he tried many other possibilites). However, developers are less than thrilled by the idea of a slam-dunk 64-byte aligning everything. Too much waste: On

Re: [musl] Re: Compiler support for erasure of sensitive data

On Wed, Sep 9, 2015 at 10:26 PM, Szabolcs Nagy wrote: > * Zack Weinberg [2015-09-09 15:03:50 -0400]: >> On 09/09/2015 02:02 PM, paul_kon...@dell.com wrote: >> >> On Sep 9, 2015, at 1:54 PM, David Edelsohn >> >> wrote: >> >> >> >> What level

Re: [musl] Compiler support for erasure of sensitive data

On Wed, Sep 9, 2015 at 6:36 PM, Zack Weinberg wrote: > The first, simpler problem is strictly optimization. explicit_bzero > can be optimized to memset followed by a vacuous use of the memory > region (generating no machine instructions, but preventing the stores > from being

Re: Why not contribute? (to GCC)

On Friday 23 April 2010 21:10, Richard Kenner wrote: I've happened to be looking at a number of other free-software projects recently (having nothing to do with compilers) and find the quality of the code ABSOLUTELY APALLING. That's because you didn't look at non-open code. It's no better.

Re: gcc will become the best optimizing x86 compiler

On Thursday 31 July 2008 11:36, Dave Korn wrote: Agner Fog wrote on 31 July 2008 07:14: Denys Vlasenko wrote: I tend to doubt that odd-byte aligned large memcpys are anywhere near typical. malloc and mmap both return well-aligned buffers (say, 8 byte aligned). Static and on-stack

Re: gcc will become the best optimizing x86 compiler

On Fri, Jul 25, 2008 at 9:08 AM, Agner Fog [EMAIL PROTECTED] wrote: Raksit Ashok wrote: There is a more optimized version for 64-bit: http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libc/amd64/gen/memcpy.s I think this looks similar to your implementation, Agner. Yes it is

Re: gcc will become the best optimizing x86 compiler

On Wed, Jul 30, 2008 at 5:57 PM, Denys Vlasenko [EMAIL PROTECTED] wrote: On Fri, Jul 25, 2008 at 9:08 AM, Agner Fog [EMAIL PROTECTED] wrote: Raksit Ashok wrote: There is a more optimized version for 64-bit: http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libc/amd64/gen/memcpy.s

Re: gcc will become the best optimizing x86 compiler

On Wednesday 30 July 2008 19:14, Agner Fog wrote: I agree that the OpenSolaris memcpy is bigger than necessary. However, it is necessary to have 16 branches for covering all possible alignments modulo 16. This is because, unfortunately, there is no XMM shift instruction with a variable

Re: free (static_array)

On Tuesday 01 July 2008 08:38, Sajish V wrote: Hi All, Can you please let me know why GCC does not crib when we try to free a static array? main () { char array[100]; free (array); } The above code compiles without any hitch. Thanks, Sajish. # ./a.out *** glibc detected

Re: Feature request - a macro defined for GCC

On Tuesday 01 July 2008 07:33, x z wrote: I would like to see that GCC define a macro in the case it is being used to compile a program. Currently there is a __GNUC__ macro defined by the GNU C preprocessor CPP. That does not suit the need. As the CPP Manual says: __GNUC__ is defined by

Re: free (static_array)

On Tuesday 01 July 2008 09:24, Sajish V wrote: Thanks for the reply, Denys. My question was, why doesn't gcc catch it during compilation? It is clear that we are trying to free a variable from stack. Shouldn't gcc flag an error for this during compilation? How gcc can know that free() is

Re: 4.3.0 and 4.3.1 don't build startfiles (crtXXX.o files)

On Sunday 08 June 2008 04:52, Daniel Jacobowitz wrote: On Sat, Jun 07, 2008 at 11:26:05AM +0200, Denys Vlasenko wrote: Seen that 4.3.1 has been released, I tried to build i486-linux-uclibc cross-compiler. You probably forgot to build libgcc. Are you using 'make all' / 'make install

Re: 4.3.0 and 4.3.1 don't build startfiles (crtXXX.o files)

On Sunday 08 June 2008 13:50, Joseph S. Myers wrote: On Sun, 8 Jun 2008, Denys Vlasenko wrote: ../../../gcc-4.3.1/libgcc/config/libbid/bid_decimal_globals.c:52:18: error: fenv.h: No such file or directory Decimal floating point requires fenv.h. The DPD code only requires the header

Re: 4.3.0 and 4.3.1 don't build startfiles (crtXXX.o files)

On Sunday 08 June 2008 16:27, Paul Brook wrote: As far as I know, toolchain is built in this order: 1. binutils 2. C compiler 3. libc No. That usually only works if you already have the toolchain installed. In which case ordering is irelevant, you can just build whichever

climits: unsafe #defines?

Accudentally noticed this in my freshly built 4.3.1 tree in climits C++ header file: #ifndef LLONG_MIN #define LLONG_MIN -__LONG_LONG_MAX__ - 1 #endif #ifndef LLONG_MAX #define LLONG_MAX __LONG_LONG_MAX__ #endif #ifndef ULLONG_MAX #define ULLONG_MAX __LONG_LONG_MAX__ * 2ULL + 1 #endif Think

Re: 4.3.0 and 4.3.1 don't build startfiles (crtXXX.o files)

On Sunday 08 June 2008 22:41, Paolo Bonzini wrote: Then, running make all-target-libgcc built them, but I finally settled for just make - it didn't error out. Yes, the advantage of Paul's suggested process are not only that the installations are reproducible and always use the complete

4.3.0 and 4.3.1 don't build startfiles (crtXXX.o files)

Seen that 4.3.1 has been released, I tried to build i486-linux-uclibc cross-compiler. It went fine except for the detail that none of crt.o files are found in installation directory after make install For comparison, gcc 4.2.1's directory has them: # find -name 'crt*.o'

Re: Can't build correctly working crosscompiler with 4.3.0. 4.2.1 worked like charm

On Thursday 17 April 2008 05:26, Brian Dessent wrote: Denys Vlasenko wrote: Only in my case, $prefix contain neither as nor ld. gcc lives in Okay, so prepend /usr/app/binutils-2.18-x86_64-linux-uclibc/bin to PATH and gcc will find and use x86_64-linux-uclibc-{as,ld} without any

Re: Can't build correctly working crosscompiler with 4.3.0. 4.2.1 worked like charm

On Wednesday 16 April 2008 16:23, Daniel Jacobowitz wrote: On Tue, Apr 15, 2008 at 05:34:17AM +0200, Denys Vlasenko wrote: --bindir=/usr/bin \ bindir=$STATIC/bin \ Why are you configuring for one set of paths which are half in $STATIC and half

Re: Can't build correctly working crosscompiler with 4.3.0. 4.2.1 worked like charm

On Wednesday 16 April 2008 17:43, Daniel Jacobowitz wrote: On Wed, Apr 16, 2008 at 05:21:55PM +0200, Denys Vlasenko wrote: Maybe gcc can use paths relative to executable's location? readlink(/proc/self/exe) and all that. It will make gcc installation movable without rebuilding

Re: Can't build correctly working crosscompiler with 4.3.0. 4.2.1 worked like charm

On Wednesday 16 April 2008 21:17, Daniel Jacobowitz wrote: On Wed, Apr 16, 2008 at 09:01:44PM +0200, Denys Vlasenko wrote: As I mentined in the first mail, it's not the end of a story. Next issue: can't find header files. This used to work with 4.2.1: Try -v to see where it is searching

Re: Can't build correctly working crosscompiler with 4.3.0. 4.2.1 worked like charm

On Wednesday 16 April 2008 21:59, Daniel Jacobowitz wrote: On Wed, Apr 16, 2008 at 09:55:09PM +0200, Denys Vlasenko wrote: #include ... search starts here: #include ... search starts here: include libbb /.share/usr/app/gcc-4.3.0-x86_64-linux-uclibc/bin/../lib/gcc/x86_64-linux

Re: Can't build correctly working crosscompiler with 4.3.0. 4.2.1 worked like charm

On Thursday 17 April 2008 00:42, Daniel Jacobowitz wrote: On Wed, Apr 16, 2008 at 10:24:35PM +0200, Denys Vlasenko wrote: It seems that 4.2.1 was testing /usr/lib/../x86_64-linux-uclibc/include, i.e. $libdir/../x86_64-linux-uclibc/include. From the listing above I see them 4.3.0 does not do

Re: Can't build correctly working crosscompiler with 4.3.0. 4.2.1 worked like charm

On Thursday 17 April 2008 02:40, Denys Vlasenko wrote: I believe I solved it with --with-sysroot... Will try again and let you know. So far I only discovered that --with-as=$CROSS-as is not going to work. Fixing configure is not enough: 23651 access(x86_64-linux-uclibc-as, X_OK) = -1 ENOENT

Re: Can't build correctly working crosscompiler with 4.3.0. 4.2.1 worked like charm

On Thursday 17 April 2008 03:35, Denys Vlasenko wrote: On Thursday 17 April 2008 02:40, Denys Vlasenko wrote: I believe I solved it with --with-sysroot... Will try again and let you know. I got over the problem of includes not being found using --with-sysroot, and reached /usr/bin/x86_64

Re: Can't build correctly working crosscompiler with 4.3.0. 4.2.1 worked like charm

On Thursday 17 April 2008 04:04, Brian Dessent wrote: What happened to the good old concept of looking up executables' location in $PATH if they have no slashes on the name? (Oh well)^2. Recompiling with --with-as=/usr/bin/$CROSS-as... Why do you think it's necessary to specify this?

INSTALL/configure.html mentions ${gcc_tooldir} - what's that?

Hi, INSTALL/configure.html mentions ${gcc_tooldir}, just once. Here: Cross-Compiler-Specific Options The following options only apply to building cross compilers. --with-sysroot --with-sysroot=dir Tells GCC to consider dir as the root of a tree that contains a (subset of) the root

Can't build correctly working crosscompiler with 4.3.0. 4.2.1 worked like charm

Ok, I give up. I killed many hours trying to build a cross-compiling x86_64-linux-uclibc-gcc, version 4.3.0. After many WTF? moments I decided to go back and try to build a cross-compiler which I already have, just older version: I decided to build i486 one, not x86_64. Because I already have

Re: gcc for Linux/x86 vs. Solaris/x86

On Saturday 29 March 2008 00:56, Alexandra (Sasha) Fedorova wrote: I was wondering anyone knows any details of the gcc port for Solaris/x86. I am wondering, if I have an executable compiled with gcc for Linux and an executable compiled with the same gcc (same version, same options) for

Re: gcc for Linux/x86 vs. Solaris/x86

On Saturday 29 March 2008 01:46, Andrew Pinski wrote: On Fri, Mar 28, 2008 at 5:16 PM, Denys Vlasenko [EMAIL PROTECTED] wrote: See: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29950 And I can tell you now that bug is on purpose and really not a bug. We base stuff on the decl uid

Re: [PATCH] linux/fs.h - Convert debug functions declared inline __attribute__((format (printf,x,y) to statement expression macros

On Friday 29 February 2008 02:09, Joe Perches wrote: But the function place_entity doesn't use it directly or indirectly. If the lines above are removed, the generated code for place_entity changes. I see it all the time. Whenever I add/remove/change something to a header, some functions grow a

Re: How to understand gcc source code?

On Saturday 22 March 2008 11:14, Basile STARYNKEVITCH wrote: Actually you ask an interesting difficult question. Some thoughts from somebody who works on GCC for more than a year but still considers himself a newbie: * my impression is that nobody understands fully the GCC compiler. Maybe

Re: Plans for Linux ELF i686+ ABI ? Like SPARC V8+ ?

On Monday 15 October 2007 13:18, Darryl Miles wrote: Yes maybe there is a restriction in the ELF format on the maximum executable size but linking has little to do with the issue of improving performance via better linkage ABI rules. Passing function arguments by registers [64bit] verses

Re: Preparsing sprintf format strings

On Tuesday 09 October 2007 20:48, Heikki Linnakangas wrote: The new linux code is slightly but not much faster than the old one (3.04s vs 3.16s), Test on my machine (three runs) $ time ./sprintf-linux ./sprintf-linux 10-70-110 user0m2.018s user0m2.024s user0m1.997s $ time

Re: Preparsing sprintf format strings

On Monday 08 October 2007 13:50, Heikki Linnakangas wrote: While profiling a test case of exporting data from PostgreSQL, I noticed that a lot of CPU time was spent in sprintf, formatting timestamps like 2007-10-01 12:34. I could speed that up by an order of magnitude by replacing the sprintf

Re: Preparsing sprintf format strings

On Monday 08 October 2007 16:08, Heikki Linnakangas wrote: Denys Vlasenko wrote: On Monday 08 October 2007 13:50, Heikki Linnakangas wrote: While profiling a test case of exporting data from PostgreSQL, I noticed that a lot of CPU time was spent in sprintf, formatting timestamps like 2007