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

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: [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

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: 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

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

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

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

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; 

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

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

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

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

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

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?

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,

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

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

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

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: 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: $

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"

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

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.

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

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

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

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

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 vector #include numeric #include array #define USE_ARRAY #if defined(USE_ARRAY) static int calc(const