[Bug c++/32112] [4.1/4.2/4.3 regression] #'unbound_class_template' not supported by dump_decl#
--- Comment #2 from pcarlini at suse dot de 2007-08-10 09:51 --- Seems manageable... -- pcarlini at suse dot de changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-08-10 09:51:55 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32112
[Bug fortran/31538] misleading bounds check error
--- Comment #5 from burnus at gcc dot gnu dot org 2007-08-10 09:43 --- Newly created test case. Expected: * Extend (size) should be printed for "a = f()", as NAG f95 does (I'm not sure that "different shape" is correct for the current a=b message; additionally, the A should not be capitalized and the D in different should.) integer :: a(-4:1), b(0:4) b = 5 ! a(-4:1) = b(0:4) ! Error: different shape for Array ! ! assignment at (1) on dimension 1 (6/5) ! ! gfortran: Array bound mismatch for dimension 1 of array 'f' ! NAG f95: Rank 1 of array operand has extent 5 instead of 2 a(i:1) = f(b) contains function f(x) integer :: x(:),f(size(x)) f = x end function end -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31538
[Bug debug/32990] [Regression] gdb has symbol table issues
--- Comment #3 from scovich at gmail dot com 2007-08-10 16:20 --- Created an attachment (id=14050) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14050&action=view) Output of readelf -wf I'm attaching the output of `readelf -wf' This time around some of offending PC are 0x41ac8c, 0x41bc1c, 0x41bc2d, 0x41bc44, 0x41bc45, 0x41bc55, 0x41bc56, 0x41bc63, 0x41bc64. Also in case it helps, `readelf -a' prints the following warning/error messages: readelf: Warning: There is a hole [0xe1fc - 0xe238] in .debug_loc section. readelf: Warning: There is a hole [0x100dc - 0x10118] in .debug_loc section. readelf: Warning: There is a hole [0x13860 - 0x1389c] in .debug_loc section. readelf: Warning: There is a hole [0x138ac - 0x138e8] in .debug_loc section. readelf: Warning: There is a hole [0x13c3c - 0x13c78] in .debug_loc section. readelf: Warning: There is a hole [0x13f34 - 0x13f70] in .debug_loc section. readelf: Warning: There is a hole [0x13f80 - 0x13fbc] in .debug_loc section. readelf: Warning: There is a hole [0x14148 - 0x14184] in .debug_loc section. readelf: Warning: There is a hole [0x15908 - 0x15944] in .debug_loc section. readelf: Warning: There is a hole [0x16618 - 0x16654] in .debug_loc section. readelf: Warning: There is a hole [0x17f54 - 0x17f90] in .debug_loc section. readelf: Warning: There is a hole [0x17fec - 0x18028] in .debug_loc section. readelf: Warning: There is a hole [0x1824c - 0x18288] in .debug_loc section. readelf: Warning: There is a hole [0x184ac - 0x184e8] in .debug_loc section. readelf: Warning: There is a hole [0x18590 - 0x185cc] in .debug_loc section. readelf: Warning: There is a hole [0x22a08 - 0x22a44] in .debug_loc section. readelf: Warning: There is a hole [0x232f0 - 0x2332c] in .debug_loc section. readelf: Warning: There is a hole [0x26944 - 0x26980] in .debug_loc section. readelf: Warning: There is a hole [0x29320 - 0x2935c] in .debug_loc section. readelf: Warning: There is a hole [0x29878 - 0x298b4] in .debug_loc section. readelf: Warning: There is a hole [0x29910 - 0x2994c] in .debug_loc section. readelf: Error: Range lists in .debug_info section aren't in ascending order! readelf: Warning: There is a hole [0x50 - 0xb0] in .debug_ranges section. readelf: Warning: There is an overlap [0x2fe0 - 0x50] in .debug_ranges section. readelf: Warning: There is a hole [0xb0 - 0x3010] in .debug_ranges section. readelf: Warning: There is an overlap [0x30b0 - 0x2fe0] in .debug_ranges section. readelf: Warning: There is a hole [0x3010 - 0x56e0] in .debug_ranges section. readelf: Warning: There is a hole [0x7610 - 0x76d0] in .debug_ranges section. readelf: Warning: There is an overlap [0x7700 - 0x7610] in .debug_ranges section. readelf: Warning: There is a hole [0x76d0 - 0x9b40] in .debug_ranges section. readelf: Warning: There is an overlap [0xd700 - 0x9a20] in .debug_ranges section. readelf: Warning: There is a hole [0x9b40 - 0xd700] in .debug_ranges section. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32990
[Bug target/32894] Segmentation fault bootstrapping on HP-UX 11.11
--- Comment #4 from pda at freeshell dot org 2007-08-10 16:51 --- I'll get the other info you asked for a little later, but in the meantime here's my output from gcc-3.3.6 -v. The as and ld referred to are binutils-2.17, and I believe I also tried with binutils-2.16.1. I may not have yet tried binutils-2.16, which I thing is what my gcc-3.3.6 was originally configured for. Perhaps that's really the problem? Reading specs from /usr/local/64bit/lib/gcc-lib/hppa64-hp-hpux11.11/3.3.6/specs Configured with: /usr/local/src/gcc-3.3.6/configure --host=hppa64-hp-hpux11.11 --enable-languages=c,c++ --enable-threads=posix --enable-shared --with-stabs --with-gnu-as --with-as=/usr/local/64bit/bin/as --with-gnu-ld --with-ld=/usr/local/64bit/bin/ld --disable-nls --prefix=/usr/local/64bit --prefix=/usr/local/64bit Thread model: posix gcc version 3.3.6 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32894
[Bug tree-optimization/32941] [4.3 regression] Bootstrap comparison failure
--- Comment #11 from schwab at suse dot de 2007-08-10 17:16 --- Looks good. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32941
[Bug libffi/28313] libffi has not been ported to mips64-linux-gnu
--- Comment #4 from daney at gcc dot gnu dot org 2007-08-10 15:36 --- Subject: Bug 28313 Author: daney Date: Fri Aug 10 15:35:55 2007 New Revision: 127336 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127336 Log: PR libffi/28313 * configure.ac: Don't treat mips64 as a special case. * Makefile.am (nodist_libffi_la_SOURCES): Add n32.S. * configure: Regenerate * Makefile.in: Ditto. * fficonfig.h.in: Ditto. * src/mips/ffitarget.h (REG_L, REG_S, SUBU, ADDU, SRL, LI): Indent. (LA, EH_FRAME_ALIGN, FDE_ADDR_BYTES): New preprocessor macros. (FFI_DEFAULT_ABI): Set for n64 case. (FFI_CLOSURES, FFI_TRAMPOLINE_SIZE): Define for n32 and n64 cases. * src/mips/n32.S (ffi_call_N32): Add debug macros and labels for FDE. (ffi_closure_N32): New function. (.eh_frame): New section * src/mips/o32.S: Clean up comments. (ffi_closure_O32): Pass ffi_closure parameter in $12. * src/mips/ffi.c: Use FFI_MIPS_N32 instead of _MIPS_SIM == _ABIN32 throughout. (FFI_MIPS_STOP_HERE): New, use in place of ffi_stop_here. (ffi_prep_args): Use unsigned long to hold pointer values. Rewrite to support n32/n64 ABIs. (calc_n32_struct_flags): Rewrite. (calc_n32_return_struct_flags): Remove unused variable. Reverse position of flag bits. (ffi_prep_cif_machdep): Rewrite n32 portion. (ffi_call): Enable for n64. Add special handling for small structure return values. (ffi_prep_closure_loc): Add n32 and n64 support. (ffi_closure_mips_inner_O32): Add cast to silence warning. (copy_struct_N32, ffi_closure_mips_inner_N32): New functions. Modified: trunk/libffi/ChangeLog trunk/libffi/Makefile.am trunk/libffi/Makefile.in trunk/libffi/configure trunk/libffi/configure.ac trunk/libffi/fficonfig.h.in trunk/libffi/src/mips/ffi.c trunk/libffi/src/mips/ffitarget.h trunk/libffi/src/mips/n32.S trunk/libffi/src/mips/o32.S -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28313
[Bug fortran/32937] segfault with string and -fdefault-integer-8
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-08-10 15:31 --- The problem with integer kind is from the string length: character(2_8) :: c(2) integer :: i c = "aa" print *, c .eq. "aa" call foo ((/(c(i), i = 1,2)/)) print *, c .eq. "aa" contains subroutine foo (c) character(*), dimension(:) :: c end subroutine foo end If you compile it and set a breakpoint on the translation of the string comparison (which is trans-expr.c:1172), and print out the tree that is the length of c (lse.string_length), you get the first time: constant invariant 2> $3 = void which is correct, while the second time you get: constant invariant 2> which is wrong: the charlen type is int4, not int8. Somehow, the conjunction of function call and temporary produces this, because if you remove either the function call or the need for a temporary, the code is then correct. >From what I seem there is a cl->backend_decl somewhere (or a string_length) that is generated refering to this int8 constant, which should never happen. I haven't been able to find out where this happens, though. PS: in the mean time, I've found what I think is an unrelated bug. This is the only occurrence that I could find of an cl->backend_decl with wrong type, but it doesn't fix this bug ;-) Index: trans-expr.c === --- trans-expr.c(revision 127334) +++ trans-expr.c(working copy) @@ -1855,6 +1851,7 @@ gfc_conv_aliased_arg (gfc_se * parmse, g gfc_array_index_type); tmp = fold_build2 (MINUS_EXPR, gfc_array_index_type, tmp, tmp_se.expr); + tmp = fold_convert (gfc_charlen_type_node, tmp); expr->ts.cl->backend_decl = tmp; break; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32937
[Bug debug/33044] New: Local variables in C++ constructor not visible for debugging
SUMMARY:
In gcc 3.2.3 (and other versions) the DWARF information created by gcc does not
create DW_AT_location attribute for local (static) variables inside a C++
constructor.
WHAT::
The reproducer below shows TWO problems related to debug information available
regarding variables inside a C++ a constructor. One type is (1) a local
variable inside a constructor and second type is (2) a local _static_ variable
inside a constructor. Sometimes TV is able to see the case (1) but only in the
Program Browser (PB); but case (2) is never correctly shown in TV, neither when
Diving, Stack Frame or in PB.
For some versions of gcc TV can show type (1) in the PB, but for all gcc
versions TV fails to show type (2) at all.
This problem is not related to TV alone, GDB fails to see these variables as
well.
On gcc 3.2.3, TV can see type (1) only in PB, but type (2) is
not visible to TV at all (only in symtable).
With PGI-7.0.5 (and some other non-gcc compilers) TV can see everything
alright.
REPRODUCE/TEST::
See attached c++ file.
dbreak 25
drun
dprint iii
dprint foofoo
WHY::
In some gcc versions there is no DWARF information whatsoever related to types
(1) and (2).
In gcc 3.2.3 (and others, e.g. 4.0.3) the DWARF information created by gcc does
not create DW_AT_location attribute for neither type (1) and (2), e.g.
less tx_local.gcc3.2.3.txt
<2><1760>: Abbrev Number: 41 (DW_TAG_variable)
DW_AT_name: foofoo
DW_AT_decl_file : 1
DW_AT_decl_line : 28
DW_AT_type: <178a>
less tx_local.pgi7.0.5.txt
<1><1048>: Abbrev Number: 14 (DW_TAG_variable)
DW_AT_name: foofoo
DW_AT_type: <1864>
DW_AT_location: 5 byte block: 3 30 e0 4 8 (DW_OP_addr: 804e030; )
Therefore TV (or gdb) does not have enough information to resolve these
variables.
These variables do exist in the symtable, e.g.:
d1.<> sgrep foofoo
{kind loader_symbol} {id 1|795} {full_pathname
##/nfs/netapp0/user/home/seppo/tx_local.out_gcc3.2.3#tx_local_var_cpp_constructor.cxx/_ZZN1AC1Eii\
E6foofoo} {artificial 0} {scope_owner 1|220} {loader_name _ZZN1AC1EiiE6foofoo}
\
{loader_file_path tx_local_var_cpp_constructor.cxx} {location {{ldam
0x97a0\
}}} {address_class module_static_var} {length 96} {weak 0}
#include
class A {
public:
A (int a, int b);
int a_;
int b_;
int c_;
};
A::A (int a, int b) : a_ (a), b_ (b), c_ (0)
{
int iii;
iii = 42;
c_ = a_ * b_;
c_ += iii;
static const int foofoo[6][4] = { {0,1,2,3},
{1,2,3,4},
{2,3,4,5},
{3,4,5,6},
{4,5,6,7},
{5,6,7,8} };
printf("c_ = %d\n", c_);
printf("foofoo = %d\n", foofoo);
}
int main (int, char* *)
{
int a = 34, b = 56;
A x (a, b);
return x.a_ + x.b_;
}
XX
--
Summary: Local variables in C++ constructor not visible for
debugging
Product: gcc
Version: 3.2.3
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: seppo at totalviewtech dot com
GCC build triplet: linux-x86 (2.6.16.13-4-smp)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33044
[Bug target/33042] [4.3 Regression] Bootstrap failure on ppc64
--- Comment #1 from dje at gcc dot gnu dot org 2007-08-10 18:48 --- Subject: Bug 33042 Author: dje Date: Fri Aug 10 18:48:33 2007 New Revision: 127348 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127348 Log: PR target/33042 * config/rs6000/driver-rs6000.c: Include link.h. Use ElfW instead of wordsize-specif typedef. Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/driver-rs6000.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33042
[Bug libfortran/32812] random_seed and date_and_time
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-08-10 19:04
---
I guess we have to scramble the seed given by the user, something like this:
Index: intrinsics/random.c
===
--- intrinsics/random.c (revision 127331)
+++ intrinsics/random.c (working copy)
@@ -32,6 +32,7 @@ Boston, MA 02110-1301, USA. */
#include "config.h"
#include "libgfortran.h"
#include
+#include
extern void random_r4 (GFC_REAL_4 *);
iexport_proto(random_r4);
@@ -639,6 +640,29 @@ arandom_r16 (gfc_array_r16 *x)
#endif
+
+
+static void
+scramble_seed (unsigned char *dest, unsigned char *src, int size)
+{
+ int i;
+
+ for (i = 0; i < size; i++)
+dest[(i % 2) * (size / 2) + i / 2] = src[i];
+}
+
+
+static void
+unscramble_seed (unsigned char *dest, unsigned char *src, int size)
+{
+ int i;
+
+ for (i = 0; i < size; i++)
+dest[i] = src[(i % 2) * (size / 2) + i / 2];
+}
+
+
+
/* random_seed is used to seed the PRNG with either a default
set of seeds or user specified set of seeds. random_seed
must be called with no argument or exactly one argument. */
@@ -647,6 +671,7 @@ void
random_seed (GFC_INTEGER_4 *size, gfc_array_i4 *put, gfc_array_i4 *get)
{
int i;
+ unsigned char seed[4*kiss_size];
__gthread_mutex_lock (&random_lock);
@@ -654,10 +679,8 @@ random_seed (GFC_INTEGER_4 *size, gfc_ar
{
/* From the standard: "If no argument is present, the processor assigns
a processor-dependent value to the seed." */
-
for (i=0; idim[0].ubound + 1 - put->dim[0].lbound)) < kiss_size)
runtime_error ("Array size of PUT is too small.");
- /* This code now should do correct strides. */
+ /* We copy the seed given by the user. */
for (i = 0; i < kiss_size; i++)
- kiss_seed[i] =(GFC_UINTEGER_4) put->data[i * put->dim[0].stride];
+ memcpy (seed + i * sizeof(GFC_UINTEGER_4),
+ &(put->data[(kiss_size - 1 - i) * put->dim[0].stride]),
+ sizeof(GFC_UINTEGER_4));
+
+ /* We put it after scrambling the bytes, to paper around users who
+provide low-quality seeds. */
+ scramble_seed ((unsigned char *) kiss_seed, seed, 4*kiss_size);
}
/* Return the seed to GET data. */
@@ -689,9 +718,14 @@ random_seed (GFC_INTEGER_4 *size, gfc_ar
if (((get->dim[0].ubound + 1 - get->dim[0].lbound)) < kiss_size)
runtime_error ("Array size of GET is too small.");
+ /* Unscramble the seed. */
+ unscramble_seed (seed, (unsigned char *) kiss_seed, 4*kiss_size);
+
/* This code now should do correct strides. */
for (i = 0; i < kiss_size; i++)
-get->data[i * get->dim[0].stride] = (GFC_INTEGER_4) kiss_seed[i];
+ memcpy (&(get->data[(kiss_size - 1 - i) * get->dim[0].stride]),
+ seed + i * sizeof(GFC_UINTEGER_4),
+ sizeof(GFC_UINTEGER_4));
}
__gthread_mutex_unlock (&random_lock);
This doesn't make miracles (i.e. provide you with a good seed when you input a
particularly poor one), but at least it makes using the VALUES of DATE_AND_TIME
less frustrating (by generating visibly different streams of PRN).
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||patch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32812
[Bug libfortran/32812] random_seed and date_and_time
--- Comment #3 from kargl at gcc dot gnu dot org 2007-08-10 19:10 --- UGH. I'd rather document gfortran's behavior than add additional hacks into the compiler. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32812
[Bug libfortran/32812] random_seed and date_and_time
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-08-10 19:23 --- (In reply to comment #3) > UGH. > > I'd rather document gfortran's behavior than add additional hacks > into the compiler. Hum, I was of the same opinion at first. What somehow convinced me that it might be worth the price is that the use of DATE_AND_TIME to initialize the random seed is actually in the Metcalf book. There is a nice chance that it will end up in most user codes. But, as you said, it's a hack, I'm not submitting a patch yet. I'd like to have Thomas' opinion first. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32812
[Bug debug/32990] [Regression] gdb has symbol table issues
--- Comment #5 from scovich at gmail dot com 2007-08-10 16:50 --- Murphy strikes again -- 5 minutes after closing this bug it popped back up in spite of a clean compile. Apparently `make clean' can change which PC causes complaints but doesn't necessarily fix the problem. -- scovich at gmail dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32990
[Bug c++/17763] [4.0/4.1/4.2 Regression] Wrong context in error message for template parameter
--- Comment #19 from paolo at gcc dot gnu dot org 2007-08-10 18:05 --- Subject: Bug 17763 Author: paolo Date: Fri Aug 10 18:04:46 2007 New Revision: 127345 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127345 Log: /cp 2007-08-10 Paolo Carlini <[EMAIL PROTECTED]> PR c++/17763 * error.c (dump_expr): Consistently use the *_cxx_* variants of the pretty-print functions. /testsuite 2007-08-10 Paolo Carlini <[EMAIL PROTECTED]> PR c++/17763 * g++.dg/other/error16.C: New. Added: branches/gcc-4_2-branch/gcc/testsuite/g++.dg/other/error16.C Modified: branches/gcc-4_2-branch/gcc/cp/ChangeLog branches/gcc-4_2-branch/gcc/cp/error.c branches/gcc-4_2-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17763
[Bug c++/17763] [4.0/4.1/4.2 Regression] Wrong context in error message for template parameter
--- Comment #21 from pcarlini at suse dot de 2007-08-10 18:06 --- Fixed for 4.1.3. -- pcarlini at suse dot de changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17763
[Bug fortran/32933] ICE in simplify_subreg with -fdefault-integer-8
--- Comment #11 from fxcoudert at gcc dot gnu dot org 2007-08-10 13:25 --- Fixed. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32933
[Bug fortran/33039] Read NAMELIST: reads wrong namelist name
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2007-08-10 12:43 --- Fixed on 4.3 -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33039
[Bug fortran/33039] Read NAMELIST: reads wrong namelist name
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2007-08-10 12:36 --- Subject: Bug 33039 Author: jvdelisle Date: Fri Aug 10 12:36:01 2007 New Revision: 127332 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127332 Log: 2007-08-10 Jerry DeLisle <[EMAIL PROTECTED]> PR libfortran/33039 * io/list_read.c (find_nml_name): Check for a space after a namelist name match. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/io/list_read.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33039
[Bug fortran/33039] Read NAMELIST: reads wrong namelist name
--- Comment #7 from jvdelisle at gcc dot gnu dot org 2007-08-10 12:40 --- Subject: Bug 33039 Author: jvdelisle Date: Fri Aug 10 12:39:46 2007 New Revision: 127333 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127333 Log: 2007-08-10 Jerry DeLisle <[EMAIL PROTECTED]> PR libfortran/33039 * gfortran.dg/namelist_37.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/namelist_37.f90 Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33039
[Bug c++/17763] [4.0/4.1/4.2/4.3 Regression] Wrong context in error message for template parameter
--- Comment #17 from pcarlini at suse dot de 2007-08-10 12:28 --- Working on the spurious space issue... -- pcarlini at suse dot de changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17763
[Bug c/33043] Miscompiled statement a[i] = (a[i]++) % x;
--- Comment #2 from gjasny at web dot de 2007-08-10 12:02 --- I've found: http://c-faq.com/expr/seqpoints.html *** This bug has been marked as a duplicate of 11751 *** -- gjasny at web dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33043
[Bug c/33043] Miscompiled statement a[i] = (a[i]++) % x;
--- Comment #1 from gjasny at web dot de 2007-08-10 10:51 --- Created an attachment (id=14049) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14049&action=view) Simple testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33043
[Bug c/33043] New: Miscompiled statement a[i] = (a[i]++) % x;
When the following program is compiled with gcc the output of the array-value is 1 2 3 4 5 6. Icc and cl produce the output 1 2 3 4 1 2. If the arrray is susbtituted by a simple scalar, the gcc output is 1 2 3 4 1 2, too. I don't know if the statement if even valid and behavior-defined C code. If it's not, then gcc maybe should warn somehow. Thanks, Gregor PS: This hapens with gcc-snapshot 20070720-1, too. -- Summary: Miscompiled statement a[i] = (a[i]++) % x; Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: gjasny at web dot de GCC build triplet: i486-pc-linux-gnu GCC host triplet: i486-pc-linux-gnu GCC target triplet: i486-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33043
[Bug middle-end/31979] ICE compiling openssl-0.9.8e/apps/ocsp.c
--- Comment #7 from clemens dot koller at anagramm dot de 2007-08-10 10:40 --- exactly the same openssl behaviour on embedded PowerPC e500 (gcc-4.2.1, openssl-0.9.8e, glibc-2.3.6) $ gcc -v Using built-in specs. Target: powerpc-unknown-linux-gnu Configured with: ../gcc-4.2.1/configure --prefix=/usr --libexecdir=/usr/lib --enable-languages=c,c++,objc --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-shared --disable-nls --with-x=no --with-cpu=8540 --with-tune=8540 --with-float=soft --with-long-double-128 --disable-multilib --enable-e500_double Thread model: posix gcc version 4.2.1 (ckcore) please contact if you need further debugging output. -- clemens dot koller at anagramm dot de changed: What|Removed |Added CC||clemens dot koller at ||anagramm dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31979
[Bug fortran/31629] option to make module entities PRIVATE by default
--- Comment #5 from arnaud02 at users dot sourceforge dot net 2007-08-10 09:46 --- For information, I added this option to g95 around 2001-2002 before the split gfortran-g95. The inspiration comes from the option "--private" of the Lahey-Fujitsu compiler. For some reason, this option was removed in November 2006 (http://gcc.gnu.org/ml/fortran/2006-11/msg00316.html). IMO, it can come handy and it is a good idea to keep it. Note that a test case would be welcome. -- arnaud02 at users dot sourceforge dot net changed: What|Removed |Added CC||arnaud02 at users dot ||sourceforge dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31629
[Bug libffi/12782] ffi.h #defines ffi_type_[us]long wrong on 32bit arches
--- Comment #7 from green at redhat dot com 2007-08-10 09:18 --- I believe the patch for this was checked in a long time ago. -- green at redhat dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12782
[Bug c++/22256] diagnostic shows wrong type for conversion operator
--- Comment #8 from pcarlini at suse dot de 2007-08-10 08:57 --- Fixed for 4.3.0. -- pcarlini at suse dot de changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22256
[Bug libffi/23718] ffitarget.h include problem
--- Comment #3 from daney at gcc dot gnu dot org 2007-08-10 08:17 --- *** This bug has been marked as a duplicate of 23935 *** -- daney at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23718
[Bug libffi/23935] $PREFIX/include/ffi.h needs to go to a target- and -version-dependent location
--- Comment #3 from daney at gcc dot gnu dot org 2007-08-10 08:17 --- *** Bug 23718 has been marked as a duplicate of this bug. *** -- daney at gcc dot gnu dot org changed: What|Removed |Added CC||bernd dot paysan at gmx dot ||de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23935
[Bug debug/32990] [Regression] gdb has symbol table issues
--- Comment #4 from scovich at gmail dot com 2007-08-10 16:39 --- The problem comes from adding a member function to a header file and only recompiling some of the source files that include it (make depend missed something). It looked like a regression because changing versions of gcc required a clean recompile. -- scovich at gmail dot com changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32990
[Bug fortran/33037] TRANSFER should warn on mismatched sizes
--- Comment #4 from pault at gcc dot gnu dot org 2007-08-10 08:47 --- Just for the record: 13.14.110 TRANSFER (SOURCE, MOLD [, SIZE]) ...snip... Result Value. If the physical representation of the result has the same length as that of SOURCE, the physical representation of the result is that of SOURCE. ***If the physical representation of the result is longer than that of SOURCE, the physical representation of the leading part is that of SOURCE and the remainder is undefined.*** If the physical representation of the result is shorter than that of SOURCE, the physical representation of the result is the leading part of SOURCE. If D and E are scalar variables such that the physical representation of D is as long as or longer than that of E, the value of TRANSFER (TRANSFER (E, D), E) shall be the value of E. IF D is an array and E is an array of rank one, the value of TRANSFER (TRANSFER (E, D), E, SIZE (E)) shall be the value of E. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33037
[Bug c++/22256] diagnostic shows wrong type for conversion operator
--- Comment #7 from paolo at gcc dot gnu dot org 2007-08-10 08:56 --- Subject: Bug 22256 Author: paolo Date: Fri Aug 10 08:56:34 2007 New Revision: 127331 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127331 Log: /cp 2007-08-10 Paolo Carlini <[EMAIL PROTECTED]> PR c++/22256 * decl.c (check_special_function_return_type): Just error on return type specified for conversion operator. /testsuite 2007-08-10 Paolo Carlini <[EMAIL PROTECTED]> PR c++/22256 * g++.dg/conversion/op3.C: New. Added: trunk/gcc/testsuite/g++.dg/conversion/op3.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22256
[Bug c++/33041] New: g++ incorrectly resolves an identically named templated struct in a super class
The following code compiles, but produces an incorrect result. I think this is
because g++ seems to incorrectly determine which templated struct foo should be
used (the one at the namespace level versus the member struct in bar). The two
lines in main() should produce the same result I think, but do not in practice.
The code should, when executed, produce "2\n2\n" I think, but it produces
"1\n2\n", showing an incorrect resolving of foo in the first line of
main().
Reproducable using 3.3 and 4.0 on OS X as well.
Test case code:
#include
struct bar {
typedef bar type;
template
struct foo {
static const int value = 2;
};
};
template
struct foo : bar {
static const int value = 1;
};
int main() {
// foo is the foo struct at namespace level, foo should be
the foo struct within bar, but it is not in g++
std::cout << foo::foo::value << std::endl;
// foo is again the foo struct at namespace level, ::type
explicitly takes its superclass so foo is the foo struct within bar.
std::cout << foo::type::foo::value << std::endl;
}
--
Summary: g++ incorrectly resolves an identically named templated
struct in a super class
Product: gcc
Version: 4.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: matthijs at bomhoff dot nl
GCC target triplet: i486-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33041
[Bug c++/32970] [4.3 Regression] C++ frontend can not handle vector pointer constant parameter
--- Comment #5 from saliu at de dot ibm dot com 2007-08-10 10:13 --- This patch can fix the problem: Index: gcc/tree.c === --- gcc.orig/tree.c +++ gcc/tree.c @@ -7609,8 +7609,11 @@ reconstruct_complex_type (tree type, tre else return bottom; - TYPE_READONLY (outer) = TYPE_READONLY (type); - TYPE_VOLATILE (outer) = TYPE_VOLATILE (type); + if (TYPE_READONLY (type)) +build_qualified_type(outer, TYPE_QUAL_CONST); + + if (TYPE_VOLATILE (type)) +build_qualified_type(outer, TYPE_QUAL_VOLATILE); return outer; } -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32970
[Bug c/33042] New: Bootstrap failure on ppc64
Starting from revision r127304 bootstrap fails on ppc64 (see below). I've checked that in r127330 it still fails. r127304 | dje | 2007-08-08 22:33:24 +0300 (Wed, 08 Aug 2007) | 12 lines * config/rs6000/x-rs6000: New file. * config/rs6000/darwin.h (CC1_SPEC): Add cc1_cpu. * config/rs6000/rs6000.h (EXTRA_SPECS): Add cc1_cpu. (EXTRA_SPEC_FUNCTIONS): Define. (HAVE_LOCAL_CPU_DETECT): Define. (CC1_CPU_SPEC): Define. * config/rs6000/driver-rs6000.c: New file. * config/rs6000/aix.h (CC1_SPEC): Define. * config/rs6000/sysv4.h (CC1_SPEC): Add cc1_cpu. * config.host: Add x-rs6000 to host_xmake_file if host and target are rs6000 or powerpc. /home/victork/mainline/build.127330/./prev-gcc/xgcc -B/home/victork/mainline/build.127330/./prev-gcc/ -B/home/victork/mainline/usr.127330/powerpc64-unknown-linux-gnu/bin/ -c -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common -DHAVE_CONFIG_H -I. -I. -I../../gcc/gcc -I../../gcc/gcc/. -I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include -I../../gcc/gcc/../libdecnumber -I../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber-I. -I. -I../../gcc/gcc -I../../gcc/gcc/. -I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include -I../../gcc/gcc/../libdecnumber -I../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber ../../gcc/gcc/config/rs6000/driver-rs6000.c cc1: warnings being treated as errors ../../gcc/gcc/config/rs6000/driver-rs6000.c: In function 'elf_platform': ../../gcc/gcc/config/rs6000/driver-rs6000.c:153: error: cast to pointer from integer of different size /home/victork/mainline/build.127330/./prev-gcc/xgcc -B/home/victork/mainline/build.127330/./prev-gcc/ -B/home/victork/mainline/usr.127330/powerpc64-unknown-linux-gnu/bin/ -c -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common -DHAVE_CONFIG_H -I. -I. -I../../gcc/gcc -I../../gcc/gcc/. -I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include -I../../gcc/gcc/../libdecnumber -I../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber ../../gcc/gcc/cppspec.c -o cppspec.o make[3]: *** [driver-rs6000.o] Error 1 make[3]: *** Waiting for unfinished jobs rm fsf-funding.pod gcov.pod gfdl.pod gpl.pod cpp.pod gfortran.pod gcc.pod make[3]: Leaving directory `/home/victork/mainline/build.127330/gcc' make[2]: *** [all-stage2-gcc] Error 2 make[2]: Leaving directory `/home/victork/mainline/build.127330' make[1]: *** [stage2-bubble] Error 2 make[1]: Leaving directory `/home/victork/mainline/build.127330' make: *** [bootstrap] Error 2 -- Summary: Bootstrap failure on ppc64 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: victork at il dot ibm dot com GCC build triplet: powerpc64-unknown-linux-gnu GCC host triplet: powerpc64-unknown-linux-gnu GCC target triplet: powerpc64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33042
[Bug fortran/32933] ICE in simplify_subreg with -fdefault-integer-8
--- Comment #9 from fxcoudert at gcc dot gnu dot org 2007-08-10 10:31 --- (In reply to comment #2) > But there is, internally with __builtin_isnan. And that's where I got it wrong. In the Fortran front-end, boolean_type_node is an integer of the default logical kind, while I thought it was coming from the middle-end (as an int) and hence did not depend on Fortran kinds. I'm testing patches for both this and bounds_check_5.f90, by adding conversions at the right places. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2007-08-08 15:24:37 |2007-08-10 10:31:34 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32933
[Bug libfortran/32812] random_seed and date_and_time
--- Comment #5 from kargl at gcc dot gnu dot org 2007-08-10 20:47 --- (In reply to comment #4) > (In reply to comment #3) > > UGH. > > > > I'd rather document gfortran's behavior than add additional hacks > > into the compiler. > > Hum, I was of the same opinion at first. What somehow convinced me that it > might be worth the price is that the use of DATE_AND_TIME to initialize the > random seed is actually in the Metcalf book. There is a nice chance that it > will end up in most user codes. Ugh**2 :-) I loaned my copy of M&R to colleague and it never returned. I can't imagine that M&R did not add some qualifier to quality of seeds that one gets from DATE_AND_TIME. Your attempt to randomize the seeds really isn't all that good because there is such a limited amount of entropy in year, month, day, and hour. I have analyzed your algorthim closely enough, so what is the effect on someone who actually knows how to properly seed gfortran's PRNG. Are there any degenerate side effects? The person of c.l.f is simply doing a rather crappy test of randomness. See my replies. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32812
[Bug target/32963] ICE in failed_reload, could not find a spill register
--- Comment #4 from sje at cup dot hp dot com 2007-08-10 20:50 --- This bug is related to Jan Hubicka's caller-save changes. Applying my division code change to version 126878 results in working code, applying my division code to version 126879 results in compilation failures. The 126879 change is: 2007-07-24 Jan Hubicka <[EMAIL PROTECTED]> * caller-save.c: Include ggc.h, gt-caller-save.h (reg_save_code, reg_restore_code): Rename to ... (cached_reg_save_code, cached_reg_restore_code): ... those. (savepat, restpat, test_reg, test_mem, saveinsn, restinsn): New. (reg_save_code, reg_restore_code): New functions. (init_caller_save): Do not intialize reg_save_code/reg_restore_code tables. * Makeifle.in: (gt-caller-save.h): New. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32963
[Bug libfortran/32972] performance of pack/unpack
--- Comment #1 from tkoenig at gcc dot gnu dot org 2007-08-10 20:58 --- Hi FX, I just thought you'd like to be in the loop for this one. -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org AssignedTo|unassigned at gcc dot gnu |tkoenig at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-08-10 20:58:28 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32972
[Bug libfortran/32972] performance of pack/unpack
--- Comment #2 from tkoenig at gcc dot gnu dot org 2007-08-10 20:59 --- Created an attachment (id=14051) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14051&action=view) partial patch Partial patch (doesn't yet remove the conversion of logical(kind=1) and logical(kind=2) mask arguments). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32972
[Bug libffi/28313] libffi has not been ported to mips64-linux-gnu
--- Comment #5 from daney at gcc dot gnu dot org 2007-08-10 15:42 --- It should be working now. -- daney at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28313
[Bug libstdc++/33021] memory allocation error of std::string if -fvisibility=hidden and -D_GLIBCXX_DEBUG both active
--- Comment #4 from pcarlini at suse dot de 2007-08-10 15:15 --- Yes. -- pcarlini at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Known to work||4.2.0 4.2.1 4.3.0 Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33021
[Bug c++/17763] [4.0/4.1/4.2/4.3 Regression] Wrong context in error message for template parameter
--- Comment #18 from paolo at gcc dot gnu dot org 2007-08-10 14:58 --- Subject: Bug 17763 Author: paolo Date: Fri Aug 10 14:57:52 2007 New Revision: 127335 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127335 Log: /cp 2007-08-10 Paolo Carlini <[EMAIL PROTECTED]> PR c++/17763 * error.c (dump_expr): Consistently use the *_cxx_* variants of the pretty-print functions. /testsuite 2007-08-10 Paolo Carlini <[EMAIL PROTECTED]> PR c++/17763 * g++.dg/other/error16.C: New. Added: trunk/gcc/testsuite/g++.dg/other/error16.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/error.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17763
[Bug c++/17763] [4.0/4.1/4.2 Regression] Wrong context in error message for template parameter
--- Comment #20 from paolo at gcc dot gnu dot org 2007-08-10 18:05 --- Subject: Bug 17763 Author: paolo Date: Fri Aug 10 18:05:07 2007 New Revision: 127346 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127346 Log: /cp 2007-08-10 Paolo Carlini <[EMAIL PROTECTED]> PR c++/17763 * error.c (dump_expr): Consistently use the *_cxx_* variants of the pretty-print functions. /testsuite 2007-08-10 Paolo Carlini <[EMAIL PROTECTED]> PR c++/17763 * g++.dg/other/error16.C: New. Added: branches/gcc-4_1-branch/gcc/testsuite/g++.dg/other/error16.C Modified: branches/gcc-4_1-branch/gcc/cp/ChangeLog branches/gcc-4_1-branch/gcc/cp/error.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17763
[Bug c++/33041] g++ incorrectly resolves an identically named templated struct in a super class
--- Comment #2 from matthijs at bomhoff dot nl 2007-08-10 13:58 --- (In reply to comment #1) > I think this is really PR 11764. It could have the same cause I guess. I figured it might not be the same, as foo is not really identical to foo. (Even though the names are the same, the template arguments differ so it could never denote a c'tor of the same type in this case. Besides, I think this code should actually be accepted, as it is, but lead to a different behaviour than it currently does...) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33041
[Bug debug/33044] Local variables in C++ constructor not visible for debugging
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|critical|normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33044
[Bug debug/33044] Local variables in C++ constructor not visible for debugging
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-08-10 21:13 --- The mainline produces: .ascii "foofoo\0" # DW_AT_name .byte 0x1 # DW_AT_decl_file (t.cc) .byte 0x10# DW_AT_decl_line .long 0x282 # DW_AT_type .byte 0x5 # DW_AT_location .byte 0x3 # DW_OP_addr .long __ZZN1AC1EiiE6foofoo Which is correct. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33044
[Bug debug/33044] Local variables in C++ constructor not visible for debugging
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-08-10 21:15 --- 4.1.0 produces: .uleb128 0xd# (DIE (0x185) DW_TAG_variable) .ascii "foofoo\0" # DW_AT_name .byte 0x1 # DW_AT_decl_file .byte 0x10# DW_AT_decl_line .long 0x285 # DW_AT_type .byte 0x5 # DW_AT_location .byte 0x3 # DW_OP_addr .long _ZZN1AC1EiiE6foofoo So this was fixed in 4.1.0 and above as 4.0.0 does not produce the location. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33044
[Bug c++/33041] g++ incorrectly resolves an identically named templated struct in a super class
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-08-10 13:21 --- I think this is really PR 11764. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33041
[Bug fortran/32937] segfault with string and -fdefault-integer-8
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-08-10 12:34 --- The further I can reduce this is: $ cat u.f90 character(2) :: c(2) integer(kind=4) :: i c = "aa" call foo ((/(c(i), i = 1_4,2_4)/)) print *, c .eq. "aa" contains subroutine foo (c) character(*), dimension(:) :: c end subroutine foo end $ gfortran -m32 -fdefault-integer-8 u.f90 && ./a.out Segmentation fault The only place where integer default kind appears is the .eq. operator, which returns a logical of the default kind. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2007-08-08 15:26:23 |2007-08-10 12:34:34 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32937
[Bug c/11751] wrong evaluation order of an expression
--- Comment #78 from gjasny at web dot de 2007-08-10 12:02 --- *** Bug 33043 has been marked as a duplicate of this bug. *** -- gjasny at web dot de changed: What|Removed |Added CC||gjasny at web dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11751
[Bug libfortran/32812] random_seed and date_and_time
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2007-08-10 21:28 --- (In reply to comment #5) > Your attempt to randomize the seeds really isn't all that good because > there is such a limited amount of entropy in year, month, day, and hour. I do agree. There's no way I'm adding entropy just by a bijective function :) > I have analyzed your algorthim closely enough, so what is the effect > on someone who actually knows how to properly seed gfortran's PRNG. > Are there any degenerate side effects? There shouldn't be any side effect. What I'm doing is that I'm shuffling the bytes between user-provided and internal KISS seed so that the first bytes of the user seed end up distributed in both parts of the KISS seed (used for MSB and LSB of the final random numbers); same thing for the last bytes. In that way, whether the user seed has stronger first or last elements, it will not reflect on the quality of the MSB/LSB generated. So, since it's just shuffling bytes (and it's a bijective operation, of course), I don't think I'm messing with any of the properties of the generator. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2007-07-28 13:07:22 |2007-08-10 21:28:07 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32812
[Bug fortran/32933] ICE in simplify_subreg with -fdefault-integer-8
--- Comment #10 from fxcoudert at gcc dot gnu dot org 2007-08-10 13:21 --- Subject: Bug 32933 Author: fxcoudert Date: Fri Aug 10 13:20:46 2007 New Revision: 127334 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127334 Log: PR fortran/32933 * trans-decl.c (gfc_build_builtin_function_decls): Change prototype for associated. * trans-intrinsic.c (gfc_conv_intrinsic_minmax): Convert the result of __builtin_isnan into a boolean. (gfc_conv_intrinsic_strcmp): Cleanup. (gfc_conv_associated): Convert the result of the associated function into a boolean. * intrinsics/associated.c: Change return type of associated into a C int. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-decl.c trunk/gcc/fortran/trans-intrinsic.c trunk/libgfortran/ChangeLog trunk/libgfortran/intrinsics/associated.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32933
[Bug fortran/31270] print subscript value and array bounds when out-of-bounds error occurs
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-08-10 22:12 --- Subject: Bug 31270 Author: fxcoudert Date: Fri Aug 10 22:12:04 2007 New Revision: 127352 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127352 Log: PR fortran/31270 * trans.c (gfc_trans_runtime_check): Reorder arguments and add extra variable arguments. Hand them to the library function. * trans.h (gfc_trans_runtime_check): Update prototype. * trans-array.c (gfc_trans_array_bound_check): Issue more detailled error messages. (gfc_conv_array_ref): Likewise. (gfc_conv_ss_startstride): Likewise. (gfc_trans_dummy_array_bias): Reorder arguments to gfc_trans_runtime_check. * trans-expr.c (gfc_conv_substring): Issue more detailled error messages. (gfc_conv_function_call): Reorder arguments to gfc_trans_runtime_check. * trans-stmt.c (gfc_trans_goto): Likewise. * trans-io.c (set_string): Reorder arguments to gfc_trans_runtime_check and issue a more detailled error message. * trans-decl.c (gfc_build_builtin_function_decls): Make runtime_error and runtime_error_at handle a variable number of arguments. * trans-intrinsic.c (gfc_conv_intrinsic_bound): Reorder arguments to gfc_trans_runtime_check. (gfc_conv_intrinsic_minmax): Likewise. (gfc_conv_intrinsic_repeat): Issue more detailled error messages. * runtime/error.c (runtime_error_at): Add a variable number of arguments. * libgfortran.h (runtime_error_at): Update prototype. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-array.c trunk/gcc/fortran/trans-decl.c trunk/gcc/fortran/trans-expr.c trunk/gcc/fortran/trans-intrinsic.c trunk/gcc/fortran/trans-io.c trunk/gcc/fortran/trans-stmt.c trunk/gcc/fortran/trans.c trunk/gcc/fortran/trans.h trunk/libgfortran/ChangeLog trunk/libgfortran/libgfortran.h trunk/libgfortran/runtime/error.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31270
[Bug fortran/31270] print subscript value and array bounds when out-of-bounds error occurs
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2007-08-10 22:12 --- Fixed. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31270
[Bug c++/33045] New: [c++0x] Incorrect decltype result for function calls.
Given: int && f (); template struct incomplete; incomplete i; GCC says (when invoked with -std=c++0x): "'incomplete i' has incomplete type" However, the latest standard draft (n2369) states in section 7.1.6.2 paragraph 4: "if e is a function call [...], decltype(e) is the return type of that function". So the error should've been: 'incomplete i' has incomplete type. -- Summary: [c++0x] Incorrect decltype result for function calls. Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: gcc-bugzilla at contacts dot eelis dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33045
