https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115421
--- Comment #12 from Liviu Ionescu ---
However Debian 12 is not that old, what might be wrong with it? The initial
report is based on a Debian 12 run. I did another run on a physical Debian 12
and the issue is reproducible on my machine.
Isn't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115421
--- Comment #11 from Liviu Ionescu ---
I did two more runs, one on latest Raspberry Pi OS and one with latest Manjaro,
and they also passed.
So the problem seems indeed related to older systems.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115421
--- Comment #10 from Liviu Ionescu ---
> Are you sure that arch does not patch glibc to make it broken?
That run was using docker://archlinux:latest, I don't know if glibc is broken.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115421
--- Comment #8 from Liviu Ionescu ---
A small correction, the first run should be without -static:
```
$ g++ sleepy-threads-cv.cpp -o sleepy-threads-cv -g -lpthread
$ ./sleepy-threads-cv 4
abcd
$ g++ sleepy-threads-cv.cpp -o static-sleepy-threa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115421
--- Comment #5 from Liviu Ionescu ---
Here is a run on Arch, with 2.39:
```
Tests summary for gcc 13.3.0-1 on linux-x64 (Arch rolling)
394 test(s) passed, 4 failed:
- fail: static-sleepy-threads-cv-64
- fail: static-gc-sleepy-threads-cv-64
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115422
Liviu Ionescu changed:
What|Removed |Added
Status|RESOLVED|CLOSED
--- Comment #2 from Liviu Ionesc
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: ilg at livius dot net
Target Milestone: ---
I have a test that checks C++ threads which synchronise via a
condition_variable.
The test runs fine on Linux/macOS
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: ilg at livius dot net
Target Milestone: ---
Created attachment 58398
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58398&action=edit
The test source
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111632
--- Comment #33 from Liviu Ionescu ---
> Yes, it was...
Great, thank you.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111632
--- Comment #30 from Liviu Ionescu ---
(In reply to Dimitry Andric from comment #29)
> ... fixes system.h which is also included by gcov.cc
ok, great.
> Which version of gcc were you building?
in the reported bug I was building 13.2.
was the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111632
--- Comment #28 from Liviu Ionescu ---
(In reply to Francois-Xavier Coudert from comment #27)
> *** Bug 115006 has been marked as a duplicate of this bug. ***
11506 is related to gcov.cc, does the existing fixes also apply to this file?
rmal
Priority: P3
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: ilg at livius dot net
Target Milestone: ---
If I read the error message right, it looks like a mismatch between the
definitions in GCC headers and the clang C++ headers.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93602
--- Comment #13 from Liviu Ionescu ---
I'm not sure what the best solution might be, but it looks like the configure
script can detect the case when a distinct libiconv is encountered.
In this case the only thing that is needed is an explicit re
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93602
--- Comment #12 from Liviu Ionescu ---
--without-libiconv-prefix did not prevent configure to pick the new libiconv,
the behaviour was exactlly the same.
The only way I could make it pass was to completely remove the new libiconv.
Although I ca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93602
--- Comment #11 from Liviu Ionescu ---
> --without-libiconv-prefix looks promising
I'll try it tomorrow and let you know.
Thank you,
Liviu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93602
--- Comment #8 from Liviu Ionescu ---
> I would guess either /usr/local/include or ${INSTALL_FOLDER_PATH}/include
Yes, but I have exactly the same configuration when I build GCC 8.x and 7.x,
and GCC does not get confused, the problem occurred on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93602
--- Comment #6 from Liviu Ionescu ---
> I think you have libiconv installed locally, which defines the libiconv_xxx
> functions.
That's correct, I have the latest libiconv compiled from sources and GCC (like
many other programs) correctly iden
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93602
--- Comment #5 from Liviu Ionescu ---
> I think you have libiconv installed locally, which defines the libiconv_xxx
> functions.
That's correct, I have the latest libiconv compiled from sources and GCC (like
many other programs) correctly iden
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93602
--- Comment #3 from Liviu Ionescu ---
The actual configure line is:
bash ${DEBUG}
"${SOURCES_FOLDER_PATH}/${native_gcc_folder_name}/configure" \
--prefix="${INSTALL_FOLDER_PATH}" \
--program-suffix="${XBB_
++
Assignee: unassigned at gcc dot gnu.org
Reporter: ilg at livius dot net
Target Milestone: ---
I'm building GCC 9.2 on an older Ubuntu and the build is eventless, but the
resulting libstdc++ refers to some libiconv symbols, without listing a
reference to the library.
$ reade
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89249
--- Comment #6 from Liviu Ionescu ---
I upgraded my mingw to 5.0.4 and I can no longer reproduce the problem, so I
suggest we close this ticket for now and reopen if necessary.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89249
--- Comment #5 from Liviu Ionescu ---
The patch is wrong, it should read:
#if defined (__MINGW32__)
// Win32 fails to CreateProcess if spaces are escaped.
#else
lto_wrapper_file = convert_white_space (lto_wrapper_file);
#endif
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89249
--- Comment #4 from Liviu Ionescu ---
I added a printf() in pex_win32_exec_child() to see why the lto invocation
fails, and here is the result:
> pex_win32_exec_child (executable='c:/users/ilg/desktop/8.2.1
> 1.4-20190213-0923/bin/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89249
--- Comment #3 from Liviu Ionescu ---
Hi Richard,
Thank you for taking the time to investigate.
Indeed, COLLECT_LTO_WRAPPER is escaped, while COMPILER_PATH is not:
COLLECT_LTO_WRAPPER=c:/users/ilg/desktop/8.2.1\ \ \ \ \
1.4-20190207-1853/bin/.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89249
--- Comment #1 from Liviu Ionescu ---
possibly related:
- https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89066
tus: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: ilg at livius dot net
Target Milestone: ---
I know that supporting Windows was always a big pain, so I can fully understand
people not being o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89207
--- Comment #5 from Liviu Ionescu ---
Do you suggest to report this to the binutils tracker?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89207
--- Comment #4 from Liviu Ionescu ---
The linker version is 2.31.51.20181231 (Arm Embedded GCC release)
Assignee: unassigned at gcc dot gnu.org
Reporter: ilg at livius dot net
CC: marxin at gcc dot gnu.org
Target Milestone: ---
Created attachment 45607
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45607&action=edit
The elf, the map and the listing.
After
dot gnu.org
Reporter: ilg at livius dot net
CC: marxin at gcc dot gnu.org
Target Milestone: ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89183
--- Comment #3 from Liviu Ionescu ---
Thank you Andrew for your quick reply.
Yes, I'll notify Arm that a fix is available, I already registered a bug at
https://bugs.launchpad.net/gcc-arm-embedded/+bug/1814397.
In the mean time I already create
Assignee: unassigned at gcc dot gnu.org
Reporter: ilg at livius dot net
CC: marxin at gcc dot gnu.org
Target Milestone: ---
I encountered the problem while using arm-none-eabi-gcc 8-2018-q4 on a Windows
10 64-bit.
To reproduce it, create an empty main.c and try to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89166
--- Comment #3 from Liviu Ionescu ---
I tried all sort of configurations to build static executables, but I could not
find one that works while building Windows binaries (with mingw) and still
allow the liblto_plugin-0.dll to be created.
If the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89166
--- Comment #1 from Liviu Ionescu ---
a related bug is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84995
Assignee: unassigned at gcc dot gnu.org
Reporter: ilg at livius dot net
CC: marxin at gcc dot gnu.org
Target Milestone: ---
Passing -static to the GCC configure/make prevents the LTO plugin to be
properly created; the build is successful, but, for example for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84995
Liviu Ionescu changed:
What|Removed |Added
CC||ilg at livius dot net
--- Comment #19
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72792
--- Comment #9 from Liviu Ionescu ---
My allocator was defined as:
using F = memory_resource* (void);
template
class allocator_stateless_polymorphic_synchronized
I added the following inside the class:
template
struct rebind
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72792
--- Comment #6 from Liviu Ionescu ---
> If you have real world code that is affected ...
I do, it is called µOS++, and it is a C++ RTOS with advanced memory management
features, using C++17 memory resources and C++11 standard allocators:
https:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72792
Liviu Ionescu changed:
What|Removed |Added
CC||ilg at livius dot net
--- Comment #4
39 matches
Mail list logo
