https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100884
m farazma changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100884
--- Comment #1 from m farazma ---
The development team has mentioned this is correct behaviour, according to PPC
ABI the returning function needs to sign or zero extend the result when
necessary:
https://refspecs.linuxfoundation.org/ELF/ppc64/PP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100884
Bug ID: 100884
Summary: Comparing unsigned 32 bit integer values generates 64
bit compare instructions when optimized
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100641
--- Comment #1 from m farazma ---
Issue seems to be similar to this older gcc bug:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59364
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100641
Bug ID: 100641
Summary: Link error when using extern thread_local variables on
AIX
Product: gcc
Version: 8.3.0
Status: UNCONFIRMED
Severity: normal
P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97914
Bug ID: 97914
Summary: -fno-delete-null-pointer-checks not working properly
with constexpr
Product: gcc
Version: 7.3.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97913
Bug ID: 97913
Summary: -fno-delete-null-pointer-checks not working properly
with constexpr
Product: gcc
Version: 7.3.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97086
--- Comment #3 from m farazma ---
Sorry the above example needs to be changed to this in order to reproduce the
bug:
```
#include
#include
int main(){
float a = -0.0;
std::cout << nearbyintf(a) << std::endl;
return 0;
}
```
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97086
--- Comment #2 from m farazma ---
Wanted to point out the same happens when using "nearbyint":
```
#include
#include
int main(){
std::cout << nearbyintf(-0) << std::endl;
return 0;
}
```
expected: -0
actual: 0
https://en.cppreference.com/w/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97266
--- Comment #6 from m farazma ---
(In reply to Jonathan Wakely from comment #5)
> Neither of those cases are constants, and the warning documentation (and the
> actual diagnostic itself) talk about constants.
>
> But there's still no warning for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97266
--- Comment #4 from m farazma ---
(In reply to Jonathan Wakely from comment #3)
> No, the type is ValidateFlag. It has an underlying type of int8_t, but that
> just means it has the same size and range of values as int8_t. It's not
> actually tha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97266
--- Comment #2 from m farazma ---
(In reply to Jonathan Wakely from comment #1)
> (In reply to m farazma from comment #0)
> > ```
> > #include
> >
> > enum ValidateFlag : int8_t {
> >a = 0, b , c
> > };
> >
> > int main(){
> > bool t =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97266
Bug ID: 97266
Summary: "enum constant in boolean context" warning seems
incorrect
Product: gcc
Version: 8.3.0
Status: UNCONFIRMED
Severity: normal
Pri
13 matches
Mail list logo
