https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98327
fdlbxtqi changed:
What|Removed |Added
CC||nathan at gcc dot gnu.org
--- Comment #1 from
: unassigned at gcc dot gnu.org
Reporter: euloanty at live dot com
Target Milestone: ---
cqwrteur@Home-Server:~/w/working$ g++ -o hello hello.cc -std=c++20
-fmodules-ts
hello.cc:4:8: internal compiler error: Segmentation fault
4 | export module hello
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98300
--- Comment #9 from fdlbxtqi ---
(In reply to Nathan Sidwell from comment #6)
> Created attachment 49769 [details]
> potential patch
>
> Care to give this patch a try?
hello??
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98300
--- Comment #8 from fdlbxtqi ---
(In reply to Nathan Sidwell from comment #6)
> Created attachment 49769 [details]
> potential patch
>
> Care to give this patch a try?
make[2]: Leaving directory
'/home/unlvs/mingw-gcc-mcf-gthread/src/build-x86_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98300
--- Comment #7 from fdlbxtqi ---
(In reply to Nathan Sidwell from comment #6)
> Created attachment 49769 [details]
> potential patch
>
> Care to give this patch a try?
I will help you. no problem.
BTW. Welcome to join discord so I can show you
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98300
--- Comment #5 from fdlbxtqi ---
(In reply to Nathan Sidwell from comment #3)
> Hm, I thought there was sufficient #ifing to prevent that ...
BTW. I tried the example you showed on the GCC module webpage on Linux. It
fails to compile. why?
cqw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98300
--- Comment #4 from fdlbxtqi ---
(In reply to Nathan Sidwell from comment #3)
> Hm, I thought there was sufficient #ifing to prevent that ...
Try the compiler I build before to guard against this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98300
--- Comment #2 from fdlbxtqi ---
Here was an older version (GCC11 20201204) that can be used for bootstrapping.
Please, thank you for fixing this issue ASAP.
https://bitbucket.org/ejsvifq_mabmip/mingw-gcc/src/master/
,
||windows 10
Host||x86_64-msys2-mingw-w64,
||windows 10
CC||euloanty at live dot com
--- Comment #1 from fdlbxtqi ---
The assumption of
Severity: normal
Priority: P3
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: euloanty at live dot com
Target Milestone: ---
x86_64-w64-mingw32-g++ -fno-PIE -c -DIN_GCC_FRONTEND -march=x86-64
-mtune=generic -O2 -pipe -DIN_GCC -fno
: unassigned at gcc dot gnu.org
Reporter: euloanty at live dot com
Target Milestone: ---
| ^
../include/llvm/ADT/SparseBitVector.h:54:11: note: while referencing
'llvm::SparseBitVectorElement<128>::Bits'
54 | BitWord Bits[BITWORDS_PER_ELEMENT];
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97622
fdlbxtqi changed:
What|Removed |Added
Resolution|--- |INVALID
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97622
--- Comment #3 from fdlbxtqi ---
(In reply to Jakub Jelinek from comment #1)
> Why do you think it is a bug?
> Yes, it prints the opening quote, then
> while (deref_depth-- > 0)
> pp_star (&pretty_name);
> prints some * characters a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97622
--- Comment #2 from fdlbxtqi ---
(In reply to Jakub Jelinek from comment #1)
> Why do you think it is a bug?
> Yes, it prints the opening quote, then
> while (deref_depth-- > 0)
> pp_star (&pretty_name);
> prints some * characters a
Priority: P3
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: euloanty at live dot com
Target Milestone: ---
'%s%s%s. no. it should be \'%s%s%s%s%s%s%s???
pp_printf (&pretty_name, "'%s%s%s%s%s%s%s",
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97550
--- Comment #2 from fdlbxtqi ---
cp/cp-lang.o c-family/stub-objc.o cp/call.o cp/class.o cp/constexpr.o
cp/constraint.o cp/coroutines.o cp/cp-gimplify.o cp/cp-objcp-common.o
cp/cp-ubsan.o cp/cvt.o cp/cxx-pretty-print.o cp/decl.o cp/decl2.o c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97620
--- Comment #3 from fdlbxtqi ---
(In reply to Martin Sebor from comment #2)
> This is almost certainly caused by an incomplete charset, same as in pr82700.
>
> *** This bug has been marked as a duplicate of bug 82700 ***
Then provide a better e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97620
--- Comment #1 from fdlbxtqi ---
Program:
#include
int main()
{
printf("Hello World %d\n",6);
}
Assignee: dmalcolm at gcc dot gnu.org
Reporter: euloanty at live dot com
Target Milestone: ---
gcc -o stdio stdio.c -s -O2 -fexec-charset=IBM16804
during GIMPLE pass: strlen
stdio.c: In function 'main':
stdio.c:7: internal compiler error: converting to execution cha
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: euloanty at live dot com
Target Milestone: ---
during RTL pass: expand
../../../gcc/libgcc/libgcc2.c: In function '__mulxc3':
../../../gcc/libgcc/libgcc2.c:1989:10: internal comp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97499
--- Comment #1 from fdlbxtqi ---
/gcc_dos_build/./gcc/xgcc -B/gcc_dos_build/./gcc/
-B/i586-pc-msdosdjgpp/i586-pc-msdosdjgpp/bin/
-B/i586-pc-msdosdjgpp/i586-pc-msdosdjgpp/lib/ -isystem
/i586-pc-msdosdjgpp/i586-pc-msdosdjgpp/include -isystem
/i586-
Assignee: unassigned at gcc dot gnu.org
Reporter: euloanty at live dot com
Target Milestone: ---
../../../gcc/libgcc/config/i386/sfp-exceptions.c: In function
'__sfp_handle_exceptions':
../../../gcc/libgcc/config/i386/sfp-exceptions.c:71:7: internal compiler error:
Segmenta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97481
--- Comment #5 from fdlbxtqi ---
(In reply to Jim Wilson from comment #2)
> riscv-unknown-linux-gnu is not a supported target. You must use either
> riscv32-unknown-linux-gnu or riscv64-unknwon-linux-gnu. Both compilers
> support both word size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97481
--- Comment #4 from fdlbxtqi ---
(In reply to Jim Wilson from comment #2)
> riscv-unknown-linux-gnu is not a supported target. You must use either
> riscv32-unknown-linux-gnu or riscv64-unknwon-linux-gnu. Both compilers
> support both word size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97481
--- Comment #3 from fdlbxtqi ---
(In reply to Jim Wilson from comment #2)
> riscv-unknown-linux-gnu is not a supported target. You must use either
> riscv32-unknown-linux-gnu or riscv64-unknwon-linux-gnu. Both compilers
> support both word size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97481
--- Comment #1 from fdlbxtqi ---
Created attachment 49395
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49395&action=edit
riscv ICE
Assignee: unassigned at gcc dot gnu.org
Reporter: euloanty at live dot com
Target Milestone: ---
unlvs@DESKTOP-DFHPDC1 MINGW64 /glibc_riscv_build
$ ../glibc_riscv/configure --prefix=${PREFIX}/${TARGET} --build=$(gcc
-dumpmachine) --host=${TARGET} --target=${TARGET} --disable
: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: euloanty at live dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97465
--- Comment #3 from fdlbxtqi ---
(In reply to Jonathan Wakely from comment #2)
> e.g. what kind of cross build? We're not psychic.
I try to build x86_64-linux-gnu to x86_64-linux-gnu lol since I do not want vtv
to ruin my ABIs.
However, after I
: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: euloanty at live dot com
Target Milestone: ---
./../libstdc++-v3/include/x86_64-cross-linux/bits/os_defines.h:39:10: fatal
error: features.h: No such file or directory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97437
--- Comment #4 from fdlbxtqi ---
(In reply to Jakub Jelinek from comment #1)
> I don't see anything undesirable on that. The 0 aka %rax is used in 7
> different instructions later on besides the move, so either we just clear
> %ecx (can't use xo
: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: euloanty at live dot com
Target Milestone: ---
#include
#include
#if defined(_MSC_VER)
#include
#elif defined(__x86_64__) || defined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97387
--- Comment #14 from fdlbxtqi ---
(In reply to fdlbxtqi from comment #13)
> https://godbolt.org/z/fqGrz1
>
> After this patch, the assembly generated is much better now. However, it
> still contains many optimization problems.
>
> The problem i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97387
--- Comment #13 from fdlbxtqi ---
https://godbolt.org/z/fqGrz1
After this patch, the assembly generated is much better now. However, it still
contains many optimization problems.
The problem is the code like this.
Let's just walk through the a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97387
--- Comment #12 from fdlbxtqi ---
(In reply to CVS Commits from comment #11)
> The master branch has been updated by Jakub Jelinek :
>
> https://gcc.gnu.org/g:06bec55e80d98419121f3998d98d969990a75b0b
>
> commit r11-3882-g06bec55e80d98419121f399
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97409
--- Comment #4 from fdlbxtqi ---
(In reply to Andrew Pinski from comment #3)
> (In reply to fdlbxtqi from comment #2)
> > (In reply to Andrew Pinski from comment #1)
> > > Sounds like the binutils does not have the needed support for (32bit)
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97409
--- Comment #2 from fdlbxtqi ---
(In reply to Andrew Pinski from comment #1)
> Sounds like the binutils does not have the needed support for (32bit)
> multilib.
so I should build binutils with --disable-multilib?
Assignee: unassigned at gcc dot gnu.org
Reporter: euloanty at live dot com
Target Milestone: ---
rsion-script=libgcc.map -o lib32/ilp32/libgcc_s.so.1.tmp -g -O2 -march=rv32imac
-mabi=ilp32 -B./ _negdi2_s.o _lshrdi3_s.o _ashldi3_s.o _ashrdi3_s.o _cmpdi2_s.o
_ucmpdi2_s.o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97387
--- Comment #7 from fdlbxtqi ---
(In reply to Jakub Jelinek from comment #6)
> Trying 10, 17 -> 18:
>10: r88:QI=ltu(flags:CCC,0)
> REG_DEAD flags:CCC
>17: {flags:CCC=cmp(r88:QI-0x1,r88:QI);clobber scratch;}
> REG_DEAD r88:QI
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97387
--- Comment #3 from fdlbxtqi ---
(In reply to Hongtao.liu from comment #2)
> Same issue as PR93990?
many of them. It has been reported similar bugs since 2015.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97387
--- Comment #1 from fdlbxtqi ---
All these instructions generated by GCC are very very wrong.
https://gcc.godbolt.org/z/asMrKv
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: euloanty at live dot com
Target Milestone: ---
#include
#include
void add256(uint64_t a[4], uint64_t b[4]){
uint8_t carry = 0;
for (int i = 0
ty: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: euloanty at live dot com
Target Milestone: ---
This happens when I build qtbase.
/usr/local/lib/gcc/x86_64-pc-linux-gnu/11.0.0/include/pmmintrin.h:129:9:
internal comp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97262
--- Comment #3 from fdlbxtqi ---
Change the line of (long)m_region to this. Compile success. the type long just
considered harmful
hashval_t hash () const
{
return (binding_key::impl_hash () ^ reinterpret_cast(m_region));
}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97262
--- Comment #2 from fdlbxtqi ---
Let's face it. std::size_t should be the default integer type in both C and
C++. type like long should never EVER be used.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97262
--- Comment #1 from fdlbxtqi ---
You cannot cast pointer this way. How do you guys control your code quality
now?
Severity: normal
Priority: P3
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: euloanty at live dot com
Target Milestone: ---
c/../libbacktrace -I/mingw64/include -D__USE_MINGW_ANSI_STDIO=1
-I/mingw64/include -o analyzer/pending-diagn
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
: 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
: 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
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
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 #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 #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 #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
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=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
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 #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
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=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.
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=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 #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
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
fdlbxtqi changed:
What|Removed |Added
Host|amd ryzen 2700. Linux, |Amd ryzen 2700. Linux,
|Min
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=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: 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=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.
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=94601
--- Comment #1 from fdlbxtqi ---
Can you guys stop using macros and migrate to namespace?
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=94268
--- Comment #9 from fdlbxtqi ---
https://github.com/microsoft/WSL/issues/3898
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 #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 #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 #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 #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 #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 #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
fdlbxtqi changed:
What|Removed |Added
Host||Windows 10. MinGW-W64
Target|
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=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 implementat
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.
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 derefer
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
> std::lexicographic
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
> std::lexicographic
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)
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
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&action=edit
Officially support std::th
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, i
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());
}
: 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=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
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 -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93297
fdlbxtqi changed:
What|Removed |Added
CC||euloanty at live dot com
--- Comment #1 from
, 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
1 - 100 of 169 matches
Mail list logo
