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
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 #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 #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
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
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
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 ---
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.
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=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
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
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
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
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. ***
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 #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://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 #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 47128
--> 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 47127
--> https://gcc.gnu.org/bugzi
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=92272
--- Comment #1 from fdlbxtqi ---
*** Bug 92273 has been marked as a duplicate of this bug. ***
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=edit
The bugged code
I tried the same code with gcc 9.2, cl
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
--- Comment #3 from fdlbxtqi ---
(In reply to fdlbxtqi from comment #2)
> Should be
Should be warning message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92670
fdlbxtqi changed:
What|Removed |Added
Summary|Same error message |Same warning message
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.
-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/libgcc
: unassigned at gcc dot gnu.org
Reporter: euloanty at live dot com
Target Milestone: ---
//This code should not compile because it is UB. delete a int[1]
constexpr int f()
{
auto p(new int[1]);
delete p;
return 4;
}
int main()
{
constexpr auto w(f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93668
--- Comment #1 from fdlbxtqi ---
constexpr int f()
{
auto p(new int[1]);
delete p;
return 4;
}
int main()
{
constexpr auto w(f());
}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94013
--- Comment #5 from fdlbxtqi ---
(In reply to fdlbxtqi from comment #4)
> I noticed LLVM's libc++ has the same issue when I did the test to libstdc++.
> However, their bug reporting port has closed. How can I report that?
>
> It is amazing that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94013
--- Comment #4 from fdlbxtqi ---
I noticed LLVM's libc++ has the same issue when I did the test to libstdc++.
However, their bug reporting port has closed. How can I report that?
It is amazing that two mainstream C++ standard library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93059
--- Comment #39 from fdlbxtqi ---
(In reply to Jonathan Wakely from comment #38)
> We could also use memcmp for std::equal when it's using std::equal_to<> or
> std::equal_to<_ValueType1> or std::equal_to<_ValueType2>, and for
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93059
--- Comment #40 from fdlbxtqi ---
to_address(__first),to_address(__second)
to_address(__first1),to_address(__first2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93059
--- Comment #41 from fdlbxtqi ---
(In reply to Jonathan Wakely from comment #38)
> We could also use memcmp for std::equal when it's using std::equal_to<> or
> std::equal_to<_ValueType1> or std::equal_to<_ValueType2>, and for
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93059
--- Comment #45 from fdlbxtqi ---
(In reply to Jonathan Wakely from comment #43)
> (In reply to fdlbxtqi from comment #39)
> > const auto __c = __builtin_memcmp(&*__first1, &*__first2, __len) <=> 0;
>
> Are you mistakenly reading this as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94013
--- Comment #1 from fdlbxtqi ---
Yeah. It looks like libc++ has the same bug. LOL.
volatile is really stupid tbh.
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: euloanty at live dot com
Target Milestone: ---
Created attachment 47819
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47819=edit
Officially support std::thread on wind
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: euloanty at live dot com
Target Milestone: ---
MCF gthread is an NT syscall level of std::thread on windows to support POSIX
semantics.
https://github.com/lhmouse/mcfgthread
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93668
--- Comment #7 from fdlbxtqi ---
I mean it is a bug.
constexpr int f()
{
auto p(new int[1]);
delete p;
return 4;
}
int main()
{
constexpr auto w(f());
}
I mean this is UB so it should not compile. However,
=-Wstringop-overflow=m]
Product: gcc
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93232
--- Comment #2 from fdlbxtqi ---
(In reply to Andrew Pinski from comment #1)
> Can you attach the preprocessed source?
>
> This might be a dup of bug 92955.
The source is here:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93297
--- Comment #3 from fdlbxtqi ---
(In reply to Martin Liška from comment #2)
> Thanks for the report. Can you please send us the command line used for the
> compilation? Ideally output of -v option.
g++ -o xxx xxx.cc -Ofast -std=c++2a -s -msse2
, ice-on-invalid-code, ice-on-valid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: euloanty at live dot com
Target Milestone: ---
sha1.cc: In function ‘int main()’:
sha1.cc:7:90: internal compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93297
fdlbxtqi changed:
What|Removed |Added
CC||euloanty at live dot com
--- Comment #1 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93297
--- Comment #5 from fdlbxtqi ---
(In reply to Martin Liška from comment #4)
> (In reply to fdlbxtqi from comment #3)
> > (In reply to Martin Liška from comment #2)
> > > Thanks for the report. Can you please send us the command line used for
>
at gcc dot gnu.org
Reporter: euloanty at live dot com
Target Milestone: ---
g++ -o coroutine_epoll coroutine_epoll.cc -Ofast -std=c++2a -s -fcoroutines
coroutine_epoll.cc: In function ‘void
_Z6listenRN7fast_io16basic_tcp_serverILb1EEE.actor(listen(fast_io::async_tcp_server
: 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
fdlbxtqi changed:
What|Removed |Added
Attachment #47559|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93095
fdlbxtqi changed:
What|Removed |Added
Status|WAITING |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=93060
fdlbxtqi changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
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
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
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*
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=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)
{
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
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)
> > {
> >
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
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
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 #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
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
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
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=edit
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 #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 #25 from fdlbxtqi ---
Created attachment 47560
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47560=edit
forgot to_address
2nd patch
I am going to run testsuites
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 #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)
> > {
> >
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)
> > {
> >
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=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 it
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=edit
Testsuite
Testsuite :
cqwrteur@DESKTOP-7H7UHQ9:~/libstdcpp_testsuite$ runtest --tool libstdc++
Using
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93059
--- Comment #32 from fdlbxtqi ---
(In reply to Bernd Edlinger from comment #31)
> Yes, you usually need to make a full bootstrap / make check twice
> which the same svn revision one with and one without your patch.
> You also should make sure
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=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
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
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=edit
Let me try whether this patch works.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94268
--- Comment #9 from fdlbxtqi ---
https://github.com/microsoft/WSL/issues/3898
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=edit
Picture bug
printf works while iostream does not since it links to GetTickCount64.
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=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
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
--- 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://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
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
fdlbxtqi changed:
What|Removed |Added
Host||Windows 10. MinGW-W64
Target|
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
1 - 100 of 169 matches
Mail list logo
