[Bug middle-end/37742] [4.4 Regression] ICE in vectorizer with restrict pointer
--- Comment #16 from reichelt at gcc dot gnu dot org 2008-11-11 08:12 --- The testcase in comment #7 (and the original code in comment #4) still crashes. -- reichelt at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37742
[Bug tree-optimization/38079] gcc segfaults when using -ftree-vectorizer-verbose=9
--- Comment #2 from irar at il dot ibm dot com 2008-11-11 09:24 ---
I am testing the following:
Index: tree-vect-analyze.c
===
--- tree-vect-analyze.c (revision 141763)
+++ tree-vect-analyze.c (working copy)
@@ -3314,8 +3314,8 @@ vect_analyze_data_refs (loop_vec_info lo
if (vect_print_dump_info (REPORT_DETAILS))
{
- fprintf (dump_file, analyze in outer-loop: );
- print_generic_expr (dump_file, inner_base, TDF_SLIM);
+ fprintf (vect_dump, analyze in outer-loop: );
+ print_generic_expr (vect_dump, inner_base, TDF_SLIM);
}
outer_base = get_inner_reference (inner_base, pbitsize, pbitpos,
@@ -3325,7 +3325,7 @@ vect_analyze_data_refs (loop_vec_info lo
if (pbitpos % BITS_PER_UNIT != 0)
{
if (vect_print_dump_info (REPORT_DETAILS))
- fprintf (dump_file, failed: bit offset alignment.\n);
+ fprintf (vect_dump, failed: bit offset alignment.\n);
return false;
}
@@ -,7 +,7 @@ vect_analyze_data_refs (loop_vec_info lo
if (!simple_iv (loop, stmt, outer_base, base_iv, false))
{
if (vect_print_dump_info (REPORT_DETAILS))
- fprintf (dump_file, failed: evolution of base is not
affine.\n);
+ fprintf (vect_dump, failed: evolution of base is not
affine.\n);
return false;
}
@@ -3353,7 +3353,7 @@ vect_analyze_data_refs (loop_vec_info lo
else if (!simple_iv (loop, stmt, poffset, offset_iv, false))
{
if (vect_print_dump_info (REPORT_DETAILS))
- fprintf (dump_file, evolution of offset is not affine.\n);
+ fprintf (vect_dump, evolution of offset is not affine.\n);
return false;
}
@@ -3376,18 +3376,18 @@ vect_analyze_data_refs (loop_vec_info lo
STMT_VINFO_DR_ALIGNED_TO (stmt_info) =
size_int (highest_pow2_factor
(offset_iv.base));
- if (dump_file (dump_flags TDF_DETAILS))
+ if (vect_dump (dump_flags TDF_DETAILS))
{
- fprintf (dump_file, \touter base_address: );
- print_generic_expr (dump_file, STMT_VINFO_DR_BASE_ADDRESS
(stmt_info), TDF_SLIM);
- fprintf (dump_file, \n\touter offset from base address: );
- print_generic_expr (dump_file, STMT_VINFO_DR_OFFSET (stmt_info),
TDF_SLIM);
- fprintf (dump_file, \n\touter constant offset from base address:
);
- print_generic_expr (dump_file, STMT_VINFO_DR_INIT (stmt_info),
TDF_SLIM);
- fprintf (dump_file, \n\touter step: );
- print_generic_expr (dump_file, STMT_VINFO_DR_STEP (stmt_info),
TDF_SLIM);
- fprintf (dump_file, \n\touter aligned to: );
- print_generic_expr (dump_file, STMT_VINFO_DR_ALIGNED_TO
(stmt_info), TDF_SLIM);
+ fprintf (vect_dump, \touter base_address: );
+ print_generic_expr (vect_dump, STMT_VINFO_DR_BASE_ADDRESS
(stmt_info), TDF_SLIM);
+ fprintf (vect_dump, \n\touter offset from base address: );
+ print_generic_expr (vect_dump, STMT_VINFO_DR_OFFSET (stmt_info),
TDF_SLIM);
+ fprintf (vect_dump, \n\touter constant offset from base address:
);
+ print_generic_expr (vect_dump, STMT_VINFO_DR_INIT (stmt_info),
TDF_SLIM);
+ fprintf (vect_dump, \n\touter step: );
+ print_generic_expr (vect_dump, STMT_VINFO_DR_STEP (stmt_info),
TDF_SLIM);
+ fprintf (vect_dump, \n\touter aligned to: );
+ print_generic_expr (vect_dump, STMT_VINFO_DR_ALIGNED_TO
(stmt_info), TDF_SLIM);
}
}
--
irar at il dot ibm dot com changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |irar at il dot ibm dot com
|dot org |
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2008-11-11 09:24:41
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38079
Out of Office AutoReply: Сувенирная продукция с вашим логотипом
Thank you for your message, I'm out on business on Nov 10 till the 14.Nov.08. For urgent questions,please, contact Maxim Rozymniy 4321 or Maxim Pavelchuk*4253 in case of emergency you can reach me on my mobile +38 050 382 13 52. I'll read all e-mails addressed to me as soon as it possible.
[Bug target/35366] [4.4 Regression] gfortran.dg/equiv_7.f90 fails with -m64 -Os on powerpc-apple-darwin9
--- Comment #2 from jakub at gcc dot gnu dot org 2008-11-11 11:27 --- Testing a patch (well, two). -- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-11-11 11:27:04 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35366
[Bug libstdc++/37986] std::tr1::variate_generator does not conform to TR1.
--- Comment #1 from paolo dot carlini at oracle dot com 2008-11-11 12:20 --- Note: given the status of TR1 as a step toward C++1x, at this time this is not an high priority issue, sorry. -- paolo dot carlini at oracle dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |paolo dot carlini at oracle |dot org |dot com Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-11-11 12:20:37 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37986
[Bug fortran/38082] string truncated on return from subroutine (calling mkdtemp bind(c))
--- Comment #1 from holst at matmech dot com 2008-11-11 13:29 --- Created an attachment (id=16651) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16651action=view) callbug.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38082
[Bug fortran/38065] private/public confusion with a contained function
--- Comment #11 from clerman at fuse dot net 2008-11-11 14:35 --- Subject: Re: private/public confusion with a contained function Hello, Thank you for responding so promptly. Yes, I see what's going on now. It wasn't apparent to me that my function CreateLine was incorrectly acquiring the ''public' attribute. This explains why I could not reduce the problem as you have. Norm Clerman jv244 at cam dot ac dot uk [EMAIL PROTECTED] wrote: --- Comment #8 from jv244 at cam dot ac dot uk 2008-11-11 14:14 --- (In reply to comment #7) As best I can see, your reduction of the problem is not correct; in it subroutine S1 should be private, not public. I don't think so. See your code, S1 ~ GeomMTF, which is public. The problem is the contained function F1 (your CreateLine), which incorrectly gets a 'public' attribute. Note that the same, incorrect error message is displayed for this testcase. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38065 --- You are receiving this mail because: --- You reported the bug, or are watching the reporter. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38065
[Bug libstdc++/37986] std::tr1::variate_generator does not conform to TR1.
--- Comment #4 from paolo dot carlini at oracle dot com 2008-11-11 14:56 --- Not completely fixed yet... -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37986
[Bug rtl-optimization/37514] [4.4 Regression] Wrong code generated for 20021120-1.c with -O3 -fomit-frame-pointer on sh4
--- Comment #6 from vmakarov at redhat dot com 2008-11-11 15:22 --- Sorry, Kaz. I missed this PR. I've just found it after Bernd's email. I don't think it is a right solution or stable workaround. In fact all pseudos (551, 289, 288) involved in 2 wrong insns got different stack slots. It might be IRA triggered some latent bug in reload inheritence. Reload decided that r2 contains value of 551 (gf+4) but it contains gf+0 (pseudo 434 which died in prev insn 828). I'll look at this problem but taking reload complexity into account it will take a few days. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37514
[Bug testsuite/37202] FAIL: gcc.dg/visibility-1[4-9].c
--- Comment #12 from howarth at nitro dot med dot uc dot edu 2008-11-11 15:33 --- Posted patch to gcc-patches mailing list... http://gcc.gnu.org/ml/gcc-patches/2008-11/msg00428.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37202
[Bug fortran/36463] [4.4 regression] gfc_get_default_type(): Bad symbol
--- Comment #14 from mikael at gcc dot gnu dot org 2008-11-11 15:36 --- (In reply to comment #13) x is not marked as referenced, and read_cleanup makes a symtree for it with that name @0 from gfc_get_unique_symtree. This behavior seems expected in some cases, maybe it is here as well, or maybe not. The comment at the beginning of module.c mentions hidden symbols for which the above applies, but I don't know what they are. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36463
[Bug c++/34269] [4.2/4.3/4.4 regression] Incomplete __decltype/__typeof expressions accepted
--- Comment #4 from jakub at gcc dot gnu dot org 2008-11-11 15:42 --- The joys (well, lack thereof) of tentative parsing. No errors are reported because cp_parser_decl_specifier_seq (and its caller cp_parser_simple_declaration) is called during tentative parsing. cp_parser_decl_specifier_seq returns error_mark_node type, but any_specifiers_p is set, so cp_parser_simple_declaration calls: 8172 /* If we have seen at least one decl-specifier, and the next token 8173 is not a parenthesis, then we must be looking at a declaration. 8174 (After int ( we might be looking at a functional cast.) */ 8175 if (decl_specifiers.any_specifiers_p 8176 cp_lexer_next_token_is_not (parser-lexer, CPP_OPEN_PAREN) 8177 cp_lexer_next_token_is_not (parser-lexer, CPP_OPEN_BRACE)) 8178cp_parser_commit_to_tentative_parse (parser); Type being error_mark_node generally means that routines assume that error has been reported already, so nothing is diagnosed afterwards. Mark, how should this be fixed up? If cp_parser_decltype (and cp_parser_simple_type_specifier) knew one of the callers is going to call cp_parser_commit_to_tentative_parse, it could cp_parser_commit_to_tentative_parse first and let all the errors be reported right away. But I doubt it can. Another possibility would be add support for queing error messages during tentative parsing and at cp_parser_commit_to_tentative_parse emit them. -- jakub at gcc dot gnu dot org changed: What|Removed |Added CC||mmitchel at gcc dot gnu dot ||org, jason at gcc dot gnu ||dot org, dodji at gcc dot ||gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34269
[Bug fortran/38066] bug6 ambiguous reference
--- Comment #3 from clerman at fuse dot net 2008-11-11 16:07 --- Subject: Re: bug6 ambiguous reference Hello again, Thank you for writing. As I mentioned in my original bug report, I created this particular bug from my lens design program, which, as you know, contains much more code. I thought I had correctly reproduced it, but I did not check it on some other compilers. Obviously I should have. I will go back to my lens design program. I will recreate the bug I am seeing and proceed from there. Once I do, should I submit a new bug report, if necessary, or should I append this existing one? Thank you very much for your assistance. Yours truly, Norm Clerman burnus at gcc dot gnu dot org [EMAIL PROTECTED] wrote: --- Comment #2 from burnus at gcc dot gnu dot org 2008-11-11 15:25 --- Error: Name 'getnullset' at (1) is an ambiguous reference to 'getnullset' from module 'pbit4set' I have not yet checked the source, but other compilers give similar errors: * NAG f95: Error: bug6M.f90, line 17: Symbol GETNULLSET found both in module PBIT4SET and in PBIT8SET detected at [EMAIL PROTECTED] Error: bug6M.f90, line 17: Symbol GETNULLSET found both in module PBIT4SET and in PBIT8SET detected at [EMAIL PROTECTED] * g95: In file bug6M.f90:22 END MODULE Bug6 1 Error: Name 'getnullset' at (1) is an ambiguous reference to 'getnullset' from module 'pbit4set' * ifort: bug6M.f90(17): error #6405: The same named entity from different modules and/or program units cannot be referenced. [GETNULLSET] CALL GetNullSet (search_set) * openf95: openf95-486 openf95: ERROR SUB_A, File = bug6M.f90, Line = 17, Column = 12 GETNULLSET has been use associated from module PBIT4SET and at least one more module. It must not be referenced. The NAG, Intel and g95 compilers all compile this code. Hmm, not here! You have in bug6M.f90: USE PBit4Set USE PBit8Set That makes the following two getNullSet available: pure subroutine getNullSet (ANullSet) ! In pbit4setM.f90 type (TPBit4Set), intent(out) :: ANullSet pure subroutine getNullSet (ANullSet) ! In pbit8setM.f90 type (TPBit8Set), intent(out) :: ANullSet If you now call getNullSet you have a problem since getNullSet exists in both PBit4Set and PBit8Set. (Note: getNullSet is *not* a generic interface.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38066 --- You are receiving this mail because: --- You reported the bug, or are watching the reporter. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38066
[Bug middle-end/38083] New: [graphite] ICE: in verify_loop_structure, at cfgloop.c:1569
gfortran -O2 -floop-block test.f90 test.f90: In function 'ivsort': test.f90:1: error: edge from 7 to 12 should be marked irreducible test.f90:1: error: basic block 12 should be marked irreducible test.f90:1: internal compiler error: in verify_loop_structure, at cfgloop.c:1569 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. This was tested on the graphite branch. The reduced testcase is attached for the same bug. -Mitul Thakkar. -- Summary: [graphite] ICE: in verify_loop_structure, at cfgloop.c:1569 Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mitul dot thakkar at amd dot com GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38083
[Bug middle-end/38083] [graphite] ICE: in verify_loop_structure, at cfgloop.c:1569
--- Comment #1 from mitul dot thakkar at amd dot com 2008-11-11 16:30 --- Created an attachment (id=16653) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16653action=view) Reduced Test Case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38083
[Bug fortran/38082] string truncated on return from subroutine (calling mkdtemp bind(c))
--- Comment #2 from burnus at gcc dot gnu dot org 2008-11-11 13:53 --- Hmm, I cannot reproduce it using: 4.3.3 20081002 (prerelease) [gcc-4_3-branch revision 140831] (SUSE Linux) 4.3.3 2008 (prerelease) [gcc-4_3-branch revision 138185] (GCC) 4.4.0 2008 (experimental) [trunk revision 141763] (GCC) You could try whether a newer build fixes the problem, http://gcc.gnu.org/wiki/GFortranBinaries -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38082
[Bug libstdc++/38081] time_get::do_get_weekday does not always recognize full names of weekdays
--- Comment #1 from tsyvarev at ispras dot ru 2008-11-11 13:41 --- Created an attachment (id=16652) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16652action=view) Reproduce bug with recognition of name of weekday This test require locale ru_RU.iso88595 is installed. [EMAIL PROTECTED]:/mnt/hgfs/shared/temp/test$ g++ test.cpp ./a.out t.tm_wday becomes 1, expected 1 t.tm_wday becomes -1, expected 1 t.tm_wday becomes 1, expected -1 In Russian locale every abbriviated name of month is always a prefix of full name, so conclusion about do_get_monthname() is done only according its code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38081
[Bug fortran/38065] private/public confusion with a contained function
--- Comment #6 from jv244 at cam dot ac dot uk 2008-11-11 13:28 --- reduced: MODULE M1 IMPLICIT NONE PRIVATE TYPE T1 INTEGER :: I1 END TYPE T1 PUBLIC :: S1 CONTAINS SUBROUTINE S1 CONTAINS TYPE(T1) FUNCTION F1() END FUNCTION F1 END SUBROUTINE S1 END MODULE M1 -- jv244 at cam dot ac dot uk changed: What|Removed |Added OtherBugsDependingO||32834 nThis|| Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||rejects-valid Known to fail||4.4.0 Last reconfirmed|-00-00 00:00:00 |2008-11-11 13:28:28 date|| Summary|bug5|private/public confusion ||with a contained function http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38065
[Bug middle-end/36125] [4.4 Regression] FAIL: 26_numerics/complex/13450.cc: ICE in verify_gimple_expr, at tree-cfg.c:3962
--- Comment #9 from jakub at gcc dot gnu dot org 2008-11-11 10:04 ---
Short testcase:
extern void bar (long double *);
void
foo (long double x)
{
bar (x);
}
fails also with C. The problem is that gimplify_parameters for
reference_callee_copied copies the long double PARM_DECL into a local VAR_DECL
copy. But as the PARM_DECL was marked as TREE_ADDRESSABLE by the FE (the body
of the function takes address of the argument) and the local copy is marked
addressable during gimplification (again, the body takes address of the
parameter, which is now DECL_VALUE_EXPRed to the local VAR_DECL), this triggers
verification failure, as one addressable var is assigned into another one.
I think either we should if parm is TREE_ADDRESSABLE move that flag over to
local (i.e. parm would be no longer TREE_ADDRESSABLE, local would be) in
gimplify_parameters, or we'd need to add another temporary in between.
I'll attach the first solution soon.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org
|dot org |
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2008-11-11 10:04:15
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36125
[Bug fortran/38082] New: string truncated on return from subroutine (calling mkdtemp bind(c))
Hi! I am using the gfortran compiler in Ubuntu 8.10 (gfortran 4.3.2). I ran into a bug with calling mkdtemp(3) via the BIND(C) feature. In some way gfortran truncates the string on return from the Fortran subroutine. All results seems to be Ok inside the Fortran subroutine but the caller does not get the proper value? Please look at the examples below and mkdtemp(3) as they explain better than I can with my poor English. :-) Wrong results from gfortran: na56:1d_longtimegfortran -o callbug callbug.f90 na56:1d_longtime./callbug ctemp = /tmp/foo.XX ctemp after call: /tmp/foo.HMq3kW template = [/tmp/foo.HMq3kW] template = .HMq3kW na56:1d_longtime Correct results from sunstudio 12 na56:1d_longtimesunf95 -o callbug callbug.f90 na56:1d_longtime./callbug ctemp = /tmp/foo.XX ctemp after call: /tmp/foo.lEniI6 template = [/tmp/foo.lEniI6] template = /tmp/foo.lEniI6 na56:1d_longtime I will attach the source code in another post. Thank you for a great compiler! Henrik Holst -- Using built-in specs. Target: i486-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.3.2-1ubuntu11' --with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3 --program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr --enable-targets=all --enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu Thread model: posix gcc version 4.3.2 (Ubuntu 4.3.2-1ubuntu11) -- Summary: string truncated on return from subroutine (calling mkdtemp bind(c)) Product: gcc Version: 4.3.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: holst at matmech dot com GCC target triplet: i486-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38082
[Bug c++/34269] [4.2/4.3/4.4 regression] Incomplete __decltype/__typeof expressions accepted
--- Comment #5 from jason at redhat dot com 2008-11-11 17:45 --- Subject: Re: [4.2/4.3/4.4 regression] Incomplete __decltype/__typeof expressions accepted jakub at gcc dot gnu dot org wrote: Another possibility would be add support for queing error messages during tentative parsing and at cp_parser_commit_to_tentative_parse emit them. This seems right to me. It's even what the comment at the top of the file says we do: Then, while we attempt to parse the construct, the parser queues up error messages, rather than issuing them immediately, and saves the tokens it consumes. If the construct is parsed successfully, the parser commits, i.e., it issues any queued error messages and the tokens that were being preserved are permanently discarded. The simulate_error business only works for parse errors that indicate that this line of parsing won't work; it doesn't work for code that parses fine, but violates semantic rules and therefore needs an error. Jason -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34269
[Bug fortran/38066] bug6 ambiguous reference
--- Comment #4 from burnus at gcc dot gnu dot org 2008-11-11 19:33 --- (In reply to comment #3) I will go back to my lens design program. I will recreate the bug I am seeing and proceed from there. Once I do, should I submit a new bug report, if necessary, or should I append this existing one? It think appending would be preferred. (By the way, if you reply to the bug email, could you delete the quoted text? The reason is that the whole text of the email is added to the bugreport - including the quotes. The quoted text makes it more difficult hard to read through the comments using the web interface; quoting a line or two is OK, if one explicitly refers to those lines in the comment.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38066
[Bug fortran/38065] private/public confusion with a contained function
--- Comment #9 from burnus at gcc dot gnu dot org 2008-11-11 14:28 --- (In reply to comment #6) reduced: SUBROUTINE S1 CONTAINS TYPE(T1) FUNCTION F1() END FUNCTION F1 END SUBROUTINE S1 Error: PUBLIC function 'f1' at (1) cannot be of PRIVATE type 't1' gfortran has two bugs: a) F1 is an internal function and thus PUBLIC/PRIVATE does not apply b) If one makes F1 a (PUBLIC) *module* function, the program still would be a valid Fortran 2003 program (and an invalid Fortran 95 program). I still need to test whether the original program is fixed or not; there are quite a lot files ... Fix: +++ gcc/fortran/resolve.c (Arbeitskopie) @@ -10181,0 +10182 @@ resolve_fntype (gfc_namespace *ns) + !sym-attr.contained @@ -10186,2 +10187,3 @@ resolve_fntype (gfc_namespace *ns) - gfc_error (PUBLIC function '%s' at %L cannot be of PRIVATE type '%s', -sym-name, sym-declared_at, sym-ts.derived-name); + gfc_notify_std (GFC_STD_F2003, Fortran 2003: PUBLIC function '%s' at + %L of PRIVATE type '%s', sym-name, + sym-declared_at, sym-ts.derived-name); -- 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=38065
[Bug target/38085] New: gcc -m64 -pg generates invalid assembler code on Solaris 10/x86
gcc -m64 -pg always generates invalid assembler code on Solaris 10/x86:
int
main (void)
{
}
% ./xgcc -B./ -m64 -pg -c ptest.c
/var/tmp//cc4kvaG9.s: Assembler messages:
/var/tmp//cc4kvaG9.s:18: Error: junk `@' after expression
Line 18 of the output file is
leaq.LP0@(%rip),%r11
This happens both with gas 2.15 (/usr/ccs/bin/gas) and with gas 2.19.50 (CVS
version 2.19.50.20081009).
The bug has been present since the introduction of x86_64 profiling support by
this patch:
Fri Nov 15 14:54:19 CET 2002 Jan Hubicka [EMAIL PROTECTED]
* i386-protos.h (x86_function_profiler): New function
* i386.h (MCOUNT_NAME): New.
(PROFILE_COUNT_REGISTER): New.
(FUNCTION_PROFILER): Move offline to ...
* i386.c (x86_function_profiler) ... here; fix 64bit support
I have no idea what was intended here.
--
Summary: gcc -m64 -pg generates invalid assembler code on Solaris
10/x86
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: hubicka at gcc dot gnu dot org
ReportedBy: ro at gcc dot gnu dot org
GCC build triplet: i386-pc-solaris2.10
GCC host triplet: i386-pc-solaris2.10
GCC target triplet: i386-pc-solaris2.10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38085
[Bug middle-end/38084] New: [graphite] ICE : in build_graphite_scops, at graphite.c:1829
gcc -O3 -fgraphite-identity test_graphite_scop.c test_graphite_scop.c: In function 'test_in': test_graphite_scop.c:12: internal compiler error: in build_graphite_scops, at graphite.c:1829 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Same test case fails for -floop-block switch as well. gcc -O3 -floop-block test_graphite_scop.c test_graphite_scop.c: In function 'test_in': test_graphite_scop.c:12: internal compiler error: in build_graphite_scops, at graphite.c:1829 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Reduced test case is attached for the same... -Mitul Thakkar. -- Summary: [graphite] ICE : in build_graphite_scops, at graphite.c:1829 Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mitul dot thakkar at amd dot com GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38084
[Bug c++/34269] [4.2/4.3/4.4 regression] Incomplete __decltype/__typeof expressions accepted
--- Comment #6 from mark at codesourcery dot com 2008-11-11 20:09 --- Subject: Re: [4.2/4.3/4.4 regression] Incomplete __decltype/__typeof expressions accepted jason at redhat dot com wrote: This seems right to me. It's even what the comment at the top of the file says we do: Then, while we attempt to parse the construct, the parser queues up error messages, rather than issuing them immediately, and saves the tokens it consumes. If the construct is parsed successfully, the parser commits, i.e., it issues any queued error messages and the tokens that were being preserved are permanently discarded. The simulate_error business only works for parse errors that indicate that this line of parsing won't work; it doesn't work for code that parses fine, but violates semantic rules and therefore needs an error. I forgot that comment was still there. I think it's a lie, reflecting an earlier implementation state. I found queuing up the messages to be really difficult. For a syntactically broken construct, we can just issue the error and commit to the tentative parse at that point. I believe we do that in some other places. It doesn't matter what top-level construct (declaration or expression-statement) we might be looking at; something like __decltype( ; is always invalid. Once you see decltype ( , if the parsing of the operand to decltype fails, we can commit to the current tentative parse, issue the error, and move on. However, I think the core bug here may be that the code you mention in cp_parser_simple_declaration doesn't check to see if the parse has already failed. Committing to the tentative parse is reasonable in that situation if the parsing has succeeded thus far -- but if we've actually hit a *parse* error, rather than a *semantic* error, we could safely give up. That will result in trying to parse the decltype again (now as an expression statement), and we'll get an error that time. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34269
[Bug tree-optimization/37709] [4.4 Regression] inliner gone crazy
--- Comment #7 from hubicka at gcc dot gnu dot org 2008-11-11 20:09 --- Current implementation of inliner is perfectly unaware of the debug info size implications. There is alternative to limit number of BLOCKS in function body growth same way as we limit stack usage that would just add little extra bookkeeping, but I would like to be sure that there is no better alternative first. Current BLOCK removal code is quite conservative based on my observations of what RTL code did originally, perhaps we can be more strict? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37709
[Bug middle-end/38074] [4.4 Regression] missed inlining since IRA merge on Core2 Duo
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-11-11 20:21 --- I don't see how there can be a connection to the IRA merge. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38074
[Bug middle-end/30286] [4.1 Regression] Segfault with -O2 -ftrapv
--- Comment #8 from rguenth at gcc dot gnu dot org 2008-11-11 20:26 --- Please open another bugreport and specify details where it fails (note that 4.1 is no longer maintained) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30286
[Bug libstdc++/37957] Wrong behaviour of num_get::do_get(bool) in the case when one target sequence is a prefix of the other one
--- Comment #3 from paolo dot carlini at oracle dot com 2008-11-11 12:08 --- . -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37957
[Bug other/38077] strict aliasing is not controllable via the option pragma or is not documented that way
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-11-11 20:34 --- Confirmed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-11-11 20:34:48 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38077
[Bug fortran/38065] private/public confusion with a contained function
--- Comment #10 from burnus at gcc dot gnu dot org 2008-11-11 14:35 --- bug5a.tgz compiled successfully with the patch in comment 9. -- burnus at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |burnus at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2008-11-11 13:28:28 |2008-11-11 14:35:00 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38065
[Bug c++/34983] i486-linux-gnu-g++: Internal error: Killed (program cc1plus)
--- Comment #7 from rguenth at gcc dot gnu dot org 2008-11-11 20:37 --- 4.3 uses ~1GB of ram. tree SSA incremental : 11.10 (10%) usr 0.09 ( 4%) sys 11.70 (10%) wall 13667 kB ( 3%) ggc dominance frontiers : 10.27 ( 9%) usr 0.07 ( 3%) sys 10.24 ( 9%) wall 0 kB ( 0%) ggc loop analysis : 16.90 (15%) usr 0.03 ( 1%) sys 17.17 (15%) wall 988 kB ( 0%) ggc it's yet another case of a massive function with loops. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org Status|WAITING |NEW Ever Confirmed|0 |1 Keywords||compile-time-hog, memory-hog Last reconfirmed|-00-00 00:00:00 |2008-11-11 20:37:01 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34983
[Bug middle-end/38074] [4.4 Regression] missed inlining since IRA merge on Core2 Duo
--- Comment #2 from dominiq at lps dot ens dot fr 2008-11-11 20:37 --- Subject: Re: [4.4 Regression] missed inlining since IRA merge on Core2 Duo I don't see how there can be a connection to the IRA merge. I don't see either, but the behavior changed between Aug 23 and Sep 2. At this time the IRA merge was the major shaking and I did not see what else can have caused that. The merge may have exposed a latent bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38074
[Bug tree-optimization/35011] ICE with -fcheck-data-deps
--- Comment #7 from reichelt at gcc dot gnu dot org 2008-11-11 20:39 --- The bug reappeared on mainline. It's not a regression, because the testcase crashes since the introduction of -fcheck-data-deps in GCC 4.3.0. -- reichelt at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.3 regression] ICE with - |ICE with -fcheck-data-deps |fcheck-data-deps| Target Milestone|4.3.3 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35011
[Bug c++/31503] gcc exhausts memory when compiling pixie with optimizations
--- Comment #3 from lucabon at interfree dot it 2008-11-11 17:38 --- Compiling Pixie requires about 1.5 GB of available memory with gcc 4.2.3. -- lucabon at interfree dot it changed: What|Removed |Added CC||lucabon at interfree dot it http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31503
[Bug preprocessor/35326] [4.2/4.3 regression] ICE with stray digraph token
--- Comment #7 from reichelt at gcc dot gnu dot org 2008-11-11 21:04 --- The bug disappeared on mainline. The crash with the C frontend disappeared much later than the one with the C++ frontend. Therefore, I don't think that the bug has been really fixed, we are just lucky that it doesn't trigger segfaults anymore. -- reichelt at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.2/4.3/4.4 regression] ICE|[4.2/4.3 regression] ICE |with stray digraph token|with stray digraph token http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35326
[Bug libstdc++/38081] time_get::do_get_weekday does not always recognize full names of weekdays
--- Comment #2 from paolo dot carlini at oracle dot com 2008-11-11 13:50 --- Ok. -- paolo dot carlini at oracle dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |paolo dot carlini at oracle |dot org |dot com Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-11-11 13:50:28 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38081
[Bug c++/34983] i486-linux-gnu-g++: Internal error: Killed (program cc1plus)
--- Comment #6 from lucabon at interfree dot it 2008-11-11 17:36 --- Created an attachment (id=16655) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16655action=view) execute.cpp preprocessed source Compiling Pixie (version 2.2.4, with gcc 4.2.3), in particular execute.cpp, requires 1.5 GB of available memory (better if real, otherwise it could take some hours). Is it normal a so big amount of required memory? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34983
[Bug fortran/38065] private/public confusion with a contained function
--- Comment #7 from clerman at fuse dot net 2008-11-11 13:46 --- Subject: Re: private/public confusion with a contained function Hello, As best I can see, your reduction of the problem is not correct; in it subroutine S1 should be private, not public. Yours truly, Norm Clerman jv244 at cam dot ac dot uk [EMAIL PROTECTED] wrote: --- Comment #6 from jv244 at cam dot ac dot uk 2008-11-11 13:28 --- reduced: MODULE M1 IMPLICIT NONE PRIVATE TYPE T1 INTEGER :: I1 END TYPE T1 PUBLIC :: S1 CONTAINS SUBROUTINE S1 CONTAINS TYPE(T1) FUNCTION F1() END FUNCTION F1 END SUBROUTINE S1 END MODULE M1 -- jv244 at cam dot ac dot uk changed: What|Removed |Added OtherBugsDependingO||32834 nThis|| Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||rejects-valid Known to fail||4.4.0 Last reconfirmed|-00-00 00:00:00 |2008-11-11 13:28:28 date|| Summary|bug5|private/public confusion ||with a contained function http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38065 --- You are receiving this mail because: --- You reported the bug, or are watching the reporter. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38065
[Bug target/35366] [4.4 Regression] gfortran.dg/equiv_7.f90 fails with -m64 -Os on powerpc-apple-darwin9
--- Comment #3 from jv244 at cam dot ac dot uk 2008-11-11 16:08 --- just a note on the patch posted: http://gcc.gnu.org/ml/gcc-patches/2008-11/msg00407.html the fortran standard guarantees that E==TRANSFER(TRANSFER(E,D),E) if the physical representation of D and E is the same length. At the same time, it guarantees that a default logical and a default integer can be storage associated e.g. in a common block (talking about physical storage units). The wording seems somewhat imprecise, but I think it guarantees that the above transfer should work with integer and logical -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35366
[Bug middle-end/38074] [4.4 Regression] missed inlining since IRA merge on Core2 Duo
--- Comment #3 from jakub at gcc dot gnu dot org 2008-11-11 21:18 --- There were many changes, mainly from Jan, in that time range that could have caused it. The most likely thing I'd say is that the basic blocks where those functions are called are considered by gcc to be cold and thus considers inlining it not desirable. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38074
[Bug middle-end/30286] [4.1 Regression] Segfault with -O2 -ftrapv
--- Comment #7 from howarth at nitro dot med dot uc dot edu 2008-11-11 15:52 --- This test case is still failing on i686-apple-darwin9. Shouldn't this PR be reopened? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30286
[Bug libstdc++/37986] std::tr1::variate_generator does not conform to TR1.
--- Comment #2 from paolo at gcc dot gnu dot org 2008-11-11 14:32 --- Subject: Bug 37986 Author: paolo Date: Tue Nov 11 14:31:48 2008 New Revision: 141769 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141769 Log: 2008-11-11 Paolo Carlini [EMAIL PROTECTED] PR libstdc++/37986 * include/tr1_impl/random (struct _Adaptor): Use remove_pointer and remove_reference on _Engine. * testsuite/tr1/5_numerical_facilities/random/variate_generator/ 37986.cc: New. Added: trunk/libstdc++-v3/testsuite/tr1/5_numerical_facilities/random/variate_generator/37986.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/tr1_impl/random -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37986
[Bug libstdc++/38080] New: dead links in libstdc++ headers
The libstdc++ headers contain several links to online documentation, e.g. http://gcc.gnu.org/onlinedocs/libstdc++/17_intro/howto.html#5 but these pages are no longer available, probably due to a rearrangement on the webserver. The sources should be updated to deliver current links in future releases, but eventually the webserver should also get redirection rules added to redirect requests for the old to the new location. -- Summary: dead links in libstdc++ headers Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: gcc at abeckmann dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38080
[Bug fortran/38066] bug6 ambiguous reference
--- Comment #2 from burnus at gcc dot gnu dot org 2008-11-11 15:25 --- Error: Name 'getnullset' at (1) is an ambiguous reference to 'getnullset' from module 'pbit4set' I have not yet checked the source, but other compilers give similar errors: * NAG f95: Error: bug6M.f90, line 17: Symbol GETNULLSET found both in module PBIT4SET and in PBIT8SET detected at [EMAIL PROTECTED] Error: bug6M.f90, line 17: Symbol GETNULLSET found both in module PBIT4SET and in PBIT8SET detected at [EMAIL PROTECTED] * g95: In file bug6M.f90:22 END MODULE Bug6 1 Error: Name 'getnullset' at (1) is an ambiguous reference to 'getnullset' from module 'pbit4set' * ifort: bug6M.f90(17): error #6405: The same named entity from different modules and/or program units cannot be referenced. [GETNULLSET] CALL GetNullSet (search_set) * openf95: openf95-486 openf95: ERROR SUB_A, File = bug6M.f90, Line = 17, Column = 12 GETNULLSET has been use associated from module PBIT4SET and at least one more module. It must not be referenced. The NAG, Intel and g95 compilers all compile this code. Hmm, not here! You have in bug6M.f90: USE PBit4Set USE PBit8Set That makes the following two getNullSet available: pure subroutine getNullSet (ANullSet) ! In pbit4setM.f90 type (TPBit4Set), intent(out) :: ANullSet pure subroutine getNullSet (ANullSet) ! In pbit8setM.f90 type (TPBit8Set), intent(out) :: ANullSet If you now call getNullSet you have a problem since getNullSet exists in both PBit4Set and PBit8Set. (Note: getNullSet is *not* a generic interface.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38066
[Bug fortran/38065] private/public confusion with a contained function
--- Comment #8 from jv244 at cam dot ac dot uk 2008-11-11 14:14 --- (In reply to comment #7) As best I can see, your reduction of the problem is not correct; in it subroutine S1 should be private, not public. I don't think so. See your code, S1 ~ GeomMTF, which is public. The problem is the contained function F1 (your CreateLine), which incorrectly gets a 'public' attribute. Note that the same, incorrect error message is displayed for this testcase. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38065
[Bug middle-end/36125] [4.4 Regression] FAIL: 26_numerics/complex/13450.cc: ICE in verify_gimple_expr, at tree-cfg.c:3962
--- Comment #10 from jakub at gcc dot gnu dot org 2008-11-11 10:14 --- Created an attachment (id=16650) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16650action=view) gcc44-pr36125.patch Patch that cures this for me. Can you please bootstrap/regtest it on hppa? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36125
[Bug libstdc++/37986] std::tr1::variate_generator does not conform to TR1.
--- Comment #3 from paolo dot carlini at oracle dot com 2008-11-11 14:33 --- Fixed for 4.4.0. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37986
[Bug libstdc++/38000] [4.3/4.4 Regression] System header files not found once -isystem /usr/include is used
--- Comment #4 from paolo dot carlini at oracle dot com 2008-11-11 12:48 --- I think the use of include_next started with Benjamin's patch of 2007-03-04, adding c_global. Benjamin, can you look into this issue? Otherwise, missing a solid rationale, for 4.4.0 I would just remove the uses, per Jakub' suggestion. -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC||paolo at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38000
[Bug libstdc++/38081] New: time_get::do_get_weekday does not always recognize full names of weekdays
The description of time_get::do_get_weekday() and time_get::do_get_monthname() states (22.2.5.1.2): Effects: Reads characters starting at s until it has extracted the (perhaps abbreviated) name of a weekday or month. If it finds an abbreviation that is followed by characters that could match a full name, it continues reading until it matches the full name or fails. However, if the abbreviated name of a weekday is not a prefix of its full name, the full name is not recognized by the function. For example, the Russian name of Monday (Ponedelnik) is not recognized as Monday (locale - ru_RU.iso88595) because of this. But if one replaces the 1st 3 symbols of this word with the abbreviated Russian name of Monday (Pnd), the resulting string (Pndedelnik) is recognized as the full name of Monday, which is wrong. According to the source of time_get::do_get_weekday function's implementation as well as the comments in it, it is definitely assumed in the function that the abbreviated name of a weekday should be a prefix of its full name. A similar problem takes place for time_get::do_get_monthname() function. -- Summary: time_get::do_get_weekday does not always recognize full names of weekdays Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tsyvarev at ispras dot ru http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38081
[Bug libstdc++/37957] Wrong behaviour of num_get::do_get(bool) in the case when one target sequence is a prefix of the other one
--- Comment #2 from tsyvarev at ispras dot ru 2008-11-11 10:22 --- This bug was fixed with fixing of bug 37958. Testcase for bug 37958 also covers this one. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37957
[Bug fortran/38082] string truncated on return from subroutine (calling mkdtemp bind(c))
--- Comment #3 from holst at matmech dot com 2008-11-11 14:25 --- I tried with gcc version: gcc version 4.4.0 20081021 (experimental) [trunk revision 141258] (GCC) and then it works as expected. I will hope Ubuntu will upgrade to 4.3.3 soon! :-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38082
[Bug middle-end/38084] [graphite] ICE : in build_graphite_scops, at graphite.c:1829
--- Comment #1 from mitul dot thakkar at amd dot com 2008-11-11 16:35 --- Created an attachment (id=16654) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16654action=view) Reduced Test Case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38084
[Bug rtl-optimization/323] optimized code gives strange floating point results
--- Comment #125 from vincent at vinc17 dot org 2008-11-11 10:13 --- (In reply to comment #124) It seems like the C99 standard prohibits double rounding, only if Annex F is claimed to be supported (note: Annex F is not just IEEE 754, it also contains specific bindings). IEEE 754 doesn't prohibit double rounding either (this depends on the bindings), but with C99 + Annex F, double rounding is prohibited. Now, bug 323 is not about double rounding specifically. There are two potential problems: 1. A double variable (or result of a cast) contains a long double value (not exactly representable in a double). This is prohibited by C99 (5.1.2.3#12, 6.3.1.5#2 and 6.3.1.8#2[52]). This problem seems to be fixed by Joseph Myers' patch mentioned in comment #123 (but I haven't tried). 2. Computations on double expressions are carried out in extended precision. This is allowed by C99 (except for casts and assignments), e.g. when FLT_EVAL_METHOD=2. But if the implementation (i.e. here compiler + library + ...) claims to support Annex F, then this is prohibited. This point is rather tricky because the compiler (GCC) and library (e.g. GNU libc) settings must be consistent, so their developers need to talk with each other. FYI, I reported the following bug concerning glibc: http://sourceware.org/bugzilla/show_bug.cgi?id=6981 because it sets __STDC_IEC_559__ to 1 unconditionally. The short answer is that no compiler, be it gcc, will be modified so that complex sequences of operations are used for floating-point operations in lieu of directly using x87 instructions! At least for two reasons: * x87 is now fading away (its use is deprecated on x86-64, it's not used by default on Intel Macintosh...) * Most people don't want to pay the performance hit. That's why in Joseph's patch, it's just an option (disabled by default, but enabled by -std=c99 because one should assume that if a user wants C99, then he really wants it, and if he is able to add an option, then he is also able to add another one if he wants to disable this fix in case he knows it is useless for his application -- this is also true for -ffast-math). GCC already supports SSE, but this patch is for processors that don't. Also the performance hit depends very much on the application. Performance hit is reduced in applications that do not use intensive FP or mostly interactive applications. In addition, I think there are more urgent things to fix in gcc's floating-point system, such as support for #pragma STDC FENV ACCESS FYI, this is bug 34678. And I submitted bug 37845 concerning the FP_CONTRACT pragma. * It is possible to force the x87 to use reduced precision for the mantissa (with inline asm or even now with gcc options). Unfortunately, this means that long double wouldn't behave as expected, and the behavior is not controllable enough (e.g. due to libraries, plugins...). Such a change should have been system-wide. Now, this is needed in software where double rounding is prohibited (e.g. XSLT processor). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323
[Bug c++/35334] [4.2/4.3/4.4 regression] Broken diagnostic for complex cast
--- Comment #8 from jakub at gcc dot gnu dot org 2008-11-11 14:08 --- Patch posted. -- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | URL||http://gcc.gnu.org/ml/gcc- ||patches/2008- ||11/msg00415.html Status|NEW |ASSIGNED Last reconfirmed|2008-02-24 22:01:18 |2008-11-11 14:08:19 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35334
[Bug libgomp/38086] New: libgomp fails to build if assembler doesn't support .symver
Building current mainline on Solaris 11/SPARC with GNU ld 2.19 and Sun as fails when building libgomp: libtool: compile: /vol/gccsrc/obj/gcc-4.4.0-20081110/11-gcc-gld/./gcc/xgcc -B/vol/gccsrc/obj/gcc-4.4.0-20081110/11-gcc-gld/./gcc/ -B/vol/gcc/sparc-sun-solaris2.11/bin/ -B/vol/gcc/sparc-sun-solaris2.11/lib/ -isystem /vol/gcc/sparc-sun-solaris2.11/include -isystem /vol/gcc/sparc-sun-solaris2.11/sys-include -DHAVE_CONFIG_H -I. -I/vol/gcc/src/gcc-dist/libgomp -I. -I/vol/gcc/src/gcc-dist/libgomp/config/posix -I/vol/gcc/src/gcc-dist/libgomp -Wall -pthread -Werror -g -O2 -MT lock.lo -MD -MP -MF .deps/lock.Tpo -c /vol/gcc/src/gcc-dist/libgomp/config/posix/lock.c -fPIC -DPIC -o .libs/lock.o /usr/bin/as: /var/tmp//ccPRa4Qu.s, line 10: error: unknown opcode .symver /usr/bin/as: /var/tmp//ccPRa4Qu.s, line 10: error: invalid character (0x40) /usr/bin/as: /var/tmp//ccPRa4Qu.s, line 10: error: invalid character (0x40) /usr/bin/as: /var/tmp//ccPRa4Qu.s, line 10: error: statement syntax /usr/bin/as: /var/tmp//ccPRa4Qu.s, line 11: error: unknown opcode .symver /usr/bin/as: /var/tmp//ccPRa4Qu.s, line 11: error: invalid character (0x40) /usr/bin/as: /var/tmp//ccPRa4Qu.s, line 11: error: statement syntax /usr/bin/as: /var/tmp//ccPRa4Qu.s, line 12: error: unknown opcode .symver /usr/bin/as: /var/tmp//ccPRa4Qu.s, line 12: error: invalid character (0x40) /usr/bin/as: /var/tmp//ccPRa4Qu.s, line 12: error: invalid character (0x40) /usr/bin/as: /var/tmp//ccPRa4Qu.s, line 12: error: statement syntax /usr/bin/as: /var/tmp//ccPRa4Qu.s, line 13: error: unknown opcode .symver /usr/bin/as: /var/tmp//ccPRa4Qu.s, line 13: error: invalid character (0x40) /usr/bin/as: /var/tmp//ccPRa4Qu.s, line 13: error: statement syntax /usr/bin/as: /var/tmp//ccPRa4Qu.s, line 14: error: unknown opcode .symver /usr/bin/as: /var/tmp//ccPRa4Qu.s, line 14: error: invalid character (0x40) /usr/bin/as: /var/tmp//ccPRa4Qu.s, line 14: error: invalid character (0x40) /usr/bin/as: /var/tmp//ccPRa4Qu.s, line 14: error: statement syntax /usr/bin/as: /var/tmp//ccPRa4Qu.s, line 15: error: unknown opcode .symver /usr/bin/as: /var/tmp//ccPRa4Qu.s, line 15: error: invalid character (0x40) /usr/bin/as: /var/tmp//ccPRa4Qu.s, line 15: error: statement syntax /usr/bin/as: /var/tmp//ccPRa4Qu.s, line 16: error: unknown opcode .symver /usr/bin/as: /var/tmp//ccPRa4Qu.s, line 16: error: invalid character (0x40) /usr/bin/as: /var/tmp//ccPRa4Qu.s, line 16: error: invalid character (0x40) /usr/bin/as: /var/tmp//ccPRa4Qu.s, line 16: error: statement syntax /usr/bin/as: /var/tmp//ccPRa4Qu.s, line 17: error: unknown opcode .symver /usr/bin/as: /var/tmp//ccPRa4Qu.s, line 17: error: invalid character (0x40) /usr/bin/as: /var/tmp//ccPRa4Qu.s, line 17: error: statement syntax /usr/bin/as: /var/tmp//ccPRa4Qu.s, line 18: error: unknown opcode .symver /usr/bin/as: /var/tmp//ccPRa4Qu.s, line 18: error: invalid character (0x40) /usr/bin/as: /var/tmp//ccPRa4Qu.s, line 18: error: invalid character (0x40) /usr/bin/as: /var/tmp//ccPRa4Qu.s, line 18: error: statement syntax /usr/bin/as: /var/tmp//ccPRa4Qu.s, line 19: error: unknown opcode .symver /usr/bin/as: /var/tmp//ccPRa4Qu.s, line 19: error: invalid character (0x40) /usr/bin/as: /var/tmp//ccPRa4Qu.s, line 19: error: statement syntax /usr/bin/as: /var/tmp//ccPRa4Qu.s, line 20: error: unknown opcode .symver /usr/bin/as: /var/tmp//ccPRa4Qu.s, line 20: error: invalid character (0x40) /usr/bin/as: /var/tmp//ccPRa4Qu.s, line 20: error: invalid character (0x40) /usr/bin/as: /var/tmp//ccPRa4Qu.s, line 20: error: statement syntax /usr/bin/as: /var/tmp//ccPRa4Qu.s, line 21: error: unknown opcode .symver /usr/bin/as: /var/tmp//ccPRa4Qu.s, line 21: error: invalid character (0x40) /usr/bin/as: /var/tmp//ccPRa4Qu.s, line 21: error: statement syntax /usr/bin/as: /var/tmp//ccPRa4Qu.s, line 22: error: unknown opcode .symver /usr/bin/as: /var/tmp//ccPRa4Qu.s, line 22: error: invalid character (0x40) /usr/bin/as: /var/tmp//ccPRa4Qu.s, line 22: error: invalid character (0x40) /usr/bin/as: /var/tmp//ccPRa4Qu.s, line 22: error: statement syntax /usr/bin/as: /var/tmp//ccPRa4Qu.s, line 23: error: unknown opcode .symver /usr/bin/as: /var/tmp//ccPRa4Qu.s, line 23: error: invalid character (0x40) /usr/bin/as: /var/tmp//ccPRa4Qu.s, line 23: error: statement syntax /usr/bin/as: /var/tmp//ccPRa4Qu.s, line 24: error: unknown opcode .symver /usr/bin/as: /var/tmp//ccPRa4Qu.s, line 24: error: invalid character (0x40) /usr/bin/as: /var/tmp//ccPRa4Qu.s, line 24: error: invalid character (0x40) /usr/bin/as: /var/tmp//ccPRa4Qu.s, line 24: error: statement syntax /usr/bin/as: /var/tmp//ccPRa4Qu.s, line 25: error: unknown opcode .symver /usr/bin/as: /var/tmp//ccPRa4Qu.s, line 25: error: invalid character (0x40) /usr/bin/as: /var/tmp//ccPRa4Qu.s, line 25: error: statement syntax /usr/bin/as: /var/tmp//ccPRa4Qu.s, line 26: error: unknown opcode .symver /usr/bin/as: /var/tmp//ccPRa4Qu.s, line 26: error: invalid character (0x40) /usr/bin/as: /var/tmp//ccPRa4Qu.s, line 26: error:
[Bug testsuite/37202] FAIL: gcc.dg/visibility-1[4-9].c
--- Comment #13 from mrs at apple dot com 2008-11-11 23:13 --- The darwin patch is fine. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37202
[Bug fortran/38066] bug6 ambiguous reference
--- Comment #5 from clerman at fuse dot net 2008-11-11 23:19 --- Subject: Re: bug6 ambiguous reference Attached is a file that will allow you to reproduce the problem. Run the shell script bug6.sh. The error occurs in file mtfmodM.f90: mtfmodM.f90:2810.17: end module MTFMod 1 Error: Name 'getnullset' at (1) is an ambiguous reference to 'getnullset' from module 'pbit4set' mtfmodM.f90:2810.17: end module MTFMod 1 Error: Name 'getnullset' at (1) is an ambiguous reference to 'getnullset' from module 'pbit4set' mtfmodM.f90:2810.17: end module MTFMod 1 Error: Name 'getnullset' at (1) is an ambiguous reference to 'getnullset' from module 'pbit4set' The other compilers will compile this code. It has been part of my production lens design program for years. Thanks for you patience on this. Norm Clerman --- Comment #6 from clerman at fuse dot net 2008-11-11 23:19 --- Created an attachment (id=16656) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16656action=view) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38066
[Bug fortran/38066] bug6 ambiguous reference
--- Comment #7 from clerman at fuse dot net 2008-11-11 23:22 --- I have just sent an e-mail in response to your latest one. Attached to it is a file that will allow you to reproduce the problem. Thank you for your patience on this matter. Norm Clerman -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38066
[Bug rtl-optimization/37363] [4.4 Regression] Fix for PR 36090 causes libstdc++ regressions
--- Comment #7 from rsandifo at gcc dot gnu dot org 2008-11-11 23:27 --- Fixed on trunk. -- rsandifo at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37363
[Bug rtl-optimization/37363] [4.4 Regression] Fix for PR 36090 causes libstdc++ regressions
--- Comment #6 from rsandifo at gcc dot gnu dot org 2008-11-11 23:24 --- Subject: Bug 37363 Author: rsandifo Date: Tue Nov 11 23:23:23 2008 New Revision: 141774 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141774 Log: gcc/ PR rtl-optimization/37363 * simplify-rtx.c (simplify_plus_minus): Don't create (const (minus ...)) expresisons. Modified: trunk/gcc/ChangeLog trunk/gcc/simplify-rtx.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37363
[Bug c++/38087] New: Pseudo destructor call
In 5.2.4p2 [expr.pseudo]:
The cv-unqualified versions of
the object type and of the type designated by the pseudo-destructor-
name shall be the same type.
class B { };
class C : public B {
void m() {
this-~B();
}
};
I tried:
GNU C++ (GCC) version 4.4.0 20081003 (experimental) [trunk revision 140855]
(i686-apple-darwin9)
and it gave no error.
--
Summary: Pseudo destructor call
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mrs at apple dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38087
[Bug c++/38087] Pseudo destructor call
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-11-12 00:32 --- I still think this is valid code ... There are defect reports against this area too. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38087
[Bug c++/38087] Pseudo destructor call
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-11-12 00:35 --- See PR 12333 also. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38087
[Bug target/38052] [4.4 Regression] genautomata segfaults when -O2 is enabled
--- Comment #2 from kumba at gentoo dot org 2008-11-12 01:01 --- I ran into this too. The problem flag is -foptimize-sibling-calls. You can pass that with -O1 to trigger the bug, but not with -O0. Some other optimization in -O1 seems to be mixing with this one and causing the flaw. Ran into this on mips-unknown-linux-gnu, btw. Mips-specific maybe? -- kumba at gentoo dot org changed: What|Removed |Added CC||kumba at gentoo dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38052
[Bug bootstrap/38088] New: gcc fails to compile with undefined symbol: __LONG_LONG_MAX__ error
The weekly snapshot (dated 20081107) of gcc 4.4 fails to compile on a Sun Solaris machine with the following errors. cc -c -g -DIN_GCC-DHAVE_CONFIG_H -I. -I. -I../../../unZipped/gcc-4.4-20081107/gcc -I../../../unZipped/gcc-4.4-20081107/gcc/. -I../../.. /unZipped/gcc-4.4-20081107/gcc/../include -I./../intl -I../../../unZipped/gcc-4.4-20081107/gcc/../libcpp/include -I../../../unZipped/gcc-4. 4-20081107/gcc/../libdecnumber -I../../../unZipped/gcc-4.4-20081107/gcc/../libdecnumber/dpd -I../libdecnumber -I/home/kkusuman/software/my root/include ../../../unZipped/gcc-4.4-20081107/gcc/mcf.c -o mcf.o ../../../unZipped/gcc-4.4-20081107/gcc/mcf.c, line 215: undefined symbol: __LONG_LONG_MAX__ ../../../unZipped/gcc-4.4-20081107/gcc/mcf.c, line 223: undefined symbol: __LONG_LONG_MAX__ ../../../unZipped/gcc-4.4-20081107/gcc/mcf.c, line 534: undefined symbol: __LONG_LONG_MAX__ ../../../unZipped/gcc-4.4-20081107/gcc/mcf.c, line 809: undefined symbol: __LONG_LONG_MAX__ ../../../unZipped/gcc-4.4-20081107/gcc/mcf.c, line 826: undefined symbol: __LONG_LONG_MAX__ ../../../unZipped/gcc-4.4-20081107/gcc/mcf.c, line 849: undefined symbol: __LONG_LONG_MAX__ ../../../unZipped/gcc-4.4-20081107/gcc/mcf.c, line 889: undefined symbol: __LONG_LONG_MAX__ ../../../unZipped/gcc-4.4-20081107/gcc/mcf.c, line 1059: undefined symbol: __LONG_LONG_MAX__ cc: acomp failed for ../../../unZipped/gcc-4.4-20081107/gcc/mcf.c make[3]: *** [mcf.o] Error 2 make[3]: Leaving directory `/home/kkusuman/software/compileHere/gcc-4.4-20081107/gcc' make[2]: *** [all-stage1-gcc] Error 2 make[2]: Leaving directory `/home/kkusuman/software/compileHere/gcc-4.4-20081107' make[1]: *** [stage1-bubble] Error 2 make[1]: Leaving directory `/home/kkusuman/software/compileHere/gcc-4.4-20081107' make: *** [all] Error 2 The problem is due to the line #define CAP_INFINITY __LONG_LONG_MAX__ in gcc/mcf.c which will fail when a compiler other than gcc is used. This problem was first pointed out in http://gcc.gnu.org/ml/gcc-help/2008-11/msg00121.html and Ian Taylor asked me to file a bug for it. If you need any other information, I would be more than happy to provide it. thanks raju -- Summary: gcc fails to compile with undefined symbol: __LONG_LONG_MAX__ error Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: kamaraju at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38088
[Bug tree-optimization/37950] failure in polyhedron benchmark when ftree-parallelize-loops is enabled
--- Comment #2 from rakdver at gcc dot gnu dot org 2008-11-12 04:32 --- Patch: http://gcc.gnu.org/ml/gcc-patches/2008-11/msg00506.html -- rakdver at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2008- ||11/msg00506.html Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37950
[Bug c++/38089] New: g++ crash on invalid code
seen with 4.1, and newer g++ test.cpp test.cpp:17: error: specialization of 'templateclass T T MyNS::MyClass::test()' in different namespace test.cpp:8: error: from definition of 'templateclass T T MyNS::MyClass::test()' test.cpp:18: confused by earlier errors, bailing out -- Summary: g++ crash on invalid code Product: gcc Version: 4.2.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: doko at ubuntu dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38089
[Bug c++/38089] g++ crash on invalid code
--- Comment #1 from doko at ubuntu dot com 2008-11-12 06:04 --- Created an attachment (id=16657) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16657action=view) test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38089
[Bug fortran/38065] private/public confusion with a contained function
--- Comment #12 from burnus at gcc dot gnu dot org 2008-11-12 07:00 --- Subject: Bug 38065 Author: burnus Date: Wed Nov 12 06:59:33 2008 New Revision: 141780 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141780 Log: 2008-11-12 Tobias Burnus [EMAIL PROTECTED] PR fortran/38065 * resolve.c (resolve_fntype): Fix private derived type checking. 2008-11-12 Tobias Burnus [EMAIL PROTECTED] PR fortran/38065 * gfortran.dg/private_type_11.f90: New test. * gfortran.dg/private_type_12.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/private_type_11.f90 trunk/gcc/testsuite/gfortran.dg/private_type_12.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38065
[Bug fortran/38065] private/public confusion with a contained function
--- Comment #13 from burnus at gcc dot gnu dot org 2008-11-12 07:02 --- FIXED on the trunk (4.4.0). -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38065
[Bug tree-optimization/38079] gcc segfaults when using -ftree-vectorizer-verbose=9
--- Comment #3 from irar at gcc dot gnu dot org 2008-11-12 07:14 --- Subject: Bug 38079 Author: irar Date: Wed Nov 12 07:13:13 2008 New Revision: 141781 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141781 Log: PR tree-optimization/38079 * tree-vect-analyze.c (vect_analyze_data_refs): Replace dump_file with vect_dump. Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/tree-vect-analyze.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38079
