[Bug tree-optimization/31136] [4.2 Regression] FRE ignores bit-field truncation (C and C++ front-end don't produce bit-field truncation
--- Comment #8 from pinskia at gmail dot com 2007-03-23 07:57 --- Subject: Re: [4.2 Regression] FRE ignores bit-field truncation (C and C++ front-end don't produce bit-field truncation On 23 Mar 2007 05:01:00 -, spark at gcc dot gnu dot org <[EMAIL PROTECTED]> wrote: > The problematic STRIP_SIGN_NOPS() call is from fold_unary() > which is called from try_combine_conversion() in tree-ssa-pre.c. > > STRIP_SIGN_NOPS() is called with the expression: No, STRIP_SIGN_NOPS is correct, just fold_unary is incorrect in its folding. It should have called fold_convert on the expression if the types are different and it is a constant. -- Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31136
Re: [Bug tree-optimization/31136] [4.2 Regression] FRE ignores bit-field truncation (C and C++ front-end don't produce bit-field truncation
On 23 Mar 2007 05:01:00 -, spark at gcc dot gnu dot org <[EMAIL PROTECTED]> wrote: The problematic STRIP_SIGN_NOPS() call is from fold_unary() which is called from try_combine_conversion() in tree-ssa-pre.c. STRIP_SIGN_NOPS() is called with the expression: No, STRIP_SIGN_NOPS is correct, just fold_unary is incorrect in its folding. It should have called fold_convert on the expression if the types are different and it is a constant. -- Pinski
[Bug libgomp/26165] Cannot find libgomp.spec after 'make install' on x86_64 and ppc64
--- Comment #13 from martin at mpa-garching dot mpg dot de 2007-03-23 07:49 --- Could you please have a look at this before 4.2.0 is released? It seems (at least to me), that a lot can be gained (i.e. OpenMP works on x86_64) by very little work. Or is the proposed workaround (installing libgomp.spec in another path) incorrect for some reason? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26165
[Bug fortran/30834] ICE with kind=8 exponentiaton
--- Comment #16 from fxcoudert at gcc dot gnu dot org 2007-03-23 07:02 --- Fixed on mainline, will not backport to 4.2 as it's not a regression. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30834
[Bug fortran/30834] ICE with kind=8 exponentiaton
--- Comment #15 from fxcoudert at gcc dot gnu dot org 2007-03-23 07:01 --- Subject: Bug 30834 Author: fxcoudert Date: Fri Mar 23 07:00:56 2007 New Revision: 123154 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123154 Log: PR fortran/30834 * arith.c (complex_pow): Rewrite to handle large power. (gfc_arith_power): Handle large power in the real and integer cases. * gfortran.dg/integer_exponentiation_3.F90: New test. * gfortran.dg/integer_exponentiation_4.f90: New test. * gfortran.dg/integer_exponentiation_5.F90: New test. Added: trunk/gcc/testsuite/gfortran.dg/integer_exponentiation_3.F90 trunk/gcc/testsuite/gfortran.dg/integer_exponentiation_4.f90 trunk/gcc/testsuite/gfortran.dg/integer_exponentiation_5.F90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/arith.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30834
[Bug c++/31323] typename A::B * p; in template definition, with curiously recurring template inheritance
--- Comment #2 from mesti_mudam at yahoo dot com 2007-03-23 06:42 --- well, priv is a pointer.. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31323
[Bug c++/31323] typename A::B * p; in template definition, with curiously recurring template inheritance
--- Comment #1 from bangerth at dealii dot org 2007-03-23 06:26 --- Or smaller like this: -- template struct Base { typename T::X X; }; struct A : Base { typedef int X; }; -- sunCC also rejects it. I tend to believe that the code is invalid because at the time where we instantiate Base (in the base class list of A), A is not complete and so the inner typedef is not available yet. What makes you think that the code should compile? W. -- bangerth at dealii dot org changed: What|Removed |Added CC||bangerth at dealii dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31323
[Bug c++/31323] New: typename A::B * p; in template definition, with curiously recurring template inheritance
The following code doesnt compile with gcc, dmc, icc. Im not sure if its correct code, but it looks like it is. #include using std::cout; using std::endl; template class Base { protected: typename T::privIC * priv; public: virtual int f1() =0; virtual int f2() =0; }; class A : public Base { public: class privIC { int i; }; int f1(); int f2(); }; int A::f1() { return 0; } int A::f2() { return 0; } int main() { A a; cout << a.f2() << endl; } -- Summary: typename A::B * p; in template definition, with curiously recurring template inheritance Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mesti_mudam at yahoo dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31323
[Bug tree-optimization/31136] [4.2 Regression] FRE ignores bit-field truncation (C and C++ front-end don't produce bit-field truncation
--- Comment #7 from spark at gcc dot gnu dot org 2007-03-23 05:00 --- Follow up on Joseph's analysis: The problematic STRIP_SIGN_NOPS() call is from fold_unary() which is called from try_combine_conversion() in tree-ssa-pre.c. STRIP_SIGN_NOPS() is called with the expression: unit size align 8 symtab 0 alias set -1 precision 4 min max > arg 0 constant invariant 31>> and it stripes away the conversion, leaving only integer constant 31. This is clearly wrong as it removes the downconversion of precision. Following patch (against 4.2 branch) seems to fix the problem: Index: tree.h === --- tree.h (revision 123088) +++ tree.h (working copy) @@ -912,7 +912,9 @@ extern void omp_clause_range_check_faile && (TYPE_MODE (TREE_TYPE (EXP))\ == TYPE_MODE (TREE_TYPE (TREE_OPERAND (EXP, 0 \ && (TYPE_UNSIGNED (TREE_TYPE (EXP))\ -== TYPE_UNSIGNED (TREE_TYPE (TREE_OPERAND (EXP, 0) \ +== TYPE_UNSIGNED (TREE_TYPE (TREE_OPERAND (EXP, 0\ +&& (TYPE_PRECISION (TREE_TYPE (EXP)) \ +>= TYPE_PRECISION (TREE_TYPE (TREE_OPERAND (EXP, 0)\ (EXP) = TREE_OPERAND (EXP, 0) /* Like STRIP_NOPS, but don't alter the TREE_TYPE either. */ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31136
[Bug c++/30863] [4.1 Regression] Unsigned templatized struct treated as unsigned int
--- Comment #4 from mmitchel at gcc dot gnu dot org 2007-03-23 04:37 --- Fixed in 4.2.0, 4.3.0. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.1/4.2/4.3 Regression]|[4.1 Regression] Unsigned |Unsigned templatized struct |templatized struct treated |treated as unsigned int |as unsigned int http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30863
[Bug c++/30863] [4.1/4.2/4.3 Regression] Unsigned templatized struct treated as unsigned int
--- Comment #3 from mmitchel at gcc dot gnu dot org 2007-03-23 04:37 --- Subject: Bug 30863 Author: mmitchel Date: Fri Mar 23 04:37:40 2007 New Revision: 123152 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123152 Log: PR c++/30863 * parser.c (cp_parser_parse_and_diagnose_invalid_type_name): Do not consume tokens when failing. PR c++/30863 * g++.dg/template/error24.C: New test. * g++.dg/parse/tmpl-outside1.C: Tweak error markers. Added: trunk/gcc/testsuite/g++.dg/template/error24.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/parse/tmpl-outside1.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30863
[Bug c++/30863] [4.1/4.2/4.3 Regression] Unsigned templatized struct treated as unsigned int
--- Comment #2 from mmitchel at gcc dot gnu dot org 2007-03-23 04:36 --- Subject: Bug 30863 Author: mmitchel Date: Fri Mar 23 04:36:33 2007 New Revision: 123151 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123151 Log: PR c++/30863 * parser.c (cp_parser_parse_and_diagnose_invalid_type_name): Do not consume tokens when failing. PR c++/30863 * g++.dg/template/error24.C: New test. * g++.dg/parse/tmpl-outside1.C: Tweak error markers. Added: branches/gcc-4_2-branch/gcc/testsuite/g++.dg/template/error24.C Modified: branches/gcc-4_2-branch/gcc/cp/ChangeLog branches/gcc-4_2-branch/gcc/cp/parser.c branches/gcc-4_2-branch/gcc/testsuite/ChangeLog branches/gcc-4_2-branch/gcc/testsuite/g++.dg/parse/tmpl-outside1.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30863
[Bug c++/31273] [4.2/4.3 Regression] Erroneous bitfield conversions to boolean values
--- Comment #7 from mmitchel at gcc dot gnu dot org 2007-03-23 04:31 --- Fixed in 4.2.0. --- Comment #8 from mmitchel at gcc dot gnu dot org 2007-03-23 04:31 --- Subject: Bug 31273 Author: mmitchel Date: Fri Mar 23 04:31:21 2007 New Revision: 123150 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123150 Log: Mark Mitchell <[EMAIL PROTECTED]> PR c++/31273 * call.c (standard_conversion): Use type_decays_to. Keep FCODE consistent with FROM. PR c++/31273 * g++.dg/expr/bitfield7.C: New test. Added: trunk/gcc/testsuite/g++.dg/expr/bitfield7.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c trunk/gcc/testsuite/ChangeLog -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31273
[Bug c++/31273] [4.2/4.3 Regression] Erroneous bitfield conversions to boolean values
--- Comment #7 from mmitchel at gcc dot gnu dot org 2007-03-23 04:31 --- Fixed in 4.2.0. --- Comment #8 from mmitchel at gcc dot gnu dot org 2007-03-23 04:31 --- Subject: Bug 31273 Author: mmitchel Date: Fri Mar 23 04:31:21 2007 New Revision: 123150 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123150 Log: Mark Mitchell <[EMAIL PROTECTED]> PR c++/31273 * call.c (standard_conversion): Use type_decays_to. Keep FCODE consistent with FROM. PR c++/31273 * g++.dg/expr/bitfield7.C: New test. Added: trunk/gcc/testsuite/g++.dg/expr/bitfield7.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c trunk/gcc/testsuite/ChangeLog -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31273
[Bug c++/31273] [4.2/4.3 Regression] Erroneous bitfield conversions to boolean values
--- Comment #6 from mmitchel at gcc dot gnu dot org 2007-03-23 04:26 --- Subject: Bug 31273 Author: mmitchel Date: Fri Mar 23 04:26:13 2007 New Revision: 123149 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123149 Log: Mark Mitchell <[EMAIL PROTECTED]> PR c++/31273 * call.c (standard_conversion): Use type_decays_to. Keep FCODE consistent with FROM. PR c++/31273 * g++.dg/expr/bitfield7.C: New test. Added: branches/gcc-4_2-branch/gcc/testsuite/g++.dg/expr/bitfield7.C Modified: branches/gcc-4_2-branch/gcc/cp/ChangeLog branches/gcc-4_2-branch/gcc/cp/call.c branches/gcc-4_2-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31273
[Bug tree-optimization/31136] [4.2 Regression] FRE ignores bit-field truncation (C and C++ front-end don't produce bit-field truncation
--- Comment #6 from jsm28 at gcc dot gnu dot org 2007-03-23 03:45 --- Analysis: http://gcc.gnu.org/ml/gcc/2007-03/msg00867.html -- jsm28 at gcc dot gnu dot org changed: What|Removed |Added Component|c |tree-optimization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31136
[Bug c++/30982] Junk in diagnostic message
--- Comment #3 from gdr at gcc dot gnu dot org 2007-03-23 03:07 --- http://gcc.gnu.org/ml/gcc-patches/2007-03/msg01513.html -- gdr at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30982
[Bug c++/30982] Junk in diagnostic message
-- gdr at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |gdr at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2007-03-09 04:43:13 |2007-03-23 03:06:57 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30982
[Bug c++/31267] #'typename_type' not supported by dump_decl#
--- Comment #4 from gdr at gcc dot gnu dot org 2007-03-23 03:04 --- ttp://gcc.gnu.org/ml/gcc-patches/2007-03/msg01513.html -- gdr at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31267
[Bug c++/31187] [4.2/4.3 regression] extern declaration of variable in anonymous namespace prevents use of its address as template argument
--- Comment #6 from bangerth at dealii dot org 2007-03-23 03:03 --- (In reply to comment #5) > That's not the case here; the class is in the global namespace. Oh, bummer, of course... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31187
[Bug c++/31187] [4.2/4.3 regression] extern declaration of variable in anonymous namespace prevents use of its address as template argument
--- Comment #5 from mark at codesourcery dot com 2007-03-23 02:44 --- Subject: Re: [4.2/4.3 regression] extern declaration of variable in anonymous namespace prevents use of its address as template argument bangerth at dealii dot org wrote: > --- Comment #4 from bangerth at dealii dot org 2007-03-23 02:37 --- > Without wanting to be a distractor, but can variables of a type that > was declared in an anonymous namespace really have external linkage? That's not the case here; the class is in the global namespace. Only the variable is in the anonymous namespace, and entities in anonymous namespaces do have external linkage. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31187
[Bug c++/31187] [4.2/4.3 regression] extern declaration of variable in anonymous namespace prevents use of its address as template argument
--- Comment #4 from bangerth at dealii dot org 2007-03-23 02:37 --- Without wanting to be a distractor, but can variables of a type that was declared in an anonymous namespace really have external linkage? Think of the type being declared in a header file and one .cc file has the variable declaration/definition and another one an extern declaration for that variable. Do they refer to the same variable? I don't think so -- they have the same name, but distinct types, so we have an ODR violation. IMHO, variables with a type that comes from an anonymous namespace can but have internal linkage. W. -- bangerth at dealii dot org changed: What|Removed |Added CC||bangerth at dealii dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31187
[Bug other/31317] Fatal error when 'make'
--- Comment #2 from bangerth at dealii dot org 2007-03-23 02:29 --- You need to use 'make bootstrap' instead of just 'make'. W. -- bangerth at dealii dot org changed: What|Removed |Added CC||bangerth at dealii dot org Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31317
[Bug c++/31315] internal compiler error on mis-spelled syntax
--- Comment #1 from bangerth at dealii dot org 2007-03-23 02:28 --- You need to post a complete testcase, including all include files etc. I can't reproduce the problem with the snippet you posted. W. -- bangerth at dealii dot org changed: What|Removed |Added CC||bangerth at dealii dot org Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31315
[Bug c++/31273] [4.2/4.3 Regression] Erroneous bitfield conversions to boolean values
--- Comment #5 from mmitchel at gcc dot gnu dot org 2007-03-23 02:16 --- Jim -- I'm going to test your patch, and handle getting it checked in. Thank you for your investigation. -- Mark -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |mark at codesourcery dot com |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31273
[Bug c++/31300] undetected class name clash
--- Comment #7 from bangerth at dealii dot org 2007-03-23 02:13 --- (In reply to comment #4) > I agree , sure it is invalid ,(no mine at the root) but a diagnostic > would be nice It is very hard for a compiler to detect this because it only sees that there is a class 'T'. The compiler would need to know whether the declaration came from a header file that both .cc files include or was truly meant to be a local class. W. -- bangerth at dealii dot org changed: What|Removed |Added CC||bangerth at dealii dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31300
Re: IEEE Math is not working on Alpha Rawhide
[EMAIL PROTECTED] wrote: checking if IEEE math works with the -mieee switch... not isnan(NaN) ... no Check config.log to see what went wrong ... The -mieee option should have worked. You will need to look at the config.log file to see what went wrong. How can I make gcc support IEEE- math on my system? It seems to be a bug, because on Kernel 2.4 I was able to compile the tool. If this worked on a different kernel with the same compiler version, then that indicates a kernel bug. -- Jim Wilson, GNU Tools Support, http://www.specifix.com
[Bug c++/30863] [4.1/4.2/4.3 Regression] Unsigned templatized struct treated as unsigned int
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |mark at codesourcery dot com |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30863
[Bug libstdc++/31117] c++locale.o thread-unsafe in libstdc++
--- Comment #30 from dave at hiauly1 dot hia dot nrc dot ca 2007-03-23 00:56 --- Subject: Re: c++locale.o thread-unsafe in libstdc++ > --- Comment #29 from pcarlini at suse dot de 2007-03-23 00:29 --- > Thanks a lot Craig. Touching _POSIX_C_SOURCE makes me a little nervous, in > particular if that ends up changing _REENTRANT, as happens on HP-UX. I'd like > to ask Dave opinion about it, whether to his best knowledge there is a safe, > minimal way to have a thread-safe errno on HP-UX. Otherwise, probably for now > we have to be contect to fix only SunOS and AIX (with _THREAD_SAFE_ERRNO), all > in all the most important targets these days besides Linux and Darwin. This is how _POSIX_C_SOURCE affects _REENTRANT on 11.11: # if (_POSIX_C_SOURCE >= 199506) && !defined(_REENTRANT) # define _REENTRANT # endif /* _POSIX_C_SOURCE >= 199506 && !_REENTRANT */ In sys/errno.h: # if defined(_REENTRANT) && !defined(_PTHREADS_DRAFT4) /* Get errno definition by including not */ # else /* ! _REENTRANT || _PTHREADS_DRAFT4 */ extern int errno; # endif /* ! _REENTRANT || _PTHREADS_DRAFT4 */ In errno.h, errno is defined as follows when _REENTRANT is defined: # ifdef __cplusplus extern "C" { # endif /* __cplusplus */ #ifdef _PROTOTYPES extern int *__errno(void); #else extern int *__errno(); #endif #define errno (*__errno()) ... Don't see a thread safe implementation in HP-UX 10. I'd be hesitant about using __errno directly. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31117
[Bug c++/30897] [4.1/4.2/4.3 regression] ICE with default argument in template template parameter
--- Comment #2 from mmitchel at gcc dot gnu dot org 2007-03-23 00:50 --- This code in lookup_template_class: - /* Consider an example where a template template parameter declared as - - template > class TT - -The template parameter level of T and U are one level larger than -of TT. To proper process the default argument of U, say when an -instantiation `TT' is seen, we need to build the full -arguments containing {int} as the innermost level. Outer levels, -available when not appearing as default template argument, can be -obtained from `current_template_args ()'. - -Suppose that TT is later substituted with std::vector. The above -instantiation is `TT >' with TT at -level 1, and T at level 2, while the template arguments at level 1 -becomes {std::vector} and the inner level 2 is {int}. */ - - if (current_template_parms) - arglist = add_to_template_args (current_template_args (), arglist); is simply bogus; the current template arguments have nothing to do with the situation. It is this code which causes the crash. I believe that the correct change is to remove that code and to make template parameters for template template parameters restart at level 1. So, in: template class A> class B {}; both T and A have level 1. (Right now, T has level 2.) T should have level 1 because, when instantiating A, that's what make sense. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30897
Re: Bug in g++ 4.1.2 when using inline function definied in cpp file but declared in h file
We don't track bugs reported via email. If you want to make sure you get an answer, use the bugzilla database instead. This doesn't seem to be a gcc bug though. In C++, the inline keyword is similar to what "static inline" means in GNU C, i.e. only emit the function if it is used. Since there is no use of the function in a.cpp, gcc does not emit it. You can see this if you compile a.cpp with -S and look at the assembler output. You can fix this by deleting the use of the inline keyword. Or you can fix it by putting the inline function definition into the a.h file instead of the a.cpp file. This way it will be visible in main.cpp when we call it, and then gcc will emit it. Or you can fix it by using pragma implementation and pragma interface as you discovered. I'm not a C++ expert. There may also be other ways to fix this. -- Jim Wilson, GNU Tools Support, http://www.specifix.com
[Bug libstdc++/31117] c++locale.o thread-unsafe in libstdc++
--- Comment #29 from pcarlini at suse dot de 2007-03-23 00:29 --- Thanks a lot Craig. Touching _POSIX_C_SOURCE makes me a little nervous, in particular if that ends up changing _REENTRANT, as happens on HP-UX. I'd like to ask Dave opinion about it, whether to his best knowledge there is a safe, minimal way to have a thread-safe errno on HP-UX. Otherwise, probably for now we have to be contect to fix only SunOS and AIX (with _THREAD_SAFE_ERRNO), all in all the most important targets these days besides Linux and Darwin. -- pcarlini at suse dot de changed: What|Removed |Added CC||danglin at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31117
[Bug libgcj/31228] Race condition between setting close-on-exec and Runtime.exec()
-- daney at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31228
[Bug libgcj/31228] Race condition between setting close-on-exec and Runtime.exec()
--- Comment #3 from daney at gcc dot gnu dot org 2007-03-23 00:17 --- The committed patch fixes the race. Too bad it had to come to this. -- daney at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31228
[Bug libfortran/31052] Bad IOSTAT values when readings NAMELISTs past EOF
--- Comment #26 from jvdelisle at gcc dot gnu dot org 2007-03-23 00:13 --- Subject: Bug 31052 Author: jvdelisle Date: Fri Mar 23 00:13:19 2007 New Revision: 123139 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123139 Log: 2007-03-22 Jerry DeLisle <[EMAIL PROTECTED]> PR libgfortran/31052 * file_pos.c: Update Copyright year. * io/open.c (test_endfile): Restore test_endfile to fix SPEC regression. Update Copyright year. * io/io.h: Same. * io/unix.c (is_special): Add missing type for this function. Update Copyright year. * io/transfer.c (next_record_r): Restore test_endfile. (st_read): Fix whitespace. Update Copyright year Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/io/file_pos.c trunk/libgfortran/io/io.h trunk/libgfortran/io/open.c trunk/libgfortran/io/transfer.c trunk/libgfortran/io/unix.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31052
[Bug libgcj/31228] Race condition between setting close-on-exec and Runtime.exec()
--- Comment #2 from daney at gcc dot gnu dot org 2007-03-23 00:06 --- Subject: Bug 31228 Author: daney Date: Fri Mar 23 00:06:41 2007 New Revision: 123138 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123138 Log: PR libgcj/31228 * configure.ac: Add checks for getrlimit and sys/resource.h. * include/posix.h (_Jv_platform_close_on_exec): Remove. * include/config.h.in: Regenerate. * configure: Regenerate. * gnu/java/nio/channels/natFileChannelPosix.cc (open): Remove call to _Jv_platform_close_on_exec; * gnu/java/net/natPlainSocketImplPosix.cc (create): Likewise. (accept): Likewise. * gnu/java/net/natPlainDatagramSocketImplPosix.cc (create):Likewise. * java/lang/natPosixProcess.cc: Include sys/resource.h. (nativeSpawn): Close all file descriptors. Don't set FD_CLOEXEC on pipes. Modified: trunk/libjava/ChangeLog trunk/libjava/configure trunk/libjava/configure.ac trunk/libjava/gnu/java/net/natPlainDatagramSocketImplPosix.cc trunk/libjava/gnu/java/net/natPlainSocketImplPosix.cc trunk/libjava/gnu/java/nio/channels/natFileChannelPosix.cc trunk/libjava/include/config.h.in trunk/libjava/include/posix.h trunk/libjava/java/lang/natPosixProcess.cc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31228
[Bug middle-end/31322] [4.3 Regression] ld: Invalid symbol type for plabel (.libs/debug_list.o, __gxx_personality_v0).
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Keywords||build Summary|ld: Invalid symbol type for |[4.3 Regression] ld: Invalid |plabel (.libs/debug_list.o, |symbol type for plabel |__gxx_personality_v0). |(.libs/debug_list.o, ||__gxx_personality_v0). Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31322
[Bug middle-end/31322] New: ld: Invalid symbol type for plabel (.libs/debug_list.o, __gxx_personality_v0).
--enable-languages=c,c++,objc,fortran,ada Thread model: posix gcc version 4.3.0 20070322 (experimental) -bash-2.05b$ cat LAST_UPDATED Wed Mar 21 21:02:45 EDT 2007 Thu Mar 22 01:02:45 UTC 2007 (revision 123123M) Looking at the assembly output for debug_list, I see the following in the EH data: .word P%__gxx_personality_v0 There's no .IMPORT directive for __gxx_personality_v0, so the symbol type defaults to DATA which is wrong. If I was to guess, I suspect that the change that introduced this problem was: 2007-03-19 Mark Mitchell <[EMAIL PROTECTED]> * except.c (output_function_exception_table): Do not reference the EH personality routine for functions that do not require an exception table. -- Summary: ld: Invalid symbol type for plabel (.libs/debug_list.o, __gxx_personality_v0). Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu dot org GCC build triplet: hppa2.0w-hp-hpux11.11 GCC host triplet: hppa2.0w-hp-hpux11.11 GCC target triplet: hppa2.0w-hp-hpux11.11 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31322
[Bug middle-end/26374] Compile failure on long double
--- Comment #12 from pinskia at gcc dot gnu dot org 2007-03-22 23:49 --- *** Bug 31321 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||beebe at math dot utah dot ||edu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26374
[Bug c/31321] gcc fails to compile simple long double initializers
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-03-22 23:49 --- *** This bug has been marked as a duplicate of 26374 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31321
[Bug libstdc++/31117] c++locale.o thread-unsafe in libstdc++
--- Comment #28 from craig dot lawson at centrify dot com 2007-03-22 23:44 --- For HP-UX, SunOS, and Irix: #if !defined(_POSIX_C_SOURCE) # define _POSIX_C_SOURCE 199506L #elif _POSIX_C_SOURCE<199506L # error "Conflict" #endif (why would anyone compile C++ with POSIX < 1995.06?) For AIX, either: #define _THREAD_SAFE or #define _THREAD_SAFE_ERRNO Details: HP-UX 11.00, 11.11, 11.22, 11.23: errno.h: #ifdef _REENTRANT # ifdef _PROTOTYPES extern int *__errno(void); # else extern int *__errno(); # endif ... However, errno.h includes which contains: /* _REENTRANT selects Posix 1c threads unless draft4 selected. * This usage is obsolescent, "-D_POSIX_C_SOURCE=199506" is preferred */ ... #if (_POSIX_C_SOURCE >= 199506) && !defined(_REENTRANT) # define _REENTRANT #endif /* _POSIX_C_SOURCE >= 199506 && !_REENTRANT */ It appears _POSIX_C_SOURCE=199506 is the desired symbol and value, but there will be a conflict if intentionally set to something lower (higher is OK). Confirm using test program: #include int main() { return errno; } Confirmed: -D_POSIX_C_SOURCE=199506 works. SunOS 2.6, 7, 5.8, 5.9, 5.10: errno.h: #if (defined(_REENTRANT) || defined(_TS_ERRNO) || \ _POSIX_C_SOURCE - 0 >= 199506L) && !(defined(lint) || defined(__lint)) Confirmed: -D_POSIX_C_SOURCE=199506 works. AIX 4.3.3, 5.1: errno.h: #include #ifdef _ANSI_C_SOURCE # if defined(_THREAD_SAFE) || defined(_THREAD_SAFE_ERRNO) # define errno (*_Errno()) standards.h: defines _ANSI_C_SOURCE unless overridden by some other model. Confirmed: -D_THREAD_SAFE works. Confirmed: -D_THREAD_SAFE_ERRNO works. AIX 5.2: errno.h: similar to 4.3.3 standards.h: #if defined(_UNIX03) # define _THREAD_SAFE ... #if _XOPEN_SOURCE==600 # define _THREAD_SAFE ... Due to statement ordering in this file, if _POSIX_C_SOURCE==200112L before including this file, then _THREAD_SAFE will be set. Otherwise, this file sets _POSIX_C_SOURCE==200112L and does not set _THREAD_SAFE. Confirmed: -D_THREAD_SAFE works. Confirmed: -D_THREAD_SAFE_ERRNO works. Confirmed: -D_UNIX03 works. Size effect: sets _POSIX_C_SOURCE==200112L Irix 6.5: errno.h: #if defined(_SGI_MP_SOURCE) || (_POSIX_C_SOURCE >= 199506L) \ || (_XOPEN_SOURCE+0 >= 500) extern int *__oserror(void); ... Confirmed: -D_POSIX_C_SOURCE=199506 works. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31117
[Bug c/31321] New: gcc fails to compile simple long double initializers
gcc-4.3-20070316 and gcc-4.2-20070307 both fail to compile this one-line file on Mac OS X 10.4.9 (up to current Apple patch levels): % cat foo.c static const long double X = (27.0L) / (35.0L); % gcc-4.3-20070316 -c foo.c foo.c:1: error: initializer element is not constant If the divisor is changed to 32.0L, it compiles, as does any similar statement where the right-hand side can be evaluated exactly. The compilers were built like this: nice time env LDFLAGS="-L/usr/local/lib" \ ../gcc-4.3-20070316/configure \ --enable-decimal-float \ --enable-languages=c,c++ \ --with-gmp=/usr/local \ --with-mpfr=/usr/local nice time make bootstrap Similar code with float and double initializers compiles without problems. -- Summary: gcc fails to compile simple long double initializers Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: beebe at math dot utah dot edu GCC build triplet: powerpc-apple-darwin8.9.0 GCC host triplet: powerpc-apple-darwin8.9.0 GCC target triplet: powerpc-apple-darwin8.9.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31321
[Bug c++/31187] [4.2/4.3 regression] extern declaration of variable in anonymous namespace prevents use of its address as template argument
--- Comment #3 from mmitchel at gcc dot gnu dot org 2007-03-22 23:34 --- Jason -- This appears to be fallout from your patch for PR c++/28407 and/or c++/28409. Do you have time to take a look? Thanks, -- Mark -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added CC||jason at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31187
[Bug c++/31273] [4.2/4.3 Regression] Erroneous bitfield conversions to boolean values
--- Comment #4 from mmitchel at gcc dot gnu dot org 2007-03-22 23:22 --- Jim -- Your patch is correct. If you would care to test it, it's preapproved for 4.2/4.3. Otherwise, I will take care of it before the 4.2.0 release, as it's certainly my fault. Thanks, -- Mark -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31273
[Bug c++/31260] [4.1/4.2/4.3 Regression] ICE: segmentation fault with template code
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31260
[Bug c++/31187] [4.2/4.3 regression] extern declaration of variable in anonymous namespace prevents use of its address as template argument
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31187
[Bug fortran/31320] New: Illegal read with gfortran.dg/alloc_comp_assign_2.f90 and *_3.f90
gfortran -g gfortran.dg/alloc_comp_assign_2.f90 valgrind ./a.out ==30049== Invalid read of size 1 ==30049==at 0x4C24854: memcpy (in /usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so) ==30049==by 0x401682: MAIN__ (in /projects/tob/gcc/gcc/testsuite/gfortran.dg/a.out) ==30049==by 0x405FAB: main (fmain.c:22) ==30049== Address 0x404D64B is 3 bytes after a block of size 16 alloc'd ==30049==at 0x4C22C56: malloc (in /usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so) ==30049==by 0x4E3DD78: _gfortrani_get_mem (memory.c:53) ==30049==by 0x400A5C: MAIN__ (in /projects/tob/gcc/gcc/testsuite/gfortran.dg/a.out) ==30049==by 0x405FAB: main (fmain.c:22) I checked the example itself with g95 and NAG f95 and both fail at the second, third and fourth "call abort()" whereas ifort has a segv. Is this example (PR 20541) really valid? A check with NAG f95, g95 and ifort with valgrind shows no problem for NAG f95, and invalid reads for g95 and ifort. For alloc_comp_assign_3.f90: Compiles with g95, ifort and NAG f95 and gives no "call abort()", however, gfortran has: ==30454== Invalid read of size 1 ==30454==at 0x4C24854: memcpy (in /usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so) ==30454==by 0x401223: MAIN__ (alloc_comp_assign_3.f90:22) ==30454==by 0x40444B: main (fmain.c:22) ==30454== Address 0x404D64B is 3 bytes after a block of size 16 alloc'd ==30454==at 0x4C22C56: malloc (in /usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so) ==30454==by 0x4E3DD78: _gfortrani_get_mem (memory.c:53) ==30454==by 0x400A5C: MAIN__ (alloc_comp_assign_3.f90:19) ==30454==by 0x40444B: main (fmain.c:22) For alloc_comp_initializer_1.f90 the same. -- Summary: Illegal read with gfortran.dg/alloc_comp_assign_2.f90 and *_3.f90 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: wrong-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=31320
[Bug middle-end/29609] [4.1/4.2/4.3 Regression] Even with -O0 -g gcc optimizes a goto away and I cannot debug
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29609
[Bug middle-end/31150] [4.1/4.2/4.3 Regression] Not promoting an whole array to be static const
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31150
[Bug c/31136] [4.2 Regression] FRE ignores bit-field truncation (C and C++ front-end don't produce bit-field truncation
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31136
[Bug c++/31074] [4.1/4.2/4.3 Regression] Reference casting involving multiple inheritance produces bad pointer
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31074
[Bug other/23572] No warning for assigning a value to a 'float' variable that overflows with option -Wextra
--- Comment #12 from manu at gcc dot gnu dot org 2007-03-22 23:12 --- Fixed for GCC 4.3 -- manu at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23572
[Bug other/23572] No warning for assigning a value to a 'float' variable that overflows with option -Wextra
--- Comment #11 from manu at gcc dot gnu dot org 2007-03-22 23:04 --- Subject: Bug 23572 Author: manu Date: Thu Mar 22 23:04:24 2007 New Revision: 123137 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123137 Log: 2007-03-22 Manuel Lopez-Ibanez <[EMAIL PROTECTED]> PR other/23572 * c-lex.c (interpret_float): On overflow, emit pedantic warning if infinities not supported, otherwise emit warning if -Woverflow. On underflow, emit warning if -Woverflow. * real.c (real_from_string): Return -1 if underflow, +1 if overflow and 0 otherwise. * real.h (real_from_string): Update declaration testsuite/ * gcc.dg/float-range-4.c: New. * gcc.dg/float-range-1.c: Update. Test for a warning. * gcc.dg/float-range-3.c: New. * gcc.dg/float-range-5.c: New. Added: trunk/gcc/testsuite/gcc.dg/float-range-3.c trunk/gcc/testsuite/gcc.dg/float-range-4.c trunk/gcc/testsuite/gcc.dg/float-range-5.c Modified: trunk/gcc/ChangeLog trunk/gcc/c-lex.c trunk/gcc/real.c trunk/gcc/real.h trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/float-range-1.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23572
[Bug fortran/31262] -fno-range-check with large integer values triggers ICE
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-03-22 22:52 --- Fixed on mainline, closing. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31262
[Bug fortran/31262] -fno-range-check with large integer values triggers ICE
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-03-22 22:52 --- Subject: Bug 31262 Author: fxcoudert Date: Thu Mar 22 22:51:50 2007 New Revision: 123136 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123136 Log: PR fortran/31262 * trans-const.c (gfc_conv_mpz_to_tree): Allow integer constants larger than twice the width of a HOST_WIDE_INT. * gfortran.dg/no_range_check_1.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/no_range_check_1.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-const.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31262
[Bug testsuite/25241] DejaGNU does not distinguish between errors and warnings
--- Comment #30 from manu at gcc dot gnu dot org 2007-03-22 22:36 --- There is yet another strange behaviour of the current patch. For the testcase in gcc.dg/array-2.c: struct g g1 = { { 0, { } } }; struct g g2 = { { 0, { 1 } } }; /* { dg-error "(nested context)|(near initialization)" "nested" } */ struct h { int x[0]; int y; }; struct h h1 = { { 0 }, 1 }; /* { dg-error "(excess elements)|(near initialization)" "before end" } */ The output is: gcc.dg/array-2.c:10: error: initialization of flexible array member in a nested context gcc.dg/array-2.c:10: error: (near initialization for 'g2.f.x') gcc.dg/array-2.c:13: warning: excess elements in array initializer gcc.dg/array-2.c:13: warning: (near initialization for 'h1.x') And the test fails as follows: PASS: gcc.dg/array-2.c nested (test for errors, line 10) PASS: gcc.dg/array-2.c before end (test for errors, line 13) FAIL: gcc.dg/array-2.c (test for excess errors) Excess errors: /home/manuel/src/trunk/gcc/testsuite/gcc.dg/array-2.c:13: warning: excess elements in array initializer It seems that the second dg-error matched the wrong line. Perhaps it is getting confused by the alternatives. No idea. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25241
[Bug fortran/29616] Run-time check using nullified pointers and deallocated variables
--- Comment #2 from burnus at gcc dot gnu dot org 2007-03-22 22:32 --- *** Bug 31318 has been marked as a duplicate of this bug. *** -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||vivekrao4 at yahoo dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29616
[Bug fortran/31318] Run-time check for using deallocated variables
--- Comment #1 from burnus at gcc dot gnu dot org 2007-03-22 22:32 --- This is related to 29616 (same for nullified pointers). As the test is essentially the same, I added a comment there and close this PR as duplicate. Thanks for the idea though it will likely take a while until it will be implemented. *** This bug has been marked as a duplicate of 29616 *** -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||burnus at gcc dot gnu dot ||org Status|UNCONFIRMED |RESOLVED Keywords||diagnostic Resolution||DUPLICATE Summary|terminate program when un- |Run-time check for using |allocated array is used |deallocated variables http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31318
[Bug fortran/29616] Run-time check using nullified pointers and deallocated variables
--- Comment #1 from burnus at gcc dot gnu dot org 2007-03-22 22:30 --- Besides pointers, the same is also true for deallocated variables, only that the unknown state does not exist. (Idea taken from 31318) > I think there are essentially two problems possible with pointers: > (a) Uninitialized pointer (i.e. neither NULL nor associated) > (b) Using an unassociated pointer > I think checking (a) is not easily doable as one would need to pass this > status (has been initialized? yes/no) on to subroutines. (a) should be possible if one restricts oneself to restricts oneself to local variables. If they are passed as actual argument to non-pointer (or non-allocatable) dummies, this is also an error. For allocatable variables the checking is always possible. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Summary|Run-time check using|Run-time check using |nullified pointers |nullified pointers and ||deallocated variables http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29616
[Bug fortran/27589] Add compiler flag to check for uninitalized values at runtime
--- Comment #2 from burnus at gcc dot gnu dot org 2007-03-22 22:20 --- There are actually two run-time tests possible: a) Check only local variables (What to do about actual arguments to intent(in) dummy arguments? In the most cases this is wrong, however foo(read_argument=.false.,arg=uninitialized) is possible. Better don't check - or only optionally.) This seems to be done by ifort's -check uninit. b) Checking all calls, i.e. by passing additional information. This is done by NAG f95's -C=undefined. This is more comprehensive, but makes procedures compiled -C=undefined incompatible to those compiled without. Ideally, gfortran should offer both options. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27589
[Bug target/31319] Make big alignment for structs/arrays configurable
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-03-22 21:14 --- I think this has already been fixed for -Os in 4.2.0 or 4.3.0. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31319
[Bug libfortran/31052] Bad IOSTAT values when readings NAMELISTs past EOF
--- Comment #25 from jvdelisle at gcc dot gnu dot org 2007-03-22 20:38 --- Created an attachment (id=13255) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13255&action=view) Untested patch to fix regression on sixtrack This patch reverts portions of the original patch and keeps a minimal set of changes to see if this clears the regression. The patch is against current trunk. If you could please test, I would appreciate. Regression tested on x86-64-Gnu/Linux I do not have a testcase here yet. If this fails, then I will try a further reduction. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31052
[Bug other/31282] SegV on AIX 5.3 due to uninit'ed static object when using -pthread
--- Comment #5 from tom dot culliton at oracle dot com 2007-03-22 20:15 --- That does indeed appear to have been the problem. Even though the system claims that APAR was already applied, the header file was still missing the typedef keyword. I suspect something silly like the compiler being reinstalled after the patch was applied the first time. Many thanks! BTW - This also explains a number of other issues I've seen people report with duplicate symbols for 'thread_creds_t', but this is the only item that search turned up in the bug DB that mentions APAR IY90737. -- tom dot culliton at oracle dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31282
[Bug c/31319] Make big alignment for structs/arrays configurable
--- Comment #1 from vda dot linux at googlemail dot com 2007-03-22 20:07 --- Patch is available here: http://busybox.net/~vda/mbigdata_align.diff I cannot attach patch to this bugzilla entry because I get this: "Internal Error GCC Bugzilla has suffered an internal error. Please save this page and send it to [EMAIL PROTECTED] with details of what you were doing at the time this message appeared. URL: http://gcc.gnu.org/bugzilla/attachment.cgi undef error - Undefined subroutine Fh::slice at data/template/template/en/default/global/hidden-fields.html.tmpl line 58" I already saw this error page ~1 year ago, IIRC. Pity it didn't get more understandable over this time. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31319
[Bug c/31319] New: Make big alignment for structs/arrays configurable
Hi from busybox project. We are concerned about gcc sometimes aligning structs and arrays to 256 bits on i386. We would like to be able to disable it. The proposal is to implement new x86-specific -m option, -mbigdata_align=N. N specifies how big the struct/array should be in order to be "strongly" aligned. Run-tested patch against 4.1.2 is attached. -- Summary: Make big alignment for structs/arrays configurable Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: vda dot linux at googlemail dot com GCC build triplet: i386-pc-linux-gnu GCC host triplet: i386-pc-linux-gnu GCC target triplet: i386-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31319
[Bug other/31317] Fatal error when 'make'
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-03-22 19:40 --- 2.95 is very very old, over 7 years old. Plus only the last three lines of a build failure does not show the problem is. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|blocker |normal Component|c++ |other http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31317
[Bug fortran/31318] New: terminate program when un-allocated array is used
For the illegal code integer, allocatable :: ivec(:) print*,"shape(ivec)=",shape(ivec) end gcc version 4.3.0 20070315 (experimental) gfortran -W -Wall -pedantic-errors -std=f2003 -fbounds-check -Werror xshape_alloc.f90 gives shape(ivec)= 4298784 It would be nice if a run-time error message about the use of array that has not been allocated were emitted. A fairly common mistake I make is to pass an array that is allocatable in the caller, before having allocated it, to a procedure as an argument which is not allocatable. Within the procedure, applying SIZE or SHAPE will give strange results. -- Summary: terminate program when un-allocated array is used Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: vivekrao4 at yahoo dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31318
[Bug c++/31317] New: Fatal error when 'make'
# the system type= Linux localhost.localdomain 2.6.20-1.2925.fc6 #1 SMP Sat Mar 10 18:20:58 EST 2007 i686 i686 i386 GNU/Linux # the options given when GCC was configured/built: /home/jmsimo/gcc/gcc-2.95/configure --prefix=/opt/gcc295 --program-suffix=295 --enable-languages=c,c++ --enable-shared --enable-threads=posix --disable-checking --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions # the complete command line that triggers the bug: make # the compiler output (error messages, warnings, etc.): make[1]: *** [libgcc2.a] Error 1 make[1]: se sale del directorio `/home/jmsimo/gcc/build/gcc' make: *** [all-gcc] Error 2 # the preprocessed file (*.i*) that triggers the bug, generated by adding -save-temps to the complete compilation command, or, in the case of a bug report for the GNAT front end, a complete set of source files (see below): [EMAIL PROTECTED] build]$ make -save-temps make: opción inválida -- a # GNU Make 3.81 # Copyright (C) 2006 Free Software Foundation, Inc. # Este es software libre; consulte en el código fuente las condiciones de copia. # NO hay garantía; ni siquiera para MERCANTIBILIDAD o EL CUMPLIMIENTO DE # ALGÚN PROPÓSITO PARTICULAR. # Este programa fue construido para i686-redhat-linux-gnu Modo de empleo: make [opciones] [objetivo] ... Opciones: -b, -m No se tendrá en cuenta por compatibilidad. -B, --always-make Hace incondicionalmente todos los objetivos. -C DIRECTORIO, --directory=DIRECTORIO Se cambia al DIRECTORIO antes de hacer nada. -d Se imprimirán grandes cantidades de información de depurado. --debug[=BANDERAS]Se imprimirán varios tipos de información de depurado. -e, --environment-overrides Las variables ambientales se imponen a las de los makefiles. -f ARCHIVO, --file=ARCHIVO, --makefile=ARCHIVO Lee al ARCHIVO como un makefile. -h, --help Muestra este mensaje y finaliza. -i, --ignore-errors No se toman en cuenta los errores provenientes de las instrucciones. -I DIRECTORIO, --include-dir=DIRECTORIO Busca dentro del DIRECTORIO los makefiles incluidos. -j [N], --jobs[=N] Se permiten N trabajos a la vez; si no se especifica un argumento son infinitos. -k, --keep-goingSigue avanzando aún cuando no se puedan crear algunos objetivos. -l [N], --load-average[=N], --max-load[=N] No inicia con trabajos múltiples a menos que la carga esté por debajo de N. -L, --check-symlink-times Utiliza el último mtime entre los enlaces simbólicos y los objetivos. -n, --just-print, --dry-run, --recon No ejecuta ninguna instrucción; sólo las muestra. -o ARCHIVO, --old-file=ARCHIVO, --assume-old=ARCHIVO Supone que ARCHIVO es muy viejo y no lo reconstruye. -p, --print-data-base Se imprime la base de datos interna de `make'. -q, --question No se ejecutan las instrucciones; el estado de salida indicará si están actualizados. -r, --no-builtin-rules Se deshabilitan las reglas implícitas almacenadas internamente. -R, --no-builtin-variables Se deshabilitan los ajustes a las variables almacenadas internamente. -s, --silent, --quiet No muestra las intrucciones. -S, --no-keep-going, --stop Desactiva la opción -k. -t, --touch Se tocan los objetivos en vez de reconstruirlos. -v, --version Muestra la versión del make y finaliza. -w, --print-directory Muestra el directorio actual. --no-print-directoryDesactiva -w, aún cuando haya sido activado implícitamente. -W ARCHIVO, --what-if=ARCHIVO, --new-file=ARCHIVO, --assume-new=ARCHIVO Supone que ARCHIVO es infinitamente reciente. --warn-undefined-variables Advierte cuando se hace una referencia a una variable no definida. Este programa fue construido para i686-redhat-linux-gnu Informe sobre los errores a # Base de datos del Make, mostrada en Thu Mar 22 19:57:01 2007 # Variables # entorno DESKTOP_SESSION = default # entorno GTK_RC_FILES = /etc/gtk/gtkrc:/home/jmsimo/.gtkrc-1.2-gnome2 # entorno DESKTOP_STARTUP_ID = # entorno XAUTHORITY = /tmp/.gdmMQTKPT # entorno GDMSESSION = default # entorno XMODIFIERS = @im=none # entorno SHELL = /bin/bash # entorno _ = /usr/bin/make # entorno USERNAME = jmsimo # entorno DBUS_SESSION_BUS_ADDRESS = unix:abstract=/tmp/dbus-6tmNqzM01c,guid=4b3ceaa35c44e1492ecde9004602c275 # entorno GNOME_KEYRING_SOCKET = /tmp/keyring-kFGit0/socket # entorno LESSOPEN = |/usr/bin/lesspipe.sh %s # entorno PATH = /usr/kerberos/bin:/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/home/jmsimo/bin # entorno SESSION_MANAGER = local/localhost.localdomain:/tmp/.ICE-unix/2703 # entorno WINDOWID = 56623185 # entorno GDM_XSERVER_LOCATION = local # por defecto .FEATURES := target-specific order-only s
[Bug fortran/31193] ICE on non-constant character tranfert
--- Comment #4 from pault at gcc dot gnu dot org 2007-03-22 18:37 --- Subject: Bug 31193 Author: pault Date: Thu Mar 22 18:37:16 2007 New Revision: 123131 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123131 Log: 2006-03-22 Paul Thomas <[EMAIL PROTECTED]> PR fortran/31193 * trans-intrinsic.c (gfc_size_in_bytes): Remove function. (gfc_conv_intrinsic_array_transfer): Remove calls to previous. Explicitly extract TREE_TYPEs for source and mold. Use these to calculate length of source and mold, except for characters, where the se string_length is used. For mold, the TREE_TYPE is recalculated using gfc_get_character_type_len so that the result is correctly cast for character literals and substrings. Do not use gfc_typenode_for_spec for the final cast. 2006-03-22 Paul Thomas <[EMAIL PROTECTED]> PR fortran/31193 * gfortran.dg/transfer_array_intrinsic_3.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/transfer_array_intrinsic_3.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-intrinsic.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31193
[Bug driver/31316] New: driver specifies output file twice when compiling header with -S
[EMAIL PROTECTED]:~/gcc/trunk/gcc/tmp/gcc$ ./xgcc -B. t.h -S -v Reading specs from ./specs Target: i686-pc-linux-gnu Configured with: ../configure --enable-languages=c++ --disable-nls Thread model: posix gcc version 4.3.0 20070322 (experimental) ./cc1 -quiet -v -iprefix /home/ryan/gcc/trunk/gcc/tmp/gcc/../lib/gcc/i686-pc-linux-gnu/4.3.0/ -isystem ./include -isystem ./include-fixed t.h -quiet -dumpbase t.h -mtune=generic -auxbase t -version -o t.s -o /tmp/ccs9IVOl.s --output-pch=t.h.gch cc1: error: output filename specified twice -- Summary: driver specifies output file twice when compiling header with -S Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: driver AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rmansfield at qnx dot com GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31316
[Bug c++/31315] New: internal compiler error on mis-spelled syntax
I tried to compile the following code, but I got "internal compiler error: in lookup_member, at cp/search.c:1288" from g++. v.reserve(10); v.push_back(1); v.push_back(2); copy( v.begin() , v.end(). ostream_iterator(cout, "\n") ); P.S. the correct code should have "," after v.end(). not "." -- Summary: internal compiler error on mis-spelled syntax Product: gcc Version: 3.4.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ahmadyan at gmail dot com GCC build triplet: 3.4.2 release http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31315
[Bug c++/31314] Segmentation fault when assign std::string to another std::string when using std::vector and inheritance
--- Comment #3 from wmacura at gmail dot com 2007-03-22 16:46 --- Subject: Re: Segmentation fault when assign std::string to another std::string when using std::vector and inheritance :-o Damn. Construct() was a static function for a while and I didn't notice this when I started butchering the code. Thanks. Wiktor On 22 Mar 2007 16:34:01 -, pinskia at gcc dot gnu dot org <[EMAIL PROTECTED]> wrote: > > > --- Comment #2 from pinskia at gcc dot gnu dot org 2007-03-22 16:34 > --- > The problem is with: > Row r = r.construct(rawdata.at(i)); > > > You are using r before it is constructored. > > This is not a bug in GCC but in your code. > > > -- > > pinskia at gcc dot gnu dot org changed: > >What|Removed |Added > > Status|UNCONFIRMED |RESOLVED > Resolution||INVALID > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31314 > > --- You are receiving this mail because: --- > You reported the bug, or are watching the reporter. > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31314
[Bug c++/31314] Segmentation fault when assign std::string to another std::string when using std::vector and inheritance
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-03-22 16:34 --- The problem is with: Row r = r.construct(rawdata.at(i)); You are using r before it is constructored. This is not a bug in GCC but in your code. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31314
[Bug target/30980] [4.3 Regression] Recent complex miscompilation
--- Comment #15 from dominiq at lps dot ens dot fr 2007-03-22 16:22 --- Note that the drawback of the optimization replacing sin+cos by cexpi on PPC Darwin has been dissected in PR31249. In comment #16, I proposed a patch. Before applying it, it would be nice to test if the other platforms affected by this bug are also affected by the bad optimization and if the patch does not cause timing regressions on platforms for which the optimization is working (mostly Linux). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30980
[Bug c++/31314] Segmentation fault when assign std::string to another std::string when using std::vector and inheritance
--- Comment #1 from wmacura at gmail dot com 2007-03-22 15:58 --- Created an attachment (id=13252) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13252&action=view) Testcase (seg at line 130) Build instruction: g++ -g stringtest.cpp -o stringtest -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31314
[Bug c++/31314] New: Segmentation fault when assign std::string to another std::string when using std::vector and inheritance
Short version: Assigning an index from a vector to a local string works. Assigning to a private class member of type string fails with a segmentation fault apparently caused by a delete[]. I've managed to simplify the test case quite substantially for this bug, but its still quite convoluted. For this I apologize. Long version: Here's a summary of the example: its supposed to be a framework for implementing model-view-controller type applications in C++. The code is a foundation for a GTKmm application. We have the Database:: interface which is implemented by Sqlite::. Each model inherits from the Model:: base class which is modeled very loosely on the ActiveRecord system in Ruby-on-Rails. The User:: class is a model. Queries on the database are run through Database::exec() which really is Sqlite::exec(). The findall() function called in main() is purportedly part of User:: but actually implemented in Model::. Now, for the bug. The example causes a SIGSEGV in User::findall() (ie. Model::findall()). But the shocker is where it happens: line 130 in the example. We've run Sqlite::exec(), and gotten a vector of strings. We can also loop over the vector and print each string. I have no idea why this bug occurs in this specific code. The only thing remotely unusual is the inheritance pattern (ie. class User: public Model {} ), but that's not particularly bizarre either. -- Summary: Segmentation fault when assign std::string to another std::string when using std::vector and inheritance Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: wmacura at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31314
[Bug c++/31309] g++ 4.2.0 amd64 codegen issue with -O0. 6 byte assignment at end of structure reads/writes past end of structure causing SEGV when that memory is not accessable.
--- Comment #3 from taavib at ca dot ibm dot com 2007-03-22 15:49 --- Thanks for figuring out how to reproduce this standalone, Peeter! -- taavib at ca dot ibm dot com changed: What|Removed |Added CC||taavib at ca dot ibm dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31309
[Bug fortran/20897] derived type name shall not be same as intrinsic type name
-- tobi at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20897
[Bug fortran/20897] derived type name shall not be same as intrinsic type name
--- Comment #5 from tobi at gcc dot gnu dot org 2007-03-22 15:39 --- Fixed on the mainline. -- tobi at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20897
[Bug fortran/20897] derived type name shall not be same as intrinsic type name
--- Comment #4 from tobi at gcc dot gnu dot org 2007-03-22 15:37 --- Subject: Bug 20897 Author: tobi Date: Thu Mar 22 15:37:25 2007 New Revision: 123129 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123129 Log: PR fortran/20897 fortran/ * decl.c (gfc_match_derived_decl): Reliably reject 'doubleprecision' and 'doublecomplex' as type names. testsuite/ * gfortran.dg/derived_name_1.f90: New. * gfortran.dg/derived_name_2.f: New. Added: trunk/gcc/testsuite/gfortran.dg/derived_name_1.f90 trunk/gcc/testsuite/gfortran.dg/derived_name_2.f Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20897
[Bug c++/31267] #'typename_type' not supported by dump_decl#
--- Comment #3 from gdr at cs dot tamu dot edu 2007-03-22 15:29 --- Subject: Re: #'typename_type' not supported by dump_decl# "guillaume dot melquiond at ens-lyon dot fr" <[EMAIL PROTECTED]> writes: | I just encountered another instance of a missing typename diagnostic. This time | with a different message, so I add it here for completeness: | | a.cpp:5: error: dependent-name ÂT::#Âtypename_type not supported by | pp_cxx_unqualified_id#::D is parsed as a non-type, but instantiation yields a | type | a.cpp:5: note: say Âtypename T::#Âtypename_type not supported by | pp_cxx_unqualified_id#::D if a type is meant I have a fix for this one. It is not the same issue as your original report. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31267
[Bug fortran/31310] gfortran is missing -fcase-preserve option
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|minor |enhancement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31310
[Bug tree-optimization/31313] consecutive strcmps are not merged
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement Component|rtl-optimization|tree-optimization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31313
[Bug fortran/31299] I can produce the bug without using nohup
--- Comment #11 from pinskia at gcc dot gnu dot org 2007-03-22 15:19 --- I say GETLOG should have the same behavior as getlogin which is what this behavior is comming from. Considering the documentation says: On systems where the getlogin(3) function is not implemented, this will return a blank string. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31299
[Bug rtl-optimization/31313] New: consecutive strcmps are not merged
I just ran into some code which did something like int strcmp(const char *, const char *); int f (const char *c) { return (strcmp (c, "aaa") == 0 || strcmp (c, "aab") == 0); } It would be possible to optimize this into something like (hopefully I get it right) int f (const char *c) { if (strncmp (c, "aa", 2)) return 0; return ((c[2] == 'a' || c[2] == 'b') && !c[3]); } Instead, we scan through the whole string twice, as can be seen in the assembly. Likewise, more complicated combinations of comparisons could be reduced into an optimal matching sequence. Putting this into component rtl-optimization, because the strcmp calls survive all of the tree optimizers unchanged. -- Summary: consecutive strcmps are not merged Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tobi at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31313
[Bug fortran/20897] derived type name shall not be same as intrinsic type name
--- Comment #3 from tobi at gcc dot gnu dot org 2007-03-22 14:36 --- I'm testing a very simple fix. -- tobi at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |tobi at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2005-12-30 19:45:20 |2007-03-22 14:36:26 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20897
[Bug libfortran/31052] Bad IOSTAT values when readings NAMELISTs past EOF
--- Comment #24 from jv244 at cam dot ac dot uk 2007-03-22 13:54 --- there is only one file on the web that matches: 'C READ IN HORIZONTAL AND VERTICAL MISALIGNMENT AND TILT' http://mad.home.cern.ch/frs/Source/DA/six.f -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31052
[Bug fortran/31299] I can produce the bug without using nohup
--- Comment #10 from michael dot a dot richmond at nasa dot gov 2007-03-22 13:53 --- Several commenters believe the problem is with nohup rather than gfortran. I can produce the bug without using nohup. I redirect the input to a file: gfortran test_getlog.f90 ./a.out http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31299
[Bug ada/31174] [4.2 regression] ACATS C380004 fails
-- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|ebotcazou at gcc dot gnu dot|unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31174
[Bug ada/31108] [4.2 regression] ACATS C35507M fails
-- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-03-22 13:31:41 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31108
[Bug fortran/31193] ICE on non-constant character tranfert
--- Comment #3 from patchapp at dberlin dot org 2007-03-22 13:30 --- Subject: Bug number PR31193 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-03/msg01465.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31193
[Bug ada/31108] [4.2 regression] ACATS C35507M fails
--- Comment #5 from ebotcazou at gcc dot gnu dot org 2007-03-22 13:31 --- > Should I post a separate bug report for C380004? It's PR ada/31174. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31108
[Bug ada/31108] [4.2 regression] ACATS C35507M fails
--- Comment #4 from rolf dot ebert dot gcc at gmx dot de 2007-03-22 13:07 --- I rebuilt gcc-4.2.0 RC1 as of 2007-03-16 yesterday on Windows XP/MinGW and could completely run the ACATS tests (no GNAT tests due to missing expect on my Windows). Only the two tests C5507M and C380004 failed. I had to manually kill C974012 after it had already printed its PASSED message. Should I post a separate bug report for C380004? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31108
[Bug fortran/31310] gfortran is missing -fcase-preserve option
--- Comment #1 from burnus at gcc dot gnu dot org 2007-03-22 13:05 --- > Or a workaround / new method for mixed case functions calls from gfortran > to C. In the Fortran-Experiments branch exists support for C bindings: subroutine fortranname bind(C,name='C_Name') (Planned to be included in GCC/gfortran 4.3 rather soon.) g77 has a huge number (~20) of case options, cf. http://gcc.gnu.org/onlinedocs/gcc-3.4.6/g77/Fortran-Dialect-Options.html#index-g_t_002dfintrin_002dcase_002dinitcap-option-237 In gfortran's invoke.texi: "For example, with @option{-funderscoring}, and assuming other defaults like @option{-fcase-lower} and that @code{j()} and @code{max_count()} are external functions while @code{my_var} and @code{lvar} are local variables, a statement like" -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||burnus at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31310
[Bug fortran/31310] New: gfortran is missing -fcase-preserve option
using gcc version 4.3.0 20070315 (experimental) The -fcase options are not in gfortran as they were in g77. Specifically -fcase-preserve. This makes it very hard to link to pre-compiled C libraries that have mixed case function names. compile line and error message C:\sha>gfortran -c sha.f90 -fcase-preserve f951.exe: error: unrecognized command line option "-fcase-preserve" There is mention of -fcase-lower in the gfortran .pdf manual but it doesn't exist either. The addition of this g77 option to gfortran would be appreciated. Or a workaround / new method for mixed case functions calls from gfortran to C. -- Summary: gfortran is missing -fcase-preserve option Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mralanmorgan at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31310
[Bug c++/31309] g++ 4.2.0 amd64 codegen issue with -O0. 6 byte assignment at end of structure reads/writes past end of structure causing SEGV when that memory is not accessable.
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-03-22 10:03 --- Confirmed. The program segfaults also with -fno-inline -O[12] and we create very interesting code for XXX::Initialize: _ZN3XXX10InitializeEi: .LFB4: movq(%rdi), %rax movslq %esi,%rsi pushq %rbx .LCFI0: movq(%rax,%rsi,8), %rbx movb$0, 8(%rbx) movb$0, 9(%rbx) call_Z17INIT_6_BYTES_ZEROv movq10(%rbx), %rdx movzbl %al, %esi movzbl %ah, %ecx xorb%dl, %dl orq %rsi, %rdx movq%rax, %rsi movb%cl, %dh movq%rax, %rcx andl$4278190080, %esi andl$16711680, %ecx andq$-16711681, %rdx orq %rcx, %rdx movabsq $-4278190081, %rcx andq%rcx, %rdx movabsq $1095216660480, %rcx orq %rsi, %rdx movq%rax, %rsi andq%rcx, %rsi movabsq $-1095216660481, %rcx andq%rcx, %rdx movabsq $280375465082880, %rcx andq%rcx, %rax orq %rsi, %rdx movabsq $-280375465082881, %rcx andq%rcx, %rdx orq %rax, %rdx movq%rdx, 10(%rbx) popq%rbx ret -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-03-22 10:03:14 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31309
[Bug fortran/31299] Use getpwuid(geteuid()) instead of getlogin() for GETLOG()
--- Comment #9 from burnus at gcc dot gnu dot org 2007-03-22 09:36 --- Bob Proulx wrote at bugs-coreutils@ > Regardless of that I think it would be better if the program calling > getlogin() avoided using it since using the utmp file for this > accounting is often a source of troublesome errors. The login user is > rarely the right answer. Usually the current effective id provided by > getpwuid(geteuid()) would be better. I expect that use of getlogin() > in the original case that motivated this example is actually a bug by > itself. Thus: We should consider using getpwuid(geteuid()) which is also what g95 does, maybe guarded by "#ifdef" (or maybe not, both are part of IEEE 1003.1-2001/POSIX): #include struct passwd *getpwuid(uid_t uid); and #include uid_t geteuid(void); (I somehow missed initially the clause "getlogin() function shall return a pointer to a string containing the user name associated by the login activity with the *controlling terminal* of the current process.") One should probably also update the manual together with this change?!? -- burnus at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement Status|RESOLVED|UNCONFIRMED Resolution|WONTFIX | Summary|getlog returns blanks when |Use getpwuid(geteuid()) |not run from the command|instead of getlogin() for |prompt |GETLOG() http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31299