Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: petschy at gmail dot com
In short:
In a loop, I write to and increment a pointer in each iteration. Then, after
the loop, I write to the pointer once more. I noticed that after the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57236
--- Comment #1 from petschy at gmail dot com ---
Created attachment 30089
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30089&action=edit
preprocessed source
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57236
--- Comment #2 from petschy at gmail dot com ---
Created attachment 30090
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30090&action=edit
original source
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57236
--- Comment #3 from petschy at gmail dot com ---
Created attachment 30091
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30091&action=edit
4.8.1 generated code of write2()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57236
--- Comment #4 from petschy at gmail dot com ---
Created attachment 30092
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30092&action=edit
clang 3.4 generated code of write2()
RMED
Severity: minor
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: petschy at gmail dot com
These are two separate issues, however, both occured in the same function, so I
think it's simpler to re
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57244
--- Comment #1 from petschy at gmail dot com ---
Created attachment 30093
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30093&action=edit
preprocessed source
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57244
--- Comment #2 from petschy at gmail dot com ---
Created attachment 30094
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30094&action=edit
original source
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57244
--- Comment #3 from petschy at gmail dot com ---
Created attachment 30095
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30095&action=edit
disassembly dump
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57236
--- Comment #5 from petschy at gmail dot com ---
I spotted a minor size inefficiency in the code:
0x00400720 <+32>:jle0x4007c5 <_Z6write2R6Streamj+197>
0x00400726 <+38>:mov%rdx,%rsi
0x000
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55097
Bug #: 55097
Summary: typedef not recognized in templated class
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priorit
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: petschy at gmail dot com
Background: freeing nodes of a tree allocated with custom allocators. One of
the allocators can't free individual pointers, so free() is NOP in that case
(the whole pool will be
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57723
--- Comment #1 from petschy at gmail dot com ---
Created attachment 30365
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30365&action=edit
test case source
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57723
--- Comment #2 from petschy at gmail dot com ---
Created attachment 30366
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30366&action=edit
gcc amd64 disassembly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57723
--- Comment #3 from petschy at gmail dot com ---
Created attachment 30367
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30367&action=edit
clang amd64 disassembly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57723
--- Comment #4 from petschy at gmail dot com ---
Ooops, the test case won't perform the freeing completely, since the recursive
call is not inside the 'down' traversal loop, so only the first node on the
given level would be recursi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57723
--- Comment #5 from petschy at gmail dot com ---
Created attachment 30368
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30368&action=edit
fixed test case (correct recursive traversal)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57723
--- Comment #7 from petschy at gmail dot com ---
Is it a plausible assumption that if a function is not marked as 'noreturn' and
the loop doesn't change the program's state then the loop could be optimized
away?
Cases:
- the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57723
--- Comment #10 from petschy at gmail dot com ---
Thanks for the explanation. The multithreaded argument is sound, but then, on
second thought, even in single threaded programs the state might be altered by
a signal handler, or another process if
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53770
Bug #: 53770
Summary: Regression: incorrect line numbers in debug info since
4.5+
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53770
--- Comment #1 from petschy at gmail dot com 2012-06-25 20:29:05 UTC ---
I tested on 32bit Debian Wheezy, too, with stock 4.6.3, and everything was ok.
Another AMD64 Wheezy box w/ stock 4.6.3 showed the bug, with a minor variation:
when the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52460
Bug #: 52460
Summary: Misleading error message with templated c++ code
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: minor
Pr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51640
Bug #: 51640
Summary: Misleading error if the type in the catch() is
ambiguous
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51640
--- Comment #1 from petschy at gmail dot com 2011-12-20 16:49:02 UTC ---
Created attachment 26155
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26155
a slightly more verbose test case
Extended test case with ambiguous type name in varia
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51640
--- Comment #2 from petschy at gmail dot com 2012-01-04 20:45:00 UTC ---
I pinpointed the commit that introduced the bug, using git bisect:
commit 4272a2e82e431ac85afd0404d49b28043dc480ee
Author: paolo
Date: Fri Nov 27 10:44:49 2009 +
git
++
Assignee: unassigned at gcc dot gnu.org
Reporter: petschy at gmail dot com
Target Milestone: ---
When compiling:
8<8<8<
struct Foo;
struct Bar
{
explicit Bar(Fooo* foo_) :
m_foo{foo_}
{
}
void Baz(F
ty: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: petschy at gmail dot com
Target Milestone: ---
class Parent;
class Derived;
Derived* foo(Parent* p)
{
return static_cast(p);
}
$ g++-9.0.0 -Wall -Wextra -
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: petschy at gmail dot com
Target Milestone: ---
struct Foo;
struct Bar
{
Bar(Foo f_) :
m_foo(f_)
{
}
Foo m_foo;
};
Foo baz1
: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: petschy at gmail dot com
Target Milestone: ---
Created attachment 44058
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44058&action=edit
source
Attached a simple Adler32 checksum class. When updating with a
++
Assignee: unassigned at gcc dot gnu.org
Reporter: petschy at gmail dot com
Target Milestone: ---
Created attachment 44062
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44062&action=edit
source
Attached the source of a simple Adler32 checksum class. The Update() fn is 32
bytes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85637
--- Comment #2 from petschy at gmail dot com ---
Thanks. For non-char types, one can use __restrict on ptrs, but for chars it
doesn't work, unfortunately (strict aliasing rules). Is there a way to tell the
compiler that a char ptr doesn&#x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85637
--- Comment #5 from petschy at gmail dot com ---
Thanks, in this specific case __restrict works indeed.
On a side note, is it possible to achieve the same when a char is stored
through a char* member, and also incremented? eg:
if (m_cur < m_
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: petschy at gmail dot com
Target Milestone: ---
Created attachment 44363
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44363&action=edit
test case
The attached source
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86436
--- Comment #2 from petschy at gmail dot com ---
Folding instantiations of member functions of class templates is a low hanging
fruit IMHO. So if they are not handled ATM, then consider this ticket as a
feature request, rather than a bug.
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: petschy at gmail dot com
Target Milestone: ---
Created attachment 43414
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43414&action=edit
source to reprod
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87531
petschy at gmail dot com changed:
What|Removed |Added
CC||petschy at gmail dot com
nt: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: petschy at gmail dot com
Target Milestone: ---
struct A
{
int i;
};
void foo(A& a)
{
auto l = [&a.i]() { };
}
void bar(A& a)
{
auto& i = a.i;
auto l = [&i]() { };
}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69673
--- Comment #2 from petschy at gmail dot com ---
Is this an accidental omission in the std, or allowing member access would
cause some trouble?
Thanks, Peter
++
Assignee: unassigned at gcc dot gnu.org
Reporter: petschy at gmail dot com
Target Milestone: ---
I made a fresh build from the gcc 7 master branch (6f0a524c). Now my code
doesn't compile:
common/src/mgsnetCRSARC4Base.cpp: In constructor
‘mgs::net::CRSARC4Base::CRSARC4Base(uin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79172
--- Comment #2 from petschy at gmail dot com ---
Created attachment 40563
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40563&action=edit
preprocessed source of the reduced test case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79172
--- Comment #3 from petschy at gmail dot com ---
$ g++-7.0.1 -pthread -Werror -Wall -Wextra
20170123-Wunused-but-set-parameter.cpp
20170123-Wunused-but-set-parameter.cpp: In constructor
‘CRSARC4Base::CRSARC4Base(unsigned int, unsigned int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77620
--- Comment #6 from petschy at gmail dot com ---
Would it be sensible to put an extra line to the output of 'gcc/g++ -v' if the
slow checks are enabled, which just states this fact / warns about (possibly
mentioning the use of --enabl
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: petschy at gmail dot com
Target Milestone: ---
Created attachment 39541
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39541&action=edit
C++ source
I r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77456
--- Comment #2 from petschy at gmail dot com ---
#22141 does not mention a DSE issue, nor a segfault of the compiler, so hardly
an exact duplicate.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77456
--- Comment #5 from petschy at gmail dot com ---
Sorry. Should I open dedicated bugs for them, or can you work from this single
one? Though the example code would be the same. Probably I would have picked a
more descriptive title mentioning the
: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: petschy at gmail dot com
Target Milestone: ---
Created attachment 39561
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39561&action=edit
C++ source
In fixbuf(), the return statement is commented out at line 7
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: petschy at gmail dot com
Target Milestone: ---
Created attachment 39563
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39563&action=edit
C++ source
A string is gener
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77456
--- Comment #8 from petschy at gmail dot com ---
I created two other bugs (bug 77482 for the segfault and bug 77485 for the DSE
issue). As I noted in the latter, I'm a bit confused about the store merging,
and what change Kyrill's patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77485
--- Comment #2 from petschy at gmail dot com ---
I agree that the generic case can become quite complicated: if after the
memset, the individual values are written with gaps between them, or multiple
contiguous chunks with gaps between them, it&#
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: petschy at gmail dot com
Target Milestone: ---
Created attachment 39575
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39575&action=edit
C++ source
g++-7.0.0 -Werror -Wall
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77502
--- Comment #1 from petschy at gmail dot com ---
I found another case: initializing an array of structs:
struct X
{
const char* p;
int i;
};
X x[] = {
{ "hello", 0 },
{ 0, 0 }, // !
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: petschy at gmail dot com
Target Milestone: ---
Created attachment 39580
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39580&action=edit
Preprocessed source, generated with g+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77513
--- Comment #2 from petschy at gmail dot com ---
I don't want to enable them. The problem is not with too little but too many
warnings.
A snippet from one of the problematic files:
{ NULL, NULL, false, false }
is preprocess
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77513
--- Comment #5 from petschy at gmail dot com ---
Some more details, hope this helps. Preprocessed one of the oddly behaving
files with 5.4.1, 6.2.1 and 7.0.0, then tried to compile each preprocessed file
with each compiler version. 5.4.1 warned
++
Assignee: unassigned at gcc dot gnu.org
Reporter: petschy at gmail dot com
Target Milestone: ---
I noticed that compiling my C++ project with 7.0 at -O3 took twice as much time
as before with earlier major versions. First I thought that it might be that
7.0 used more optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77620
--- Comment #2 from petschy at gmail dot com ---
Thanks, --enable-checking=release did the trick. Those unreleased checks
definitely have some runtime cost :)
My project was built in 3m35 with -O3, and the gcc master branch:
7.0.0
-O0
: unassigned at gcc dot gnu.org
Reporter: petschy at gmail dot com
Target Milestone: ---
Background: while trying to put cold data to a dedicated section I managed to
crash the compiler. The idea was that rarely used strings, eg src file names
and expressions of assertions will be separated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77787
--- Comment #1 from petschy at gmail dot com ---
That last function in json.hpp was gutted:
//template
int foo(int div_)
{
ASSERT(div_ == 0);
return 0;
}
Removed the assertions from all the template functions, as this moved the
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: petschy at gmail dot com
struct Foo
{
template
// error: attributes are not allowed on a function-definition
static int Bar() __attribute__
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60625
--- Comment #3 from petschy at gmail dot com ---
Thanks. It's then an inconsistency, right? Because the non-template fn def
didn't trigger the error while the template version did so.
Moreover, the error message is misleading, becau
Severity: minor
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: petschy at gmail dot com
When compiling the under code, g++ gives a misleading error message:
$ g++-5.0.0 -Wall 20141230-templ_base.cpp
20141230-templ_base.cpp:7:1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64446
--- Comment #1 from petschy at gmail dot com ---
One subtlety:
template
struct Base3
{
};
struct Foo3 : Base3
{
};
In this case complaining about missing template params is probably
inappropriate, since Base3<> is perfectly valid.
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: petschy at gmail dot com
Explanation of the attached code: Str is a stream class, Txn is its helper,
thus needs access to Str's private members. There is also a Glue class that is
suppos
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64596
--- Comment #1 from petschy at gmail dot com ---
Created attachment 3
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=3&action=edit
code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: petschy at gmail dot com
Access level is changed from protected (base class) to public (derived class)
via using declaration. The default ctor and the two overloaded
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64615
--- Comment #1 from petschy at gmail dot com ---
Created attachment 34457
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34457&action=edit
complete test case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53770
--- Comment #3 from petschy at gmail dot com ---
Tried now w/ g++ 4.9.1 (Debian 4.9.1-19), and single stepping is still wrong.
The only difference is that it doesn't stop on ++f in line 30 after breaking
out from the loop. However, all the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53770
--- Comment #4 from petschy at gmail dot com ---
Clarification: I double checked now, and the templated and the non-templated
versions (do_print vs do_print2) are the same, with the same disassembly, only
the addresses differing. This is true for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64596
--- Comment #3 from petschy at gmail dot com ---
(In reply to Daniel Krügler from comment #2)
1) if the friend declaration is invalid in line 15, then g++ should tell me so,
shouldn't it? But atm it compiles it, and the surprise comes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28901
petschy at gmail dot com changed:
What|Removed |Added
CC||petschy at gmail dot com
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: petschy at gmail dot com
The under code has two unused variables, which are references to classes. We
should have two warnings, however 4.9.1 and 5.0 trunk gives just one. 4.7.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63657
--- Comment #1 from petschy at gmail dot com ---
Bisected the regression:
commit a8b52ce38f3056e464457ba1e95efa25a8f08d07
Author: paolo
Date: Wed Jun 12 21:36:36 2013 +
/cp
2013-06-12 Paolo Carlini
PR c++/38958
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63657
--- Comment #4 from petschy at gmail dot com ---
Sorry, but this is definitely not the same issue. Bug 38958 is about returning
by value and binding to a reference. This issue is about returning a REFERENCE
and binding it to a reference. No class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63657
petschy at gmail dot com changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: petschy at gmail dot com
Without -march=native, the loops in the 3 fns are eliminated as expected,
resulting in single retq's.
With -march=native, the loop which calls the defined
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: petschy at gmail dot com
Some of the stores are eliminated in dtors already, if the values are not used
later. But if there are function calls after the stores, then they are not
eliminated. I
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: petschy at gmail dot com
When developing a binary i/o lib, I ran into some performance degradation in
the writer functions. My investigation revealed that the write pointer was
loaded
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62062
--- Comment #1 from petschy at gmail dot com ---
Created attachment 33274
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33274&action=edit
source
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62062
--- Comment #3 from petschy at gmail dot com ---
(In reply to Andrew Pinski from comment #2)
> Your inline asm is broken.
How? In unaliased_storeb()? That's for only proving that the redundant
loads/stores are not an artifact of aliasing
79 matches
Mail list logo
