Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: sshannin at gmail dot com
Target Milestone: ---
Consider the two variants below:
double foo(char i) {
double f = i * 100;
return f / 100;
}
double bar(char i) {
return
-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: sshannin at gmail dot com
Target Milestone: ---
Noticed in example for PR96009.
Consider this simple function:
double bar(char i) {
return i;
}
Compiled with -O3, we get:
movsbl %dil, %edi
pxor %xmm0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96034
sshannin at gmail dot com changed:
What|Removed |Added
Resolution|--- |INVALID
Status
++
Assignee: unassigned at gcc dot gnu.org
Reporter: sshannin at gmail dot com
Target Milestone: ---
Consider the following:
seth@dev6:~/tmp$ cat opt.cpp
#include
struct X {
template
bool operator==(const T&) {
return false;
}
};
bool foo() {
std::option
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96269
--- Comment #2 from sshannin at gmail dot com ---
(In reply to Jonathan Wakely from comment #1)
> Your operator== should be const-qualified.
I don't disagree. I can also fully remove the operator== and it compiles as
well (why sh
++
Assignee: unassigned at gcc dot gnu.org
Reporter: sshannin at gmail dot com
Host: gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5)
Target: x86_64-linux-gnu
Build: Configured with: ../src/configure -v
--with-pkgversion='U
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58948
--- Comment #2 from sshannin at gmail dot com ---
Ahh, good call. I forgot that it would parse like that.
I wonder if there's any way to declare it such that the namespaces/types are
unambiguous that will parse correctly in both the c++11
: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: sshannin at gmail dot com
Target Milestone: ---
Reduced test case shown below. Easily resolved by fixing the code (capturing
COUNT or just moving its decl into the lambda), so not that interesting, but
still an ICE
++
Assignee: unassigned at gcc dot gnu.org
Reporter: sshannin at gmail dot com
Target Milestone: ---
seth@dev9:~$ cat tmp.cpp
#include
seth@dev9:~$ /build/toolchain13/bin/g++ tmp.cpp -Wctor-dtor-privacy -std=c++17
-c
In file included from tmp.cpp:1:
/build/toolchain13/include/c
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: sshannin at gmail dot com
Target Milestone: ---
For the man page shipped with 8.1.0, the description of
-Wunsafe-loop-optimizations still references the -funsafe-loop-optimizations
option, however that optimization is
Assignee: unassigned at gcc dot gnu.org
Reporter: sshannin at gmail dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at
gcc dot gnu.org
Target Milestone: ---
Code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90865
--- Comment #2 from sshannin at gmail dot com ---
Thanks for such a quick reply. I just wanted to make sure I'm understanding
you correctly about what you mean when you say this is expected.
Are you indicating that it's desirable that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90865
--- Comment #6 from sshannin at gmail dot com ---
Since we all agree that the current behavior is undesirable and since Jakub
proposes a possible solution, would it be reasonable to reopen this?
For large (multi-hour) test suites, it would be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90865
sshannin at gmail dot com changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: sshannin at gmail dot com
Target Milestone: ---
Created attachment 37541
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37541&action=edit
preprocessed source
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69600
--- Comment #1 from sshannin at gmail dot com ---
Created attachment 37542
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37542&action=edit
Error output
Error output from compiler.
Note it also fails to indicate which line the prob
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69600
--- Comment #3 from sshannin at gmail dot com ---
(In reply to Jonathan Wakely from comment #2)
> The value_type of your map is pair an you
> can't move the first part of that pair, and you can't copy the second part
> of that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66999
sshannin at gmail dot com changed:
What|Removed |Added
CC||sshannin at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69600
--- Comment #6 from sshannin at gmail dot com ---
Thanks for the update : )
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69600
--- Comment #4 from sshannin at gmail dot com ---
FWIW, this seems to be fixed on trunk. Still fails for at least 6.2, 5.4, and
4.9.4, but does compile with 7/trunk and 4.8.5
https://godbolt.org/g/hx9q4S
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: sshannin at gmail dot com
Host: Linux hostname 3.2.0-29-generic #46-Ubuntu SMP Fri Jul
27 17:03:23 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60750
--- Comment #3 from sshannin at gmail dot com ---
As a note that may help pin things down, removing either call to std::move() or
removing the concatenation with err_prefix done in call to the
std::runtime_error constructor seems to resolve this
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: sshannin at gmail dot com
Host: Linux hostname 3.2.0-29-generic #46-Ubuntu SMP Fri Jul
27 17:03:23 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
Target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59760
--- Comment #1 from sshannin at gmail dot com ---
For a simpler example, see
https://lists.debian.org/debian-gcc/2013/12/msg00107.html
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59760
--- Comment #3 from sshannin at gmail dot com ---
Created attachment 31821
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31821&action=edit
Preprocessed source
Preprocessed source of compilation from example in previous link.
Sou
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96269
--- Comment #6 from sshannin at gmail dot com ---
Thanks to you both for your analysis. As I said, I wasn't sure if it was an
issue, so I'm certainly willing to accept that it's not.
The one point I wanted to emphasize though ju
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: sshannin at gmail dot com
Target Milestone: ---
Created attachment 50136
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50136&action=edit
the code
I have attached a heavily
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69600
--- Comment #7 from sshannin at gmail dot com ---
Comment on attachment 37541
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37541
preprocessed source
> #include
> #include
> #include
>typedef std::unique_ptr inner_va
Assignee: unassigned at gcc dot gnu.org
Reporter: sshannin at gmail dot com
Target Milestone: ---
There are a number of other open bug reports about this warning, but none of
them seemed quite the same. This is different in that:
- doesn't rely on C++ constructs su
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118194
--- Comment #3 from sshannin at gmail dot com ---
> The wording is also quite confusing - it should probably say
'dereferencing 'p' would access uninitialized memory'.
Oh, indeed. I can certainly confirm that's how
30 matches
Mail list logo
