https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116178
Janez Zemva changed:
What|Removed |Added
CC||janezz55 at gmail dot com
--- Comment #14
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=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
Bug ID: 112590
Summary: structural constexpr class fails to instantiate
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111831
Bug ID: 111831
Summary: friend with requires keyword compilation error
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
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=110403
Bug ID: 110403
Summary: constant expression inside vector_size __attribute__
does not compile
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
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
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).
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 #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 #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 #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 #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 #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 #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 #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 #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 #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
Bug ID: 109818
Summary: std::trunc() requires a hack after building
DJGPP
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity: normal
Priority
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109775
Bug ID: 109775
Summary: gcc misidentifies a VLA
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee
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
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 #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 #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
Bug ID: 109741
Summary: alignas(64) in libstdc++-v3/src/c++11/shared_ptr.cc
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compo
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108317
Bug ID: 108317
Summary: g++ is unable to capture vector-extended variables
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compon
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
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
Bug ID: 107514
Summary: quick crash of gcc due to noexcept specification
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
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
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 #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 #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 #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
Bug ID: 106689
Summary: gcc crash while compiling a generic lambda
Product: gcc
Version: 12.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
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
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 #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 #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 #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 #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
Bug ID: 105064
Summary: requires crashes gcc
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104777
Bug ID: 104777
Summary: gcc crashes while compiling a custom coroutine library
sample
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
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
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 #4 from Janez Zemva ---
Ok, thank you :)
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
Bug ID: 103448
Summary: unexpected tuple collapse
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
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);
|~~
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
Bug ID: 97778
Summary: return type not deduced with gcc but get deduced with
clang
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97773
--- Comment #6 from Janez Zemva ---
try -std=c++20 ?
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 #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
Bug ID: 97773
Summary: gcc crash after some noexcept magic
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
57 matches
Mail list logo
