https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97273
--- Comment #3 from Patrick Palka ---
Patch posted:
https://gcc.gnu.org/pipermail/gcc-patches/2020-October/555465.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97272
--- Comment #5 from Bill Long ---
The original intent of adding the KIND argument was because some
implementations used a 32-bit integer for the result, and it is possible for
the answer to be larger than 2**31-1. Just checking to be sure that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97288
--- Comment #1 from Amir Kirsh ---
For user defined type this behavior might be ok, as the order of evaluation of
parameters is not defined, however this behavior is reflected also for
primitive types:
int main() {
int a {5};
(a += 1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97288
Bug ID: 97288
Summary: Assignment sequence before order - evaluating
reference to value of right side not in order
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97272
--- Comment #4 from CVS Commits ---
The master branch has been updated by Harald Anlauf :
https://gcc.gnu.org/g:35d2c6b6e8a7448a84abbf967feeb78a29117014
commit r11-3646-g35d2c6b6e8a7448a84abbf967feeb78a29117014
Author: Harald Anlauf
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97286
H.J. Lu changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97287
Bug ID: 97287
Summary: Warn for expanding range of an arithmetic type
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97275
--- Comment #1 from Duncan Simpson ---
Further information: if I use the same compiler version but a x86_64-linux-gnu
version then I get a message from the assembler telling me than the strlr
instruction is not supported but no ICE.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97286
Bug ID: 97286
Summary: GCC sometimes uses an extra xmm register for the
destination of _mm_blend_ps
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Keywords:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97070
--- Comment #4 from Ioannis E. Venetis ---
It seems that the problem was indeed some kind of confusion due to multiple gcc
installs. I removed the nvptx related packages of gcc-9.3.0 from my Ubuntu
16.04.7 LTS system (packages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96870
Dominique d'Humieres changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96809
Dominique d'Humieres changed:
What|Removed |Added
Last reconfirmed||2020-10-04
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97224
--- Comment #10 from Ev Drikos ---
(In reply to Dominique d'Humieres from comment #9)
> I think the two attached patches are not pertinent...
Possibly, you are right. I have no access to the
particular source code.
> I get
>
> 8 | call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97285
Bug ID: 97285
Summary: Interaction between no_unique_address and
has_unique_object_representations
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97224
--- Comment #9 from Dominique d'Humieres ---
I think the two attached patches are not pertinent: both tests use independent
translation units, so they should compile.
If I couple the TUs as in
SUBROUTINE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97284
Bug ID: 97284
Summary: internal compiler error: 'global_options' are modified
in local context
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89256
--- Comment #2 from Thomas Koenig ---
See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97282#c1 for one
example how this could be done for small integers (base 10 in that
case). The solution with the precomputed tables is probably not feasible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97283
Arnaud Charlet changed:
What|Removed |Added
Target Milestone|--- |11.0
Resolution|---
18 matches
Mail list logo
