iority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: joerg.rich...@pdv-fs.de
Target Milestone: ---
#include
#include
std::ostream& func( std::ostream& os, std::string_view v )
{
return os << v;
}
This code re
ty: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: joerg.rich...@pdv-fs.de
Target Milestone: ---
cat > t.cc <
struct Bar
{
int size_;
Bar( int size )
: size_( size )
{}
};
template
Bar get( T const&a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91964
--- Comment #7 from Jörg Richter ---
Yes, I changed our code already to
if( C != Enum() )
But I still think that an explicit cast should always silence this warning.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91964
--- Comment #5 from Jörg Richter ---
There needs to be at least a way to suppress the warning with a cast
or some other construct (not pragma).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91964
--- Comment #2 from Jörg Richter ---
The only boolean context I see is the if(...).
The if() is never used with enum constants/types, but only bool-s and int-s.
So according to the warning name (int-in-bool-context) the warning can
be expected in
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: joerg.rich...@pdv-fs.de
Target Milestone: ---
cat > t.cc <(C) ) return true; // 3
if( static_cast(C) ) return true; // 4
if( static_cast( static_cast(C) ) ) retur
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91914
--- Comment #4 from Jörg Richter ---
The patch in comment #2 fixes the problem for us.
: unassigned at gcc dot gnu.org
Reporter: joerg.rich...@pdv-fs.de
Target Milestone: ---
cat > t.c <
#include
struct stringpool_t
{
char stringpool_str4[sizeof("Foo")];
char stringpool_str5[sizeof("Bar")];
};
static const struct stringpool_t stri
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: joerg.rich...@pdv-fs.de
Target Milestone: ---
This code:
#include
enum Foo
{
Bar
};
std::ostream operator<<( std::ostream& os, Foo );
std::ostream operator<<( std::
++
Assignee: unassigned at gcc dot gnu.org
Reporter: joerg.rich...@pdv-fs.de
Target Milestone: ---
cat > t.cc <prev_ ? child->prev_->next_ : parent->first_ ) = child->next_;
( child->next_ ? child->next_->prev_ : parent->last_ ) = child->prev_;
}
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: joerg.rich...@pdv-fs.de
Target Milestone: ---
cat > t.cc <
Stream& operator<<( T const& t )
{
return *this;
}
};
void xxx( Stream& os
Assignee: unassigned at gcc dot gnu.org
Reporter: joerg.rich...@pdv-fs.de
Target Milestone: ---
Division by constant is not optimized for __int128 dividend.
// This function will use shift+multiply
int64_t func64( int64_t val )
{
return val / 1000;
}
// This function will
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82008
--- Comment #2 from Jörg Richter ---
My original intention was to use the attribute to skip the nullptr check when
up-casting.
So my preference is to optimize based on the attribute if possible.
++
Assignee: unassigned at gcc dot gnu.org
Reporter: joerg.rich...@pdv-fs.de
Target Milestone: ---
cat > t.cc << EOF
struct Base1
{
char s;
};
struct Base2
{
char x;
};
struct Deriv : Base1, Base2
{};
void funcyyy( Base2* ) __attribute__((nonnull));
void funcx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81885
--- Comment #2 from Jörg Richter ---
Okay, I see your point. But I think calling operator->() to get the pointer is
not a very common use-case. Its more like get() is the right function for this
task.
ent: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: joerg.rich...@pdv-fs.de
Target Milestone: ---
unique_ptr::operator* is checked with __glibcxx_assert. But
unique_ptr::operator-> uses only _GLIBCXX_DEBUG_PEDASSERT. I think the later
can use __glibcxx_asse
++
Assignee: unassigned at gcc dot gnu.org
Reporter: joerg.rich...@pdv-fs.de
Target Milestone: ---
cat > t.cc < struct Quux
{
void foo() const
{
Baz baz;
if( !baz.val )
{
}
}
};
EOF
g++ -O2 -c t.cc -Wall
t.cc: In member function 'void Quux::
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81401
Jörg Richter changed:
What|Removed |Added
CC||joerg.rich...@pdv-fs.de
--- Comment #2
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: joerg.rich...@pdv-fs.de
Target Milestone: ---
cat > t.cc << EOF
struct S
{
~S() __attribute__((noreturn));
int a;
};
int foo()
{
false ? 5 : S().a;
}
EOF
g++ -c -Wall t.cc
GCC 6.2.0 prints:
t.cc: In
++
Assignee: unassigned at gcc dot gnu.org
Reporter: joerg.rich...@pdv-fs.de
Target Milestone: ---
cat > t.cc << EOF
#include
template struct Bar
{};
template struct Bar
{
template struct Bind { constexpr static int const cb = 0;
};
};
int foo()
{
return Bar:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70462
--- Comment #3 from Jörg Richter ---
Well, my real problem is related to coverage analysis. Function coverage will
show the base object constructor as not called. But my concrete test case is
more complex and involves virtual functions and inhe
nhancement
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: joerg.rich...@pdv-fs.de
Target Milestone: ---
g++ -std=c++11 -c -o t.o -x c++ - << EOF
struct Bar final
{
Bar();
};
Bar::Bar()
{}
EOF
nm t.o
gives:
00
Assignee: unassigned at gcc dot gnu.org
Reporter: joerg.rich...@pdv-fs.de
Target Milestone: ---
Host: powerpc-ibm-aix6.1.0.0
Target: powerpc-ibm-aix6.1.0.0
Build: powerpc-ibm-aix6.1.0.0
I am building GCC 4.9.2 on AIX 6.1 with the same script I used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64634
--- Comment #6 from Jörg Richter ---
Is this stable enough to be considered for 4.9.3?
Assignee: unassigned at gcc dot gnu.org
Reporter: joerg.rich...@pdv-fs.de
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
cat > t.c <
-profile
Assignee: unassigned at gcc dot gnu.org
Reporter: joerg.rich...@pdv-fs.de
cat > t.cc <
void catchEx()
{
exit(0);
try
{}
catch( int )
{}
}
int main()
{
try
{
throw 5;
}
catch(...)
{
catchEx();
}
}
EOF
g++ -o t t.cc -O0 --coverage
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59603
--- Comment #4 from Jörg Richter ---
Are you sure that this is not a iter_swap problem? I have found nothing in the
standard that iter_swap( x, x ) is undefined.
I always thought types do not have to be prepared to handle self move
assignment.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59603
Jörg Richter changed:
What|Removed |Added
CC||joerg.rich...@pdv-fs.de
--- Comment #2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59739
--- Comment #1 from Jörg Richter ---
clang seems to optimize all cases.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36368
Jörg Richter changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
ormal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: joerg.rich...@pdv-fs.de
The script below demonstrates that __builtin_LINE used in constructors
is different when the object is allocated with new. The same is true for
__builtin_FILE
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: joerg.rich...@pdv-fs.de
Created attachment 31786
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31786&action=edit
Script for demonstration
Attached is a script (t.s
: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: joerg.rich...@pdv-fs.de
g++ -std=c++11 -x c++ -c - <
using namespace std;
struct Win
{
void setMini( bool );
bool isMini();
};
bool neg( bool val );
void foo( Win* w )
{
function a = bind( &Win::setMini,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57724
--- Comment #5 from Jörg Richter ---
BTW: There is currently a discussion [1] on this topic on the
"ISO C++ Standard - Discussion" list.
[1]
https://groups.google.com/a/isocpp.org/d/msg/std-discussion/ehqGBMsswjk/nbsubYASnPgJ
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57724
--- Comment #2 from Jörg Richter ---
You mean the special case for 'void' does not apply in this case?
What a pity.
: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: joerg.rich...@pdv-fs.de
cat > t.cc <
ty: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: joerg.rich...@pdv-fs.de
cat > t.cc <
struct Wrap
{
inline static void call( Foo cc )
{
(cc.*MEMFUNC)(); // <- warning here
: minor
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: joerg.rich...@pdv-fs.de
cat t.cc << EOF
#include
#include
int main()
{
try
{
std::function()();
}
catch( std::exception const& e )
{
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55544
--- Comment #7 from Jörg Richter 2012-12-01 09:53:13
UTC ---
I see no reference to -fexcess-precision=standard in (garbage sink) bug 323, do
you? So IMHO this is not a dup.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55544
--- Comment #5 from Jörg Richter 2012-11-30 13:47:24
UTC ---
-ffloat-store works. But I dont want to use it in our project.
-msse2 -mfpmath=sse does not work.
I still see fildll,fnstcw,... instructions in the assembler listing.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55544
Jörg Richter changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Component|c
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: joerg.rich...@pdv-fs.de
$ cat t.c
#include
int main( int argc, char** argv )
{
long long v1;
sscanf( argv[1], "%lld", &a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52887
--- Comment #22 from Jörg Richter 2012-09-14 07:58:16
UTC ---
I have reduced a real live case. But still using .
$ cat t.cc
#include
struct ClassicUpdate
{
ClassicUpdate();
};
typedef std::vector ClassicUpdates;
struct UpdateData
{
Clas
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38172
Jörg Richter changed:
What|Removed |Added
CC||joerg.rich...@pdv-fs.de
--- Comment #5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52887
--- Comment #19 from Jörg Richter 2012-06-21 06:58:13
UTC ---
See also bug 53713. Hasn't been marked as a dup yet.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52887
--- Comment #10 from joerg.rich...@pdv-fs.de 2012-06-18 09:44:30 UTC ---
Created attachment 27649
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27649
Fix for undefined references
Patch for 4.7.1 with the two missing instantiations.
Wo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53713
--- Comment #2 from joerg.rich...@pdv-fs.de 2012-06-18 09:39:55 UTC ---
(In reply to comment #1)
> probably related to PR 52887
Yes, seems to be the same bug. But I've used --disable-bootstrap.
I am testing the proposed fixes for PR 5
Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: joerg.rich...@pdv-fs.de
$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/tools/pkg/gcc/4.7.1/libexec/gcc/powerpc-ibm-aix5.3.0.0/4.7.1/lto-wrapper
Target: powerpc-ibm-aix5.3.0.0
Configured
: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: joerg.rich...@pdv-fs.de
With GCC 4.7.0:
$ cat t.cc
#define XXX( x ) x
char const* str = XXX( R"(
)" );
$ g++ -std=c++0x -o t t.cc
t.cc:2:24: error: unterminated raw string
t.cc:2:1: error: st
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: joerg.rich...@pdv-fs.de
include/c++/4.7.0/cxxabi.h has the functions __cxa_get_globals() and
__cxa_get_globals_fast() returning a pointer to __cxa_eh_globals struct.
But __cxa_eh_globals isn't declared i
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: joerg.rich...@pdv-fs.de
cat > t.cc << EOF
struct Key
{
typedef int Ser;
};
template
struct Shell
{
template
typename T::
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: joerg.rich...@pdv-fs.de
-Wcast-qual seems to be broken since at least GCC 4.1.1.
cat > t.cc <
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50882
--- Comment #4 from joerg.rich...@pdv-fs.de 2011-10-27 14:44:14 UTC ---
Cannot test svn trunk. The loc_t issue still remains, see bug 50874.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50882
--- Comment #3 from joerg.rich...@pdv-fs.de 2011-10-27 10:10:43 UTC ---
Snapshot gcc-4.7-20111022 fails with:
../gcc-4.7-20111022/gcc/tree-diagnostic.c:59: error: conflicting types for
‘loc_t’
/usr/include/sys/localedef31.h:195: error: previous
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: joerg.rich...@pdv-fs.de
When building GCC 4.6.2 on AIX:
configure --enable-languages=c,c++ --disable-bootstrap --disable-nls
--with
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50882
--- Comment #1 from joerg.rich...@pdv-fs.de 2011-10-27 09:07:16 UTC ---
Forgot to mention that 4.6.1 builds without problems.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49559
--- Comment #22 from joerg.rich...@pdv-fs.de 2011-07-13 15:11:21 UTC ---
Is it possible to fix it for 4.6.2?
Following program is a 4.4 regression (when using -std=gnu++0x):
---8<-
#include
#include
#include
using namespace
++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: joerg.rich...@pdv-fs.de
$ cat t.cc
#include
#include
#include
struct MyMoveClass
{
int val_;
explicit MyMoveClass( int val = 0 )
: val_( val )
{
std::cout << "ctr this=" << this << std::
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48248
--- Comment #3 from joerg.rich...@pdv-fs.de 2011-03-28 13:51:55 UTC ---
(In reply to comment #2)
> Can't reproduce this, neither with g++ 4.5, nor trunk.
Did you delete the empty lines?
...@gcc.gnu.org
ReportedBy: joerg.rich...@pdv-fs.de
$ cat > t.cc << EOF
#include
template void func( T )
{}
int main( int, char** )
{
std::bind( func, 0 );
}
EOF
$ g++ t.cc -std=gnu++0x
t.cc: In function 'int main(int, char**)':
t.cc:8:27: error: cannot bind 'vo
Component: preprocessor
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: joerg.rich...@pdv-fs.de
$ cat > foobar.h << EOF
enum Foo
{
BAR
};
#define BAR(x)
#define BARBAR BAR
EOF
$ cat > main.cc << EOF
#include "foobar.h"
void func()
{
(void)BARBAR;
61 matches
Mail list logo
