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
>
>
>
> > There should be no need to e
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
14 matches
Mail list logo
