NoSuchMethodError
With Sun Java 1.6.0.12 everything is ok. $ java -jar fmmdemo.jar Exception during event dispatch: java.lang.NoSuchMethodError: method edu.umiacs.fmm.gui.dialog.DialogAbout.setLocationByPlatform with signature (Z)V was not found. at edu.umiacs.fmm.gui.dialog.DialogAbout.initComponents(DialogAbout.java:37) at edu.umiacs.fmm.gui.dialog.DialogAbout.(DialogAbout.java:22) at edu.umiacs.fmm.gui.FmmDemo.initComponents(FmmDemo.java:32) at edu.umiacs.fmm.gui.FmmDemo.(FmmDemo.java:18) at edu.umiacs.fmm.gui.FmmDemo$12.run(FmmDemo.java:331) at java.awt.event.InvocationEvent.dispatch(libgcj.so.90) at java.awt.EventQueue.dispatchEvent(libgcj.so.90) at java.awt.EventDispatchThread.run(libgcj.so.90) when I was running jars from http://www.umiacs.umd.edu/~wpwy/fmm/ $ gcc -v Using built-in specs. Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.2-1.1' --with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3 --program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr --enable-cld --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.3.2 (Debian 4.3.2-1.1)
Not exception-safe default move constructors (demonstrated on std::pair)
Hi!
I'm not really sure which (g++ or libstdc++) problem this really is, so
posting into both lists.
The problem is described here:
http://cpp-next.com/archive/2009/10/exceptionally-moving/
- You have two classes:
A, which has a proper move constructor which doesn't throw
B, which which only has copy constructor which may throw
- You have an std::pair
- You move a pair
std::pair pair1;
try {
std::pair pair2(std::move(a));
}
What happens:
- A part is moved with move constructor. This is obviously destructive
to pair1.
- B part is copied as it doesn't have move constuctor.
- Now, that copy constructor throws (which is pretty expectable is it
likely allocates resources). After this, as A part was already moved,
we're left with corrupted pair1 (with empty A part).
The same problem applies to most containers, but, for example, in
std::vector it is solved gracefully:
--- bits/vector.tcc from gcc-4.8:
pointer __tmp = _M_allocate_and_copy(__n,
_GLIBCXX_MAKE_MOVE_IF_NOEXCEPT_ITERATOR(this->_M_impl._M_start),
_GLIBCXX_MAKE_MOVE_IF_NOEXCEPT_ITERATOR(this->_M_impl._M_finish));
---
so move semantics are only used IF the type has non-throwing(noexcept)
move constructor.
However, with pair this does not apply:
--- bits/stl_pair.h from gcc-4.8:
struct pair {
...
constexpr pair(pair&&) = default;
---
Either the default constructor generated by gcc is unsafe, or there
should be custom, safe move constuctor with corresponding enable_if.
I lean towards the former, as safe default move constuctors should be
always generated probably, and specific ones may be really hard to
implement for more complex types (tuples).
I've written a small program which demonstrates the problem:
https://gist.github.com/AMDmi3/5005557
tested it on FreeBSD with gcc-4.8 and on Debian with gcc-4.7, and it
showed problem on both.
Is this really a gcc problem? Should I file a bug?
--
Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D
amd...@amdmi3.ru ..: jabber: amd...@jabber.ruhttp://www.amdmi3.ru
[Bug target/85683] New: [8 Regression] GCC 8 stopped using RMW (Read Modify Write) instructions on x86[_64]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85683
Bug ID: 85683
Summary: [8 Regression] GCC 8 stopped using RMW (Read Modify
Write) instructions on x86[_64]
Product: gcc
Version: 8.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: dmitry at zend dot com
Target Milestone: ---
GCC 8 stopped generation of RMW instructions and uses 3 instructions instead of
one. Although, this shouldn't affect executed uops, this increases code size
(pressure to instruction decoder and instruction cache) and requires an extra
register (that may cause extra spills and related degradations).
=== test_rmw.c ===
typedef struct _refcounted {
unsigned int refcount;
} refcounted;
typedef struct _value {
refcounted *val;
} value;
extern void value_dtor_func(refcounted *val);
void ptr_dtor(value *ptr)
{
refcounted *ref = ptr->val;
--ref->refcount;
if (ref->refcount == 0) {
value_dtor_func(ref);
}
}
===
$ gcc -O2 -S test_rmw.c
$ cat test_rmw.s
movq(%rdi), %rdi
movl(%rdi), %eax
subl$1, %eax
movl%eax, (%rdi)
je .L4
ret
.L4:
jmp value_dtor_func
[Bug c/43686] New: GCC doesn't duplicate computed gotos for functions marked as "hot"
I've found the bug working on direct threaded interpreter for PHP. Moving from
GCC 4.3 to GCC 4.4 caused a significant performance degradation. Looking into
produced assembler code I realized that GCC 4.4 doesn't replace all jmps to
indirect jmp with indirect jmp itself. The reason is the following new
condition in function duplicate_computed_gotos() bb-reorder.c
if (!optimize_bb_for_size_p (bb))
continue;
I thought I would able to fix the problem using "hot" attribute, but
according to this condition, in case I mark function with __attribute__((hot))
duplication doesn't work, and in case I mark it with __attribute__((cold)) it
starts work. As result "hot" function works slower than "cold".
You can use the simplified code to verify it. I ran it with 'gcc -O2 -S
direct.c'
direct.c
#define NEXT goto **ip++
#define guard(n) asm("#" #n)
__attribute__((cold)) void *emu (void **prog)
{
static void *labels[] =
{&&next1,&&next2,&&next3,&&next4,&&next5,&&next6,&&next7,&&next8,&&next9,&&loop};
void **ip;
intcount;
if (!prog) {
return labels;
}
ip=prog;
count = 1000;
NEXT;
next1:
guard(1);
NEXT;
next2:
guard(2);
NEXT;
next3:
guard(3);
NEXT;
next4:
guard(4);
NEXT;
next5:
guard(5);
NEXT;
next6:
guard(6);
NEXT;
next7:
guard(7);
NEXT;
next8:
guard(8);
NEXT;
next9:
guard(9);
NEXT;
loop:
if (count>0) {
count--;
ip=prog;
NEXT;
}
return 0;
}
int main() {
void *prog[] = {(void*)0,(void*)1,
(void*)0,(void*)2,
(void*)0,(void*)3,
(void*)0,(void*)4,
(void*)0,(void*)9};
void **labels = emu(0);
int i;
for (i=0; i < sizeof(prog)/sizeof(prog[0]); i++) {
prog[i] = labels[(int)prog[i]];
}
emu(prog);
return 0;
}
I saw that the check causing the slowdown was removed in trunk, however I can't
check that it was done in a proper way.
--
Summary: GCC doesn't duplicate computed gotos for functions
marked as "hot"
Product: gcc
Version: 4.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dmitry at zend dot com
GCC build triplet: i686-redhat-linux
GCC host triplet: i686-redhat-linux
GCC target triplet: i686-redhat-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43686
[Bug c/43686] GCC doesn't duplicate computed gotos for functions marked as "hot"
--- Comment #2 from dmitry at zend dot com 2010-04-08 13:54 --- yes. It's definitely the same issue. The only additional note that __attribute__((hot)) doesn't fix the problem (as I would expect tracing down optimize_bb_for_size_p()), but makes an additional slowdown. In opposite, the __attribute__((cold)) solves the issue. It looks very strange. I suppose some condition has to be inverted :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43686
[Bug ada/24381] New: Error in visibility rules of formal generic packages
The error occures in the following code: -- a.ads generic type T is digits <>; package A is end A; -- b.ads with A; generic with package AA is new A (<>); package B is end B; -- c.ads with A; generic with package AA is new A (<>); package C is end C; - d.ads with B, C; generic with package BB is new B (<>); with package CC is new C (BB.AA); package D is X : BB.AA.T; -- "T" is not a visible entity of "AA" end D; [In the case when the formal package CC is excluded from the list of formal packages of D, it is compiled successfully. It seems that CC "hides" specifications of BB.] The output of gcc -v -save-temps -c d.ads: -- Reading specs from c:/gnat/bin/../lib/gcc/pentium-mingw32msv/3.4.5/specs Configured with: /gnatmail-gap-2005a/build-toulouse//src/configure --prefix=/gnat-prefix --enable-languages=c,c++,ada --disable-nls --disable-checking --disable-libada --enable-threads=win32 --disable-sjlj-exceptions pentium-mingw32msv Thread model: win32 gcc version 3.4.5 20050524 (prerelease) for GNAT GPL 2005 (20050614) c:/gnat/bin/../libexec/gcc/pentium-mingw32msv/3.4.5/gnat1.exe -quiet -dumpbase d.ads -mtune=pentium d.ads -o C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp/cccD.s d.ads:6:13: "T" is not a visible entity of "AA" -- Summary: Error in visibility rules of formal generic packages Product: gcc Version: 3.4.5 Status: UNCONFIRMED Severity: normal Priority: P2 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mailbox at dmitry-kazakov dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24381
[Bug c++/31951] local structure problem
--- Comment #3 from dmitry at lsi dot upc dot edu 2009-10-05 14:42 --- (In reply to comment #1) > This is not a bug, local classes cannot be template arguments. > What does prevent them to be? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31951
[Bug c++/23833] New: warning: "ignoring packed attribute on unpacked non-POD field" on templates
gcc ver 3.4.3 system type: any g++ -v -save-temps -Wall test.cpp i see bug 17519 but this can be other bug. -- Summary: warning: "ignoring packed attribute on unpacked non-POD field" on templates Product: gcc Version: 3.4.3 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: Dmitry dot Chepel at acronis dot com CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23833
[Bug c++/23833] warning: "ignoring packed attribute on unpacked non-POD field" on templates
--- Additional Comments From Dmitry dot Chepel at acronis dot com 2005-09-12 13:45 --- Created an attachment (id=9709) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9709&action=view) output from compler -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23833
[Bug c++/23833] warning: "ignoring packed attribute on unpacked non-POD field" on templates
--- Additional Comments From Dmitry dot Chepel at acronis dot com 2005-09-12 13:46 --- Created an attachment (id=9710) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9710&action=view) the preprocessed file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23833
[Bug c++/23833] warning: "ignoring packed attribute on unpacked non-POD field" on templates
--- Additional Comments From Dmitry dot Chepel at acronis dot com
2005-09-12 13:46 ---
#include
template
struct GuidTemplate
{
char kk;
D TimeLow;
W TimeMid;
W TimeHiAndVer;
union
{
char ClkSeqAndNodeArray[8];
long long ClkSeqAndNodeQword;
struct
{
char ClkSeqHiAndVariant;
char ClkSeqLow;
char Node[6];
};
};
GuidTemplate() {}
} __attribute__ ((packed));
typedef GuidTemplate LeGuid;
struct PartitionEntry
{
LeGuid PartitionTypeGuid; // Unique ID that defines the purpose and type of
this Partition.
// A value of zero defines that this partition
// record is not being used.
LeGuid UniquePartitionGuid;// GUID that is unique for every partition
record. Every
// partition ever created will have a unique GUID.
This
// GUID must be assigned when the GUID Partition
Entry
// is created. The GUID Partition Entry is created
when
// ever the NumberOfPartitionEntries in the
// GUID Partition Table Header is increased to
include a
// larger range of addresses.
//le_qword StartingLba;// Starting LBA of the partition defined by this
record
///le_qword EndingLba; // Ending LBA of the partition defined by this
record
//le_qword Attributes; // All bit EFI Reserved
//le_word PartitionName[GPT_PARTITION_NAME_LENGTH]; // Human readable
Unicode string identification
} __attribute__ ((packed));
int main()
{
PartitionEntry entry;
std::cout << "sizeof structute LeGuid = " << sizeof(LeGuid) << "\n";
std::cout << "sizeof structute PartitionEntry = " << sizeof(PartitionEntry)
<<
"\n";
return 0;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23833
