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
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
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
mainli
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 ho
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
>
&
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
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
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-endi
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.
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?
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
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!
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(allo
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/m
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
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
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;
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
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 p
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
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,
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
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?
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,
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 (l
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 memo
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:
is the patch already integrated into mainline?
is this the most recent development place?
https://github.com/tkchia/gcc-ia16
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.
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"
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
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 t
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&#
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
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 U
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
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_
37 matches
Mail list logo
