ibstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: janezz55 at gmail dot com
Target Milestone: ---
As the comment says, std::is_signed_v<__int128> should evaluate to true.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95561
--- Comment #2 from Janez Zemva ---
(In reply to Marc Glisse from comment #1)
> Are you using -std=gnu++17 or -std=c++17 ?
yes, of course.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95561
--- Comment #3 from Janez Zemva ---
BTW: std::is_integral_v<__int128> is also false. I'm not certain, whether this
is a bug, but reporting nonetheless.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95561
--- Comment #5 from Janez Zemva ---
Thank you for the "fix", I am writing my own 128-bit integral type, but in the
mean time, I'm using __int128.
++
Assignee: unassigned at gcc dot gnu.org
Reporter: janezz55 at gmail dot com
Target Milestone: ---
source code is at: https://github.com/user1095108/generic
I do this:
g++ -std=c++17 forwarder.cpp -o f
I get this:
In file included from forwarder.cpp:3:
forwarder.hpp: In
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95684
--- Comment #1 from Janez Zemva ---
Everything works with clang version 10.0.0.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95684
--- Comment #3 from Janez Zemva ---
Isn't a link to the source code sufficient? You can generate your own, if you
want.
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: janezz55 at gmail dot com
Created attachment 30626
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30626&action=edit
file demonstrating bug
The following example compiles without issue with clang++ 3.3:
#
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58109
--- Comment #2 from Janez Zemva ---
Please don't neglect std::integral_constant, as it is has a constexpr
conversion operator and so one can use its "instance" as a template parameter.
++
Assignee: unassigned at gcc dot gnu.org
Reporter: janezz55 at gmail dot com
Target Milestone: ---
clang version 10.0.1 compiles this, but gcc 10.2.0 fails gloriously:
template
std::size_t hash_combine(T&& ...v) noexcept(noexcept(
((hash>()(std::declval())), ...)))
{
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97773
--- Comment #2 from Janez Zemva ---
#include
#include
#include
#include
#include
#include
template
struct hash : std::hash
{
};
template <>
struct hash
{
auto operator()(std::chrono::seconds const cp) const noexcept
{
return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97773
--- Comment #3 from Janez Zemva ---
Created attachment 49535
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49535&action=edit
bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97773
--- Comment #6 from Janez Zemva ---
try -std=c++20 ?
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: janezz55 at gmail dot com
Target Milestone: ---
Created attachment 49538
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49538&action=edit
bug
Ok, here we go again: does not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97778
--- Comment #1 from Janez Zemva ---
oh, once, again, -std=c++20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97778
--- Comment #2 from Janez Zemva ---
t.cpp:57:22: error: no matching function for call to 'apply(, const std::tuple >, std::chrono::time_point > >,
std::basic_string_view > >&)'
57 | return std::apply(hash_combine, t);
|~~
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: janezz55 at gmail dot com
Target Milestone: ---
The code sample is here https://github.com/user1095108/cr. gcc crashes only if
the optimization level is higher than 2.
g++ -I.. -Ofast
: unassigned at gcc dot gnu.org
Reporter: janezz55 at gmail dot com
Target Milestone: ---
another gcc crash:
g++ -std=c++20 -Ofast loopdemo.cpp -o s
In file included from loopdemo.cpp:3:
loop.hpp:168:45: internal compiler error: Segmentation fault
168 | requires(std::is_integral_v
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105064
--- Comment #2 from Janez Zemva ---
Yeah, I tried to make a minimal crash example for you, but it compiled
perfectly. Anyway, you know about the crash, you know about my repository and I
am no hurry for a fix, as this is my pet-project. And this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105064
--- Comment #5 from Janez Zemva ---
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure
--enable-languag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105064
--- Comment #6 from Janez Zemva ---
Also, there are several workarounds around this bug, but I'll keep my
repository in a crashing state, until you find time to produce a minimal test
case.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105064
--- Comment #7 from Janez Zemva ---
Also, I'd like to add, that you can mount a github repository with FUSE, so
providing an URL is almost the same as providing an archive.
https://github.com/taterbase/git-mount
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105064
--- Comment #8 from Janez Zemva ---
I can reproduce the bug in my rpi4b:
$ g++ -std=c++20 -Ofast loopdemo.cpp -o l
In file included from loopdemo.cpp:3:
loop.hpp:169:55: internal compiler error: Segmentation fault
169 | requires(std::is_s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105064
--- Comment #9 from Janez Zemva ---
Anyway, I've grown bored, so here's the minimal test case:
#include
class task
{
friend void suspend_to(auto const tp) noexcept
requires(std::is_same_v);
};
class loop
{
friend void suspend_to(auto
++
Assignee: unassigned at gcc dot gnu.org
Reporter: janezz55 at gmail dot com
Target Milestone: ---
Reproducing the crash is easy, clone my repository:
https://github.com/user1095108/sq2
then compile:
g++ -std=c++20 -Ofast sq2.cpp -s -o sq2 -lsqlite3
In file included from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106689
--- Comment #2 from Janez Zemva ---
Sorry, I can't, because I already changed the code a little and I'm keeping the
repo such as it is so as to not invalidate this bug report. Why not clone the
repo and do what you need to do? I'm keeping it in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106689
--- Comment #3 from Janez Zemva ---
BTW: I already tried to make a minimal test case, but failed, all compiled
fine. Maybe tomorrow.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106689
--- Comment #4 from Janez Zemva ---
Created attachment 53482
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53482&action=edit
preprocessed source
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106689
--- Comment #5 from Janez Zemva ---
The workaround is very simple, just put "[&]() noexcept -> bool" into sq2.hpp.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106689
--- Comment #6 from Janez Zemva ---
I have since changed the repo. You can still demonstrate the bug by
uncommenting the line:
//[&a, &r, &s]() noexcept -> bool // uncomment for bug
++
Assignee: unassigned at gcc dot gnu.org
Reporter: janezz55 at gmail dot com
Target Milestone: ---
Here you have a fully working program, that instead of creating a
std::tuple>
creates a
std::tuple
something collapses the tuple of tuples into a single tuple. The workaround is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103448
--- Comment #2 from Janez Zemva ---
I have no idea, but it seems wrong me. Is there an explanation for the lvalue
references? I expected rvalue references, but that's unrelated to the bug.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103448
--- Comment #4 from Janez Zemva ---
Ok, thank you :)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103448
--- Comment #7 from Janez Zemva ---
The c++17 type deduction rules are also going on. This makes me wonder how
std::make_tuple() circumvents the problem.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103448
--- Comment #10 from Janez Zemva ---
The code worked for ((...), (...), ...), but not for ((...)), I did not
understand how a tuple not containing another tuple could possibly be
constructed. On the other hand, I already found a workaround and I
: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: janezz55 at gmail dot com
Target Milestone: ---
The noexcept specification is probably c++ non-complaint, but still causes a
crash:
constexpr void assign_tuple(auto& t, auto&& ...a)
noexcept(noexcept(
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107514
--- Comment #1 from Janez Zemva ---
A working version:
https://wandbox.org/permlink/ki45SRwCNwuMRw7G
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107514
--- Comment #3 from Janez Zemva ---
Created attachment 53833
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53833&action=edit
example
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: janezz55 at gmail dot com
Target Milestone: ---
Created attachment 54204
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54204&action=edit
sample file demonstrating the bug
g++ will be unable to captur
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108317
--- Comment #1 from Janez Zemva ---
Created attachment 54205
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54205&action=edit
sample file demonstrating the bug
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: janezz55 at gmail dot com
Target Milestone: ---
This line:
struct alignas(64) M : __gnu_cxx::__mutex { };
has been an eyesore for me for a number of years. I propose to change it into:
struct alignas(std
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109741
--- Comment #1 from Janez Zemva ---
alternatively, the line could be changed into:
struct alignas(void*) M : __gnu_cxx::__mutex { };
since this was probably meant with the magic number 64.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109741
--- Comment #5 from Janez Zemva ---
This line has been patched out by djgpp builds for a long time now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109741
--- Comment #8 from Janez Zemva ---
Here is the compile error:
../../../../../gcc-13.1.0/libstdc++-v3/src/c++11/shared_ptr.cc: In function
'__gnu_cxx::__mutex& __gnu_internal::get_mutex(unsigned char)':
../../../../../gcc-13.1.0/libstdc++-v3/src
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109741
--- Comment #13 from Janez Zemva ---
@Jonathan Wakely
I asked ChatGPT about this:
What is the most common size of a cache line?
The most common size of a cache line is 64 bytes. This size is used by most
modern CPUs because it strikes a balance
++
Assignee: unassigned at gcc dot gnu.org
Reporter: janezz55 at gmail dot com
Target Milestone: ---
If I compile the example .cpp file:
gcc -std=c++20 -Wextra -Wall -Wpedantic add_sub_tests.cpp -o a
gcc produces the warning:
../intt.hpp: In member function 'constexpr auto intt::intt
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: janezz55 at gmail dot com
Target Milestone: ---
After building gcc/DJGPP, the installation requires the following hack:
sed -i '/{ return __builtin_tanh(__x); }/a\
\
using ::
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109818
--- Comment #3 from Janez Zemva ---
I am the "maintainer" of this dosbox-gcc aur (mostly I just borrow from other
builds). I have told the DJGPP community about this issue 2 times and they
shrugged it off, since they mostly compile .c source fil
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109818
--- Comment #6 from Janez Zemva ---
There are a lot of patches and I never went over all of them. I'll take another
look and update my bug report, if necessary (I think you're probably right).
But, should anyone else want to, the build script is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109818
--- Comment #8 from Janez Zemva ---
I took a look and I believe the c_global is already being selected and I
believe the hack I presented should perhaps be applied to
libstdc++-v3/include/c_global/cmath - the hack template is in there. As for th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109818
--- Comment #9 from Janez Zemva ---
I'd also like to mention, that the hack is already present in the c_global
cmath file, but is perhaps in a wrong section of the file, i.e. it is in the
section protected by:
#if defined(__STDCPP_FLOAT64_T__)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109818
--- Comment #12 from Janez Zemva ---
I doubt DJGPP will change their C library, at least this workaround exists now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109818
--- Comment #14 from Janez Zemva ---
Certainly, but users will still be able to make use of the kludge.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109818
--- Comment #17 from Janez Zemva ---
Perhaps missing functionality could also be auto-generated? I am a big fan of
generative programming.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109818
--- Comment #22 from Janez Zemva ---
They are very sloppy, so I doubt even what they provide is working 100%. This
is why I suggested the generative approach. gcc has many built-in functions,
surely a rudimentary could be cobbled out of them.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109818
--- Comment #24 from Janez Zemva ---
I'll go libm shopping them, I know just the thing to try out first:
https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/devel/libs/libm/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109818
--- Comment #26 from Janez Zemva ---
I am a c++ user, so I don't like using c header files if at all possible. I am
pleased with how things are: I now compile/link a replacement libm and replace
the sloppy djgpp header files, but I haven't teste
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109818
--- Comment #27 from Janez Zemva ---
forcing glibcxx_cv_c99_math_tr1=yes solved this issue for me. The C99
compliance test is really strict, even openlibm fails the test (it fails to
define float_t and double_t, but this can be hacked around).
: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: janezz55 at gmail dot com
Target Milestone: ---
If I compile list.cpp with:
g++ -std=c++20 list.cpp -o l
friend auto operator==(list const& l, list const& r)
noexcept(noexcept(
std::equal(l.begin(
: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: janezz55 at gmail dot com
Target Milestone: ---
Compiling:
#include
template void test() {}
template
struct S
{
int a_[N];
int* f_;
constexpr S(): a_{}, f_{a_} {}
};
int main()
{
test{}>();
retur
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112590
--- Comment #2 from Janez Zemva ---
Very nice, but if I write:
int main()
{
static constexpr S<10> s;
return 0;
}
there will still be a compile error.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112590
--- Comment #3 from Janez Zemva ---
Sorry for my last comment. I have prepared a more involved example:
https://github.com/user1095108/ca/blob/master/consttests.cpp
If
test();
is commented out, everything compiles, otherwise not.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109818
--- Comment #32 from Janez Zemva ---
I resolved this issue by porting openlibm over to djgpp (some hacks and typedef
float float_t;, ... were necessary). The fix on the side of gcc might have been
a more thorough analysis of what is available in
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: janezz55 at gmail dot com
Target Milestone: ---
trying to compile:
template
using array_t __attribute__ ((vector_size(std::bit_ceil(N * sizeof(T) = T;
produces the following
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110403
--- Comment #1 from Janez Zemva ---
Here is a possible workaround:
#define S__(x) ((x) | (x) >> 1 | (x) >> 2 | (x) >> 3 | (x) >> 4)
#define BITCEIL(x) ((x) & (x) - 1 ? (S__(x) & ~(S__(x) >> 1)) << 1 : (x))
template
using array_t __attribute__ (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116178
Janez Zemva changed:
What|Removed |Added
CC||janezz55 at gmail dot com
--- Comment
66 matches
Mail list logo
