[Bug target/97086] aix: ceilf and truncf do not preserve the sign bit when output is rounded to 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/c/numeric/math/nearbyint
Above url clearly mentions "If arg is ±0, it is returned, unmodified".
[Bug target/97086] aix: ceilf and truncf do not preserve the sign bit when output is rounded to 0
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;
}
```
[Bug c++/97913] New: -fno-delete-null-pointer-checks not working properly with constexpr
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
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mfarazma.ext at gmail dot com
Target Milestone: ---
Compiling this code:
```
constexpr int test(const int *arr) {
if(arr == 0){
//
}
return 5;
}
int main(){
static constexpr int arr[] = {1,2,3};
static constexpr int b = test(arr);
return 0;
}
```
With "g++ -fno-delete-null-pointer-check test.cc" generates this error:
error '(((const int*)(& arr)) == 0u)' is not a constant expression.
Seems like an odd behaviour as clang++ is able to compile this successfully.
I have tested it on gcc 6, 7, 9 as well has "HEAD 11.0.0".
[Bug c++/97914] New: -fno-delete-null-pointer-checks not working properly with constexpr
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
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mfarazma.ext at gmail dot com
Target Milestone: ---
Compiling this code:
```
constexpr int test(const int *arr) {
if(arr == 0){
//
}
return 5;
}
int main(){
static constexpr int arr[] = {1,2,3};
static constexpr int b = test(arr);
return 0;
}
```
With "g++ -fno-delete-null-pointer-check test.cc" generates this error:
error '(((const int*)(& arr)) == 0u)' is not a constant expression.
Seems like an odd behaviour as clang++ is able to compile this successfully.
I have tested it on gcc 6, 7, 9 as well has "HEAD 11.0.0".
[Bug c++/97266] New: "enum constant in boolean context" warning seems incorrect
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
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mfarazma.ext at gmail dot com
Target Milestone: ---
```
#include
enum ValidateFlag : int8_t {
a = 0, b , c
};
int main(){
bool t = static_cast(c);
return static_cast(t);
}
```
Compiling the above code with `g++ -Wall test.cc` generates this warning:
warning: enum constant in boolean context [-Wint-in-bool-context]
The behaviour doesn't seem correct as `c` is just an `int8_t` value, and
casting an `int8_t` value to `bool` does not generate any warnings:
```
int8_t c = 2;
bool t = static_cast(c);
return static_cast(t);
```
Having only 2 values in the enum also makes it compile fine:
```
enum ValidateFlag : int8_t {
a = 0, c
};
```
[Bug c++/97266] "enum constant in boolean context" warning seems incorrect
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 = static_cast(c);
> > return static_cast(t);
> > }
> > ```
> >
> > Compiling the above code with `g++ -Wall test.cc` generates this warning:
> >
> > warning: enum constant in boolean context [-Wint-in-bool-context]
> >
> > The behaviour doesn't seem correct as `c` is just an `int8_t` value,
>
> No it isn't. In C enumerators are just integers, but in C++ they have the
> same type as the enumeration type they belong to.
>
But isn't the type of the enum set to be `int8_t` in this example?
In which case casting from `int8_t` to `bool` should be straight forward and
without warnings.
[Bug c++/97266] "enum constant in boolean context" warning seems incorrect
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 that type. Sorry for the confusion, I've tried creating a new variable with the following 2 types: ``` ValidateFlag v = c; bool t = static_cast(v); ``` and ``` int8_t i = c; bool t = static_cast(i); ``` and they both compile whiteout a warning, but using `c` itself causes the issue.
[Bug c++/97266] "enum constant in boolean context" warning seems incorrect
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: > > constexpr ValidateFlag v = c; > bool t = static_cast(v); > > which definitely seems inconsistent. I don't know what the intended > behaviour is, but it should be consistent. When using clang 12 there are no warning messages. We had to use "-Wno-int-in-bool-context" to disable the warning on gcc.
[Bug c++/100641] New: Link error when using extern thread_local variables on AIX
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
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mfarazma.ext at gmail dot com
Target Milestone: ---
Declaring a variable as "extern thread_local" in a C++ program leads to:
"ERROR: Undefined symbol: TLS init function for ..." during linking.
To reproduce:
file `0.cc`:
```
extern thread_local int foo;
int main(){
return foo;
}
```
file `1.cc`:
```
thread_local int foo = 1;
```
Then compile with `g++ 0.cc 1.cc` which produces this error:
```
ld: 0711-317 ERROR: Undefined symbol: TLS init function for foo
ld: 0711-317 ERROR: Undefined symbol: .TLS init function for foo
ld: 0711-317 ERROR: Undefined symbol: __get_tpointer
ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information.
collect2: error: ld returned 8 exit status
```
[Bug c++/100641] Link error when using extern thread_local variables on AIX
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
[Bug c++/100884] New: Comparing unsigned 32 bit integer values generates 64 bit compare instructions when optimized
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
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mfarazma.ext at gmail dot com
Target Milestone: ---
**0.c**
```
#include
uint32_t codegen();
int main(){
uint32_t expected = (codegen()) != 0 ? -1 : -2;
bool check_eq = expected == codegen();
if (!(check_eq)){
std::cout << "Check failed" << std::endl;
}
return 0;
}
```
**1.cc**
```
#include
uint32_t codegen(){
volatile int64_t a = -1;
return a;
}
```
Compile it with optimization enabled:
g++ -O3 0.cc 1.cc
Checking the generate code shows this instruction is generated for ` if
(!(check_eq)){...}`:
```
cmpdr31,r3
```
Compiling the same code with gcc version 8.4.0 emits this instead which is
correct:
```
cmpwcr7,r3,r31
```
This issue is causing failures as the returned value from `codegen()` may not
have its upper 32 bits cleared and using `cmpd` on it will create the wrong
output.
[Bug target/100884] Comparing unsigned 32 bit integer values generates 64 bit compare instructions when optimized
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/PPC-elf64abi.html#RETURN-VAL Will be closing this issue.
[Bug target/100884] Comparing unsigned 32 bit integer values generates 64 bit compare instructions when optimized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100884 m farazma changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from m farazma --- Details are mentioned in the above comment.
