Is ther document that describes how the "braching/fixing" on releases is done
GCC 7.5 November 14, 2019 GCC 9.2 August 12, 2019 GCC 9.1 May 3, 2019 GCC 8.3 February 22, 2019 GCC 7.4 December 6, 2018 GCC 6.5 October 26, 2018 GCC 8.2 July 26, 2018 GCC 8.1 May 2, 2018 GCC 7.3 January 25, 2018 GCC 5.5 October 10, 2017 GCC 7.2 August 14, 2017 GCC 6.4 July 4, 2017 GCC 7.1 May 2, 2017 GCC 6.3 December 21, 2016 for example: is the 6.4 release only a bug fix "branch" of the 6.3 "branch" and the real succesor of 6.3 is 7.1? and sucessor of 7.3 is 8.1?
Re: Is ther document that describes how the "braching/fixing" on releases is done
Am 16.02.2020 um 18:03 schrieb David Edelsohn: https://gcc.gnu.org/develop.html#timeline Thanks any idea how to reintegrate (many) changes from a release/6.3.0 branch back into mainline? is there a tag or something where mainline was for short time in sync with 6.3.0?
Re: Is ther document that describes how the "braching/fixing" on releases is done
Am 16.02.2020 um 18:27 schrieb David Edelsohn: On Sun, Feb 16, 2020 at 12:19 PM Dennis Luehring wrote: > > Am 16.02.2020 um 18:03 schrieb David Edelsohn: > > https://gcc.gnu.org/develop.html#timeline > > > Thanks > > any idea how to reintegrate (many) changes from a release/6.3.0 branch > back into mainline? > > is there a tag or something where mainline was for short time in sync > with 6.3.0? There is no need to reintegrate changes from a release into trunk. The intent is that all bugs are fixed on trunk and back-ported to branches. The fix on a release branch may be implemented differently or as a work-around, but the bug is intended to be fixed in all release branches that still are maintained, where the bug is relevant, that exhibited the bug and where the benefit justifies the potential risk of the bug fix. Thanks David i've got an older project where features where integrated based on an 6.3.0 branch no bug fixes - only new features and no backporting was done :( i now want to reintegrate these new features back into mainline (not directly into head due to amount conflicts) but somewhere around "GCC 7 Stage 4 (starts 2017-01-20)" could work i think or should i try to directly merge with a 7.1 tag branch, i've no idea how many changes where done
Re: Is ther document that describes how the "braching/fixing" on releases is done
Am 16.02.2020 um 18:42 schrieb David Edelsohn: If you are trying to forward-port your own, proprietary features into a newer release of GCC for your own, internal use, that's your responsibility. that is my case, i ask for a meaningfull way of doing that i could upgrade the 6.3 branch to 6.4, 6.5 and then try to merge back into a branch based on releases/gcc-7.1.0 or try to directly merge the 6.3 with a releases/gcc-7.1 tag based branch, what would be easier?
Re: Is ther document that describes how the "braching/fixing" on releases is done
Am 17.02.2020 um 10:51 schrieb Richard Biener: I would start merging the new feature ontop master to the point where GCC 6 branched (so go _back_ in time) and only then start moving forward, remaining on master. good idea, thank you
update github gcc mirror forks to the new repo?
so the github gcc mirror is already using the new reposurgeon based git repo, that means that all the commit hashes etc. are different if someone forked this gcc mirror so easy pulling from the mirror isn't possible anymore - or am im wrong? is there any description how to "port" over github projects that dependens on the old repo? would a simple rebase work, or cherry picking? thx
Re: update github gcc mirror forks to the new repo?
Am 18.02.2020 um 11:43 schrieb Jonathan Wakely: On Tue, 18 Feb 2020 at 06:38, Dennis Luehring wrote: > > so the github gcc mirror is already using the new reposurgeon based git > repo, > > that means that all the commit hashes etc. are different if someone > forked this gcc mirror > > so easy pulling from the mirror isn't possible anymore - or am im wrong? > > > is there any description how to "port" over github projects that > dependens on the old repo? > > would a simple rebase work, or cherry picking? You can use rebasing or cherry-picking, but you need to do so carefully. If you try to rebase (or cherry-pick) onto the tip of a branch in the new repo you'll almost certainly get conflicts, because the new branch in the new repo has moved on since the point where you last pulled from the old repo. The best way is to find the commit in the new repo which corresponds to the last commit you have from the old repo, and rebase onto that. That way you can graft your local commits onto exactly the same tree (but with different hashes and different history) which should apply cleanly. There's a script to do that at https://gcc.gnu.org/ml/gcc/2020-01/msg00202.html (and an alternative in the reply to that email). To use the script you need to have set up a remote for the old repo (which you can remove again later if you want): git remote add gcc-old git://gcc.gnu.org/git/gcc-old.git git fetch gcc-old lets see if rebasing or cherry picking is easier, thank you
is there a reason why "explicit specialization in non-namespace scope" is still an error in gcc-trunk?
i've read that scoped template specalization is allowed in C++17
clang supports it starting with release 7
MSVC supports it with VS2017(i don't know what revision)
Intel does not like it
https://gcc.godbolt.org/z/1GET6v
--
enumclass E{ A, B };
struct Ta{ int x; };
struct Tb{ float y; };
struct Mapper
{
template struct type_to_enum{};
template<> // <-- FAILS
struct type_to_enum
{
staticconstexprauto value = E::A;
};
template <> // <-- Fails
struct type_to_enum
{
staticconstexprauto value = E::B;
};
};
---
when will scoped template specialization be available in gcc?
i've read that scoped template specalization is allowed in C++17
suports it:
-clang starting with release 7
-MSVC starting with VS2017(i don't know what revision)
no support:
-gcc(trunk)
-latest Intel
https://gcc.godbolt.org/z/1GET6v
--
enum class E{ A, B };
struct Ta{ int x; };
struct Tb{ float y; };
struct Mapper
{
template struct type_to_enum{};
template<> // <-- FAILS
struct type_to_enum
{
static constexpr auto value = E::A;
};
template <> // <-- Fails
struct type_to_enum
{
static constexpr auto value = E::B;
};
};
---
when will "scoped template specalization" be available? gcc trunk seems not support it
i've read that scoped template specalization is allowed in C++17 - is it
planned for the next gcc release?
otherwise i will switch to an if constexpr solution - but would be still
to have this feature
checked compiler:
gcc trunk (and latest intel) do not support it
clang (starting with release 7) and MSVC (starting with VS2017(i don't
know the exact revision)) supports it
--
enum class E{ A };
struct Ta{ int x; };
struct Mapper
{
template struct type_to_enum{};
template<> // <-- FAILS
struct type_to_enum
{
static constexpr auto value = E::A;
};
};
gcc 4.8.3 configure/build targeting alpha dec does not fully respect --prefix - or is it something else?
The github-repo https://github.com/LowLevelMahn/build_clfs_tools
contains the scripts, files AND complete build-logs (so no need to run
the script yourself)
separated for each step that i will use here as a "walkable" reference.
Its better read/clickable then this long email.
I'll try to keep the github readme.md up to date if somethings changes.
===
Goal
===
I want to add alpha dec support to the current stable Cross Linux From
Scratch (CLFS clfs.org) 3.0 (which uses gcc 4.8.3 as source base)
CLFS 3.0 currently only supports x86/mips/sparc/arm/powerpc.
Using a ready-for-use-cross-development-toolkit is not an option for
being CLFS conform.
===
Work so far - the build-script
===
I’ve written a bash script
https://github.com/LowLevelMahn/build_clfs_tools/build_clfs_cross_tools.sh
(for being consistent in building for the different targets)
that is doing the CLFS "5. Constructing Cross-Compile Tools" chapter.
Its based on
http://www.clfs.org/view/CLFS-3.0.0-SYSTEMD/sparc64-64/cross-tools/introduction.html
and
http://www.clfs.org/view/CLFS-3.0.0-SYSTEMD/mips64-64/cross-tools/introduction.html
I've got extra follow up scripts for building kernel, bash, hello world
etc. but I haven't included them here to keep the problem report smaller.
The script needs sudo to add /tools and /cross-tools symbolic links to
the root - the CLFS gcc patches are directing to them - but thats all
The script checks for every possible error and exits with current
step/substep info on any fail, it logs every ./configure, make, make
install run
and creates some extra info files for searchdirs, paths etc.
Every package is built out of Source-Tree and freshly extracted/removed
in every step.
The target configuration (build script line 35-70) is the only part of
the script which is target specific.
The rest of the script only uses these variables, no target related
ifs/switch-cases while configuring/building are present.
This is the essence of the script:
step(04) starting at line 299 in the build script
* step( 4): 5.2. File-5.19
* step( 5): 5.3. Linux-3.14.21 Headers
* step( 6): 5.4. M4-1.4.17
* step( 7): 5.5. Ncurses-5.9
* step( 8): 5.6. Pkg-config-lite-0.28-1
* step( 9): 5.7. GMP-6.0.0
* step(10): 5.8. MPFR-3.1.2
* step(11): 5.9. MPC-1.0.2
* step(12): 5.10. ISL-0.12.2
* step(13): 5.11. CLooG-0.18.2
* step(14): 5.12. Cross Binutils-2.24
* step(15): 5.13. Cross GCC-4.8.3
* step(16): 5.14. Glibc-2.19
* step(17): 5.15. Cross GCC-4.8.3 <-- alpha fails here
build-logs:
https://github.com/LowLevelMahn/build_clfs_tools/clfs_cross_tools/system/alpha/build_log
https://github.com/LowLevelMahn/build_clfs_tools/clfs_cross_tools/system/mips64-64/build_log
https://github.com/LowLevelMahn/build_clfs_tools/clfs_cross_tools/system/sparc64-64/build_log
===
what is working:
===
Sparc64-64 and mips64-64 are working perfectly - I’m able to compile and
run a linux kernel + bash + hello-world in sparc64/mips64-qemu
based on the built cross-tools.
===
the problem:
===
If building for alpha target the script fails in step(17) with linking
crti.o
https://github.com/LowLevelMahn/build_clfs_tools/clfs_cross_tools/system/alpha/build_log/step_17_gcc-4.8.3/make.out
in line 3776
===
My findings so far:
===
The reason for the fail in step(17) is that the built gcc in step(15)
got the wrong gcc search-dirs, whereas
sparc64-64/mips64-64 got the correct and equal gcc-search-dirs, but the
alpha target differs in the last 4 paths.
Logged gcc search-dirs:
gcc_search_dirs.(diffable).out is generated in step(15) Cross GCC-4.8.3,
build_clfs_cross_tools.sh, line: 723/726
better readable search-dirs
https://github.com/LowLevelMahn/build_clfs_tools/clfs_cross_tools/system/alpha/build_log/step_15_gcc-4.8.3/gcc_search_dirs.out
https://github.com/LowLevelMahn/build_clfs_tools/clfs_cross_tools/system/mips64-64/build_log/step_15_gcc-4.8.3/gcc_search_dirs.out
https://github.com/LowLevelMahn/build_clfs_tools/clfs_cross_tools/system/sparc64-64/build_log/step_15_gcc-4.8.3/gcc_search_dirs.out
for being better diffable target replaced by {TARGET}, clfs_target
replace by [CLFS_TARGET} etc.
https://github.com/LowLevelMahn/build_clfs_tools/clfs_cross_tools/system/alpha/build_log/step_15_gcc-4.8.3/gcc_search_dirs.diffable.out
https://github.com/LowLevelMahn/build_clfs_tools/clfs_cross_tools/system/mips64-64/build_log/step_15_gcc-4.8.3/gcc_search_dirs.diffable.out
https://github.com/LowLevelMahn/build_clfs_tools/clfs_cross_tools/system/sparc64-64/build_log/step_15_gcc-4.8.3/gcc_search_dirs.diffable.out
logged c-runtime location:
-the crti.o is the same in all target-folders - that seems correct
crt-path.out is generated in step(16) Glibc-2.19,
build_clfs_cross_tools.sh, line: 776
https://github.com/LowLevelMahn/build_clfs_tools/clfs_cross_tools/system/alpha/build_lo
FIXED LINKS: gcc 4.8.3 configure/build targeting alpha dec does not fully respect --prefix - or is it something else?
The github-repo https://github.com/LowLevelMahn/build_clfs_tools
contains the scripts, files AND complete build-logs (so no need to run
the script yourself)
separated for each step that i will use here as a "walkable" reference.
The Repo Readme.MD better read/clickable then this long email. I'll try
to keep the github readme.md up to date if somethings changes.
===
Goal
===
I want to add alpha dec support to the current stable Cross Linux From
Scratch (CLFS clfs.org) 3.0 (which uses gcc 4.8.3 as source base)
CLFS 3.0 currently only supports x86/mips/sparc/arm/powerpc.
Using a ready-for-use-cross-development-toolkit is not an option for
being CLFS conform.
===
Work so far - the build-script
===
I’ve written a bash script
https://github.com/LowLevelMahn/build_clfs_tools/blob/master/build_clfs_cross_tools.sh
(for being consistent in building for the different targets)
that is doing the CLFS "5. Constructing Cross-Compile Tools" chapter.
Its based on
http://www.clfs.org/view/CLFS-3.0.0-SYSTEMD/sparc64-64/cross-tools/introduction.html
and
http://www.clfs.org/view/CLFS-3.0.0-SYSTEMD/mips64-64/cross-tools/introduction.html
I've got extra follow up scripts for building kernel, bash, hello world
etc. but I haven't included them here to keep the problem report smaller.
The script needs sudo to add /tools and /cross-tools symbolic links to
the root - the CLFS gcc patches are directing to them - but thats all
The script checks for every possible error and exits with current
step/substep info on any fail, it logs every ./configure, make, make
install run
and creates some extra info files for searchdirs, paths etc.
Every package is built out of Source-Tree and freshly extracted/removed
in every step.
The target configuration (build script line 35-70) is the only part of
the script which is target specific.
The rest of the script only uses these variables, no target related
ifs/switch-cases while configuring/building are present.
This is the essence of the script:
step(04) starting at line 299 in the build script
* step( 4): 5.2. File-5.19
* step( 5): 5.3. Linux-3.14.21 Headers
* step( 6): 5.4. M4-1.4.17
* step( 7): 5.5. Ncurses-5.9
* step( 8): 5.6. Pkg-config-lite-0.28-1
* step( 9): 5.7. GMP-6.0.0
* step(10): 5.8. MPFR-3.1.2
* step(11): 5.9. MPC-1.0.2
* step(12): 5.10. ISL-0.12.2
* step(13): 5.11. CLooG-0.18.2
* step(14): 5.12. Cross Binutils-2.24
* step(15): 5.13. Cross GCC-4.8.3
* step(16): 5.14. Glibc-2.19
* step(17): 5.15. Cross GCC-4.8.3 <-- alpha fails here
build-logs:
https://github.com/LowLevelMahn/build_clfs_tools/tree/master/clfs_cross_tools/system/alpha/build_log
https://github.com/LowLevelMahn/build_clfs_tools/tree/master/clfs_cross_tools/system/mips64-64/build_log
https://github.com/LowLevelMahn/build_clfs_tools/tree/master/clfs_cross_tools/system/sparc64-64/build_log
===
what is working:
===
Sparc64-64 and mips64-64 are working perfectly - I’m able to compile and
run a linux kernel + bash + hello-world in sparc64/mips64-qemu
based on the built cross-tools.
===
the problem:
===
If building for alpha target the script fails in step(17) with linking
crti.o
https://github.com/LowLevelMahn/build_clfs_tools/tree/master/clfs_cross_tools/system/alpha/build_log/step_17_gcc-4.8.3/make.out
in line 3776
===
My findings so far:
===
The reason for the fail in step(17) is that the built gcc in step(15)
got the wrong gcc search-dirs, whereas
sparc64-64/mips64-64 got the correct and equal gcc-search-dirs, but the
alpha target differs in the last 4 paths.
Logged gcc search-dirs:
gcc_search_dirs.(diffable).out is generated in step(15) Cross GCC-4.8.3,
build_clfs_cross_tools.sh, line: 723/726
better readable search-dirs
https://github.com/LowLevelMahn/build_clfs_tools/tree/master/clfs_cross_tools/system/alpha/build_log/step_15_gcc-4.8.3/gcc_search_dirs.out
https://github.com/LowLevelMahn/build_clfs_tools/tree/master/clfs_cross_tools/system/mips64-64/build_log/step_15_gcc-4.8.3/gcc_search_dirs.out
https://github.com/LowLevelMahn/build_clfs_tools/tree/master/clfs_cross_tools/system/sparc64-64/build_log/step_15_gcc-4.8.3/gcc_search_dirs.out
for being better diffable target replaced by {TARGET}, clfs_target
replace by [CLFS_TARGET} etc.
https://github.com/LowLevelMahn/build_clfs_tools/tree/master/clfs_cross_tools/system/alpha/build_log/step_15_gcc-4.8.3/gcc_search_dirs.diffable.out
https://github.com/LowLevelMahn/build_clfs_tools/tree/master/clfs_cross_tools/system/mips64-64/build_log/step_15_gcc-4.8.3/gcc_search_dirs.diffable.out
https://github.com/LowLevelMahn/build_clfs_tools/tree/master/clfs_cross_tools/system/sparc64-64/build_log/step_15_gcc-4.8.3/gcc_search_dirs.diffable.out
logged c-runtime location:
-the crti.o is the same in all target-folders - that seems correct
crt-path.out is generated in
check for the existence of "__sync_lock_test_and_set"
https://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Atomic-Builtins.html is there a define to check for the existence of "__sync_lock_test_and_set"
Re: Successful bootstrap and install of gcc (GCC) 6.3.0 on mips64el-unknown-linux-gnu
are you only building gcc or also glibc/binutils? and building a kernel with minimal hello world init or something for testing? what about a dec-alpha build test :) Am 08.01.2017 um 21:27 schrieb Aaro Koskinen: Hi, Here's a report of a successful build and install of GCC: $ gcc-6.3.0/config.guess mips64el-unknown-linux-gnu $ newcompiler/bin/gcc -v Using built-in specs. COLLECT_GCC=newcompiler/bin/gcc COLLECT_LTO_WRAPPER=/home/aaro/gcctest/newcompiler/libexec/gcc/mipsel-unknown-linux-gnu/6.3.0/lto-wrapper Target: mipsel-unknown-linux-gnu Configured with: ../gcc-6.3.0/configure --with-arch=loongson2f --with-abi=32 --with-fp-32=xx --enable-targets=all --disable-nls --prefix=/home/aaro/gcctest/newcompiler --enable-languages=c,c++ --host=mipsel-unknown-linux-gnu --build=mipsel-unknown-linux-gnu --target=mipsel-unknown-linux-gnu --with-system-zlib --with-sysroot=/ Thread model: posix gcc version 6.3.0 (GCC) -- Build environment -- host: fuloong-minipc distro: los.git rootfs=ef31e1 native=ef31e1 kernel: Linux 4.9.0-lemote-los_ef31e1 binutils: GNU binutils 2.27 make: GNU Make 4.2.1 libc: GNU C Library (GNU libc) stable release version 2.24 zlib: 1.2.8 mpfr: 3.1.3 gmp: 6 -- Time consumed -- configure: real0m 23.73s user0m 15.35s sys 0m 6.22s bootstrap: real50h 9m 38s user46h 31m 26s sys 3h 16m 30s install:real16m 28.01s user6m 15.90s sys 7m 51.50s -- Hardware details --- MemTotal: 494016 kB system type : lemote-fuloong-2f-box machine : Unknown processor : 0 cpu model : ICT Loongson-2 V0.3 FPU V0.1 BogoMIPS: 264.19 wait instruction: yes microsecond timers : yes tlb_entries : 64 extra interrupt vector : no hardware watchpoint : yes, count: 0, address/irw mask: [] isa : mips2 mips3 ASEs implemented: shadow register sets: 1 kscratch registers : 0 package : 0 core: 0 VCED exceptions : not available VCEI exceptions : not available A.
simple example -O3 optimizer problem?
tested following code with
http://gcc.godbolt.org/
tested with
g++-4.8 (Ubuntu 4.8.1.2ubuntu1~12.04) 4.8.1
g++ (GCC) 4.9.0 20130909 (experimental)
and the result with -O3 + defined USE_ITER seems to be a little bit long
--
static void foo(int a, int& dummy)
{
dummy += a;
}
#define USE_ITER
int main(int argc, char** argv)
{
//--
//anti-optimizer
int dummy = 0;
int* array = (int*)&argv;
//--
#if defined(USE_ITER)
int* pend = &array[10];
for(int* p = &array[0]; p < pend; ++p) foo(*p, dummy);
#else
for(int i = 0; i < 10; ++i) foo(array[i], dummy);
#endif
return dummy;
}
-
with -O2
with/without define USE_ITER
result:
main:
leardx, [rsp-8]
learcx, [rsp+32]
movQWORD PTR [rsp-8], rsi
xoreax, eax
.L3:
addeax, DWORD PTR [rdx]
addrdx, 4
cmprdx, rcx
jb.L3
rep; ret
with -O3
without define USE_ITER
main:
movrax, rsi
shrrax, 32
addeax, esi
addeax, DWORD PTR [rsp]
addeax, DWORD PTR [rsp+4]
addeax, DWORD PTR [rsp+8]
addeax, DWORD PTR [rsp+12]
addeax, DWORD PTR [rsp+16]
addeax, DWORD PTR [rsp+20]
addeax, DWORD PTR [rsp+24]
addeax, DWORD PTR [rsp+28]
ret
with define USE_ITER
main:
leardi, [rsp-16]
learax, [rsp+27]
movQWORD PTR [rsp-16], rsi
lear8, [rsp+24]
movecx, 1
leardx, [rdi+4]
learsi, [rdi+1]
subrax, rdx
movrdx, rdi
shrrax, 2
addrax, 1
cmprsi, r8
cmovbercx, rax
andedx, 15
shrrdx, 2
cmprcx, rdx
cmovberdx, rcx
cmprax, 8
ja.L30
.L2:
movrdx, rcx
.L11:
cmprdx, 1
moveax, DWORD PTR [rsp-16]
je.L13
addeax, DWORD PTR [rsp-12]
cmprdx, 2
je.L14
addeax, DWORD PTR [rsp-8]
cmprdx, 3
je.L15
addeax, DWORD PTR [rsp-4]
cmprdx, 4
je.L16
addeax, DWORD PTR [rsp]
cmprdx, 5
je.L17
addeax, DWORD PTR [rsp+4]
cmprdx, 6
je.L18
addeax, DWORD PTR [rsp+8]
cmprdx, 7
je.L19
addeax, DWORD PTR [rsp+12]
learsi, [rsp+16]
.L4:
cmprcx, rdx
je.L23
.L3:
subrcx, rdx
movr9, rcx
shrr9, 2
lear10, [0+r9*4]
testr10, r10
je.L6
leardx, [rdi+rdx*4]
cmpr9, 1
movdquxmm0, XMMWORD PTR [rdx]
jbe.L7
movdquxmm1, XMMWORD PTR [rdx+16]
cmpr9, 2
padddxmm0, xmm1
je.L7
movdquxmm1, XMMWORD PTR [rdx+32]
padddxmm0, xmm1
.L7:
movdqaxmm2, xmm0
learsi, [rsi+r10*4]
psrldqxmm2, 8
padddxmm0, xmm2
movdqaxmm3, xmm0
psrldqxmm3, 4
padddxmm0, xmm3
movdedx, xmm0
addeax, edx
cmprcx, r10
je.L23
.L6:
leardx, [rsi+4]
addeax, DWORD PTR [rsi]
cmpr8, rdx
jbe.L23
leardx, [rsi+8]
addeax, DWORD PTR [rsi+4]
cmpr8, rdx
jbe.L31
addeax, DWORD PTR [rsi+8]
ret
.L23:
rep; ret
.L30:
cmprsi, r8
ja.L2
xoreax, eax
testrdx, rdx
movrsi, rdi
je.L3
jmp.L11
.L31:
ret
.L16:
movrsi, rsp
jmp.L4
.L17:
learsi, [rsp+4]
jmp.L4
.L18:
learsi, [rsp+8]
jmp.L4
.L19:
learsi, [rsp+12]
jmp.L4
.L14:
learsi, [rsp-8]
jmp.L4
.L15:
learsi, [rsp-4]
jmp.L4
.L13:
learsi, [rdi+4]
jmp.L4
Re: simple example -O3 optimizer problem?
Am 18.07.2014 10:29, schrieb Andrew Haley: On 18/07/14 08:30, Dennis Luehring wrote: >int* array = (int*)&argv; This looks like undefined behaviour. Don't you get a warning? Andrew. no warning - its an valid typed pointer to stack and i don't care what the values are its just an anti-optimizer trick nothing more
Re: simple example -O3 optimizer problem?
Am 18.07.2014 11:14, schrieb Andrew Haley:
On 07/18/2014 09:40 AM, Dennis Luehring wrote:
> Am 18.07.2014 10:29, schrieb Andrew Haley:
>> On 18/07/14 08:30, Dennis Luehring wrote:
>>>int* array = (int*)&argv;
>>
>> This looks like undefined behaviour. Don't you get a warning?
>
> no warning - its an valid typed pointer to stack and i don't care what
> the values are
> its just an anti-optimizer trick nothing more
And if you give it the correct type, doe that make any difference?
static void foo(int a, int& dummy)
{
dummy += a;
}
#define USE_CHAR
#define USE_ITER
int main(int argc, char** argv)
{
//--
//anti-optimizer
int dummy = 0;
#if defined(USE_CHAR)
typedef char T;
T* array = argv[0];
#else
typedef int T;
T* array = (int*)&argv; // undefined?
#endif
//--
#if defined(USE_ITER)
T* pend = &array[10];
for(T* p = &array[0]; p < pend; ++p) foo(*p, dummy);
#else
for(int i = 0; i < 10; ++i) foo(array[i], dummy);
#endif
return dummy;
}
with USE_CHAR, with/without USE_ITER, -O3 gives:
main:
movrdx, QWORD PTR [rsi]
movsxecx, BYTE PTR [rdx]
movsxeax, BYTE PTR [rdx+1]
addeax, ecx
movsxecx, BYTE PTR [rdx+2]
addeax, ecx
movsxecx, BYTE PTR [rdx+3]
addeax, ecx
movsxecx, BYTE PTR [rdx+4]
addeax, ecx
movsxecx, BYTE PTR [rdx+5]
addeax, ecx
movsxecx, BYTE PTR [rdx+6]
addeax, ecx
movsxecx, BYTE PTR [rdx+7]
addeax, ecx
movsxecx, BYTE PTR [rdx+8]
movsxedx, BYTE PTR [rdx+9]
addeax, ecx
addeax, edx
ret
without USE_CHAR, without USE_ITER, -O3 gives:
main:
movrax, rsi
shrrax, 32
addeax, esi
addeax, DWORD PTR [rsp]
addeax, DWORD PTR [rsp+4]
addeax, DWORD PTR [rsp+8]
addeax, DWORD PTR [rsp+12]
addeax, DWORD PTR [rsp+16]
addeax, DWORD PTR [rsp+20]
addeax, DWORD PTR [rsp+24]
addeax, DWORD PTR [rsp+28]
ret
without USE_CHAR, with USE_ITER, -O3 gives
main:
leardi, [rsp-16]
learax, [rsp+27]
movQWORD PTR [rsp-16], rsi
lear8, [rsp+24]
movecx, 1
leardx, [rdi+4]
learsi, [rdi+1]
subrax, rdx
movrdx, rdi
shrrax, 2
addrax, 1
cmprsi, r8
cmovbercx, rax
andedx, 15
shrrdx, 2
cmprcx, rdx
cmovberdx, rcx
cmprax, 8
ja.L30
.L2:
movrdx, rcx
.L11:
cmprdx, 1
moveax, DWORD PTR [rsp-16]
je.L13
addeax, DWORD PTR [rsp-12]
cmprdx, 2
je.L14
addeax, DWORD PTR [rsp-8]
cmprdx, 3
je.L15
addeax, DWORD PTR [rsp-4]
cmprdx, 4
je.L16
addeax, DWORD PTR [rsp]
cmprdx, 5
je.L17
addeax, DWORD PTR [rsp+4]
cmprdx, 6
je.L18
addeax, DWORD PTR [rsp+8]
cmprdx, 7
je.L19
addeax, DWORD PTR [rsp+12]
learsi, [rsp+16]
.L4:
cmprcx, rdx
je.L23
.L3:
subrcx, rdx
movr9, rcx
shrr9, 2
lear10, [0+r9*4]
testr10, r10
je.L6
leardx, [rdi+rdx*4]
cmpr9, 1
movdquxmm0, XMMWORD PTR [rdx]
jbe.L7
movdquxmm1, XMMWORD PTR [rdx+16]
cmpr9, 2
padddxmm0, xmm1
je.L7
movdquxmm1, XMMWORD PTR [rdx+32]
padddxmm0, xmm1
.L7:
movdqaxmm2, xmm0
learsi, [rsi+r10*4]
psrldqxmm2, 8
padddxmm0, xmm2
movdqaxmm3, xmm0
psrldqxmm3, 4
padddxmm0, xmm3
movdedx, xmm0
addeax, edx
cmprcx, r10
je.L23
.L6:
leardx, [rsi+4]
addeax, DWORD PTR [rsi]
cmpr8, rdx
jbe.L23
leardx, [rsi+8]
addeax, DWORD PTR [rsi+4]
cmpr8, rdx
jbe.L31
addeax, DWORD PTR [rsi+8]
ret
.L23:
rep; ret
.L30:
cmprsi, r8
ja.L2
xoreax, eax
testrdx, rdx
movrsi, rdi
je.L3
jmp.L11
.L31:
ret
.L16:
movrsi, rsp
jmp.L4
.L17:
learsi, [rsp+4]
jmp.L4
.L18:
learsi, [rsp+8]
jmp.L4
.L19:
learsi, [rsp+12]
jmp.L4
.L14:
learsi, [rsp-8]
jmp.L4
.L15:
learsi, [rsp-4]
jmp.L4
.L13:
learsi, [rdi+4]
jmp.L4
but is still don't get whats undefined is with (int*)&argv - i
understand that the values are undefined (pointing anywhere in stack)
but why should the -O3 optimization generate such amount of code due to
this "undefined behavior"
strangely for clang 3.4.1 behaves different
with USE_CHAR, without USE_ITER, -O3 gives:
main: # @main
movq(%rsi), %rax
movsbl(%rax), %ecx
movsbl1(%rax), %edx
addl%ecx, %edx
movsbl2(%rax
Re: Status of C++11 support
Overview: https://gcc.gnu.org/projects/cxx-status.html#cxx11 Am 09.12.2019 um 04:17 schrieb Nicholas Krause: Greetings, I was wondering what the current status of being able to use C++11 is without the gcc project. Seems it will be much easier to implement basic spinlocks with the C++11 memory model than without. Thanks, Nick
Re: Proposal for the transition timetable for the move to GIT
the differences between Maxim and Erics final result will hopefully show the open bugs in both tools and allow fixing - i think this compare phase is needed if the result should be the best possible Am 11.12.2019 um 16:19 schrieb Jonathan Wakely: On Wed, 11 Dec 2019 at 15:03, Richard Earnshaw (lists) wrote: > I wouldn't bother with that. There are known defects in the version of > reposurgeon that I used to produce that which have since been fixed. It > was *never* the point of that upload to ask for correctness checks on > the conversion (I said so at the time). Instead it was intended to > demonstrate the improvements to the commit summaries that I think we can > make. My concern is that there is no conversion done using reposurgeon that *can* be used to do correctness checks.
current state of gcc-ia16?
is the patch already integrated into mainline? is this the most recent development place? https://github.com/tkchia/gcc-ia16
Re: current state of gcc-ia16?
is the patch already integrated into mainline? No, it's not. will that ever happen? is this the most recent development place? https://github.com/tkchia/gcc-ia16 Yes, that's the right place. thx Am 08.06.2018 um 12:59 schrieb Andrew Jenner: Hi Dennis, On 08/06/2018 11:37, Dennis Luehring wrote: > is the patch already integrated into mainline? No, it's not. > is this the most recent development place? > https://github.com/tkchia/gcc-ia16 Yes, that's the right place. Andrew
is there a optimizing opportunity for const std::vector + std::initializer_list replaced with std::array?
gcc 4.8.1, -O3 -march=native -std=c++11
small example program to check what does the gcc 4.8.1 optimizer do with
const std::vector/std::arrays + simple operations
---
#include
#include
#include
#define USE_ARRAY
#if defined(USE_ARRAY)
static int calc(const std::array p_ints, const int& p_init)
#else
static int calc(const std::vector p_ints, const int& p_init)
#endif
{
return std::accumulate(p_ints.begin(), p_ints.end(), p_init);
}
int main()
{
const int result = calc({10,20,30},100);
return result;
}
---
gcc produces this code if USE_ARRAY is defined
main:
moveax, 160
ret
if USE_ARRAY is undefined (and vector is in use) it produces
main:
pushrbx
movedi, 12
calloperator new(unsigned long)
movrdx, QWORD PTR ._81[rip]
movrdi, rax
movQWORD PTR [rax], rdx
moveax, DWORD PTR ._81[rip+8]
movrsi, rdx
shrrsi, 32
leaebx, [rsi+100+rdx]
addebx, eax
testrdi, rdi
movDWORD PTR [rdi+8], eax
je.L2
calloperator delete(void*)
.L2:
moveax, ebx
poprbx
ret
._81:
.long10
.long20
.long30
so my questions is - can gcc replace/subtitute the const std::vector by
const std::array in such const situations, to get better
optimizer results or is the STL itself responsible for beeing
optimizeable like that - or does that brake any standard definitions?
btw: clang 3.3 produces much more code for both cases - nearly equal
using array/vector (except new/delete)
main: # @main
movabsq$85899345930, %rax # imm = 0x14000A
movq%rax, -16(%rsp)
movl$100, %esi
movl$30, -8(%rsp)
xorl%edx, %edx
leaq-16(%rsp), %rcx
movb$1, %al
testb%al, %al
jne.LBB0_1
movd%esi, %xmm1
pxor%xmm0, %xmm0
xorl%eax, %eax
.LBB0_3:# %vector.body.i.i
movdqu(%rsp,%rax,4), %xmm2
paddd%xmm2, %xmm0
movdqu-16(%rsp,%rax,4), %xmm2
paddd%xmm2, %xmm1
addq$8, %rax
cmpq%rax, %rdx
jne.LBB0_3
jmp.LBB0_4
.LBB0_1:
pxor%xmm0, %xmm0
movd%esi, %xmm1
.LBB0_4:# %middle.block.i.i
movl$3, %esi
paddd%xmm1, %xmm0
movdqa%xmm0, %xmm1
movhlps%xmm1, %xmm1# xmm1 = xmm1[1,1]
paddd%xmm0, %xmm1
phaddd%xmm1, %xmm1
movd%xmm1, %eax
cmpq%rdx, %rsi
je.LBB0_7
addq$-12, %rcx
leaq-16(%rsp), %rdx
.LBB0_6:# %scalar.ph.i.i
addl12(%rcx), %eax
addq$4, %rcx
cmpq%rcx, %rdx
jne.LBB0_6
.LBB0_7:# %_ZL4calcSt5arrayIiLm3EERKi.exit
ret
Re: is there a optimizing opportunity for const std::vector + std::initializer_list replaced with std::array?
Am 20.09.2013 07:50, schrieb Marc Glisse:
(gcc-h...@gcc.gnu.org would have been a better list)
On Fri, 20 Sep 2013, Dennis Luehring wrote:
> gcc 4.8.1, -O3 -march=native -std=c++11
>
> small example program to check what does the gcc 4.8.1 optimizer do with
> const std::vector/std::arrays + simple operations
>
> ---
> #include
> #include
> #include
>
> #define USE_ARRAY
>
> #if defined(USE_ARRAY)
> static int calc(const std::array p_ints, const int& p_init)
> #else
> static int calc(const std::vector p_ints, const int& p_init)
> #endif
> {
> return std::accumulate(p_ints.begin(), p_ints.end(), p_init);
> }
>
> int main()
> {
> const int result = calc({10,20,30},100);
> return result;
> }
> ---
>
> gcc produces this code if USE_ARRAY is defined
>
> main:
>moveax, 160
>ret
>
> if USE_ARRAY is undefined (and vector is in use) it produces
[long expected code]
> so my questions is - can gcc replace/subtitute the const std::vector by const
> std::array in such const situations, to get better
> optimizer results or is the STL itself responsible for beeing optimizeable
> like that - or does that brake any standard definitions?
We don't perform such high-level optimizations. But if you expand, inline
and simplify this program, the optimizers sees something like:
p=operator new(12);
memcpy(p,M,12); // M contains {10, 20, 30}
res=100+p[0]+p[1]+p[2];
if(p!=0) operator delete(p);
A few things that go wrong:
* because p is filled with memcpy and not with regular assignments, the
compiler doesn't realize that p[0] is known.
* the test p != 0 is unnecessary (a patch that should help is pending
review)
* we would then be left with: p=new(12); delete p; return 160; gcc knows
how to remove free(malloc(12)) but not the C++ variant (I don't even know
if it is legal, or what conditions and flags are required to make it so).
Please go to the gcc bugzilla and file an enhancement request (category
tree-optimization) if these problems are not there yet.
can you give more details about what you've done in "...But if you
expand, inline and simplify this program, the optimizers sees something
like..."
have you done it manualy or?
he test p != 0 is unnecessary (a patch that should help is pending
review) <- do you know the bugzilla entry?
gcc does not reduce the function call to the result if called function is not static when using -O2, only with -O3, clang and msvc do the optimization also with -O2
gcc does not reduce to call result if called function is not static in
-O2 (will do with -O2)
clang and msvc does it also in -O2 regardless of the function beeing
static or not
can someone explain to me why the -O2 optimizer is not able(allowed) to
reduce this small sample the same way as clang/msvc?
x86-64 gcc 10.2 and trunk -O2: https://godbolt.org/z/r3GM57
x86-64 clang trunk and 11.0.0 -O2: https://godbolt.org/z/8hqbz5
x64 msvc v19.27 -O2: https://godbolt.org/z/nv3rWq
code to reproduce
---
#include
// part of run length encoding...
static void v32(uint32_t v_, uint8_t* b_, int& s_)
{
if (v_ <= 0x007FU)
{
s_ = 1;
b_[0] = (uint8_t)v_;
return;
}
if (v_ <= 0x3FFFU)
{
s_ = 2;
b_[1] = (uint8_t)(v_ & 0x7F);
b_[0] = (uint8_t)((v_ >> 7) | 0x80);
return;
}
s_ = 3;
b_[2] = (uint8_t)(v_ & 0x7F);
b_[1] = (uint8_t)((v_ >> 7) | 0x80);
b_[0] = (uint8_t)((v_ >> 14) | 0x80);
return;
}
int test(uint32_t v_)
{
uint8_t b[3]{};
int s=0;
v32(v_, b, s);
return s+b[0]+b[1]+b[2];
}
int main(int argc, char** argv)
{
return test(1337); // results in 197
// clang reduces the call down to 197 regardless of test beeing
static or not
//main: # @main
// mov eax, 197
// ret
// gcc reduces the call only if test is static
//main:
// mov edi, 1337
// jmp test(unsigned int)
}
Re: gcc does not reduce the function call to the result if called function is not static when using -O2, only with -O3, clang and msvc do the optimization also with -O2
Am 05.12.2020 um 13:04 schrieb Jan Hubicka: > gcc does not reduce to call result if called function is not static in > -O2 (will do with -O2) > clang and msvc does it also in -O2 regardless of the function beeing > static or not > > can someone explain to me why the -O2 optimizer is not able(allowed) to > reduce this small sample the same way as clang/msvc? GCC is optimizing for size here, so it is more careful with inlning. This is because it knows that function main is called once. If you rename main to something else or add a loop around the call, then it will inline for speed and do same work as clang. Clang (and probaby msvc) does not implement the heuristics that certain functions (static constructors, destructors, main and noreturns) are called once so they probably both optimize for speed. Even when optimizing for size it would be good idea to inline. However the inliner heruistics predicts that it is not. This is because at the inlining time compiler does not see that calee will optimize to constant. The reason is that you store the temporary vlues to array and those are not tracked. If you used scalar variables it would be able to constant fold everything early. Handling this would require either recovering early ipa-sra or adding return functions for values passed by reference. Honza If you rename main... main -> test2 -> test test(unsigned int): moveax, edi cmpedi, 127 jbe.L3 moveax, edi ... test2(unsigned int): moveax, 197 ret main: movedi, 1337 jmptest(unsignedint) gives the expected result and that is enough for my benchmarking tests - thanks
Re: gcc does not reduce the function call to the result if called function is not static when using -O2, only with -O3, clang and msvc do the optimization also with -O2
Am 05.12.2020 um 14:25 schrieb Eric Botcazou: > can someone explain to me why the -O2 optimizer is not able(allowed) to > reduce this small sample the same way as clang/msvc? Change the name of the function to something else than "main". that works, thanks!
Re: [Regarding GCOV].gcda:stamp mismatch with notes file
Am 25.04.2024 um 08:45 schrieb Gejoe Daniel via Gcc: Hi team, The following is my query posted but would need more inputs : https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114751 The gcov tool which was working so far seems to fail with our latest branch where gcc is 11.4.0 and hence we wanted to sort this out by getting the right help as early as possible. Awaiting prompt reply. Thanks to the GCC team for all the help ! Regards, Gejoe thanks for looking at that subject - i think i also stumbled over this - thought it was something with my configuration i tried: https://github.com/mozilla/grcov as a temporary solution that worked for me - hoping the fix that maybe comes for you also helps im my case
why are these std::set iterators of different type when compiling with -D_GLIBCXX_DEBUG
using latest gcc/STL - #include using int_set1 = std::set>; using int_set2 = std::set; static_assert(std::is_same()); - the two iterators are equal when not using _GLIBCXX_DEBUG but become different when using the define?
Re: why are these std::set iterators of different type when compiling with -D_GLIBCXX_DEBUG
Am 24.07.2024 um 12:41 schrieb Jonathan Wakely: The standard says it's unspecified whether those types are the same, so portable code should not assume they are/aren't the same. I don't know for sure, but I assume somebody thought that making them different was helpful to avoid non-portable code. thanks - will try the other mailinglist
c99 does not handle -O2 but cc does?
latest SUSE Tumbleweed/gcc 14.2 c99 -O2 test.c returns: c99: invalid option -- '2' cc -O2 test.c returns successfull according to https://linux.die.net/man/1/c99 the -O2 option should work c99 is used in an older build system and that didn't work due to the -O2 problem
Re: c99 does not handle -O2 but cc does?
Am 11.10.2024 um 18:07 schrieb Jonathan Wakely: The c99 executable is provided by your distro, it's not part of GCC. Maybe it wants a space between the -O and 2, but I don't know. thanks for clearing that up does not work with spaces - will ask on the Tumbleweed list
Is there a need to sometimes change gcc/config/t-* files when building a cross compiler?
im currently trying to replicate a gcc-3.4.0 arm-elf build from an very old cross toolchain building with my script (https://pastebin.com/kAEK0S24) works but my -print-multi-lib returns only --- .; thumb;@mthumb --- the original builds -print-multi-lib returns --- .; thumb;@mthumb be;@mbig-endian fpu;@mhard-float interwork;@mthumb-interwork nofmult;@mcpu=arm7 fpu/interwork;@mhard-float@mthumb-interwork fpu/nofmult;@mhard-float@mcpu=arm7 be/fpu;@mbig-endian@mhard-float be/interwork;@mbig-endian@mthumb-interwork be/nofmult;@mbig-endian@mcpu=arm7 be/fpu/interwork;@mbig-endian@mhard-float@mthumb-interwork be/fpu/nofmult;@mbig-endian@mhard-float@mcpu=arm7 thumb/be;@mthumb@mbig-endian thumb/interwork;@mthumb@mthumb-interwork thumb/be/interwork;@mthumb@mbig-endian@mthumb-interwork --- and the configure lines getting with -v are the same i tried adding --with-float=hard --with-thumb-interwork --with-big-endian to ./configure but that doesn't changed my -print-multi-lib output is it needed that i directly change the content of my gcc-3.4.0\gcc\config\arm\t-arm-elf file to get the multi-lib options or is there a better way?
Re: Is there a need to sometimes change gcc/config/t-* files when building a cross compiler?
content of my gcc-3.4.0\gcc\config\arm\t-arm-elf https://pastebin.com/CivYHhRa Am 27.09.2024 um 09:23 schrieb Dennis Luehring via Gcc: im currently trying to replicate a gcc-3.4.0 arm-elf build from an very old cross toolchain building with my script (https://pastebin.com/kAEK0S24) works but my -print-multi-lib returns only --- .; thumb;@mthumb --- the original builds -print-multi-lib returns --- .; thumb;@mthumb be;@mbig-endian fpu;@mhard-float interwork;@mthumb-interwork nofmult;@mcpu=arm7 fpu/interwork;@mhard-float@mthumb-interwork fpu/nofmult;@mhard-float@mcpu=arm7 be/fpu;@mbig-endian@mhard-float be/interwork;@mbig-endian@mthumb-interwork be/nofmult;@mbig-endian@mcpu=arm7 be/fpu/interwork;@mbig-endian@mhard-float@mthumb-interwork be/fpu/nofmult;@mbig-endian@mhard-float@mcpu=arm7 thumb/be;@mthumb@mbig-endian thumb/interwork;@mthumb@mthumb-interwork thumb/be/interwork;@mthumb@mbig-endian@mthumb-interwork --- and the configure lines getting with -v are the same i tried adding --with-float=hard --with-thumb-interwork --with-big-endian to ./configure but that doesn't changed my -print-multi-lib output is it needed that i directly change the content of my gcc-3.4.0\gcc\config\arm\t-arm-elf file to get the multi-lib options or is there a better way?
Re: Is there a need to sometimes change gcc/config/t-* files when building a cross compiler?
Am 27.09.2024 um 09:34 schrieb Jonathan Wakely: They might not have been using the original gcc-3.4.0 sources. seems to be very possible There should be no need to edit those files, but that doesn't mean that the people who built your old toolchain didn't edit them. the other way would be using --with-multilib-list=list ? but that usage should be visible by using -v on the original build, or?
Re: Is there a need to sometimes change gcc/config/t-* files when building a cross compiler?
Am 27.09.2024 um 13:00 schrieb Richard Earnshaw (lists):
> It was very common at that time for suppliers to use slightly modified gcc
sources for microcontrollers (especially ARM, but also for other targets).
Typically manufacturers and some major third-party gcc builders were ahead of
mainline in support for some microcontroller cores and workarounds for known
hardware bugs, and they also often backported such changes from newer gcc mainline
to older gcc releases. So there is a very real chance that the sources you have
are not original.
>
> You could download the archived release from the gcc website and compare the
sources to get some idea if they have changed.
>
> And if you don't get hold of someone from Microcross, you might have luck
with someone from Code Sourcery. I believe they were doing a lot of the work on
ARM gcc on behalf of microcontroller manufacturers at that time.
>
> David
>
>
The list of multilibs for Arm has become increadibly long as the architecture
has migrated down the different (A, R, M) profiles. To handle this we now
provide some canned rules to build a set of multilibs that will handle most of
these profiles out of the box, but they can increase the overall build time
significantly, and only work correctly if you don't try to override the default
architecture flags, or change the default code generation from Arm to Thumb.
You can enable all this if you add
--with-multilib-list=
where can be any of "aprofile", "rmprofile" or "aprofile,rmprofile".
You can also see the code that supports all this (and how complex it is :) ) in
gcc/config/arm/{t-multilib,t-aprofile,t-rmprofile).
thanks, i will try that
All this is with the latest sources, but this code dates back several releases
now.
hoepfully back to 2004 :)
Re: Is there a need to sometimes change gcc/config/t-* files when building a cross compiler?
Am 27.09.2024 um 09:56 schrieb Jonathan Wakely: On Fri, 27 Sept 2024, 08:39 Dennis Luehring, wrote: > Am 27.09.2024 um 09:34 schrieb Jonathan Wakely: > > > > They might not have > > been using the original gcc-3.4.0 sources. > > > seems to be very possible > > > > > There should be no need to edit those files, but that doesn't mean that > the > > people who built your old toolchain didn't edit them. > > the other way would be using --with-multilib-list=list ? > but that usage should be visible by using -v on the original build, or? > I think so yes, but I'm not sure. If you said arm-elf in the mail Subject you might get the attention of somebody who knows the details. so just repost with a changed subject? Have you tried to obtain the sources from whoever provided the original compiler that you're trying to replicate? so far not available - the original providing company (Microcross) is long defunct (over a decade now) but im still trying to reach someone
Re: Is there a need to sometimes change gcc/config/t-* files when building a cross compiler?
Am 27.09.2024 um 11:03 schrieb David Brown: So there is a very real chance that the sources you have are not original. You could download the archived release from the gcc website and compare the sources to get some idea if they have changed. i do not have original source - only binaries, i hope that building the exact versions of binutils(2.15)/gcc(3.4.0) and newlib(1.12.0) will bring me very near to the binaries i got - maybe i can compare the build-results using assembler-code/or map diffing...
