[Bug fortran/30481] New: Accepts namelist-group object with assumed character length
Found at http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/75b797b2d4257f74 subroutine foo(c) character*(*) c namelist /abc/ c end subroutine is accepted by gfortran. Other compilers give the correct error: fortcom: Error: aaa.f, line 3: A namelist-group-object must not be a variable with assumed character length (R544.1). [ERRMSG] Error: bbb.f90, line 4: Namelist-group-object C has assumed character length Error: Variable 'c' at (1) cannot have a variable length and be in a NAMELIST ERROR: C has the CHARACTER*(*) attribute, therefore it must not be declared as a namelist-group-object. -- Summary: Accepts namelist-group object with assumed character length Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: accepts-invalid 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=30481
[Bug libstdc++/30482] New: complex division by 0
http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=221319
raises a question whether:
std::complexdouble (1.0, 1.0) / 0.0
and
std::complexdouble (1.0, 1.0) / std::complexdouble (0.0, 0.0)
can or can't be NaN. In C say:
#define I (__extension__ 1.0iF)
_Complex double d = 1.0 + 0.0 * I, e, f, z = 0.0 + 0.0 * I;
int
main (void)
{
e = d / 0.0;
f = d / z;
__builtin_printf (%g %g %g %g\n, __real__ e, __imag__ e, __real__ f,
__imag__ f);
return 0;
}
in -std=c99 always prints inf (where complex inf is even when just one of the
parts is inf), no matter what optimization options, in C89 the first division
when optimizing is usually optimized into the simpler __real__ d / 0.0,
__imag__ d / 0.0 division and thus gives inf too, but the latter and when not
optimizing
even the first one gives NaN.
What do we want in C++? C++ doesn't use flag_complex_method = 2, so unless
that changes, only the division by double (rather than std::complex double)
could generally (when not optimizing) return inf - with a help in the
specialization, see the above URL.
--
Summary: complex division by 0
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30482
[Bug c/30477] Integer Overflow detection code optimised away, -fwrapv broken
--- Comment #8 from rguenth at gcc dot gnu dot org 2007-01-16 10:36 --- If you rely on support and maintainance for gcc releases that have been discontinued by the FSF you need to get to your system vendor providing the old gcc or to an external contractor. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30477
[Bug c/30483] New: Internal compiler error with inline volatile assembly on AVR
I was reworking an existing AVR application for C89 compatibility, and while
doing so, found an internal compiler error while dealing with inline assembly.
I have taken the offending function and trimmed the code to a minimum for a
test.
Output is as follows:
test.c: In function 'spi_manual_send_ass_GCC_BUGGY':
test.c:22: internal compiler error: in ptrreg_to_str, at config/avr/avr.c:1009
Please submit a full bug report,
with preprocessed source if appropriate.
The preprocessed source of test.i is appended:
# 1 test.c
# 1 built-in
# 1 command line
# 1 test.c
typedef unsigned char uint8_t;
__inline__ uint8_t spi_manual_send_ass_GCC_BUGGY( uint8_t dat )
{
uint8_t pb;
__asm__ volatile (
\n
nop \n\t
ori %a1,8 \n\t
out 0x05,%a1 \n\t
: =d (dat)
: d (pb)
);
return pb;
}
int main() {
uint8_t dat = 0;
uint8_t result = 0;
result = spi_manual_send_ass_GCC_BUGGY(dat);
return 0;
}
--
Summary: Internal compiler error with inline volatile assembly on
AVR
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: richard at vems dot co dot nz
GCC build triplet: i586-suse-linux
GCC host triplet: i586-suse-linux
GCC target triplet: avr-unknown-unknown
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30483
[Bug c/30483] Internal compiler error with inline volatile assembly on AVR
--- Comment #1 from richard at vems dot co dot nz 2007-01-16 11:19 --- Created an attachment (id=12910) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12910action=view) Preprocessed source of test.c (test.i) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30483
[Bug c++/30470] Compiling C++ programs with -mno-80387 and -O3 failes
--- Comment #8 from bugzilla at bennee dot com 2007-01-16 11:28 --- (In reply to comment #7) However if the -mno-80387 option is meant to disable x87 instructions then it should be possible to build something without causing and x87 instructions to be emitted shouldn't it? Yes and that means you can not use (or reference, even via a prototype) any function that would cause x87 which is all functions which return a float/double. I can see why it breaks now. The headers instantiate something passed long double hence the code generation. Looking at my SuSE and Redhat box headers the headers are different. This could be an Ubuntu-ism - it's glibc seems to be older than that of RHAT4. It should be perfectly possible to use the -mno-80387 build flag as long as the program your compiling doesn't use the long double data type or call anything that returns it. According to the X86_64 ABI (3.2.3 Parameter Passing): 6. If the class is X87, the value is returned on the X87 stack in %st0 as 80-bit x87 number. 7. If the class is X87UP, the value is returned together with the previous X87 value in %st0. 8. If the class is COMPLEX_X87, the real part of the value is returned in %st0 and the imaginary part in %st1. Where the X87 classes are: The 64-bit mantissa of arguments of type long double belongs to class X87, the 16-bit exponent plus 6 bytes of padding belongs to class X87UP. and A variable of type complex long double is classi#64257;ed as type COM- PLEX_X87. -- bugzilla at bennee dot com changed: What|Removed |Added Component|target |c++ http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30470
[Bug fortran/30476] [Regression 4.2, 4.3] Via other module imported generic interface rejected
--- Comment #1 from patchapp at dberlin dot org 2007-01-16 14:51 --- Subject: Bug number PR30476 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-01/msg01324.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30476
[Bug target/30484] New: Miscompilation of remainder expressions on CPUs of the i386 family
The program below shows (at all the optimization levels) a miscompilation of
the remainder expression that causes INT_MIN % -1 to cause a SIGFPE on CPUs of
the i386 family.
#include limits.h
#include stdio.h
int minus_one(int n) {
return (n+1)*(n-1)-n*n;
}
void p(int x, int y) {
int z = x % y;
printf(%d %% %d - %d\n, x, y, z);
}
int main(int argc, char** argv) {
p(INT_MIN, minus_one(argc));
}
For simpler programs, the behavior depends on the ability of the optimizer to
realize that the divisor is -1, in which case the compiler evaluates the
remainder expression (to 0, at compile-time) and no signal is raised.
Since the remainder is always defined, this violates the C standard.
By the way, the Ariane 5 Flight 501 crash was caused by an unexpected exception
(http://en.wikipedia.org/wiki/Ariane_5_Flight_501).
--
Summary: Miscompilation of remainder expressions on CPUs of the
i386 family
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bagnara at cs dot unipr dot it
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30484
[Bug target/30483] Internal compiler error with inline volatile assembly on AVR
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|major |normal Component|c |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30483
[Bug c/30477] Integer Overflow detection code optimised away, -fwrapv broken
--- Comment #9 from tg at mirbsd dot org 2007-01-16 16:56 --- Subject: Re: Integer Overflow detection code optimised away, -fwrapv broken rguenth at gcc dot gnu dot org dixit: If you rely on support and maintainance for gcc releases that have been discontinued by the FSF you need to get to your system vendor providing the old gcc or to an external contractor. Look, I'm the founder and head developer of a free BSD operating sy- stem with a mere two active developers, _and_ a core developer of an embedded GNU/Linux operating system with much less than a dozen devs so I cannot either do it myself or gather funds to do this. Neither can we switch to gcc4 simply because it breaks too much exi- sting codebase. Furthermore, in FreeWRT, the Linux 2.4 kernel, which MUST be used for certain targets (also Linux 2.6 is said to be bloa- ted and thusly unusable due to its sheer size, which I can only cite because I don't do Linux myself), also cannot be compiled with gcc4. True, that's the fault of the Linux developers, but GCC is core tech in widespread use, and as such, you should weigh better between cost and result of your actions. bye, //mirabile -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30477
[Bug c/30477] Integer Overflow detection code optimised away, -fwrapv broken
--- Comment #10 from rguenth at gcc dot gnu dot org 2007-01-16 17:18 --- We do weight between cost and result which is a reason we keep branches in active maintainance for a long time. But we need to focus on where the majority of our users are, which is gcc 4.1 nowadays. We don't have ressources to maintain older releases for an infinite time. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30477
[Bug c/30477] Integer Overflow detection code optimised away, -fwrapv broken
--- Comment #11 from tg at mirbsd dot org 2007-01-16 17:34 --- Subject: Re: Integer Overflow detection code optimised away, -fwrapv broken rguenth at gcc dot gnu dot org dixit: But we need to focus on where the majority of our users are, which is gcc 4.1 nowadays. I highly doubt that, unless your users is only applying to users of the GNU OS (i.e. GNU/HURD) ;-) Even then, you _might_ _want_ to fix a critical security problem in an older version _even_ if it's discontinued. Or at least supply a patch to interested parties. bye, //mirabile -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30477
[Bug c/30477] Integer Overflow detection code optimised away, -fwrapv broken
--- Comment #12 from tg at mirbsd dot org 2007-01-16 17:49 --- Reopening this bug because http://gcc.gnu.org/ml/gcc/2006-12/msg00749.html states that: For example, GCC itself assumes wrapv semantics internally, This implies that gcc2 and gcc3 cannot compile gcc correctly, unless using -O0. Adding -fwrapv to autoconf's defaults won't help gcc2 and gcc3 users either, without a fix for this PR. -- tg at mirbsd dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30477
[Bug c/30477] Integer Overflow detection code optimised away, -fwrapv broken
--- Comment #13 from pinskia at gcc dot gnu dot org 2007-01-16 18:00 --- (In reply to comment #12) Reopening this bug because http://gcc.gnu.org/ml/gcc/2006-12/msg00749.html states that: For example, GCC itself assumes wrapv semantics internally, And those places are getting fixed. Again this specific bug was fixed in 4.0.0. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30477
[Bug c/30477] Integer Overflow detection code optimised away, -fwrapv broken
--- Comment #14 from gdr at cs dot tamu dot edu 2007-01-16 18:01 --- Subject: Re: Integer Overflow detection code optimised away, -fwrapv broken rguenth at gcc dot gnu dot org [EMAIL PROTECTED] writes: | We do weight between cost and result which is a reason we keep branches in | active maintainance for a long time. But we need to focus on where the | majority of our users are, which is gcc 4.1 nowadays. Fully agreed. We must however do something about the integer overflow thingy, because we stillface the needs of our user base. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30477
[Bug fortran/30404] Wrong FORALL result
--- Comment #5 from sayle at gcc dot gnu dot org 2007-01-16 18:15 --- Subject: Bug 30404 Author: sayle Date: Tue Jan 16 18:15:19 2007 New Revision: 120829 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=120829 Log: 2007-01-16 Roger Sayle [EMAIL PROTECTED] PR fortran/30404 * trans-stmt.c (forall_info): Remove pmask field. (gfc_trans_forall_loop): Remove NVAR argument, instead assume that NVAR covers all the interation variables in the current forall_info. Add an extra OUTER parameter, which specified the loop header in which to place mask index initializations. (gfc_trans_nested_forall_loop): Remove NEST_FLAG argument. Change the semantics of MASK_FLAG to only control the mask in the innermost loop. (compute_overall_iter_number): Optimize the trivial case of a top-level loop having a constant number of iterations. Update call to gfc_trans_nested_forall_loop. Calculate the number of times the inner loop will be executed, not to size of the iteration space. (allocate_temp_for_forall_nest_1): Reuse SIZE as BYTESIZE when sizeof(type) == 1. Tidy up. (gfc_trans_assign_need_temp): Remove NEST_FLAG argument from calls to gfc_trans_nested_forall_loop. (gfc_trans_pointer_assign_need_temp): Likewise. (gfc_trans_forall_1): Remove unused BYTESIZE, TMPVAR, SIZEVAR and LENVAR local variables. Split mask allocation into a separate hunk/pass from mask population. Use allocate_temp_for_forall_nest to allocate the FORALL mask with the correct size. Update calls to gfc_trans_nested_forall_loop. (gfc_evaluate_where_mask): Update call to gfc_trans_nested_forall_loop. (gfc_trans_where_2): Likewise. * gfortran.dg/forall_6.f90: New test case. * gfortran.dg/dependency_8.f90: Update test to find temp array. * gfortran.dg/dependency_13.f90: Likewise. Added: trunk/gcc/testsuite/gfortran.dg/forall_6.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-stmt.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/dependency_13.f90 trunk/gcc/testsuite/gfortran.dg/dependency_8.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30404
[Bug middle-end/18071] [4.0/4.1/4.2/4.3 Regression] -Winline does not respect -fno-default-inline
--- Comment #27 from patchapp at dberlin dot org 2007-01-16 19:45 --- Subject: Bug number PR middle-end/18071 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-01/msg01366.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18071
[Bug target/30485] New: ICE in rs6000_emit_vector_compare when building with -fno-trapping-math
The tests pr23816-1.c and vect-111.c (from gcc.dg/vect) generate an ICE when compiled with -fno-trapping-math for rs6000: $ gcc pr23816-1.c -fno-trapping-math -ftree-vectorize -maltivec -O2 pr23816-1.c: In function 'foo': pr23816-1.c:9: internal compiler error: in rs6000_emit_vector_compare, at config/rs6000/rs6000.c:11962 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. $ gcc vect-111.c -fno-trapping-math -ftree-vectorize -maltivec -O2 vect-111.c: In function 'main1': vect-111.c:19: internal compiler error: in rs6000_emit_vector_compare, at config/rs6000/rs6000.c:11962 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. $ I have a patch for this that I'll submit... -- Summary: ICE in rs6000_emit_vector_compare when building with - fno-trapping-math Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jconner at apple dot com GCC host triplet: powerpc-apple-darwin8 GCC target triplet: powerpc-apple-darwin8 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30485
[Bug c/30486] New: ICE in aggregate_value_p
/scratch/obj.x86_64/buildroot.arm/toolchain_build_arm/gcc-4.2-final/./gcc/cc1 -E -lang-fortran -traditional-cpp -D_LANGUAGE_FORTRAN -quiet -v -I. -I/scratch/obj.x86_64/buildroot.arm/toolchain_build_arm/gcc-4.2/libgfortran -I. -I/scratch/obj.x86_64/buildroot.arm/toolchain_build_arm/gcc-4.2/libgfortran/../gcc -I/scratch/obj.x86_64/buildroot.arm/toolchain_build_arm/gcc-4.2/libgfortran/../gcc/config -I../.././gcc -I . -iprefix /scratch/obj.x86_64/buildroot.arm/toolchain_build_arm/gcc-4.2-final/gcc/../lib/gcc/arm-linux-uclibcgnueabi/4.2.0/ -isystem /scratch/obj.x86_64/buildroot.arm/toolchain_build_arm/gcc-4.2-final/./gcc/include -DHAVE_CONFIG_H -D_GNU_SOURCE -DPIC -isystem /scratch/obj.x86_64/buildroot.arm/build_arm/staging_dir/arm-linux-uclibcgnueabi/include -isystem /scratch/obj.x86_64/buildroot.arm/build_arm/staging_dir/arm-linux-uclibcgnueabi/sys-include -iquote/scratch/obj.x86_64/buildroot.arm/toolchain_build_arm/gcc-4.2/libgfortran/io /scratch/obj.x86_64/buildroot.arm/toolchain_build_arm/gcc-4.2/libgfortran/generated/_mod_i8.F90 -Wall -fno-repack-arrays -fno-underscoring -fPIC -fworking-directory -O2 -o ice_on_armeabi.f95 $ egrep -v ^(#|$|!) ice_on_armeabi.f95 elemental function specific__mod_i8 (p1, p2) integer (kind=8), intent (in) :: p1, p2 integer (kind=8) :: specific__mod_i8 specific__mod_i8 = mod (p1, p2) end function (gdb) run Starting program: /scratch/obj.x86_64/buildroot.arm/toolchain_build_arm/gcc-4.2-final/gcc/f951 ice_on_armeabi.f95 -ffree-form -quiet -dumpbase _mod_i8.F90 -auxbase-strip .libs/_mod_i8.o -g -O2 -Wall -version -fno-repack-arrays -fno-underscoring -fPIC -I. -I/scratch/obj.x86_64/buildroot.arm/toolchain_build_arm/gcc-4.2/libgfortran -I. -I/scratch/obj.x86_64/buildroot.arm/toolchain_build_arm/gcc-4.2/libgfortran/../gcc -I/scratch/obj.x86_64/buildroot.arm/toolchain_build_arm/gcc-4.2/libgfortran/../gcc/config -I../.././gcc -I . -fpreprocessed -I finclude -o /dev/null GNU F95 version 4.2.0 20070115 (prerelease) (arm-linux-uclibcgnueabi) compiled by GNU C version 4.0.3 (Ubuntu 4.0.3-1ubuntu5). GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Program received signal SIGSEGV, Segmentation fault. aggregate_value_p (exp=0x0, fntype=0x0) at /scratch/obj.x86_64/buildroot.arm/toolchain_build_arm/gcc-4.2/gcc/function.c:1756 1756 tree type = (TYPE_P (exp)) ? exp : TREE_TYPE (exp); (gdb) bt #0 aggregate_value_p (exp=0x0, fntype=0x0) at /scratch/obj.x86_64/buildroot.arm/toolchain_build_arm/gcc-4.2/gcc/function.c:1756 #1 0x004dbdc5 in emit_library_call_value_1 (retval=1, orgfun=0x2b15ea40, value=0x0, fn_type=LCT_CONST, outmode=TImode, nargs=value optimized out, p=0x7fa29800) at /scratch/obj.x86_64/buildroot.arm/toolchain_build_arm/gcc-4.2/gcc/calls.c:3312 #2 0x004dc435 in emit_library_call_value (orgfun=0x0, value=0x0, fn_type=LCT_THROW, outmode=TImode, nargs=2) at /scratch/obj.x86_64/buildroot.arm/toolchain_build_arm/gcc-4.2/gcc/calls.c:3967 #3 0x005d9b7a in expand_twoval_binop_libfunc ( binoptab=value optimized out, op0=0x2b1989e0, op1=0x2b1989c0, targ0=dwarf2_read_address: Corrupted DWARF expression. ) at /scratch/obj.x86_64/buildroot.arm/toolchain_build_arm/gcc-4.2/gcc/optabs.c:2283 #4 0x0052b6e9 in expand_divmod (rem_flag=1, code=TRUNC_MOD_EXPR, mode=DImode, op0=0x2b1989e0, op1=0x2b1989c0, target=0x2b198980, unsignedp=0) at /scratch/obj.x86_64/buildroot.arm/toolchain_build_arm/gcc-4.2/gcc/expmed.c:4914 #5 0x00534bcd in expand_expr_real_1 (exp=value optimized out, target=0x2b198980, tmode=value optimized out, modifier=value optimized out, alt_rtl=0x0) at /scratch/obj.x86_64/buildroot.arm/toolchain_build_arm/gcc-4.2/gcc/expr.c:8189 #6 0x005382cb in expand_expr_real (exp=0x2b0ec370, target=0x2b198980, tmode=DImode, modifier=EXPAND_NORMAL, alt_rtl=0x0) at /scratch/obj.x86_64/buildroot.arm/toolchain_build_arm/gcc-4.2/gcc/expr.c:6706 #7 0x00631324 in expand_return (retval=0x2b0ec5a0) at expr.h:493 #8 0x00534995 in expand_expr_real_1 (exp=value optimized out, target=0x2b0eb400, tmode=value optimized out, modifier=value optimized out, alt_rtl=0x0) at /scratch/obj.x86_64/buildroot.arm/toolchain_build_arm/gcc-4.2/gcc/expr.c:8613 #9 0x005382cb in expand_expr_real (exp=0x2b197100, target=0x2b0eb400, tmode=VOIDmode, modifier=EXPAND_NORMAL, alt_rtl=0x0) at /scratch/obj.x86_64/buildroot.arm/toolchain_build_arm/gcc-4.2/gcc/expr.c:6706 #10 0x00630fd9 in expand_expr_stmt (exp=0x0) at expr.h:493 #11 0x0065ac16 in expand_gimple_basic_block (bb=0x2b19a100) at /scratch/obj.x86_64/buildroot.arm/toolchain_build_arm/gcc-4.2/gcc/cfgexpand.c:1383 #12 0x0065bd0b in tree_expand_cfg () at /scratch/obj.x86_64/buildroot.arm/toolchain_build_arm/gcc-4.2/gcc/cfgexpand.c:1649 #13 0x006591c8
[Bug fortran/30487] New: Math implicit function in forall statement causes compiler error
Hi: I noticed that whenever I use a math function (such as sqrt, cos, log) in a forall all statement that further uses of that function caused gfortran to say that the function has no implicit type. I've shown an example program below: program test implicit none integer :: i real :: a, c(5) = (/1.0,2.0,3.0,4.0,5.0/), d(5) a = sqrt(2.0) d(:) = 0.0 forall (i = 1:5, sqrt(c(i)) 2.0) d(i) = i end forall end program test If I try to compile the above program I get the following error: In file test.f90:8 a = sqrt(2.0) 1 Error: Symbol 'sqrt' at (1) has no IMPLICIT type If I comment out the line a = sqrt(2.0), everything works fine. Also, if I don't use the sqrt test in the forall statement, everything works fine. If you substitute other mathematical functions for sqrt (such as log or cos) it fails to compile in a similar way. I tried this in the latest experimental build (downloaded from the gfortran wiki) and had similar problems. Thank You -- Summary: Math implicit function in forall statement causes compiler error Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: icksa1 at gmail 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=30487
[Bug c/8268] no compile time array index checking
--- Comment #41 from dcb314 at hotmail dot com 2007-01-16 21:18 --- (In reply to comment #40) I've a patch, which is currently blocked by -fivopts bug Still blocked ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8268
[Bug fortran/30487] Math implicit function in forall statement causes compiler error
--- Comment #1 from burnus at gcc dot gnu dot org 2007-01-16 21:30 --- Confirmed with gfortran 4.3.0 20070116. -- 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 GCC build triplet|i686-pc-linux-gnu | GCC host triplet|i686-pc-linux-gnu | GCC target triplet|i686-pc-linux-gnu | Keywords||rejects-valid Last reconfirmed|-00-00 00:00:00 |2007-01-16 21:30:26 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30487
[Bug c/30456] tgmath.h not found
--- Comment #2 from schnetter at aei dot mpg dot de 2007-01-16 21:45 --- This is what Apple thinks about tgmath.h. See http://developer.apple.com/releasenotes/DeveloperTools/RN-GCC4/index.html: Major bugs fixed in this release of GCC 4.0: radar 2872232: Compiler should provide a tgmath.h This means that Apple thinks that tgmath.h should ship with the compiler, and the Apple-modified versions of gcc will contain it. The operating system won't. Hence vanilla versions of gcc won't find tgmath.h on Apple machines. I have opened a bug report with Apple, Bug ID# 4927542. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30456
[Bug fortran/30481] Accepts namelist-group object with assumed character length
--- Comment #1 from burnus at gcc dot gnu dot org 2007-01-16 21:50 --- Fortran 95: Constraint: A namelist-group-object shall not be an array dummy argument with a nonconstant bound, a variable with nonconstant character length, an automatic object, a pointer, a variable of a type that has an ultimate component that is a pointer, or an allocatable array. Actually, I have problems to find this constrain explicitly in Fortran 2003. I believe it must be buried in the last paragraph. 5.4 NAMELIST statement C574 (R553) A namelist-group-object shall not be an assumed-size array. A namelist group object shall either be accessed by use or host association or shall have its type, type parameters, and shape specified by previous specification statements or the procedure heading in the same scoping unit or by the implicit typing rules in effect for the scoping unit. If a namelist group object is typed by the implicit typing rules, its appearance in any subsequent type declaration statement shall confirm the implied type and type parameters. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30481
[Bug c/16202] The -Wsequence-point warning misses many important instances
--- Comment #7 from manu at gcc dot gnu dot org 2007-01-16 22:02 --- (In reply to comment #5) Created an attachment (id=7299) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7299action=view) [edit] proposed patch I've attached a more official-looking patch, with a testsuite change to gcc.dg/sequence-pt-1.c and a new sequence-pt-2.c Could you send your patch to [EMAIL PROTECTED], please ? Thanks. You can find more info on contributing to GCC development at: http://gcc.gnu.org/contribute.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16202
[Bug target/30484] Miscompilation of remainder expressions on CPUs of the i386 family
--- Comment #1 from vincent at vinc17 dot org 2007-01-16 22:03 ---
Is this specific to x86? On PowerPC (gcc 4.0.1 from Mac OS X), I get:
-2147483648 % -1 - -2147483648
Ditto with:
#include limits.h
#include stdio.h
int main (void)
{
volatile int i = INT_MIN, j = -1;
printf (%d\n, i % j);
return 0;
}
--
vincent at vinc17 dot org changed:
What|Removed |Added
CC||vincent at vinc17 dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30484
[Bug target/30484] Miscompilation of remainder expressions on CPUs of the i386 family
--- Comment #2 from vincent at vinc17 dot org 2007-01-16 22:10 --- -2147483648, this was on a G5, with gcc 4.0.1 under Mac OS X. On a G4 under Linux, with gcc 4.1.2 prerelease (Debian), I get 2147483647. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30484
[Bug target/30484] Miscompilation of remainder expressions on CPUs of the i386 family
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-01-16 22:11 --- (In reply to comment #1) Is this specific to x86? On PowerPC (gcc 4.0.1 from Mac OS X), I get: This is because the PPC ISA says for divide: If an attempt is made to perform either of the divisions -- 0x8000_ / -1 or anything / 0, then the contents of rD are undefined, as are the contents of the LT, GT, and EQ bits of the CR0 field (if Rc = 1). In this case, if OE = 1 then OV is set. The 32-bit signed remainder of diving the contents of rA by the contents of rB can be computed as follows, exept in the case that hthe constnat of ra = - 2^31 and the constants of rB = -1. divw rD, rA, rB mullw rD, rD, rB subf rD, rD, rA -- So the ISA in fact even mentions this case :). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30484
[Bug target/30484] Miscompilation of remainder expressions on CPUs of the i386 family
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-01-16 22:15 --- (In reply to comment #3) So the ISA in fact even mentions this case :). But the PPC compiler writers guide does not talk about that case, hmmm. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|major |normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30484
[Bug c/16202] The -Wsequence-point warning misses many important instances
--- Comment #8 from manu at gcc dot gnu dot org 2007-01-16 22:35 --- (In reply to comment #5) Created an attachment (id=7299) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7299action=view) [edit] proposed patch I've attached a more official-looking patch, with a testsuite change to gcc.dg/sequence-pt-1.c and a new sequence-pt-2.c This patch does not even compile on current mainline, since lvalue_p was moved out of c-common.c to c-typeck.c and to cp/tree.c :( -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16202
[Bug libgcj/30454] [4.3 Regression] classpath/gnu/javax/crypto/jce/GnuCrypto.java:431: error: cannot find file for class gnu.javax.crypto.jce.mac.HMacSHA512Spi
--- Comment #4 from dave at hiauly1 dot hia dot nrc dot ca 2007-01-16 23:04 --- Subject: Re: [4.3 Regression] classpath/gnu/javax/crypto/jce/GnuCrypto.java:431: error: cannot find file for class gnuRO make -j 2 bootstrap Error also occurs with make bootstrap. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30454
[Bug c++/11856] unsigned warning in template
--- Comment #13 from manu at gcc dot gnu dot org 2007-01-17 00:47 ---
#include cassert
template typename Int, Int D
void f(Int x) {
assert(0 = x and x = D);
}
int main() {
funsigned char, 2(5);
fsigned char, 2(5);
}
We don't emit a warning when instantiated as a signed char, so everything boils
down to having an option to disable the warning, doesn't it?
There is a patch pending review for that:
http://gcc.gnu.org/ml/gcc-patches/2007-01/msg01120.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11856
[Bug c++/11856] unsigned warning in template
--- Comment #14 from gdr at cs dot tamu dot edu 2007-01-17 00:59 ---
Subject: Re: unsigned warning in template
manu at gcc dot gnu dot org [EMAIL PROTECTED] writes:
| #include cassert
| template typename Int, Int D
| void f(Int x) {
| assert(0 = x and x = D);
| }
| int main() {
| funsigned char, 2(5);
| fsigned char, 2(5);
| }
|
|
| We don't emit a warning when instantiated as a signed char, so everything
boils
| down to having an option to disable the warning, doesn't it?
the logical inference escapes me.
-- Gaby
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11856
[Bug c++/11856] unsigned warning in template
--- Comment #15 from manu at gcc dot gnu dot org 2007-01-17 01:11 --- (In reply to comment #14) | We don't emit a warning when instantiated as a signed char, so everything boils | down to having an option to disable the warning, doesn't it? the logical inference escapes me. Is having an option to disable the warning the right fix for this PR or is it not? If it is, there is a patch pending review. If it is not, could you explain what would be the correct behaviour? Thanks. -- manu at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|manu 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=11856
[Bug c++/11856] unsigned warning in template
--- Comment #16 from gdr at cs dot tamu dot edu 2007-01-17 01:30 --- Subject: Re: unsigned warning in template manu at gcc dot gnu dot org [EMAIL PROTECTED] writes: | (In reply to comment #14) | | We don't emit a warning when instantiated as a signed char, so everything | boils | | down to having an option to disable the warning, doesn't it? | | the logical inference escapes me. | | | Is having an option to disable the warning the right fix for this PR or is it | not? You made an inference in an earlier message, and I would like to understand it. Because, I do not believe a nobe in form of hey, you can silence it with with sledge-hammer is the solution to this particular type of constructs -- note that constants are involved. Care to explain further your earlier message? -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11856
[Bug c++/11856] unsigned warning in template
--- Comment #17 from tromey at gcc dot gnu dot org 2007-01-17 01:32 --- A flag to control the warning does not provide fine enough granularity of control. That is, sometimes the warning is appropriate, and disabling the warning would let through code that you would prefer not to let through. One idea would be to disable the warning if the expression involves types which came from a template instantiation (sorry, I don't know the C++ terminology for this). This at least would suitably solve the case I ran into while writing gcjx. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11856
[Bug fortran/30487] Math implicit function in forall statement causes compiler error
--- Comment #2 from kargl at gcc dot gnu dot org 2007-01-17 01:37 --- A workaround for this problem is place parentheses around the mask in the forall. The parentheses force evaluation of the expression whereas gfortran is apparently taking a different path through the compiler without. *** This bug has been marked as a duplicate of 30400 *** -- kargl at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30487
[Bug fortran/30400] ANY not accepted as mask in FORALL
--- Comment #2 from kargl at gcc dot gnu dot org 2007-01-17 01:37 --- *** Bug 30487 has been marked as a duplicate of this bug. *** -- kargl at gcc dot gnu dot org changed: What|Removed |Added CC||icksa1 at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30400
[Bug c++/11856] unsigned warning in template
--- Comment #18 from gdr at cs dot tamu dot edu 2007-01-17 01:46 --- Subject: Re: unsigned warning in template tromey at gcc dot gnu dot org [EMAIL PROTECTED] writes: | A flag to control the warning does not provide | fine enough granularity of control. Indeed. | That is, sometimes | the warning is appropriate, and disabling the warning | would let through code that you would prefer not to let through. Indeed. The particularity of this PR is that it involves only constants. It that case, the compiler should just elide the warning. That would be a first order approximation of a solution to this issue. | One idea would be to disable the warning if the expression involves | types which came from a template instantiation (sorry, I don't know | the C++ terminology for this). Please, don't sorry about the terminology. The particularity of such expressions is that they are constants. And I would like we solve this not just for template arguments, but of such comparaison involving constants. Tom, what do you think? -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11856
[Bug c++/11856] unsigned warning in template
--- Comment #19 from manu at gcc dot gnu dot org 2007-01-17 03:49 ---
(In reply to comment #16)
Subject: Re: unsigned warning in template
manu at gcc dot gnu dot org [EMAIL PROTECTED] writes:
| (In reply to comment #14)
| | We don't emit a warning when instantiated as a signed char, so
everything
| boils
| | down to having an option to disable the warning, doesn't it?
|
| the logical inference escapes me.
|
|
| Is having an option to disable the warning the right fix for this PR or is
it
| not?
You made an inference in an earlier message, and I would like to
understand it. Because, I do not believe a nobe in form
of hey, you can silence it with with sledge-hammer is the solution to this
particular type of constructs -- note that constants are involved.
Care to explain further your earlier message?
Of course. I was reflecting on the fact that we don't warn when the template is
instantiated as signed int. Also, we don't warn for template parameters:
template typename Int, Int D
void g(void) {
assert(0 = D);
}
int gg(void) {
gunsigned char, 2();
}
However, those are different from the template testcase discussed here. Yet,
since the comparison in the template testcase seems to me as constant as in
this case:
#include cassert
void f(unsigned char c) {
assert(0 = c and c = 2);
}
int main() {
f(5);
}
and as far as I know front-ends cannot do dataflow solving, I wrongly concluded
that there was nothing else we could do. If you have a solution in mind, that
is great! I hope you manage to find time to implement it. Being able to know
the value of c would be very useful for many other warnings, -Wconversion in
particular, so I will learn a lot from your patch.
Nonetheless, having an individual option -Wcomparison-fixed to enabled/disable
this unnamed warning seems worthwhile by itself and it is also useful as a
temporary work-around while you are working in your patch.
Also, the same patch will close PR 23587 and PR 12963 and come closer to fix PR
7651.
We can keep this PR open until your patch is committed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11856
[Bug libstdc++/30463] [regression] -Wconversion triggers warnings for vector::push_back()
--- Comment #1 from pcarlini at suse dot de 2007-01-17 04:20 --- I'm marking this one as duplicate of the other: by now we know well it's really the same issue and in any case an audit is necessary (assuming the warning stays, of course) *** This bug has been marked as a duplicate of 30464 *** -- pcarlini at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30463
[Bug libstdc++/30464] [regression] -Wconversion triggers warnings for deque::push_back()
--- Comment #8 from pcarlini at suse dot de 2007-01-17 04:20 --- *** Bug 30463 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30464
[Bug libstdc++/30464] [regression] -Wconversion triggers warnings for deque::push_back()
--- Comment #9 from pcarlini at suse dot de 2007-01-17 04:22 --- Gaby, any news about the signed - unsigned warning itself? Are we going to keep it or are we coming to the conclusion it's too noisy? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30464
[Bug libstdc++/30482] complex division by 0
--- Comment #1 from pcarlini at suse dot de 2007-01-17 04:48 --- Jakub, a few observations: the first one, we have got other PRs about complex math (e.g., 24581, 28408), I don't know if you are aware of that, it would be great if you could have a unified look. Also, I don't think we want to change the library here (like in you link), I think we discussed this kind of solution for such troubles other times and we came to the conclusion that really these are compiler issues, because we are relying in a very straightforward way on the complex extension (maybe Gaby has something to add). Also, as you may also find in some of the existing audit trails and past discussions on gcc@, people is particularly troubled by the large differences in behavior when optimizing and not, I think we should tackle that issue. Ah, maybe the most important point for this specific PR: I think we *do* want a behavior of the complex division in C++ consistent with C99 (and LIA-2, which, AFAIK, is consistent with C99), for many different reasons, among other things, the new standard will be based on C99, not C89, probably Gaby has something to add. Unfortunately, I'm afraid the way we are implementing C99 vs complex in the middle-end is buggy, see 24581, Joseph' comments in particular, but consistency between the C99 and the C++ math seems to me an improvement anyway. -- pcarlini at suse dot de changed: What|Removed |Added CC||gdr at integrable-solutions ||dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30482
[Bug testsuite/30489] New: treelang.log ends up in main testsuite dir, not treelang subdir.
After make check-treelang, I have a treelang subdirectory within build/gcc/testsuite, but no files end up in it, and treelang.log ends up in the build/gcc/testsuite directory. -- Summary: treelang.log ends up in main testsuite dir, not treelang subdir. Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: brooks at gcc dot gnu dot org 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=30489
[Bug c++/30470] Compiling C++ programs with -mno-80387 and -O3 failes
--- Comment #9 from ubizjak at gmail dot com 2007-01-17 06:58 --- (In reply to comment #4) Testcase compiles OK with gcc version 4.3.0 20070115 (experimental). Uh, I was compiling in 32bit mode. For x86_64 compilation fails as documented in comment #3. -- ubizjak at gmail dot com changed: What|Removed |Added Known to work|4.3.0 | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30470
[Bug target/30484] Miscompilation of remainder expressions on CPUs of the i386 family
--- Comment #5 from jv244 at cam dot ac dot uk 2007-01-17 07:14 --- (In reply to comment #0) The program below shows (at all the optimization levels) a miscompilation of the remainder expression that causes INT_MIN % -1 to cause a SIGFPE on CPUs of the i386 family. notice that this is language dependent. I.e. in Fortran the equivalent of the above 'INT_MIN % -1' is undefined. So, whatever the fix for C and friends, it should not slow down Fortran programs using MOD. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30484
[Bug middle-end/30473] [4.0/4.1/4.2/4.3 Regression] Internal Compiler Error with a sprintf with few arguments for format %s
--- Comment #2 from avg07 at tid dot es 2007-01-17 07:23 --- Created an attachment (id=12912) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12912action=view) patch to rev 120440: make additional check on arglist -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30473
