[Bug fortran/50375] gfortran must complain on NULL() ambiguity without MOLD
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50375 --- Comment #5 from Tobias Burnus burnus at gcc dot gnu.org 2011-09-14 06:26:14 UTC --- Author: burnus Date: Wed Sep 14 06:26:07 2011 New Revision: 178841 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=178841 Log: 2011-09-14 Tobias Burnus bur...@net-b.de PR fortran/34547 PR fortran/50375 * check.c (gfc_check_null): Allow allocatables as MOLD to NULL. * resolve.c (resolve_transfer): Reject NULL without MOLD. * interface.c (gfc_procedure_use): Reject NULL without MOLD if no explicit interface is known. (gfc_search_interface): Reject NULL without MOLD if it would lead to ambiguity. 2011-09-14 Tobias Burnus bur...@net-b.de PR fortran/34547 PR fortran/50375 * gfortran.dg/null_5.f90: New. * gfortran.dg/null_6.f90: New. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/check.c trunk/gcc/fortran/interface.c trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/34547] NULL(): Fortran 2003 changes, accepts invalid, ICE on invalid
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34547 --- Comment #4 from Tobias Burnus burnus at gcc dot gnu.org 2011-09-14 06:27:30 UTC --- Author: burnus Date: Wed Sep 14 06:27:25 2011 New Revision: 178842 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=178842 Log: Really add: 2011-09-14 Tobias Burnus bur...@net-b.de PR fortran/34547 PR fortran/50375 * gfortran.dg/null_5.f90: New. * gfortran.dg/null_6.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/null_5.f90 trunk/gcc/testsuite/gfortran.dg/null_6.f90
[Bug fortran/34547] NULL(): Fortran 2003 changes, accepts invalid, ICE on invalid
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34547 --- Comment #3 from Tobias Burnus burnus at gcc dot gnu.org 2011-09-14 06:26:13 UTC --- Author: burnus Date: Wed Sep 14 06:26:07 2011 New Revision: 178841 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=178841 Log: 2011-09-14 Tobias Burnus bur...@net-b.de PR fortran/34547 PR fortran/50375 * check.c (gfc_check_null): Allow allocatables as MOLD to NULL. * resolve.c (resolve_transfer): Reject NULL without MOLD. * interface.c (gfc_procedure_use): Reject NULL without MOLD if no explicit interface is known. (gfc_search_interface): Reject NULL without MOLD if it would lead to ambiguity. 2011-09-14 Tobias Burnus bur...@net-b.de PR fortran/34547 PR fortran/50375 * gfortran.dg/null_5.f90: New. * gfortran.dg/null_6.f90: New. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/check.c trunk/gcc/fortran/interface.c trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/50375] gfortran must complain on NULL() ambiguity without MOLD
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50375 --- Comment #6 from Tobias Burnus burnus at gcc dot gnu.org 2011-09-14 06:27:30 UTC --- Author: burnus Date: Wed Sep 14 06:27:25 2011 New Revision: 178842 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=178842 Log: Really add: 2011-09-14 Tobias Burnus bur...@net-b.de PR fortran/34547 PR fortran/50375 * gfortran.dg/null_5.f90: New. * gfortran.dg/null_6.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/null_5.f90 trunk/gcc/testsuite/gfortran.dg/null_6.f90
[Bug tree-optimization/49452] [4.7 regression] comp-goto-2.c regresses in testing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49452 --- Comment #21 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-09-14 06:48:01 UTC --- All callee saved registers should never changed after function call. Here fp has been changed is not because it is after a function call, it is because it is after the target of non local goto. I'm not familiar with the implementation of non local goto, but I guess there is some convention/protocol defines which registers may be changed after the target of a non local goto. That's not the problem. The problem is that the blockage isn't honored.
[Bug fortran/50375] gfortran must complain on NULL() ambiguity without MOLD
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50375 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #7 from Tobias Burnus burnus at gcc dot gnu.org 2011-09-14 07:17:48 UTC --- FIXED on the trunk (for 4.7). Thanks for the report!
[Bug fortran/34547] NULL(): Fortran 2003 changes, accepts invalid, ICE on invalid
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34547 --- Comment #5 from Tobias Burnus burnus at gcc dot gnu.org 2011-09-14 07:19:03 UTC --- The patch fixes the issues of comment 0. However, one should go through the lengthy, convoluted thread at http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/f014195ccf7b93e6/ to check whether it contains some still-unfixed issues.
[Bug middle-end/50325] [4.7 Regression] 76 new fails with rev. 177691
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50325
--- Comment #4 from Andreas Krebbel krebbel at gcc dot gnu.org 2011-09-14
07:20:14 UTC ---
I've looked into the 22_locale/money_get/get/char/13.cc failure.
The problem is a miscompilation of locale-inst.cc in libstdc++.
Source:
templatetypename _CharT, typename _InIter
_InIter
money_get_CharT, _InIter::
do_get(iter_type __beg, iter_type __end, bool __intl, ios_base __io,
ios_base::iostate __err, long double __units) const
{
string __str;
__beg = __intl ? _M_extracttrue(__beg, __end, __io, __err, __str)
: _M_extractfalse(__beg, __end, __io, __err, __str);
std::__convert_to_v(__str.c_str(), __units, __err, _S_get_c_locale());
return __beg;
}
The result of _M_extract is copied into the return ptr field of the
function. This assignment copies 12 bytes:
MEM[(struct iter_type *)__beg] = MEM[(struct iter_type *)D.23511];
expand_assignement expands this using store_field. However
store_bit_field_1 does not seem to handle BLKmode copies correctly for
byte big endian targets if the source cannot exactly be covered by
word mode operands. It calls itself recursively for the last chunk with:
store_bit_field_1 (str_rtx=0x3fff6528a38, bitsize=32, bitnum=64,
bitregion_start=0, bitregion_end=0,
fieldmode=DImode, value=0x3fff6528ab0, fallback_p=true)
with value being (subreg:DI (reg:TI 70) 8)
But copying 4 bytes from that value on a big endian target results in
a src value of (subreg:DI (reg:TI 70) 12) so the wrong word is being
copied here.
[Bug lto/50383] ICE in lto_symtab_register_decl, at lto-symtab.c:148
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50383 --- Comment #2 from Jan Hubicka hubicka at gcc dot gnu.org 2011-09-14 07:38:03 UTC --- Created attachment 25267 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25267 somewhat reducted testcase.
[Bug other/50384] Copying a char array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50384
--- Comment #1 from Marc Glisse marc.glisse at normalesup dot org 2011-09-14
08:23:15 UTC ---
Don't know if it is the same problem, but gcc seems to have trouble optimizing
with structs:
//typedef struct A { unsigned char t; } A;
typedef unsigned char A;
extern A f(A,A);
A g(A x,A y){ return f(y,x); }
Gives a nice:
movzbl%dil, %eax
movzbl%sil, %edi
movl%eax, %esi
jmpf
whereas if I use the struct definition on the line above:
movl%edi, %eax
subq$8, %rsp
.cfi_def_cfa_offset 16
movl%esi, %edi
movl%eax, %esi
callf
addq$8, %rsp
.cfi_def_cfa_offset 8
ret
Somehow gcc doesn't realize that the 2 codes are equivalent (at least that's
how I understand the ABI).
[Bug fortran/50378] MALLOC_CHECK_ glibc detects free() invalid pointer in compiler
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50378 --- Comment #8 from Vittorio Zecca zeccav at gmail dot com 2011-09-14 08:23:39 UTC --- gfortran 4.7.0 fixes this one. However, sometimes I get the following: /home/vitti/gcc-4.7/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.7.0/f951: symbol lookup error: /home/vitti/gcc-4.7/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.7.0/f951: undefined symbol: mpfr_get_z_exp Never got this one, I have mpfr-3.0.0-4 How can I fix it?
[Bug fortran/50392] New: SIGSEGV in gfc_trans_label_assign
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50392 Bug #: 50392 Summary: SIGSEGV in gfc_trans_label_assign Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: zec...@gmail.com Created attachment 25268 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25268 just compile it SIGSEGV in gfc_trans_label_assign
[Bug fortran/50393] New: free() invalid pointer in mio_expr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50393 Bug #: 50393 Summary: free() invalid pointer in mio_expr Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: zec...@gmail.com Created attachment 25269 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25269 just compile it with MALLOC_CHECK_=1 free() invalid pointer in mio_expr
[Bug c++/48320] [C++0x][4.6/4.7 Regression] Template parameter packs cannot be expanded in default template arguments
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48320 Dodji Seketeli dodji at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #6 from Dodji Seketeli dodji at gcc dot gnu.org 2011-09-14 08:40:15 UTC --- Fixed in gcc-4_6-branch and in trunk (4.7).
[Bug middle-end/50325] [4.7 Regression] 76 new fails with rev. 177691
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50325 --- Comment #5 from Andreas Krebbel krebbel at gcc dot gnu.org 2011-09-14 08:41:21 UTC --- Created attachment 25270 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25270 Experimental fix On S/390 all the failures disappear with that patch.
[Bug fortran/50378] MALLOC_CHECK_ glibc detects free() invalid pointer in compiler
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50378 --- Comment #9 from Tobias Burnus burnus at gcc dot gnu.org 2011-09-14 08:50:04 UTC --- (In reply to comment #8) x86_64-unknown-linux-gnu/4.7.0/f951: symbol lookup error: undefined symbol: mpfr_get_z_exp Never got this one, I have mpfr-3.0.0-4 See http://www.mpfr.org/mpfr-3.0.0/#changes and http://www.mpfr.org/mpfr-3.0.1/mpfr.html#Changed-Functions mpfr_get_z_exp changed in MPFR 3.0 [...] this function has been renamed to mpfr_get_z_2exp in MPFR 3.0 and mpfr_get_z_exp is still available via a macro in mpfr.h. Seemingly, you have a f951 which has been compiled with MPFR 2.x but you run it with MPFR 3. In that case, the macro does not help. gfortran calls this function for real-to-integer conversions, which seems to be the only use.
[Bug fortran/50393] free() invalid pointer in mio_expr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50393 Mikael Morin mikael at gcc dot gnu.org changed: What|Removed |Added CC||mikael at gcc dot gnu.org --- Comment #1 from Mikael Morin mikael at gcc dot gnu.org 2011-09-14 09:11:27 UTC --- (In reply to comment #0) Created attachment 25269 [details] just compile it with MALLOC_CHECK_=1 free() invalid pointer in mio_expr Valgrind doesn't complain on FreeBSD. Did you manage to fix your mpfr issue?
[Bug fortran/50392] SIGSEGV in gfc_trans_label_assign
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50392 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-09-14 Ever Confirmed|0 |1 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-09-14 09:46:41 UTC --- Confirmed on gfortran 4.4.6, 4.5.3, 4.6.1, and trunk (r178842). The backtrace is pr50392.f90:3.20: assign 1 to kf 1 Warning: Deleted feature: ASSIGN statement at (1) kf Program received signal SIGSEGV, Segmentation fault. gfc_trans_label_assign (code=value optimized out) at ../../work/gcc/fortran/trans-stmt.c:107 107 len = GFC_DECL_STRING_LEN (se.expr); (gdb) bt #0 gfc_trans_label_assign (code=value optimized out) at ../../work/gcc/fortran/trans-stmt.c:107 #1 0x0001000b4d48 in trans_code (code=value optimized out, cond=value optimized out) at ../../work/gcc/fortran/trans.c:1204 #2 0x0001000dbb64 in gfc_generate_function_code (ns=value optimized out) at ../../work/gcc/fortran/trans-decl.c:5211 #3 0x000100072f5d in gfc_parse_file () at ../../work/gcc/fortran/parse.c:4404 #4 0x0001000af786 in gfc_be_parse_file () at ../../work/gcc/fortran/f95-lang.c:250 #5 0x0001007b72bc in toplev_main (argc=2, argv=0x7fff5fbfdc08) at ../../work/gcc/toplev.c:548 #6 0x00011974 in start ()
[Bug c++/50391] [C++0x] ICE on invalid code, pair with incomplete type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50391 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-09-14 Ever Confirmed|0 |1
[Bug lto/50394] New: [meta-bug] Issues with building libreoffice with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50394 Bug #: 50394 Summary: [meta-bug] Issues with building libreoffice with LTO Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassig...@gcc.gnu.org ReportedBy: hubi...@gcc.gnu.org This is tracking PR for libreoffice issues, similar to PR45375
[Bug lto/50394] [meta-bug] Issues with building libreoffice with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50394 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-09-14 Depends on||50383, 50381 Ever Confirmed|0 |1 --- Comment #1 from Jan Hubicka hubicka at gcc dot gnu.org 2011-09-14 09:55:19 UTC --- Currently libreoffice dies building svx at PR50383. Also there are couple of errors even with -fpermissive. Could someone look into that?
[Bug c++/50391] [C++0x] ICE on invalid code, pair with incomplete type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50391 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Target Milestone|--- |4.7.0
[Bug c++/50391] [C++0x] ICE on invalid code, pair with incomplete type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50391 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |paolo.carlini at oracle dot |gnu.org |com --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2011-09-14 10:09:11 UTC --- On it.
[Bug fortran/50393] free() invalid pointer in mio_expr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50393 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org 2011-09-14 10:33:35 UTC --- (In reply to comment #1) just compile it with MALLOC_CHECK_=1 free() invalid pointer in mio_expr Valgrind doesn't complain on FreeBSD. No problems either on x86-64-linux (w/ MALLOC_CHECK_, MALLOC_PERTURB_ but also with valgrind). Given that the code is rather standard, it must be either a local problem or one of the nasty race-condition bugs, which only trigger very rarely.
[Bug fortran/50392] SIGSEGV in gfc_trans_label_assign
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50392 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-valid-code CC||burnus at gcc dot gnu.org --- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org 2011-09-14 10:42:55 UTC --- The code looks valid (Fortran 90) to me. Except that kf needs to be re-defined before returning from the function. From Fortran 95's deleted section: B.1.4 ASSIGN, assigned GO TO, and assigned FORMAT The definitions of the ASSIGN and assigned GO TO statements are: assign-stmt is ASSIGN label TO scalar-int-variable Constraint: The label shall be the statement label of a branch target statement or format-stmt that appears in the same scoping unit as the assign-stmt. Constraint: scalar-int-variable shall be named and of type default integer. [...] Execution of an ASSIGN statement causes a statement label to be assigned to an integer variable. While defined with a statement label value, the integer variable may be referenced only in the context of an assigned GO TO statement or as a format specifier in an input/output statement. An integer variable defined with a statement label value may be redefined with a statement label value or an integer value.
[Bug testsuite/50322] [avr]: fail: gcc.dg/tree-ssa/ivopts-lt.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50322 vries at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Keywords|missed-optimization | Last reconfirmed||2011-09-14 Component|tree-optimization |testsuite CC||vries at gcc dot gnu.org AssignedTo|unassigned at gcc dot |vries at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #3 from vries at gcc dot gnu.org 2011-09-14 11:01:25 UTC --- the testcase uses 'long int' and 'char*', and the transformation is done provided they are the same size. avr sizes int : 2 long int : 4 long long int: 8 char*: 2 Changing 'long int' to 'int' makes the testcase pass for avr. The testcase needs to be adapted.
[Bug lto/50383] ICE in lto_symtab_register_decl, at lto-symtab.c:148
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50383 --- Comment #3 from Jan Hubicka hubicka at gcc dot gnu.org 2011-09-14 11:32:47 UTC --- Created attachment 25271 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25271 More reduced testcase
[Bug lto/50383] ICE in lto_symtab_register_decl, at lto-symtab.c:148
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50383 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added Attachment #25271|0 |1 is obsolete|| --- Comment #4 from Jan Hubicka hubicka at gcc dot gnu.org 2011-09-14 11:53:29 UTC --- Created attachment 25272 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25272 reduced testcase again ;)
[Bug middle-end/50325] [4.7 Regression] 76 new fails with rev. 177691
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50325 --- Comment #6 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-09-14 12:42:06 UTC --- Created attachment 25270 [details] Experimental fix I'll test the patch on ppc-darwin9, but it will take some time on my slow machine. Meanwhile do you understand why the tests do not fail on powerpc64-unknown-linux-gnu (see http://gcc.gnu.org/ml/gcc-testresults/2011-09/msg01230.html ) and why there are only 30 failures on darwin?
[Bug fortran/47978] [OOP] Invalid INTENT in overriding TBP not detected
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47978 --- Comment #7 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-09-14 13:31:15 UTC --- Janus, I am worried about your fix as it seems to break at least the original tests of pr41656 and pr41685: pr41656.f90:68.13: procedure, pass(a) :: s_scal = s_coo_scal 1 Error: Argument mismatch for the overriding procedure 's_scal' at (1): INTENT mismatch in argument 'a' pr41656.f90:67.13: procedure, pass(a) :: s_scals = s_coo_scals 1 Error: Argument mismatch for the overriding procedure 's_scals' at (1): INTENT mismatch in argument 'a' pr41656.f90:174.6: use s_base_mat_mod 1 Fatal Error: Can't open module file 's_base_mat_mod.mod' for reading at (1): No such file or directory Could you double check with Salvatore that it is the intended behavior?
[Bug lto/50383] ICE in lto_symtab_register_decl, at lto-symtab.c:148
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50383
Markus Trippelsdorf markus at trippelsdorf dot de changed:
What|Removed |Added
CC||markus at trippelsdorf dot
||de
--- Comment #5 from Markus Trippelsdorf markus at trippelsdorf dot de
2011-09-14 13:32:17 UTC ---
More reduced:
% cat test.cpp
typedef long unsigned int size_t;
extern C {
typedef unsigned short sal_uInt16;
};
class Resource {
};
namespace com {
namespace sun {
namespace star {
namespace uno {
class BaseReference {
};
enum UnoReference_Query {
UNO_QUERY, UNO_REF_QUERY
};
template class interface_type class Reference:public BaseReference {
public:
inline static void *operator new (:: size_t nSize) {
}
inline Reference (const BaseReference rRef, UnoReference_Query);
};
class Exception {
};
class XInterface {
};
}
}
}
}
class OutputDevice:public Resource {
};
class Window:public OutputDevice {
};
class SystemWindow:public Window {
};
class Dialog:public SystemWindow {
};
class ModalDialog:public Dialog {
};
class TabPage:public Window {
};
class SvListEntry {
};
class SvLBoxEntry:public SvListEntry {
};
namespace com {
namespace sun {
namespace star {
namespace beans {
class XPropertySet: public::com::sun::star::uno::XInterface {
};
}
namespace xforms {
class XFormsUIHelper1: public::com::sun::star::uno::XInterface {
};
class XSubmission;
}
}
}
}
namespace svxform {
struct ItemNode;
typedef::com::sun::star::uno::Reference
::com::sun::star::xforms::XFormsUIHelper1 XFormsUIHelper1_ref;
typedef::com::sun::star::uno::Reference ::com::sun::star::beans::XPropertySet
XPropertySet_ref;
typedef::com::sun::star::uno::Reference ::com::sun::star::xforms::XSubmission
XSubmission_ref;
class XFormsPage: TabPage {
XFormsUIHelper1_ref m_xUIHelper;
bool DoToolBoxAction (sal_uInt16 _nToolBoxID);
SvLBoxEntry *AddEntry (const XPropertySet_ref _rPropSet);
void EditEntry (const XPropertySet_ref _rPropSet);
};
class AddSubmissionDialog: ModalDialog {
public:
AddSubmissionDialog (Window *pParent, ItemNode *_pNode, const
XFormsUIHelper1_ref _rUIHelper);
XSubmission_ref GetNewSubmission () const {
}
};
}
using namespace::com::sun::star::beans;
using namespace::com::sun::star::uno;
namespace css =::com::sun::star;
namespace svxform {
bool XFormsPage::DoToolBoxAction (sal_uInt16 _nToolBoxID)
{
switch (_nToolBoxID) {
case 12: {
{
AddSubmissionDialog aDlg (this, __null, m_xUIHelper);
{
try {
Reference css::xforms::XSubmission xNewSubmission =
aDlg.GetNewSubmission ();
Reference XPropertySet xNewPropSet
(xNewSubmission, UNO_QUERY);
SvLBoxEntry *pEntry = AddEntry (xNewPropSet);
} catch (Exception ) {
}
}
}
}
}
}
SvLBoxEntry *XFormsPage::AddEntry (const Reference XPropertySet _rEntry)
{
}
void XFormsPage::EditEntry (const Reference XPropertySet _rEntry)
{
}
}
% g++ -o /dev/null -O0 -nostdlib -Wfatal-errors -fpreprocessed -fpermissive
-flto -w -r -fpermissive test.cpp
lto1: internal compiler error: in lto_symtab_register_decl, at lto-symtab.c:148
[Bug fortran/47978] [OOP] Invalid INTENT in overriding TBP not detected
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47978 --- Comment #9 from Salvatore Filippone sfilippone at uniroma2 dot it 2011-09-14 13:46:00 UTC --- (In reply to comment #8) The test case in my original post is wrong in this respect I mean: in the original post for pr41656.
[Bug fortran/47978] [OOP] Invalid INTENT in overriding TBP not detected
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47978 --- Comment #8 from Salvatore Filippone sfilippone at uniroma2 dot it 2011-09-14 13:45:13 UTC --- Duh! My bad: all versions of scal are supposed to update the A dummy argument, which should be INTENT(INOUT). The test case in my original post is wrong in this respect :( Salvatore
[Bug fortran/47978] [OOP] Invalid INTENT in overriding TBP not detected
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47978 --- Comment #11 from janus at gcc dot gnu.org 2011-09-14 13:49:24 UTC --- Hi Dominique, I am worried about your fix as it seems to break at least the original tests of pr41656 and pr41685: thanks for noticing. But, from a quick glance, I would say that you don't need to worry: When committing the INTENT check, I had to modify 'dynamic_dispatch_5' in the testsuite, which is just the test case for PR41656. I checked that it is indeed invalid. However, I would be even more relieved if Salvatore could tell us that his latest code still compiles with gfortran ... Cheers, Janus
[Bug fortran/47978] [OOP] Invalid INTENT in overriding TBP not detected
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47978 --- Comment #10 from janus at gcc dot gnu.org 2011-09-14 13:49:04 UTC --- Hi Dominique, I am worried about your fix as it seems to break at least the original tests of pr41656 and pr41685: thanks for noticing. But, from a quick glance, I would say that you don't need to worry: When committing the INTENT check, I had to modify 'dynamic_dispatch_5' in the testsuite, which is just the test case for PR41656. I checked that it is indeed invalid. However, I would be even more relieved if Salvatore could tell us that his latest code still compiles with gfortran ... Cheers, Janus
[Bug bootstrap/50395] New: Infinite loop when bootstrapping java
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50395 Bug #: 50395 Summary: Infinite loop when bootstrapping java Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: kreb...@gcc.gnu.org During java bootstrap the s390x-ibm-linux-gnu/32/libjava/.libs/lt-gcj-dbtool gets trapped in an endless loop after throwing an exception. It has been introduced between r176700 and r176730. Most revisions in between do not bootstrap due to compilation errors caused by the first bunch of dwarf2cfi patches (r176701 - r176704). Here are a few GDB backtraces from the endless loop: #0 0x75aca982 in _Unwind_RaiseException () from /lib/libgcc_s.so.1 #1 0x76877d4a in _Jv_Throw (value=0x75534648) at /build/gcc-head/libjava/exception.cc:118 #2 0x768b949e in java::lang::Class::initializeClass (this=0x77cbda48) at /build/gcc-head/libjava/java/lang/natClass.cc:808 #3 0x76868894 in _Jv_InitClass (klass=0x77cbda48) at /build/gcc-head/libjava/java/lang/Class.h:742 #4 _Jv_AllocObjectNoFinalizer (klass=0x77cbda48) at /build/gcc-head/libjava/prims.cc:586 #5 0x768dd77a in gnu.gcj.runtime.PersistentByteMap.init(gnu.gcj.runtime.PersistentByteMap, java.io.File, int, int)void (this=@75b16ee0, m=Unhandled dwarf expression opcode 0xf3 ) at /build/gcc-head/libjava/gnu/gcj/runtime/PersistentByteMap.java:181 #6 0x768ddaba in gnu.gcj.runtime.PersistentByteMap.emptyPersistentByteMap(java.io.File, int, int)gnu.gcj.runtime.PersistentByteMap (name=@75530e90, capacity=32749, strtabSize=1047968) at /build/gcc-head/libjava/gnu/gcj/runtime/PersistentByteMap.java:231 #7 0x00403aa4 in gnu.gcj.tools.gcj_dbtool.Main.main(java.lang.String[])void (s=@75558c00) at /build/gcc-head/libjava/gnu/gcj/tools/gcj_dbtool/Main.java:82 #0 0x76877b0e in base_of_encoded_value (encoding=1 '\001', context=0x0) at /build/gcc-head/libjava/.././libjava/../libgcc/unwind-pe.h:102 #1 0x76877f50 in read_encoded_value (version=Unhandled dwarf expression opcode 0xf3 ) at /build/gcc-head/libjava/.././libjava/../libgcc/unwind-pe.h:284 #2 __gcj_personality_v0 (version=Unhandled dwarf expression opcode 0xf3 ) at /build/gcc-head/libjava/exception.cc:373 #3 0x75aca988 in _Unwind_RaiseException () from /lib/libgcc_s.so.1 #4 0x76877d4a in _Jv_Throw (value=0x75534648) at /build/gcc-head/libjava/exception.cc:118 #5 0x768b949e in java::lang::Class::initializeClass (this=0x77cbda48) at /build/gcc-head/libjava/java/lang/natClass.cc:808 #6 0x76868894 in _Jv_InitClass (klass=0x77cbda48) at /build/gcc-head/libjava/java/lang/Class.h:742 #7 _Jv_AllocObjectNoFinalizer (klass=0x77cbda48) at /build/gcc-head/libjava/prims.cc:586 #8 0x768dd77a in gnu.gcj.runtime.PersistentByteMap.init(gnu.gcj.runtime.PersistentByteMap, java.io.File, int, int)void (this=@75b16ee0, m=Unhandled dwarf expression opcode 0xf3 ) at /build/gcc-head/libjava/gnu/gcj/runtime/PersistentByteMap.java:181 #9 0x768ddaba in gnu.gcj.runtime.PersistentByteMap.emptyPersistentByteMap(java.io.File, int, int)gnu.gcj.runtime.PersistentByteMap (name=@75530e90, capacity=32749, strtabSize=1047968) at /build/gcc-head/libjava/gnu/gcj/runtime/PersistentByteMap.java:231 #10 0x00403aa4 in gnu.gcj.tools.gcj_dbtool.Main.main(java.lang.String[])void (s=@75558c00) at /build/gcc-head/libjava/gnu/gcj/tools/gcj_dbtool/Main.java:82 #0 0x76878170 in read_encoded_value (version=Unhandled dwarf expression opcode 0xf3 ) at /build/gcc-head/libjava/.././libjava/../libgcc/unwind-pe.h:284 #1 get_ttype_entry (version=Unhandled dwarf expression opcode 0xf3 ) at /build/gcc-head/libjava/exception.cc:200 #2 __gcj_personality_v0 (version=Unhandled dwarf expression opcode 0xf3 ) at /build/gcc-head/libjava/exception.cc:438 #3 0x75aca988 in _Unwind_RaiseException () from /lib/libgcc_s.so.1 #4 0x76877d4a in _Jv_Throw (value=0x75534648) at /build/gcc-head/libjava/exception.cc:118 #5 0x768b949e in java::lang::Class::initializeClass (this=0x77cbda48) at /build/gcc-head/libjava/java/lang/natClass.cc:808 #6 0x76868894 in _Jv_InitClass (klass=0x77cbda48) at /build/gcc-head/libjava/java/lang/Class.h:742 #7 _Jv_AllocObjectNoFinalizer (klass=0x77cbda48) at /build/gcc-head/libjava/prims.cc:586 #8 0x768dd77a in gnu.gcj.runtime.PersistentByteMap.init(gnu.gcj.runtime.PersistentByteMap, java.io.File, int, int)void (this=@75b16ee0, m=Unhandled dwarf expression opcode 0xf3 ) at /build/gcc-head/libjava/gnu/gcj/runtime/PersistentByteMap.java:181 #9 0x768ddaba in gnu.gcj.runtime.PersistentByteMap.emptyPersistentByteMap(java.io.File, int, int)gnu.gcj.runtime.PersistentByteMap (name=@75530e90, capacity=32749, strtabSize=1047968) at /build/gcc-head/libjava/gnu/gcj/runtime/PersistentByteMap.java:231 #10 0x00403aa4 in gnu.gcj.tools.gcj_dbtool.Main.main(java.lang.String[])void (s=@75558c00) at
[Bug target/50176] [4.7 Regression] 4.7 generates spill-fill dealing with char-int conversion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50176
--- Comment #7 from Igor Zamyatin izamyatin at gmail dot com 2011-09-14
14:30:35 UTC ---
In RTL everythin is vice-versa, additional instruction appears:
For the bad case couple instructions are responsible for cb load (asmcons
dump):
(insn 52 51 53 5 (set (reg:QI 83 [ D.2685 ])
(mem:QI (plus:SI (reg/v/f:SI 75 [ inptr1 ])
(reg/v:SI 117 [ col ])) [0 MEM[base: inptr1_19, index:
col_90, offset: 0B]+0 S1 A8])) ../test_bad_4_6.c:42 66 {*movqi_internal}
(nil))
and later
(insn 62 61 122 5 (parallel [
(set (reg:SI 152 [ D.2685 ])
(zero_extend:SI (reg:QI 83 [ D.2685 ])))
(clobber (reg:CC 17 flags))
]) ../test_bad_4_6.c:47 123 {*zero_extendqisi2_movzbl_and}
(expr_list:REG_DEAD (reg:QI 83 [ D.2685 ])
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil
while in good case only one:
(insn 52 51 53 5 (parallel [
(set (reg/v:SI 84 [ cb ])
(zero_extend:SI (mem:QI (plus:SI (reg/v/f:SI 75 [ inptr1 ])
(reg/v:SI 119 [ col ])) [0 MEM[base: inptr1_19,
index: col_90, offset: 0B]+0 S1 A8])))
(clobber (reg:CC 17 flags))
]) ../test_good_4_6.c:42 123 {*zero_extendqisi2_movzbl_and}
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil)))
And life ranges in bad case became splitted:
a34(r152): [71..82]
a38(r83): [83..92]
And in good case only:
a34(r84): [71..90]
[Bug middle-end/50251] [4.7 Regression] Revision 178353 caused many test failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50251 --- Comment #19 from vries at gcc dot gnu.org 2011-09-14 14:32:12 UTC --- Author: vries Date: Wed Sep 14 14:32:07 2011 New Revision: 178853 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=178853 Log: 2011-09-14 Tom de Vries t...@codesourcery.com PR middle-end/50251 * explow.c (emit_stack_restore): Set crtl-need_drap if stack_restore is emitted. Modified: trunk/gcc/ChangeLog trunk/gcc/explow.c
[Bug middle-end/50251] [4.7 Regression] Revision 178353 caused many test failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50251 vries at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #21 from vries at gcc dot gnu.org 2011-09-14 14:37:46 UTC --- patch and test-case checked in.
[Bug middle-end/50251] [4.7 Regression] Revision 178353 caused many test failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50251 --- Comment #20 from vries at gcc dot gnu.org 2011-09-14 14:33:40 UTC --- Author: vries Date: Wed Sep 14 14:33:35 2011 New Revision: 178854 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=178854 Log: 2011-09-14 Tom de Vries t...@codesourcery.com PR middle-end/50251 * gcc.dg/pr50251.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr50251.c Modified: trunk/gcc/testsuite/ChangeLog
[Bug libstdc++/43241] std::tr1::regex is not fully implemented yet
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43241 Scott A. Colcord sacolcor at provide dot net changed: What|Removed |Added CC||sacolcor at provide dot net --- Comment #8 from Scott A. Colcord sacolcor at provide dot net 2011-09-14 14:59:01 UTC --- Now that regex has been ratified as part of the C++11 standard, shouldn't failure to support it be considered a bug? At the least, it seems like a WONTFIX status isn't appropriate, because (as I understand it) WONTFIX means that even if someone were to offer to do the work, there's no interest in accepting it into the tree.
[Bug fortran/47978] [OOP] Invalid INTENT in overriding TBP not detected
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47978 --- Comment #12 from Salvatore Filippone sfilippone at uniroma2 dot it 2011-09-14 15:02:46 UTC --- (In reply to comment #11) relieved if Salvatore could tell us that his latest code still compiles with gfortran ... Cheers, Janus Yes it does. No (new) worries here Salvatore
[Bug libstdc++/43241] std::tr1::regex is not fully implemented yet
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43241 --- Comment #9 from Paolo Carlini paolo.carlini at oracle dot com 2011-09-14 15:09:45 UTC --- tr1::regex is definitely a wontfix. std::regex is a completely different matter, of course should be implemented, maybe you can help?!?
[Bug libstdc++/43241] std::tr1::regex is not fully implemented yet
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43241 --- Comment #10 from Jonathan Wakely redi at gcc dot gnu.org 2011-09-14 15:13:57 UTC --- It's a known issue that std::regex is incomplete, as documented in the libstdc++ manual. If it makes you feel better file a bug, but it isn't going to make any difference to anything. We know it's incomplete, we haven't forgotten, we aren't waiting until someone notices before working on it. As Paolo says, contributions would be far more helpful than a bug report.
[Bug libstdc++/43241] std::tr1::regex is not fully implemented yet
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43241 --- Comment #11 from Jonathan Wakely redi at gcc dot gnu.org 2011-09-14 15:26:23 UTC --- And for std::regex, what would be more useful than just it's not fully implemented yet would be listing what's missing, e.g. I disabled support for anchors because it was buggy, see PR 49870 (which you'll notice noone has closed as INVALID or WONTFIX)
[Bug libstdc++/43241] std::tr1::regex is not fully implemented yet
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43241 --- Comment #12 from Scott A. Colcord sacolcor at provide dot net 2011-09-14 15:36:46 UTC --- As long as std::regex is still on the todo list, that resolves my concern. And I would love to be able to help; if you can give me a couple of extra hours in my day, I'll happily devote them to developing this feature. :-P
[Bug lto/50394] [meta-bug] Issues with building libreoffice with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50394 Markus Trippelsdorf markus at trippelsdorf dot de changed: What|Removed |Added CC||markus at trippelsdorf dot ||de --- Comment #2 from Markus Trippelsdorf markus at trippelsdorf dot de 2011-09-14 16:03:07 UTC --- Just successfully built libreoffice with todays gcc without LTO. I ran into three issues: 1) I use the following patch to include unistd.h in gcc/gthr-posix.h. This gets rid of many trivial errors. diff --git a/gcc/gthr-posix.h b/gcc/gthr-posix.h index b1d499d..3c155d0 100644 --- a/gcc/gthr-posix.h +++ b/gcc/gthr-posix.h @@ -39,6 +39,7 @@ see the files COPYING3 and COPYING.RUNTIME respectively. If not, see #endif #include pthread.h +#include unistd.h #if ((defined(_LIBOBJC) || defined(_LIBOBJC_WEAK)) \ || !defined(_GTHREAD_USE_MUTEX_TIMEDLOCK)) Revision 176335 deleted this include and the authors insist that this is the right thing to do... 2) There is an error in ./oox/inc/oox/helper/refmap.hxx: ../../inc/oox/helper/refmap.hxx:182:86: error: no matching function for call to 'find(oox::RefMapstd::pairshort int, rtl::OUString, oox::xls::DefinedName::key_type)' Fixed by following the note given in the warning that proceeds the error: ../../inc/oox/helper/refmap.hxx:182:86: warning: 'find' was not declared in this scope, and no declarations were found by argument-dependent lookup at the point of instantiation [-fpermissive] ../../inc/oox/helper/refmap.hxx:182:86: note: declarations in dependent base 'std::mapint, boost::shared_ptroox::xls::Connection, std::lessint, std::allocatorstd::pairconst int, boost::shared_ptroox::xls::Connection ' are not found by unqualified lookup ../../inc/oox/helper/refmap.hxx:182:86: note: use 'this-find' instead 3) There were three identical errors in /sc/source/ui/view/dbfunc.cxx (complaining that GetViewData() cannot be called without an object). Fixed by putting a this- before GetViewData() in lines 434, 463 and 473.
[Bug fortran/50392] SIGSEGV in gfc_trans_label_assign
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50392
--- Comment #3 from Tobias Burnus burnus at gcc dot gnu.org 2011-09-14
16:08:16 UTC ---
Patch:
--- a/gcc/fortran/trans-decl.c
+++ b/gcc/fortran/trans-decl.c
@@ -1264,9 +1265,7 @@ gfc_get_symbol_decl (gfc_symbol * sym)
TREE_USED (sym-backend_decl) = 1;
if (sym-attr.assign GFC_DECL_ASSIGN (sym-backend_decl) == 0)
- {
- gfc_add_assign_aux_vars (sym);
- }
+ gfc_add_assign_aux_vars (sym);
if (sym-attr.dimension
DECL_LANG_SPECIFIC (sym-backend_decl)
@@ -1277,6 +1276,10 @@ gfc_get_symbol_decl (gfc_symbol * sym)
return sym-backend_decl;
}
+ if (sym-result == sym sym-attr.assign
+ GFC_DECL_ASSIGN (sym-backend_decl) == 0)
+gfc_add_assign_aux_vars (sym);
+
if (sym-backend_decl)
return sym-backend_decl;
[Bug target/50396] New: SSE division by zero generates incorrect code with optimizations enabled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50396 Bug #: 50396 Summary: SSE division by zero generates incorrect code with optimizations enabled Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: major Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: math...@gaunard.com Created attachment 25273 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25273 divide by zero example The attached C code, written using SSE intrinsics, prints -nan when no optimizations are used (as expected) and 0 otherwise. It seems constant folding of the divps instruction doesn't do the right thing. It works correctly when the first argument is non-zero though (including minus zero).
[Bug c++/50391] [C++0x] ICE on invalid code, pair with incomplete type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50391 --- Comment #2 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org 2011-09-14 16:20:12 UTC --- Author: paolo Date: Wed Sep 14 16:19:59 2011 New Revision: 178857 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=178857 Log: /cp 2011-09-14 Paolo Carlini paolo.carl...@oracle.com PR c++/50391 * pt.c (regenerate_decl_from_template): Don't pass an error_mark_node to build_exception_variant. /testsuite 2011-09-14 Paolo Carlini paolo.carl...@oracle.com PR c++/50391 * g++.dg/cpp0x/noexcept15.C: New. Added: trunk/gcc/testsuite/g++.dg/cpp0x/noexcept15.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog
[Bug c++/50391] [C++0x] ICE on invalid code, pair with incomplete type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50391 --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com 2011-09-14 16:20:53 UTC --- Done.
[Bug c++/50391] [C++0x] ICE on invalid code, pair with incomplete type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50391 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com 2011-09-14 16:21:20 UTC --- .
[Bug fortran/50392] SIGSEGV in gfc_trans_label_assign
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50392
--- Comment #4 from Tobias Burnus burnus at gcc dot gnu.org 2011-09-14
16:40:08 UTC ---
(In reply to comment #3)
Patch:
I have accidentally submitted the patch before testing finished. It does not
work. The problem is that it does create the required declaration - but it does
not get used as one later calls gfc_get_fake_result_decl, which does not
propagate this information on.
That's fixed by applying additionally the following patch, which feels slightly
hackish.
--- a/gcc/fortran/trans-decl.c
+++ b/gcc/fortran/trans-decl.c
@@ -2557,6 +2561,9 @@ gfc_get_fake_result_decl (gfc_symbol * sym, int
parent_flag)
else
current_fake_result_decl = build_tree_list (NULL, decl);
+ if (sym-attr.assign)
+DECL_LANG_SPECIFIC (decl) = DECL_LANG_SPECIFIC (sym-backend_decl);
+
return decl;
}
... maybe by moving the gfc_add_assign_aux_vars to gfc_get_fake_result_decl -
like below?
@@ -2501,6 +2501,10 @@ gfc_get_fake_result_decl (gfc_symbol * sym, int
parent_flag)
if (!sym)
return NULL_TREE;
+ if (sym-attr.assign
+ GFC_DECL_ASSIGN (sym-backend_decl) == 0)
+gfc_add_assign_aux_vars (sym);
+
if (sym-ts.type == BT_CHARACTER)
{
if (sym-ts.u.cl-backend_decl == NULL_TREE)
[Bug fortran/50392] SIGSEGV in gfc_trans_label_assign
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50392 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #5 from kargl at gcc dot gnu.org 2011-09-14 17:10:59 UTC --- (In reply to comment #4) (In reply to comment #3) Patch: I have accidentally submitted the patch before testing finished. It does not work. The problem is that it does create the required declaration - but it does not get used as one later calls gfc_get_fake_result_decl, which does not propagate this information on. That's fixed by applying additionally the following patch, which feels slightly hackish. Just a FYI. The following code works with the current gfortran. function kf() result(j) assign 3 to j 3 continue j = 3 end
[Bug middle-end/50137] [4.7 Regression] ppc64/libstdc++-v3 is miscompiled on powerpc-apple-darwin9 since revision 177691
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50137 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-09-14 18:01:25 UTC --- This pr is fixed with the patch in http://gcc.gnu.org/bugzilla/attachment.cgi?id=25270 (pr50325 comment #5). Marking as a duplicate. *** This bug has been marked as a duplicate of bug 50325 ***
[Bug middle-end/50325] [4.7 Regression] 76 new fails with rev. 177691
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50325 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added CC||dominiq at lps dot ens.fr --- Comment #7 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-09-14 18:01:25 UTC --- *** Bug 50137 has been marked as a duplicate of this bug. ***
[Bug middle-end/50325] [4.7 Regression] 76 new fails with rev. 177691
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50325 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-09-14 Ever Confirmed|0 |1 --- Comment #8 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-09-14 18:03:03 UTC --- With the patch in comment #5 Created attachment 25270 [details] Experimental fix and after rebuilding libstdc++-v3 for both -m32 and -m64, the tests with -m64 gives ... Running target unix/-m64 ... === libstdc++ Summary === # of expected passes7234 # of unexpected failures2 # of expected failures46 # of unsupported tests732 So the patch fixes pr50137. I'll start a clean bootstrap and a full regtest tonight (allow for ~36h for the cycle).
[Bug other/49533] [4.7 regression] Revision 174989 (ipa-inline-transform.c) regressions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49533 Dmitry Gorbachev d.g.gorbachev at gmail dot com changed: What|Removed |Added CC||d.g.gorbachev at gmail dot ||com --- Comment #16 from Dmitry Gorbachev d.g.gorbachev at gmail dot com 2011-09-14 18:28:20 UTC --- *** Bug 50226 has been marked as a duplicate of this bug. ***
[Bug c++/50226] Wrong code with -O -fno-implicit-templates
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50226 Dmitry Gorbachev d.g.gorbachev at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #1 from Dmitry Gorbachev d.g.gorbachev at gmail dot com 2011-09-14 18:28:20 UTC --- Fixed by r178809. *** This bug has been marked as a duplicate of bug 49533 ***
[Bug target/49826] [4.7 Regression] Symbols are not decorated with attribute stdcall and -mrtd
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49826 --- Comment #1 from Dmitry Gorbachev d.g.gorbachev at gmail dot com 2011-09-14 19:35:41 UTC --- Created attachment 25274 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25274 patch
[Bug fortran/50378] MALLOC_CHECK_ glibc detects free() invalid pointer in compiler
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50378 --- Comment #10 from Vittorio Zecca zeccav at gmail dot com 2011-09-14 20:01:17 UTC --- gfortran 4.7.0 has been compiled with the old mpfr 2.4.2, I just downloaded it, this one will probably work. Anyway gfortran 4.7.0 does not give free() errors.
[Bug fortran/50393] free() invalid pointer in mio_expr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50393 --- Comment #3 from Vittorio Zecca zeccav at gmail dot com 2011-09-14 20:03:44 UTC --- It seems to work now, no free() error messages. Maybe you can close the issue.
[Bug fortran/50378] MALLOC_CHECK_ glibc detects free() invalid pointer in compiler
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50378 kargl at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #11 from kargl at gcc dot gnu.org 2011-09-14 20:13:17 UTC --- (In reply to comment #10) gfortran 4.7.0 has been compiled with the old mpfr 2.4.2, I just downloaded it, this one will probably work. Anyway gfortran 4.7.0 does not give free() errors. Thanks for the bug report and confirming that the issue is fixed.
[Bug fortran/50393] free() invalid pointer in mio_expr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50393 kargl at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||kargl at gcc dot gnu.org Resolution||WORKSFORME --- Comment #4 from kargl at gcc dot gnu.org 2011-09-14 20:16:06 UTC --- (In reply to comment #3) It seems to work now, no free() error messages. Maybe you can close the issue. Again, thanks for the bug report. This may also have been fixed by Mikael patch. I'm closing this with a WORKSFORME tag. FIXED might also apply.
[Bug tree-optimization/49452] [4.7 regression] comp-goto-2.c regresses in testing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49452 --- Comment #22 from Ramana Radhakrishnan ramana.r at gmail dot com 2011-09-14 20:26:43 UTC --- On 14 Sep 2011, at 07:48, ebotcazou at gcc dot gnu.org gcc-bugzi...@gcc.gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49452 --- Comment #21 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-09-14 06:48:01 UTC --- All callee saved registers should never changed after function call. Here fp has been changed is not because it is after a function call, it is because it is after the target of non local goto. I'm not familiar with the implementation of non local goto, but I guess there is some convention/protocol defines which registers may be changed after the target of a non local goto. That's not the problem. The problem is that the blockage isn't honored. By ? -- Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You reported the bug.
[Bug c++/50388] Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50388 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Known to work||4.6.1, 4.7.0 Resolution||WORKSFORME --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com 2011-09-14 20:55:12 UTC --- Indeed, this does *not* happen in mainline and 4_6-branch. And it's an ICE on *invalid*: at this point, realistically, will not be fixed in 4_5-branch.
[Bug c++/50303] [C++0x] Segfault with variadic template template parameters
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50303 --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2011-09-14 20:59:20 UTC --- Can you try reducing your testcase? 563 KB is definitely unmanageable.
[Bug c++/50276] [C++0x] Wrong used uninitialized in this function warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50276 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-09-14 CC||jason at gcc dot gnu.org Summary|Wrong used uninitialized |[C++0x] Wrong used |in this function warning |uninitialized in this |[C++0x] |function warning Ever Confirmed|0 |1 Severity|minor |normal --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com 2011-09-14 21:03:48 UTC --- Note: -Wuninitialized required.
[Bug c++/50344] friend declaration confused by const qualifier
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50344 --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com 2011-09-14 21:11:02 UTC --- So, I guess we only need confirmation that your analysis is correct. Indeed, I can confirm that the patch, only one line thus not requiring a Copyright assignment, works for the testcase (however, I didn't fully regression test it yet). Jason, can you have a look? PS: Current Comeau accepts the snippet.
[Bug c++/50344] friend declaration confused by const qualifier
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50344 --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com 2011-09-14 21:34:35 UTC --- Passes the testsuite.
[Bug c++/50303] [C++0x] Segfault with variadic template template parameters
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50303 Andrea Arteaga andyspiros at gmail dot com changed: What|Removed |Added Attachment #25203|0 |1 is obsolete|| --- Comment #2 from Andrea Arteaga andyspiros at gmail dot com 2011-09-14 22:46:19 UTC --- Created attachment 25275 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25275 Not-preprocessed source As requested, I attach a minimal source code with some comments. There are no external dependencies, just iostream gets #included. The compilation result is the same as already stated (segmentation fault during compilation).
[Bug c++/50303] [C++0x] Segfault with variadic template template parameters
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50303 --- Comment #3 from Andrea Arteaga andyspiros at gmail dot com 2011-09-14 22:47:56 UTC --- I recently blogged about this issue: http://wp.me/pzWEm-9N.
[Bug c++/50303] [C++0x] Segfault with variadic template template parameters
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50303
Paolo Carlini paolo.carlini at oracle dot com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2011-09-14
CC||jason at gcc dot gnu.org
Ever Confirmed|0 |1
--- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com 2011-09-14
23:11:11 UTC ---
Ah, ok, the below seems enough:
templatetypename Interface
struct A1 {
};
templatetemplateclass I class... Actions
void g2() {
g2Actions...();
}
int main()
{
g2A1();
}
[Bug middle-end/50397] New: openssl crash due to incorrect codegen when using LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50397
Bug #: 50397
Summary: openssl crash due to incorrect codegen when using LTO
Classification: Unclassified
Product: gcc
Version: 4.6.2
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: m...@use.net
When adding -flto and compiling openssl-1.0.0d with gcc-4.6.real (Ubuntu/Linaro
4.6.1-9ubuntu2) that comes with Ubuntu 11.10, the testsuite fails with a
segfault during the bignumber tests.
To reproduce:
1. untar openssl-1.0.0d
2. make this change in the Configure file on the debian-amd64 line:
debian-amd64, gcc:-m64 -DL_ENDIAN -DTERMIO -O2 -flto -floop-block
-floop-flatten -floop-interchange -floop-strip-mine -Wa,--noexecstack -g -Wall
-DMD32_REG_T=int::-D_REENTRANT::-Wl,-flto=2 -ldl
-Wl,-Bsymbolic-functions:SIXTY_FOUR_BIT_LONG RC4_CHUNK DES_INT
DES_UNROLL:${x86_64_asm}:elf:dlfcn:linux-shared:-fPIC:-m64:.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR):::,
3. make, which will run the tests and fail.
4. for extra grins, run the specific suite under valgrind:
matt@matt-desktop:~/openssl-1.0.0d/test$ valgrind -q --trace-children=yes
../util/shlib_wrap.sh ./bntest
[...]
==12136== Process terminating with default action of signal 8 (SIGFPE)
==12136== Integer divide by zero at address 0x40359EA94
==12136==at 0x433C4D: BN_div (bn_div.c:342)
==12136==by 0x403B86: main (bntest.c:1951)
Floating point exception (core dumped)
PS: I filed this as 4.6.2, given the number of patches that Linaro has applied
to this 4.6.1 base version. If that's wrong, let me know.
I tried testing it on trunk, but that gets an ICE during compile (filing a
separate bug).
[Bug middle-end/50397] openssl crash due to incorrect codegen when using LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50397 --- Comment #1 from Matt Hargett matt at use dot net 2011-09-15 00:37:43 UTC --- BTW, worth noting that this also happens with just -O1 as well.
[Bug middle-end/50398] New: ICE when compiling openssl-1.0.0d with graphite optimizations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50398 Bug #: 50398 Summary: ICE when compiling openssl-1.0.0d with graphite optimizations Classification: Unclassified Product: gcc Version: 4.6.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: m...@use.net Created attachment 25276 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25276 pre-processed source of the file that triggers the ICE During compile of openssl-1.0.0d using trunk r177733. matt@matt-desktop:~/openssl-1.0.0d/engines/ccgost$ /usr/lib/gcc-snapshot/bin/gcc -I../../include -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -m64 -DL_ENDIAN -DTERMIO -O2 -floop-flatten -Wa,--noexecstack -g -Wall -DMD32_REG_T=int -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DWHIRLPOOL_ASM -c gosthash.c gosthash.c: In function 'hash_step': gosthash.c:87:12: internal compiler error: in psct_dynamic_dim, at graphite-poly.h:659 The crash goes away with -O1 -floop-flatten, or if I remove -floop-flatten. valgrind doesn't provide any output related to this issue. Pre-processed source attached.
[Bug c++/50399] New: [c++11] Lookup error w/ enums
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50399
Bug #: 50399
Summary: [c++11] Lookup error w/ enums
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: blelb...@cct.lsu.edu
$ cat cxx11_enum_lookup_bug.cpp
namespace A {
namespace B {
void F() { }
}
namespace C {
enum B { };
void G() { B::F(); }
}
}
$ /usr/lib/gcc-snapshot/bin/g++ --version
g++ (Debian 20110816-1) 4.7.0 20110816 (experimental) [trunk revision 177785]
Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ /usr/lib/gcc-snapshot/bin/g++ cxx11_enum_lookup_bug.cpp -c
$ /usr/lib/gcc-snapshot/bin/g++ cxx11_enum_lookup_bug.cpp -c -std=c++0x
cxx11_enum_lookup_bug.cpp: In function 'void A::C::G()':
cxx11_enum_lookup_bug.cpp:13:12: error: 'F' is not a member of 'A::C::B'
$ g++-4.6 --version
g++-4.6 (Debian 4.6.1-8) 4.6.1
Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ g++-4.6 cxx11_enum_lookup_bug.cpp -c
$ g++-4.6 cxx11_enum_lookup_bug.cpp -c -std=c++0x
cxx11_enum_lookup_bug.cpp: In function ‘void A::C::G()’:
cxx11_enum_lookup_bug.cpp:13:12: error: ‘F’ is not a member of ‘A::C::B’
$ g++-4.5 --version
g++-4.5 (Debian 4.5.3-8) 4.5.3
Copyright (C) 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ g++-4.5 cxx11_enum_lookup_bug.cpp -c
$ g++-4.5 cxx11_enum_lookup_bug.cpp -c -std=c++0x
cxx11_enum_lookup_bug.cpp: In function ‘void A::C::G()’:
cxx11_enum_lookup_bug.cpp:13:12: error: ‘F’ is not a member of ‘A::C::B’
$ g++-4.4 --version
g++-4.4 (Debian 4.4.6-8) 4.4.6
Copyright (C) 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ g++-4.4 cxx11_enum_lookup_bug.cpp -c
$ g++-4.4 cxx11_enum_lookup_bug.cpp -c -std=c++0x
cxx11_enum_lookup_bug.cpp: In function ‘void A::C::G()’:
cxx11_enum_lookup_bug.cpp:13: error: ‘F’ is not a member of ‘A::C::B’
