http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55217
Michael Veksler changed:
What|Removed |Added
CC||mickey.veksler at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55217
--- Comment #2 from Michael Veksler ---
A much more clear-cut, weird, and severe case:
$ cat delta.c
int bar();
void foo()
{
int stop= 0;
for (int i=10 ; i>=0 && !stop; --i) {
stop= bar();
}
}
$ gcc -c -O3 -Wstrict-overflow=3
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mickey.veksler at gmail dot com
Target Milestone: ---
The following code should not compile, not when passed as a template argument
to std::intergral_constant :
constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89481
--- Comment #3 from Michael Veksler ---
Thanks for looking into it.
With the fix, does it behave the same way for:
- runtime evaluation of all_zeros()
- compile time evaluation such as std::integral_constant::value;
Currently (trunk 20190223
: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mickey.veksler at gmail dot com
Target Milestone: ---
// gcc version 9.0.0 20180720 (experimental)
// Compiled with -O3
int f(std::array & a, std::array & b)
{
a[0] = 1;
b[0] = 2;
return a[0];
}
Produce
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86619
--- Comment #2 from Michael Veksler ---
>> type-based alias analysis doesn't distinguish between int[2] and int[3].
Is it just the way GCC implements type-based alias analysis,
or is it defined that way in the C and C++ standards?
I suspect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86619
--- Comment #4 from Michael Veksler ---
It is interesting to check the impact on numerical C++ benchmarks.
Fortran has a conceptual restrict on all its parameter arrays,
since aliasing is not allowed.
void f(int * __restrict__ v1, int * __rest
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=18501
Michael Veksler changed:
What|Removed |Added
CC||mickey.veksler at gmail dot com
++
Assignee: unassigned at gcc dot gnu.org
Reporter: mickey.veksler at gmail dot com
Target Milestone: ---
template
auto work(Param && ...param)
{
return ("hi" ... / param);
}
int main()
{
std::cout << work(1.0, 2.0, 5, 4.0) << "
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: mickey.veksler at gmail dot com
Target Milestone: ---
According to
https://en.cppreference.com/w/cpp/container/unordered_map/deduction_guides
Deduction guides for unodrered_map
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86852
--- Comment #3 from Michael Veksler ---
I agree that this is a ridiculous example. That's why there should be an
official DR to it. It is a bad idea to have each compiler, do a different thing
-- that's why there is a C++ standard. clang are stic
ty: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: mickey.veksler at gmail dot com
Target Milestone: ---
The following is rejected by gcc (not by other compilers):
#include
#include
struct St : std::ostringstream {
template St& operator<<(
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86860
--- Comment #2 from Michael Veksler ---
Sounds reasonable. Thanks.
ty: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: mickey.veksler at gmail dot com
Created attachment 33383
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33383&action=edit
ostream vs. fprintf
I have tried
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55217
--- Comment #5 from Michael Veksler ---
Running the delta.c example with -fdump-tree-all-all-lineno produces
delta.c.125t.vrp2.
For some reason, stop_9 (which is the first stop_.* in the file) is initialized
with stop_9 = barD.1593 (), but it
15 matches
Mail list logo
