[Bug middle-end/33581] OpenMP segmentation fault
--- Comment #7 from jakub at gcc dot gnu dot org 2007-10-26 06:49 --- Using -static for threaded programs is highly discouraged in glibc, for many reasons. If you want to do it anyway for whatever weird reason, you usually need to use -Wl,--whole-archive -lnptl -Wl,--no-whole-archive. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33581
[Bug libgomp/33275] Transient libgomp.fortran/omp_parse3.f90 -O0 failure
--- Comment #3 from jakub at gcc dot gnu dot org 2007-10-26 06:51 --- Fixed on the trunk. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33275
[Bug libstdc++/33903] New: Backtrace info in std::exception
The adding of backtrace info to std::exception would be most helpful. Currently when a program throws an exception, the debug info is rather useless. Only the backtrace to the catch is shown. Ideally symbol info and line numbers should be available, so that the throw can be easily found. execinfo.h already provides a way of obtaining runtime backtrace info, but would it not be more appropriate to add this to debug info for the exception? -- Summary: Backtrace info in std::exception Product: gcc Version: 4.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: djh at emss dot co dot za http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33903
[Bug tree-optimization/33875] Small performance improvement
--- Comment #3 from ubizjak at gmail dot com 2007-10-26 07:13 --- Patch has been committed to SVN. -- ubizjak at gmail dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33875
[Bug fortran/33881] allocate negative memory
--- Comment #4 from jv244 at cam dot ac dot uk 2007-10-26 07:17 --- In order to make the testcase valid, subroutine option_stopwatch_a needs to be replaced by: subroutine option_stopwatch_a(default_clock) character(len=*), intent(in), dimension(:) :: default_clock allocate(default_clocks(size(default_clock))) end subroutine option_stopwatch_a In that case it segfaults with gfortran and runs fine .e.g. with g95 and NAG, also the g95 run is clean within valgrind, but gives several errors with gfortran: ==16592== Conditional jump or move depends on uninitialised value(s) ==16592==at 0x4011EE: __stopwatch_MOD_create_watch_ss (test.f90:33) ==16592==by 0x401A71: MAIN__ (test.f90:59) ==16592==by 0x401AAB: main (fmain.c:21) ==16592== ==16592== Conditional jump or move depends on uninitialised value(s) ==16592==at 0x401207: __stopwatch_MOD_create_watch_ss (test.f90:33) ==16592==by 0x401A71: MAIN__ (test.f90:59) ==16592==by 0x401AAB: main (fmain.c:21) ==16592== ==16592== Conditional jump or move depends on uninitialised value(s) ==16592==at 0x4A225FA: memcpy (mc_replace_strmem.c:406) ==16592==by 0x401271: __stopwatch_MOD_create_watch_ss (test.f90:33) ==16592==by 0x401A71: MAIN__ (test.f90:59) ==16592==by 0x401AAB: main (fmain.c:21) ==16592== ==16592== Conditional jump or move depends on uninitialised value(s) ==16592==at 0x4012D5: __stopwatch_MOD_create_watch_ss (test.f90:33) ==16592==by 0x401A71: MAIN__ (test.f90:59) ==16592==by 0x401AAB: main (fmain.c:21) ==16592== ==16592== Conditional jump or move depends on uninitialised value(s) ==16592==at 0x4012EE: __stopwatch_MOD_create_watch_ss (test.f90:33) ==16592==by 0x401A71: MAIN__ (test.f90:59) ==16592==by 0x401AAB: main (fmain.c:21) ==16592== ==16592== Conditional jump or move depends on uninitialised value(s) ==16592==at 0x4A225FA: memcpy (mc_replace_strmem.c:406) ==16592==by 0x4013A0: __stopwatch_MOD_create_watch_ss (test.f90:33) ==16592==by 0x401A71: MAIN__ (test.f90:59) ==16592==by 0x401AAB: main (fmain.c:21) which look as if they could be related to the optional character arguments. -- jv244 at cam dot ac dot uk changed: What|Removed |Added OtherBugsDependingO||32834 nThis|| Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-10-26 07:17:07 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33881
[Bug bootstrap/33879] bootstrapping revision 129600 fails
--- Comment #6 from ubizjak at gmail dot com 2007-10-26 07:15 --- Bootstrapps OK now on i686-pc-linux-gnu and x86_64-pc-linux-gnu. -- ubizjak at gmail dot com changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33879
[Bug fortran/33881] incorrect code for optional assumed length character arrays ?
--- Comment #5 from jv244 at cam dot ac dot uk 2007-10-26 07:51 --- I'm guess-changing the summary -- jv244 at cam dot ac dot uk changed: What|Removed |Added Keywords||wrong-code Summary|allocate negative memory|incorrect code for optional ||assumed length character ||arrays ? http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33881
[Bug fortran/33904] New: OpenMP: Default(shared) and wrong lastprivate variable is private in outer context
Reported by Vasileios Liaskovitis, http://gcc.gnu.org/ml/fortran/2007-10/msg00339.html The following valid program gives error: lastprivate variable i2 is private in outer context SUBROUTINE foo(a, b, n) DOUBLE PRECISION a, b INTEGER*8 i1, i2, i3, n DIMENSION a(n,n,n), b(n,n,n) !$OMP PARALLEL !$OMP+DEFAULT(SHARED) !$OMP+PRIVATE(I3) !$OMP DO !$OMP+LASTPRIVATE(I1,I2) DO i3 = 2, n-1, 1 DO i2 = 2, n-1, 1 DO i1 = 2, n-1, 1 a(i1, i2, i3) = b(i1, i2, i3); 600CONTINUE ENDDO ENDDO ENDDO !$OMP END DO NOWAIT !$OMP END PARALLEL RETURN END Vasilis wrote: I believe this code is compliant with the OPENMP 2.5 spec, since the DEFAULT(SHARED) clause should make the scope of i1, i2 shared in the enclosing parallel region. Pathscale 3.0, PGI 7.0.6 and Intel 10.0.026 compile the above code successfully. Replacing: !$OMP+DEFAULT(SHARED) with: !$OMP+SHARED(I1,I2) makes the code compile successfully with gfortran. Alternatively, keeping DEFAULT(SHARED) and fusing the OMP PARALLEL clause with the OMP DO clause (i.e. using OMP PARALLEL DO) also solves the problem. (this testcase is derived from a benchmark suite that doesn't allow source code modifications. gfortran should be able to compile this with no code changes - if this is indeed openmp-compliant code) Could this behavior be due to the following libgomp patch not getting all necessary information from the fortran front-end? http://gcc.gnu.org/ml/gcc-patches/2007-01/msg01940.html -- Summary: OpenMP: Default(shared) and wrong lastprivate variable is private in outer context Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: rejects-valid, openmp 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=33904
[Bug fortran/30374] aliasing amoung dummy arguments: possibly missing optimization
--- Comment #3 from jv244 at cam dot ac dot uk 2007-10-26 07:25 --- paul, the patch you have been regtesting (9 months ;-) seems not yet in. I've marked this as a missed-optimization. -- jv244 at cam dot ac dot uk changed: What|Removed |Added CC||pault at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||missed-optimization Last reconfirmed|-00-00 00:00:00 |2007-10-26 07:25:36 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30374
[Bug fortran/28484] system_clock with real-type count_rate does not compile
--- Comment #9 from jv244 at cam dot ac dot uk 2007-10-26 07:32 --- (In reply to comment #8) Taking over. Any news on this ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28484
[Bug fortran/33196] Generic name to non-standard procedure: Not diagnosed with -std=f95
-- jv244 at cam dot ac dot uk changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-10-26 07:28:13 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33196
[Bug libstdc++/33903] Backtrace info in std::exception
-- djh at emss dot co dot za changed: What|Removed |Added Severity|normal |enhancement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33903
[Bug c++/31747] [4.2 regression] ICE combining static and extern
--- Comment #6 from pcarlini at suse dot de 2007-10-26 09:59 --- Fixed in mainline. -- pcarlini at suse dot de changed: What|Removed |Added AssignedTo|pcarlini at suse dot de |unassigned at gcc dot gnu ||dot org Status|ASSIGNED|NEW Summary|[4.2/4.3 regression] ICE|[4.2 regression] ICE |combining static and extern |combining static and extern http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31747
[Bug fortran/33897] [4.1/4.2/4.3 Regression] Entries and modules
--- Comment #5 from pault at gcc dot gnu dot org 2007-10-26 09:45 --- As a final remark: Digital F90 5.0 gives the result of gfortran in #4, so now I am convinced that I am right! The Lahey source checker shows that setbd is not host associated in the module but is use associated in foo. I'll bet that it gives: 42 42 99 Paul Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33897
[Bug fortran/33897] [4.1/4.2/4.3 Regression] Entries and modules
--- Comment #4 from pault at gcc dot gnu dot org 2007-10-26 09:36 ---
This gives the correct behaviour:
Index: gcc/fortran/decl.c
===
*** gcc/fortran/decl.c (révision 129434)
--- gcc/fortran/decl.c (copie de travail)
*** gfc_match_entry (void)
*** 4376,4382
if (state == COMP_SUBROUTINE)
{
/* An entry in a subroutine. */
! if (!add_global_entry (name, 1))
return MATCH_ERROR;
m = gfc_match_formal_arglist (entry, 0, 1);
--- 4376,4382
if (state == COMP_SUBROUTINE)
{
/* An entry in a subroutine. */
! if (!gfc_current_ns-parent !add_global_entry (name, 1))
return MATCH_ERROR;
m = gfc_match_formal_arglist (entry, 0, 1);
*** gfc_match_entry (void)
*** 4398,4404
ENTRY f() RESULT (r)
can't be written as
ENTRY f RESULT (r). */
! if (!add_global_entry (name, 0))
return MATCH_ERROR;
old_loc = gfc_current_locus;
--- 4398,4404
ENTRY f() RESULT (r)
can't be written as
ENTRY f RESULT (r). */
! if (!gfc_current_ns-parent !add_global_entry (name, 0))
return MATCH_ERROR;
old_loc = gfc_current_locus;
such that
MODULE ksbin1_aux_mod
CONTAINS
SUBROUTINE nxtstg()
INTEGER :: i
INTEGER :: setbd
i = setbd() ! available by host association.
write(6,*) i
END SUBROUTINE nxtstg
FUNCTION binden()
INTEGER :: binden
INTEGER :: setbd
binden = 0
ENTRY setbd()
setbd = 99
END FUNCTION binden
END MODULE ksbin1_aux_mod
PROGRAM test
USE ksbin1_aux_mod, only : nxtstg
integer setbd ! setbd is external, since not use assoc.
CALL nxtstg()
print *, setbd ()
call foo
contains
subroutine foo
USE ksbin1_aux_mod ! module setbd is available
print *, setbd ()
end subroutine
END PROGRAM test
INTEGER FUNCTION setbd()
setbd=42
END FUNCTION setbd
gives
99
42
99
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org
|dot org |
Status|NEW |ASSIGNED
Last reconfirmed|2007-10-25 17:33:09 |2007-10-26 09:36:40
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33897
[Bug c++/32260] [4.3 Regression] too many warning: dereferencing type-punned pointer will break strict-aliasing rules
--- Comment #3 from pcarlini at suse dot de 2007-10-26 09:00 --- *** Bug 33902 has been marked as a duplicate of this bug. *** -- pcarlini at suse dot de changed: What|Removed |Added CC||benoit dot hudson at gmail ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32260
[Bug c++/33902] alias warning returning typeid(void)
--- Comment #2 from pcarlini at suse dot de 2007-10-26 09:00 --- *** This bug has been marked as a duplicate of 32260 *** -- pcarlini at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33902
[Bug fortran/33897] [4.1/4.2/4.3 Regression] Entries and modules
--- Comment #3 from pault at gcc dot gnu dot org 2007-10-26 09:10 --- (In reply to comment #2) this works with gcc_4_0_branch, which makes this a regression. Michael and Joost, Are you sure that anything is wrong with gfortran, here? If there is, I would agree that this is a regression. When Michael first posted PRs on ENTRY statements in modules, I was a bit startled because ENTRY statements are a bit contrary to the spirit of modules. That said, there is nothing wrong with it and. according to the standard: NOTE 11.3 Although statement function definitions, ENTRY statements, and FORMAT statements shall not appear in the specification part of a module, they may appear in the specification part of a module subprogram in the module. A module is host to any module subprograms (12.1.2.2) it contains, and the entities in the module are therefore accessible in the module subprograms through host association. Therefore, there is nothing wrong with having a module procedure with an entry and this note says that gfortran is right on first testscase, since setbd is made available by host association. From 12.5.2.5, we have: Because an ENTRY statement defines an additional function or an additional subroutine, it is referenced in the same manner as any other function or subroutine (12.4). I take it to mean that the ENTRY in the examples given is also made available by use association. Given these two bits of guidance from the standard, I believe that gfortran's behaviour is consistent and correct, until the additional function setbd is introduced. There, the complaint Global name 'setbd' at (1) is already being used as a FUNCTION at (2), which does not happen if the new function is called 'binden' says that there is indeed something wrong - the module entry is being promoted to a global symbol, which is not correct. The examples of #1 are indeed bugs but not really a regression - entry in modules did not work at all! Cheers Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33897
[Bug c++/31747] [4.2/4.3 regression] ICE combining static and extern
--- Comment #5 from paolo at gcc dot gnu dot org 2007-10-26 09:57 --- Subject: Bug 31747 Author: paolo Date: Fri Oct 26 09:57:12 2007 New Revision: 129647 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=129647 Log: cp/ 2007-10-26 Paolo Carlini [EMAIL PROTECTED] PR c++/31747 * decl.c (grokdeclarator): In case of conflicting specifiers just return error_mark_node. testsuite/ 2007-10-26 Paolo Carlini [EMAIL PROTECTED] PR c++/31747 * g++.dg/parse/crash39.C: New. Added: trunk/gcc/testsuite/g++.dg/parse/crash39.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31747
[Bug fortran/33897] [4.1/4.2/4.3 Regression] Entries and modules
--- Comment #6 from jv244 at cam dot ac dot uk 2007-10-26 10:42 --- (In reply to comment #5) As a final remark: Digital F90 5.0 gives the result of gfortran in #4, so now I am convinced that I am right! I was actually not so sure as you seem to be. I agree it is intuitive to consider it available through host association. I'm only surprised that NAG, IBM, g95, Lahey, pgf90 consistently say it is not (i.e. they all print 42 42 99). My judgement of 'regression' seems to have been a pilot error. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33897
[Bug libfortran/33905] New: show_backtrace hangs on SIGSEGV in malloc/free
The current implementation of show_backtrace hangs on a mutex lock in the malloc/free routines when a segmentation fault due to corruption of the malloc/free administration happens to trigger the backtrace. There is an alternative implementation using a temporary file to store the translation of address - symbol name that doesn't malloc storage (see 'man backtrace'). A work around is to force the hanging process to the background and using the attach functionality of gdb to force a backtrace with the where command. -- Summary: show_backtrace hangs on SIGSEGV in malloc/free Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: libfortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: toon at moene dot indiv dot nluug dot nl http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33905
[Bug fortran/33906] New: -fshape-check
Sometimes, when an array bounds overrun is detected, it is actually due to a shape mismatch between arrays in an expression / assignment. Fortran 2003, 7.1.5: For all elemental binary operations, the two operands shall be in shape conformance ... and mutatis mutandis for more complex expressions. The constraints on assignment are in 7.4.1.2. Because it's much cheaper to check for shape conformance violation than for array bound overruns, it might be useful to add an optional check for this. -- Summary: -fshape-check Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: toon at moene dot indiv dot nluug dot nl http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33906
[Bug c++/33744] [4.1/4.2/4.3 regression] function-style cast and '' not allowed in template argument
--- Comment #8 from jakub at gcc dot gnu dot org 2007-10-26 12:06 --- Subject: Bug 33744 Author: jakub Date: Fri Oct 26 12:06:31 2007 New Revision: 129650 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=129650 Log: PR c++/33744 * parser.c (cp_parser_parenthesized_expression_list): Set greater_than_is_operator_p to true in between the parens. * g++.dg/template/arg6.C: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/g++.dg/template/arg6.C Modified: branches/gcc-4_1-branch/gcc/cp/ChangeLog branches/gcc-4_1-branch/gcc/cp/parser.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33744
[Bug c++/33744] [4.1/4.2/4.3 regression] function-style cast and '' not allowed in template argument
--- Comment #7 from jakub at gcc dot gnu dot org 2007-10-26 12:05 --- Subject: Bug 33744 Author: jakub Date: Fri Oct 26 12:04:57 2007 New Revision: 129649 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=129649 Log: PR c++/33744 * parser.c (cp_parser_parenthesized_expression_list): Set greater_than_is_operator_p to true in between the parens. * g++.dg/template/arg6.C: New test. Added: branches/gcc-4_2-branch/gcc/testsuite/g++.dg/template/arg6.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 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33744
[Bug c++/33744] [4.1/4.2/4.3 regression] function-style cast and '' not allowed in template argument
--- Comment #6 from jakub at gcc dot gnu dot org 2007-10-26 11:58 --- Subject: Bug 33744 Author: jakub Date: Fri Oct 26 11:57:46 2007 New Revision: 129648 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=129648 Log: PR c++/33744 * parser.c (cp_parser_parenthesized_expression_list): Set greater_than_is_operator_p to true in between the parens. * g++.dg/template/arg6.C: New test. Added: trunk/gcc/testsuite/g++.dg/template/arg6.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33744
[Bug c++/33744] [4.1/4.2/4.3 regression] function-style cast and '' not allowed in template argument
--- Comment #9 from jakub at gcc dot gnu dot org 2007-10-26 12:07 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33744
[Bug preprocessor/33907] Empty macro definitions not considered equal
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-10-26 13:46 --- I know - I should have made this an enhancement request. Certainly there will be no observable difference for empty replacement lists, no? -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33907
[Bug preprocessor/33907] Empty macro definitions not considered equal
--- Comment #1 from schwab at suse dot de 2007-10-26 13:44 --- The standard requires the spelling of parameters to be the same even if the replacement list is empty. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33907
[Bug preprocessor/33907] New: Empty macro definitions not considered equal
#define A(a) #define A(b) g++-4.3 -S t.C t.C:2:1: error: A redefined t.C:1:1: error: this is the location of the previous definition We check the parameter names before the expansion, but if the expansion is empty in both cases there is no need to warn about different names. Of course watch out to still warn for #define A(a) a #define A(b) a which is why this only works for empty macros. The following would work for example: Index: macro.c === --- macro.c (revision 129646) +++ macro.c (working copy) @@ -1281,6 +1281,12 @@ warn_of_redefinition (cpp_reader *pfile, || macro1-variadic != macro2-variadic) return true; + /* If the macro expansion has no tokens there is no need to compare + parameters spellings. */ + if (macro1-count == 0 + macro2-count == 0) +return false; + /* Check parameter spellings. */ for (i = 0; i macro1-paramc; i++) if (macro1-params[i] != macro2-params[i]) -- Summary: Empty macro definitions not considered equal Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: diagnostic Severity: normal Priority: P3 Component: preprocessor AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rguenth at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33907
[Bug preprocessor/33907] Empty macro definitions not considered equal
--- Comment #3 from schwab at suse dot de 2007-10-26 13:55 --- The difference is that it is a constraint. You must diagnose it at least in pedantic mode. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33907
[Bug fortran/33897] [4.1/4.2/4.3 Regression] Entries and modules
--- Comment #7 from pault at gcc dot gnu dot org 2007-10-26 13:38 --- (In reply to comment #6) (In reply to comment #5) As a final remark: Digital F90 5.0 gives the result of gfortran in #4, so now I am convinced that I am right! I was actually not so sure as you seem to be. I agree it is intuitive to consider it available through host association. I'm only surprised that NAG, IBM, g95, Lahey, pgf90 consistently say it is not (i.e. they all print 42 42 99). How about I take it to comp.lang.fortran? I find nothing in the standard that says that entries should not be host associated and plenty to say that they should. Why would entrys be availeble by use association and not by host association within the module? Anyway, thanks for giving it your attention. Cheers Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33897
[Bug preprocessor/33907] Empty macro definitions not considered equal
--- Comment #4 from joseph at codesourcery dot com 2007-10-26 14:45 --- Subject: Re: New: Empty macro definitions not considered equal On Fri, 26 Oct 2007, rguenth at gcc dot gnu dot org wrote: #define A(a) #define A(b) g++-4.3 -S t.C t.C:2:1: error: A redefined t.C:1:1: error: this is the location of the previous definition We check the parameter names before the expansion, but if the expansion is empty in both cases there is no need to warn about different names. Both C and C++ require diagnostics here, my interpretation being that they are required even if the only spelling difference is a different UCN for the same identifier (bug 9449 comment 39). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33907
[Bug ada/33908] New: gcc Ada does not handle fixed point division correctly in Ada 83 mode
gcc -c -gnat83 test.adb
procedure Test
is
type T is delta 0.1 range 0.0 .. 10.0;
X : T;
begin
X := 10.0;
X := T (X / 10.0);
end Test;
XD-Ada rejects the test program with the following error message,
%ADAC-E-UNIVFIXUNIVOPND, (1) Multiplication or division for fixed-point type T
is not allowed with an operand of type {universal_real} [LRM 4.5.5(10-11)]
gcc Ada compiles the test program (in Ada 83 mode) with no errors.
I believe XD-Ada to be correct, and gcc Ada to be incorrect, for the following
reason. Ada 83 LRM 4.6 states, An implicit conversion of a convertible
universal operand is applied if and only if the innermost complete context (see
8.7) determines a unique (numeric) target type for the implicit conversion, and
there is no legal interpretation of this context without this conversion. In
this case, there is no unique target type for the implicit conversion, since
Ada 83 allowed division between any two fixed point types.
--
Summary: gcc Ada does not handle fixed point division correctly
in Ada 83 mode
Product: gcc
Version: 3.4.5
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dewi dot daniels at silver-software dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33908
[Bug c++/33909] New: Error reported on a legal source: invalid use of non-lvalue array when array name is used in initializer
Compiling the following code with g++ result in error. Command line to
reproduce the error is arm-linux-gnueabi-g++ -c test.cpp, where test.cpp is
the file comprising the following lines:
struct T
{
const void* ptr;
};
const struct T my_arr[] =
{
{ 0 },
{ my_arr+1 }// Error at this line
};
Error is: invalid use of non-lvalue array
This error is reported only when compiling as C++ code. Compilation with gcc or
with -xc is successful.
I think that the code above perfectly meet C++ standard because:
1. According to 3.3.1p1, the point of declaration of my_arr is immediately
before =. Thus, the name my_arr is properly introduced and can be used in
the initializer.
2. Expression my_arr+1 should be treated as: Array-to-pointer conversion
(4.2p1), additive operator + (5.7p1). Resulting pointer does not exceed array
boundaries, so the expression is well-formed and it has legal result.
3. Whether my_arr is an lvalue or an rvalue expression is not important,
because array-to-pointer conversion is defined for lvalue and rvalue arrays
(4.2p1). Which makes error message irrelevant, because such use is valid.
4. However, I believe that expression my_arr is an lvalue expression because
it refers to an object (3.10p2). The fact that the object is const (i.e.
non-modifiable) doesn't make it non-lvalue.
Output of arm-linux-gnueabi-g++ -v is:
Using built-in specs.
Target: arm-none-linux-gnueabi
Configured with:
/home/toolbuilder/tools_build/build.arm-linux-gnueabi/gcc-4.1.1/configure
--target=arm-none-linux-gnueabi
--prefix=/usr/toolchain/arm-linux-gnueabi/gcc-4.1.1
--with-local-prefix=/usr/toolchain/arm-linux-gnueabi/gcc-4.1.1/local
--with-sysroot=/usr/toolchain/arm-linux-gnueabi/sysroot-arm11-linux-2.6.17.8-glibc-2.4
--enable-languages=c,c++ --enable-c99
--program-transform-name=s/.*/arm-linux-gnueabi--4.1.1/ --enable-shared
--enable-__cxa_atexit --disable-libunwind-exceptions --enable-threads=posix
--enable-symvers=gnu --enable-long-long --disable-cpp --with-gnu-as
--with-gnu-ld
--with-as=/usr/toolchain/arm-linux-gnueabi/bin/arm-linux-gnueabi-as
--with-ld=/usr/toolchain/arm-linux-gnueabi/bin/arm-linux-gnueabi-ld
--with-nm=/usr/toolchain/arm-linux-gnueabi/bin/arm-linux-gnueabi-nm
--with-objdump=/usr/toolchain/arm-linux-gnueabi/bin/arm-linux-gnueabi-objdump
--disable-nls --disable-multilib
Thread model: posix
gcc version 4.1.1
--
Summary: Error reported on a legal source: invalid use of non-
lvalue array when array name is used in initializer
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: igusarov at mail dot ru
GCC build triplet: i386-unknown-freebsd5.4
GCC host triplet: i386-unknown-freebsd5.4
GCC target triplet: arm-none-linux-gnueabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33909
[Bug c++/33900] (exception handling) bad/inconsistent code generation
--- Comment #3 from darkxun at paran dot com 2007-10-26 14:43 --- Also I needed to search the web or the manuals. Sorry. And thanks for the comment about the option -fnon-call-exceptions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33900
[Bug ada/33910] New: gcc Ada doesn't handle address clauses correctly in Ada 83 mode
gcc -c -gnat83 test.adb procedure Test is X : INTEGER; Y : INTEGER; for Y use at X'ADDRESS; begin null; end Test; XD-Ada generates the error message, %ADAC-E-ADRREPNOSYS, (1) No with clause for predefined package SYSTEM applies to this unit [LRM 10.1.1(4), 13.5(3)] Ada 83 LRM 13.5 states that package SYSTEM must be named by a with clause that applies to the compilation unit in which the address clause occurs. -- Summary: gcc Ada doesn't handle address clauses correctly in Ada 83 mode Product: gcc Version: 3.4.5 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dewi dot daniels at silver-software dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33910
[Bug c++/33911] New: attribute deprecated vs. templates
In the following example, class foo gets a deprecated warning, but a similar
class template goo does not. Typedefs constructed with foo or goo get an
error.
What up?
struct foo
{
int i;
} __attribute__ ((__deprecated__));
templatetypename _Tp
struct goo
{
int i;
} __attribute__ ((__deprecated__));
typedef foo foo_type __attribute__ ((__deprecated__));
typedef gooint goo_type __attribute__ ((__deprecated__));
int main()
{
foo f1;
gooint f2;
foo_type f3;
goo_type f4;
return 0;
}
I have a patch to mark the C++0x bits deprecated, but it's not working because
of this issue.
--
Summary: attribute deprecated vs. templates
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bkoz at gcc dot gnu dot org
GCC host triplet: all
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33911
[Bug fortran/33897] [4.1/4.2/4.3 Regression] Entries and modules
--- Comment #8 from jv244 at cam dot ac dot uk 2007-10-26 14:54 --- (In reply to comment #7) How about I take it to comp.lang.fortran? yes, and Ron has given the golden clue (how easy to overlook these things). Indeed, the integer declaration of setbd in nxtstg implies that the external one has to be called as the host-associated one is inaccessible (14.6.1.3). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33897
[Bug c++/33842] [4.1/4.2/4.3 regression] Broken diagnostic: 'offsetof_expr' not supported by dump_expr
-- 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 |2007-10-26 14:57:28 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33842
[Bug libgomp/33894] [libgomp/parallel mode] pragma omp atomic broken
--- Comment #3 from singler at ira dot uka dot de 2007-10-26 15:22 --- Preprocessed source as attached. Apparently, the file is slightly to big. So I put it here: http://algo2.iti.uni-karlsruhe.de/singler/GCCTrunkTest.cpp -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33894
[Bug c++/33912] New: attribute deprecated vs. templates
In the following example, class foo gets a deprecated warning, but a similar
class template goo does not. Typedefs constructed with foo or goo get an
error.
What up?
struct foo
{
int i;
} __attribute__ ((__deprecated__));
templatetypename _Tp
struct goo
{
int i;
} __attribute__ ((__deprecated__));
typedef foo foo_type __attribute__ ((__deprecated__));
typedef gooint goo_type __attribute__ ((__deprecated__));
int main()
{
foo f1;
gooint f2;
foo_type f3;
goo_type f4;
return 0;
}
I have a patch to mark the C++0x bits deprecated, but it's not working because
of this issue.
--
Summary: attribute deprecated vs. templates
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bkoz at gcc dot gnu dot org
GCC host triplet: all
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33912
[Bug fortran/33897] [4.1/4.2/4.3 Regression] Entries and modules
--- Comment #9 from burnus at gcc dot gnu dot org 2007-10-26 15:51 --- How about I take it to comp.lang.fortran? http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/3076af3caa74347d/ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33897
[Bug c++/33911] attribute deprecated vs. templates
--- Comment #1 from pcarlini at suse dot de 2007-10-26 16:08 --- *** Bug 33912 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33911
[Bug fortran/33913] f771: ../../src/gcc/f/com.c:7504: ffecom_sym_transform_: Assertion `0 == compare_tree_int (((t)-decl.size_unit), ((st)-size))' failed.
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-10-26 16:33 --- t.F:1035: error: dim.par: No such file or directory t.F:1036: error: machconst.com: No such file or directory t.f: In function 'gencan': t.f:216: error: size of variable 'h' is too large If I use -m64, I don't get an error for that variable so this has been fixed. -- pinskia 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=33913
[Bug fortran/33913] f771: ../../src/gcc/f/com.c:7504: ffecom_sym_transform_: Assertion `0 == compare_tree_int (((t)-decl.size_unit), ((st)-size))' failed.
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-10-26 16:32 --- f/com.c only exist in 3.4.x and before, can you try compiling with gfortran in 4.0.x (or 4.1.x or 4.2.x)? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|blocker |normal Version|4.1.2 |3.4.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33913
[Bug fortran/33913] f771: ../../src/gcc/f/com.c:7504: ffecom_sym_transform_: Assertion `0 == compare_tree_int (((t)-decl.size_unit), ((st)-size))' failed.
--- Comment #1 from egbirgin at ime dot usp dot br 2007-10-26 16:11 --- Created an attachment (id=14412) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14412action=view) solely Fortran program that cause the bug when compiled Just compile the attachment with: g77 -O4 -xf77-cpp-input -Wimplicit -Wunused -c bug.f to reproduce the bug -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33913
[Bug fortran/33913] New: f771: ../../src/gcc/f/com.c:7504: ffecom_sym_transform_: Assertion `0 == compare_tree_int (((t)-decl.size_unit), ((st)-size))' failed.
g77 -O4 -xf77-cpp-input -Wimplicit -Wunused -c bug.f f771: ../../src/gcc/f/com.c:7504: ffecom_sym_transform_: Assertion `0 == compare_tree_int (((t)-decl.size_unit), ((st)-size))' failed. bug.f: In subroutine `gencan': In file included from bug.f:0: bug.f:216: internal compiler error: Aborted Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. For Debian GNU/Linux specific bug reporting instructions, see URL:file:///usr/share/doc/gcc-3.4/README.Bugs. -- Summary: f771: ../../src/gcc/f/com.c:7504: ffecom_sym_transform_: Assertion `0 == compare_tree_int (((t)-decl.size_unit), ((st)-size))' failed. Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: egbirgin at ime dot usp dot br GCC build triplet: Configured with: ../src/configure -v --enable- languages=c,c++,fo GCC host triplet: Using built-in specs. GCC target triplet: Target: x86_64-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33913
[Bug c++/33844] [4.1/4.2/4.3 regression] Broken diagnostic: 'dotstar_expr/member_ref' not supported by pp_cxx_unqualified_id
-- 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 |2007-10-26 16:17:00 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33844
[Bug c++/33894] [4.3 Regression] pragma omp atomic broken
--- Comment #4 from jakub at gcc dot gnu dot org 2007-10-26 17:38 --- Seems Paolo's 2007-02-05 OMP_ATOMIC changes broke this. -- 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|WAITING |ASSIGNED Component|libgomp |c++ Ever Confirmed|0 |1 Known to fail||4.3.0 Known to work||4.2.0 Last reconfirmed|-00-00 00:00:00 |2007-10-26 17:38:53 date|| Summary|[libgomp/parallel mode] |[4.3 Regression] pragma omp |pragma omp atomic broken|atomic broken Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33894
[Bug c++/33839] [4.3 regresssion] ICE with decltype
--- Comment #2 from dgregor at gcc dot gnu dot org 2007-10-26 17:54 ---
Subject: Bug 33839
Author: dgregor
Date: Fri Oct 26 17:53:56 2007
New Revision: 129656
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=129656
Log:
2007-10-26 Douglas Gregor [EMAIL PROTECTED]
PR c++/33839
* parser.c (cp_parser_decltype): Return ERROR_MARK_NODE if we
don't see the leading '('. Only lookup names if we get an
IDENTIFIER_NODE.
2007-10-26 Douglas Gregor [EMAIL PROTECTED]
* g++.dg/cpp0x/pr33839.C: New.
Added:
trunk/gcc/testsuite/g++.dg/cpp0x/pr33839.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/parser.c
trunk/gcc/testsuite/ChangeLog
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33839
[Bug fortran/33881] incorrect code for optional assumed length character arrays ?
--- Comment #6 from jv244 at cam dot ac dot uk 2007-10-26 17:54 ---
reduced testcase still failing with valgrind
character(len=4), dimension(4) :: default_clocks=
call create_watch_ss('total')
contains
subroutine create_watch_actual(clock,name)
character(len=*), dimension(:) :: clock
character(len=*), dimension(:) :: name
end subroutine create_watch_actual
subroutine create_watch_ss(name,clock)
character(len=*), optional :: clock
character(len=*) :: name
if (present(clock)) then
call create_watch_actual((/clock/),(/name/))
else
call create_watch_actual(default_clocks,(/name/))
end if
end subroutine create_watch_ss
end
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33881
[Bug c++/33839] [4.3 regresssion] ICE with decltype
--- Comment #3 from dgregor at gcc dot gnu dot org 2007-10-26 18:01 --- Fixed. The testcase is invalid code, but we shouldn't crash on it. Now we don't. -- dgregor at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33839
[Bug libstdc++/9925] ostrstream (buf, size) ... does not work properly
--- Comment #26 from jason at gcc dot gnu dot org 2007-10-26 17:32 --- Changed component to libstdc++. This problem should be fixed by adding rvalue reference support to iostreams; the current working paper calls for templateclass traits basic_ostreamchar,traits operator(basic_ostreamchar,traits out, const unsigned char* s); which should make the original testcase work as expected. Though I find it surprising that this signature returns an lvalue reference rather than rvalue. -- jason at gcc dot gnu dot org changed: What|Removed |Added CC||bkoz at redhat dot com Component|c++ |libstdc++ http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9925
[Bug c++/31988] new operator should not permit default first parameter
--- Comment #7 from paolo at gcc dot gnu dot org 2007-10-26 18:32 --- Subject: Bug 31988 Author: paolo Date: Fri Oct 26 18:32:41 2007 New Revision: 129657 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=129657 Log: cp/ 2007-10-26 Paolo Carlini [EMAIL PROTECTED] PR c++/31988 * decl2.c (coerce_new_type): Do not allow a default argument for the first parameter. testsuite/ 2007-10-26 Paolo Carlini [EMAIL PROTECTED] PR c++/31988 * g++.dg/init/new25.C: New. Added: trunk/gcc/testsuite/g++.dg/init/new25.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl2.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31988
[Bug c++/31988] new operator should not permit default first parameter
--- Comment #8 from pcarlini at suse dot de 2007-10-26 18:34 --- Fixed for 4.3.0. -- pcarlini at suse dot de changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31988
[Bug c++/33837] [4.3 regresssion] ICE with invalid use of decltype
--- Comment #1 from dgregor at gcc dot gnu dot org 2007-10-26 18:36 --- Same problem as 33839; fixed now. *** This bug has been marked as a duplicate of 33839 *** -- dgregor at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33837
[Bug c++/33839] [4.3 regresssion] ICE with decltype
--- Comment #4 from dgregor at gcc dot gnu dot org 2007-10-26 18:36 --- *** Bug 33837 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33839
[Bug c++/33838] [4.3 regresssion] ICE with invalid use of decltype
--- Comment #1 from dgregor at gcc dot gnu dot org 2007-10-26 18:38 --- Same problem as in 33839; fixed by that patch. *** This bug has been marked as a duplicate of 33839 *** -- dgregor at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33838
[Bug c++/33839] [4.3 regresssion] ICE with decltype
--- Comment #5 from dgregor at gcc dot gnu dot org 2007-10-26 18:38 --- *** Bug 33838 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33839
[Bug c++/33914] New: False warning: allocating zero-element array
Compile
begin of test.cpp
int main()
{
const unsigned nElementCount = 0;
int *piArray = nElementCount ? new int[nElementCount] : 0;
return 0;
}
end of test.cpp
Compiler displays a warning even though new operator is never executed:
test.cpp: In function 'int main()':
test.cpp:4: warning: allocating zero-element array
It does not depend on optimization.
--
Summary: False warning: allocating zero-element array
Product: gcc
Version: 4.2.1
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: oder at eleks dot lviv dot ua
GCC build triplet: x86
GCC host triplet: x86
GCC target triplet: x86
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33914
[Bug c++/33914] False warning: allocating zero-element array
--- Comment #1 from pcarlini at suse dot de 2007-10-26 18:58 --- *** This bug has been marked as a duplicate of 33124 *** -- pcarlini at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33914
[Bug c++/33124] C++ frontend should not warn about new a[0] in template context
--- Comment #10 from pcarlini at suse dot de 2007-10-26 18:58 --- *** Bug 33914 has been marked as a duplicate of this bug. *** -- pcarlini at suse dot de changed: What|Removed |Added CC||oder at eleks dot lviv dot ||ua http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33124
[Bug c++/33601] [4.3 regression] ICE with pointers to members using const C as the class identifier
--- Comment #2 from dgregor at gcc dot gnu dot org 2007-10-26 19:34 --- Subject: Bug 33601 Author: dgregor Date: Fri Oct 26 19:34:03 2007 New Revision: 129659 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=129659 Log: 2007-10-26 Douglas Gregor [EMAIL PROTECTED] PR c++/33601 * tree.c (build_offset_type): Build canonical type based on the TYPE_MAIN_VARIANT of the base type. 2007-10-26 Douglas Gregor [EMAIL PROTECTED] * g++.dg/other/pr33601.C: New. Added: trunk/gcc/testsuite/g++.dg/other/pr33601.C Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33601
[Bug c++/33601] [4.3 regression] ICE with pointers to members using const C as the class identifier
--- Comment #3 from dgregor at gcc dot gnu dot org 2007-10-26 19:35 --- Fixed. -- dgregor at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33601
[Bug c++/24791] ICE on invalid instantiation of template's static member
--- Comment #12 from jason at gcc dot gnu dot org 2007-10-26 19:54 --- Subject: Bug 24791 Author: jason Date: Fri Oct 26 19:54:10 2007 New Revision: 129660 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=129660 Log: PR c++/24791 * pt.c (get_template_info): New fn. (template_class_depth): Use it. (push_template_decl_real): Check that the template args of the definition match the args of the previous declaration. Added: trunk/gcc/testsuite/g++.dg/template/error33.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-tree.h trunk/gcc/cp/pt.c trunk/gcc/testsuite/g++.old-deja/g++.pt/crash11.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24791
[Bug tree-optimization/33915] New: iv folding fails with pointer iterations
void
cyg_hal_plf_serial_write(void* __ch_data, const unsigned char* __buf,
unsigned long __len)
{
while(__len-- 0)
cyg_hal_plf_serial_putc(__ch_data, *__buf++);
}
cc1 -O3 -mcpu=m32c dj.c
fails in build2_stat trying to add two pointers.
See also http://gcc.gnu.org/ml/gcc/2007-10/msg00435.html
--
Summary: iv folding fails with pointer iterations
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: rakdver at kam dot mff dot cuni dot cz
ReportedBy: dj at redhat dot com
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: m32c-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33915
[Bug fortran/33913] f771: ../../src/gcc/f/com.c:7504: ffecom_sym_transform_: Assertion `0 == compare_tree_int (((t)-decl.size_unit), ((st)-size))' failed.
--- Comment #4 from burnus at gcc dot gnu dot org 2007-10-26 21:06 --- (In reply to comment #2) f/com.c only exist in 3.4.x and before, can you try compiling with gfortran in 4.0.x (or 4.1.x or 4.2.x)? To add: g77 was part of GCC 3.x. Starting from GCC 4.0.0, the Fortran compiler of the GCC suite is called gfortran. gfortran supports Fortran 77, Fortran 95 and some parts of Fortran 2003 and supports almost all g77 extensions. GCC 3.x and 4.0.x are no longer maintained. As this bug does not occur with gfortran, I would recomment to update to GCC 4.1.x or later. Binary builds of the experimental GCC 4.3.0 are available from: http://gcc.gnu.org/wiki/GFortranBinaries Note: If you have a more-or-less recent Linux distribution, it might well be that it ships gfortran (and g77 is only additionally provided). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33913
[Bug fortran/33881] [4.3 Regression] incorrect code for optional assumed length character arrays ?
--- Comment #7 from burnus at gcc dot gnu dot org 2007-10-26 21:16 --- Works: 2007-07-13-r126613 Fails: 2007-07-16-r126671 -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||burnus at gcc dot gnu dot ||org Known to fail||4.3.0 Known to work||4.2.2 4.1.3 Summary|incorrect code for optional |[4.3 Regression] incorrect |assumed length character|code for optional assumed |arrays ?|length character arrays ? http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33881
[Bug c++/33916] New: Default constructor fails to initialize array members
(This may be related to PR 30111 )
In this program, a default constructor fails to initialize the given array
members to zero. Results are shown with several versions of gcc.
===
#include string.h
#include iostream
namespace {
class Stats {
friend void alpha();
private:
int a_[12];
int b_[12];
};
void dirty_stack() {
char array[4096];
memset(array, 0x11, 4096);
}
void alpha() {
Stats my_stats = Stats();
for (int i = 0; i 12; ++i) {
std::cout my_stats.a_[i] ;
}
std::cout std::endl;
}
}
int main() {
dirty_stack();
alpha();
return 0;
}
===
[EMAIL PROTECTED]:~/exp-array-default$ /home/mec/gcc-4.1.2/install/bin/g++
z3.cc
./a.out
0 0 0 0 0 0 0 0 0 0 0 0
[EMAIL PROTECTED]:~/exp-array-default$ /home/mec/gcc-4.2.2/install/bin/g++
z3.cc
./a.out
286331153 286331153 286331153 286331153 286331153 286331153 286331153 286331153
286331153 286331153 286331153 286331153
[EMAIL PROTECTED]:~/exp-array-default$
/home/mec/gcc-4.3-20071019/install/bin/g++
z3.cc ./a.out
286331153 286331153 286331153 286331153 286331153 286331153 286331153 286331153
286331153 286331153 286331153 286331153
--
Summary: Default constructor fails to initialize array members
Product: gcc
Version: 4.2.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mec at google 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=33916
[Bug fortran/33917] New: Rejects valid procedure declarations
This one is a heisenbug, which showed up in the testsuite while testing a patch but is also present on trunk: $ cat proc_decl_2.f90 program s implicit none procedure() :: q2 procedure() :: q3 procedure() :: q5 procedure(sub) :: p4 procedure(p4) :: p6 contains subroutine sub end subroutine end program s $ gfortran proc_decl_2.f90 proc_decl_2.f90:7.21: procedure(p4) :: p6 1 Error: Interface 'p4' of procedure 'p6' at (1) must be explicit -- Summary: Rejects valid procedure declarations Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: rejects-valid Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: fxcoudert at gcc dot gnu dot org 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=33917
[Bug fortran/33917] Rejects valid procedure declarations
--- Comment #1 from burnus at gcc dot gnu dot org 2007-10-26 21:59 --- As depending which line is commented out or not, the bug disappears or appears, my educated guess would be that one does not properly walk a tree and thus not all leafs are found. -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||burnus at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-10-26 21:59:55 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33917
[Bug fortran/31608] wrong types in character array/scalar binop
--- Comment #50 from rguenth at gcc dot gnu dot org 2007-10-26 22:17 --- Note that I still see achar_4.f90 fail with type-checking and there are now some more testcases that also fail. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31608
[Bug libfortran/20278] Performance of formatted output
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2007-10-26 22:43 --- Probably too generic to be useful, and we're not doing so bad. Closing (with Jerry's approval). -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20278
[Bug libfortran/31501] libgfortran internal unit I/O performance issues
--- Comment #11 from fxcoudert at gcc dot gnu dot org 2007-10-26 22:43 --- Probably too generic to be useful, and we're not doing so bad. Closing (with Jerry's approval). -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31501
[Bug c++/32125] [4.3 regression] ICE with invalid specialization of variadic template
-- pcarlini at suse dot de changed: What|Removed |Added AssignedTo|pcarlini at suse dot de |unassigned at gcc dot gnu ||dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32125
[Bug c++/32126] [4.3 regression] ICE with invalid definition of variadic template
-- pcarlini at suse dot de changed: What|Removed |Added AssignedTo|pcarlini at suse dot de |unassigned at gcc dot gnu ||dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32126
[Bug fortran/33881] [4.3 Regression] incorrect code for optional assumed length character arrays ?
--- Comment #8 from fxcoudert at gcc dot gnu dot org 2007-10-26 22:26 --- Reduced-reduced testcase which still triggers valgrind: call create_watch_ss( ) contains subroutine create_watch_actual(name) character(len=1) :: name(1) end subroutine create_watch_actual subroutine create_watch_ss(name,clock) character(len=*) :: name integer, optional :: clock if (present(clock)) then call create_watch_actual((/name/)) else call create_watch_actual((/name/)) end if end subroutine create_watch_ss end It's apparent form the dump that, in the second branch of the IF, we use variables declared in the first branch. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2007-10-26 07:17:07 |2007-10-26 22:26:14 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33881
[Bug fortran/33881] [4.3 Regression] incorrect code for optional assumed length character arrays ?
--- Comment #9 from fxcoudert at gcc dot gnu dot org 2007-10-26 22:40 --- And the smaller testcase with invalid dump: subroutine create_watch_ss (name,l) character(len=*) :: name logical l if (l) then call create_watch_actual([name]) else call create_watch_actual([name]) end if end -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33881
[Bug fortran/33917] Rejects valid procedure declarations
--- Comment #2 from burnus at gcc dot gnu dot org 2007-10-26 23:14 --- procedure(sub) :: p4 procedure(p4) :: p6 The problem is that first sub needs to be resolved for p4 and then p4 before p6. The problem is that procedure(p4) :: p6 is checked before procedure(sub) :: p4 and that thus for p6 sym-interface-attr.if_source == IFSRC_UNKNOWN instead of IFSRC_DECL. This seems to be a tree-walking problem. The solution is to make sure the interfaces are resolved first such that the following holds true: /* Get the attributes from the interface (now resolved). */ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33917
[Bug rtl-optimization/33828] Issues with the implementation of code hoisting in gcse.c
--- Comment #7 from steven at gcc dot gnu dot org 2007-10-26 23:32 --- Running multiple code hoisting passes currently does not work, because one_code_hoisting_pass() never returns non-zero. Therefore, in the main loop of gcse_main() changed is never set to true, and --param max-gcse-passes has no effect. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33828
[Bug fortran/31608] wrong types in character array/scalar binop
--- Comment #51 from danglin at gcc dot gnu dot org 2007-10-27 00:21 --- Subject: Bug 31608 Author: danglin Date: Sat Oct 27 00:21:02 2007 New Revision: 129671 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=129671 Log: PR fortran/31608 * pa.h (ASM_PN_FORMAT): Delete define. Modified: trunk/gcc/ChangeLog trunk/gcc/config/pa/pa.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31608
[Bug c/33918] New: GCC failed to produce assembler output with -masm=intel option
This happened to me when I wanted to look at assembler output source using gcc
-S and for better readability choose -masm=intel option. -S only works fine. I
tried to cut my source and include short example which can be quickly verified.
I also checked this problem happen on mingw32 gcc ver 3.4.5
Try to compile this: gcc -S x.c -masm=intel
x.c:
=
#include stdlib.h
#include stdio.h
typedef struct {
unsigned long offset; // 32-bit offset
unsigned short selector; // 16-bit selector
} __attribute__((packed)) PM_FAR_POINTER;
int exec_ring0_code(unsigned long code_address, unsigned long ecx, unsigned
long *eax, unsigned long *edx)
{
PM_FAR_POINTER callgate_ptr;
asm __volatile__ (
lcall *%5\n
: =a(*eax), =d(*edx)
: a(*eax), c(ecx), d(*edx), m (callgate_ptr)
: memory
);
return(0);
}
=
result is:
x.c: In function 'exec_ring0_code':
x.c:19: internal compiler error: in print_operand, at config/i386/i386.c:7961
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
Assembler output x.S stops at line
lcall *
when I compile it with gcc -S x.c only it compile all without error
and mentioned line looks this:
lcall *-6(%ebp)
--
Summary: GCC failed to produce assembler output with -masm=intel
option
Product: gcc
Version: 4.2.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rayer at seznam dot cz
GCC build triplet: i386-pc-dos-djgpp, win32-mingw
GCC host triplet: i386-pc-dos-djgpp, win32-mingw
GCC target triplet: i386-pc-dos-djgpp, win32-mingw
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33918
[Bug fortran/31608] wrong types in character array/scalar binop
--- Comment #52 from dave at hiauly1 dot hia dot nrc dot ca 2007-10-27 00:29 --- Subject: Re: wrong types in character array/scalar binop Fixed on PA. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31608
[Bug preprocessor/33919] New: __BASE_FILE__ does not expand correctly when included from the command line
If the following line is present in an include file, test_base_file.h:
char *base_file = __BASE_FILE__;
And it is included as follows:
gcc -include test_base_file.h test_base_file.c -o test_base_file
The base file value will be printed as follows:
base file = command line
by this main program:
#include stdio.h
int
main ()
{
printf (base file = %s\n, base_file);
}
If the program is changed ton include test_base_file.h directly
and the -include switch is removed from the command line, the
expected result (test_base_file.c) is printed.
This behavior was noted in GCC 3.0, and is still present in 4.2.0.
I think that it is likely in the development head version as well,
but have not verified that.
--
Summary: __BASE_FILE__ does not expand correctly when included
from the command line
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: preprocessor
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gary at intrepid dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33919
[Bug target/33918] GCC failed to produce assembler output with -masm=intel option
--- Comment #1 from dannysmith at users dot sourceforge dot net 2007-10-27 00:52 --- Same error message as http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18353 This works with revision 129548 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33918
[Bug fortran/33162] INTRINSIC functions as ACTUAL argument
--- Comment #10 from jvdelisle at gcc dot gnu dot org 2007-10-27 00:54 --- Subject: Bug 33162 Author: jvdelisle Date: Sat Oct 27 00:54:20 2007 New Revision: 129673 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=129673 Log: 2007-10-26 Jerry DeLisle [EMAIL PROTECTED] PR fortran/33162 * intrinsic.h: Add prototypes for four new functions, gfc_check_datan2, gfc_check_dprod, gfc_check_fn_d, and gfc_check_x_yd. * intrinsic.c (add_functions): Add double precision checks for dabs, dacos, dacosh, dasin, dasinh, datan, datanh, datan2, dbesj0, dbesj1, dbesy0, dbesy1, dcos, dcosh, ddim, derf, derfc, dexp, dgamma, dlgama, dlog, dlog10, dmod, dsign, dsin, dsinh, dsqrt, dtan, and dtanh. Add real check dprod. * check.c (gfc_check_datan2): New function to check for double precision argumants. (gfc_check_dprod, gfc_check_fn_d, and gfc_check_x_yd): Ditto. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/check.c trunk/gcc/fortran/intrinsic.c trunk/gcc/fortran/intrinsic.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33162
[Bug preprocessor/33919] __BASE_FILE__ does not expand correctly when included from the command line
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-10-27 00:56 --- http://gcc.gnu.org/ml/gcc/2004-10/msg00534.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33919
[Bug fortran/33162] INTRINSIC functions as ACTUAL argument
--- Comment #11 from jvdelisle at gcc dot gnu dot org 2007-10-27 00:57 --- Subject: Bug 33162 Author: jvdelisle Date: Sat Oct 27 00:57:26 2007 New Revision: 129674 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=129674 Log: 2007-10-26 Jerry DeLisle [EMAIL PROTECTED] PR fortran/33162 * gfortran.dg/argument_checking_9.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/argument_checking_9.f90 Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33162
[Bug target/33918] GCC failed to produce assembler output with -masm=intel option
--- Comment #2 from rayer at seznam dot cz 2007-10-27 01:04 --- (In reply to comment #1) Same error message as http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18353 This works with revision 129548 Oh, sorry for that, I was searching for -masm and nothing found. Anyway well I'll wait for new DJGPP and MinGW 4.3.0 ports... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33918
[Bug preprocessor/33919] __BASE_FILE__ does not expand correctly when included from the command line
--- Comment #2 from gary at intrepid dot com 2007-10-27 01:05 --- Subject: Re: __BASE_FILE__ does not expand correctly when included from the command line Andrew, thanks for linking in that e-mail thread. FYI, I worked out a simple fix that I implemented in 3.0, and I think Zack made a different fix, but somehow it didn't seem to make it into 4.x, I guess. - Gary -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33919
