https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98424
--- Comment #1 from Andrew Pinski ---
Hmm, ICC and MSVC both have the same behavior as GCC.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98249
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |9.5
See Also|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98249
Andrew Pinski changed:
What|Removed |Added
Known to fail||4.5.3
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38542
--- Comment #2 from Andrew Pinski ---
clang and even ICC accept this code now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97448
Andrew Pinski changed:
What|Removed |Added
Target|powerpc |powerpc-*-*linux (32bit)
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102395
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |12.0
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97344
Andrew Pinski changed:
What|Removed |Added
See Also||https://sourceware.org/bugz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97344
Andrew Pinski changed:
What|Removed |Added
Assignee|pinskia at gcc dot gnu.org |unassigned at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97344
Andrew Pinski changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97344
--- Comment #4 from Andrew Pinski ---
if (GET_CODE (rtl) == SYMBOL_REF
&& SYMBOL_REF_TLS_MODEL (rtl) != TLS_MODEL_NONE)
{
dw_loc_descr_ref temp;
/* If this is not defined, we have no way to emit the da
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97344
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2021-09-19
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102144
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2021-09-19
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102144
--- Comment #1 from Andrew Pinski ---
This fixes the problem for me:
diff --git a/libsanitizer/hwasan/hwasan_thread_list.h
b/libsanitizer/hwasan/hwasan_thread_list.h
index 15916a802d6..c13c5910b95 100644
--- a/libsanitizer/hwasan/hwasan_thread_l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84774
Bug 84774 depends on bug 102386, which changed state.
Bug 102386 Summary: [12 regression] bogus -Wrestrict for unreachable memcpy()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102386
What|Removed |Added
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102386
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98379
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98303
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102401
--- Comment #4 from Jonathan Wakely ---
(In reply to Jakub Jelinek from comment #3)
> There are things that need to be clarified, in particular value
> initialization should clear even the padding bits, so supposedly
> std::bit_cast of Item() if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102404
--- Comment #1 from Freddie Witherden ---
Created attachment 51481
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51481&action=edit
Generated assembly.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102404
Bug ID: 102404
Summary: Loop vectorized with 32 byte vectors actually uses 16
byte vectors
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98184
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48297
Gabriel Ravier changed:
What|Removed |Added
CC||gabravier at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102403
Martin Sebor changed:
What|Removed |Added
Last reconfirmed||2021-09-18
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102403
Bug ID: 102403
Summary: [12 Regression] ICE in in init_from_control_deps, at
gimple-predicate-analysis.cc:2364
Product: gcc
Version: 12.0
Status: UNCONFIRMED
S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56883
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102302
Andrew Pinski changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102401
--- Comment #3 from Jakub Jelinek ---
There are things that need to be clarified, in particular value initialization
should clear even the padding bits, so supposedly std::bit_cast of Item() if
the NSDMIs would be dropped might be well defined a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102401
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102402
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Component|target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102402
Bug ID: 102402
Summary: Seemingly suboptimal optimization of jmp/cmovcc for
conditionally loading constants
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Seve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102401
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102401
Bug ID: 102401
Summary: std::bit_cast falls over, seemingly due to some
invisible alignment requirements
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102393
--- Comment #3 from Gabriel Ravier ---
It seems odd that the equivalent 32-bit pattern, i.e. this:
void HeaderWriteU32LE(int offset, uint32_t value, uint8_t *RomHeader)
{
RomHeader[offset] = value;
RomHeader[offset + 1] = value >> 8;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102270
--- Comment #6 from Jonathan Wakely ---
I think that constructor could just be deleted, but it's fixed now. Thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102397
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102400
Bug ID: 102400
Summary: Field might miss initialization in
vn_reference_insert_pieces()
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102399
Bug ID: 102399
Summary: Cannot mix GCC and C++11 / C23 attribute syntax
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102398
Bug ID: 102398
Summary: thread_local works incorrectly outside of main file
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102397
Bug ID: 102397
Summary: Documentation of attribute syntax does not discuss
C++11 / C23 attribute syntax
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102016
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102395
--- Comment #6 from Jan-Benedict Glaw ---
I'll fetch that patch and stuff it in the autobuilder, then let it run for
nvptx, vax and a few others.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101109
Andrew Pinski changed:
What|Removed |Added
Summary|ICE: Segmentation Fault:|[9/10/11/12 Regression] ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102245
Roger Sayle changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88173
Roger Sayle changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |roger at
nextmovesoftware dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99449
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97303
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97303
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |9.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102395
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102395
--- Comment #4 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #1)
> Actually it might be easier to change line 1291:
> gcc_assert (sclass < LIM_REG_CLASSES);
>
> to be:
> gcc_assert (sclass < LIM_REG_CLASSES && sclass >= NO_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102395
--- Comment #3 from Andrew Pinski ---
Note your reduced testcase is no where near what the code looks like.
The code is like this:
if (!(sclass < LIM_REG_CLASSES))__builtin_unreachable();
if (slcass == ALL_REGS) return;
if (sclass != NO_REGS &&
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102395
--- Comment #2 from Andrew Pinski ---
Can you attach the original full preprocessed source?
a));
//static_assert(std::equality_comparable::iterator>);
std::ranges::uninitialized_default_construct(span);
}
The error:
/opt/compiler-explorer/gcc-trunk-20210918/include/c++/12.0.0/concepts:280:17:
internal compiler error: in get, at cp/constraint.cc:2637
280 | { __
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102395
--- Comment #1 from Andrew Pinski ---
Actually it might be easier to change line 1291:
gcc_assert (sclass < LIM_REG_CLASSES);
to be:
gcc_assert (sclass < LIM_REG_CLASSES && sclass >= 0);
I don't see how -1 is coming into play ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102395
Bug ID: 102395
Summary: [nvptx, vax] enum reg_class inferred as signed /
unsigned
Product: gcc
Version: analyzer branch
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63581
Andrew Pinski changed:
What|Removed |Added
CC||arnetheduck at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64593
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43847
Andrew Pinski changed:
What|Removed |Added
Keywords||build
Last reconfirmed|2010-04-22 16:5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54353
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Keywords|
58 matches
Mail list logo