[Bug fortran/37159] RANDOM_SEED: PUT= check array size at compile time
--- Comment #4 from tkoenig at gcc dot gnu dot org 2008-11-01 10:25 --- Subject: Bug 37159 Author: tkoenig Date: Sat Nov 1 10:24:15 2008 New Revision: 141511 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141511 Log: 2008-11-01 Dennis Wassel [EMAIL PROTECTED] PR fortran/37159 * fortran/check.c (gfc_check_random_seed): Check PUT size at compile time. 2008-11-01 Dennis Wassel [EMAIL PROTECTED] PR fortran/37159 * intrinsics/random.c: Added comment to adapt check.c, should kiss_size change. Few cosmetic changes to existing comments. 2008-11-01 Dennis Wassel [EMAIL PROTECTED] PR fortran/37159 * gfortran.dg/random_seed_1.f90: New testcase. Added: trunk/gcc/testsuite/gfortran.dg/random_seed_1.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/check.c trunk/gcc/testsuite/ChangeLog trunk/libgfortran/ChangeLog trunk/libgfortran/intrinsics/random.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37159
[Bug fortran/37159] RANDOM_SEED: PUT= check array size at compile time
--- Comment #5 from tkoenig at gcc dot gnu dot org 2008-11-01 10:29 --- Committed patch. Not closing yet, as the GET array could also be checked, see http://gcc.gnu.org/ml/fortran/2008-10/msg00281.html . Thomas -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37159
[Bug c++/37984] New: unable to access virtual functions from derived class passed as a refference
Hi, this is my first bug report so im sorry if i stuff this up. I have a simple
c++ program which can reproduce this. im not sure if this is expected behavior,
but i cant find anything solid saying this is expected behavior and it seems
strange to me.
#include stdio.h
class A
{
public:
virtual int funk () { return 1; }
};
class B : public A
{
public:
virtual int funk () { return 2; }
};
void func (A a)
{
printf (%d\n, a.funk ());
}
void func2 (A a)
{
func (a);
}
int main ()
{
A a;
B b;
func (a);
func (b);
func2 (A());
func2 (B());
}
the output is
1
2
1
1
as you can see B's virtual function was not called
compiled with
g++ derived.cpp -save-temps -O0 -o derived -Wall
and im sorry but i cant work out how to attach a file, so i cant add my .ii
file. Sorry, i hope this is enough.
--
Summary: unable to access virtual functions from derived class
passed as a refference
Product: gcc
Version: 4.2.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: carlchatfield at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37984
[Bug c++/37984] unable to access virtual functions from derived class passed as a refference
--- Comment #1 from carlchatfield at gmail dot com 2008-11-01 10:41 --- my apologies, this is expected behavior -- carlchatfield at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37984
[Bug c/37985] New: unsigned char shift lacks statement with no effect warning
I would have expected a warning statement with no effect
for this code:
$ cat tmp.c
unsigned char foo(unsigned char a)
{
a 2;
return a;
}
$ gcc -S -Wall -O3 -Wextra tmp.c
$
--
Summary: unsigned char shift lacks statement with no effect
warning
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: enhancement
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tkoenig at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37985
[Bug debug/37982] Extraneous DW_TAG_variable tag
--- Comment #4 from dodji at gcc dot gnu dot org 2008-11-01 11:03 --- I could reproduce this on 4.3 and trunk (4.4). Actually I think there are several problems here. First, I think the DIE representing the defining declaration of A::elsewhere in class2.c should have a DW_AT_specification pointing back to the DIE representing the declaration or A::elsewhere in class.h. That can be deduced from the dwarf2 spec, section [4.1 Data Object Entries], point 5, pdf page 35, spec page 33 that reads: 5. If the variable entry represents the defining declaration for a C++ static data member of a structure, class or union, the entry has a DW_AT_specification attribute, whose value is a reference to the debugging information entry representing the declaration of this data member. The referenced entry will be a child of some class, structure or union type entry.. Second, I think the DIE of the defining declaration of A::elsewhere in class2 should have a DW_AT_const_value attribute whose value should be the constant 211. This can be deduced from the dwarf2 spec, section [4.1 Data Object Entries], point 9, pdf page 35, spec page 33 that reads: 9. An entry describing a variable whose value is constant and not represented by an object in the address space of the program, or an entry describing a named constant, does not have a location attribute. Such entries have a DW_AT_const_value attribute, whose value may be a string or any of the constant data or data block forms, as appropriate for the representation of the variables value. The value of this attribute is the actual constant value of the variable, represented as it would be on the target architecture. And third, as you pointed out, the DIE of the declaration of A::elsewhere should not appear twice in the class.c compilation unit. It should only appear once, in the scope of the A class. -- dodji at gcc dot gnu dot org changed: What|Removed |Added CC||dodji at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-11-01 11:03:52 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37982
[Bug middle-end/37843] [4.4 Regression] unaligned stack in main due to tail call optimization
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-11-01 11:36 --- Confirmed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC target triplet|i686-* |i?86-*-* Known to fail||4.4.0 Known to work||4.3.2 Priority|P3 |P1 Last reconfirmed|-00-00 00:00:00 |2008-11-01 11:36:26 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37843
[Bug target/37942] [4.4 Regression] FAIL: gcc.c-torture/compile/930618-1.c
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P4 Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37942
[Bug target/37939] [4.2/4.3/4.4 Regression] CRIS port: no addi insn
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P5 Target Milestone|--- |4.2.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37939
[Bug java/37900] [4.4 Regression] StringBuffer_1 failures
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added GCC target triplet||ia64-linux-gnu Priority|P3 |P4 Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37900
[Bug target/37812] [4.4 Regression] Invalid mnemonic 'lvlx'
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 Target Milestone|--- |4.4.0 Version|unknown |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37812
[Bug target/35574] [4.4 Regression] unrecognizable insn generated for vector move
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 Summary|[4.4 regression]|[4.4 Regression] |unrecognizable insn |unrecognizable insn |generated for vector move |generated for vector move Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35574
[Bug bootstrap/33503] [4.3/4.4 Regression] problems with libtool wrapper scripts on mingw32
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-11-01 11:43 --- Hum, this is a host problem - and we do not have a list of primary or secondary host platforms ... extrapolating from the secondary mingw32 target platform I set this to P2. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Keywords||build Priority|P3 |P2 Target Milestone|--- |4.3.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33503
[Bug libstdc++/37986] New: std::tr1::variate_generator does not conform to TR1.
I am assuming that section 5.1.3 of [1] is sufficiently close to the final TR1.
In paragraph 2, the draft allows U, U, U* as the first template parameter of
variate_generator. However, the following minimal program:
--
#include tr1/random
int main(int argc, char **argv) {
std::tr1::mt19937 mt;
std::tr1::uniform_realdouble dist;
std::tr1::variate_generator
std::tr1::mt19937,
std::tr1::uniform_realdouble
g(mt, dist);
std::tr1::variate_generator
std::tr1::mt19937,
std::tr1::uniform_realdouble
g(mt, dist);
std::tr1::variate_generator
std::tr1::mt19937*,
std::tr1::uniform_realdouble
g(mt, dist);
return 0;
}
--
Yields these error message:
--
/opt/local/include/gcc43/c++/tr1_impl/random: In instantiation of
'std::tr1::__detail::_Adaptorstd::tr1::mt19937,
std::tr1::uniform_realdouble ':
/opt/local/include/gcc43/c++/tr1_impl/random:245: instantiated from
'std::tr1::variate_generatorstd::tr1::mt19937, std::tr1::uniform_realdouble
'
tr1_43.cpp:14: instantiated from here
/opt/local/include/gcc43/c++/tr1_impl/random:82: error: 'std::tr1::mt19937' is
not a class, struct, or union type
/opt/local/include/gcc43/c++/tr1_impl/random: In instantiation of
'std::tr1::__detail::_Adaptorstd::tr1::mt19937*,
std::tr1::uniform_realdouble ':
/opt/local/include/gcc43/c++/tr1_impl/random:245: instantiated from
'std::tr1::variate_generatorstd::tr1::mt19937*, std::tr1::uniform_realdouble
'
tr1_43.cpp:18: instantiated from here
/opt/local/include/gcc43/c++/tr1_impl/random:82: error: 'std::tr1::mt19937*' is
not a class, struct, or union type
--
I do not know if this is still the case with gcc 4.4.
[1] www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1836.pdf
--
Summary: std::tr1::variate_generator does not conform to TR1.
Product: gcc
Version: 4.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: holtgrewe at ira dot uka dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37986
[Bug middle-end/37858] [4.3/4.4 Regression] ICE when -fdump-ipa-all -dv is used
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 Target Milestone|--- |4.3.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37858
[Bug tree-optimization/14703] Inadequate optimization of inline templated functions, infinite loop in ipa-reference and memory hog
--- Comment #16 from rguenth at gcc dot gnu dot org 2008-11-01 11:51 --- How is this a regression? In fact this seems to be fixed on the trunk and instead the 4.3 branch and earlier releases suffer from memory/compile-time explosion during inlining. Marked as fixed. If the problem from comment #12 still occurs it should go to a separate PR. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Priority|P2 |P3 Resolution||FIXED Summary|[4.4 regression] Inadequate |Inadequate optimization of |optimization of inline |inline templated functions, |templated functions,|infinite loop in ipa- |infinite loop in ipa- |reference and memory hog |reference and memory hog| Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14703
[Bug fortran/37821] [4.4 Regression] gfortran is ignoring #includes with the syntax file.h
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P4 Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37821
[Bug rtl-optimization/32283] [4.3/4.4 regression] Missed induction variable optimization
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32283
[Bug libfortran/37839] st_parameter_dt has unwanted padding, is out of sync with compiler
--- Comment #10 from jvdelisle at gcc dot gnu dot org 2008-11-01 12:17 --- Steve, if I knew how to fix this, I would have done so by now. I plan to remove st43 and st44 in 4.5, this was merely a bandaid for the ABI breakage. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-11-01 12:17:18 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37839
[Bug libstdc++/37958] num_get::do_get(bool) sets eofbit flag incorrectly when boolalpha == true
--- Comment #9 from tsyvarev at ispras dot ru 2008-11-01 12:21 --- Patch seems doesn't resolve problem entirely. The thing is that, besides of constraints on setting eofbit flag, the standard claims, that comparision (in == end) should be perfomed only when it is needed for identify a match(22.2.2.1.2, p15): Successive characters in the range [in,end) (see 23.1.1) are obtained and matched against corresponding positions in the target sequences ONLY as necessary to identify a unique match. The input iterator in is compared to end ONLY when necessary to obtain a character. If also take into account constraints on setting eofbit flag: if, when seeking another character to match, it is found that (in == end) and if the reason for the failure was that (in == end)., one may conclude, that eofbit flag should be set IF and ONLY IF comparision (in == end) was performed and it returned true. Declaration bool __testeof = __beg == __end; in the patched code means, that implementation always compares (in == end) at start, even when input and target sequences are empty (). In that case, err will be set to failbit, which conforms to the example in the standard: For empty targets (), any input sequence yields err == str.failbit But input sequence should not be read at all in this case, so comparision (in == end) should not be performed! There are also other cases, when implementation performs unnecessary comparision (in == end). -- tsyvarev at ispras dot ru changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37958
[Bug fortran/34136] Add entry point and symbol for linker
--- Comment #17 from jvdelisle at gcc dot gnu dot org 2008-11-01 12:21 --- Jack, did this problem go away on Darwin? -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added CC||howarth at nitro dot med dot ||uc dot edu Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-11-01 12:21:11 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34136
[Bug rtl-optimization/37889] [4.3/4.4 Regression] SEGV, conditional execution proactively executed the false arm.
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37889
[Bug fortran/34136] Add entry point and symbol for linker
--- Comment #18 from dominiq at lps dot ens dot fr 2008-11-01 12:32 --- I have run the tests in comment #1 and main.bad main.init still fail on i686-apple-darwin9. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34136
[Bug libstdc++/37958] num_get::do_get(bool) sets eofbit flag incorrectly when boolalpha == true
--- Comment #10 from paolo dot carlini at oracle dot com 2008-11-01 12:36 --- (In reply to comment #9) Declaration bool __testeof = __beg == __end; in the patched code means, that implementation always compares (in == end) at start, even when input and target sequences are empty (). In that case, err will be set to failbit, which conforms to the example in the standard: For empty targets (), any input sequence yields err == str.failbit But input sequence should not be read at all in this case, so comparision (in == end) should not be performed! Ok, I'll special case this, but please let's stop the nitpicking here. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37958
[Bug rtl-optimization/37769] internal compiler error: in reg_overlap_mentioned_for_reload_p, at reload.c:6525
--- Comment #6 from kkojima at gcc dot gnu dot org 2008-11-01 12:40 --- Subject: Bug 37769 Author: kkojima Date: Sat Nov 1 12:39:17 2008 New Revision: 141513 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141513 Log: Backport from mainline: 2008-10-24 Kaz Kojima [EMAIL PROTECTED] PR rtl-optimization/37769 * regmove.c (optimize_reg_copy_2): Update REG_INC note if needed. Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/regmove.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37769
[Bug rtl-optimization/37769] [4.3/4.4 Regression] internal compiler error: in reg_overlap_mentioned_for_reload_p, at reload.c:6525
--- Comment #7 from kkojima at gcc dot gnu dot org 2008-11-01 12:45 --- Fixed. -- kkojima at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Summary|internal compiler error: in |[4.3/4.4 Regression] |reg_overlap_mentioned_for_re|internal compiler error: in |load_p, at reload.c:6525|reg_overlap_mentioned_for_re ||load_p, at reload.c:6525 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37769
[Bug fortran/35952] Segmentation fault with character strings only when compiling with -funroll-loops and -O3
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2008-11-01 12:47 --- Confirmed. On trunk R 141238. I can't get a very usable backtrace on this. Maybe valgind will give us a hint on Linux box. This could also be a Cygwin.dll issue. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-11-01 12:47:05 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35952
[Bug middle-end/37976] [4.4 Regression] ICE in insert_into_preds_of_block
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-11-01 12:47 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37976
[Bug c/37985] unsigned char shift lacks statement with no effect warning
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-11-01 12:48 --- Confirmed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-11-01 12:48:50 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37985
[Bug middle-end/37976] [4.4 Regression] ICE in insert_into_preds_of_block
--- Comment #6 from rguenth at gcc dot gnu dot org 2008-11-01 12:49 --- Subject: Bug 37976 Author: rguenth Date: Sat Nov 1 12:47:38 2008 New Revision: 141514 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141514 Log: 2008-11-01 Richard Guenther [EMAIL PROTECTED] PR middle-end/37976 * builtins.c (fold_builtin_strspn): Return a size_t. (fold_builtin_strcspn): Likewise. * gcc.c-torture/compile/pr37976.c: New testcase. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr37976.c Modified: trunk/gcc/ChangeLog trunk/gcc/builtins.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37976
[Bug fortran/35754] -std=f95: Reject 1P2E12.4 w/o a comma after the P
-- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jvdelisle at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-11-01 12:50:08 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35754
[Bug fortran/36205] Hangup with array_constructor_24.f90 at -O3
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2008-11-01 12:57 --- Confirmed on recent trunk. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-11-01 12:57:07 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36205
[Bug fortran/36463] [4.4 Regression] ICE in expand_expr_real_1, at expr.c:7264 with rev.136554
--- Comment #10 from janus at gcc dot gnu dot org 2008-11-01 13:25 --- Subject: Bug 36463 Author: janus Date: Sat Nov 1 13:24:03 2008 New Revision: 141515 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141515 Log: 2008-11-01 Janus Weil [EMAIL PROTECTED] PR fortran/36322 PR fortran/36463 * gfortran.h: New function gfc_expr_replace_symbols. * decl.c (match_procedure_decl): Increase reference count for interface. * expr.c: New functions replace_symbol and gfc_expr_replace_symbols. * resolve.c (resolve_symbol): Correctly copy array spec and char len of PROCEDURE declarations from their interface. * symbol.c (gfc_get_default_type): Enhanced error message. (copy_formal_args): Call copy_formal_args recursively for arguments. * trans-expr.c (gfc_conv_function_call): Bugfix. 2008-11-01 Janus Weil [EMAIL PROTECTED] PR fortran/36322 PR fortran/36463 * gfortran.dg/proc_decl_17.f90: New. * gfortran.dg/proc_decl_18.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/proc_decl_17.f90 trunk/gcc/testsuite/gfortran.dg/proc_decl_18.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/fortran/expr.c trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/resolve.c trunk/gcc/fortran/symbol.c trunk/gcc/fortran/trans-expr.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36463
[Bug fortran/36322] ICE with PROCEDURE using a complicated interface
--- Comment #9 from janus at gcc dot gnu dot org 2008-11-01 13:25 --- Subject: Bug 36322 Author: janus Date: Sat Nov 1 13:24:03 2008 New Revision: 141515 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141515 Log: 2008-11-01 Janus Weil [EMAIL PROTECTED] PR fortran/36322 PR fortran/36463 * gfortran.h: New function gfc_expr_replace_symbols. * decl.c (match_procedure_decl): Increase reference count for interface. * expr.c: New functions replace_symbol and gfc_expr_replace_symbols. * resolve.c (resolve_symbol): Correctly copy array spec and char len of PROCEDURE declarations from their interface. * symbol.c (gfc_get_default_type): Enhanced error message. (copy_formal_args): Call copy_formal_args recursively for arguments. * trans-expr.c (gfc_conv_function_call): Bugfix. 2008-11-01 Janus Weil [EMAIL PROTECTED] PR fortran/36322 PR fortran/36463 * gfortran.dg/proc_decl_17.f90: New. * gfortran.dg/proc_decl_18.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/proc_decl_17.f90 trunk/gcc/testsuite/gfortran.dg/proc_decl_18.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/fortran/expr.c trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/resolve.c trunk/gcc/fortran/symbol.c trunk/gcc/fortran/trans-expr.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36322
[Bug fortran/35681] wrong result for vector subscripted array expression in MVBITS
--- Comment #15 from domob at gcc dot gnu dot org 2008-11-01 13:27 --- Subject: Bug 35681 Author: domob Date: Sat Nov 1 13:26:19 2008 New Revision: 141516 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141516 Log: 2008-11-01 Daniel Kraft [EMAIL PROTECTED] PR fortran/35681 * gfortran.h (struct gfc_code): New field `resolved_isym'. * trans.h (gfc_build_memcpy_call): Made public. * trans-array.h (gfc_trans_create_temp_array): New argument `initial'. * intrinsic.c (gfc_intrinsic_sub_interface): Set resolved_isym. * iresolve.c (create_formal_for_intents): New helper method. (gfc_resolve_mvbits): Put dummy formal arglist on resolved_sym. * resolve.c (resolve_call): Initialize resolved_isym to NULL. * trans-array.c (gfc_trans_allocate_array_storage): New argument `initial' to allow initializing the allocated storage to some initial value copied from another array. (gfc_trans_create_temp_array): Allow initialization of the temporary with a copy of some other array by using the new extension. (gfc_trans_array_constructor): Pass NULL_TREE for initial argument. (gfc_conv_loop_setup): Ditto. * trans-intrinsic.c (gfc_conv_intrinsic_array_transfer): Ditto. * trans-expr.c (gfc_conv_function_call): Ditto. (gfc_build_memcpy_call): Made public. * trans-stmt.c (gfc_conv_elemental_dependencies): Initialize created temporary for INTENT(INOUT) arguments to the value of the mirrored array and clean up the temporary as very last intructions in the created block. * trans.c (gfc_trans_code): For EXEC_CALL, see if we have a MVBITS call and enable elemental dependency checking if we have. 2008-11-01 Daniel Kraft [EMAIL PROTECTED] PR fortran/35681 * gfortran.dg/mvbits_4.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/mvbits_4.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/intrinsic.c trunk/gcc/fortran/iresolve.c trunk/gcc/fortran/resolve.c trunk/gcc/fortran/trans-array.c trunk/gcc/fortran/trans-array.h trunk/gcc/fortran/trans-expr.c trunk/gcc/fortran/trans-intrinsic.c trunk/gcc/fortran/trans-stmt.c trunk/gcc/fortran/trans.c trunk/gcc/fortran/trans.h trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35681
[Bug fortran/36322] ICE with PROCEDURE using a complicated interface
--- Comment #10 from janus at gcc dot gnu dot org 2008-11-01 13:33 --- Rev. 141515 does not fix the complete test case on c.l.f., but most of the troubles it made, including comment #8. Still I'm closing this PR, because PR36463 is about the same c.l.f. code, and will be kept open to track the remaining issues. -- janus at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36322
[Bug fortran/35681] wrong result for vector subscripted array expression in MVBITS
--- Comment #16 from domob at gcc dot gnu dot org 2008-11-01 13:37 --- This commit implements correct dependency and temporary handling if the arguments to MVBITS are *not* expressions; thus it does not yet fix the original test, although it fixes it if the parentheses are taken off the first argument. This other problem with ELEMENTAL scalarization will be part 2... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35681
[Bug fortran/36463] gfc_get_default_type(): Bad symbol
--- Comment #11 from janus at gcc dot gnu dot org 2008-11-01 13:52 --- r141515 eliminates the ICE in comment #2 and the c.l.f. example, so I guess this can not be called a regression any more. Removing the [4.4 Regression] tag. -- janus at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.4 Regression] ICE in |gfc_get_default_type(): Bad |expand_expr_real_1, at |symbol |expr.c:7264 with rev.136554 | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36463
[Bug testsuite/30176] gcc.dg/tree-prof/stringop-1.c fails
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-11-01 13:54 --- This doesn't fail anymore. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30176
[Bug c++/37847] Invalid tree sharing with CHANGE_DYNAMIC_TYPE_EXPR
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-11-01 14:00 --- Invalid. TARGET_EXPRs behave like SAVE_EXPRs. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37847
[Bug fortran/36463] gfc_get_default_type(): Bad symbol
--- Comment #12 from janus at gcc dot gnu dot org 2008-11-01 14:06 ---
To clarify the situation regarding the code on c.l.f.: The link in comment #0
points to a thread which contains two example programs. One is called fptr
and uses Cray pointers, the other one is called gptr and uses procedure
pointers. Both contain minor formal errors.
The gptr example can not be compiled with gfortran at this point, since it
uses procedure pointers as function results, which are not yet supported (see
PR36704).
The corrected version of the fptr example looks like this:
module funcs
implicit none
! Interface block for function program fptr will invoke
! to get the C_FUNPTR
interface
function get_proc(mess) bind(C,name='BlAh')
use ISO_C_BINDING
implicit none
character(kind=C_CHAR) mess(*)
type(C_FUNPTR) get_proc
end function get_proc
end interface
end module funcs
module other_fun
use ISO_C_BINDING
implicit none
private
! Message to be returned by procedure pointed to
! by the C_FUNPTR
character, allocatable, save :: my_message(:)
! Interface block for the procedure pointed to
! by the C_FUNPTR
public abstract_fun
abstract interface
function abstract_fun(x)
use ISO_C_BINDING
import my_message
implicit none
integer(C_INT) x(:)
character(size(my_message),C_CHAR) abstract_fun(size(x))
end function abstract_fun
end interface
contains
! Procedure to store the message and get the C_FUNPTR
function gp(message) bind(C,name='BlAh')
character(kind=C_CHAR) message(*)
type(C_FUNPTR) gp
integer(C_INT64_T) i
i = 1
do while(message(i) /= C_NULL_CHAR)
i = i+1
end do
my_message = message(int(1,kind(i)):i-1)
gp = get_funloc(make_mess,aux)
end function gp
! Intermediate procedure to pass the function and get
! back the C_FUNPTR
function get_funloc(x,y)
procedure(abstract_fun) :: x
type(C_FUNPTR) y
external y
type(C_FUNPTR) get_funloc
get_funloc = y(x)
end function get_funloc
! Procedure to convert the function to C_FUNPTR
function aux(x)
interface
subroutine x() bind(C)
end subroutine x
end interface
type(C_FUNPTR) aux
aux = C_FUNLOC(x)
end function aux
! Procedure pointed to by the C_FUNPTR
function make_mess(x)
integer(C_INT) x(:)
character(size(my_message),C_CHAR) make_mess(size(x))
make_mess = transfer(my_message,make_mess(1))
end function make_mess
end module other_fun
program fptr
use funcs
use other_fun
use ISO_C_BINDING
implicit none
procedure(abstract_fun) :: fun
pointer(p,fun)
type(C_FUNPTR) fp
fp = get_proc('Hello, world'//achar(0))
p = transfer(fp,p)
write(*,'(a)') fun([1,2,3])
end program fptr
Compiling this via gfortran-4.4 -fcray-pointer fptr.f90 yields the error:
end program fptr
1
Internal Error at (1):
gfc_get_default_type(): Bad symbol '@3'
With 4.3 I get an ICE on this, so it is no regression, though I haven't tried
4.2 or earlier.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36463
[Bug tree-optimization/37837] missed PRE
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-11-01 14:14 --- Seems to work now. DOM1 threads the jump, if disabled PRE correctly detects the partial redundant calls and optimizes them. But we miss a jump threading pass after PRE which makes us end up with bb 2: *neig = 3; if (ABS_EXPR cn 1.0e+0) goto bb 9; else goto bb 3; bb 9: prephitmp.33 = 1.5e+0; prephitmp.31 = 4.97002397833512077340856194496154785e-1; prephitmp.29 = -1.0e+0; prephitmp.17 = 5.00111022302462515654042363166809082e-1; goto bb 4; ... bb 4: if (prephitmp.33 1.8180305391403130954586231382564e-5) goto bb 7; else goto bb 5; bb 5: if (ABS_EXPR prephitmp.17 - prephitmp.31 1.8180305391403130954586231382564e-5) goto bb 7; else goto bb 6; bb 6: if (ABS_EXPR prephitmp.29 - prephitmp.31 1.8180305391403130954586231382564e-5) goto bb 7; else goto bb 8; bb 7: *neig = 2; note that VRP doesn't track floating-point ranges and thus does not thread jumps here. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37837
[Bug fortran/36463] [4.4 regression] gfc_get_default_type(): Bad symbol
--- Comment #13 from janus at gcc dot gnu dot org 2008-11-01 14:20 --- Here is a maximally reduced (and slightly modified) version of comment #12, which gives the same error: module other_fun abstract interface function abstract_fun(x) integer x integer abstract_fun(x) end function abstract_fun end interface end module other_fun program fptr use other_fun procedure(abstract_fun) :: fun end program fptr gfortran-4.4 fptr.f90 gives the output: end program fptr 1 Internal Error at (1): gfc_get_default_type(): Bad symbol '@0' gfortran version 4.3 happily accepts this test case without complaining, so I suppose this makes it a regression again. -- janus at gcc dot gnu dot org changed: What|Removed |Added Summary|gfc_get_default_type(): Bad |[4.4 regression] |symbol |gfc_get_default_type(): Bad ||symbol http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36463
[Bug bootstrap/33503] [4.3/4.4 Regression] problems with libtool wrapper scripts on mingw32
--- Comment #5 from bonzini at gnu dot org 2008-11-01 14:26 --- The problem is that this bug is unconfirmed. I'd like to see a failure log; mingw builds were tested very carefully when we upgraded Libtool. Marked as waiting. -- bonzini at gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33503
[Bug c++/26693] [4.2/4.3/4.4 regression] Access checks not performed for types in templates
--- Comment #7 from dodji at gcc dot gnu dot org 2008-11-01 14:29 --- I posted a patch to http://gcc.gnu.org/ml/gcc-patches/2008-10/msg01278.html. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26693
[Bug fortran/36426] Endless loop in gfc_apply_interface_mapping_to_expr
--- Comment #2 from janus at gcc dot gnu dot org 2008-11-01 14:43 --- I'm not completely convinced yet that the code in comment #0 is valid. While g95 accepts it, ifort 11.0 beta says: c0.f90(4): error #6362: The data types of the argument(s) are invalid. [LEN] character(len=len(x)) :: foo,x -^ c0.f90(4): error #6415: This name cannot be assigned this data type because it conflicts with prior uses of the name. [X] character(len=len(x)) :: foo,x ^ compilation aborted for c0.f90 (code 1) What I'm worrying about: Is it allowed to use len(x) in the declaration of x? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36426
[Bug fortran/36426] Endless loop in gfc_apply_interface_mapping_to_expr
--- Comment #3 from janus at gcc dot gnu dot org 2008-11-01 14:49 --- Here is a modified version of comment #0: abstract interface function foo(x) character(len=*) :: x character(len=len(x)) :: foo end function foo end interface character(len=20) :: str procedure(foo) :: bar str = bar(Hello) end While this is accepted by both g95 and ifort 11 beta, gfortran-4.4 gives: /tmp/ccAEUsfi.s: Assembler messages: /tmp/ccAEUsfi.s:29: Error: junk `(intrinsic)_MOD_len' after expression -- janus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-11-01 14:49:48 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36426
[Bug fortran/36426] Endless loop in gfc_apply_interface_mapping_to_expr
--- Comment #4 from janus at gcc dot gnu dot org 2008-11-01 14:58 --- A variant of comment #3 which gives a different error: abstract interface function foo(x,y) character(len=*) :: x integer y(:) character(len=size(y)) :: foo end function foo end interface character(len=20) :: str procedure(foo) :: bar str = bar(Hello,(/1,2,3/)) end Here the error message is less cryptic: internal compiler error: in fold_convert, at fold-const.c:2527 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36426
[Bug fortran/36426] Endless loop in gfc_apply_interface_mapping_to_expr
--- Comment #5 from janus at gcc dot gnu dot org 2008-11-01 15:03 --- For both comment #3 and comment #4 the errors disappear if the PROCEDURE statement is removed and instead the interface is made non-abstract. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36426
[Bug c/37987] New: iwmmxt: insn does not satisfy its constraints on (int64_t)
When compiling attached file with -march=iwmmxt -mtune=iwmmxt -O
-fno-omit-frame-pointer, then following error appears on line score= sqr -
((diff*(int64_t)diff)(level+3)):
svq1enc.c: In function 'encode_block':
svq1enc.c:265: error: insn does not satisfy its constraints:
(insn 1636 1634 334 22 (set (reg:SI 43 wcgr0)
(mem/c:SI (plus:SI (reg/f:SI 11 fp)
(const_int -3888 [0xf0d0])) [0 D.8214+0 S4 A32]))
407 {*iwmmxt_movsi_insn} (nil)
(nil))
svq1enc.c:265: internal compiler error: in reload_cse_simplify_operands, at
postreload.c:392
When compiling without -fno-omit-frame-pointer, everything works correctly.
Using built-in specs.
Target: arm-angstrom-linux-gnueabi
Configured with:
/OE/build/tmp/work/armv5te-angstrom-linux-gnueabi/gcc-cross-4.2.4-r3/gcc-4.2.4/configure
--build=x86_64-linux --host=x86_64-linux --target=arm-angstrom-linux-gnueabi
--prefix=/OE/build/tmp/cross/armv5te --exec_prefix=/OE/build/tmp/cross/armv5te
--bindir=/OE/build/tmp/cross/armv5te/bin
--sbindir=/OE/build/tmp/cross/armv5te/bin
--libexecdir=/OE/build/tmp/cross/armv5te/libexec
--datadir=/OE/build/tmp/cross/armv5te/share
--sysconfdir=/OE/build/tmp/cross/armv5te/etc
--sharedstatedir=/OE/build/tmp/cross/armv5te/com
--localstatedir=/OE/build/tmp/cross/armv5te/var
--libdir=/OE/build/tmp/cross/armv5te/lib
--includedir=/OE/build/tmp/cross/armv5te/include
--oldincludedir=/OE/build/tmp/cross/armv5te/include
--infodir=/OE/build/tmp/cross/armv5te/share/info
--mandir=/OE/build/tmp/cross/armv5te/share/man --with-gnu-ld --enable-shared
--enable-target-optspace --enable-languages=c,c++,objc,fortran
--enable-threads=posix --enable-multilib --enable-c99 --enable-long-long
--enable-symvers=gnu --enable-libstdcxx-pch
--program-prefix=arm-angstrom-linux-gnueabi- --enable-libssp
--disable-bootstrap --enable-libgomp --disable-libmudflap --with-float=soft
--with-local-prefix=/OE/build/tmp/staging/armv5te-angstrom-linux-gnueabi/usr
--with-gxx-include-dir=/OE/build/tmp/staging/armv5te-angstrom-linux-gnueabi//usr/include/c++
--with-sysroot=/OE/build/tmp/staging/armv5te-angstrom-linux-gnueabi
--with-build-sysroot=/OE/build/tmp/staging/armv5te-angstrom-linux-gnueabi
--disable-libunwind-exceptions
--with-mpfr=/OE/build/tmp/staging/x86_64-linux/usr --enable-__cxa_atexit
Thread model: posix
gcc version 4.2.4
--
Summary: iwmmxt: insn does not satisfy its constraints on
(int64_t)
Product: gcc
Version: 4.2.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: utx at penguin dot cz
GCC build triplet: iwmmxt-angstrom-linux-gnueabi
GCC host triplet: x86_64-suse-linux
GCC target triplet: arm-angstrom-linux-gnueabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37987
[Bug c/37987] iwmmxt: insn does not satisfy its constraints on (int64_t)
--- Comment #1 from utx at penguin dot cz 2008-11-01 15:12 --- Created an attachment (id=16606) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16606action=view) svq1enc_e.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37987
[Bug fortran/35840] ICE for character expression in I/O specifier
--- Comment #20 from jvdelisle at gcc dot gnu dot org 2008-11-01 15:13 --- Closing, thanks for patch. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35840
[Bug libstdc++/37958] num_get::do_get(bool) sets eofbit flag incorrectly when boolalpha == true
--- Comment #11 from tsyvarev at ispras dot ru 2008-11-01 15:52 --- It is not nitpicking. Case with empty sequences is only demonstration, that code behaviour is not confirm to the standard. Really, it seems that in every succesfull matching it will be unnecessary comparision (in == end). For example, for target sequences false and true and input sequence false eofbit flag won't be set in err, but when __beg points to 'e', (++__beg == __end) in the last if-operator inside for-cycle will return true. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37958
[Bug libstdc++/37958] num_get::do_get(bool) sets eofbit flag incorrectly when boolalpha == true
--- Comment #12 from tsyvarev at ispras dot ru 2008-11-01 16:01 --- Created an attachment (id=16607) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16607action=view) Test, whether there is an unnecessary comparision (in == end) By hooking underflow() method of stringbuf, one can verify, whether do_get() implementation performs unnesessary call of (in == end). First test in main() verify situation, when all sequences are empty. Second and third - falsename is false, truename is true, input sequence is false or true correspondingly. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37958
[Bug c++/34158] Template delete doesn't call if exception thrown in constructor
--- Comment #6 from jwakely dot gcc at gmail dot com 2008-11-01 16:18
---
This is a compile-time test which should fail because undefT cannot be
instantiated, but the deallocation function is not used.
#include stdlib.h
template class T class undef;
struct A {
A() { throw 1; }
};
templatetypename T class Pool { };
templatetypename T
inline void *operator new(size_t size,PoolT pool)
{
return malloc(size);
}
templatetypename T
inline void operator delete(void *p,PoolT pool)
{
undefT t;
free(p);
}
int main ()
{
Poolint pool;
new (pool) A();
return 0;
}
--
jwakely dot gcc at gmail dot com changed:
What|Removed |Added
CC||jwakely dot gcc at gmail dot
||com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34158
[Bug java/37068] [4.4 Regression] libgcj linkage failure: Incorrect library ABI version detected
--- Comment #9 from danglin at gcc dot gnu dot org 2008-11-01 16:18 --- Breakpoint 1, cgraph_build_static_cdtor (which=-52 '?', body=0x400555d8, priority=1074005676) at ../../gcc/gcc/cgraphunit.c:1353 1353 sprintf (which_buf, %c_%.5d_%d, which, priority, counter++); (gdb) bt #0 cgraph_build_static_cdtor (which=-52 '?', body=0x400555d8, priority=1074005676) at ../../gcc/gcc/cgraphunit.c:1353 #1 0x00077010 in java_parse_file (set_yydebug=73) at ../../gcc/gcc/java/jcf-parse.c:1702 #2 0x001ff4e8 in toplev_main (argc=1073746884, argv=0x400555d8) at ../../gcc/gcc/toplev.c:968 #3 0x00082a6c in main (argc=73, argv=0x7aff79e0) at ../../gcc/gcc/main.c:35 (gdb) c Continuing. Breakpoint 1, cgraph_build_static_cdtor (which=1 '\001', body=0x7eff0a08, priority=1) at ../../gcc/gcc/cgraphunit.c:1353 1353 sprintf (which_buf, %c_%.5d_%d, which, priority, counter++); (gdb) bt #0 cgraph_build_static_cdtor (which=1 '\001', body=0x7eff0a08, priority=1) at ../../gcc/gcc/cgraphunit.c:1353 #1 0x00289a20 in build_cdtor (ctor_p=1 '\001', cdtors=0x7afec8a8, len=1) at ../../gcc/gcc/cgraphunit.c:219 #2 0x0028bdc0 in cgraph_optimize () at ../../gcc/gcc/cgraphunit.c:289 #3 0x00077030 in java_parse_file (set_yydebug=73) at ../../gcc/gcc/java/jcf-parse.c:1961 #4 0x001ff4e8 in toplev_main (argc=1073746884, argv=0x400555d8) at ../../gcc/gcc/toplev.c:968 #5 0x00082a6c in main (argc=73, argv=0x7a7af860) at ../../gcc/gcc/main.c:35 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37068
[Bug libstdc++/37958] num_get::do_get(bool) sets eofbit flag incorrectly when boolalpha == true
--- Comment #13 from paolo at gcc dot gnu dot org 2008-11-01 16:19 --- Subject: Bug 37958 Author: paolo Date: Sat Nov 1 16:17:42 2008 New Revision: 141517 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141517 Log: 2008-11-01 Paolo Carlini [EMAIL PROTECTED] PR libstdc++/37958 (cont) * include/bits/locale_facets.tcc (num_get::do_get(iter_type, iter_type, ios_base, ios_base::iostate, bool): Fix again. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/locale_facets.tcc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37958
[Bug libstdc++/37958] num_get::do_get(bool) sets eofbit flag incorrectly when boolalpha == true
--- Comment #14 from paolo dot carlini at oracle dot com 2008-11-01 16:22 --- Ok, ok. In the future, please don't lump issues together (i.e., do not reopen PRs if the first commit fixes the original issue, file a separate one) and always provide specific testcases. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37958
[Bug fortran/37988] New: Edit descriptor checking (compile time) for HolerithT)
Found at http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/1086da75f7aed669 The following program is invalid as the (Holerith) string has 22 and not 21 characters. Thus the format is ...Holerith stringT). gfortran accepts the program at compile time, but rejects it at run time with: Fortran runtime error: Positive width required in format EVEL =',F7.4, 21H ONE-SIDED AT THE LEFT) ^ g95 and NAG f95 detect the problem already at compile time - gfortran should do the same. WRITE(0,8001) SIG WRITE(6,8001) SIG 8001 FORMAT(//,' SIGNIFICANCE LEVEL =',F7.4, 21H ONE-SIDED AT THE LEFT) end -- Summary: Edit descriptor checking (compile time) for HolerithT) Product: gcc Version: 4.4.0 Status: UNCONFIRMED Keywords: diagnostic Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37988
[Bug fortran/37988] Edit descriptor checking (compile time) for HolerithT)
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2008-11-01 16:32 --- I will attend to this if you dont beat me to it. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jvdelisle at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-11-01 16:32:54 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37988
[Bug fortran/37925] some error during 'make' on GCC 4.3.2
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2008-11-01 16:39 --- Are you trying to make from within the source directory? -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Summary|some error during 'make' on |some error during 'make' on |GCC 4.3.2 |GCC 4.3.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37925
[Bug fortran/19925] Implied do-loop in an initialization expression is broken
--- Comment #30 from jvdelisle at gcc dot gnu dot org 2008-11-01 16:43 --- Subject: Bug 19925 Author: jvdelisle Date: Sat Nov 1 16:42:31 2008 New Revision: 141518 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141518 Log: 2008-11-01 Steven G. Kargl [EMAIL PROTECTED] PR fortran/19925 * trans-array.c (gfc_trans_array_constructor_value): Fix comment. (gfc_conv_array_initializer): Convert internal_error() to gfc_error_now. * array.c: Remove GFC_MAX_AC_EXPAND macro. (gfc_expand_constructor): Use gfc_option.flag_max_array_constructor. * gfortran.h (gfc_option): Add flag_max_array_constructor member. * lang.opt: Add -fmax-array-constructor option. * expr.c (gfc_match_init_expr): Fix error message to mention new option. * invoke.texi: Document new option. * options.c (gfc_init_options): Set default value for new option. (gfc_handle_option): Deal with commandline. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/array.c trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/invoke.texi trunk/gcc/fortran/lang.opt trunk/gcc/fortran/options.c trunk/gcc/fortran/trans-array.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19925
[Bug java/37068] [4.4 Regression] libgcj linkage failure: Incorrect library ABI version detected
--- Comment #10 from dave at hiauly1 dot hia dot nrc dot ca 2008-11-01 16:49 --- Subject: Re: [4.4 Regression] libgcj linkage failure: Incorrect library ABI version detected On Sat, 01 Nov 2008, danglin at gcc dot gnu dot org wrote: Possibly the attached change will fix the problem. However, I'm not sure if cgraphunit.c will detect all the java constructors that need calling. Someone who knows a little about java will need to look at this. Dave --- Comment #11 from dave at hiauly1 dot hia dot nrc dot ca 2008-11-01 16:49 --- Created an attachment (id=16608) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16608action=view) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37068
[Bug fortran/19925] Implied do-loop in an initialization expression is broken
--- Comment #31 from jvdelisle at gcc dot gnu dot org 2008-11-01 17:02 --- Subject: Bug 19925 Author: jvdelisle Date: Sat Nov 1 17:00:49 2008 New Revision: 141519 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141519 Log: 2008-11-01 Steven G. Kargl [EMAIL PROTECTED] PR fortran/19925 * gfortran.dg/initialization_20.f90: New test. * gfortran.dg/initialization_21.f90: Ditto. Added: trunk/gcc/testsuite/gfortran.dg/initialization_20.f90 trunk/gcc/testsuite/gfortran.dg/initialization_21.f90 Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19925
[Bug fortran/19925] Implied do-loop in an initialization expression is broken
--- Comment #32 from jvdelisle at gcc dot gnu dot org 2008-11-01 17:07 --- Finally, I hope. :) -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19925
[Bug tree-optimization/37542] [4.4 Regression] PRE doesn't simplify during phi-translation
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-11-01 17:11 ---
We need to be careful with simplifying to SSA_NAMEs as the following example
shows:
int foo (int i, int b)
{
int mask;
int result;
if (b)
mask = -1;
else
mask = 0;
result = i + 1;
result = result mask;
return result;
}
we have a phi-translation for result mask that is 0 or result dependent
on the path through the CFG. But we cannot insert this as a PHI as one
argument (result with value i + 1) is not available there.
The PRE of 4.3 inserts i + 1, re-generating the expression recursively and
exposing a code hoisting opportunity:
bb 2:
if (b_2(D) != 0)
goto bb 5;
else
goto bb 3;
bb 5:
pretmp.6_10 = i_5(D) + 1;
pretmp.6_11 = pretmp.6_10;
goto bb 4;
bb 3:
pretmp.6_13 = i_5(D) + 1;
bb 4:
# prephitmp.7_14 = PHI pretmp.6_10(5), pretmp.6_13(3)
# prephitmp.7_12 = PHI pretmp.6_11(5), 0(3)
# mask_1 = PHI -1(5), 0(3)
result_6 = prephitmp.7_14;
result_7 = prephitmp.7_12;
return result_7;
I don't think we want to do this now (without code hoisting implemented), but
for cases where result_6 is available we surely want it.
I'm trying to find a way to detect whether it is safe to phi-translate to
result_6.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||dberlin at gcc dot gnu dot
||org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37542
[Bug tree-optimization/37542] [4.4 Regression] PRE doesn't simplify during phi-translation
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-11-01 17:12 --- Created an attachment (id=16609) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16609action=view) preliminary patch preliminary patch, only dealing with optimizing to constants. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37542
[Bug c++/35652] [4.2/4.3/4.4 Regression] offset warning should be given in the front-end
--- Comment #8 from manu at gcc dot gnu dot org 2008-11-01 17:44 ---
This is my current patch and it works in this testcase. However, it also
triggers on cases like: const char *p = str + sizeof(str)
Perhaps I am doing this at the wrong place. Any suggestions?
@@ -3322,10 +3323,36 @@ pointer_int_sum (enum tree_code resultco
/* Create the sum or difference. */
if (resultcode == MINUS_EXPR)
intop = fold_build1 (NEGATE_EXPR, sizetype, intop);
+
+ if (TREE_CODE (intop) == INTEGER_CST)
+{
+ tree offset_node;
+ tree string_cst = string_constant (ptrop, offset_node);
+
+ if (string_cst != 0
+ !(offset_node TREE_CODE (offset_node) != INTEGER_CST))
+ {
+ HOST_WIDE_INT max = TREE_STRING_LENGTH (string_cst) - 1;
+ HOST_WIDE_INT offset;
+ if (offset_node == 0)
+ offset = 0;
+ else if (! host_integerp (offset_node, 0))
+ offset = -1;
+ else
+ offset = tree_low_cst (offset_node, 0);
+
+ offset = offset + tree_low_cst (intop, 0);
+ if (offset 0 || offset max)
+ warning_at (location, 0,
+ offset %%ld% outside bounds of constant string,
+ tree_low_cst (intop, 0));
+ }
+}
+
ret = fold_build2 (POINTER_PLUS_EXPR, result_type, ptrop, intop);
fold_undefer_and_ignore_overflow_warnings ();
return ret;
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35652
[Bug c/37989] New: PR37528 fix broke --disable-shared on mingw32
gcc-4.4-20081003 and later configured with --disable-shared for mingw32 attempt
to link with libgcc_eh.a even though it never built libgcc_eh.a (those object
files are included in libgcc.a):
/home/mikpe/gcc-4.4-20081031/configure --target=x86_64-pc-mingw32
--prefix=/tmp/cross-mingw64 --disable-nls --disable-shared
--enable-threads=win32 --enable-languages=c --with-gmp=/opt/local/gmp-4.2.4
--with-mpfr=/opt/local/mpfr-2.3.2 --disable-win32-registry
--enable-sjlj-exceptions
make
make install
echo int main(void) { return 0; } trivial.c
/tmp/cross-mingw64/bin/x86_64-pc-mingw32-gcc trivial.c
/tmp/cross-mingw64/lib/gcc/x86_64-pc-mingw32/4.4.0/../../../../x86_64-pc-mingw32/bin/ld:
cannot find -lgcc_eh
collect2: ld returned 1 exit status
The fix for PR37528 changed mingw32.h to #define REAL_LIBGCC_SPEC, and it also
changed it to unconditionally link with -lgcc_eh for !shared-libgcc.
That only works if libgcc_eh.a actually was built, which isn't the case when
gcc was configured with --disable-shared.
--
Summary: PR37528 fix broke --disable-shared on mingw32
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mikpe at it dot uu dot se
GCC build triplet: i686-pc-cygwin
GCC host triplet: i686-pc-cygwin
GCC target triplet: x86_64-pc-mingw32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37989
[Bug c/37989] PR37528 fix broke --disable-shared on mingw32
--- Comment #1 from mikpe at it dot uu dot se 2008-11-01 18:10 --- Created an attachment (id=16610) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16610action=view) patch to unbreak --disable-shared on mingw32 Proposed patch to unbreak --disable-shared on mingw32. When PR37528 changed mingw32.h to #define REAL_LIBGCC_SPEC it also bypassed gcc/gcc.c's logic to only link with -lgcc_eh when ENABLE_SHARED_LIBGCC is defined. So my proposed fix adds that logic to mingw32.h's definition of REAL_LIBGCC_SPEC. Tested on WinXP64 under cygwin both with and without --disable-shared. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37989
[Bug libstdc++/37958] num_get::do_get(bool) sets eofbit flag incorrectly when boolalpha == true
--- Comment #15 from tsyvarev at ispras dot ru 2008-11-01 18:43 --- I belived that the easier describe situation is the better. Because setting flag is simpler to observe, than the fact of comparision (in == end), PR was reported about flag but comparision. But the second patch is also not correct... If run test in the second attachment, in the second testcase(falsename - false, truename - true, input - false) eofbit flag won't be set(it is right). But in the third testcase(input is true) implementation set eofbit flag. Problem is that __lim cannot be used as stopper for the cycle, because target sequences have different lenght. If move last if in for-cycle if ((!__testt __n = __lc-_M_falsename_size) || (!__testf __n = __lc-_M_truename_size)) break; to the beginning of the cycle, all seems to be correct... except case of identical target sequences. Later I'll try to write more presize test, and may try to write patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37958
[Bug libstdc++/37958] num_get::do_get(bool) sets eofbit flag incorrectly when boolalpha == true
--- Comment #16 from paolo dot carlini at oracle dot com 2008-11-01 18:48 --- (In reply to comment #15) But the second patch is also not correct... I don't see why. If run test in the second attachment, in the second testcase(falsename - false, truename - true, input - false) eofbit flag won't be set(it is right). But in the third testcase(input is true) implementation set eofbit flag. Your testcase passes, three PASS in the output. Problem is that __lim cannot be used as stopper for the cycle, because target sequences have different lenght. Indeed, the other tests at the end of the for trigger in that case (different lengths). Later I'll try to write more presize test, and may try to write patch. Yes, we need a testcase. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37958
[Bug middle-end/37071] [4.4 Regression] EH is broken
--- Comment #2 from danglin at gcc dot gnu dot org 2008-11-01 18:54 --- Except for the fail noted in PR 37610, the problems with the new .cfi directives have been fixed by a combination of assembler and gcc fixes. The assembler fixes are currently only available from CVS. -- danglin at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37071
[Bug libstdc++/37958] num_get::do_get(bool) sets eofbit flag incorrectly when boolalpha == true
--- Comment #17 from paolo dot carlini at oracle dot com 2008-11-01 19:05 --- Ok, I see that for true in input eofbit should not be set. I'll fix this, but your testcase is wrong. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37958
[Bug fortran/36426] Endless loop in gfc_apply_interface_mapping_to_expr
--- Comment #6 from janus at gcc dot gnu dot org 2008-11-01 19:06 ---
The following patch fixes comment #3 and comment #4:
Index: gcc/fortran/expr.c
===
--- gcc/fortran/expr.c (revision 141520)
+++ gcc/fortran/expr.c (working copy)
@@ -3511,12 +3511,11 @@ static bool
replace_symbol (gfc_expr *expr, gfc_symbol *sym, int *i ATTRIBUTE_UNUSED)
{
if ((expr-expr_type == EXPR_VARIABLE || expr-expr_type == EXPR_FUNCTION)
- expr-symtree-n.sym-ns != sym-formal_ns
- expr-symtree-n.sym-attr.dummy)
+ expr-symtree-n.sym-ns == sym-ts.interface-formal_ns)
{
gfc_symtree *stree;
gfc_get_sym_tree (expr-symtree-name, sym-formal_ns, stree);
- stree-n.sym-attr.referenced = expr-symtree-n.sym-attr.referenced;
+ stree-n.sym-attr = expr-symtree-n.sym-attr;
expr-symtree = stree;
}
return false;
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c (revision 141515)
+++ gcc/fortran/resolve.c (working copy)
@@ -8936,6 +8936,9 @@ resolve_symbol (gfc_symbol *sym)
sym-ts.cl-resolved = ifc-ts.cl-resolved;
sym-ts.cl-length = gfc_copy_expr (ifc-ts.cl-length);
gfc_expr_replace_symbols (sym-ts.cl-length, sym);
+ /* Add charlen to namespace. */
+ sym-ts.cl-next = sym-formal_ns-cl_list;
+ sym-formal_ns-cl_list = sym-ts.cl;
}
}
else if (sym-ts.interface-name[0] != '\0')
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |janus at gcc dot gnu dot org
|dot org |
Status|NEW |ASSIGNED
Last reconfirmed|2008-11-01 14:49:48 |2008-11-01 19:06:52
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36426
[Bug ada/35533] FAIL: gnat.dg/derived_aggregate.adb execution test
--- Comment #1 from danglin at gcc dot gnu dot org 2008-11-01 19:13 --- No longer fails. -- danglin at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35533
[Bug middle-end/35193] [4.3/4.4 Regression] can't find a register in class 'R1_REGS' while reloading 'asm'
--- Comment #10 from danglin at gcc dot gnu dot org 2008-11-01 19:25 --- This seems to be fixed with 4.4.0 as of 2008-11-01. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35193
[Bug target/35090] [4.3/4.4 regression] libjava testsuite failures on hppa-linux
--- Comment #7 from danglin at gcc dot gnu dot org 2008-11-01 19:39 --- These tests no longer fail on either 4.3 or 4.4. I am fairly certain that these failures were a libc problem. -- danglin at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35090
[Bug fortran/37903] [4.3/4.4 Regression] wrong-code for complicated vector subscripts
--- Comment #15 from pault at gcc dot gnu dot org 2008-11-01 19:46 --- Mikael, Thanks for the report and the fix:-) Fixed on trunk and 4.3 Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37903
[Bug fortran/37903] [4.3/4.4 Regression] wrong-code for complicated vector subscripts
--- Comment #16 from pault at gcc dot gnu dot org 2008-11-01 19:47 --- Subject: Bug 37903 Author: pault Date: Sat Nov 1 19:45:41 2008 New Revision: 141521 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141521 Log: 2008-11-01 Mikael Morin [EMAIL PROTECTED] PR fortran/37903 * trans-array.c (gfc_trans_create_temp_array): If n is less than the temporary dimension, assert that loop-from is zero (reverts to earlier versions). If there is at least one null loop-to[n], it is a callee allocated array so set the size to NULL and break. (gfc_trans_constant_array_constructor): Set the offset to zero. (gfc_trans_array_constructor): Remove loop shifting around the temporary creation. (gfc_conv_loop_setup): Prefer zero-based descriptors if possible. Calculate the translation from loop variables to array indices if an array constructor. 2008-11-01 Mikael Morin [EMAIL PROTECTED] PR fortran/37749 * trans-array.c (gfc_trans_create_temp_array): If size is NULL use the array bounds for loop-to. 2008-11-01 Mikael Morin [EMAIL PROTECTED] PR fortran/37903 * gfortran.dg/vector_subscript_4.f90: New test. 2008-11-01 Mikael Morin [EMAIL PROTECTED] PR fortran/37749 * gfortran.dg/vector_subscript__5.f90: New test. Added: branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/vector_subscript_4.f90 branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/vector_subscript_5.f90 Modified: branches/gcc-4_3-branch/gcc/fortran/ChangeLog branches/gcc-4_3-branch/gcc/fortran/trans-array.c branches/gcc-4_3-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37903
[Bug fortran/37749] ICE on array section with vector subscript
--- Comment #5 from pault at gcc dot gnu dot org 2008-11-01 19:47 --- Subject: Bug 37749 Author: pault Date: Sat Nov 1 19:45:41 2008 New Revision: 141521 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141521 Log: 2008-11-01 Mikael Morin [EMAIL PROTECTED] PR fortran/37903 * trans-array.c (gfc_trans_create_temp_array): If n is less than the temporary dimension, assert that loop-from is zero (reverts to earlier versions). If there is at least one null loop-to[n], it is a callee allocated array so set the size to NULL and break. (gfc_trans_constant_array_constructor): Set the offset to zero. (gfc_trans_array_constructor): Remove loop shifting around the temporary creation. (gfc_conv_loop_setup): Prefer zero-based descriptors if possible. Calculate the translation from loop variables to array indices if an array constructor. 2008-11-01 Mikael Morin [EMAIL PROTECTED] PR fortran/37749 * trans-array.c (gfc_trans_create_temp_array): If size is NULL use the array bounds for loop-to. 2008-11-01 Mikael Morin [EMAIL PROTECTED] PR fortran/37903 * gfortran.dg/vector_subscript_4.f90: New test. 2008-11-01 Mikael Morin [EMAIL PROTECTED] PR fortran/37749 * gfortran.dg/vector_subscript__5.f90: New test. Added: branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/vector_subscript_4.f90 branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/vector_subscript_5.f90 Modified: branches/gcc-4_3-branch/gcc/fortran/ChangeLog branches/gcc-4_3-branch/gcc/fortran/trans-array.c branches/gcc-4_3-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37749
[Bug fortran/37749] ICE on array section with vector subscript
--- Comment #6 from pault at gcc dot gnu dot org 2008-11-01 19:47 --- Jakub, Thanks for the report - fixed by Mikael on trunk and 4.3. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37749
[Bug fortran/36426] Endless loop in gfc_apply_interface_mapping_to_expr
--- Comment #7 from dominiq at lps dot ens dot fr 2008-11-01 20:13 --- With the patch in comment #6 the following code gives an ICE: subroutine sub(x) abstract interface character function abs_fun() end function end interface procedure(abs_fun):: x end subroutine end [ibook-dhum] f90/bug% gfc pr36322_1.f90 f951: internal compiler error: Bus error -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36426
[Bug middle-end/34483] wo_prof_two_strs.c:56: internal compiler error: in find_new_var_of_type, at ipa-struct-reorg.c:605
--- Comment #69 from danglin at gcc dot gnu dot org 2008-11-01 20:15 --- Fixed. -- danglin at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34483
[Bug ada/33602] FAIL: c452001
--- Comment #1 from danglin at gcc dot gnu dot org 2008-11-01 20:23 --- 4.3.3 20081006 revision 140917 and 4.4.0 20081027 revision 141382 are ok. -- danglin at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33602
[Bug target/37812] [4.4 Regression] Invalid mnemonic 'lvlx'
--- Comment #2 from ubizjak at gmail dot com 2008-11-01 21:04 --- There was similar problem on x86 target with sun as and ffreep mnemonic. This was fixed by a configure check and conditional generation of either ffreep or .word\t0x. Please grep for HAVE_AS_IX86_FFREEP. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37812
[Bug fortran/35040] usage of init expression in its own definition
--- Comment #5 from janus at gcc dot gnu dot org 2008-11-01 21:19 --- On a related note: The following snippet from PR36426 produces an ICE. function foo(x) character(len=len(x)) :: foo,x end function foo -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35040
[Bug c/37990] New: -Os produces redundant instructions
DESCRIPTION:
Simple test case is below.
There is redundant stack manipulation in the assembly output.
Use gcc -Wall -Os -S test.c
-
VERSION INFO:
--
gcc -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu
--enable-libstdcxx-debug --enable-mpfr --enable-checking=release i486-linux-gnu
Thread model: posix
gcc version 4.1.2 20060928 (prerelease) (Ubuntu 4.1.1-13ubuntu5)
---
SOURCE CODE:
--
extern int ii(int i);
void
mm()
{
int i=99;
more:
i = ii(i);
goto inc;
inc:
if(i==0)
goto more;
i++;
goto more;
}
---
--
Summary: -Os produces redundant instructions
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reza at parvan dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37990
[Bug c++/37991] New: excessive memory consumption - possible hang
I just tried to compile the attached C++ source code with both gcc 4.3.1 and gcc 4.4.0 snapshot 20081031. gcc 431 took less than one second and consumed a trivial amount of virtual memory. gcc 440 snapshot 20081031 took over 90 seconds on an idle machine, and consumed over 11 Gig of virtual memory before running out of virtual memory. In my opinion, 11 Gig of memory is an excessive amount of memory to use. I suspect the compiler is looping without doing any productive work. Preprocessed source code attached. Flag -O2 required. -- Summary: excessive memory consumption - possible hang Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dcb314 at hotmail dot com GCC host triplet: suse-linux-x86_64 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37991
[Bug c++/37991] excessive memory consumption - possible hang
--- Comment #1 from dcb314 at hotmail dot com 2008-11-01 21:28 --- Created an attachment (id=16611) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16611action=view) C++ source code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37991
[Bug fortran/36426] Endless loop in gfc_apply_interface_mapping_to_expr
--- Comment #8 from janus at gcc dot gnu dot org 2008-11-01 21:57 --- Subject: Bug 36426 Author: janus Date: Sat Nov 1 21:56:27 2008 New Revision: 141522 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141522 Log: 2008-11-01 Janus Weil [EMAIL PROTECTED] PR fortran/36426 * expr.c (replace_symbol): Replace all symbols which lie in the formal namespace of the interface and copy their attributes. * resolve.c (resolve_symbol): Add charlen to namespace. 2008-11-01 Janus Weil [EMAIL PROTECTED] PR fortran/36426 * gfortran.dg/proc_decl_19.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/proc_decl_19.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/expr.c trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36426
[Bug fortran/36426] Endless loop in gfc_apply_interface_mapping_to_expr
--- Comment #9 from janus at gcc dot gnu dot org 2008-11-01 22:00 --- Fixed with r141522. Closing. -- janus at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36426
[Bug fortran/37992] New: [4.4 Regression] ICE segfault for character(len=len(x)) :: foo,x
Split off from PR 35040 comment 5. The following program gives now an ICE: function foo(x) character(len=len(x)) :: foo,x end function foo With 4.3 there is no ICE, but with 4.4 there is an ICE after the (new!) error detection. (len(x)... :: x is invalid.) Valgrind shows a huge number of invalid reads. -- Summary: [4.4 Regression] ICE segfault for character(len=len(x)) :: foo,x Product: gcc Version: 4.4.0 Status: UNCONFIRMED Keywords: ice-on-invalid-code Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37992
[Bug ada/37993] New: bootstrap with ada fails: a-direct.ads:426:09: alignment for Search_Typeb82s must be at least 8
/Users/dave/Documents/gnu/gcc/objdir/./gcc/xgcc -B/Users/dave/Documents/gnu/gcc/ objdir/./gcc/ -B/opt/gnu/gcc/gcc-4.4.0/i686-apple-darwin9/bin/ -B/opt/gnu/gcc/gc c-4.4.0/i686-apple-darwin9/lib/ -isystem /opt/gnu/gcc/gcc-4.4.0/i686-apple-darwi n9/include -isystem /opt/gnu/gcc/gcc-4.4.0/i686-apple-darwin9/sys-include -c -g -O2 -m64 -fPIC -pipe -fno-common -W -Wall -gnatpg -m64 a-d irect.adb -o a-direct.o a-direct.ads:426:09: alignment for Search_Typeb82s must be at least 8 a-direct.ads:426:09: alignment for Search_Typer80s must be at least 8 a-direct.ads:426:09: alignment for Search_Typet77s must be at least 8 -- Summary: bootstrap with ada fails: a-direct.ads:426:09: alignment for Search_Typeb82s must be at least 8 Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu dot org GCC build triplet: i686-apple-darwin9 GCC host triplet: i686-apple-darwin9 GCC target triplet: i686-apple-darwin9 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37993
[Bug libstdc++/37958] num_get::do_get(bool) sets eofbit flag incorrectly when boolalpha == true
--- Comment #18 from paolo at gcc dot gnu dot org 2008-11-01 22:10 --- Subject: Bug 37958 Author: paolo Date: Sat Nov 1 22:09:43 2008 New Revision: 141523 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141523 Log: 2008-11-01 Paolo Carlini [EMAIL PROTECTED] PR libstdc++/37958 (cont again) * include/bits/locale_facets.tcc (num_get::do_get(iter_type, iter_type, ios_base, ios_base::iostate, bool): Fix again. * testsuite/22_locale/num_get/get/char/37958.cc: Extend. * testsuite/22_locale/num_get/get/wchar_t/37958.cc: Likewise. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/locale_facets.tcc trunk/libstdc++-v3/testsuite/22_locale/num_get/get/char/37958.cc trunk/libstdc++-v3/testsuite/22_locale/num_get/get/wchar_t/37958.cc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37958
[Bug fortran/35040] usage of init expression in its own definition
--- Comment #6 from burnus at gcc dot gnu dot org 2008-11-01 22:14 --- (In reply to comment #5) On a related note: The following snippet from PR36426 produces an ICE. function foo(x) character(len=len(x)) :: foo,x end function foo As this ICE is a regression, I opened the PR 37992 for this. (It is also not an accepts invalid since gfortran 4.4 now prints an error message.) * * * For the LHS (of =) expressions such as in comment 1, one now also gets the error message. * * * (In reply to comment #4) And I also believe all our examples in this PR are wrong. In all the invalid examples given in comment #3, the dimension specification is on the rhs of '::'. In my example it's on the lhs. Sorry, I don't understand / find your example. The example REAL, DIMENSION(2,2), PARAMETER :: xyz = RESHAPE((/ 1,2,3,4 /), SHAPE(xyz)) is no different from the invalid examples of comment #3: REAL :: X = EPSILON(X) If the latter is invalid too, how about DIMENSION :: xyz(2,2) REAL, PARAMETER :: xyz = RESHAPE((/ 1,2,3,4 /), SHAPE(xyz)) I think that test case is OK. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35040
[Bug target/37939] [4.2/4.3/4.4 Regression] CRIS port: no addi insn
--- Comment #3 from hp at gcc dot gnu dot org 2008-11-01 22:17 --- Subject: Bug 37939 Author: hp Date: Sat Nov 1 22:16:09 2008 New Revision: 141524 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141524 Log: PR target/37939 * config/cris/cris.c (cris_rtx_costs) MULT: Return 0 for an ADDI operand. Modified: trunk/gcc/ChangeLog trunk/gcc/config/cris/cris.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37939
[Bug target/37939] [4.2/4.3/4.4 Regression] CRIS port: no addi insn
--- Comment #4 from hp at gcc dot gnu dot org 2008-11-01 22:20 --- Subject: Bug 37939 Author: hp Date: Sat Nov 1 22:19:26 2008 New Revision: 141525 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141525 Log: PR target/37939 * gcc.target/cris/biap.c: New test. Added: trunk/gcc/testsuite/gcc.target/cris/biap.c Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37939
[Bug target/37939] [4.2/4.3/4.4 Regression] CRIS port: no addi insn
--- Comment #5 from hp at gcc dot gnu dot org 2008-11-01 22:28 --- Subject: Bug 37939 Author: hp Date: Sat Nov 1 22:26:43 2008 New Revision: 141526 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141526 Log: PR target/37939 * config/cris/cris.c (cris_rtx_costs) MULT: Return 0 for an ADDI operand. Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/config/cris/cris.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37939
[Bug target/37939] [4.2/4.3/4.4 Regression] CRIS port: no addi insn
--- Comment #6 from hp at gcc dot gnu dot org 2008-11-01 22:29 --- Subject: Bug 37939 Author: hp Date: Sat Nov 1 22:28:28 2008 New Revision: 141527 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141527 Log: PR target/37939 * gcc.target/cris/biap.c: New test. Added: branches/gcc-4_3-branch/gcc/testsuite/gcc.target/cris/biap.c Modified: branches/gcc-4_3-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37939
