gcc-bugs Library cleaner Book sterilizer for distributor looking for
Dear gcc-bugs, We just develop new device special for library book distributors. If you don't know where to find new products and how to make profits, Pls contact us for your interesting immediately. visit site at http://www.emetal.tw/protect/MF001.htm for library cleaner and http://www.emetal.tw/protect/UV001.htm for book sterilizer Sincerely, Eric Mayor eMetal Technology Ltd. 179-2, Sec. 3, Jianguo Rd., Fongshan City, Kaohsiung County 830, Taiwan Tel: +886-989707190 Fax: +886-7-7458015 www.emetal.tw/protect i...@emetal.tw 46718
[Bug c++/51571] No named return value optimization while adding a dummy scope
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51571
Guillaume Melquiond guillaume.melquiond at inria dot fr changed:
What|Removed |Added
CC||guillaume.melquiond at inria
dot f
||r
--- Comment #3 from Guillaume Melquiond guillaume.melquiond at inria dot fr
---
I have recently encountered a similar problem, but in a much more general case.
struct A {
A(int);
A(A const );
~A();
};
A f(bool b)
{
if (b) return A(0);
A a(1);
return a;
}
All the return statements dominated by variable a return a, so its
construction should happen in-place, hence eliding copy-construction and
destruction. Unfortunately, this is not what happens with g++ 4.8.0.
Interestingly enough, if one uninlines the code by hand, g++ actually generates
the optimal code, so it is possible though cumbersome to work around the missed
optimization:
inline A f2()
{
A a(1);
return a;
}
A f1(bool b)
{
if (b) return A(0);
return f2();
}
produces
A f1(bool) (bool b)
{
bb 2:
if (b_2(D) != 0)
goto bb 3;
else
goto bb 4;
bb 3:
A::A (_4(D), 0);
goto bb 5;
bb 4:
A::A (_4(D), 1);
bb 5:
return _4(D);
}
[Bug regression/57473] FAIL: gcc.dg/tls/emutls-2.c (internal compiler error)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57473 --- Comment #4 from Hans-Peter Nilsson hp at gcc dot gnu.org --- Seems to have been fixed with the Symtab cleanups 2/17 - merge alias code fix (r199577) or possibly with the same fix as for PR57467 (r199582).
[Bug middle-end/57503] New: [4.7/4.8 Regression] Expand uses wrong multiply routine
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57503
Bug ID: 57503
Summary: [4.7/4.8 Regression] Expand uses wrong multiply
routine
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: gjl at gcc dot gnu.org
Target: avr
Created attachment 30241
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30241action=edit
cecky.c
== Test case ==
#include stdlib.h
long __attribute__((__noinline__))
rot (unsigned char v)
{
unsigned vs = v * 255;
return (long) vs * 254;
}
int main (void)
{
long r = rot (129);
if (r != 8355330)
abort();
exit (0);
}
This program hits abort if compiled with 4.7.2 or 4.8.0.
== Command line ==
avr-gcc -mmcu=atmega168 cecky.c -Os -save-temps -dp -funsigned-char -o
cecky.elf -fdump-rtl-expand-details
== Configure ==
Configured with: ../../gcc.gnu.org/gcc-4_7-branch/configure --target=avr
--prefix=/local/gnu/install/gcc-4.7 --enable-languages=c,c++ --disable-nls
--disable-shared --with-dwarf2 --with-avrlibc=yes
[Bug middle-end/57503] [4.7/4.8 Regression] Expand uses wrong multiply routine
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57503
Georg-Johann Lay gjl at gcc dot gnu.org changed:
What|Removed |Added
CC||gjl at gcc dot gnu.org
--- Comment #1 from Georg-Johann Lay gjl at gcc dot gnu.org ---
Created attachment 30242
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30242action=edit
.expand dump
Notice that in rot(), long D.1484_5 is unused and instead the 32-bit value
D.1482_3 is used.
BTW, what does w* mean?
;; Function rot (rot, funcdef_no=4, decl_uid=1471, cgraph_uid=4)
rot (unsigned char v)
{
long int D.1484;
long int D.1483;
int D.1482;
int D.1481;
# BLOCK 2 freq:1
# PRED: ENTRY [100.0%] (fallthru,exec)
D.1481_2 = (int) v_1(D);
D.1482_3 = v_1(D) w* 255;
D.1484_5 = (long int) D.1482_3;
D.1483_6 = D.1482_3 w* 254;
return D.1483_6;
# SUCC: EXIT [100.0%]
}
[Bug middle-end/57503] [4.7/4.8 Regression] Expand uses wrong multiply routine
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57503 Georg-Johann Lay gjl at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-06-02 Ever confirmed|0 |1
[Bug middle-end/57503] [4.7/4.8 Regression] Expand uses wrong multiply routine
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57503 --- Comment #2 from Georg-Johann Lay gjl at gcc dot gnu.org --- (In reply to Georg-Johann Lay from comment #1) Created attachment 30242 [details] .expand dump Notice that in rot(), long D.1484_5 is unused and instead the 32-bit value D.1482_3 is used. 16-bit, of course. In the s-file you can see that __usmulhisi3 is used. This is a widening 16-bit unsigned * 16-bit signed multiplication and not correct here.
[Bug c++/57504] New: invalid this pointer passed in call to virtual function that returns a struct
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57504
Bug ID: 57504
Summary: invalid this pointer passed in call to virtual
function that returns a struct
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: bugzilla at cems dot de
/*The following code compiles without diagnostic in both gcc 4.6.2 and gcc
4.7.2. It produces correct code in gcc 4.6.2 but incorrect code in gcc 4.7.2.
The error occurs with or without optimization. No other compiler switches were
used. The mingw builds of gcc are used.
*/
#include iostream
using namespace std;
struct S { int a, b, c, d; }; //must be more than 8 bytes to generate bug
struct Base
{ int i;
virtual S f() = 0;
void g() { f(); }
};
struct Middle : virtual Base //intermediate class needed to generate bug
{ int i;
};
struct Derived : Middle
{ S f()
{ cerr this endl
return S();
}
};
int main()
{ Derived d;
d.f();
d.g(); //incorrect value of this pointer in gcc 4.7.2
d.f();
}
/*
When compiled with gcc 462, all three calls to d.f() and d.g() show the same
value of the this pointer.
When compiled with gcc 472, the call to g.d() shows a wrong this pointer.
In code examples where the function called with an invalid this pointer
accesses members of the class, a run-time segmentation fault is typicallly
generated.
Workaround: When using virtual fucntions that return structures, gcc 4.7.x
should not be used. gcc 4.6.x is ok. gcc 4.8.x and later are not yet available
for mingw.
*/
[Bug c++/57502] Expected error Declaration doesn't declare anything, but code compiles fine for user-defined class with using decltype, but not with built-in types.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57502
Daniel Krügler daniel.kruegler at googlemail dot com changed:
What|Removed |Added
CC||daniel.kruegler@googlemail.
||com
--- Comment #1 from Daniel Krügler daniel.kruegler at googlemail dot com ---
The problem exists in gcc 4.9.0 20130519 (experimental) as well. It seems also
to exist for other user-defined types such as enumeration types:
enum E {};
decltype(E{}); // Accepted
Neither -predantic nor -predantic-errors makes any difference.
[Bug c++/57504] invalid this pointer passed in call to virtual function that returns a struct
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57504 Daniel Krügler daniel.kruegler at googlemail dot com changed: What|Removed |Added CC||daniel.kruegler@googlemail. ||com --- Comment #1 from Daniel Krügler daniel.kruegler at googlemail dot com --- I tested your program with both gcc 4.7.2 and gcc 4.9.0 20130519 (experimental) on my mingw-64-bit system after fixing the missing semicolon of the cerr this endl statement. For the 64-bit-builds (-m64) both compilers return the same pointer values. I can confirm that for -m32 I get indeed a pointer value difference using gcc 4.7.2 as you describe. This difference does not occur for the -m64 version of any compiler and it does not occur for -m32 using gcc 4.9.0 20130519 (experimental), so it seems to be fixed on trunk. You may want to test it with gcc 4.8, you can get a version for it from http://www.equation.com/servlet/equation.cmd?fa=fortran
[Bug fortran/55574] [4.7/4.8 Regression] C binding access to c_ptr type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55574 Mikael Morin mikael at gcc dot gnu.org changed: What|Removed |Added CC||mikael at gcc dot gnu.org Summary|[4.7/4.8/4.9 Regression] C |[4.7/4.8 Regression] C |binding access to c_ptr |binding access to c_ptr |type|type --- Comment #6 from Mikael Morin mikael at gcc dot gnu.org --- This is fixed on trunk (upcoming 4.9.0). As Tobias' fix is somewhat intrusive, another patch which I posted at http://gcc.gnu.org/ml/fortran/2013-03/msg8.html was considered for 4.8 and 4.7 backport. But this will probably end up with a WONTFIX for the branches.
[Bug fortran/56079] [4.7/4.8 Regression] ICE with C_PTR renaming and TRANSFER
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56079 Mikael Morin mikael at gcc dot gnu.org changed: What|Removed |Added CC||mikael at gcc dot gnu.org Summary|[4.7/4.8/4.9 Regression]|[4.7/4.8 Regression] ICE |ICE with C_PTR renaming and |with C_PTR renaming and |TRANSFER|TRANSFER --- Comment #8 from Mikael Morin mikael at gcc dot gnu.org --- It works with trunk (upcoming 4.9.0).
[Bug libstdc++/57505] New: [C++11] destructor of std::function should be noexcept
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57505 Bug ID: 57505 Summary: [C++11] destructor of std::function should be noexcept Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: f.heckenb...@fh-soft.de Created attachment 30243 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30243action=edit Test case According to http://en.cppreference.com/w/cpp/utility/functional/function/~function, the destructor of std::function, like all standard destructors, should be noexcept, but as the attached test case shows, it isn't so: % g++-4.7 -std=c++11 test.cpp test.cpp:4:1: error: static assertion failed: ~function is not noexcept
[Bug middle-end/57503] [4.7/4.8 Regression] Expand uses wrong multiply routine
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57503 --- Comment #3 from Andrew Pinski pinskia at gcc dot gnu.org --- I thought this was fixed for 4.8 by bug 54295.
[Bug libstdc++/57505] [C++11] destructor of std::function should be noexcept
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57505 --- Comment #1 from Frank Heckenbach f.heckenb...@fh-soft.de --- Created attachment 30244 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30244action=edit Test case for enable_shared_from_this The same applies to std::enable_shared_from_this.
[Bug libstdc++/57505] [C++11] destructor of std::function should be noexcept
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57505 --- Comment #2 from Daniel Krügler daniel.kruegler at googlemail dot com --- This is fixed in gcc 4.9 trunk and I believe it has already been fixed in gcc 4.8 due to bug #50043.
[Bug middle-end/57503] [4.7/4.8 Regression] Expand uses wrong multiply routine
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57503 --- Comment #4 from Georg-Johann Lay gjl at gcc dot gnu.org --- Created attachment 30245 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30245action=edit cecky2.c: More test case (In reply to Andrew Pinski from comment #3) I thought this was fixed for 4.8 by bug 54295. My 4.8 is dated some days before the release candidate, around 2013-03-06. If I understand correctly, that 4.8.0 (experimental) contains the fix for PR54295 but still generates wrong code? And I don't see a backport to 4.7. Thus the fix for PR54295 is not complete, or this is an other, unrelated problem.
[Bug middle-end/57503] [4.7/4.8 Regression] Expand uses wrong multiply routine
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57503 --- Comment #5 from Georg-Johann Lay gjl at gcc dot gnu.org --- Created attachment 30246 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30246action=edit cecky2.s: Addembler dump with -dP from 4.8.0 (experimental) 2013-03-06
[Bug target/57506] New: [avr] Some devices are present twice in avr-mcus.def
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57506 Bug ID: 57506 Summary: [avr] Some devices are present twice in avr-mcus.def Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: minor Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: gjl at gcc dot gnu.org CC: eric.weddington at atmel dot com Target: avr avr-mcus.def has doublicate entries for some devices: atmega16hva, atmega16hva2, atmega16hvb, atmega16m1, atmega16u4, atmega32hvb, atmega32a, atmega32c1, ... See also the duplicates in the documentation at http://gcc.gnu.org/onlinedocs/gcc-4.8.1/gcc/AVR-Options.html#AVR-Options
[Bug target/57506] [avr] Some devices are present twice in avr-mcus.def
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57506 Georg-Johann Lay gjl at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P5 Status|UNCONFIRMED |NEW Last reconfirmed||2013-06-02 Target Milestone|--- |4.8.2 Ever confirmed|0 |1
[Bug libstdc++/57505] [C++11] destructor of std::function should be noexcept
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57505 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Target Milestone|--- |4.8.0 --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org --- Yes, this is already fixed.
[Bug c++/57419] Access control doesn't stop referring to a deleted function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57419 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |paolo.carlini at oracle dot com Target Milestone|--- |4.9.0 --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com --- finish_qualified_id_expr gets a complain == 0 and then just calls mark_used which has naked error calls.
[Bug libstdc++/53477] pretty printer fails with: Python Exception type 'exceptions.IndexError' list index out of range
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53477 asmwarrior asmwarrior at gmail dot com changed: What|Removed |Added CC||asmwarrior at gmail dot com --- Comment #3 from asmwarrior asmwarrior at gmail dot com --- I have the same error when try to print a stl container, see the log: (this happens when I debug Code::Blocks), I'm using GCC 4.6.3 and GDB CVS HEAD. [debug] p m_Headers [debug]Python Exception type 'exceptions.IndexError' list index out of range: [debug]$2 = std::set with 1 elements [debug]cb_gdb:
[Bug libstdc++/53477] pretty printer fails with: Python Exception type 'exceptions.IndexError' list index out of range
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53477 --- Comment #4 from asmwarrior asmwarrior at gmail dot com --- This is what I get when I enable the python stack print: set python print-stack full [debug] set python print-stack full [debug]cb_gdb: p m_Headers [debug] p m_Headers [debug]Traceback (most recent call last): [debug] File E:\code\gcc\PCXMinGW463\bin\libstdcxx\v6\printers.py, line 477, in children [debug]rep_type = find_type(self.val.type, '_Rep_type') [debug] File E:\code\gcc\PCXMinGW463\bin\libstdcxx\v6\printers.py, line 52, in find_type [debug]field = typ.fields()[0] [debug]IndexError: list index out of range [debug]$3 = std::set with 1 elements [debug]cb_gdb: Thanks.
[Bug libstdc++/53477] pretty printer fails with: Python Exception type 'exceptions.IndexError' list index out of range
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53477
--- Comment #5 from asmwarrior asmwarrior at gmail dot com ---
p /r m_Headers
[debug] p /r m_Headers
[debug]$5 = (StringSet ) @0x116d0bc4: {_M_t = {_M_impl =
{std::allocatorstd::_Rb_tree_nodewxString =
{__gnu_cxx::new_allocatorstd::_Rb_tree_nodewxString = {No data
fields}, No data fields}, _M_key_compare = {std::binary_functionwxString,
wxString, bool = {No data fields}, No data fields}, _M_header = {_M_color
= std::_S_red, _M_parent = 0x116d2d28, _M_left = 0x116d2d28, _M_right =
0x116d2d28}, _M_node_count = 1}}}
[debug]cb_gdb:
When I see the E:\code\gcc\PCXMinGW463\bin\libstdcxx\v6\printers.py, I see in
the line: 476
def children (self):
rep_type = find_type(self.val.type, '_Rep_type')
node = find_type(rep_type, '_Link_type')
node = node.strip_typedefs()
return self._iter (RbtreeIterator (self.val), node)
The variable is declared as: StringSet m_Headers;
and the StringSet is defined as: typedef std::setwxString StringSet;
Hope those information can help to solve this bug.
[Bug middle-end/56341] GCC produces unaligned data access
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56341 --- Comment #10 from Sandra Loosemore sandra at codesourcery dot com --- I'm working on a new patch that addresses the first problem, the failure in test(). I think the second failure is not in test1() at all, and has nothing to do with -fstrict-volatile-bitfields. Looks to me like problem is that the expression x1-t1 is returning an unaligned pointer due to the packed attribute on struct test2. It should probably not be allowed to take the address of a packed struct field, at least on targets that require strict alignment. H, that bug is already filed as PR 41809. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41809
