[Bug tree-optimization/30911] VRP fails to eliminate range checks in Ada code
--- Comment #13 from rguenth at gcc dot gnu dot org 2007-02-23 09:22
---
In reply to comment #8
To understand the issues a little bit more -- are there any requirements on
overflow behavior of the _base_ type? Suppose a type T with range -100..120
has indeed be assigned a signed char with precision 8 (and so range -128..127).
If we now do arithmetic like (to add two Ts)
T foo(T t1, T t2)
{
signed char t1_base = (signed char)t1;
signed char t2_base = (signed char)t2;
signed char res_base = t1_base + t2_base;
if (res_base 10 || res_base 120)
abort ();
return (T)res_base;
}
is it ok to not raise a constraint error if I happen to add 100 and 100 which
wraps on the machine in signed char precision back to a valid value inside
the range of T?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30911
[Bug tree-optimization/30911] VRP fails to eliminate range checks in Ada code
--- Comment #14 from baldrick at free dot fr 2007-02-23 09:39 --- Subject: Re: VRP fails to eliminate range checks in Ada code On Friday 23 February 2007 06:50:48 ebotcazou at gcc dot gnu dot org wrote: --- Comment #12 from ebotcazou at gcc dot gnu dot org 2007-02-23 05:50 --- Sorry about that - it wasn't on purpose: your comment and mine collided. I actually checked the two bugs after getting the message that I'd manage to wipe out your change, and the relationship between 26797 and 30911 that you'd set up still seemed to be there. I added it again. Note that you had received a warning before overwriting. Yes, but since I hadn't made any changes except adding a comment, I didn't see why this should cause any problems. The fact that it did cause problems seems like a bugzilla bug to me. Anyway, now that I know how this works I will be more careful next time :-/ Ciao, D. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30911
[Bug tree-optimization/30930] [4.3 Regression] vector can cause to create an extra variable
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-02-23 09:56 --- I believe the mini-pre-alias passes from honza will fix this by recomputing addressability. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30930
[Bug tree-optimization/30911] VRP fails to eliminate range checks in Ada code
--- Comment #15 from baldrick at free dot fr 2007-02-23 10:03 ---
Subject: Re: VRP fails to eliminate range checks in Ada code
On Friday 23 February 2007 10:22:15 rguenth at gcc dot gnu dot org wrote:
--- Comment #13 from rguenth at gcc dot gnu dot org 2007-02-23 09:22
---
In reply to comment #8
To understand the issues a little bit more -- are there any requirements on
overflow behavior of the _base_ type? Suppose a type T with range -100..120
has indeed be assigned a signed char with precision 8 (and so range
-128..127).
If we now do arithmetic like (to add two Ts)
T foo(T t1, T t2)
{
signed char t1_base = (signed char)t1;
signed char t2_base = (signed char)t2;
signed char res_base = t1_base + t2_base;
if (res_base 10 || res_base 120)
abort ();
return (T)res_base;
}
is it ok to not raise a constraint error if I happen to add 100 and 100 which
wraps on the machine in signed char precision back to a valid value inside
the range of T?
The Ada language requires the compiler to insert checks that arithmetic in
the base type does not overflow, and to raise an exception if it does. To
be more precise, it is allowed either to raise an exception or return the
mathematically correct result (i.e. what you would get if the range of your
base type was infinite). For example, calculating (x + INT_MAX) - INT_MAX
is allowed to return x or raise an exception. The Ada f-e doesn't insert
the required checks by default - you have to give it the -gnato switch if
you want full language conformance (it doesn't do it by default because it
is too expensive; the Ada f-e really wants to use -ftrapv but doesn't because
-ftrapv doesn't work reliably enough, instead it inserts explicit checks).
Thus in standard conformant -gnato mode the problem you describe can never
happen. What about the default mode, without -gnato? The language provides
a way of suppressing checks, in this case the check is called Overflow_Check.
Not using -gnato is equivalent to suppressing Overflow_Check everywhere. The
language standard says If a given check has been suppressed, and the
corresponding error situation occurs, the execution of the program is
erroneous.
Thus you may reasonably assume that the result of signed overflow is undefined.
So you can do what you like here, the same as in C. I think, as a general
rule,
that if you assume arithmetic on base types is the same as in C, then you won't
go wrong.
PS: For unsigned types the situation is different, as in C, namely addition has
wraparound semantics.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30911
[Bug rtl-optimization/30931] Simple test case loops infinitely with -O1 -fstrength-reduce.
--- Comment #5 from rguenth at gcc dot gnu dot org 2007-02-23 10:03 --- Works for me. Can you tell us all options in effect? I.e. gcc -O -fstrength-reduce t.c -v output? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30931
[Bug target/30825] [4.3 Regression] current mainline fails to bootstrap with --with-arch=athlon64
--- Comment #3 from ubizjak at gmail dot com 2007-02-23 10:22 --- There is something wrong in combine_predictions_for_insn(). Perhaps stack gets corrupted, but from the comment: /* Use FP math to avoid overflows of 32bit integers. */ combined_probability variable is _sometimes_ calculated as nan. Tracing through asm, it looks that it happens because fildl from stack loads 0x1388, pushed to stack earlier. BTW: For some reason gdb can't trace through this source, so it is really something strange going on. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30825
[Bug c/30934] New: gcc: Internal error: Segmentation fault (program as)
Configured with: ../gcc-3.4.6/configure --prefix=/usr --enable-shared --enable-threads=posix --enable-__cxa_atexit --disable-checking --with-gnu-ld --verbose --target=i486-slackware-linux --host=i486-slackware-linux Thread model: posix gcc version 3.4.6 Command Line : gcc -I/opt/bluetooth/include -I/usr/include/glib-1.2 -I/usr/lib/glib/include -c obex.c -o obex.o gcc: Internal error: Segmentation fault (program as) Please submit a full bug report. See URL:http://gcc.gnu.org/bugs.html for instructions. make: *** [obex.o] Error 1 -- Summary: gcc: Internal error: Segmentation fault (program as) Product: gcc Version: 3.4.6 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: grega dot koprivnikar at 7-s dot si GCC target triplet: i486-slackware-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30934
[Bug c/30934] gcc: Internal error: Segmentation fault (program as)
--- Comment #1 from grega dot koprivnikar at 7-s dot si 2007-02-23 11:18 --- Created an attachment (id=13095) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13095action=view) Make file used to sompile the program -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30934
[Bug tree-optimization/30911] VRP fails to eliminate range checks in Ada code
--- Comment #16 from rguenth at gcc dot gnu dot org 2007-02-23 11:37 --- Created an attachment (id=13096) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13096action=view) patch fixing the problem The attached patch removes all checks (from the first half of the testcase). Not yet bootstrapped or tested. There is one appearant problem with the way the Ada frontend sets TYPE_MIN/MAX_VALUE on the integer subtypes -- I expected the min/max values to be of the type of the subtype, not of the underlying base type. This unnecessarily complicates things. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30911
[Bug tree-optimization/30911] VRP fails to eliminate range checks in Ada code
--- Comment #17 from rguenth at gcc dot gnu dot org 2007-02-23 11:42 --- This also depends on PR30317 as we have for example L9:; source.4_29 = (js__TsB) source_4; R5b_30 = source.4_29 + 1; R5b.5_31 = (UNSIGNED_8) R5b_30; if (R5b.5_31 100) goto L10; else goto L11; -- rguenth at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||30317 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30911
[Bug tree-optimization/30911] VRP fails to eliminate range checks in Ada code
--- Comment #18 from baldrick at free dot fr 2007-02-23 12:36 --- Subject: Re: VRP fails to eliminate range checks in Ada code The attached patch removes all checks (from the first half of the testcase). Thanks for the patch! + Make sure to preserve ~[a, a] (FIXME: why?) and ~[-INF, +INF] though. Some parts of VRP punt on anti-ranges unless it is of the form ~[a,a], however turning this into [a+1,TYPE_MAX] should cause no problems, since this is a range not an anti-range. +(tree_int_cst_equal (min,TYPE_MIN_VALUE (TREE_TYPE (min))) Missing space after min,. + fprintf (dump_file, Canonicalized anit-range to [); anit-range! :) Unfortunately bootstrap dies instantly with In file included from ../../gcc.fsf.master/gcc/fold-const.c:56: ../../gcc.fsf.master/gcc/tree.h: In function âVEC_tree_base_lengthâ: ../../gcc.fsf.master/gcc/tree.h:208: internal compiler error: tree check: expected integer_type or enumeral_type or boolean_type or real_type, have pointer_type in fold_comparison, at fold-const.c:8768 Most likely it was a pointer type. By the way, I guess you're also doing the folding for floating point types, is that wise? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30911
[Bug tree-optimization/30911] VRP fails to eliminate range checks in Ada code
--- Comment #19 from rguenth at gcc dot gnu dot org 2007-02-23 12:41 --- Yeah, the fold-const.c chunk misses + /* We can compare x OP cst based on the value range of the type of + x. */ + if (TREE_CODE (arg1) == INTEGER_CST +TREE_CODE (arg0) != INTEGER_CST +!POINTER_TYPE_P (TREE_TYPE (arg0)) this line +TYPE_MIN_VALUE (TREE_TYPE (arg0)) I don't think I'm folding pointer types, if arg1 is an integer constant arg0 is of integer type as well. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30911
[Bug bootstrap/30853] warnings about traditional.c during bootstrap with -O3, leading to internal error
--- Comment #2 from sdack at gmx dot de 2007-02-23 13:03 --- Subject: Re: warnings about traditional.c during bootstrap with -O3, leading to internal error --enable-bootstrap Don't use that option for 4.1.x. Can you try again without that option? I have, and together with alot of other options. I then compiled multiple packages (bash, binutils, bison, bzip2, coreutils, cpio, ... sed, tar, texinfo) with the resulting gcc and ran the regression tests of those packages. It does not seem to do any harm after all. Still, I find it a bit scary installing gcc without first bootstrapping it. I trust the result more than without it. Sven -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30853
[Bug tree-optimization/30911] VRP fails to eliminate range checks in Ada code
--- Comment #20 from baldrick at free dot fr 2007-02-23 13:04 --- Subject: Re: VRP fails to eliminate range checks in Ada code !POINTER_TYPE_P I'm testing with INTEGRAL_TYPE_P. By the way, I see a lot a anti-range canonicalization going on in C code. A lot of code where u is of an unsigned type checks whether u!=0. This now gets turned into the range [1,INF] which I guess is a good thing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30911
[Bug target/30825] [4.3 Regression] current mainline fails to bootstrap when -msse is used
--- Comment #4 from ubizjak at gmail dot com 2007-02-23 13:54 ---
Got it.
This regression is indeed introduced by patch that fixes inter-unit moves
(http://gcc.gnu.org/viewcvs?view=revrevision=121767) as was found out in PR
30921.
The failure is due to slight register preference change introduced by the above
patch. The consequence of this change is, that a mmx register is allocated when
-mmmx (or -msseX) is used in bootstrap flags. This affects all subsequent x87
FP calculations, so they always show nan in active shared x87/mm registers
due to missing emms insn.
Attached patch tries to set register preferences back as they were before
inter-unit moves patch. Using this patch, I was able to bootstrap gcc using
-O2 -msse and -O2 -march=pentium4 BOOT_CFLAGS. For the former case, patch
was also regression tested for c testsuite without new failures.
2007-02-23 Uros Bizjak [EMAIL PROTECTED]
* config/i386/i386.md (*movdi_1_rex64, zero_extendsidi2_32,
zero_extendsidi2_rex64): Penalize MMX register-memory moves.
(*movsf_1): Penalize MMX moves.
Index: i386.md
===
--- i386.md (revision 122219)
+++ i386.md (working copy)
@@ -2022,9 +2022,9 @@
(define_insn *movdi_1_rex64
[(set (match_operand:DI 0 nonimmediate_operand
- =r,r ,r,m ,!m,*y,*y,?r ,m ,?*Ym,*y,*x,*x,?r ,m,?*Yi,*x,?*x,?*Ym)
+ =r,r ,r,m ,!m,*y,*y,?r ,?m,?*Ym,?*y,*x,*x,?r ,m,?*Yi,*x,?*x,?*Ym)
(match_operand:DI 1 general_operand
- Z ,rem,i,re,n ,C ,*y,*Ym,*y,r ,m ,C ,*x,*Yi,*x,r ,m ,*Ym,*x))]
+ Z ,rem,i,re,n ,C ,*y,*Ym,*y,r ,m ,C ,*x,*Yi,*x,r ,m ,*Ym,*x))]
TARGET_64BIT !(MEM_P (operands[0]) MEM_P (operands[1]))
{
switch (get_attr_type (insn))
@@ -2326,9 +2326,9 @@
(define_insn *movsf_1
[(set (match_operand:SF 0 nonimmediate_operand
- =f,m,f,r ,m ,x,x,x ,m,*y,m ,*y,Yi,r ,*Ym,r )
+ =f,m,f,r ,m ,x,x,x ,m,!*y,!m ,!*y,!Yi,!r ,!*Ym,!r )
(match_operand:SF 1 general_operand
- fm,f,G,rmF,Fr,C,x,xm,x,m ,*y,*y,r ,Yi,r ,*Ym))]
+ fm,f,G,rmF,Fr,C,x,xm,x,m , *y, *y,r ,Yi ,r ,*Ym))]
!(MEM_P (operands[0]) MEM_P (operands[1]))
(reload_in_progress || reload_completed
|| (ix86_cmodel == CM_MEDIUM || ix86_cmodel == CM_LARGE)
@@ -3401,9 +3401,9 @@
})
(define_insn zero_extendsidi2_32
- [(set (match_operand:DI 0 nonimmediate_operand
=r,?r,?o,?*Ym,*y,?*Yi,*Y2)
+ [(set (match_operand:DI 0 nonimmediate_operand
=r,?r,?o,?*Ym,?*y,?*Yi,?*Y2)
(zero_extend:DI
-(match_operand:SI 1 nonimmediate_operand 0,rm,r ,r ,m ,r ,m)))
+(match_operand:SI 1 nonimmediate_operand 0,rm,r ,r ,m ,r
,m)))
(clobber (reg:CC FLAGS_REG))]
!TARGET_64BIT
@
@@ -3418,9 +3418,9 @@
(set_attr type multi,multi,multi,mmxmov,mmxmov,ssemov,ssemov)])
(define_insn zero_extendsidi2_rex64
- [(set (match_operand:DI 0 nonimmediate_operand =r,o,?*Ym,*y,?*Yi,*Y2)
+ [(set (match_operand:DI 0 nonimmediate_operand =r,o,?*Ym,?*y,?*Yi,?*Y2)
(zero_extend:DI
- (match_operand:SI 1 nonimmediate_operand rm,0,r ,m ,r ,m)))]
+ (match_operand:SI 1 nonimmediate_operand rm,0,r ,m ,r ,m)))]
TARGET_64BIT
@
mov\t{%k1, %k0|%k0, %k1}
--
ubizjak at gmail dot com changed:
What|Removed |Added
CC||rth at gcc dot gnu dot org
Severity|normal |critical
Keywords||ssemmx
Summary|[4.3 Regression] current|[4.3 Regression] current
|mainline fails to bootstrap |mainline fails to bootstrap
|with --with-arch=athlon64 |when -msse is used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30825
[Bug java/20495] [4.0/4.1/4.2/4.3 Regression] building gcj hangs on gcj-dbtool
--- Comment #5 from wangguoqin1001 at gmail dot com 2007-02-23 14:04 --- (In reply to comment #4) Does this still happen? Still happening on me, both in 4.1.1-r3 and 4.1.2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20495
[Bug tree-optimization/30911] VRP fails to eliminate range checks in Ada code
--- Comment #21 from rguenth at gcc dot gnu dot org 2007-02-23 14:05
---
Yep, INTEGRAL_TYPE_P is better. the u!=0 case might be why I tried to preserve
~[0,0] for unsigneds... maybe we have some failing testcases with ranges for
range_is_nonnull, which only checks
static inline bool
range_is_nonnull (value_range_t *vr)
{
return vr-type == VR_ANTI_RANGE
integer_zerop (vr-min)
integer_zerop (vr-max);
}
but doesn't see that for unsigned it's equivalent to [1, +INF]. I'll adjust
that, too.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30911
[Bug rtl-optimization/30931] Simple test case loops infinitely with -O1 -fstrength-reduce.
--- Comment #6 from bergner at gcc dot gnu dot org 2007-02-23 14:06 --- Here's the output you asked for using the latest 4.1 sources I built yesterday. This also fails for me using the system compilers on Ubuntu Edgy and SLES10. I'll try and track down a x86 RHEL5 system to test there too. Please note it's not the compiler that is looping forever, but the built binary when executed. bg47:bergner% ./install/gcc-4.1/bin/gcc -O1 -fstrength-reduce pr30311.c -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../../gcc-4_1-20070222/configure --enable-shared --enable-threads=posix --enable-checking --enable-languages=c --prefix=/tmp/bergner/install/gcc-4.1 Thread model: posix gcc version 4.1.3 20070222 (prerelease) /tmp/bergner/install/gcc-4.1/libexec/gcc/i686-pc-linux-gnu/4.1.3/cc1 -quiet -v pr30311.c -quiet -dumpbase pr30311.c -mtune=pentiumpro -auxbase pr30311 -O1 -version -fstrength-reduce -o /tmp/cc6Cx7Y6.s ignoring nonexistent directory /tmp/bergner/install/gcc-4.1/lib/gcc/i686-pc-linux-gnu/4.1.3/../../../../i686-pc-linux-gnu/include #include ... search starts here: #include ... search starts here: /usr/local/include /tmp/bergner/install/gcc-4.1/include /tmp/bergner/install/gcc-4.1/lib/gcc/i686-pc-linux-gnu/4.1.3/include /usr/include End of search list. GNU C version 4.1.3 20070222 (prerelease) (i686-pc-linux-gnu) compiled by GNU C version 3.4.4 20050721 (Red Hat 3.4.4-2). GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Compiler executable checksum: 3c763771770d7626aeca3ba678fea9f5 as -V -Qy -o /tmp/ccmkRFA6.o /tmp/cc6Cx7Y6.s GNU assembler version 2.15.92.0.2 (i386-redhat-linux) using BFD version 2.15.92.0.2 20040927 /tmp/bergner/install/gcc-4.1/libexec/gcc/i686-pc-linux-gnu/4.1.3/collect2 --eh-frame-hdr -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 /usr/lib/crt1.o /usr/lib/crti.o /tmp/bergner/install/gcc-4.1/lib/gcc/i686-pc-linux-gnu/4.1.3/crtbegin.o -L/tmp/bergner/install/gcc-4.1/lib/gcc/i686-pc-linux-gnu/4.1.3 -L/tmp/bergner/install/gcc-4.1/lib/gcc/i686-pc-linux-gnu/4.1.3/../../.. /tmp/ccmkRFA6.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /tmp/bergner/install/gcc-4.1/lib/gcc/i686-pc-linux-gnu/4.1.3/crtend.o /usr/lib/crtn.o -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30931
[Bug c/30916] Wrong �float� rather than �double� due to prototype warning
--- Comment #1 from manu at gcc dot gnu dot org 2007-02-23 14:08 --- What is your version of GCC ? -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30916
[Bug fortran/30793] [4.1 only] Segfault on calling a function returning a pointer
--- Comment #15 from burnus at gcc dot gnu dot org 2007-02-23 14:12 --- Subject: Bug 30793 Author: burnus Date: Fri Feb 23 14:12:44 2007 New Revision: 122256 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122256 Log: fortran/ 2007-02-23 Tobias Burnus [EMAIL PROTECTED] PR fortran/30793 * trans-decl.c (gfc_generate_function_code): Do not initialize pointers to derived components. testsuite/ 2007-02-23 Tobias Burnus [EMAIL PROTECTED] PR fortran/30793 * gfortran.dg/func_derived_4.f90: New test. Added: branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/func_derived_4.f90 Modified: branches/gcc-4_2-branch/gcc/fortran/ChangeLog branches/gcc-4_2-branch/gcc/fortran/trans-decl.c branches/gcc-4_2-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30793
[Bug rtl-optimization/30931] [4.1 Regression] Simple test case loops infinitely with -O1 -fstrength-reduce.
--- Comment #7 from rguenth at gcc dot gnu dot org 2007-02-23 14:13 --- Confirmed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |NEW Ever Confirmed|0 |1 GCC build triplet|i686-linux | GCC host triplet|i686-linux | GCC target triplet|i686-linux |i?86-*-* Keywords||wrong-code Known to fail||4.0.0 4.0.4 4.1.0 4.1.2 Known to work||3.4.6 4.2.0 Last reconfirmed|-00-00 00:00:00 |2007-02-23 14:13:03 date|| Summary|Simple test case loops |[4.1 Regression] Simple test |infinitely with -O1 - |case loops infinitely with - |fstrength-reduce. |O1 -fstrength-reduce. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30931
[Bug rtl-optimization/30931] [4.1 Regression] Simple test case loops infinitely with -O1 -fstrength-reduce.
--- Comment #8 from bergner at gcc dot gnu dot org 2007-02-23 14:17 --- Created an attachment (id=13097) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13097action=view) Good assembly output from the 4.1 compiler (-O1 -fno-strength-reduce) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30931
[Bug rtl-optimization/30931] [4.1 Regression] Simple test case loops infinitely with -O1 -fstrength-reduce.
--- Comment #9 from bergner at gcc dot gnu dot org 2007-02-23 14:17 --- Created an attachment (id=13098) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13098action=view) Bad assembly output from the 4.1 compiler (-O1 -fstrength-reduce) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30931
[Bug c/30916] Wrong �float� rather than �double� due to prototype warning
--- Comment #2 from manu at gcc dot gnu dot org 2007-02-23 14:21 --- I think the warning is correct. If there were no prototype, the value would be passed as double. Since there is a prototype, the value is passed as float. That is what -Wconversion warns about up to GCC 4.2 (check the manual for the description of Wconversion). Since GCC 4.3, those warnings have been moved to Wtraditional-conversion and Wconversion has a new purpose. More info: http://gcc.gnu.org/wiki/NewWconversion (Please, notice that the project is not finished yet, so things may change before GCC 4.3 is released). Please, let us know if this answers your question, so we can close this bug report. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30916
[Bug c++/29433] using boost::MPL requires lots of memory
--- Comment #23 from rguenth at gcc dot gnu dot org 2007-02-23 14:21 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29433
[Bug rtl-optimization/30931] [4.1 Regression] Simple test case loops infinitely with -O1 -fstrength-reduce.
--- Comment #10 from bonzini at gnu dot org 2007-02-23 14:30 ---
No, i (which is in %edx) *is* being incremented. It's the strength-reduced
derived induction variable that is constructed in a wrong way. The optimized
code looks like:
void bug (struct s *p)
{
int i;
struct s *pp = p;
for (i=0; i 2; i++)
{
goto loop_cond;
loop:
/* ??? I think gcc assumes that pp (%eax) is an induction variable of
the inner loop... */
pp[-1].first = 0;
loop_cond:
if (!pp[0].first)
goto break_out_of_inner_loop;
if (pp[0].done)
goto loop;
break_out_of_inner_loop;
pp++; /* actually adds sizeof (struct s) in the asm code */
i++;
}
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30931
[Bug bootstrap/30853] warnings about traditional.c during bootstrap with -O3, leading to internal error
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-02-23 14:30 --- Still, I find it a bit scary installing gcc without first bootstrapping it. I trust the result more than without it. --enable-bootstrap is not the flag which enables bootstrap but instead it enables toplevel bootstrap which is not supported in 4.1.x. make bootstrap without --enable-bootstrap will do a normal bootstrap and should just work. So closing as invalid. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30853
[Bug target/30934] gcc: Internal error: Segmentation fault (program as)
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-02-23 14:32 --- gcc: Internal error: Segmentation fault (program as) the assembler is seg faulting and not really the compiler. Can you add -save-temps and attach the resulting .i file? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Component|c |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30934
[Bug rtl-optimization/30931] [4.1 Regression] Simple test case loops infinitely with -O1 -fstrength-reduce.
--- Comment #11 from bonzini at gnu dot org 2007-02-23 14:32 --- for (i=0; i 2; i++) Well, that's obviously for (i=0; i 2; ) in my code of comment #10. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30931
[Bug libgcj/17002] java.util.TimeZone.getDefault() is broken
--- Comment #7 from gary at gcc dot gnu dot org 2007-02-23 15:13 --- Subject: Bug 17002 Author: gary Date: Fri Feb 23 15:13:18 2007 New Revision: 122258 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122258 Log: 2007-02-22 Jakub Jelinek [EMAIL PROTECTED] PR libgcj/17002 PR classpath/28550 * java/util/VMTimeZone.java (getDefaultTimeZoneId): To read /etc/localtime, use ZoneInfo.readTZFile instead of VMTimeZone.readtzFile. Get better timezone name for /etc/localtime, either if it is a symlink or through /etc/sysconfig/clock. (readSysconfigClockFile): New static method. (readtzFile): Removed. * java/lang/System.java: Add gnu.java.util.zoneinfo.dir to comments. * posix.cc (_Jv_platform_initProperties): Set gnu.java.util.zoneinfo.dir. * sources.am (gnu_java_util_source_files): Add classpath/gnu/java/util/ZoneInfo.java. * Makefile.in: Regenerated. * java/util/VMTimeZone.h: Regenerated. * java/util/TimeZone.h: Regenerated. * gnu/java/util/ZoneInfo.h: Generated. Modified: trunk/libjava/classpath/lib/gnu/java/util/ZoneInfo.class trunk/libjava/classpath/lib/java/lang/System$EnvironmentCollection.class trunk/libjava/classpath/lib/java/lang/System$EnvironmentMap.class trunk/libjava/classpath/lib/java/lang/System$EnvironmentSet.class trunk/libjava/classpath/lib/java/lang/System.class trunk/libjava/classpath/lib/java/util/Date.class trunk/libjava/classpath/lib/java/util/GregorianCalendar.class trunk/libjava/classpath/lib/java/util/SimpleTimeZone.class trunk/libjava/classpath/lib/java/util/TimeZone$1.class trunk/libjava/classpath/lib/java/util/TimeZone.class trunk/libjava/classpath/lib/java/util/VMTimeZone.class -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17002
[Bug tree-optimization/30911] VRP fails to eliminate range checks in Ada code
--- Comment #22 from rguenth at gcc dot gnu dot org 2007-02-23 15:15 --- Ok, I get lot's of acats failures with the patch, all of the form RUN a22006d raised CONSTRAINT_ERROR : a-textio.adb:1339 explicit raise FAIL: a22006d which is from procedure Set_Col (File : File_Type; To : Positive_Count) is ch : int; begin -- Raise Constraint_Error if out of range value. The reason for this -- explicit test is that we don't want junk values around, even if -- checks are off in the caller. if not To'Valid then raise Constraint_Error; end if; (so it seems like we have a rts miscompilation or a rts error somewhere) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30911
[Bug c/30935] New: Wrong evaluation result
The following C program evaluates t.a to a *wrong* value of 5 instead of 9:
#include stdio.h
struct test {
int a;
};
int func(struct test* tp) {
tp-a = 8; /* this update is lost */
return 1;
}
int main(int ac, char** av) {
struct test t;
t.a = 4;
t.a += func(t); /* t.a (=4) already loaded into a CPU register? */
printf(t.a=%d , t.a);
if (t.a == 9) {
printf(OK\n);
return 0;
} else {
printf(BAD\n);
return 1;
}
}
# gcc bad_eval.c ./a.out
t.a=5 BAD
The machine is a Fedora Core 6 Linux x86_64 box.
# uname -a
Linux titan 2.6.16-1.2080_FC5 #1 SMP Tue Mar 28 03:38:47 EST 2006 x86_64 x86_64
x86_64 GNU/Linux
# gcc -v
Using built-in specs.
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-libgcj-multifile
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk
--disable-dssi --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre
--with-cpu=generic --host=x86_64-redhat-linux
Thread model: posix
gcc version 4.1.0 20060304 (Red Hat 4.1.0-3)
--
Summary: Wrong evaluation result
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jrr at concept dot de
GCC build triplet: x86_64-redhat-linux
GCC host triplet: x86_64-redhat-linux
GCC target triplet: x86_64-redhat-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30935
[Bug c/30935] Wrong evaluation result
--- Comment #1 from jrr at concept dot de 2007-02-23 15:19 --- Created an attachment (id=13099) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13099action=view) Initial test case showing the bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30935
[Bug c/30935] Wrong evaluation result
--- Comment #2 from jrr at concept dot de 2007-02-23 15:22 --- (In reply to comment #0) The machine is a Fedora Core 6 Linux x86_64 box. Sorry, I meant Fedora Core release 5 (Bordeaux) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30935
[Bug c/30916] Wrong �float� rather than �double� due to prototype warning
--- Comment #3 from hermantenbrugge at home dot nl 2007-02-23 15:26 --- Subject: Re: Wrong =?windows-1252?Q?=91float=92_rather_?= =?windows-1252?Q?than_=91double=92_due_to_prototype_warning?= manu at gcc dot gnu dot org wrote: --- Comment #2 from manu at gcc dot gnu dot org 2007-02-23 14:21 --- I think the warning is correct. If there were no prototype, the value would be passed as double. Since there is a prototype, the value is passed as float. That is what -Wconversion warns about up to GCC 4.2 (check the manual for the description of Wconversion). Since GCC 4.3, those warnings have been moved to Wtraditional-conversion and Wconversion has a new purpose. More info: http://gcc.gnu.org/wiki/NewWconversion (Please, notice that the project is not finished yet, so things may change before GCC 4.3 is released). Please, let us know if this answers your question, so we can close this bug report. Yes. This answers the question. Sorry about the noise. I was testing this with gcc version 4.1.1 20070105 (Red Hat 4.1.1-51) on fedora core 6. When I use gcc version 4.3.0 20070222 (experimental). The problem goes away. So the problem report can be closed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30916
[Bug c/30935] Wrong evaluation result
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-02-23 15:36 --- *** This bug has been marked as a duplicate of 11751 *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30935
[Bug c/11751] wrong evaluation order of an expression
--- Comment #73 from rguenth at gcc dot gnu dot org 2007-02-23 15:36 --- *** Bug 30935 has been marked as a duplicate of this bug. *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||jrr at concept dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11751
[Bug c/30936] New: const attribute in nanf prototype causes gcc not producing correct code.
Being nanf declared using const attribute, sh4-linux-gcc (4.1.1) doesn't produce the code to call the nanf function. Removing the 'const' attribute the generated code works fine. Using gcc (3.4.3) Red Hat EL4 the test runs fine. -- Summary: const attribute in nanf prototype causes gcc not producing correct code. Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: filippo dot arcidiacono at gmail dot com GCC host triplet: i686-pc-linux-gnu GCC target triplet: sh4-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30936
[Bug tree-optimization/30911] VRP fails to eliminate range checks in Ada code
--- Comment #23 from baldrick at free dot fr 2007-02-23 15:40 --- Subject: Re: VRP fails to eliminate range checks in Ada code if not To'Valid then I'm pretty sure that this is an example of PR26797: the front-end should generate 'Valid by doing a VIEW_CONVERT_EXPR of To to its base type, and then checking whether that is in the right range. But what it often does right now is simply check whether To is in TYPE_MIN_VALUE .. TYPE_MAX_VALUE using an if statement. Of course VRP eliminates that. This is exactly PR26797, and needs to be fixed in the Ada f-e. That said, maybe I should explain about 'Valid. How can a variable have a value that is not in range? One answer is: because it is uninitialized. Another way is provided by the language: there is a technique for assigning from one variable to another without a range check, called unchecked conversion. If the result is out of range, then the behaviour you get if you use it is undefined. Finally, there are some other funky situations which can be thought of as equivalent to a use of unchecked conversion. Anyway, the language provides exactly one way to check if a variable is in range: using 'Valid. So the 'Valid check must stop the optimizers from optimizing away the check based on the known range. The technique that seems to have been agreed on is to use VIEW_CONVERT_EXPR, but unfortunately the front-end doesn't seem to always use that right now. So this is not a problem with your patch as such. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30911
[Bug c/30936] const attribute in nanf prototype causes gcc not producing correct code.
--- Comment #1 from filippo dot arcidiacono at gmail dot com 2007-02-23 15:43 --- Created an attachment (id=13100) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13100action=view) simple test case exploiting gcc bug compiled with the following command: sh4-linux-gcc nanf-test.c -D_GNU_SOURCE -o nanf-test -lm -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30936
[Bug fortran/30887] %VAL only accepts default-kind integer/real/complex
--- Comment #7 from p dot w dot draper at durham dot ac dot uk 2007-02-23 15:44 --- Tried out the patch and it works for me under 64bit with default sized integers. Seems to have fixed PR 30888 too. Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30887
[Bug libgcj/17002] java.util.TimeZone.getDefault() is broken
--- Comment #8 from cvs-commit at developer dot classpath dot org
2007-02-23 15:50 ---
Subject: Bug 17002
CVSROOT:/cvsroot/classpath
Module name:classpath
Changes by: Gary Benson gbenson 07/02/23 15:50:04
Modified files:
. : ChangeLog NEWS
java/lang : System.java
java/util : Date.java SimpleTimeZone.java TimeZone.java
vm/reference/java/util: VMTimeZone.java
Added files:
gnu/java/util : ZoneInfo.java
Log message:
2007-02-23 Gary Benson [EMAIL PROTECTED]
Jakub Jelinek [EMAIL PROTECTED]
PR libgcj/17002
PR classpath/28550
* java/util/Date.java (parse): Properly parse 09:01:02 as
hours/minutes/seconds, not as hours/minutes/year.
* java/util/SimpleTimeZone.java (SimpleTimeZone): Simplify
{start,end}TimeMode constructor by calling shorter constructor,
set {start,end}TimeMode fields after it returns.
(setStartRule): Don't adjust startTime into WALL_TIME. Set
startTimeMode to WALL_TIME.
(endStartRule): Similarly.
(getOffset): Handle properly millis + dstOffset overflowing
into the
next day. Adjust startTime resp. endTime based on
startTimeMode
resp. endTimeMode.
* java/util/TimeZone.java (zoneinfo_dir, availableIDs,
aliases0): New
static fields.
(timezones): Remove synchronized keyword. Set zoneinfo_dir.
If non-null, set up aliases0 and don't put anything into
timezones0.
(defaultZone): Call getTimeZone instead of timezones().get.
(getDefaultTimeZone): Fix parsing of EST5 or EST5EDT6. Use
getTimeZoneInternal instead of timezones().get.
(parseTime): Parse correctly hour:minute.
(getTimeZoneInternal): New private method.
(getTimeZone): Do the custom ID checking first, canonicalize
ID for custom IDs as required by documentation. Call
getTimeZoneInternal to handle the rest.
(getAvailableIDs(int)): Add locking. Handle zoneinfo_dir !=
null.
(getAvailableIDs(File,String,ArrayList)): New private method.
(getAvailableIDs()): Add locking. Handle zoneinfo_dir != null.
* vm/reference/java/util/VMTimeZone.java
(getDefaultTimeZoneId):
To read /etc/localtime, use ZoneInfo.readTZFile instead of
VMTimeZone.readtzFile. Get better timezone name for
/etc/localtime, either if it is a symlink or through
/etc/sysconfig/clock.
(readSysconfigClockFile): New static method.
(readtzFile): Removed.
* gnu/java/util/ZoneInfo.java: New file.
* java/lang/System.java: Add gnu.java.util.zoneinfo.dir to
comments.
* NEWS: Documented TimeZone interface changes.
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/classpath/ChangeLog?cvsroot=classpathr1=1.9128r2=1.9129
http://cvs.savannah.gnu.org/viewcvs/classpath/NEWS?cvsroot=classpathr1=1.177r2=1.178
http://cvs.savannah.gnu.org/viewcvs/classpath/gnu/java/util/ZoneInfo.java?cvsroot=classpathrev=1.1
http://cvs.savannah.gnu.org/viewcvs/classpath/java/lang/System.java?cvsroot=classpathr1=1.59r2=1.60
http://cvs.savannah.gnu.org/viewcvs/classpath/java/util/Date.java?cvsroot=classpathr1=1.25r2=1.26
http://cvs.savannah.gnu.org/viewcvs/classpath/java/util/SimpleTimeZone.java?cvsroot=classpathr1=1.31r2=1.32
http://cvs.savannah.gnu.org/viewcvs/classpath/java/util/TimeZone.java?cvsroot=classpathr1=1.36r2=1.37
http://cvs.savannah.gnu.org/viewcvs/classpath/vm/reference/java/util/VMTimeZone.java?cvsroot=classpathr1=1.4r2=1.5
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17002
[Bug bootstrap/30853] warnings about traditional.c during bootstrap with -O3, leading to internal error
--- Comment #4 from sdack at gmx dot de 2007-02-23 15:52 --- Subject: Re: warnings about traditional.c during bootstrap with -O3, leading to internal error Still, I find it a bit scary installing gcc without first bootstrapping it. I trust the result more than without it. --enable-bootstrap is not the flag which enables bootstrap but instead it enables toplevel bootstrap which is not supported in 4.1.x. make bootstrap without --enable-bootstrap will do a normal bootstrap and should just work. So closing as invalid. Of course I ran make with bootstrap and with profiledbootstrap. It still fails to compile with a BOOT_CFLAGS set to -O3. Since this is the section for reporting bugs and problems with bootstrap, please explain to me why you changed the severity from major to minor. When you tell me not to use the option at all I consider it to be broken and that is surely not a minor problem! I still fail to bootstrap with -O3. Please explain why you close the report as being invalid. Sven -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30853
[Bug tree-optimization/30911] VRP fails to eliminate range checks in Ada code
--- Comment #24 from rguenth at gcc dot gnu dot org 2007-02-23 15:55 --- Of course in this case I would have expected VRP or whatever to optimize away if not To'Valid then raise Constraint_Error; end if; but it looks it is now an unconditional raise Constraint_Error; btw - I failed to manually re-build a file from the rts, what do I need to do this? (I tried with -gnatpg but that just complains in different ways than without -gnatpg) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30911
[Bug tree-optimization/30911] VRP fails to eliminate range checks in Ada code
--- Comment #25 from baldrick at free dot fr 2007-02-23 15:59 --- Subject: Re: VRP fails to eliminate range checks in Ada code There seems to be an additional C testsuite failure: loadpre1.c Also, some of the acats failures look interesting, for example the first one c34004a is showing a real problem. I will try to analyze it later. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30911
[Bug tree-optimization/30911] VRP fails to eliminate range checks in Ada code
--- Comment #26 from baldrick at free dot fr 2007-02-23 16:01 --- Subject: Re: VRP fails to eliminate range checks in Ada code Of course in this case I would have expected VRP or whatever to optimize away if not To'Valid then raise Constraint_Error; end if; but it looks it is now an unconditional raise Constraint_Error; Some of the other tests are showing similar behaviour. btw - I failed to manually re-build a file from the rts, what do I need to do this? (I tried with -gnatpg but that just complains in different ways than without -gnatpg) What does it complain about with -gnatpg? Without it, it probably complains that you are not allowed to compile children of package Ada, or something like that. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30911
[Bug tree-optimization/30911] VRP fails to eliminate range checks in Ada code
--- Comment #28 from rguenth at gcc dot gnu dot org 2007-02-23 16:11
---
Got it compiling now with -gnatpg -- my tree was probably too old and messed
up, rebuilding everything helped. Now we indeed fold not To'Valid to 1 ;)
Unfolded
it looks like
if (to == 0 || (SIGNED_32) to 0)
{
__gnat_rcheck_04 (a-textio.adb, 1339);
}
I'll try to get my hands on what goes wrong, but a small testcase resembling
the
above part would be nice to have ;)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30911
[Bug target/30825] [4.3 Regression] current mainline fails to bootstrap when -msse is used
--- Comment #5 from rth at gcc dot gnu dot org 2007-02-23 16:12 --- Subject: Re: [4.3 Regression] current mainline fails to bootstrap when -msse is used On Fri, Feb 23, 2007 at 01:54:35PM -, ubizjak at gmail dot com wrote: * config/i386/i386.md (*movdi_1_rex64, zero_extendsidi2_32, zero_extendsidi2_rex64): Penalize MMX register-memory moves. (*movsf_1): Penalize MMX moves. Ok. I guess I really need to get around to disabling mmx when it's not supposed to be used. r~ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30825
[Bug fortran/30933] intrinsic: EXIT
-- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||burnus at gcc dot gnu dot ||org AssignedTo|unassigned at gcc dot gnu |burnus at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-02-23 16:45:28 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30933
[Bug bootstrap/30914] Bootstrap fails on HP-UX
--- Comment #2 from info at icomsoftware dot de 2007-02-23 16:55 --- I have installed a precompiled binary. You can close this bug. -- info at icomsoftware dot de changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30914
[Bug tree-optimization/30911] VRP fails to eliminate range checks in Ada code
--- Comment #29 from baldrick at free dot fr 2007-02-23 17:09 --- Subject: Re: VRP fails to eliminate range checks in Ada code BTW, this is not a bug, but a possible enhancement, and a very tricky one at that, since removing too many checks will hurt much more Ada programmers than having too many, so let's please be extra careful here. Yes - vrp has potentially massive effects on Ada code. These effects can be good, even wonderful, if done right, but the slightest mistake could cause bad bad trouble. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30911
[Bug middle-end/28690] [4.2/4.3 Regression] Performace problem with indexed load/stores on powerpc
--- Comment #36 from bergner at gcc dot gnu dot org 2007-02-23 17:14 --- Created an attachment (id=13101) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13101action=view) Alternate patch to commutative_operand_precedence to increase the precedence of REG_POINTER and MEM_POINTER objects. With help from Honza, this updated patch eliminates the ICE the previous patch hit. -- bergner at gcc dot gnu dot org changed: What|Removed |Added Attachment #13042|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28690
[Bug tree-optimization/30911] VRP fails to eliminate range checks in Ada code
--- Comment #30 from rguenth at gcc dot gnu dot org 2007-02-23 17:32 --- Ok, I have too little Ada skills ;) What is missing in the following? with test; package test is type Count is range 0 .. Natural'Last; subtype Positive_Count is Count range 1 .. Count'Last; procedure Set_Col (To : Positive_Count); end test; procedure Set_Col (To : Positive_Count) is begin if not To'Valid then raise Constraint_Error; end if; end Set_Col; $ gnatchop -w Set_Col.adb splitting Set_Col.adb into: test.ads set_col.adb $ gnatmake set_col.adb gcc-4.1 -c set_col.adb set_col.ads:2:25: Positive_Count is undefined (more references follow) gnatmake: set_col.adb compilation error -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30911
[Bug c/30936] const attribute in nanf prototype causes gcc not producing correct code.
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-02-23 17:39 --- Being nanf declared using const attribute Can you attach the preprocessed source which you can get by adding -save-temps to the command line? The file will be called something.i. Also can you compile with -W -Wall as I think really nanf is not being prototyped which means this is not a GCC issue. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30936
[Bug other/30756] Daily bump in branches/gcc-4_0-branch/libstdc++-v3/include/bits/c++config
--- Comment #1 from andreas dot meier_ at gmx dot de 2007-02-23 17:56 --- This happens until now -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30756
[Bug bootstrap/30669] i686-pc-linux-gnu doesn't build
--- Comment #4 from b33fc0d3 at gmail dot com 2007-02-23 17:58 --- I'm still getting an ICE when trying to bootstrap on x86_64: /var/tmp/portage/dev-java/gcj-4.3.0_alpha20070216/work/gcc-4.3-20070216/libgcc/../gcc/libgcc2.c: In function '__multi3': /var/tmp/portage/dev-java/gcj-4.3.0_alpha20070216/work/gcc-4.3-20070216/libgcc/../gcc/libgcc2.c:566: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See URL:http://bugs.gentoo.org/ for instructions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30669
[Bug fortran/30933] intrinsic: EXIT
--- Comment #5 from patchapp at dberlin dot org 2007-02-23 18:05 --- Subject: Bug number PR30933 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-02/msg01902.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30933
[Bug fortran/30910] [Regression 4.2, 4.3] Gfortran: ES format not quite right...
--- Comment #11 from jvdelisle at gcc dot gnu dot org 2007-02-23 18:13 --- Subject: Bug 30910 Author: jvdelisle Date: Fri Feb 23 18:13:16 2007 New Revision: 122265 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122265 Log: 2007-02-23 Jerry DeLisle [EMAIL PROTECTED] PR libgfortran/30910 * io/write.c (output_float): Add condition of format F only for special case rounding with zero precision. Modified: branches/gcc-4_2-branch/libgfortran/ChangeLog branches/gcc-4_2-branch/libgfortran/io/write.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30910
[Bug fortran/30910] [Regression 4.2, 4.3] Gfortran: ES format not quite right...
--- Comment #12 from jvdelisle at gcc dot gnu dot org 2007-02-23 18:15 --- Subject: Bug 30910 Author: jvdelisle Date: Fri Feb 23 18:15:27 2007 New Revision: 122266 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122266 Log: 2007-02-23 Jerry DeLisle [EMAIL PROTECTED] PR libgfortran/30910 * gfortran.dg/fmt_zero_precision.f90: Update test. Modified: branches/gcc-4_2-branch/gcc/testsuite/ChangeLog branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/fmt_zero_precision.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30910
[Bug fortran/30681] obsolescent vs. obsolete
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2007-02-23 18:17 --- Subject: Bug 30681 Author: jvdelisle Date: Fri Feb 23 18:16:54 2007 New Revision: 122267 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122267 Log: 2007-02-23 Jerry DeLisle [EMAIL PROTECTED] PR fortran/30681 * options.c (set_default_std_flags): New function to consolidate setting the flags. Relax warning level for obsolescent. (gfc_init_options): Use new function. (gfc_handle_option): Use new function. * match.c (match_arithmetic_if): Change to obsolescent from deleted. (gfc_match_if): Same. Modified: branches/gcc-4_2-branch/gcc/fortran/ChangeLog branches/gcc-4_2-branch/gcc/fortran/match.c branches/gcc-4_2-branch/gcc/fortran/options.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30681
[Bug target/30825] [4.3 Regression] current mainline fails to bootstrap when -msse is used
--- Comment #6 from uros at gcc dot gnu dot org 2007-02-23 18:19 --- Subject: Bug 30825 Author: uros Date: Fri Feb 23 18:19:07 2007 New Revision: 122268 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122268 Log: PR target/30825 * config/i386/i386.md (*movdi_1_rex64, zero_extendsidi2_32, zero_extendsidi2_rex64): Penalize MMX register-memory moves. (*movsf_1): Penalize MMX moves. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.md -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30825
[Bug fortran/30681] obsolescent vs. obsolete
--- Comment #9 from jvdelisle at gcc dot gnu dot org 2007-02-23 18:20 --- Subject: Bug 30681 Author: jvdelisle Date: Fri Feb 23 18:20:01 2007 New Revision: 122269 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122269 Log: 2007-02-23 Jerry DeLisle [EMAIL PROTECTED] PR fortran/30681 * gfortran.dg/pr17229.f: Change Obsolete to Obsolescent. Modified: branches/gcc-4_2-branch/gcc/testsuite/ChangeLog branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/pr17229.f -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30681
[Bug target/30825] [4.3 Regression] current mainline fails to bootstrap when -msse is used
--- Comment #7 from ubizjak at gmail dot com 2007-02-23 18:20 --- Fixed on mainline. -- ubizjak at gmail dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30825
[Bug fortran/30910] [Regression 4.2, 4.3] Gfortran: ES format not quite right...
--- Comment #13 from jvdelisle at gcc dot gnu dot org 2007-02-23 18:26 --- Subject: Bug 30910 Author: jvdelisle Date: Fri Feb 23 18:26:23 2007 New Revision: 122270 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122270 Log: 2007-02-23 Jerry DeLisle [EMAIL PROTECTED] PR libgfortran/30910 * io/write.c (output_float): Add condition of format F only for special case rounding with zero precision. Modified: branches/gcc-4_1-branch/libgfortran/ChangeLog branches/gcc-4_1-branch/libgfortran/io/write.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30910
[Bug fortran/30910] [Regression 4.2, 4.3] Gfortran: ES format not quite right...
--- Comment #14 from jvdelisle at gcc dot gnu dot org 2007-02-23 18:31 --- Subject: Bug 30910 Author: jvdelisle Date: Fri Feb 23 18:30:57 2007 New Revision: 122271 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122271 Log: 2007-02-23 Jerry DeLisle [EMAIL PROTECTED] PR libgfortran/30910 * gfortran.dg/fmt_zero_precision.f90: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/fmt_zero_precision.f90 Modified: branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30910
[Bug fortran/30910] [Regression 4.2, 4.3] Gfortran: ES format not quite right...
--- Comment #15 from jvdelisle at gcc dot gnu dot org 2007-02-23 18:35 --- Fixed on 4.1, 4.2, and 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=30910
[Bug fortran/30681] obsolescent vs. obsolete
--- Comment #10 from jvdelisle at gcc dot gnu dot org 2007-02-23 18:37 --- Fixed on 4.2 and 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=30681
[Bug libgcj/30937] New: Win32: Process.exitValue() does not work after multiple calls to a terminated process
After calling process.waitFor(), or calling process.exitValue() multiple times
on a process that has exited, the process returns
java.lang.IllegalThreadStateException: Process has not exited even though it
has. Sun's java, and gcj on linux does not have this problem.
Result on SUN win32:
5
EV: 5 [EMAIL PROTECTED]
EV: 5 [EMAIL PROTECTED]
Result on GCJ 4.2 Win: (probably 4.3 as well since it doesn't look changed in
viewcvs):
5
X: java.lang.IllegalThreadStateException: Process has not exited
X: java.lang.IllegalThreadStateException: Process has not exited
Snippet:
import java.io.FileOutputStream;
import java.io.PrintStream;
public class ProcTest {
static Process process;
public static void main(String[] args) {
try {
String bat = exitcode.bat;
PrintStream p = new PrintStream(new FileOutputStream(bat));
p.println(@exit 5);
p.close();
process = Runtime.getRuntime().exec(bat);
try {
int wf = process.waitFor();
System.err.println(wf);
} catch (InterruptedException e) {
}
try {
int ev = process.exitValue();
System.err.println(EV: + ev + + process);
} catch (IllegalThreadStateException ile) {
System.err.println(X: + ile);
}
try {
int ev = process.exitValue();
System.err.println(EV: + ev + + process);
} catch (IllegalThreadStateException ile) {
System.err.println(X: + ile);
}
} catch (Exception e) {
e.printStackTrace();
}
}
}
--
Summary: Win32: Process.exitValue() does not work after multiple
calls to a terminated process
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgcj
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: r_ovidius at eml dot cc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30937
[Bug tree-optimization/30938] New: Bootstrap fails on x86_64 for -ftree-vectorize
-ftree-vectorize bootstrap segfaults on x86_64 in: 0x0098ecf9 in vect_is_simple_use (operand=0x2aaab01533c0, loop_vinfo=0x156f0b0, def_stmt=0x7fff4264e488, def=0x7fff4264e490, dt=0x7fff4264e488) at ../../gcc-svn/trunk/gcc/tree-vectorizer.c:1729 1729 switch (TREE_CODE (*def_stmt)) (gdb) bt #0 0x0098ecf9 in vect_is_simple_use (operand=0x2aaab01533c0, loop_vinfo=0x156f0b0, def_stmt=0x7fff4264e488, def=0x7fff4264e490, dt=0x7fff4264e488) at ../../gcc-svn/trunk/gcc/tree-vectorizer.c:1729 #1 0x00cf8b95 in vectorizable_call (stmt=0x2ee70ed0, bsi=0x0, vec_stmt=0x0) at ../../gcc-svn/trunk/gcc/tree-vect-transform.c:1847 #2 0x00ce602d in vect_analyze_operations (loop_vinfo=0x156f0b0) at ../../gcc-svn/trunk/gcc/tree-vect-analyze.c:376 #3 0x00ced78d in vect_analyze_loop (loop=0x156f480) at ../../gcc-svn/trunk/gcc/tree-vect-analyze.c:2727 #4 0x00990d90 in vectorize_loops () at ../../gcc-svn/trunk/gcc/tree-vectorizer.c:2217 #5 0x00919053 in tree_vectorize () at ../../gcc-svn/trunk/gcc/tree-ssa-loop.c:183 This failure happens when compiling i386.c, in function classify_argument. To reproduce this failure, run make with BOOT_CFLAGS=-O2 -ftree-vectorize. -- Summary: Bootstrap fails on x86_64 for -ftree-vectorize Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: build Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ubizjak at gmail dot com GCC build triplet: x86_64-pc-linux-gnu GCC host triplet: x86_64-pc-linux-gnu GCC target triplet: x86_64-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30938
[Bug tree-optimization/30938] Bootstrap fails on x86_64 for -ftree-vectorize
--- Comment #1 from ubizjak at gmail dot com 2007-02-23 20:16 --- This is the operand that is not liked by vect_is_simple_use(): (gdb) p debug_tree (operand) ssa_name 0x2aaab01533c0 type enumeral_type 0x2edc0b40 x86_64_reg_class sizes-gimplified unsigned type_0 SI size integer_cst 0x2dff1ab0 constant invariant 32 unit size integer_cst 0x2dff1720 constant invariant 4 align 32 symtab 0 alias set 16 canonical type 0x2edc0b40 precision 32 min integer_cst 0x2dff1ae0 0 max integer_cst 0x2dff1a80 4294967295 values tree_list 0x2edc3150 purpose identifier_node 0x2edbf780 X86_64_NO_CLASS value integer_cst 0x2e00e540 constant invariant 0 chain tree_list 0x2edc31b0 purpose identifier_node 0x2edbf7e0 X86_64_INTEGER_CLASS value integer_cst 0x2e00e570 constant invariant 1 chain tree_list 0x2edc3210 purpose identifier_node 0x2edbf840 X86_64_INTEGERSI_CLASS value integer_cst 0x2e0250c0 constant invariant 2 chain tree_list 0x2edc3270 purpose identifier_node 0x2edbf8a0 X86_64_SSE_CLASS value integer_cst 0x2e025120 constant invariant 3 chain tree_list 0x2edc32d0 purpose identifier_node 0x2edbf900 X86_64_SSESF_CLASS value integer_cst 0x2e025180 4 chain tree_list 0x2edc3330 context translation_unit_decl 0x2edd81a0 D.49546 pointer_to_this pointer_type 0x2ec5ab40 chain type_decl 0x2ed66d00 D.33440 visited var var_decl 0x2ee64580 D.34839 def_stmt gimple_modify_stmt 0x2ee70e40 version 243 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30938
[Bug tree-optimization/30911] VRP fails to eliminate range checks in Ada code
--- Comment #31 from rguenth at gcc dot gnu dot org 2007-02-23 20:18 --- Created an attachment (id=13102) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13102action=view) patch updated patch -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Attachment #13096|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30911
[Bug bootstrap/30669] i686-pc-linux-gnu doesn't build
--- Comment #5 from ubizjak at gmail dot com 2007-02-23 20:21 --- (In reply to comment #4) I'm still getting an ICE when trying to bootstrap on x86_64: /var/tmp/portage/dev-java/gcj-4.3.0_alpha20070216/work/gcc-4.3-20070216/libgcc/../gcc/libgcc2.c: In function '__multi3': Try to build in empty directory. I have just finished bootstrap on x86_64-pc-linux-gnu for all default languages and everything went normal: ./xgcc -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ../gcc-svn/trunk/configure Thread model: posix gcc version 4.3.0 20070223 (experimental) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30669
[Bug fortran/30372] various intrinsics do not diagnose invalid argument kinds
--- Comment #7 from burnus at gcc dot gnu dot org 2007-02-23 20:42 --- various intrinsics do not diagnose invalid argument kinds The question is what is the right solution: a) Only allow certain kinds b) Allowing all kinds and doing the conversion/providing the needed functions. (a) is in the spirit of Fortran 95, which allowed only the default kind for a lot of arguments to intrinsic procedures (b) is in the spirit of Fortran 2003 which lifted a lot of those restrictions. For legacy intrinsics we have the choice, but I favour option (b). -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||burnus at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30372
[Bug libgcj/30937] Win32: Process.exitValue() does not work after multiple calls to a terminated process
--- Comment #1 from r_ovidius at eml dot cc 2007-02-23 20:53 ---
Also seems to affect process.destroy() somehow. The DONE is not printed
after the destroy call on gcj win32, but is on Sun.
public class ProcTest {
static Process process;
public static void main(String[] args) {
try {
String bat = exitcode.bat;
PrintStream p = new PrintStream(new FileOutputStream(bat));
p.println(@exit 5);
p.close();
process = Runtime.getRuntime().exec(bat);
try {
int wf = process.waitFor();
System.err.println(wf);
} catch (InterruptedException e) {
}
try {
int ev = process.exitValue();
System.err.println(EV: + ev + + process);
} catch (IllegalThreadStateException ile) {
System.err.println(X: + ile);
}
try {
int ev = process.exitValue();
System.err.println(EV: + ev + + process);
} catch (IllegalThreadStateException ile) {
System.err.println(X: + ile);
}
process.destroy();
System.err.println(DONE);
} catch (Exception e) {
e.printStackTrace();
}
}
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30937
[Bug fortran/30793] Segfault on calling a function returning a pointer
--- Comment #16 from burnus at gcc dot gnu dot org 2007-02-23 20:53 --- Fixed in 4.2 and the trunk. Allocatable components are not in 4.1 and thus this bug fix cannot be ported to 4.1. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Summary|[4.1 only] Segfault on |Segfault on calling a |calling a function returning|function returning a pointer |a pointer | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30793
[Bug fortran/30372] various intrinsics do not diagnose invalid argument kinds
--- Comment #8 from sgk at troutmask dot apl dot washington dot edu 2007-02-23 21:02 --- Subject: Re: various intrinsics do not diagnose invalid argument kinds On Fri, Feb 23, 2007 at 08:42:03PM -, burnus at gcc dot gnu dot org wrote: various intrinsics do not diagnose invalid argument kinds The question is what is the right solution: a) Only allow certain kinds b) Allowing all kinds and doing the conversion/providing the needed functions. (a) is in the spirit of Fortran 95, which allowed only the default kind for a lot of arguments to intrinsic procedures (b) is in the spirit of Fortran 2003 which lifted a lot of those restrictions. For legacy intrinsics we have the choice, but I favour option (b). I agree that (b) is perhaps the best option. Afterall, we are moving forward in time so gfortran will chase F2003 (and F2008). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30372
[Bug fortran/30939] New: Report if dummy array sizes is larger than actual array size
NAG f95: Error: bar.f90, line 6: Array supplied for dummy IN (no. 1) of COPY too small g95: Error: Array argument at (1) is smaller than the dummy size gfortran: No error/warning. -- program main implicit none character :: digit_arr(10) call copy(digit_arr) contains subroutine copy(in) character, dimension(11) :: in, out end subroutine copy end program main -- Note: The other way round is ok, i.e. actual = 1:10, dummy = 1:8 -- Summary: Report if dummy array sizes is larger than actual array size Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: diagnostic Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30939
[Bug fortran/30940] New: Fortran 2003: Scalar CHARACTER supplied to array dummy
The following valid program is rejected by gfortran with the error: Type/rank mismatch in argument 'in' - program main implicit none character(len=10) :: digit_string = '123456789' character :: digit_arr(10) call copy(digit_string, digit_arr) print '(1x, a1)',digit_arr(1:9) contains subroutine copy(in, out) character, dimension(10) :: in, out out(1:10) = in(1:10) end subroutine copy end program main - The program compiles with g95 -std=f2003 and NAG f95 -f2003. They give for -std=f95 and no -f2003 the warning/error: Error: Cannot pass scalar to array argument 'in' Extension: bar.f90, line 5: Scalar CHARACTER supplied for dummy IN of COPY I think this is somewhere embedded in section 12.4.1.5 Sequence association of the Fortran 2003 standard. If the actual argument is of type default character or of type character with the C character kind, and is an array expression, array element, or array element substring designator, the element sequence consists of the storage units beginning with the first storage unit of the actual argument and continuing to the end of the array. The storage units of an array element substring designator are viewed as array elements consisting of consecutive groups of storage units having the character length of the dummy array. If the actual argument is of type default character or of type character with the C character kind, and is a scalar that is not an array element or array element substring designator, the element sequence consists of the storage units of the actual argument. An actual argument that represents an element sequence and corresponds to a dummy argument that is an array is sequence associated with the dummy argument if the dummy argument is an explicit-shape or assumed-size array. The rank and shape of the actual argument need not agree with the rank and shape of the dummy argument, but the number of elements in the dummy argument shall not exceed the number of elements in the element sequence of the actual argument. If the dummy argument is assumed-size, the number of elements in the dummy argument is exactly the number of elements in the element sequence. -- Summary: Fortran 2003: Scalar CHARACTER supplied to array dummy Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: rejects-valid Severity: enhancement Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30940
[Bug fortran/30941] New: intrinsic: FLUSH
1. The name of the dummy argument is COUNT instead of UNIT. 2. FLUSH implements option (iii) of Tobias' list in [1], but (i) was agreed upon (at least for EXIT) 3. The documentation states: UNIT (Optional) The type shall be INTEGER. Be more specific here. [1] http://gcc.gnu.org/ml/fortran/2007-02/msg00538.html -- Summary: intrinsic: FLUSH Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dfranke at gcc dot gnu dot org OtherBugsDependingO 30932 nThis: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30941
[Bug fortran/30941] intrinsic: FLUSH
--- Comment #1 from dfranke at gcc dot gnu dot org 2007-02-23 22:28 ---
libgfortran/io/intrinsics.c provides flush_i8, but that one is never used.
INTEGER(kind=8) :: i8
CALL FLUSH(i8)
results in
MAIN__ ()
{
int8 int_8;
_gfortran_set_std (70, 127, 0, 0);
{
int4 D.1001;
D.1001 = (int4) int_8;
_gfortran_flush_i4 (D.1001);
}
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30941
[Bug tree-optimization/30911] VRP fails to eliminate range checks in Ada code
--- Comment #32 from rguenth at gcc dot gnu dot org 2007-02-23 22:40 --- Created an attachment (id=13103) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13103action=view) patch Bah - now with the errors fixed. Bootstraps ok, some of acats regresses. If you disable bootstrap and run the testsuite you get FAIL: c340001 FAIL: c35507j FAIL: c390001 FAIL: c390005 FAIL: c390006 FAIL: c390a01 FAIL: c390a02 FAIL: c390a03 FAIL: c954012 FAIL: c96005a FAIL: c96005d FAIL: c96005f FAIL: c96006a FAIL: c96007a FAIL: c96008a FAIL: c96008b FAIL: c974002 FAIL: cc51007 FAIL: cd92001 FAIL: ce3305a FAIL: ce3402c FAIL: ce3405a FAIL: ce3405d FAIL: ce3409c FAIL: ce3410c FAIL: ce3602a FAIL: ce3605d FAIL: ce3605e FAIL: ce3606a FAIL: ce3606b FAIL: ce3706f FAIL: ce3806e FAIL: ce3806h FAIL: ce3906a FAIL: ce3906e FAIL: ce3906f FAIL: cxh1001 FAIL: ee3203a FAIL: ee3402b Most of the are either raised CONSTRAINT_ERROR : a-calend.adb:440 explicit raise or raised CONSTRAINT_ERROR : a-textio.adb:1511 explicit raise With bootstrapping the compiler and then checking you get FAIL: c35507j FAIL: cd92001 FAIL: cxh1001 I guess that nearly all range checks are eliminated and without bootstrapping we have a disconnect between the redundant checks in the rts and the testcases. If it happens that the non-bootstrapped rts is built by the host compiler(?). -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Attachment #13102|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30911
[Bug fortran/30942] New: Can't find keyword: error marker always at end of line
$ cat link-flush-2.f90 program subroutine_flush_link INTEGER(kind=1) :: int_1 CALL flush(unit = int_1) ! this is a somewhat lengthy comment end program $ gfortran-svn link-flush-2.f90 link-flush-2.f90:4.60: CALL flush(unit = int_1) ! this is a somewhat lengthy comment 1 Error: Can't find keyword named 'unit' in call to 'flush' at (1) $ gfortran-svn gcc version 4.3.0 20070212 (experimental) -- Summary: Can't find keyword: error marker always at end of line Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: diagnostic Severity: enhancement Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dfranke at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30942
[Bug tree-optimization/30930] [4.3 Regression] vector can cause to create an extra variable
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-02-23 22:47 --- (In reply to comment #1) I believe the mini-pre-alias passes from honza will fix this by recomputing addressability. But this is not about recomputing addressability but instead recomputing DECL_GIMPLE_REG_P which we don't do currently. We could do it the same time as we recompute addressability and I think we should. I will go look into this futher later today. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30930
[Bug fortran/30941] intrinsic: FLUSH
--- Comment #2 from dfranke at gcc dot gnu dot org 2007-02-23 22:58 --- The problem described in comment #1 depends on the default integer kind. See also: http://gcc.gnu.org/ml/fortran/2007-02/msg00542.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30941
[Bug middle-end/30143] [4.2 only] OpenMP can produce invalid gimple
--- Comment #13 from pinskia at gcc dot gnu dot org 2007-02-23 23:01 --- Fixed. -- 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=30143
[Bug fortran/30943] New: Compiler Crash while compiling GNU Octave
The compiler encouraged me to write this bugreport. My gcc-Version: [EMAIL PROTECTED]:~$ gcc --version gcc (GCC) 4.0.3 (Ubuntu 4.0.3-1ubuntu5) My f77-Version: [EMAIL PROTECTED]:~$ g77 --version GNU Fortran (GCC) 3.4.6 (Ubuntu 3.4.6-1ubuntu2) Copyright (C) 2006 Free Software Foundation, Inc. The bug itself: While make(ing) GNU Octave 2.9.9 the following occured: g77 -c -fPIC -O -mieee-fp dorgbr.f -o pic/dorgbr.o *** glibc detected *** corrupted double-linked list: 0x084f0290 *** In file included from dorgbr.f:0: dorgbr.f:245: interner Compiler-Fehler: Aborted Please submit a full bug report,... This bug isn't reproducable. Compiling again works. -- Summary: Compiler Crash while compiling GNU Octave Product: gcc Version: 4.0.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: martin at lawitzky dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30943
[Bug target/30770] [4.3 regression] BOOT_CFLAGS=-O2 -g -mtune=nocona miscompiled the stage 3 compiler
--- Comment #4 from h dot mth at web dot de 2007-02-23 23:29 --- JFYI, '-O2 -march=athlon64' also fails. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30770
[Bug libstdc++/25896] [DR 526] hash_map::erase, unordered_map::erase fail if key is inside the table
--- Comment #6 from paolo at gcc dot gnu dot org 2007-02-23 23:34 --- Subject: Bug 25896 Author: paolo Date: Fri Feb 23 23:34:18 2007 New Revision: 122276 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122276 Log: 2007-02-23 Paolo Carlini [EMAIL PROTECTED] PR libstdc++/25896 * include/tr1/hashtable (_Hashtable::erase(const key_type)): Take care of _M_extract((*__slot)-_M_v) == __k. * testsuite/tr1/6_containers/unordered_map/erase/1.cc: New. * testsuite/tr1/6_containers/unordered_multimap/erase/1.cc: Likewise. * testsuite/tr1/6_containers/unordered_multiset/erase/1.cc: Likewise. * testsuite/tr1/6_containers/unordered_set/erase/1.cc: Likewise. Added: trunk/libstdc++-v3/testsuite/tr1/6_containers/unordered_map/erase/1.cc trunk/libstdc++-v3/testsuite/tr1/6_containers/unordered_multimap/erase/1.cc trunk/libstdc++-v3/testsuite/tr1/6_containers/unordered_multiset/erase/1.cc trunk/libstdc++-v3/testsuite/tr1/6_containers/unordered_set/erase/1.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/tr1/hashtable -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25896
[Bug libstdc++/25896] [DR 526] hash_map::erase, unordered_map::erase fail if key is inside the table
--- Comment #7 from pcarlini at suse dot de 2007-02-23 23:35 --- Fixed. -- 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=25896
[Bug fortran/30943] Compiler Crash while compiling GNU Octave
--- Comment #1 from kargl at gcc dot gnu dot org 2007-02-24 00:09 --- This crash is with g77, which is no longer support. -- kargl at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30943
[Bug debug/29614] [4.2/4.3 Regression] DWARF information for function static variable is missing after unrelated code addition
--- Comment #5 from sje at gcc dot gnu dot org 2007-02-24 00:11 --- Subject: Bug 29614 Author: sje Date: Sat Feb 24 00:11:39 2007 New Revision: 122277 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122277 Log: PR debug/29614 * varpool.c (varpool_assemble_pending_decls): Set varpool_last_needed_node to null. Modified: trunk/gcc/ChangeLog trunk/gcc/varpool.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29614
[Bug c++/30944] New: cstddef:54: internal compiler error: Segmentation fault
I received a segmentation fault when I tried to compile my code from Anjuta as well as from the make file created by Anjuta. Sorry, this is my first bug report and I am not sure what the triplets are. Let me know how to find that information and I will gladly supply it. -- Summary: cstddef:54: internal compiler error: Segmentation fault Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tdepuy at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30944
[Bug bootstrap/30495] can't compile on AIX
--- Comment #4 from dje at gcc dot gnu dot org 2007-02-24 04:42 --- The 4G is the cumulative allocation, not the total amount of memory currently in use. The problem has nothing to do with physical memory installed in the system. The process data and stack resource limits need to be larger to compile GCC. -- dje at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30495
[Bug c++/30945] New: iostream includes excessive headers - results in large files
On Bjarne Stroustrup's site, it's says in the FAQs: Why is the code generated for the Hello world program ten times larger for C++ than for C? It isn't on my machine, and it shouldn't be on yours. I have even seen the C++ version of the hello world program smaller than the C version. When I recently (2004) tested using gcc -o2 on a Unix, the two versions (iostreams and stdio) yielded identical sizes. There is no language reason why the one version should be larger than the other. It is all an issue on how the implementor organized the libraries. If one version is significantly larger than the other, report the problem to the implementor of the larger. __ Perhaps unnecessary files are being included in iostream. These files should NOT be over 400 KB. In fact, a standard Win32 header compiles to a smaller file. -- Summary: iostream includes excessive headers - results in large files Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rosenwad at bxscience dot edu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30945
[Bug c++/30946] New: classes and structs are interchangeable?
The following will compile with no problem.
___
class character
{
//bah
};
struct character enemy;
___
So will
___
struct character
{
//bah
};
class character enemy;
___
--
Summary: classes and structs are interchangeable?
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rosenwad at bxscience dot edu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30946
