Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: euloanty at live dot com
Target Milestone: ---
Even the hacks work the same result.
https
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94268
fdlbxtqi changed:
What|Removed |Added
Host||Windows 10. MinGW-W64
Target|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94268
--- Comment #2 from fdlbxtqi ---
The hacking code is here.
https://bitbucket.org/ejsvifq_mabmip/fast_io/src/reserver_test/include/fast_io_legacy_impl/cpp/libstdc%2B%2B_libc%2B%2B.h
https://bitbucket.org/ejsvifq_mabmip/fast_io/src/reserver_test/i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94268
--- Comment #3 from fdlbxtqi ---
I have found out the reason. It is because the buffer size is too small on the
windows. BUFSIZ == 512
You need to set the value to 4096 at least. I think even 65536 is something
should be done since the windows s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94268
--- Comment #4 from fdlbxtqi ---
(In reply to fdlbxtqi from comment #3)
> I have found out the reason. It is because the buffer size is too small on
> the windows. BUFSIZ == 512
>
> You need to set the value to 4096 at least. I think even 65536
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94268
--- Comment #5 from fdlbxtqi ---
Here is the proof.
https://bitbucket.org/ejsvifq_mabmip/fast_io/src/reserver_test/benchmarks/.10m_size_t/unit/streambuf_io_observer___gnu_cxx_stdio_filebuf.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94268
--- Comment #6 from fdlbxtqi ---
Created attachment 48086
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48086&action=edit
simple patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94268
--- Comment #7 from fdlbxtqi ---
I rebuilt a new GCC with this patch. The performance improves for 10 times for
output integer. 3 times for input integer. Definitely worth it.
D:\hg\w4\f8\fast_io\benchmarks\.10m_size_t\unit>gcc --version
gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94268
--- Comment #8 from fdlbxtqi ---
Well. These links are dead. Repost them.
https://bitbucket.org/ejsvifq_mabmip/fast_io/src/master/benchmarks/.10m_size_t/unit/filebuf_io_observer.cc
https://bitbucket.org/ejsvifq_mabmip/fast_io/src/master/bench
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94268
--- Comment #9 from fdlbxtqi ---
https://github.com/microsoft/WSL/issues/3898
Priority: P3
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: euloanty at live dot com
Target Milestone: ---
In file included from ../../gcc-git/intl/plural.y:35:
../../gcc-git/intl/plural-exp.h:102:23: error: conflicting types for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94601
--- Comment #1 from fdlbxtqi ---
Can you guys stop using macros and migrate to namespace?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94601
--- Comment #4 from fdlbxtqi ---
Created attachment 48276
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48276&action=edit
Let me try whether this patch works.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92008
--- Comment #7 from fdlbxtqi ---
(In reply to Andrew Pinski from comment #6)
> https://github.com/zerovm/glibc/commit/9f3f5229848390ae921f77c92f666ca6f0bff
>
> is more the correct fix.
> Or use an older version of Bison.
But I am using windows.
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: euloanty at live dot com
Target Milestone: ---
libstdc++ could not work on the old win32 operating systems (32 bit) because
dll does not have
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95170
--- Comment #1 from fdlbxtqi ---
Created attachment 48550
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48550&action=edit
Picture bug
printf works while iostream does not since it links to GetTickCount64.
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: euloanty at live dot com
Target Milestone: ---
#include
#include
int main()
{
std::mt19937_64 eng;
std::uniform_real_distribution dis(-1.0f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95286
fdlbxtqi changed:
What|Removed |Added
Host|amd ryzen 2700. Linux, |Amd ryzen 2700. Linux,
|Min
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95286
fdlbxtqi changed:
What|Removed |Added
Target|Amd ryzen 2700. Linux, |Amd ryzen 3600. Linux,
|Min
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95286
--- Comment #3 from fdlbxtqi ---
#include
#include
#include
int main()
{
std::mt19937_64 eng;
std::uniform_real_distribution dis(-1.0f,1.0f);
float v{};
for(std::size_t i(0);i!=36;++i)
v=di
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95286
--- Comment #4 from fdlbxtqi ---
I test on another Amd ryzen computer. Same issue here. Why???
cqwrteur@Home-Server:~/fast_io_all/fast_io/helpers/fp$ g++ -o dontagree
dontagree.cc -Ofast -std=c++20 -s -march=native
cqwrteur@Home-Server:~/fast_i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95286
--- Comment #5 from fdlbxtqi ---
I tried other architectures. Same issues here. WHY???
cqwrteur@Home-Server:~/fast_io_all/fast_io/helpers/fp$ g++ -o dontagree
dontagree.cc -Ofast -std=c++20 -s -march=x86-64
cqwrteur@Home-Server:~/fast_io_all/fas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94268
--- Comment #10 from fdlbxtqi ---
What about adding another check when BUFSIZ is smaller than 4KB? If it is
smaller than 4kb, adjust the filebuf size to 4kb at least.
NCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: euloanty at live dot com
Target Milestone: ---
$ ../gcc/configure --with-pkgversion=cqwrteur --enable-multilib
--enable-languages=c,c++,f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95402
--- Comment #2 from fdlbxtqi ---
(In reply to Jakub Jelinek from comment #1)
> As mentioned in https://gcc.gnu.org/install/prerequisites.html one needs to
> use GNU make to build gcc, are you sure make is a GNU make?
Really? LLVM also provides a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95402
--- Comment #3 from fdlbxtqi ---
(In reply to Jakub Jelinek from comment #1)
> As mentioned in https://gcc.gnu.org/install/prerequisites.html one needs to
> use GNU make to build gcc, are you sure make is a GNU make?
So sad nowadays LLVM just co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95402
--- Comment #4 from fdlbxtqi ---
(In reply to Jakub Jelinek from comment #1)
> As mentioned in https://gcc.gnu.org/install/prerequisites.html one needs to
> use GNU make to build gcc, are you sure make is a GNU make?
g++ -fno-PIE -c -g -O2 -D
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: euloanty at live dot com
Target Milestone: ---
.file "helloworld_linux_writev.cc"
.text
.p2align 4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95917
--- Comment #1 from fdlbxtqi ---
void __dummy_resume_destroy() __attribute__((__weak__));
void __dummy_resume_destroy() {}
struct __noop_coro_frame
{
void (*__r)() = __dummy_resume_destroy;
void (*__d)() = __dummy_resume_destroy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95917
--- Comment #2 from fdlbxtqi ---
This makes me mad.
I compiled this under freestanding mode. Now coroutine causes binary bloat
which is completely unacceptable for me.
The problem of C++ is that you have to always write inline to undo the brain
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95917
--- Comment #3 from fdlbxtqi ---
Jonathan. I am MAD at you. This is absolutely your fault. I told you to always
write inline and you guys do not then allow Herb Sutter to ban me. Here is the
fault in your own controlled codebase. Are you satisfie
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95917
--- Comment #5 from fdlbxtqi ---
(In reply to Iain Sandoe from comment #4)
> (In reply to fdlbxtqi from comment #3)
> > Jonathan. I am MAD at you. This is absolutely your fault. I told you to
> > always write inline and you guys do not then allow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95917
--- Comment #6 from fdlbxtqi ---
(In reply to Iain Sandoe from comment #4)
> (In reply to fdlbxtqi from comment #3)
> > Jonathan. I am MAD at you. This is absolutely your fault. I told you to
> > always write inline and you guys do not then allow
: unassigned at gcc dot gnu.org
Reporter: euloanty at live dot com
Target Milestone: ---
#include
#include
template struct pack {};
template struct uv : std::false_type {};
template struct uv> {
using type = pack;
};
template
concept is_any_of_impl_4 = requires(pack) {
requi
: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: euloanty at live dot com
Target Milestone: ---
https://godbolt.org/z/haG4E7
https://godbolt.org/z/M8e7Kb
First:
#include
#include
#include
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: euloanty at live dot com
Target Milestone: ---
https://godbolt.org/z/9K3369
#include
#include
struct number
{
std::array num
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: euloanty at live dot com
Target Milestone: ---
Created attachment 47118
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47118&action=edit
The bugged code
I tried the same code with
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: euloanty at live dot com
Target Milestone: ---
In file included from
../../../.././libsanitizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92248
fdlbxtqi changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92247
--- Comment #1 from fdlbxtqi ---
*** Bug 92248 has been marked as a duplicate of this bug. ***
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: euloanty at live dot com
Target Milestone: ---
In file included from
../../../.././libsanitizer/sanitizer_common/sanitizer_linux.cpp:162:
../../../.././libsanitizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92247
--- Comment #4 from fdlbxtqi ---
It sounds like it is a huge bug. I am using windows insider + wsl2. The problem
can even be observed on native windows.
I hope it could be fixed as soon as possible, or I could not build new
version's GCC on any
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92247
--- Comment #5 from fdlbxtqi ---
https://github.com/torvalds/linux/commit/a0673fdbcd42105261646cd4f3447455b5854a32
It looks like all these system calls are removed in unistd.h in Linux kernel.
/*
* All syscalls below here should go away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92247
--- Comment #6 from fdlbxtqi ---
I have examined the source code of the unistd.h in Microsoft WSL2. The same
thing, these syscalls were removed as well.
https://github.com/microsoft/WSL2-Linux-Kernel/blob/7fec2bd4a7fd7a952e3e5ea2202bef963aa4781d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92247
--- Comment #8 from fdlbxtqi ---
Line 211
#ifndef SANITIZER_USES_CANONICAL_LINUX_SYSCALLS
# if defined(__aarch64__) && SANITIZER_LINUX
# define SANITIZER_USES_CANONICAL_LINUX_SYSCALLS 1
# else
# define SANITIZER_USES_CANONICAL_LINUX_SYSCALLS 0
#
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: euloanty at live dot com
CC: jwakely at redhat dot com
Target Milestone: ---
Created attachment 47127
--> https://gcc.gnu.org/bugzi
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: euloanty at live dot com
CC: jwakely at redhat dot com
Target Milestone: ---
Created attachment 47128
--> https://gcc.gnu.org/bugzi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92272
--- Comment #1 from fdlbxtqi ---
*** Bug 92273 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92273
fdlbxtqi changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92247
fdlbxtqi changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92247
fdlbxtqi changed:
What|Removed |Added
Resolution|WORKSFORME |INVALID
--- Comment #11 from fdlbxtqi ---
No
sion: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: euloanty at live dot com
Target Milestone: ---
/d/mw/mingw-gcc-mcf-gthread/src/build-x86_64-w64-mingw32/./gcc/xg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92296
--- Comment #1 from fdlbxtqi ---
Here are the patches I am using from msys2.
https://bitbucket.org/ejsvifq_mabmip/mingw-gcc-mcf-gthread/src/master/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92296
--- Comment #3 from fdlbxtqi ---
(In reply to Andrew Pinski from comment #2)
> Most likely the reduced testcase is just:
> #pragma push_macro("__has_builtin")
>
> --- CUT ---
> > I did finish compilation with the same script 3 days ago. Now It f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92296
--- Comment #4 from fdlbxtqi ---
(In reply to Andrew Pinski from comment #2)
> Most likely the reduced testcase is just:
> #pragma push_macro("__has_builtin")
>
> --- CUT ---
> > I did finish compilation with the same script 3 days ago. Now It f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92296
--- Comment #6 from fdlbxtqi ---
(In reply to fdlbxtqi from comment #4)
> (In reply to Andrew Pinski from comment #2)
> > Most likely the reduced testcase is just:
> > #pragma push_macro("__has_builtin")
> >
> > --- CUT ---
> > > I did finish co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92296
--- Comment #7 from fdlbxtqi ---
(In reply to Andrew Pinski from comment #5)
> >Then how can I build a new version of GCC on MinGW? :(
>
> Wait for the bug to fixed. Bugs happen. Most people compiling the trunk
> don't build using mingw. You
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92296
--- Comment #8 from fdlbxtqi ---
(In reply to Andrew Pinski from comment #5)
> >Then how can I build a new version of GCC on MinGW? :(
>
> Wait for the bug to fixed. Bugs happen. Most people compiling the trunk
> don't build using mingw. You
ty: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: euloanty at live dot com
Target Milestone: ---
Here is an example:
[[deprecated("sha1 is no longer a secure algorithm, see wikipedia. The
SHAppening: https://en.wikipedia
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92670
--- Comment #1 from fdlbxtqi ---
The same error message generates twice.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92670
fdlbxtqi changed:
What|Removed |Added
Summary|Same error message |Same warning message
|dupli
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92670
--- Comment #3 from fdlbxtqi ---
(In reply to fdlbxtqi from comment #2)
> Should be
Should be warning message
-invalid
Severity: normal
Priority: P3
Component: libgcc
Assignee: unassigned at gcc dot gnu.org
Reporter: euloanty at live dot com
Target Milestone: ---
make[3]: Entering directory
'/home/cqwrteur/gcc-riscv64-build/riscv64-linux-gnu/libgc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92709
--- Comment #2 from fdlbxtqi ---
(In reply to Richard Biener from comment #1)
> The actual error is missing from the log.
Yea. It has no actual error. I have checked that.
Keywords: EH
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: euloanty at live dot com
Target Milestone: ---
This paper shows the possibility of optimizing the current exception model.
Just
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92823
--- Comment #2 from fdlbxtqi ---
(In reply to Richard Biener from comment #1)
> It's called "exception" handling. If you use an "exception" on the fast path
> you are doing something wrong.
Have you read recent papers about deterministic except
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92823
--- Comment #3 from fdlbxtqi ---
(In reply to Richard Biener from comment #1)
> It's called "exception" handling. If you use an "exception" on the fast path
> you are doing something wrong.
If this succeeds, we will be able to directly use POSI
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: euloanty at live dot com
Target Milestone: ---
#include
#include
#include
int main
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92823
--- Comment #4 from fdlbxtqi ---
I know it is mostly a clang bug. However, jwakely you can try to use clang to
test your code.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92850
--- Comment #2 from fdlbxtqi ---
(In reply to Andrew Pinski from comment #1)
> The crash itself should report to llvm project for sure.
>
> Are you sure concepts are fully implemented in clang?
Yea. I know it is an LLVM bug and should be report
: unassigned at gcc dot gnu.org
Reporter: euloanty at live dot com
Target Milestone: ---
https://godbolt.org/z/SPktTz
All these functions should generate exactly the same assembly but they do not.
GCC does not treat char and char8_t the same because libstdc++ does not do this
check. I did my
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93059
--- Comment #1 from fdlbxtqi ---
I am going to rewrite these functions by C++20 concepts + if constexpr for
C++20 for you, Jwakely. I do not believe these enable-if/ overloading functions
would not be a problem.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93059
--- Comment #2 from fdlbxtqi ---
Also find a bug of __memmove
/*
* A constexpr wrapper for __builtin_memmove.
* @param __num The number of elements of type _Tp (not bytes).
*/
template
_GLIBCXX14_CONSTEXPR
inline void*
_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93059
--- Comment #3 from fdlbxtqi ---
https://github.com/gcc-mirror/gcc/blob/master/libstdc%2B%2B-v3/include/bits/stl_algobase.h
I have found out the problem.
1. libstdc++ does not use memmove for different trivially copyable objects. It
only uses i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93059
--- Comment #4 from fdlbxtqi ---
A demo fix would be like this i think:
template
inline constexpr output_iter my_copy_n(input_iter first,std::size_t
count,output_iter result)
{
using input_value_type = typename
std::iterator_traits::value_ty
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: euloanty at live dot com
Target Milestone: ---
Host: GCC 10
https://en.cppreference.com/w/cpp/types/is_integral
:5:20: error: static assertion failed
5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93060
fdlbxtqi changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93060
--- Comment #2 from fdlbxtqi ---
(In reply to Andrew Pinski from comment #1)
> >extended integer types
>
> Because it is not an extended integer type.
Ok. Thank you for your answer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93059
--- Comment #6 from fdlbxtqi ---
> What operation are you doing on vector? None of your testcases seem to use
> it.
void copy_char_vector_with_iter(std::vector::iterator
out,std::vector const& bits)
{
std::copy_n(bits.begin(),bits.size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93059
--- Comment #10 from fdlbxtqi ---
(In reply to fdlbxtqi from comment #9)
> (In reply to Marc Glisse from comment #8)
> > (In reply to fdlbxtqi from comment #6)
> > > void copy_char_vector_with_iter(std::vector::iterator
> > > out,std::vector cons
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93059
--- Comment #9 from fdlbxtqi ---
(In reply to Marc Glisse from comment #8)
> (In reply to fdlbxtqi from comment #6)
> > void copy_char_vector_with_iter(std::vector::iterator
> > out,std::vector const& bits)
> > {
> > std::copy_n(bits.begin(),
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93059
--- Comment #11 from fdlbxtqi ---
(In reply to Marc Glisse from comment #8)
> (In reply to fdlbxtqi from comment #6)
> > void copy_char_vector_with_iter(std::vector::iterator
> > out,std::vector const& bits)
> > {
> > std::copy_n(bits.begin()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93059
--- Comment #12 from fdlbxtqi ---
(In reply to Marc Glisse from comment #8)
> (In reply to fdlbxtqi from comment #6)
> > void copy_char_vector_with_iter(std::vector::iterator
> > out,std::vector const& bits)
> > {
> > std::copy_n(bits.begin()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93059
--- Comment #14 from fdlbxtqi ---
I think It is worth the effort to rewrite these functions since they are so
fundamental to the performance of entire C++. What I am worry about is that
whether revamping these functions would be a new ABI breakin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93059
--- Comment #15 from fdlbxtqi ---
(In reply to fdlbxtqi from comment #14)
> I think It is worth the effort to rewrite these functions since they are so
> fundamental to the performance of entire C++. What I am worry about is that
> whether revamp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93059
--- Comment #16 from fdlbxtqi ---
(In reply to Marc Glisse from comment #13)
> (In reply to fdlbxtqi from comment #11)
> > TBH. I would rather see the library does the optimization instead of the
> > compiler. I do not trust the compiler can alwa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93059
--- Comment #18 from fdlbxtqi ---
(In reply to Marc Glisse from comment #17)
> (In reply to fdlbxtqi from comment #15)
> > What I am worried about is that whether revamping these functions would be
> > a new wave of ABI breaking.
>
> I don't fo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93059
--- Comment #19 from fdlbxtqi ---
Created attachment 47559
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47559&action=edit
An untested patch
From 1dfd714e1f29e229d69a0c7f6f84bf05dd4ee85d Mon Sep 17 00:00:00 2001
From: expnkx
Date: Sun, 2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93059
--- Comment #20 from fdlbxtqi ---
Comment on attachment 47559
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47559
An untested patch
>From 1dfd714e1f29e229d69a0c7f6f84bf05dd4ee85d Mon Sep 17 00:00:00 2001
>From: expnkx
>Date: Sun, 29 Dec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93059
--- Comment #23 from fdlbxtqi ---
Comment on attachment 47559
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47559
An untested patch
>From 1dfd714e1f29e229d69a0c7f6f84bf05dd4ee85d Mon Sep 17 00:00:00 2001
>From: expnkx
>Date: Sun, 29 Dec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93059
--- Comment #22 from fdlbxtqi ---
Comment on attachment 47559
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47559
An untested patch
>From 1dfd714e1f29e229d69a0c7f6f84bf05dd4ee85d Mon Sep 17 00:00:00 2001
>From: expnkx
>Date: Sun, 29 Dec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93059
--- Comment #21 from fdlbxtqi ---
Comment on attachment 47559
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47559
An untested patch
>From 1dfd714e1f29e229d69a0c7f6f84bf05dd4ee85d Mon Sep 17 00:00:00 2001
>From: expnkx
>Date: Sun, 29 Dec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93059
--- Comment #24 from fdlbxtqi ---
Comment on attachment 47559
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47559
An untested patch
>From 1dfd714e1f29e229d69a0c7f6f84bf05dd4ee85d Mon Sep 17 00:00:00 2001
>From: expnkx
>Date: Sun, 29 Dec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93059
--- Comment #25 from fdlbxtqi ---
Created attachment 47560
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47560&action=edit
forgot to_address
2nd patch
I am going to run testsuites
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: euloanty at live dot com
Target Milestone: ---
g++ -fno-PIE -c -g -O2 -DIN_GCC -fno-exceptions -fno-rtti
-fasynchronous
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93095
--- Comment #2 from fdlbxtqi ---
(In reply to Jakub Jelinek from comment #1)
> Can't reproduce and don't see anything problematic on that code.
> Unless e.g. the system headers are defining throws as a macro, can you e.g.
> attach preprocessed gi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93059
--- Comment #27 from fdlbxtqi ---
(In reply to Bernd Edlinger from comment #26)
> (In reply to fdlbxtqi from comment #2)
> > Also find a bug of __memmove
> >
> > /*
> >* A constexpr wrapper for __builtin_memmove.
> >* @param __num The
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93059
--- Comment #28 from fdlbxtqi ---
Created attachment 47570
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47570&action=edit
Testsuite
Testsuite :
cqwrteur@DESKTOP-7H7UHQ9:~/libstdcpp_testsuite$ runtest --tool libstdc++
Using ../gcc/libstd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93059
--- Comment #29 from fdlbxtqi ---
(In reply to Marc Glisse from comment #17)
> (In reply to fdlbxtqi from comment #15)
> > What I am worried about is that whether revamping these functions would be
> > a new wave of ABI breaking.
>
> I don't fo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93059
--- Comment #30 from fdlbxtqi ---
Created attachment 47571
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47571&action=edit
Here is my stl_algobase.h after patch. You can try it directly.
Here is my stl_algobase.h after patch. You can try
1 - 100 of 169 matches
Mail list logo
