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
Liviu Ionescu changed:
What|Removed |Added
CC||ilg at livius dot net
--- Comment #4
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:
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=89249
--- Comment #1 from Liviu Ionescu ---
possibly related:
- https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89066
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\ \ \ \ \
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
>
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=89207
--- Comment #4 from Liviu Ionescu ---
The linker version is 2.31.51.20181231 (Arm Embedded GCC release)
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=89166
--- Comment #1 from Liviu Ionescu ---
a related bug is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84995
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=84995
Liviu Ionescu changed:
What|Removed |Added
CC||ilg at livius dot net
--- Comment #19
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
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=edit
The elf, the map and the listing.
After fina
dot gnu.org
Reporter: ilg at livius dot net
CC: marxin at gcc dot gnu.org
Target Milestone: ---
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
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
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.
++
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.
$ readelf -s
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
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
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}" \
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
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 #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
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
27 matches
Mail list logo
