[Bug libstdc++/35942] New: Self Reference In Dinamic Linked Library builds for building Cross-Compiler
While building a cross-compiler, the the libstdc++-v3 includes a copy of
Libtool script, which includes a reference to libstdc++ itself. This prevent
the user to build a new compiler without existing libstdc++ for the target
triplet.
The following is a patch that tested to be working for this problem, but I
think it should be done in a better way.
###BEGIN OF PATCH CODE##
diff -Naur gcc-4.3-20080410.orig/libstdc++-v3/src/Makefile.in
gcc-4.3-20080410/libstdc++-v3/src/Makefile.in
--- gcc-4.3-20080410.orig/libstdc++-v3/src/Makefile.in 2008-03-01
05:26:50.0 +1100
+++ gcc-4.3-20080410/libstdc++-v3/src/Makefile.in 2008-04-14
23:16:35.0 +1000
@@ -212,6 +212,7 @@
LIBS = @LIBS@
LIBSUPCXX_PICFLAGS = @LIBSUPCXX_PICFLAGS@
LIBTOOL = @LIBTOOL@
+LIBTOOLLINK = @[EMAIL PROTECTED]
LN_S = @LN_S@
LTLIBICONV = @LTLIBICONV@
LTLIBOBJS = @LTLIBOBJS@
@@ -472,7 +473,7 @@
# course is problematic at this point. So, we get the top-level
# directory to configure libstdc++-v3 to use gcc as the C++
# compilation driver.
-CXXLINK = $(LIBTOOL) --tag CXX --mode=link $(CXX) \
+CXXLINK = $(LIBTOOLLINK) --tag CXX --mode=link $(CXX) \
$(OPT_LDFLAGS) $(SECTION_LDFLAGS) $(AM_CXXFLAGS) $(LTLDFLAGS) -o $@
debugdir = debug
@@ -536,7 +537,8 @@
echo rm -f \$${dir}/so_locations\; \
rm -f $${dir}/so_locations; \
done
-libstdc++.la: $(libstdc___la_OBJECTS) $(libstdc___la_DEPENDENCIES)
+libstdc++.la: $(libstdc___la_OBJECTS) $(libstdc___la_DEPENDENCIES)
+ sed '/postdeps=/[EMAIL PROTECTED]@\-lm@' `echo $(LIBTOOL) | cut -d\
-f2`
`echo $(LIBTOOLLINK) | cut -d\ -f2`
$(CXXLINK) -rpath $(toolexeclibdir) $(libstdc___la_LDFLAGS)
$(libstdc___la_OBJECTS) $(libstdc___la_LIBADD) $(LIBS)
mostlyclean-compile:
###END OF PATCH CODE##
--
Summary: Self Reference In Dinamic Linked Library builds for
building Cross-Compiler
Product: gcc
Version: 4.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: earthengine at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35942
[Bug c++/35909] [4.4 Regression] ICE with bit-field and const references
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-04-15 08:57 --- It did work with: GNU C++ (GCC) version 4.3.0 20080128 (experimental) [trunk revision 131899] (i386-apple-darwin8.10.1) But fails with: GNU C++ (GCC) version 4.4.0 20080304 (experimental) [trunk revision 132852] (i386-apple-darwin8.10.1) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35909
[Bug middle-end/35509] [4.3/4.4 Regression] builtin isinf() mismatch to compile-time substitution
--- Comment #11 from rguenther at suse dot de 2008-04-15 08:58 --- Subject: Re: [4.3/4.4 Regression] builtin isinf() mismatch to compile-time substitution On Tue, 15 Apr 2008, ghazi at gcc dot gnu dot org wrote: --- Comment #10 from ghazi at gcc dot gnu dot org 2008-04-15 01:36 --- (In reply to comment #8) I propose that we do the following: - add a warning to the C/C++ frontends that isinf (x) CMP isinf (y) is only well-defined for !isinf (x) !isinf (y). this doesn't result in a runtime penalty and informs people about the possible problem in their code (it is non-portable). IMHO the above warning would have limited coverage because there are other ways users can test the results of isinf that would run into the sign problem. Well, of course. A different workaround would be to canonicalize the return value of isinf to bool. Doesn't this change the interface defined by c99? Yes, we would need to hide that fact and always add promotion code to int via isinf() != 0. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35509
[Bug tree-optimization/35737] [4.2/4.3/4.4 regression] ICE with __builtin_setjmp and complex variable
-- jakub at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35737
[Bug middle-end/35854] [4.3/4.4 Regression] life passes dump option still documented
-- jakub at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35854
[Bug tree-optimization/35899] [4.3/4.4 Regression] ICE on filesystem code
-- jakub at gcc dot gnu dot org changed: What|Removed |Added Keywords||ice-on-invalid-code Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35899
[Bug c/35739] [4.3/4.4 regression] ICE with _Decimal128 and va_list
-- jakub at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35739
[Bug target/35907] [4.3/4.4 Regression] 64-bit power6 glibc miscompilation
-- jakub at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35907
[Bug c++/35747] [4.3/4.4 regression] ICE with undefined variable in statement expression
-- jakub at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35747
[Bug c/35746] [4.3/4.4 regression] ICE with undefined variables
-- jakub at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35746
[Bug fortran/35932] [4.3/4.4 Regression] ICE: CHAR with array arg and also a KIND arg
-- jakub at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35932
[Bug c/35742] [4.1/4.2/4.3/4.4 regression] Broken diagnostic: 'goto_expr' not supported by pp_c_expression
-- jakub at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35742
[Bug bootstrap/35933] local variable used before set in fold-const.c
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-04-15 09:54 --- Doh. Rafael, this was you with http://gcc.gnu.org/ml/gcc-cvs/2008-04/msg00326.html -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org, espindola at gcc dot ||gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35933
[Bug c/35744] [4.1/4.2/4.3 regression] ICE attributes for invalid types
--- Comment #4 from jakub at gcc dot gnu dot org 2008-04-15 09:33 --- IMHO this should be backported to gcc-4_3-branch. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35744
[Bug target/32424] [4.3/4.4 Regression] gcc.c-torture/compile/20050303-1.c FAILs
-- jakub at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32424
[Bug target/35455] [4.1/4.2/4.3/4.4 Regression] h8300: internal compiler error: in compute_frame_pointer_to_fb_displacement, at dwarf2out.c:10984
-- jakub at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35455
[Bug libfortran/35863] [F2003] Implement ENCODING=UTF-8
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2008-04-15 10:45 --- (In reply to comment #0) Front end and library are ready to handle this when implemented. Front-end is ready? Is ENCODING=UTF-8 related to UCS-4 support? Because if it is, then the front-end is not ready, it only supports a single character kind. (In reply to comment #1) This could be a bit tricky to get right. OTOH Fortran is fortunate enough that there are real strings and not char arrays like in C, so from a user perspective it should be pretty transparent. Well, I'm not too sure it's hard. We are not required to support UTF-8 strings as a character kind (that would be really hard) but just UCS-4 strings (ie UTF-32), which is basically (as I see it): - remove limitations in the front-end that there is only one character kind] - make a new character kind, as an array of 32-bit integers and a length - adjust library functions Then, I/O with UTF-8 encoding just needs UTF-8 -- UTF-32 conversions, which is only a few dozen lines of code (unless I'm confused). -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35863
[Bug ada/16086] Legal program rejected, procedure of protected object should be visible
--- Comment #6 from sam at gcc dot gnu dot org 2008-04-15 11:03 --- Subject: Bug 16086 Author: sam Date: Tue Apr 15 11:02:58 2008 New Revision: 134312 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134312 Log: 2008-04-15 Ed Schonberg [EMAIL PROTECTED] gcc/ada/ PR ada/16086 * sem_ch12.adb (Analyze_Formal_Subprogram): The default can be any protected operation that matches the signature, not only an entry, a regular subprogram or a literal. 2008-04-15 Samuel Tardieu [EMAIL PROTECTED] gcc/testsuite/ PR ada/16086 * gnat.dg/prot_def.adb: New. Added: trunk/gcc/testsuite/gnat.dg/prot_def.adb Modified: trunk/gcc/ada/ChangeLog trunk/gcc/ada/sem_ch12.adb trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16086
[Bug ada/16086] Legal program rejected, procedure of protected object should be visible
--- Comment #7 from sam at gcc dot gnu dot org 2008-04-15 11:04 --- Fixed in SVN. -- sam at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16086
[Bug target/35662] [4.3/4.4 regression] gfortran interfaces badly with glibc sincosf() causing breakage
--- Comment #1 from jakub at gcc dot gnu dot org 2008-04-15 11:20 --- This is a fortran FE bug. -- 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 Priority|P3 |P2 Last reconfirmed|-00-00 00:00:00 |2008-04-15 11:20:07 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35662
[Bug target/35662] [4.3/4.4 regression] gfortran interfaces badly with glibc sincosf() causing breakage
-- jakub at gcc dot gnu dot org changed: What|Removed |Added Priority|P2 |P4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35662
[Bug ada/28733] GNAT crash while compiling Ada-2005 code
--- Comment #10 from sam at gcc dot gnu dot org 2008-04-15 12:00 --- Subject: Bug 28733 Author: sam Date: Tue Apr 15 11:59:39 2008 New Revision: 134313 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134313 Log: 2008-04-15 Samuel Tardieu [EMAIL PROTECTED] Gary Dismukes [EMAIL PROTECTED] gcc/ada/ PR ada/28733 * sem_ch8.adb (Analyze_Use_Package): Do not allow use of something which is not an entity (and hence not a package). (End_Use_Package): Ditto. Modified: trunk/gcc/ada/ChangeLog trunk/gcc/ada/sem_ch8.adb -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28733
[Bug ada/28733] GNAT crash while compiling Ada-2005 code
--- Comment #11 from sam at gcc dot gnu dot org 2008-04-15 12:22 --- This has been fixed in SVN. -- sam at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28733
[Bug target/35860] [4.3 Regression] [avr] code bloat caused by -fsplit-wide-types
--- Comment #6 from bonzini at gnu dot org 2008-04-15 12:26 --- The point of -fsplit-wide-types was to kill patterns like iorsi3 in AVR backend. -- bonzini at gnu dot org changed: What|Removed |Added CC||bonzini at gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35860
[Bug target/35907] [4.3/4.4 Regression] 64-bit power6 glibc miscompilation
--- Comment #15 from jakub at gcc dot gnu dot org 2008-04-15 12:34 --- Ok, let's leave that for a follow-up. Have you managed to test this? I could bootstrap/regtest on ppc-linu and ppc64-linux, but don't have time right now for further testing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35907
[Bug ada/35880] GNAT does not generate debugging information on imported entities
--- Comment #9 from knoxj at att dot net 2008-04-15 13:31 --- I was going to update my bug report when I noticed Sam's comments. I used readelf -a -w test_pacs_cp_package.o to try to see what was happening, and I saw that the compiler was throwing out any information about the Ada definintion. I would have expected the compiler to hang onto the Ada debug information, but use the IMPORT information for code generation. The linker would then resolve the IMPORT name, and the debugger could see the Ada description. I too realized that shared memory was a red herring, and the real problem was simply the IMPORT implementation. Sam's sample illustrates this much better than the source files I submitted. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35880
[Bug fortran/35943] New: -fbounds-check: actual character string shorter than dummy
Found at
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/1a93179a80b6e6e8
The following program is invalid as the passed character string is too short
for the dummy argument. gfortran detects this at compile time (if contained)
and prints a warning; however, I expect that it also detects this at run time
with -fbounds-check.
This should be quite easy as substr has:
substr (strng, _strng)
i.e. the _strng size can be compared at run time.
(Note: Using character(len=n) the string length of the dummy might not be
known at compile time either.)
PROGRAM TST_STRING
CALL SUBSTR('HELLO THE WETHER IS NICE')
CALL SUBSTR('HELLO THE WETHER IS ')
CALL SUBSTR('HELLO THE WETHER ')
STOP
! CONTAINS
END
SUBROUTINE SUBSTR(STRNG)
CHARACTER(24) STRNG
WRITE(6,*) 'STRING=', STRNG
RETURN
END SUBROUTINE
! END PROGRAM
--
Summary: -fbounds-check: actual character string shorter than
dummy
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
OtherBugsDependingO 27766
nThis:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35943
[Bug fortran/35944] New: wrong result for MOD with kind=10 for some array argument values
The following program gives the wrong answers when the MOD arguments have kind = 10 and one is an array. It works when the kind is 4 or 8. program FA2083 ! fails on Windows XP ! gcc version 4.4.0 20080312 (experimental) [trunk revision 133139] implicit none integer j1,k parameter (k=10) !fails ! parameter (k=8) !works ! parameter (k=4) !works REAL(k) QDA1(10) REAL(k) QDA(10), qval print *, 'kind = ',k qda = (/ 1,2,3,4,5,6,7,8,9,10 /) QDA1 = MOD ( 1.1_k*( QDA(1) -5.0_k), P=( QDA -2.5_k)) DO J1 = 1,10 QVAL = MOD(1.1_k*(QDA(1)-5.0_k),P=(QDA(J1)-2.5_k)) print '(i3, 3f10.2)', j1, qda1(j1), qval, qval-qda1(j1) ENDDO END c:\gfortran:gfortran fa2083.f c:\gfortran:a kind = 10 1 -1.40 -1.40 0.00 2 -0.40 -0.40 0.00 3 -0.40 -0.40 0.00 4 -0.40 -1.40 -1.00 5 -0.40 -1.90 -1.50 6 -0.40 -0.90 -0.50 7 -0.40 -4.40 -4.00 8 -0.40 -4.40 -4.00 9 -0.40 -4.40 -4.00 10 -0.40 -4.40 -4.00 c:\gfortran:gfortran fa2083.f c:\gfortran:a kind =8 1 -1.40 -1.40 0.00 2 -0.40 -0.40 0.00 3 -0.40 -0.40 0.00 4 -1.40 -1.40 0.00 5 -1.90 -1.90 0.00 6 -0.90 -0.90 0.00 7 -4.40 -4.40 0.00 8 -4.40 -4.40 0.00 9 -4.40 -4.40 0.00 10 -4.40 -4.40 0.00 c:\gfortran:gfortran fa2083.f c:\gfortran:a kind =4 1 -1.40 -1.40 0.00 2 -0.40 -0.40 0.00 3 -0.40 -0.40 0.00 4 -1.40 -1.40 0.00 5 -1.90 -1.90 0.00 6 -0.90 -0.90 0.00 7 -4.40 -4.40 0.00 8 -4.40 -4.40 0.00 9 -4.40 -4.40 0.00 10 -4.40 -4.40 0.00 -- Summary: wrong result for MOD with kind=10 for some array argument values Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dick dot hendrickson at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35944
[Bug libfortran/35862] [F2003] Implement new rounding modes for run time
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2008-04-15 14:02 --- I agree with you for output: we currently do COMPATIBLE rounding and it shouldn't be too hard to change. The only case where we might not have control is for the last significant digit output by snprintf(), where we might rely somehow on the system library's implementation. For input, however, I think we don't really have control on what we do (we rely on the system strtod) and it is probably not that easy to change. I'll try to think about it some more. PS: for input, I have come to the conclusion that NEAREST and COMPATIBLE are really the same, as it is not possible for a decimal value to be exactly halfway between two machine-representable floating point values. Can someone confirm/infirm this? -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35862
[Bug target/35907] [4.3/4.4 Regression] 64-bit power6 glibc miscompilation
--- Comment #16 from bergner at gcc dot gnu dot org 2008-04-15 14:36 --- I'll fire off a bootstrap and regtest of Alan's patch on powerpc64-linux and running the test suite in 32-bit and 64-bit modes (ie, -m32 and -m64). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35907
[Bug c/35751] ICE with invalid variable after #pragma omp parallel
--- Comment #2 from jakub at gcc dot gnu dot org 2008-04-15 15:10 --- Subject: Bug 35751 Author: jakub Date: Tue Apr 15 15:09:42 2008 New Revision: 134317 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134317 Log: PR c/35751 * c-decl.c (finish_decl): If extern or static var has variable size, set TREE_TYPE (decl) to error_mark_node. * decl.c (layout_var_decl): If extern or static var has variable size, set TREE_TYPE (decl) to error_mark_node. * gcc.dg/gomp/pr35751.c: New test. * g++.dg/gomp/pr35751.C: New test. Added: trunk/gcc/testsuite/g++.dg/gomp/pr35751.C trunk/gcc/testsuite/gcc.dg/gomp/pr35751.c Modified: trunk/gcc/ChangeLog trunk/gcc/c-decl.c trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35751
[Bug fortran/35945] New: Complex module-based overloading fails
If a type is renamed on import and then an unrenamed copy is also imported, and
overloaded functions are called then gfortran fails to compile with a blocked
by an incompatible object error. The code compiles cleanly with {NAG, ifort,
g95}.
Not sure if this is a bug or non-standard code, though I suspect the former.
Thanks,
Joanthan Hogg
Full test case:
[EMAIL PROTECTED] ~/bugs/gfortran-4.3/import_rename $ make
gfortran-4.3 -c stype.f90
gfortran-4.3 -c dtype.f90
gfortran-4.3 -c test.f90
test.f90:15.29:
subroutine fred(sval, dval)
1
test.f90:16.15:
use stype
2
Error: The type 'overloaded_type' cannot be host associated at (1) because it
is blocked by an incompatible object of the same name declared at (2)
make: *** [test.o] Error 1
[EMAIL PROTECTED] ~/bugs/gfortran-4.3/import_rename $ gfortran-4.3 -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --program-suffix=-4.3
Thread model: posix
gcc version 4.3.0 (GCC)
[EMAIL PROTECTED] ~/bugs/gfortran-4.3/import_rename $ cat test.f90
program test
use stype, overloaded_type_s = overloaded_type
use dtype, overloaded_type_d = overloaded_type
implicit none
type(overloaded_type_s) :: sval
type(overloaded_type_d) :: dval
sval%part = 1
dval%part = 2
call fred(sval, dval)
contains
subroutine fred(sval, dval)
use stype
type(overloaded_type_s), intent(in) :: sval
type(overloaded_type_d), intent(in) :: dval
call overloaded_sub(sval)
call overloaded_sub(dval)
end subroutine
end program
[EMAIL PROTECTED] ~/bugs/gfortran-4.3/import_rename $ cat stype.f90
module stype
implicit none
type overloaded_type
real :: part
end type
interface overloaded_sub
module procedure overloaded_sub_s
end interface
contains
subroutine overloaded_sub_s(otype)
type(overloaded_type), intent(in) :: otype
print *, s type = , otype%part
end subroutine
end module
[EMAIL PROTECTED] ~/bugs/gfortran-4.3/import_rename $ cat dtype.f90
module dtype
implicit none
type overloaded_type
double precision :: part
end type
interface overloaded_sub
module procedure overloaded_sub_d
end interface
contains
subroutine overloaded_sub_d(otype)
type(overloaded_type), intent(in) :: otype
print *, d type = , otype%part
end subroutine
end module
--
Summary: Complex module-based overloading fails
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: J dot Hogg at rl dot ac dot uk
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=35945
[Bug c/35751] ICE with invalid variable after #pragma omp parallel
--- Comment #3 from jakub at gcc dot gnu dot org 2008-04-15 15:19 --- Subject: Bug 35751 Author: jakub Date: Tue Apr 15 15:18:41 2008 New Revision: 134318 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134318 Log: PR c/35751 * c-decl.c (finish_decl): If extern or static var has variable size, set TREE_TYPE (decl) to error_mark_node. * decl.c (layout_var_decl): If extern or static var has variable size, set TREE_TYPE (decl) to error_mark_node. * gcc.dg/gomp/pr35751.c: New test. * g++.dg/gomp/pr35751.C: New test. Added: branches/gcc-4_3-branch/gcc/testsuite/g++.dg/gomp/pr35751.C branches/gcc-4_3-branch/gcc/testsuite/gcc.dg/gomp/pr35751.c Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/c-decl.c branches/gcc-4_3-branch/gcc/cp/ChangeLog branches/gcc-4_3-branch/gcc/cp/decl.c branches/gcc-4_3-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35751
[Bug c/35751] ICE with invalid variable after #pragma omp parallel
--- Comment #4 from jakub at gcc dot gnu dot org 2008-04-15 15:21 --- 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=35751
[Bug fortran/35946] New: wrong result with array constructor as argument to ATAN2
The following program gives the wrong answers when an array constructor with a complicated implied do is used as an argument to REAL which is then used as an argument to ATAN2. Dick Hendrickson program try_fa6013 ! fails on Windows XP ! gcc version 4.4.0 20080312 (experimental) [trunk revision 133139] call fa6013(10,1,-1) end program subroutine FA6013 (nf10,nf1,mf1) integer, parameter :: kv=4!fails ! integer, parameter :: kv=8!fails REAL(KV) DDA1(10) REAL(KV) DDA2(10) REAL(KV) DDA(10), dval dda = (/ 1,2,3,4,5,6,7,8,9,10/) print '(10f5.1)', REAL((/(J1,J1=nf10,nf1,mf1)/),KV) !works DDA1 = ATAN2 ( (/(REAL(J1,KV),J1=1,10)/) , $ REAL((/(J1,J1=nf10,nf1,mf1)/),KV)) !fails !$ REAL((/(J1,J1= 10, 1, -1)/),KV)) !works DDA2 = ATAN2 ( DDA, DDA(10:1:-1) ) DVAL = .09967_kv !atan2(1.0,10.0) print '(i3,3f10.5)', 1, dda1(1),dval, dval-dda1(1) DO J1 = 2,10 DVAL = DDA2(J1) print '(i3,3f10.5)', j1, dda1(j1),dval, dval-dda1(j1) 100 ENDDO END c:\gfortran:gfortran fa6013.f c:\gfortran:a 10.0 9.0 8.0 7.0 6.0 5.0 4.0 3.0 2.0 1.0 1 0.11066 0.09967 -0.01099 2 0.24498 0.21867 -0.02631 3 0.40489 0.35877 -0.04612 4 0.58800 0.51915 -0.06886 5 0.78540 0.69474 -0.09066 6 0.98279 0.87606 -0.10674 7 1.16590 1.05165 -0.11425 8 1.32582 1.21203 -0.11379 9 1.46014 1.35213 -0.10801 10 0.0 1.47113 1.47113 -- Summary: wrong result with array constructor as argument to ATAN2 Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dick dot hendrickson at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35946
[Bug middle-end/35838] [4.4 Regression] FAIL: 22_locale/num_get/get/char/16.cc execution test, and 76 others
--- Comment #7 from dave at hiauly1 dot hia dot nrc dot ca 2008-04-15 15:37 --- Subject: Re: [4.4 Regression] FAIL: 22_locale/num_get/get/char/16.cc execution test, and 76 others Sorry for the problems. Can you give this patch a try? I'd wrongly assumed that one of the subregs would always be paradoxical. The patch fixes this PR and PR ada/35687. Thanks, Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35838
[Bug fortran/35947] New: wrong answers with array constructor argument to IEOR
The following program gives wrong answers when an array is used in an array constructor as an argument to IEOR. Dick Hendrickson program try_fa6077 ! fails on Windows XP ! gcc version 4.4.0 20080312 (experimental) [trunk revision 133139] call fa6077 ( 10, 1, -1, (/1,2,3,4,5,6,7,8,9,10/)) end subroutine FA6077 (nf10,nf1,mf1, ida) INTEGER IDA1(10) INTEGER IDA2(10), ida(10) IDA1 = IEOR((/1,2,3,4,5,6,7,8,9,10/), $(/(IDA(J1),J1=10,1,-1)/) ) IDA2 = IEOR ((/1,2,3,4,5,6,7,8,9,10/), (/10,9,8,7,6,5,4,3,2,1/) ) print '(10i3)', (/1,2,3,4,5,6,7,8,9,10/), $(/10,9,8,7,6,5,4,3,2,1/),ida1,ida2 END SUBROUTINE c:\gfortran:gfortran fa6077.f c:\gfortran:a 1 2 3 4 5 6 7 8 9 10 10 9 8 7 6 5 4 3 2 1 8 10 4 2 0 2 4 10 8 10 11 11 11 3 3 3 3 11 11 11 -- Summary: wrong answers with array constructor argument to IEOR Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dick dot hendrickson at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35947
[Bug c/35948] New: -D_FORTIFY_SOURCE discards qualifier overrides on {str,mem}cpy
The following source, without the (void*) overrides, will throw an warning
(as expected), when compiled with -Wall:
$ gcc -o memcpy-fortify -Wall memcpy-fortify.c
memcpy-fortify.c: In function 'main':
memcpy-fortify.c:21: warning: passing argument 1 of 'memcpy' discards
qualifiers from pointer target type
memcpy-fortify.c:22: warning: passing argument 1 of 'strcpy' discards
qualifiers from pointer target type
With (void*) it is (as expected) silent. With -O2, it is silent, but with
-D_FORTIFY_SOURCE != 0, the qualifier override is ignored:
$ gcc -o memcpy-fortify -Wall -O2 -D_FORTIFY_SOURCE=2 memcpy-fortify.c
memcpy-fortify.c: In function 'main':
memcpy-fortify.c:21: warning: passing argument 1 of 'memcpy' discards
qualifiers from pointer target type
memcpy-fortify.c:22: warning: passing argument 1 of 'strcpy' discards
qualifiers from pointer target type
This will cause problems for builds that run with -Werror.
/*
* gcc -o memcpy-fortify -Wall -Werror -O2 -D_FORTIFY_SOURCE=2 memcpy-fortify.c
*
*/
#include stdio.h
#include stdlib.h
#include unistd.h
#include stdint.h
#include string.h
#include stdint.h
#include inttypes.h
int main(int argc, char * argv[])
{
char *foo = strdup(string one);
char *bar = strdup(string two);
const char *baz = (const char *)foo;
printf(%s\n, foo);
memcpy((void*)baz, bar, strlen(bar)+1);
strcpy((void*)baz, bar);
printf(%s\n, foo);
return 0;
}
--
Summary: -D_FORTIFY_SOURCE discards qualifier overrides on
{str,mem}cpy
Product: gcc
Version: 4.2.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kees at outflux dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35948
[Bug c/35948] -D_FORTIFY_SOURCE discards qualifier overrides on {str,mem}cpy
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-04-15 16:35 --- This is not a GCC bug but rather a glibc issue. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35948
[Bug tree-optimization/35899] [4.3/4.4 Regression] ICE on filesystem code
--- Comment #4 from jakub at gcc dot gnu dot org 2008-04-15 16:42 --- Testing a fix. -- 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|NEW |ASSIGNED Last reconfirmed|2008-04-12 03:35:42 |2008-04-15 16:42:46 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35899
[Bug c/35948] -D_FORTIFY_SOURCE discards qualifier overrides on {str,mem}cpy
--- Comment #2 from kees at outflux dot net 2008-04-15 16:44 --- Erk, right. Sorry for the noise. -- kees at outflux dot net changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35948
[Bug translation/35177] Error in the french traduction
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2008-04-15 17:42 --- Thanks Jim for letting us (TP) know. I'll take care of it. -- 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|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-04-15 17:42:34 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35177
[Bug ada/22387] Ada compiler crash when inheriting from a record with custom layout
--- Comment #7 from sam at gcc dot gnu dot org 2008-04-15 18:46 --- Bug fixed in AdaCore tree, will eventually be committed to FSF tree. -- sam at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|sam at gcc dot gnu dot org |unassigned at gcc dot gnu ||dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22387
[Bug c/35739] [4.3/4.4 regression] ICE with _Decimal128 and va_list
-- 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|NEW |ASSIGNED Last reconfirmed|2008-03-30 20:52:57 |2008-04-15 18:58:38 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35739
[Bug ada/22387] Ada compiler crash when inheriting from a record with custom layout
--- Comment #8 from sam at gcc dot gnu dot org 2008-04-15 19:06 --- Subject: Bug 22387 Author: sam Date: Tue Apr 15 19:05:29 2008 New Revision: 134326 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134326 Log: 2008-04-15 Ed Schonberg [EMAIL PROTECTED] gcc/ada/ PR ada/22387 * exp_ch5.adb (Expand_Assign_Record): Within an initialization procedure for a derived type retrieve the discriminant values from the parent using the corresponding discriminant. 2008-04-15 Samuel Tardieu [EMAIL PROTECTED] gcc/testsuite/ PR ada/22387 * gnat.dg/specs/corr_discr.ads: New. Added: trunk/gcc/testsuite/gnat.dg/specs/corr_discr.ads Modified: trunk/gcc/ada/ChangeLog trunk/gcc/ada/exp_ch5.adb trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22387
[Bug ada/22387] Ada compiler crash when inheriting from a record with custom layout
--- Comment #9 from sam at gcc dot gnu dot org 2008-04-15 19:06 --- This has been fixed in GCC SVN trunk. -- sam at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22387
[Bug c++/35949] New: 'const' attribute applied to typedefed type in methods's return is ignored
In the following code 'const VR' in declaration of the return value of 'kk'
works as just 'VR', without constness.
In arguments 'const VR' is applied as const.
code example
typedef int X;
struct S {
typedef X VR; // --- VR is declared as X by-reference
X x;
// uncomment one of these two lines:
const VR kk(VR) const { return (x); } // --- bug: first 'const' is
ignored and function is defined as returning *not* const causing compiler error
message
// const X kk(VR) const { return (x); } // --- ok: function is defined as
returning const by-reference
};
void f() {
typedef S::VR VR;
const X (S::*fn)(VR) const; // ---: ask for the function returning
by-reference
fn = S::kk; // --- error message here
}
--
Summary: 'const' attribute applied to typedefed type in methods's
return is ignored
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: yuri at tsoft dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35949
[Bug libfortran/35862] [F2003] Implement new rounding modes for run time
--- Comment #4 from burnus at gcc dot gnu dot org 2008-04-15 19:08 --- I agree with you for output: we currently do COMPATIBLE rounding I wanted to write this when I approved the code, but I found one *printf function and checking the POSIX standard one finds: f, F The double argument shall be converted to decimal notation [...] The low-order digit shall be rounded in an implementation-defined manner. Therefore, I think COMPATIBLE is a good guess, but I'm not sure whether COMPATIBLE is always true. (In reply to comment #3) I agree with you for output: we currently do COMPATIBLE rounding and it shouldn't be too hard to change. The only case where we might not have control is for the last significant digit output by snprintf(), where we might rely somehow on the system library's implementation. Well, I would argue that this digit is the most important for rounding ... Does this mean we have to roll out our own implementation which replaces snprintf? For input, however, I think we don't really have control on what we do (we rely on the system strtod) and it is probably not that easy to change. I probably miss something, but where on input do you need to round? PS: for input, I have come to the conclusion that NEAREST and COMPATIBLE are really the same, as it is not possible for a decimal value to be exactly halfway between two machine-representable floating point values. Can someone confirm/infirm this? I wanted to mention BOZ I/O, but there you don't have a decimal point. But still I'm not sure that you cannot dream up a decimal number which has one digit too much for the machine-representible FP number. But in any case NEAREST is contained in COMPATIBLE as NEAREST does not describe what to to if the numbers are equidistant. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35862
[Bug c++/35949] 'const' attribute applied to typedefed type in methods's return is ignored
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-04-15 19:10 --- const VR is different from const X. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35949
[Bug c++/35261] GCC4.3 internal compiler error: verify_flow_info failed
--- Comment #2 from truedfx at gentoo dot org 2008-04-15 19:17 --- Created an attachment (id=15479) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15479action=view) bug.ii I ran into this same error with different code, which I posted to http://gcc.gnu.org/ml/gcc-help/2008-04/msg00190.html but reduced further to the attached. It, like the original code, fails with GCC 4.3.0, GCC 4.3-20080410, and GCC-4.4-20080411, when GCC is configured with --enable-checking. gcc -c -O is enough to show it with this: $ ~/gcc/bin/gcc -c -O bug.ii bug.ii: In function void h(): bug.ii:7: error: BB 13 can not throw but has EH edges bug.ii:7: internal compiler error: verify_flow_info failed Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. $ ~/gcc/bin/gcc --version gcc (GCC) 4.4.0 20080411 (experimental) Copyright (C) 2008 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35261
[Bug libstdc++/35915] [4.4 Regression] atomic.cc:31:20: error: stdint.h: No such file
--- Comment #4 from bkoz at gcc dot gnu dot org 2008-04-15 19:21 --- Sorry about the delay folks. Trying to track down some config issues, and so far failing to get a local xcompiler up so I can test locally a config w/o stdint.h provided. Goal is to use GCC_HEADER_STDINT(gstdint.h) to construct a stdint.h that works when stdint.h is not found. When stdint.h is found, do nothing. -benjamin -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35915
[Bug libstdc++/35915] [4.4 Regression] atomic.cc:31:20: error: stdint.h: No such file
--- Comment #5 from bkoz at gcc dot gnu dot org 2008-04-15 19:31 --- Sorry about the delay folks. Trying to track down some config issues, and so far failing to get a local xcompiler up so I can test locally a config w/o stdint.h provided. Goal is to use GCC_HEADER_STDINT(gstdint.h) to construct a stdint.h that works when stdint.h is not found. When stdint.h is found, do nothing. -benjamin -- bkoz at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||448 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35915
[Bug c/448] stdint.h-related issues (C99 issues)
--- Comment #9 from bkoz at gcc dot gnu dot org 2008-04-15 19:37 --- C++ folks also. Note that GCC_HEADER_STDINT(gstdint.h) solution is used by: libgomp libgfortran libdecnumber and soon by libstdc++. This does use the native stdint.h when possible. I'm with Geoff in that another stddef.h macro-nest is to be avoided. That file is ridiculous. -- bkoz at gcc dot gnu dot org changed: What|Removed |Added Last reconfirmed|2006-10-18 12:31:30 |2008-04-15 19:37:34 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=448
[Bug fortran/35864] [4.4 Regression] Revision 133965 broke gfortran.dg/initialization_1.f90
--- Comment #11 from pault at gcc dot gnu dot org 2008-04-15 19:41 --- Subject: Bug 35864 Author: pault Date: Tue Apr 15 19:40:33 2008 New Revision: 134329 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134329 Log: 2008-04-15 Paul Thomas [EMAIL PROTECTED] PR fortran/35864 * expr.c (scalarize_intrinsic_call): Reorder identification of array argument so that if one is not found a segfault does not occur. Return FAILURE if all scalar arguments. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/expr.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35864
[Bug fortran/35864] [4.4 Regression] Revision 133965 broke gfortran.dg/initialization_1.f90
--- Comment #12 from pault at gcc dot gnu dot org 2008-04-15 19:43 --- Finally, I have managed to deal with this. Sorry it took so long Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35864
[Bug c/448] stdint.h-related issues (C99 issues)
--- Comment #10 from jsm28 at gcc dot gnu dot org 2008-04-15 19:44 --- GCC allows duplicate typedefs in system headers, which should simplify this header a bit. See http://gcc.gnu.org/ml/gcc/2008-03/msg00558.html for the latest partial attempt at giving the compiler knowledge of these types, and my followups on how to handle OSes where GCC lacks knowledge of the types but the OS might have some or all (don't provide the header), OSes where a newer version has the types (take the types from the newer version) and unmaintained OSes or OSes that otherwise won't be updated to have these types themselves (only in that case make a GCC-local choice of types). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=448
[Bug libfortran/35863] [F2003] Implement ENCODING=UTF-8
--- Comment #3 from burnus at gcc dot gnu dot org 2008-04-15 19:46 ---
Front end and library are ready to handle this when implemented.
Front-end is ready?
Yes, it is: ENCODING= is supported and the rest is neither in the library nor
in the front-end implemented. Though I would not call this ready.
Is ENCODING=UTF-8 related to UCS-4 support?
I think it is at the end. You can easily use UTF-8 encoding already now, but
'(a2)' might print one (non-ascii) or two (ascii) characters. To have something
well-defined, only one-byte-wide characters can be used currently. For anything
beyond, UCS4 is needed in the front end.
Actually, I do not understand how to write things like
character(kind=myUCS4,len=20) :: foo = myUCS4_'Some UCS4 string'
(The problem is switching the encoding within the same file; good luck in
finding an editor which supports this.)
If one does not need non-ascii character literals (i.e. reading from / writing
to files), there is no problem.
Possible solutions?
a) Have a UCS-4 input file; then both default_'foo' and ucs4_'foo' work.
b) Expect that for myUCS4_'foo' literals the characters in the quotes are
actually UTF-8.
I'm personally in favour of (b). I'm not quite sure whether this is really
compatible with the Fortran standard, but I like the way of inputting the
string.
Otherwise, I think Fortran misses a good way of inputting non-ascii characters
in an ASCII file. C99 offers '\u' but unless I missed something in Fortran
the equivalent would be:
I think (c) is what most programmers want, but I actually do not see how this
should work syntax wise; or should an ascii literal automatically handled as
UTF-8? Then it would work: when assigning to a ucs8 string, the UTF-8 gets
properly converted a non-ascii character has then the length one (len(char()
while if one assigns to a ASCII string, non-ascii characters of cause need more
bytes and thus len('§') == 2.
(b) is also an interesting problem. And (a) of cause works, but it is quite
cumbersome to use - Fortran misses the \u way of C for specifying an
unicode character; one can probably work with
myUCS4string = char(int(z/A0FF/),kind=myUCS4)
but this is awful. (Actually, I think the standard does not even guarantee that
it does this as char is processor dependent.)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35863
[Bug c++/35949] 'const' attribute applied to typedefed type in methods's return is ignored
--- Comment #2 from schwab at suse dot de 2008-04-15 20:10 --- const VR is the same as X const, and qualifiers on non-lvalues are ignored. -- schwab at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35949
[Bug c++/33979] support for char16_t, char32_t
--- Comment #4 from kris dot van dot hees at oracle dot com 2008-04-15 20:17 --- Updated patch: http://gcc.gnu.org/ml/gcc-patches/2008-04/msg01235.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33979
[Bug libfortran/35863] [F2003] Implement ENCODING=UTF-8
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2008-04-15 20:53 --- (In reply to comment #3) Actually, I do not understand how to write things like character(kind=myUCS4,len=20) :: foo = myUCS4_'Some UCS4 string' Ah, I'm glad that I'm not alone! I was thinking of asking advice on c.l.f when I get some time to write. I agree with you that it is not clear at all. (The problem is switching the encoding within the same file; good luck in finding an editor which supports this.) I don't think there is such thing as a file with multiple encodings, and we shouldn't create such a beast just for Fortran. a) Have a UCS-4 input file; then both default_'foo' and ucs4_'foo' work. I'd suggest going for that. b) Expect that for myUCS4_'foo' literals the characters in the quotes are actually UTF-8. See above, I don't think we want to mix encodings. But, we can support both (a) and (b): if the file is UCS4, go for (a), if the file is UTF-8, go for (b). On a personal note, I would use (b) more than (a): UTF-8 is the way forward, and fixed-width encodings are a real pain for file representation (which is different than internal representation). Otherwise, I think Fortran misses a good way of inputting non-ascii characters in an ASCII file. C99 offers '\u' We already have -fbackslash, I can see us accepting that kind of code with a given option; it would really be useful. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35863
[Bug libfortran/35862] [F2003] Implement new rounding modes for run time
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2008-04-15 20:59 --- (In reply to comment #4) Well, I would argue that this digit is the most important for rounding... Only for list-directed output and if people use really large formats (which is a lot of cases). Otherwise, not. Does this mean we have to roll out our own implementation which replaces snprintf? Might be. I probably miss something, but where on input do you need to round? Rounding is done for all I/O, including input. For example, if you have: read (0.1, *, rounding=up) x read (0.1, *, rounding=down) y then you will have x == nearest(y, -1.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35862
[Bug fortran/35944] [4.3, 4.4 regression] wrong result for MOD with kind=10 for some array argument values
--- Comment #1 from tkoenig at gcc dot gnu dot org 2008-04-15 21:02 --- Confirmed, this used to work for 4.2. $ gfortran-4.2 foo.f90 $ ./a.out kind = 10 1 -1.40 -1.40 0.00 2 -0.40 -0.40 0.00 3 -0.40 -0.40 0.00 4 -1.40 -1.40 0.00 5 -1.90 -1.90 0.00 6 -0.90 -0.90 0.00 7 -4.40 -4.40 0.00 8 -4.40 -4.40 0.00 9 -4.40 -4.40 0.00 10 -4.40 -4.40 0.00 $ gfortran-4.2 -v Using built-in specs. Target: i486-linux-gnu Configured with: ../src/configure -v --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.2 --program-suffix=-4.2 --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr --disable-libmudflap --enable-targets=all --enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu Thread model: posix gcc version 4.2.3 (Debian 4.2.3-3) $ gfortran-4.3 foo.f90 $ ./a.out kind = 10 1 0.00 -1.40 -1.40 2 -0.00 -0.40 NaN 3 -0.40 -0.40 0.00 4 -0.40 -1.40 -1.00 5 -0.40 -1.90 -1.50 6 -0.40 -0.90 -0.50 7 -0.40 -4.40 -4.00 8 -0.40 -4.40 -4.00 9 -0.40 -4.40 -4.00 10 -0.40 -4.40 -4.00 $ gfortran-4.3 -v Using built-in specs. Target: i486-linux-gnu Configured with: ../src/configure linux gnu Thread model: posix gcc version 4.3.1 20080309 (prerelease) (Debian 4.3.0-1) -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added CC||tkoenig at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||wrong-code Known to work||4.2.3 Last reconfirmed|-00-00 00:00:00 |2008-04-15 21:02:35 date|| Summary|wrong result for MOD with |[4.3, 4.4 regression] wrong |kind=10 for some array |result for MOD with kind=10 |argument values |for some array argument ||values http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35944
[Bug target/35907] [4.3/4.4 Regression] 64-bit power6 glibc miscompilation
--- Comment #17 from bergner at gcc dot gnu dot org 2008-04-15 21:16 --- Created an attachment (id=15480) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15480action=view) Updated test case ready for inclusion in gcc's testsuite. Ok, I bootstrapped (powerpc64-linux) and regtested Alan's patch and saw no regressions in either 32-bit or 64-bit modes. I have also attached an updated version of Jakub's test case ready for inclusion into GCC's testsuite. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35907
[Bug libgcj/35950] New: jar produces files ecj won't handle
If the copy of gjar from GCJ 4.3.0 is used to build GNU Classpath with the examples turned on (--enable-examples) it will fail with an error relating to gnu.classpath.tools.tnameserv.Main. This class is inside tools.zip, which is created earlier in the build by gjar. ecj seems to refuse to pick up the class from this zip file. Uncompressing the zip file, using gcj's tools.zip or creating the zip with fastjar or current gjar from GNU Classpath cause the examples to be built correctly. Seems like a lingering gjar bug that may need to be backported. ecj is being run using gcj. -- Summary: jar produces files ecj won't handle Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcj AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: gnu_andrew at member dot fsf dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35950
[Bug target/35907] [4.3/4.4 Regression] 64-bit power6 glibc miscompilation
--- Comment #18 from amodra at bigpond dot net dot au 2008-04-16 00:41 --- My bootstrap and regression tests also pass. It took a while... I didn't have a recent baseline to compare against so needed to do two bootstraps. -- amodra at bigpond dot net dot au changed: What|Removed |Added Priority|P1 |P3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35907
[Bug target/35907] [4.3/4.4 Regression] 64-bit power6 glibc miscompilation
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35907
[Bug target/35921] Con/de-structor definition fails to override dllimport declaration
--- Comment #5 from tdragon at tdragon dot net 2008-04-16 00:50 --- The issue is fixed for me when applying the mentioned patch to 4.3.0, so as far as I'm concerned we can close this bug as soon as someone applies the fix to 4.3 SVN. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35921
[Bug fortran/35951] New: Unexpected erro Expected another dimension in array declaration
The below code produces the error Expected another dimension in array declaration at 1. It only seems to occur when the passed argument that contains the array dimension is a derived type and not an integer. Also, it only occurs when the derived-type declaration is below (not above) the declaration of the array. When the dimension is an integer and not a derived-type component, either order compiles correctly. I tested on g95 and intel and obtained no error. My system is WindowsXP, cygwin, and gcc version 4.3.0 20080212 (experimental) [trunk revision 132252] John !== module test_module implicit none type tt integer :: n end type tt contains !=== !=== subroutine test_sub_1(z,t) implicit none real :: z(t%n) !this order produces compiler error Expected another dimension in array declaration at 1 type (tt) :: t !type (tt) :: t !this order compiles correctly !real :: z(t%n) end subroutine test_sub_1 !=== ! subroutine test_sub_2(z,m) implicit none real:: z(m) !this order compiles correctly integer :: m !integer,intent(in) :: m!this order compiles correctly too !real, intent(out) :: z(m) end subroutine test_sub_2 !=== !=== end module test_module -- Summary: Unexpected erro Expected another dimension in array declaration Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: john dot young at jrc dot co dot jp GCC target triplet: i686-pc-cygwin http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35951
[Bug fortran/35951] Unexpected erro Expected another dimension in array declaration
--- Comment #1 from john dot young at jrc dot co dot jp 2008-04-16 01:51 --- Created an attachment (id=15481) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15481action=view) code to produce error described in bug report -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35951
[Bug target/35921] Con/de-structor definition fails to override dllimport declaration
--- Comment #6 from dannysmith at users dot sourceforge dot net 2008-04-16 01:54 --- (In reply to comment #5) The issue is fixed for me when applying the mentioned patch to 4.3.0, so as far as I'm concerned we can close this bug as soon as someone applies the fix to 4.3 SVN. I'll wait a week to see if it causes any problems on trunk, then apply to 4.3 branch. Danny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35921
[Bug fortran/35951] Unexpected erro Expected another dimension in array declaration
--- Comment #2 from john dot young at jrc dot co dot jp 2008-04-16 01:57 --- I take back my comment that intel's compiler produces no error. Intel 8.1 produces an error when the structure declaration is below the array declaration. I do not know the standard well enough to know whether this is a bug or not. G95 still compiles with no error. John -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35951
[Bug tree-optimization/35629] [4.4 Regression] gcc.dg/tree-ssa/loop-25.c scan-tree-dump-times profile fails
--- Comment #8 from hp at gcc dot gnu dot org 2008-04-16 02:44 --- Subject: Bug 35629 Author: hp Date: Wed Apr 16 02:44:01 2008 New Revision: 134339 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134339 Log: PR tree-optimization/35629 * gcc.dg/tree-ssa/loop-25.c: Xfail all but the first scan-tree-dump-times. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/tree-ssa/loop-25.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35629
[Bug fortran/35944] [4.3, 4.4 regression] wrong result for MOD with kind=10 for some array argument values
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2008-04-16 03:51 --- The tree dump for the kind=8 and kind=10 are exactly identical except for the call to __builtin_fmodl for kind=10 and __builtin_fmod for kind=8. It looks like fmodl is broken. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35944
[Bug fortran/35951] Unexpected erro Expected another dimension in array declaration
--- Comment #3 from burnus at gcc dot gnu dot org 2008-04-16 05:05 --- I think this is wrong: real :: z(t%n) type (tt) :: t the order has to be reversed. The following is also invalid (with implicit none): real:: z(m) integer :: m Most compilers support this, however. I think gfortran behaves OK; though, one could argue that for consistency also the first has to be supported or that second one should be diagnosed (only with -std=, there are too many programs with reversed order). When I have time, I will search for the quote from the standard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35951
[Bug fortran/35952] New: Segmentation fault with character strings only when compiling with -funroll-loops and -O3
I attached a short code that produces segmentation faults (or strange cygwin
errors). The segmentation faults only occur when compiling with both
-funroll-loops and -O3. If one or the other or neither are used, the program
runs fine. The code has several examples. I attached a stackdump for the case
of the three write statements.
System : WinXP, cygwin, gcc version 4.3.0 20080212 (experimental)
==
subroutine test_sub(label)
character(len=*),intent(in) :: label
character (len=(len(label)+20)) :: c1
character (len=(len(label)+20)) :: c2
character (len=(len(label)+20)) :: c3
! the below 3 lines cause a segmentation fault
! print*, len(c1)
! print*, len(c2)
! print*, len(c3)
! the below 2 lines produce strange cygwin errors
! a ### sig_send: wait for sig_complete event failed, signal -34, rc
-1, Win32 error 6
! print*, len(c1)
! print*, len(c2)
! the below 1 lines produces no problem
! print*, len(c3)
! the below 3 lines cause a segmentation fault (I gave the stackdump for this
case)
write(c1,'(A)') 'a'
write(c2,'(A)') 'b'
write(c3,'(A)') 'c'
! the below 2 lines produce strange cygwin erros
! a ### sig_send: wait for sig_complete event failed, signal -34, rc
-1, Win32 error 6
! write(c1,'(A)') 'a'
! write(c2,'(A)') 'b'
! the below 1 lines produces no problem
! write(c1,'(A)') 'a'
end subroutine test_sub
!==
program test
call test_sub('a')
print*, 'done'
end program test
!==
--
Summary: Segmentation fault with character strings only when
compiling with -funroll-loops and -O3
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: john dot young at jrc dot co dot jp
GCC target triplet: i686-pc-cywgin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35952
[Bug fortran/35952] Segmentation fault with character strings only when compiling with -funroll-loops and -O3
--- Comment #1 from john dot young at jrc dot co dot jp 2008-04-16 05:34 --- Created an attachment (id=15482) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15482action=view) Code that exhibits segmentation fault. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35952
[Bug fortran/35952] Segmentation fault with character strings only when compiling with -funroll-loops and -O3
--- Comment #2 from john dot young at jrc dot co dot jp 2008-04-16 05:34 --- Created an attachment (id=15483) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15483action=view) stackdump for the case of three writes -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35952
