https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110522
Roman Lebedev changed:
What|Removed |Added
CC||dmalcolm at redhat dot com,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110522
--- Comment #1 from Roman Lebedev ---
To spell it out explicitly, not storing the resulting `.sarif`
next to the produced object file itself, like it's done in (all?)
other cases, very much looks like a not-a-feature,
basically making the featur
Priority: P3
Component: driver
Assignee: unassigned at gcc dot gnu.org
Reporter: lebedev.ri at gmail dot com
Target Milestone: ---
The sarif-file is stored into PWD of the compiler invocation.
Worse yet, it uses only a basename of the target object file,
but
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108674
--- Comment #10 from Roman Lebedev ---
Created attachment 54409
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54409&action=edit
the patch
I'm not at all familiar with the GCC's preferred patch protocol,
this is the result of `git format-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108674
--- Comment #9 from Roman Lebedev ---
(In reply to Jonathan Wakely from comment #7)
> (In reply to Roman Lebedev from comment #0)
> > I believe in the version 12, a new instance of such intentional wraparound
> > was introduced into libstdc++: h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108674
Roman Lebedev changed:
What|Removed |Added
Resolution|DUPLICATE |---
Status|RESOLVED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: lebedev.ri at gmail dot com
Target Milestone: ---
Dear maintainer.
As everyone knows, unsigned integer overflow is well-defined in C and C++.
However
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107763
--- Comment #5 from Roman Lebedev ---
Thank you.
Forwarded to https://github.com/llvm/llvm-project/issues/59085
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107763
Roman Lebedev changed:
What|Removed |Added
Component|c |c++
--- Comment #2 from Roman Lebedev
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: lebedev.ri at gmail dot com
Target Milestone: ---
enum a { b };
int foo(a a) {
switch(a) {
case b: return 42;
}
}
The `a` can only have value `a::b`,
so the function
Assignee: unassigned at gcc dot gnu.org
Reporter: lebedev.ri at gmail dot com
Target Milestone: ---
https://godbolt.org/z/KPc5hM3f9
clang:
:4:39: error: variable 'c' must have explicitly specified data sharing
attributes
#pragma omp parallel for simd aligned(c) fi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97844
Roman Lebedev changed:
What|Removed |Added
CC||lebedev.ri at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93240
Roman Lebedev changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALID
ty: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: lebedev.ri at gmail dot com
Target Milestone: ---
https://godbolt.org/z/-ExpDY
typedef double * aligned_double_ptr __attribute__((align_value(64)));
struct S {
aligned_do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90691
--- Comment #2 from Roman Lebedev ---
(In reply to Richard Biener from comment #1)
> Confirmed.
Note that this isn't just about constants, but about the evaluation
of constant-range of the signed operand.
E.g. '(b ? 10 : 9)' is not a constant, b
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: lebedev.ri at gmail dot com
Target Milestone: ---
Manually reduced:
#include
struct S {
int a;
constexpr S();
explicit constexpr S(int a_) : a(a_) {}
};
constexpr S b = S(12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90406
--- Comment #2 from Roman Lebedev ---
(In reply to Jakub Jelinek from comment #1)
> That is again a clang bug. if clause is on the parallel (after all, it is
> not a combined/composite construct in this case), so the expression in the
> clause i
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: lebedev.ri at gmail dot com
Target Milestone: ---
A continuation of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90365
That bug was a clang bug, https://bugs.llvm.org/show_bug.cgi?id=41767 and it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90366
Roman Lebedev changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
See Also|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90365
Roman Lebedev changed:
What|Removed |Added
See Also||https://bugs.llvm.org/show_
0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: lebedev.ri at gmail dot com
Target Milestone: ---
#include
void test(int chunkSize) {
#pragma omp parallel default(none)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90365
--- Comment #1 from Roman Lebedev ---
Forgot to add https://godbolt.org/z/CeVhEu
: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: lebedev.ri at gmail dot com
Target Milestone: ---
void sink();
void test(int chunkSize) {
#pragma omp parallel for default(none) schedule(dynamic, chunkSize)
for(int i = 0; i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88967
--- Comment #9 from Roman Lebedev ---
(In reply to Jakub Jelinek from comment #8)
> Well, in your case firstprivate is really what you want, unless the compiler
> figures that out for you magically you want to firstprivatize these
> variables.
H
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88967
--- Comment #7 from Roman Lebedev ---
(In reply to Jakub Jelinek from comment #6)
> No, gcc always implements just one OpenMP version, the latest one that has
> support written.
E.g. because of this everyone affected will need to either just comp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88967
--- Comment #5 from Roman Lebedev ---
(In reply to Jakub Jelinek from comment #1)
> I've asked the ifort/clang maintainers about why they keep violating the
> standard, but haven't heard back from them. And I must say I was trying
> hard to read
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88967
--- Comment #4 from Roman Lebedev ---
(In reply to Roman Lebedev from comment #3)
> While there, any advice on how that is supposed to be rewritten?
> Simply adding "shared(begin, len)" makes older gcc's unhappy
> https://godbolt.org/z/gyZBR-
> O
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88967
--- Comment #3 from Roman Lebedev ---
While there, any advice on how that is supposed to be rewritten?
Simply adding "shared(begin, len)" makes older gcc's unhappy
https://godbolt.org/z/gyZBR-
Only keeping "shared(begin, len)" (and dropping "defa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88967
--- Comment #2 from Roman Lebedev ---
(In reply to Jakub Jelinek from comment #1)
> It indeed changed, already in OpenMP 4.0 actually, but I've been long hoping
> that the change will be reverted in later OpenMP standards, in the end that
> is no
Assignee: unassigned at gcc dot gnu.org
Reporter: lebedev.ri at gmail dot com
Target Milestone: ---
https://godbolt.org/z/8WHddH
void foo(int *x);
void test1(int * const begin, const int len) {
#pragma omp parallel default(none)
#pragma omp for
for(int x = 0; x < len
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87667
Roman Lebedev changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
See Also|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87667
--- Comment #2 from Roman Lebedev ---
(In reply to Jonathan Wakely from comment #1)
> It's a warning, why do you think either compiler is wrong?
Either it is incorrect to pass `enum class Enum : unsigned short`
when the format specifier is %hx (
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: lebedev.ri at gmail dot com
Target Milestone: ---
https://godbolt.org/z/05Zgdd
#include
struct b {};
void c() {
std::vector d;
#ifdef _OPENMP
#pragma omp
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: lebedev.ri at gmail dot com
Target Milestone: ---
https://godbolt.org/z/GX-Fqv
#include
enum class Enum : unsigned short {
One,
};
void test(Enum e) {
printf("0x%04hx", e);
}
gcc:
: In function
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: lebedev.ri at gmail dot com
Target Milestone: ---
https://godbolt.org/g/qX6k2H
# 0 "" 3
template void b(int, a);
template void b(int, a &&e, c) {
b(0, [=] { e; });
}
vo
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: lebedev.ri at gmail dot com
Target Milestone: ---
Originally reported as https://bugs.llvm.org/show_bug.cgi?id=37593
Minimal testcase:
extern int a;
auto a = 0
Priority: P3
Component: libgcc
Assignee: unassigned at gcc dot gnu.org
Reporter: lebedev.ri at gmail dot com
Target Milestone: ---
$ lscpu
Architecture:x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
CPU(s): 8
On
37 matches
Mail list logo
