[Bug libstdc++/96324] two semantic errors in polymorphic allocator for Ranges because it is attributed by constexpr.

2020-07-27 Thread jesus at refusetoown dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96324

--- Comment #2 from Jesus Christ  ---
Created attachment 48934
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48934&action=edit
your isomorphic allocator is limited to 80% of the allocation

isomorphic algorithms are limited by The Pareto Principle and only allocates
80% of the needed allocation so eventually a push_back to vector, for example,
will fail to allocate due to failing at 80% allocation instead of 100%
allocation. The only way I found to get around this is to use isomutative
algorithms that I have developed to get a better seeker result and it does work
but I still have trouble getting past the %80 of truth available but if I can
only seek truth up to 80% of truth, then you probably can't allocate beyond 80%
of allocation using a seeker. That is my seeker law: no seeks beyond 80
iterations else it will fail. The around it I have found is to use two loops:
for (int i=0;i<7:i++) {
 for (int s=0; s<81; s++) {
 // isomorphically seek something.
 }
}
This kind-of works but only gets you close to %100 and still you fail. To get
up-to %100 take feedback, and that means you have to feedback the seek result
into the next seek:
for (int i=0;i<7:i++) {
 for (int s=0; s<81; s++) {
 // why is "last seek result " successful or unsuccessful 
 }
 // save seek result
}
With a feedback loop your control is as good as open loop vs close loop
algorithms. A closed loop algorithm is always better at work than an open loop
algorithm. You can trust me on that, it's from engineering school in the 70's
so it's a bit dim now.

I hope you find this useful for explaining why it fails: It is syntactically
correct bu semantically wrong, can you add a semantic error to your compiler 
to prevent things like this. Two semantic errors you could check for is "too
forced" when it exceeds 80. And "defaulted to true" when you detect an
assumption like an arbitrary limit. The limit of assumptions should be two,
three assumptions will fail something.

Sorry I have no test case. I am too busy to find the file I had. I know when I
gave up on the project, I came to the conclusion that C++ is worthless. And
have been winding down and working in assembly language with total success and
worthwhile programs like my redmeme meme installer that goes through chaos to
find people like all my warriors have redmemes and say the a question that
nobody else says. It is the nest red  vmemes cause mine have six truths and
Spiral Dynamics has only 4 truths. So if C++ is still worthless I hope you can
fix it with what I have told you. 

A story might help, After Bertrand Russell wrote his book "Principia
Mathmatica" he claimed "My math can solve any of the world's problems!" That
stood until a German Logician named Kurt Godel decided that that English claim
was false and he might be be able to disprove it. So he invented a way to
"Godel Number" the letters of a text assigning a unique number to each letter
leaving the sequence correct so so retains the syntactic  quality of the
letters but converts the string of letters into a string of numbers simply
because numbers are easier to evaluate than letters, and all you to do is sum
the number up for example and compare two string to see which sum is bigger for
example, maybe the bigger sum is better unless less is more by McLuhan is real
maybe you can answer that. I say the least is the most is my rule. 
So maybe someone can disprove Bjarne Stroutrup's claim that C++ can solve any
problem in the world. Maybe he was Bertrand in his past life :)

Sincerely
Larry Daniel at least at birth.

[Bug libstdc++/96324] New: two semantic errors in polymorphic allocator for Ranges because it is attributed by constexpr.

2020-07-26 Thread jesus at refusetoown dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96324

Bug ID: 96324
   Summary: two semantic errors in polymorphic allocator for
Ranges because it is attributed by constexpr.
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jesus at refusetoown dot com
  Target Milestone: ---

By my seeker test:
in libstdc++ version 12 two semantic errors are in polymorphic allocator for
Ranges because it is attributed by constexpr. is Consistent with 39 fidelities.

My explanation:
It is syntactically correct but semantically incorrect twice. I think error is
in the constexpr of polymorphic allocator. The symptom, for example is a vector
that fails to allocate any thing when you use push_back and it fails at runtime
with a crash of some type like segmentation faults because there is nothing
allocated when you try to use the vector after you push_back into it. You can
resize and such but it will still fail.

[Bug c++/95623] New: #include fails to define this_thread

2020-06-10 Thread jesus at refusetoown dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95623

Bug ID: 95623
   Summary: #include  fails to define this_thread
   Product: gcc
   Version: 8.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jesus at refusetoown dot com
  Target Milestone: ---

seeker2 "The bug in gcc is that #include  fails fails fails fails if
evil if evil if evil if good if good if good, if so, if so, if so"
the bug in gcc is that #include  fails fails fails fails if evil if
evil if evil if good if good if good, if so, if so, if so
Consistent with 46 fidelities.

The compiler is on windows 10, with MinGW-W64 used with -std=c++11 or c++17
they both fail.

C:\Users\Larry\Documents\safe>gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=C:/Program\
Files/mingw-w64/x86_64-8.1.0-win32-seh-rt_v6-rev0/mingw64/bin/../libexec/gcc/x86_64-w64-mingw32/8.1.0/lto-wrapper.exe
Target: x86_64-w64-mingw32
Configured with: ../../../src/gcc-8.1.0/configure --host=x86_64-w64-mingw32
--build=x86_64-w64-mingw32 --target=x86_64-w64-mingw32 --prefix=/mingw64
--with-sysroot=/c/mingw810/x86_64-810-win32-seh-rt_v6-rev0/mingw64
--enable-shared --enable-static --disable-multilib
--enable-languages=c,c++,fortran,lto --enable-libstdcxx-time=yes
--enable-threads=win32 --enable-libgomp --enable-libatomic --enable-lto
--enable-graphite --enable-checking=release --enable-fully-dynamic-string
--enable-version-specific-runtime-libs --disable-libstdcxx-pch
--disable-libstdcxx-debug --enable-bootstrap --disable-rpath
--disable-win32-registry --disable-nls --disable-werror --disable-symvers
--with-gnu-as --with-gnu-ld --with-arch=nocona --with-tune=core2
--with-libiconv --with-system-zlib
--with-gmp=/c/mingw810/prerequisites/x86_64-w64-mingw32-static
--with-mpfr=/c/mingw810/prerequisites/x86_64-w64-mingw32-static
--with-mpc=/c/mingw810/prerequisites/x86_64-w64-mingw32-static
--with-isl=/c/mingw810/prerequisites/x86_64-w64-mingw32-static
--with-pkgversion='x86_64-win32-seh-rev0, Built by MinGW-W64 project'
--with-bugurl=https://sourceforge.net/projects/mingw-w64 CFLAGS='-O2 -pipe
-fno-ident -I/c/mingw810/x86_64-810-win32-seh-rt_v6-rev0/mingw64/opt/include
-I/c/mingw810/prerequisites/x86_64-zlib-static/include
-I/c/mingw810/prerequisites/x86_64-w64-mingw32-static/include' CXXFLAGS='-O2
-pipe -fno-ident
-I/c/mingw810/x86_64-810-win32-seh-rt_v6-rev0/mingw64/opt/include
-I/c/mingw810/prerequisites/x86_64-zlib-static/include
-I/c/mingw810/prerequisites/x86_64-w64-mingw32-static/include' CPPFLAGS='
-I/c/mingw810/x86_64-810-win32-seh-rt_v6-rev0/mingw64/opt/include
-I/c/mingw810/prerequisites/x86_64-zlib-static/include
-I/c/mingw810/prerequisites/x86_64-w64-mingw32-static/include' LDFLAGS='-pipe
-fno-ident -L/c/mingw810/x86_64-810-win32-seh-rt_v6-rev0/mingw64/opt/lib
-L/c/mingw810/prerequisites/x86_64-zlib-static/lib
-L/c/mingw810/prerequisites/x86_64-w64-mingw32-static/lib '
Thread model: win32
gcc version 8.1.0 (x86_64-win32-seh-rev0, Built by MinGW-W64 project)