[Bug c/32175] New: Condition check for const char string fails
Ive been working on a c program that does the error
condition check in the beginning as follows,
char *fun(str)
const char *str;
{
if (str == NULL) <-- Error check, taking the const char variable directly.
printf("Null string \n");
..
}
But the code fails to perform the error checking
when a NULL string is passed and gives a segmentation
fault.
Did anyone face a similar problem. Please provide me some
information regarding this problem.
--
Summary: Condition check for const char string fails
Product: gcc
Version: 3.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kmanjunat at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32175
[Bug rtl-optimization/26449] [4.2/4.3 Regression] ICE in loop invariant motion
--- Comment #12 from ubizjak at gmail dot com 2007-06-01 06:42 --- *** Bug 32123 has been marked as a duplicate of this bug. *** -- ubizjak at gmail dot com changed: What|Removed |Added CC||ubizjak at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26449
[Bug rtl-optimization/32123] gcc.target/i386/sse2-vec-6.c fails for -mtune=k8
--- Comment #2 from ubizjak at gmail dot com 2007-06-01 06:42 --- *** This bug has been marked as a duplicate of 26449 *** -- ubizjak at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32123
[Bug rtl-optimization/26449] [4.2/4.3 Regression] ICE in loop invariant motion
--- Comment #11 from ubizjak at gmail dot com 2007-06-01 06:42 ---
New test (from PR32123):
Standalone testcase, compile with -O2 -msse2 -mtune=k8:
--cut here--
typedef short __v8hi __attribute__ ((__vector_size__ (16)));
typedef long long __m128i __attribute__ ((__vector_size__ (16)));
void sse2_test (void)
{
union
{
__m128i x;
} val1, res[8], tmp;
short ins[8] = { 8, 5, 9, 4, 2, 6, 1, 20 };
int i;
for (i = 0; i < 8; i++)
{
tmp.x = val1.x;
if (memcmp (&tmp, &res[i], sizeof (tmp)))
(__m128i) __builtin_ia32_vec_set_v8hi ((__v8hi) val1.x, ins[i], 0);
}
}
--cut here--
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26449
[Bug rtl-optimization/26449] [4.2/4.3 Regression] ICE in loop invariant motion
--- Comment #10 from ubizjak at gmail dot com 2007-06-01 06:39 ---
Not fixed, please look for the same failure at PR32123.
start_sequence ();
op = force_operand (SET_SRC (set), reg);
+ if (!op)
+ {
+ end_sequence ();
+ goto fail;
+ }
if (op != reg)
Also, this fix is wrong, force opereand will not return NULL, but will ICE if
value can't be expanded via optab.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED |
Summary|[4.2 Regression] ICE with - |[4.2/4.3 Regression] ICE in
|march=pentium4 -ftree- |loop invariant motion
|vectorize in matmul_i4.c in |
|loop invariant motion |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26449
[Bug other/32172] Behavior of -ffast-math
--- Comment #5 from eres at il dot ibm dot com 2007-06-01 06:24 --- (In reply to comment #3) > > *** This bug has been marked as a duplicate of 28684 *** > Related, but a different issue. I Agree. Bug 28684 mainly deals with the need to redefine -funsafe-math-optimizations as IEEE compliant (which is still under discussions) so I also think it is not the same problem. > My understanding of the Fortran standard (7.1.8.3) is that reordering is > allowed: 'a+b+c' can be computed as '(a+c)+b' (note 7.18), even if it is > usually computed as '(a+b)+c', but "7.1.8.2 Integrity of parentheses" forbids > to compute '(a+f)-f' as 'a'. GCC has all or nothing policy for applying reordering optimization. It currently does not have the ability to obey parenthesis in only parts of the program as permitted in Fortran. This is a separate problem I am looking at. For example; in programs like glibc that contains parts which could benefit from re-ordering this flag can not be used as reordering the rounding expression (a+TWO52)-TWO52 --> a will result an error. As for this bug - I will try to update -funsafe-math-optimizations flag according to your suggestion in (4). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32172
[Bug c/32174] New: Condition check for const char string fails
Ive been working on a c program that does the error
condition check in the beginning as follows,
char *fun(str)
const char *str;
{
if (str == NULL) <-- Error check, taking the const char variable directly.
printf("Null string \n");
..
}
But the code fails to perform the error checking
when a NULL string is passed and gives a segmentation
fault.
Did anyone face a similar problem. Please provide me some
information regarding this problem.
--
Summary: Condition check for const char string fails
Product: gcc
Version: 3.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kmanjunat at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32174
[Bug fortran/32049] Support on x86_64 also kind=16
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2007-06-01 04:06 --- It seems then the first step is to support both real 10 and real 16 simultaneously if available. Then implement the soft library for real 16 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32049
[Bug fortran/32049] Support on x86_64 also kind=16
--- Comment #4 from kargl at gcc dot gnu dot org 2007-06-01 02:52 --- (In reply to comment #3) > > What about rolling our own with mpfr? Or is that too difficult. :) > It could be done with mpfr, but note that at the moment gfortran will provide either REAL(10) or REAL(16). This has to do with mapping Fortran types to equivalent C long double. If you really want to get interesting, GCC has libdecnumber. We could offer a base 10 REAL(X) where X is 42. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32049
[Bug tree-optimization/32167] [pointer_plus] Ice in compare_values_warnv, at tree-vrp.c:760
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-06-01 02:20 --- Fixed. Thanks for these reports. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32167
[Bug tree-optimization/32167] [pointer_plus] Ice in compare_values_warnv, at tree-vrp.c:760
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-06-01 02:19 --- Subject: Bug 32167 Author: pinskia Date: Fri Jun 1 02:19:29 2007 New Revision: 125256 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125256 Log: 2007-05-31 Andrew Pinski <[EMAIL PROTECTED]> * gcc.c-torture/compile/20070531-1.c: New test. PR tree-opt/32167 * gcc.c-torture/compile/20070531-2.c: New test. 2007-05-31 Andrew Pinski <[EMAIL PROTECTED]> * tree-vrp.c (extract_range_from_binary_expr): Handle MIN_EXPR/MAX_EXPR for pointers type. PR tree-opt/32167 * tree-chrec.c (chrec_fold_plus): When either operand is zero, convert the other operand. Added: branches/pointer_plus/gcc/testsuite/gcc.c-torture/compile/20070531-1.c branches/pointer_plus/gcc/testsuite/gcc.c-torture/compile/20070531-2.c Modified: branches/pointer_plus/gcc/ChangeLog.ptr branches/pointer_plus/gcc/testsuite/ChangeLog.ptr branches/pointer_plus/gcc/tree-chrec.c branches/pointer_plus/gcc/tree-vrp.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32167
[Bug other/32154] sim-crt0.o/crt0.o isn't found during configure due to missing -L or -B
--- Comment #5 from dj at redhat dot com 2007-06-01 01:08 --- m32c still needs -L$$r/$(TARGET_SUBDIR)/libgloss/m32c to find r8c.ld in the build directory. Your patch would only search in the source directory. Be careful with -B vs -L, and $$r vs $$s. You've also removed the special flags needed for a mep build. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32154
[Bug fortran/32049] Support on x86_64 also kind=16
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2007-06-01 00:53 --- FX, this library might do the trick. I have x86-64 machine here to help on this. What about rolling our own with mpfr? Or is that too difficult. :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32049
[Bug target/32163] Compiling with stack protector causes reigster spill failure
--- Comment #4 from kkojima at gcc dot gnu dot org 2007-06-01 00:17 --- In the faulty case, stack protector inserts PIC codes after the result is set to R0 register. It looks like rX = [EMAIL PROTECTED] A = rX + r12 B = mem[A] and combine optimization pass makes this turn into rX = [EMAIL PROTECTED] B = mem[rX + r12] Unfortunately, the last insn requires R0 which is already used and we see the famous R0 spill failure. We didn't get this error on SH4 with -O2 because the first insn scheduling and other optimizations move the insn which set the result to R0 after these protector codes. But it looks to be fragile even on SH4 -O2. I'm testing the patch below on the trunk. * config/sh/sh.md (symGOT_load): Don't schedule insns when the symbol is generated with the stack protector. --- ORIG/trunk/gcc/config/sh/sh.md 2007-04-27 21:30:47.0 +0900 +++ LOCAL/trunk/gcc/config/sh/sh.md 2007-06-01 08:21:18.0 +0900 @@ -8502,6 +8502,20 @@ label: operands[2], gen_rtx_REG (Pmode, PIC_REG))); + /* When stack protector inserts codes after the result is set to + R0, @(rX, r12) will cause a spill failure for R0. Don't schedule + insns to avoid combining (set A (plus rX r12)) and (set op0 (mem A)) + when rX is a GOT address for the guard symbol. Ugly but doesn't + matter because this is a rare situation. */ + if (!TARGET_SHMEDIA + && flag_stack_protect + && GET_CODE (operands[1]) == CONST + && GET_CODE (XEXP (operands[1], 0)) == UNSPEC + && GET_CODE (XVECEXP (XEXP (operands[1], 0), 0, 0)) == SYMBOL_REF + && strcmp (XSTR (XVECEXP (XEXP (operands[1], 0), 0, 0), 0), +\"__stack_chk_guard\") == 0) +emit_insn (gen_blockage ()); + /* N.B. This is not constant for a GOTPLT relocation. */ mem = gen_rtx_MEM (Pmode, operands[3]); MEM_NOTRAP_P (mem) = 1; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32163
[Bug libstdc++/31426] TR1 includes do not work with -std=c++0x
--- Comment #7 from paolo at gcc dot gnu dot org 2007-05-31 23:38 --- Subject: Bug 31426 Author: paolo Date: Thu May 31 23:37:56 2007 New Revision: 125244 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125244 Log: 2007-05-31 Paolo Carlini <[EMAIL PROTECTED]> PR libstdc++/31426 * include/bits/c++config: Remove namespace association bits from tr1 to std. * include/ext/type_traits.h (__promote, __promote2, __promote3, __promote4): Add. * include/bits/hashtable.h: New. * include/bits/functional_hash.h: Likewise. * include/tr1/hashtable.h: Likewise. * include/tr1_impl/random: New. * include/tr1_impl/cinttypes: Likewise. * include/tr1_impl/cstdlib: Likewise. * include/tr1_impl/unordered_map: Likewise. * include/tr1_impl/cstdio: Likewise. * include/tr1_impl/boost_shared_ptr.h: Likewise. * include/tr1_impl/cctype: Likewise. * include/tr1_impl/random.tcc: Likewise. * include/tr1_impl/tuple: Likewise. * include/tr1_impl/functional_hash.h: Likewise. * include/tr1_impl/hashtable: Likewise. * include/tr1_impl/cmath: Likewise. * include/tr1_impl/type_traitsfwd.h: Likewise. * include/tr1_impl/hashtable_policy.h: Likewise. * include/tr1_impl/cfenv: Likewise. * include/tr1_impl/unordered_set: Likewise. * include/tr1_impl/functional: Likewise. * include/tr1_impl/utility: Likewise. * include/tr1_impl/complex: Likewise. * include/tr1_impl/type_traits: Likewise. * include/tr1_impl/cwchar: Likewise. * include/tr1_impl/cstdint: Likewise. * include/tr1_impl/regex: Likewise. * include/tr1_impl/array: Likewise. * include/tr1_impl/cwctype: Likewise. * include/tr1/type_traitsfwd.h: Remove. * include/tr1/boost_shared_ptr.h: Likewise. * include/tr1/common.h: Likewise. * include/tr1/hashtable: Likewise. * include/tr1/hashtable_policy.h: Likewise. * include/tr1/random.tcc: Likewise. * include/c_global/cinttypes: Include tr1_impl/cinttypes. * include/c_global/cstdlib: Likewise for cstdlib. * include/c_global/cstdio: Likewise for cstdio. * include/c_global/cctype: Likewise for cctype. * include/c_global/cmath: Likewise for cmath. * include/c_global/cfenv: Likewise for cfenv. * include/c_global/cwchar: Likewise for cwchar. * include/c_global/cstdint: Likewise for cstdint. * include/c_global/cwctype: Likewise for cwctype. * include/tr1/cinttypes: Likewise for cinttypes. * include/tr1/cstdlib: Likewise for cstdlib. * include/tr1/cstdio: Likewise for cstdio. * include/tr1/cctype: Likewise for cctype. * include/tr1/cmath: Likewise for cmath. * include/tr1/cfenv: Likewise for cfenv. * include/tr1/cwchar: Likewise for cwchar. * include/tr1/cstdint: Likewise for cstdint. * include/tr1/cwctype: Likewise for cwctype. * include/tr1/functional_hash.h: Likewise for functional_hash. * include/std/tuple: Include tr1_impl/tuple. * include/std/utility: Likewise for utility. * include/std/type_traits: Likewise for type_traits. (is_pod): Just forward to __is_pod. (has_trivial_default_constructor): Just forward to __has_trivial_constructor. (has_trivial_copy_constructor): Just forward to __has_trivial_copy. (has_trivial_assign): Just forward to __has_trivial_assign. (has_trivial_destructor): Just forward to __has_trivial_destructor. (has_nothrow_default_constructor): Just forward to __has_nothrow_constructor. (has_nothrow_copy_constructor): Just forward to __has_nothrow_copy. (has_nothrow_assign): Just forward to __has_nothrow_assign. (is_base_of): Just forward to __is_base_of. (is_signed, is_unsigned): Implement according to the C++0x specifications. * include/std/memory: Likewise for memory. * include/std/regex: Likewise for regex. * include/std/random: Likewise for random. * include/std/unordered_map: Likewise for unordered_map. * include/std/unordered_set: Likewise for unordered_set. * include/std/functional: Likewise for functional. * include/std/complex: Likewise for complex. * include/std/array: Likewise for array. * include/tr1/tuple: Likewise for tuple. * include/tr1/utility: Likewise for utility. * include/tr1/type_traits: Likewise for type_traits * include/tr1/memory: Likewise for memory. * include/tr1/regex: Likewise for regex. * include/tr1/random: Likewise for random. * include/tr1/unordered_map: Likewise for unordered_map. * include/tr1/unordered_set: Likewise for unordered_set. * include/tr1/functiona
[Bug tree-optimization/32167] [pointer_plus] Ice in compare_values_warnv, at tree-vrp.c:760
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-05-31 22:43 --- Simple fix: Index: tree-chrec.c === --- tree-chrec.c(revision 125239) +++ tree-chrec.c(working copy) @@ -344,9 +344,9 @@ chrec_fold_plus (tree type, return chrec_fold_automatically_generated_operands (op0, op1); if (integer_zerop (op0)) -return op1; +return chrec_convert (type, op1, NULL_TREE); if (integer_zerop (op1)) -return op0; +return chrec_convert (type, op0, NULL_TREE); if (POINTER_TYPE_P (type)) code = POINTER_PLUS_EXPR; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32167
[Bug other/32154] sim-crt0.o/crt0.o isn't found during configure due to missing -L or -B
--- Comment #4 from rask at sygehus dot dk 2007-05-31 22:37 --- Created an attachment (id=13642) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13642&action=view) Patch v2 to add -L and -B as necessary I believe I have covered boths cases of linker script placement. The comments ended up a lot farther away from the lines they were supposed to comment than intended. The attached patch fixes a few things that I didn't get right in my first attempt. -- rask at sygehus dot dk changed: What|Removed |Added Attachment #13641|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32154
[Bug ada/16525] Ada ICE Assert_Failure einfo.adb:435
--- Comment #4 from laurent at guerby dot net 2007-05-31 21:45 --- ICE everywhere including trunk. +===GNAT BUG DETECTED==+ | 3.4.6 (i686-pc-linux-gnu) Assert_Failure einfo.adb:459 | | Error detected at dm-tools.adb:4:16 | +===GNAT BUG DETECTED==+ | 4.2.0 (i686-pc-linux-gnu) Assert_Failure einfo.adb:551 | | Error detected at dm-tools.adb:4:16 | +===GNAT BUG DETECTED==+ | 4.3.0 20070511 (experimental) (x86_64-unknown-linux-gnu) Assert_Failure einfo.adb:550| | Error detected at dm-tools.adb:4:16 | -- laurent at guerby dot net changed: What|Removed |Added Known to fail||3.3.4 3.4.6 4.0.0 4.1.1 ||4.2.0 Summary|3.3.4 (i486-slackware-linux-|Ada ICE Assert_Failure |gnu) Assert_Failure |einfo.adb:435 |einfo.adb:435 | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16525
[Bug fortran/32049] Support on x86_64 also kind=16
--- Comment #2 from ubizjak at gmail dot com 2007-05-31 21:44 --- (In reply to comment #1) > To have decent support for __float128 in gfortran, we need to provide a > __float128 math library. Do you happen to know any? http://sourceware.org/cgi-bin/cvsweb.cgi/libc/sysdeps/ieee754/?cvsroot=glibc Look into ldbl-128 directory... BTW: What exactly is incomplete with software fp? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32049
[Bug other/32172] Behavior of -ffast-math
--- Comment #4 from dominiq at lps dot ens dot fr 2007-05-31 21:34 --- > Note we do expand anint in this optimal way already (for x86 and SSE math). I forgot to mention PPC (see comment #3) for which the implementation of anint(x) and friends (mod(x), modulo(x)) are quite bad compared to xlf. > Note that we don't have infrastructure to obey paranthesis > but only to not do re-association at all. I am not sure to understand what you mean. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32172
[Bug other/32172] Behavior of -ffast-math
--- Comment #3 from dominiq at lps dot ens dot fr 2007-05-31 21:31 --- > This behavior with -ffast-math is expected and is hoped for. Yes indeed: I said I would like to see it at some level of -On. > That is PR 323. If I understood correctly the PR, it deals with side effects to do the extra precision in x87. I have done the tests on a PPC (sorry for not mentionning it). In the later case it is due to the fact that a/b may have a different round-off error as a*(1.0/b). > *** This bug has been marked as a duplicate of 28684 *** Related, but a different issue. My understanding of the Fortran standard (7.1.8.3) is that reordering is allowed: 'a+b+c' can be computed as '(a+c)+b' (note 7.18), even if it is usually computed as '(a+b)+c', but "7.1.8.2 Integrity of parentheses" forbids to compute '(a+f)-f' as 'a'. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32172
[Bug target/31938] Wrong code on int to short cast on armeb
--- Comment #2 from bigfoot at private dot dk 2007-05-31 21:22 ---
(In reply to comment #1)
> However, I suspect your test case is wrong. Unpatched versions of gcc default
> to little-endian mode on arm, even if you configure with
> --target=arm${foo}b-${bar}.
> Since you didn't pass -mbig-endian when compiling the test case, gcc will
> generate code assuming little-endian data representation. The assembly code
> you
> listed is actually correct for little-endian.
Yes, indeed it is correct for little endian, so I assumed it was some
optimisation wrongly applied to big endian. However, you're entirely right.
Using -mbig-endian makes it produce code that looks more correct.
What I'm asking myself now is what sense there is to this default. Shouldn't it
default to big endian?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31938
[Bug other/32172] Behavior of -ffast-math
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-05-31 21:18 --- Note we do expand anint in this optimal way already (for x86 and SSE math). Note that we don't have infrastructure to obey paranthesis but only to not do re-association at all. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32172
[Bug c++/27078] [4.1/4.2/4.3 Regression] Duplicate error message for ambiguous enum
--- Comment #4 from aaw at gcc dot gnu dot org 2007-05-31 21:18 --- I've got a fix to this as part of my using directive / using declaration cleanup. I'll disentangle this from the rest of my changes and submit a patch soonish. -- aaw at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|shinwell at gcc dot gnu dot |aaw at gcc dot gnu dot org |org | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27078
[Bug fortran/32148] FAIL: gfortran.dg/sizeof.f90 -O0 (internal compiler error)
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-05-31 21:15 --- So, I believe this is fixed by r125242. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32148
[Bug fortran/32156] [4.3 Regression] ICE with characters
--- Comment #7 from pault at gcc dot gnu dot org 2007-05-31 21:13 --- Fixed as 'obvious'. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32156
[Bug fortran/32156] [4.3 Regression] ICE with characters
--- Comment #6 from pault at gcc dot gnu dot org 2007-05-31 21:12 --- Subject: Bug 32156 Author: pault Date: Thu May 31 21:12:10 2007 New Revision: 125241 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125241 Log: 2007-05-31 Paul Thomas <[EMAIL PROTECTED]> PR fortran/32156 * trans-array.c (gfc_trans_array_constructor): Treat the case where the ss expression charlen is missing. 2007-05-31 Paul Thomas <[EMAIL PROTECTED]> PR fortran/32156 * gfortran.dg/char_array_constructor_3.f90: New test. Modified: trunk/gcc/fortran/trans-array.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32156
[Bug fortran/32156] [4.3 Regression] ICE with characters
--- Comment #5 from pault at gcc dot gnu dot org 2007-05-31 21:11 --- Subject: Bug 32156 Author: pault Date: Thu May 31 21:11:31 2007 New Revision: 125240 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125240 Log: 2007-05-31 Paul Thomas <[EMAIL PROTECTED]> PR fortran/32156 * trans-array.c (gfc_trans_array_constructor): Treat the case where the ss expression charlen is missing. 2007-05-31 Paul Thomas <[EMAIL PROTECTED]> PR fortran/32156 * gfortran.dg/char_array_constructor_3.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/char_array_constructor_3.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32156
[Bug other/32154] sim-crt0.o/crt0.o isn't found during configure due to missing -L or -B
--- Comment #3 from dj at redhat dot com 2007-05-31 21:09 --- Subject: Re: sim-crt0.o/crt0.o isn't found during configure due to missing -L or -B Note that m32c puts *.ld files in the *build* directory, not the *source* directory, unlike most targets. The m32c source directory only has templates. Also, please keep the comments around. You're deleting them from the m32c case, but not adding equivalent ones in the generic case. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32154
[Bug fortran/32148] FAIL: gfortran.dg/sizeof.f90 -O0 (internal compiler error)
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-05-31 21:08 --- sizeof has wrong types. might be fixed by one of my pending patches (I don't see this failure). -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32148
[Bug fortran/32148] FAIL: gfortran.dg/sizeof.f90 -O0 (internal compiler error)
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-05-31 21:05 --- *** Bug 32173 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pault at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32148
[Bug fortran/32173] sizeof.f90 fails on x86_ia64
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-05-31 21:05 --- *** This bug has been marked as a duplicate of 32148 *** *** This bug has been marked as a duplicate of 32148 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Keywords|ice-on-valid-code | Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32173
[Bug fortran/32173] New: sizeof.f90 fails on x86_ia64
On x86_ia64/fc5 [EMAIL PROTECTED] prs]# /svn-4.3/bin/gfortran $test/sizeof.f90 /svn/trunk/gcc/testsuite/gfortran.dg/sizeof.f90: In function check_int: /svn/trunk/gcc/testsuite/gfortran.dg/sizeof.f90:3: internal compiler error: in copy_to_mode_reg, at explow.c:645 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. Note that this program is OK with -O1 and higher:) Coo! I never saw that before Paul -- Summary: sizeof.f90 fails on x86_ia64 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pault at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32173
[Bug other/32154] sim-crt0.o/crt0.o isn't found during configure due to missing -L or -B
--- Comment #2 from rask at sygehus dot dk 2007-05-31 21:01 --- Created an attachment (id=13641) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13641&action=view) Patch to add -L and -B as necessary This happens on all targets except m32c-*-*. I'm testing the attached patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32154
[Bug other/32172] Behavior of -ffast-math
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-05-31 20:55 --- This behavior with -ffast-math is expected and is hoped for. >'a' and 'b' are not equal, but differ only by the round-off error. That is PR 323. *** This bug has been marked as a duplicate of 28684 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32172
[Bug middle-end/28684] Imprecise -funsafe-math-optimizations definition
--- Comment #10 from pinskia at gcc dot gnu dot org 2007-05-31 20:55 --- *** Bug 32172 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||dominiq at lps dot ens dot ||fr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28684
[Bug fortran/31608] wrong types in character array/scalar binop
--- Comment #12 from pault at gcc dot gnu dot org 2007-05-31 20:40 --- I am not at all convinced that this is the fault of gfc_trans_array_transfer. It is quite correctly producing &(*(char[0:][1:1] as the output type. The problem is the comaprison between an array of character(1)'s and the scalar character. Some sorting out is needed in the binary operator that has a character array on one side and a character scalar on the other. I have changed the title to reflect this but this does not mean that I will ignore it. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Summary|wrong types in array|wrong types in character |transfer|array/scalar binop http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31608
[Bug ada/32164] [4.1/4.2 Regression] Ada ICE when renaming predefined "=" and "/="
--- Comment #3 from laurent at guerby dot net 2007-05-31 20:39 --- And still present on trunk from a few weeks ago: +===GNAT BUG DETECTED==+ | 4.3.0 20070511 (experimental) (x86_64-unknown-linux-gnu) Assert_Failure einfo.adb:852| | Error detected at pak1.ads:4:43 | -- laurent at guerby dot net changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-05-31 20:39:36 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32164
[Bug other/32172] New: Behavior of -ffast-math
In http://gcc.gnu.org/ml/gcc-patches/2007-05/msg01931.html Andrew Pinski wrote: > On 5/28/07, Dominique Dhumieres <[EMAIL PROTECTED]> wrote: > > So if I am not mistaken, -ffast-math does not obey the parentheses. > > If you consider this is a bug, I'll fill a bug report. > > -ffast-math enables -funsafe-math-optimizations which tells the > compiler to ignore those rules (and reassiocate all it can). So no > this is not a bug. This is by design. In my opinion, this is a very bad design. Take the following code: real :: f1, f2 print *, f1(1.2), f2(1.2) print *, f1(nearest(1.5,-1.0)), f2(nearest(1.5,-1.0)) print *, f1(1.5), f2(1.5), anint(1.5) print *, f1(nearest(1.5,1.0)), f2(nearest(1.5,1.0)) print *, f1(1.7), f2(1.7) end real function f1(a) real, parameter :: f = 2.0**23 real :: a f1 = (f+a)-f end real function f2(a) real, parameter :: f = 2.0**23 real :: a f2 = (a+f)-f end As you can try, f1(a) and f2(a) return anint(a) in a much faster way (I borrowed the trick from xlf!-). -funsafe-math-optimizations prevents me to use it with other "unsafe-math-optimizations" (see below why this can be bad). For me one of the following actions should be taken (ranked according my preference): (1) This feature should be deleted, though I have no illusion! As a lazy programmer when I put parentheses I have good reasons (see the above code) and want the parentheses obeyed as it is mandatory in Fortran. To bad if it does not give a good timing on some stupid benchmark designed to test this kind of pseudo-optimisation. (2) Remove the feature from -funsafe-math-optimizations and add a new option -fdont-obey-parentheses (anything like that) being not part of -ffast-math. (3) Emit a warning when the parentheses are not obeyed. (4) At least, document (in flashing bold-face red) the (mis)feature: The gcc manual says: > -funsafe-math-optimizations > > Allow optimizations for floating-point arithmetic that (a) assume > that arguments and results are valid and (b) may violate IEEE or ANSI > standards. When used at link-time, it may include libraries or > startup files that change the default FPU control word or other > similar optimizations. > > This option is not turned on by any -O option since it can result in > incorrect output for programs which depend on an exact implementation > of IEEE or ISO rules/specifications for math functions. It may, > however, yield faster code for programs that do not require the > guarantees of these specifications. > > The default is -fno-unsafe-math-optimizations. As far as I can read English, I do not see any mention of parentheses removal in this quotation. Note that (2), (3), and (4) are not incompatible, but in any case (4) is mandatory in my opinion if (1) is rejected. Now consider this other code: integer i, n real a, b n = 0 do i = 0, 999 a = 0.001*real(i) b = real(i)/1000.0 if ((a /= b) .and. (n == 0)) print *, a-b, spacing(a) if (a /= b) n = n + 1 end do print *, n end compiled with "-O", it yields: 4.6566129E-10 4.6566129E-10 584 'a' and 'b' are not equal, but differ only by the round-off error. Now compiled with "-O -funsafe-math-optimizations", it yields: 0 Though I did not look at the assembly code, I am pretty sure that the division by 1000.0 has been replaced by a multiplication by 1.0/1000.0 computed only once outside the loop. Since the division is a very costly operation this can give a significant speedup for some codes. In my opinion, this is a very useful optimization (should be included at some level of -O, say -O3) and pretty safe. Indeed one could argue that if I am really interested by this optimization, I can always do it by hand. My answer is that in general I use it in my codes, but sometime the code is easier to understand if the division is left where it belongs in the formulae and I don't see why I'd have to chase divisions when I use the code from a colleague. In addition if the argument is true for division, it is also for writing (a+f)-f if all what you want is a! To summarize I do not see the logic of the design of "-funsafe-math-optimizations": it mixes legitimate (and safe from a numerical point of view) optimization with illegitimate (in the sense that the code is no longer complying to the requirements of the programming language) ones. Final note (to document?): the division is optimized outside the loop with "-funsafe-math-optimizations", while the parentheses are not obeyed starting at "-O1 -funsafe-math-optimizations", but "-O0 -funsafe-math-optimizations" obeys the parentheses. -- Summary: Behavior of -ffast-math Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dominiq at lps dot ens dot fr http:
[Bug ada/32164] [4.1/4.2 Regression] Ada ICE when renaming predefined "=" and "/="
--- Comment #2 from laurent at guerby dot net 2007-05-31 20:37 --- +===GNAT BUG DETECTED==+ | 4.2.0 (i686-pc-linux-gnu) Assert_Failure einfo.adb:853 | | Error detected at pak1.ads:4:43 | +===GNAT BUG DETECTED==+ | 4.1.2 (i686-pc-linux-gnu) Assert_Failure einfo.adb:846 | | Error detected at pak1.ads:4:43 | Compiles successfully with 3.4.6 and 4.0.4 so this is a regression. -- laurent at guerby dot net changed: What|Removed |Added CC||laurent at guerby dot net Known to fail||4.2.0 4.1.2 Known to work||3.4.6 4.0.4 Summary|Bug box, Assert_Failure at |[4.1/4.2 Regression] Ada ICE |einfo.adb:846, renaming |when renaming predefined "=" |predefined "=" and "/=" |and "/=" http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32164
[Bug target/26463] -O2, -O3, -Os segment fault due to bad array index on ARM
--- Comment #2 from mikpe at it dot uu dot se 2007-05-31 20:35 --- I cannot reproduce this bug with gcc-4.0.4, 4.1.2, or 4.2.0 on an armv5b-softvfp-linux machine. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26463
[Bug inline-asm/31693] Incorrectly assigned registers to operands for ARM inline asm
--- Comment #3 from mikpe at it dot uu dot se 2007-05-31 20:01 --- I can confirm this broken behaviour, including that it disappears if the 'c' variable is renamed to 'xxc', with gcc-3.3.6, 4.0.4, 4.1.2, and 4.2.0, all running natively on an armv5b-softvfp-linux machine. -- mikpe at it dot uu dot se changed: What|Removed |Added CC||mikpe at it dot uu dot se http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31693
[Bug target/31938] Wrong code on int to short cast on armeb
--- Comment #1 from mikpe at it dot uu dot se 2007-05-31 19:48 ---
I cannot reproduce this on an armv5b-softvfp-linux machine, with either
gcc-3.3.6, gcc-4.0.4, gcc-4.1.2, or gcc-4.2.0 (all bootstrapped natively on the
arm machine).
However, I suspect your test case is wrong. Unpatched versions of gcc default
to little-endian mode on arm, even if you configure with
--target=arm${foo}b-${bar}.
Since you didn't pass -mbig-endian when compiling the test case, gcc will
generate code assuming little-endian data representation. The assembly code you
listed is actually correct for little-endian.
--
mikpe at it dot uu dot se changed:
What|Removed |Added
CC||mikpe at it dot uu dot se
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31938
[Bug fortran/32170] string badly passed as function arguments
--- Comment #7 from dominiq at lps dot ens dot fr 2007-05-31 19:38 --- subroutine test(chars) character(len=*), dimension(2) :: chars write(6,*) chars end subroutine for the code in comment #2. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32170
[Bug fortran/32170] string badly passed as function arguments
--- Comment #6 from dominiq at lps dot ens dot fr 2007-05-31 19:34 --- In the code in comment #4, you should use: subroutine test(chars) character(len=*) :: chars write(6,*) chars end subroutine -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32170
[Bug fortran/32170] string badly passed as function arguments
--- Comment #5 from dominiq at lps dot ens dot fr 2007-05-31 19:33 --- Compiled with g95, the code in comment #3 gives In file pr32170_2.f90:10 call test( (/ "string1", "string2" /) ) In file pr32170_2.f90:16 subroutine test(chars) 2 Error: Passing array at (1) to assumed-shape actual argument at (2) via an implicit interface In file pr32170_2.f90:9 call test( str2 ) 1 In file pr32170_2.f90:16 subroutine test(chars) 2 Error: Passing array at (1) to assumed-shape actual argument at (2) via an implicit interface These errors explain why the code is invalid. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32170
[Bug fortran/32170] string badly passed as function arguments
--- Comment #4 from mikael dot morin at tele2 dot fr 2007-05-31 19:26
---
$ export FILE=test6
$ cat $FILE.f
program testchar
character(len=30) :: str2
write(str2,*) "string1"
call test( str2 )
call test("string2")
end program
subroutine test(chars)
character(len=30) :: chars
write(6,*) chars
end subroutine
$
Actually, I could have reported this case only, because it doesn't even use
string arrays. Both versions write junk on the terminal.
$ FC=gfortran
$ $FC -v;$FC -o $FILE $FILE.f ; echo; ./$FILE
Lecture des spécification à partir de
/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/specs
Target: x86_64-pc-linux-gnu
Configuré avec: /usr/src/gcc-4.1.2/configure --host=x86_64-pc-linux-gnu
--prefix=/usr --infodir=/usr/share/info --mandir=/usr/share/man
--enable-threads=posix --with-system-zlib --enable-languages=f95
--disable-multilib
Modèle de thread: posix
version gcc 4.1.2
string1
string2;0L}
$
$ export FC=/usr/local/bin/gfortran
$ $FC -v;$FC -o $FILE $FILE.f ; echo; ./$FILE
Utilisation des specs internes.
Target: x86_64-unknown-linux-gnu
Configuré avec: ../gcc-4.3-20070525/configure --enable-languages=fortran
--disable-multilib
Modèle de thread: posix
version gcc 4.3.0 20070525 (experimental)
string1
string2;4Pb
$
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32170
[Bug fortran/32170] string badly passed as function arguments
--- Comment #3 from mikael dot morin at tele2 dot fr 2007-05-31 19:18 --- $ export FILE=test3 $ cat $FILE.f program testchar character(len=30), dimension(2) :: str2 write(str2(1),*) "string1" write(str2(2),*) "string2" call test( str2 ) call test( (/ "string1", "string2" /) ) end program subroutine test(chars) character(len=30), dimension(:) :: chars write(6,*) chars end subroutine $ This case fails with gfortran 4.1.2 (segmentation fault) and does nothing with gfortran 4.3 $ export FC=gfortran $ $FC -v;$FC -o $FILE $FILE.f ; echo; ./$FILE Lecture des spécification à partir de /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/specs Target: x86_64-pc-linux-gnu Configuré avec: /usr/src/gcc-4.1.2/configure --host=x86_64-pc-linux-gnu --prefix=/usr --infodir=/usr/share/info --mandir=/usr/share/man --enable-threads=posix --with-system-zlib --enable-languages=f95 --disable-multilib Modèle de thread: posix version gcc 4.1.2 zsh: segmentation fault ./$FILE $ $ export FC=/usr/local/bin/gfortran $ $FC -v;$FC -o $FILE $FILE.f ; echo; ./$FILE Utilisation des specs internes. Target: x86_64-unknown-linux-gnu Configuré avec: ../gcc-4.3-20070525/configure --enable-languages=fortran --disable-multilib Modèle de thread: posix version gcc 4.3.0 20070525 (experimental) $ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32170
[Bug fortran/32170] string badly passed as function arguments
--- Comment #2 from mikael dot morin at tele2 dot fr 2007-05-31 19:04 --- $ export FILE=test2 $ cat $FILE.f program testchar character(len=30), dimension(2) :: str2 write(str2(1),*) "string1" write(str2(2),*) "string2" call test( str2 ) call test( (/ "string1", "string2" /) ) end program subroutine test(chars) character(len=30), dimension(2) :: chars write(6,*) chars end subroutine $ This case writes junk on the terminal $ export FC=gfortran $ $FC -v;$FC -o $FILE $FILE.f ; echo; ./$FILE Lecture des spécification à partir de /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/specs Target: x86_64-pc-linux-gnu Configuré avec: /usr/src/gcc-4.1.2/configure --host=x86_64-pc-linux-gnu --prefix=/usr --infodir=/usr/share/info --mandir=/usr/share/man --enable-threads=posix --with-system-zlib --enable-languages=f95 --disable-multilib Modèle de thread: posix version gcc 4.1.2 string1 string2 string1string2 @ @ L%Ö«* ^¤├Ö«* ◆îIÖ«* ¸â–Ô $ $ export FC=/usr/local/bin/gfortran [EMAIL PROTECTED] scol/ragsl/progs $ $FC -v;$FC -o $FILE $FILE.f ; echo; ./$FILE Utilisation des specs internes. Target: x86_64-unknown-linux-gnu Configuré avec: ../gcc-4.3-20070525/configure --enable-languages=fortran --disable-multilib Modèle de thread: posix version gcc 4.3.0 20070525 (experimental) string1 string2 string1string2� @� @`â�� l"+^ $ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32170
[Bug fortran/32170] string badly passed as function arguments
--- Comment #1 from mikael dot morin at tele2 dot fr 2007-05-31 19:00 --- $ export FILE=test $ cat $FILE.f program testchar character(len=30), dimension(2) :: str1, str2 str1 = (/ "string1", "string2" /) write(6,*) str1 write(str2(1),*) "string1" write(str2(2),*) "string2" write(6,*) str2 end program This is the working (reference case) Note the different spacing (I think it is the write function which is called twice in the second case). $ export FC=gfortran $ $FC -v;$FC -o $FILE $FILE.f ; echo; ./$FILE Lecture des spécification à partir de /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/specs Target: x86_64-pc-linux-gnu Configuré avec: /usr/src/gcc-4.1.2/configure --host=x86_64-pc-linux-gnu --prefix=/usr --infodir=/usr/share/info --mandir=/usr/share/man --enable-threads=posix --with-system-zlib --enable-languages=f95 --disable-multilib Modèle de thread: posix version gcc 4.1.2 string1 string2 string1 string2 $ export FC=/usr/local/bin/gfortran $ $FC -v;$FC -o $FILE $FILE.f ; echo; ./$FILE Utilisation des specs internes. Target: x86_64-unknown-linux-gnu Configuré avec: ../gcc-4.3-20070525/configure --enable-languages=fortran --disable-multilib Modèle de thread: posix version gcc 4.3.0 20070525 (experimental) string1 string2 string1 string2 -- mikael dot morin at tele2 dot fr changed: What|Removed |Added CC||mikael dot morin at tele2 ||dot fr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32170
[Bug c/32171] New: ICE w/ -ftree-loop-linear, gcc4.1 and 4.2
gcc segfaults on the code below (which is a simplified des.c from
nettle-1.15.tar.gz). '-ftree-loop-linear' seems to be the trigger,
at least -O1 is required too.
ICEs:
gcc version 4.2.1 20070531 (prerelease)
gcc version 4.1.3 20070519 (prerelease)
survives:
gcc version 4.0.4 20061113 (prerelease)
uname -a:
Linux node 2.6.21.1-g4ead5093 #29 PREEMPT Sun May 6 22:54:15 CEST 2007 i686
GNU/Linux
$ gcc -O1 -ftree-loop-linear -c des.c
des.c: In function 'f':
des.c:4: internal compiler error: Segmentation fault
where des.c is:
---
int f( char *p );
int f( char *p )
{
unsigned n, w;
char a[4];
n = 4;
do {
w = *p++;
do {
--n;
w >>= 1;
a[n] = w;
} while ( w >= 16 );
} while ( n );
return a[0];
}
---
--
Summary: ICE w/ -ftree-loop-linear, gcc4.1 and 4.2
Product: gcc
Version: 4.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bu dot gz dot 200-7 at src dot neostrada dot pl
GCC target triplet: i486-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32171
[Bug tree-optimization/32169] Ice in set_value_range, at tree-vrp.c:326
--- Comment #1 from mstein at phenix dot rootshell dot be 2007-05-31 18:59 --- Created an attachment (id=13640) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13640&action=view) from linux-2.6.20 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32169
[Bug fortran/32170] New: string badly passed as function arguments
-- Summary: string badly passed as function arguments Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mikael dot morin at tele2 dot fr GCC host triplet: x86_64-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32170
[Bug fortran/31867] [4.2 only] function result with character LEN computed at run time
--- Comment #14 from pault at gcc dot gnu dot org 2007-05-31 18:53 --- Fixed 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=31867
[Bug fortran/31540] [Regression 4.2 only] character((constant expression)) for external function
--- Comment #9 from pault at gcc dot gnu dot org 2007-05-31 18:52 --- Fixed 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=31540
[Bug fortran/31483] [4.1/4.2 only] ICE on fortran Code
--- Comment #8 from pault at gcc dot gnu dot org 2007-05-31 18:51 --- Fixed 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=31483
[Bug fortran/31483] [4.1/4.2 only] ICE on fortran Code
--- Comment #7 from pault at gcc dot gnu dot org 2007-05-31 18:51 --- Subject: Bug 31483 Author: pault Date: Thu May 31 18:50:56 2007 New Revision: 125235 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125235 Log: 2007-05-31 Paul Thomas <[EMAIL PROTECTED]> backport from trunk PR fortran/31483 * trans-expr.c (gfc_conv_function_call): Give a dummy procedure the correct type if it has alternate returns. PR fortran/31540 * resolve.c (resolve_fl_procedure): Resolve constant character lengths. PR fortran/31867 PR fortran/31994 * trans-array.c (gfc_conv_expr_descriptor): Obtain the stored offset for non-descriptor, source arrays and correct for stride not equal to one before writing to field of output descriptor. 2007-05-31 Paul Thomas <[EMAIL PROTECTED]> backport from trunk PR fortran/31483 * gfortran.dg/altreturn_5.f90: New test. PR fortran/31540 * gfortran.dg/char_result_5.f90: New test. PR fortran/31867 * gfortran.dg/char_length_5.f90: New test. PR fortran/31994 * gfortran.dg/array_reference_1.f90: New test. Added: branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/altreturn_5.f90 branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/array_reference_1.f90 branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/char_length_5.f90 branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/char_result_13.f90 Modified: branches/gcc-4_2-branch/gcc/fortran/ChangeLog branches/gcc-4_2-branch/gcc/fortran/resolve.c branches/gcc-4_2-branch/gcc/fortran/trans-array.c branches/gcc-4_2-branch/gcc/fortran/trans-expr.c branches/gcc-4_2-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31483
[Bug fortran/31994] conjg(transpose(a)) produces wrong answer.
--- Comment #11 from pault at gcc dot gnu dot org 2007-05-31 18:51 --- Subject: Bug 31994 Author: pault Date: Thu May 31 18:50:56 2007 New Revision: 125235 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125235 Log: 2007-05-31 Paul Thomas <[EMAIL PROTECTED]> backport from trunk PR fortran/31483 * trans-expr.c (gfc_conv_function_call): Give a dummy procedure the correct type if it has alternate returns. PR fortran/31540 * resolve.c (resolve_fl_procedure): Resolve constant character lengths. PR fortran/31867 PR fortran/31994 * trans-array.c (gfc_conv_expr_descriptor): Obtain the stored offset for non-descriptor, source arrays and correct for stride not equal to one before writing to field of output descriptor. 2007-05-31 Paul Thomas <[EMAIL PROTECTED]> backport from trunk PR fortran/31483 * gfortran.dg/altreturn_5.f90: New test. PR fortran/31540 * gfortran.dg/char_result_5.f90: New test. PR fortran/31867 * gfortran.dg/char_length_5.f90: New test. PR fortran/31994 * gfortran.dg/array_reference_1.f90: New test. Added: branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/altreturn_5.f90 branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/array_reference_1.f90 branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/char_length_5.f90 branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/char_result_13.f90 Modified: branches/gcc-4_2-branch/gcc/fortran/ChangeLog branches/gcc-4_2-branch/gcc/fortran/resolve.c branches/gcc-4_2-branch/gcc/fortran/trans-array.c branches/gcc-4_2-branch/gcc/fortran/trans-expr.c branches/gcc-4_2-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31994
[Bug fortran/31867] [4.2 only] function result with character LEN computed at run time
--- Comment #13 from pault at gcc dot gnu dot org 2007-05-31 18:51 --- Subject: Bug 31867 Author: pault Date: Thu May 31 18:50:56 2007 New Revision: 125235 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125235 Log: 2007-05-31 Paul Thomas <[EMAIL PROTECTED]> backport from trunk PR fortran/31483 * trans-expr.c (gfc_conv_function_call): Give a dummy procedure the correct type if it has alternate returns. PR fortran/31540 * resolve.c (resolve_fl_procedure): Resolve constant character lengths. PR fortran/31867 PR fortran/31994 * trans-array.c (gfc_conv_expr_descriptor): Obtain the stored offset for non-descriptor, source arrays and correct for stride not equal to one before writing to field of output descriptor. 2007-05-31 Paul Thomas <[EMAIL PROTECTED]> backport from trunk PR fortran/31483 * gfortran.dg/altreturn_5.f90: New test. PR fortran/31540 * gfortran.dg/char_result_5.f90: New test. PR fortran/31867 * gfortran.dg/char_length_5.f90: New test. PR fortran/31994 * gfortran.dg/array_reference_1.f90: New test. Added: branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/altreturn_5.f90 branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/array_reference_1.f90 branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/char_length_5.f90 branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/char_result_13.f90 Modified: branches/gcc-4_2-branch/gcc/fortran/ChangeLog branches/gcc-4_2-branch/gcc/fortran/resolve.c branches/gcc-4_2-branch/gcc/fortran/trans-array.c branches/gcc-4_2-branch/gcc/fortran/trans-expr.c branches/gcc-4_2-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31867
[Bug fortran/31540] [Regression 4.2 only] character((constant expression)) for external function
--- Comment #8 from pault at gcc dot gnu dot org 2007-05-31 18:51 --- Subject: Bug 31540 Author: pault Date: Thu May 31 18:50:56 2007 New Revision: 125235 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125235 Log: 2007-05-31 Paul Thomas <[EMAIL PROTECTED]> backport from trunk PR fortran/31483 * trans-expr.c (gfc_conv_function_call): Give a dummy procedure the correct type if it has alternate returns. PR fortran/31540 * resolve.c (resolve_fl_procedure): Resolve constant character lengths. PR fortran/31867 PR fortran/31994 * trans-array.c (gfc_conv_expr_descriptor): Obtain the stored offset for non-descriptor, source arrays and correct for stride not equal to one before writing to field of output descriptor. 2007-05-31 Paul Thomas <[EMAIL PROTECTED]> backport from trunk PR fortran/31483 * gfortran.dg/altreturn_5.f90: New test. PR fortran/31540 * gfortran.dg/char_result_5.f90: New test. PR fortran/31867 * gfortran.dg/char_length_5.f90: New test. PR fortran/31994 * gfortran.dg/array_reference_1.f90: New test. Added: branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/altreturn_5.f90 branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/array_reference_1.f90 branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/char_length_5.f90 branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/char_result_13.f90 Modified: branches/gcc-4_2-branch/gcc/fortran/ChangeLog branches/gcc-4_2-branch/gcc/fortran/resolve.c branches/gcc-4_2-branch/gcc/fortran/trans-array.c branches/gcc-4_2-branch/gcc/fortran/trans-expr.c branches/gcc-4_2-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31540
[Bug tree-optimization/32169] New: Ice in set_value_range, at tree-vrp.c:326
Hello, I get an ICE when compiling linux-2.6.20 with a host-gcc from today's trunk. gcc -m32 -Wp,-MD,sound/usb/.usbaudio.o.d -nostdinc -isystem /home/mstein/host-gcc/pointer_plus-2007-05-31/bin/../lib/gcc/i686-pc-linux-gnu/4.3.0/include -D__KERNEL__ -Iinclude -include include/linux/autoconf.h -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Os -pipe -msoft-float -mregparm=3 -mpreferred-stack-boundary=2 -march=i686 -mtune=generic -ffreestanding -maccumulate-outgoing-args -DCONFIG_AS_CFI=1 -Iinclude/asm-i386/mach-default -fno-omit-frame-pointer -fno-optimize-sibling-calls -g -fno-stack-protector -Wdeclaration-after-statement -Wno-pointer-sign -DMODULE -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(usbaudio)" -D"KBUILD_MODNAME=KBUILD_STR(snd_usb_audio)" -c -o sound/usb/.tmp_usbaudio.o sound/usb/usbaudio.c -save-temps gcc: warning: -pipe ignored because -save-temps specified sound/usb/usbaudio.c: In function 'prepare_startup_playback_urb': sound/usb/usbaudio.c:503: internal compiler error: in set_value_range, at tree-vrp.c:326 -- Summary: Ice in set_value_range, at tree-vrp.c:326 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mstein at phenix dot rootshell dot be GCC target triplet: i686-gnu-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32169
[Bug tree-optimization/32167] [pointer_plus] Ice in compare_values_warnv, at tree-vrp.c:760
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-05-31 18:42 --- The bug is in chrec_fold_plus somewhere. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32167
[Bug tree-optimization/32167] [pointer_plus] Ice in compare_values_warnv, at tree-vrp.c:760
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-05-31 18:29 ---
Reduced testcase:
int f(void)
{
int *a = 0;
for(a = 0; a < (int*)32767;a++)
;
}
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |pinskia at gcc dot gnu dot
|dot org |org
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2007-05-31 18:29:08
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32167
[Bug tree-optimization/32168] vectorizer doesn't handle vector condition with simple assignment
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-05-31 18:11 --- *** This bug has been marked as a duplicate of 21997 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32168
[Bug tree-optimization/21997] vectorization inhibited by gcc's choice to view an integer as a boolean
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-05-31 18:11 --- *** Bug 32168 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||hjl at lucon dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21997
[Bug tree-optimization/32168] New: vectorizer doesn't handle vector condition with simple assignment
[EMAIL PROTECTED] vect]$ cat x.c
typedef char vec_t;
extern __attribute__((aligned(16))) vec_t x [64];
extern __attribute__((aligned(16))) vec_t y [64];
extern __attribute__((aligned(16))) vec_t m [64];
void
foo1 ()
{
int i;
for (i = 0; i < 64; i++)
m [i] = x [i] == y [i] ? 1 : 2;
}
void
foo2 ()
{
int i;
for (i = 0; i < 64; i++)
m [i] = x [i] == y [i];
}
[EMAIL PROTECTED] vect]$ /export/build/gnu/gcc-nni/build-x86_64-linux/gcc/xgcc
-B./
-B/export/build/gnu/gcc-nni/build-x86_64-linux/gcc/ -O2 -msse4.2
-ftree-vectorize -ftree-vectorizer-verbose=3 -S x.c
x.c:12: note: LOOP VECTORIZED.
x.c:9: note: vectorized 1 loops in function.
x.c:21: note: not vectorized: stmt not supported: D.2111_8 = D.2109_5 ==
D.2110_7
x.c:18: note: vectorized 0 loops in function.
[EMAIL PROTECTED] vect]$
m [i] = x [i] == y [i] ? 1 : 2;
works. But
m [i] = x [i] == y [i];
doesn't work.
--
Summary: vectorizer doesn't handle vector condition with simple
assignment
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl at lucon dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32168
[Bug tree-optimization/32167] [pointer_plus] Ice in compare_values_warnv, at tree-vrp.c:760
--- Comment #1 from mstein at phenix dot rootshell dot be 2007-05-31 17:53 --- Created an attachment (id=13639) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13639&action=view) from linux-2.6.20 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32167
[Bug tree-optimization/32167] New: [pointer_plus] Ice in compare_values_warnv, at tree-vrp.c:760
Hello, I get an ICE when compiling linux-2.6.20 with a host-gcc from today's pointer_plus branch. gcc -m32 -Wp,-MD,drivers/atm/.horizon.o.d -nostdinc -isystem /home/mstein/host-gcc/pointer_plus-2007-05-31/bin/../lib/gcc/i686-pc-linux-gnu/4.3.0/include -D__KERNEL__ -Iinclude -include include/linux/autoconf.h -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Os -pipe -msoft-float -mregparm=3 -mpreferred-stack-boundary=2 -march=i686 -mtune=generic -ffreestanding -maccumulate-outgoing-args -DCONFIG_AS_CFI=1 -Iinclude/asm-i386/mach-default -fno-omit-frame-pointer -fno-optimize-sibling-calls -g -fno-stack-protector -Wdeclaration-after-statement -Wno-pointer-sign -DMODULE -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(horizon)" -D"KBUILD_MODNAME=KBUILD_STR(horizon)" -c -o drivers/atm/.tmp_horizon.o drivers/atm/horizon.c drivers/atm/horizon.c: In function 'hrz_probe': drivers/atm/horizon.c:2690: internal compiler error: in compare_values_warnv, at tree-vrp.c:760 -- Summary: [pointer_plus] Ice in compare_values_warnv, at tree- vrp.c:760 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mstein at phenix dot rootshell dot be GCC target triplet: i686-gnu-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32167
[Bug fortran/32156] [4.3 Regression] ICE with characters
--- Comment #4 from burnus at gcc dot gnu dot org 2007-05-31 17:01 --- > Yes - it's r125088 that is responsible for the regression. http://gcc.gnu.org/ml/gcc-cvs/2007-05/msg00788.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32156
[Bug c/32166] Condition check for const char string fails
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-05-31 16:35 --- without a testcase it is hard to help you. The char pointer might just point to some random memory which you might get a crash. Either hand us a testcase or use a debuger to debug your code more. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|major |normal Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32166
[Bug c++/31806] miscompilation with -fschedule-insns2 -fno-threadsafe-statics
--- Comment #7 from jakub at gcc dot gnu dot org 2007-05-31 16:40 --- Subject: Bug 31806 Author: jakub Date: Thu May 31 16:40:12 2007 New Revision: 125229 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125229 Log: PR c++/31806 * decl.c (cp_finish_decl): Also clear was_readonly if a static var needs runtime initialization. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31806
[Bug c++/31809] [4.1/4.2/4.3 Regression] sometimes TREE_READONLY is still set for non read only variables causing wrong code
--- Comment #9 from mark at codesourcery dot com 2007-05-31 16:32 --- Subject: Re: [4.1/4.2/4.3 Regression] sometimes TREE_READONLY is still set for non read only variables causing wrong code jakub at gcc dot gnu dot org wrote: > 2007-05-31 Jakub Jelinek <[EMAIL PROTECTED]> > > PR c++/31806 > * decl.c (cp_finish_decl): Also clear was_readonly if a static var > needs runtime initialization. This patch is OK. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31809
[Bug tree-optimization/32160] [4.3 Regression] ICE with -O3 in verify_ssa
--- Comment #4 from rakdver at gcc dot gnu dot org 2007-05-31 16:27 --- Subject: Bug 32160 Author: rakdver Date: Thu May 31 16:27:05 2007 New Revision: 125228 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125228 Log: PR tree-optimization/32160 * tree-predcom.c (predcom_tmp_var): New function. Mark created variable as gimple reg. (initialize_root_vars, initialize_root_vars_lm): Use predcom_tmp_var. * gfortran.dg/predcom-1.f: New test. Added: trunk/gcc/testsuite/gfortran.dg/predcom-1.f Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-predcom.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32160
[Bug c/32166] New: Condition check for const char string fails
Ive been working on a c program that does the error
condition check in the beginning as follows,
char *fun(str)
const char *str;
{
if (str == NULL) <-- Error check, taking the const char variable directly.
printf("Null string \n");
..
}
But the code fails to perform the error checking
when a NULL string is passed and gives a segmentation
fault.
Did anyone face a similar problem. Please provide me some
information regarding this problem.
--
Summary: Condition check for const char string fails
Product: gcc
Version: 3.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kmanjunat at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32166
[Bug c++/32165] New: Calling main allowed at O3 and Os
int
main ()
{
main();
}
Compiling this program at different optimisation levels gives different
results. Levels O3 and Os appear to be broken (with GCC 4.1.1).
$ g++ t.cxx -c -ansi -pedantic -O0
t.cxx: In function int main():
t.cxx:4: error: ISO C++ forbids taking address of function ::main
$ g++ t.cxx -c -ansi -pedantic -O1
t.cxx: In function int main():
t.cxx:4: error: ISO C++ forbids taking address of function ::main
$ g++ t.cxx -c -ansi -pedantic -O2
t.cxx: In function int main():
t.cxx:4: error: ISO C++ forbids taking address of function ::main
$ g++ t.cxx -c -ansi -pedantic -O3
$ g++ t.cxx -c -ansi -pedantic -Os
--
Summary: Calling main allowed at O3 and Os
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: andrew dot stubbs at st dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32165
[Bug ada/32164] Bug box, Assert_Failure at einfo.adb:846, renaming predefined "=" and "/="
--- Comment #1 from ludovic at ludovic-brenta dot org 2007-05-31 14:58 --- Same symptoms on i686-unknown-linux-gnu. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32164
[Bug ada/32164] New: Bug box, Assert_Failure at einfo.adb:846, renaming predefined "=" and "/="
(forwarded from the Debian bug tracking system) package Pak1 is type T1 is tagged null record; function Eq(X, Y : T1) return Boolean renames "="; function Neq(X, Y : T1) return Boolean renames "/="; -- line 4 end Pak1; gnatmake pak1 yields: gnatmake pak1 gcc-4.1 -c pak1.ads +===GNAT BUG DETECTED==+ | 4.1.2 20061115 (prerelease) (Debian 4.1.1-22) (x86_64-pc-linux-gnu) | | Assert_Failure einfo.adb:846 | | Error detected at pak1.ads:4:43 | The token that triggers the bug box is the "renames" in line 4. Here is a second test case that triggers the same bug box: package Pak1 is type T1 is tagged null record; function Eq (X, Y : T1) return Boolean renames "="; type T2 is new T1 with null record; function Eq (X, Y : T2) return Boolean renames "="; -- line 6 end Pak1; gnatmake pak1 gcc-4.1 -c pak1.ads +===GNAT BUG DETECTED==+ | 4.1.2 20061115 (prerelease) (Debian 4.1.1-22) (x86_64-pc-linux-gnu) | | Assert_Failure einfo.adb:846 | | Error detected at pak1.ads:6:43 | The token that triggers this bug box is, again, the "renames" in line 6. -- Summary: Bug box, Assert_Failure at einfo.adb:846, renaming predefined "=" and "/=" Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ludovic at ludovic-brenta dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32164
[Bug ada/16525] 3.3.4 (i486-slackware-linux-gnu) Assert_Failure einfo.adb:435
--- Comment #3 from ludovic at ludovic-brenta dot org 2007-05-31 14:51 --- Confirmed in Debian 4.1.1-22: +===GNAT BUG DETECTED==+ | 4.1.2 20061115 (prerelease) (Debian 4.1.1-22) (x86_64-pc-linux-gnu) | | Assert_Failure einfo.adb:550 | | Error detected at dm-tools.adb:4:16 | Someone, please update the "known to fail" line to 3.3.4, 4.0.0, 4.1.1 as I don't have the permission to do so myself. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16525
[Bug target/32163] Compiling with stack protector causes reigster spill failure
--- Comment #3 from kkojima at gcc dot gnu dot org 2007-05-31 13:30 ---
I've confirmed that this fails with 4.1.2, 4.2.0 and 4.3.0
on sh4-unknown-linux-gnu. A reduced testcase is:
--
int foo ()
{
char *p;
char fext[128];
p = fext;
bar (&p, (void *)0);
if (p)
free (p);
return 0;
}
--
which fails with -O -fpic -fstack-protector. Curiously the error
went away with -O2 -fpic -fstack-protector.
--
kkojima at gcc dot gnu dot org changed:
What|Removed |Added
CC||kkojima at gcc dot gnu dot
||org
Status|UNCONFIRMED |NEW
Component|other |target
Ever Confirmed|0 |1
Keywords||ice-on-valid-code
Known to fail||4.1.2 4.2.0 4.3.0
Last reconfirmed|-00-00 00:00:00 |2007-05-31 13:30:12
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32163
[Bug tree-optimization/32146] Bad matrix layout transformations
--- Comment #3 from razya at il dot ibm dot com 2007-05-31 12:57 --- (In reply to comment #2) > (In reply to comment #1) > > I get the same failure on powerpc64-linux-gnu. > I recreated it too, working on it. Thanks Here's a patch that fixes the problems: http://gcc.gnu.org/ml/gcc-patches/2007-05/msg02141.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32146
[Bug fortran/32151] Misleading compilation diagnostic
--- Comment #1 from P dot Schaffnit at access dot rwth-aachen dot de 2007-05-31 12:47 --- More weird stuff with the following... Philippe subroutine Test ( Verbose, Position ) logical, intent(in) :: Verbose integer, intent(in) :: Position integer, parameter :: Anchor = 666, Cut_off = 3 if ( Verbose ) ) then write(*,*) "Been there, got the tee-shirt!" endif if ( ( Verbose ) .and. ( abs ( Position - Anchor ) le. Cut_off ) ) then write(*,*) "Been there, got the tee-shirt!" endif return end subroutine Test -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32151
[Bug tree-optimization/32160] [4.3 Regression] ICE with -O3 in verify_ssa
--- Comment #3 from rakdver at gcc dot gnu dot org 2007-05-31 12:20 --- Patch: http://gcc.gnu.org/ml/gcc-patches/2007-05/msg02138.html -- rakdver at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2007- ||05/msg02138.html Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32160
[Bug fortran/32002] [4.2 regression] insufficient conformance check when assigning the result of an elemental function to an array
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Known to fail|4.2.1 4.3.0 |4.2.1 Known to work|4.1.1 |4.1.1 4.3.0 Last reconfirmed|-00-00 00:00:00 |2007-05-31 12:01:02 date|| Summary|[4.2/4.3 regression]|[4.2 regression] |insufficient conformance|insufficient conformance |check when assigning the|check when assigning the |result of an elemental |result of an elemental |function to an array|function to an array Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32002
[Bug fortran/31929] [4.1/4.2 only] atan2 accepts non-conforming array shapes
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-05-31 12:00 --- I don't think we should backport that to 4.2, as it's not a regression AFAICS. Can you close it? (or, if you think it's worth backporting, ask for opinions on the mailing-list?) -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-05-31 12:00:09 date|| Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31929
[Bug fortran/32155] Unresolved external __gfortran_os_error in program that manipulates strings
--- Comment #4 from KnowlesPJ at Cardiff dot ac dot uk 2007-05-31 11:58 --- The compiler was downloaded from the link in http://hpc.sourceforge.net/ . -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32155
[Bug fortran/32129] ICE: Procedure call with array-section-actual to scalar dummy
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-05-31 11:57:03 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32129
[Bug fortran/32049] Support on x86_64 also kind=16
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-05-31 11:56 --- To have decent support for __float128 in gfortran, we need to provide a __float128 math library. Do you happen to know any? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32049
[Bug fortran/32150] Strangeness when repeating an INTERFACE entity in ONLY clause of USE statement
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC build triplet|x86_64-unknown-linux-gnu| GCC host triplet|x86_64-unknown-linux-gnu| GCC target triplet|x86_64-unknown-linux-gnu| Keywords||diagnostic Last reconfirmed|-00-00 00:00:00 |2007-05-31 11:55:09 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32150
[Bug fortran/32155] Unresolved external __gfortran_os_error in program that manipulates strings
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-05-31 11:54 --- (In reply to comment #0) > In the following code, __gfortran_os_error is thrown as unresolved at link > time. Is that a compiler you built from scratch, or did you build it, update the source and rebuilt it not-from-scratch? That's a case where I'd expect to see that kind of error. Otherwise, I don't know how this is happening. -- 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=32155
[Bug other/32163] Compiling with stack protector causes reigster spill failure
--- Comment #2 from uwe at netbsd dot org 2007-05-31 11:44 --- Before failing to compile pic version of asprintf.o as reportde above, non-pic version is successfully compiled. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32163
[Bug other/32163] Compiling with stack protector causes reigster spill failure
--- Comment #1 from uwe at netbsd dot org 2007-05-31 11:37 --- Created an attachment (id=13638) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13638&action=view) Preprocessed source of the file that causes the error. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32163
[Bug other/32163] New: Compiling with stack protector causes reigster spill failure
Building NetBSD/sh3 soruce tree with stack protector enabled fails with
/usr/nb-ssp/tools/bin/shle--netbsdelf-gcc -O -Wall -Wstrict-prototypes
-Wmissing-prototypes -Wpointer-arith -Wno-sign-compare -Wno-traditional
-Wreturn-type -Wswitch -Wshadow -Wcast-qual -Wwrite-strings -Wextra
-Wno-unused-parameter -std=gnu99 -Werror -fstack-protector -Wstack-protector
--param ssp-buffer-size=1 -D_LIBC -DLIBC_SCCS -DSYSLIBC_SCCS -D_REENTRANT
-DHESIOD -DINET6 -DNLS -DYP -I/usr/src/lib/libc/include -I/usr/src/lib/libc
-DSOFTFLOAT -I/usr/src/lib/libc/arch/sh3/softfloat
-I/usr/src/lib/libc/softfloat -DSOFTFLOAT_FOR_GCC -I/usr/src/sys
-I/usr/src/lib/libc/compat/stdlib -I/usr/src/lib/libc/compat/../stdlib
-I/usr/src/lib/libc/../../common/lib/libc/quad
-I/usr/src/lib/libc/../../common/lib/libc/string
-I/usr/src/lib/libc/../../common/lib/libc/arch/sh3/string
-D__DBINTERFACE_PRIVATE -DI18NMODULE_MAJOR=4 -DCITRUS
-I/usr/src/libexec/ld.elf_so -I/usr/src/lib/libc/dlfcn
-I/usr/src/lib/libc/gdtoa -DNO_FENV_H -I/usr/src/lib/libc/arch/sh3/gdtoa
-DCITRUS_ICONV -DWITH_RUNE -I/usr/src/lib/libc -DPOSIX_MISTAKE -DCOMPAT__RES
-DUSE_POLL -DPORTMAP -DWIDE_DOUBLE -DALL_STATE -DUSG_COMPAT -nostdinc -isystem
/usr/nb-ssp/distrib/landisk/usr/include -c -D_I18N_DYNAMIC -fPIC -DPIC
/usr/src/lib/libc/stdio/asprintf.c -o asprintf.so
/usr/src/lib/libc/stdio/asprintf.c: In function '_asprintf':
/usr/src/lib/libc/stdio/asprintf.c:85: error: unable to find a register to
spill in class 'R0_REGS'
/usr/src/lib/libc/stdio/asprintf.c:85: error: this is the insn:
(insn 191 211 210 7 (set (reg/f:SI 2 r2 [246])
(mem/u/c:SI (plus:SI (reg:SI 12 r12)
(reg/f:SI 1 r1 [247])) [0 S4 A32])) 171 {movsi_i}
(insn_list:REG_DEP_TRUE 189 (nil))
(expr_list:REG_DEAD (reg/f:SI 1 r1 [247])
(expr_list:REG_EQUIV (symbol_ref:SI ("__stack_chk_guard") [flags 0x40]
)
(nil
/usr/src/lib/libc/stdio/asprintf.c:85: confused by earlier errors, bailing out
The compiler is gcc 4.1.2 as imported into the NetBSD tree:
shle--netbsdelf-gcc (GCC) 4.1.2 20070110 (prerelease) (NetBSD nb1 20070110)
--
Summary: Compiling with stack protector causes reigster spill
failure
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: uwe at netbsd dot org
GCC build triplet: i386--netbsdelf
GCC host triplet: i386--netbsdelf
GCC target triplet: sh3--netbsdelf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32163
[Bug c++/32158] uninitialized_fill compile failure if no default assignment operator
--- Comment #11 from pcarlini at suse dot de 2007-05-31 11:15 --- Fixed. Thanks again Michael for timely raising the issue. -- 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=32158
[Bug c++/32158] uninitialized_fill compile failure if no default assignment operator
--- Comment #10 from paolo at gcc dot gnu dot org 2007-05-31 11:14 --- Subject: Bug 32158 Author: paolo Date: Thu May 31 11:13:57 2007 New Revision: 125223 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125223 Log: 2007-05-31 Paolo Carlini <[EMAIL PROTECTED]> PR c++/32158 (libstdc++ bits) * include/bits/stl_uninitialized.h (__uninitialized_copy_aux, __uninitialized_fill_aux, __uninitialized_fill_n_aux): Remove. (struct __uninitialized_copy, struct __uninitialized_fill, struct __uninitialized_fill_n): Add. (uninitialized_copy, uninitialized_fill, uninitialized_fill_n): Adjust. * testsuite/20_util/specialized_algorithms/32158.cc: New. * include/bits/stl_uninitialized.h (uninitialized_copy(_InputIterator, _InputIterator, _ForwardIterator)): Robustify vs non-POD input. * include/bits/stl_vector.h (_M_fill_initialize): New. (vector(size_type, const value_type&, const allocator_type&), _M_initialize_dispatch(_Integer, _Integer, __true_type)): Use it. * testsuite/23_containers/vector/requirements/dr438/assign_neg.cc: Adjust dg-error line. * testsuite/23_containers/vector/requirements/dr438/insert_neg.cc: Likewise. * testsuite/23_containers/vector/requirements/dr438/ constructor_1_neg.cc: Likewise. * testsuite/23_containers/vector/requirements/dr438/ constructor_2_neg.cc: Likewise. Added: trunk/libstdc++-v3/testsuite/20_util/specialized_algorithms/32158.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/stl_uninitialized.h trunk/libstdc++-v3/include/bits/stl_vector.h trunk/libstdc++-v3/testsuite/23_containers/vector/requirements/dr438/assign_neg.cc trunk/libstdc++-v3/testsuite/23_containers/vector/requirements/dr438/constructor_1_neg.cc trunk/libstdc++-v3/testsuite/23_containers/vector/requirements/dr438/constructor_2_neg.cc trunk/libstdc++-v3/testsuite/23_containers/vector/requirements/dr438/insert_neg.cc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32158
[Bug c++/16635] g++ instantiates templates at the wrong place
--- Comment #10 from andrew dot stubbs at st dot com 2007-05-31 10:57
---
Here's another issue in this area. Is it the same, or a separate bug? This code
is adapted from the example in DR197.
#include
struct C1 {};
struct C2 : C1 {
};
C1 c1;
C2 c2;
void f(C1);
template void g(T t)
{
f(c2); // f(C1) should be the nearest match
f(t); // dependent
}
void f(C2);
int main()
{
g(c2); // will cause one call of f(C1) followed
// by one calls of f(C2)
g(c1); // will cause two calls of f(C1)
}
void f(C1) { printf ("C1\n");}
void f(C2) { printf ("C2\n");}
What actually happens (with the 4.1.1 I have anyway) is three calls to f(C2)
followed by one call to f(C1). This shows that the *non-dependent* call is
being resolved in the wrong scope also - it should not be able to see f(C2).
If the prototype for f(C2) is removed, then the previously described problem is
apparent also, and the (incorrect) behaviour of the program is unchanged.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16635
[Bug fortran/32103] Module with equivalence draws "unsatisfied reference"
--- Comment #8 from pault at gcc dot gnu dot org 2007-05-31 10:19 --- Fixed on trunk 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=32103
[Bug other/32154] sim-crt0.o/crt0.o isn't found during configure due to missing -L or -B
--- Comment #1 from rask at sygehus dot dk 2007-05-31 10:02 --- The same thing happens when configuring with --target==mcore-unknown-elf, only the startup file is crt0.c instead of sim-crt0.o. -- rask at sygehus dot dk changed: What|Removed |Added GCC target triplet|powerpc-unknown-eabisim |powerpc-eabisim mcore-elf Summary|sim-crt0.o isn't found |sim-crt0.o/crt0.o isn't |during configure due to |found during configure due |missing -L or -B|to missing -L or -B http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32154
[Bug c++/31809] [4.1/4.2/4.3 Regression] sometimes TREE_READONLY is still set for non read only variables causing wrong code
--- Comment #8 from jakub at gcc dot gnu dot org 2007-05-31 10:00 ---
I saw was_readonly as well and wondered if it might be a problem or not, then
incorrectly assumed REFERENCE_TYPEs can't be an issue, but as PR31806 shows,
they apparently are.
2007-05-31 Jakub Jelinek <[EMAIL PROTECTED]>
PR c++/31806
* decl.c (cp_finish_decl): Also clear was_readonly if a static var
needs runtime initialization.
--- gcc/cp/decl.c.jj2007-05-30 21:03:07.0 +0200
+++ gcc/cp/decl.c 2007-05-31 11:32:48.0 +0200
@@ -5361,8 +5361,12 @@ cp_finish_decl (tree decl, tree init, bo
/* If a TREE_READONLY variable needs initialization
at runtime, it is no longer readonly and we need to
avoid MEM_READONLY_P being set on RTL created for it. */
- if (init && TREE_READONLY (decl))
- TREE_READONLY (decl) = 0;
+ if (init)
+ {
+ if (TREE_READONLY (decl))
+ TREE_READONLY (decl) = 0;
+ was_readonly = 0;
+ }
expand_static_init (decl, init);
}
}
should cure this.
Regarding the performance degradation, to cure this, we'd either have to
revert to RTX_UNCHANGING_P (which we know just leads to tremendous amount
of bugs), or introduce a way to say "this tree resp. this rtl is readonly
in all functions but ". For filescope C++ vars that need
runtime the set is certainly static initialization and destruction, all
functions inlined into it and then depends on how aggresive IPA optimizations
want to be, if one day they choose to clone some constructor of a initialized
once, then read-only variable and the optimizers would assume that var is
readonly, we'd again miscompile things. For function-scope static vars we'd
need to put the containing function into the set, so it probably won't help
there at all.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31809
[Bug c++/23885] incorrect template two-stage name-lookup
--- Comment #7 from andrew dot stubbs at st dot com 2007-05-31 09:49 --- See here: http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#197 It would appear that only koenig lookup is done for functions defined after the template declaration. As the Intel statement says, koenig lookup does not apply to fundamental types. Koenig lookup is described in clause 3.4.2 "Argument dependent name lookup". It is clause 14.6.4 "Dependent name resolution" that limits the lookup to Koenig only. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23885
[Bug fortran/32156] [4.3 Regression] ICE with characters
--- Comment #3 from pault at gcc dot gnu dot org 2007-05-31 09:19 --- (In reply to comment #2) Yes - it's r125088 that is responsible for the regression. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32156
