[Bug ada/27776] ICE on limited with and instantiation
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2006-05-28 09:18 --- Confirmed, Gigi is not prepared for this kind of circularity. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ebotcazou at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-05-27 08:54:39 |2006-05-28 09:18:07 date|| Summary|Ada ICE when instatiating a |ICE on limited with and |'limited with'ed access type|instantiation http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27776
[Bug c/27781] New: weak-attribute over-optimisation with 4.1
file-a.c:
-
void __attribute__((weak)) func(void)
{
/* no code */
}
main()
{
func();
}
file-b.c:
-
void func(void)
{
printf("func\n");
}
# gcc -c file-a.c file-b.c -O2
# gcc -o program file-a.o file-b.o
The program will not print "func", because the call to func() was optimised out
during the compilation of file-a.c. This happens with -O2, but not when using
-fno-unit-at-a-time. First sighted in 4.1.
--
Summary: weak-attribute over-optimisation with 4.1
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jan dot kiszka at web dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27781
[Bug bootstrap/27782] New: Bootstrap failure with -msse2 -ftree-vectorize
There is a problem in data dependence analysis that breaks bootstrap with -ftree-vectorize (or any other flag that causes find_data_references_in_loop to be called): stage1/xgcc -Bstage1/ -B/usr/local/i686-pc-linux-gnu/bin/ -c -g -O2 -msse2 -ftree-vectorize -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wmissing-format-attribute -Werror -fno-common -DHAVE_CONFIG_H -I. -I. -I../../gcc/gcc -I../../gcc/gcc/. -I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include -I../../gcc/gcc/../libdecnumber -I../libdecnumber../../gcc/gcc/recog.c -o recog.o ../../gcc/gcc/recog.c: In function âconstrain_operandsâ: ../../gcc/gcc/recog.c:2273: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. #0 0x0830b9ba in fold_convert (type=0x0, arg=0x402f57f8) at fold-const.c:1991 #1 0x0861768f in chrec_convert_1 (type=0x0, chrec=0x402f57f8, at_stmt=0x409361b0, use_overflow_semantics=1 '\001') at tree-chrec.c:1268 #2 0x0861738d in chrec_convert (type=0x0, chrec=0x402f57f8, at_stmt=0x409361b0) at tree-chrec.c:1225 #3 0x0862a6ce in create_data_ref (memref=0x40929d98, stmt=0x409361b0, is_read=1 '\001') at tree-data-ref.c:1960 #4 0x08632bc8 in find_data_references_in_loop (loop=0x88b5998, datarefs=0x89e988c) at tree-data-ref.c:4050 #5 0x086338e1 in compute_data_dependences_for_loop (loop=0x88b5998, compute_self_and_read_read_dependences=0 '\0', datarefs=0x89e988c, dependence_relations=0x89e9890) at tree-data-ref.c:4189 #6 0x081c38c2 in vect_analyze_data_refs (loop_vinfo=0x89e9868) at tree-vect-analyze.c:1336 #7 0x081c571d in vect_analyze_loop (loop=0x88b5998) at tree-vect-analyze.c:1999 #8 0x081c0672 in vectorize_loops (loops=0x88f9f18) at tree-vectorizer.c:2040 #9 0x081ac9fb in tree_vectorize () at tree-ssa-loop.c:193 ... (gdb) fr 3 #3 0x0862a6ce in create_data_ref (memref=0x40929d98, stmt=0x409361b0, is_read=1 '\001') at tree-data-ref.c:1960 1960 init_cond = chrec_convert (chrec_type (access_fn), init_cond, stmt); (gdb) call debug_generic_stmt (access_fn) scev_not_known; -- Summary: Bootstrap failure with -msse2 -ftree-vectorize Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rakdver at gcc dot gnu dot org GCC host triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27782
[Bug fortran/27655] ICE on invalid use of NULL as an argument to ASSOCIATED
--- Comment #1 from pault at gcc dot gnu dot org 2006-05-28 09:45 --- Created an attachment (id=11523) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11523&action=view) Patch to fix bug I will submit this tonight; regtests on FC5/Athlon1700 Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27655
[Bug preprocessor/27783] New: Garbage at end of #include line ignored
The following malformed program is not diagnosed: #include "stdio.h" "bar" -Chris -- Summary: Garbage at end of #include line ignored Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: preprocessor AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sabre at nondot dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27783
[Bug tree-optimization/26242] [4.1/4.2 Regression] VRP is not documented in passes.texi
--- Comment #4 from steven at gcc dot gnu dot org 2006-05-28 09:50 --- It is sad that this is not release critical, and even worse that the contributor of vrp apparently can't miss half an hour to document his work as he is required to do. -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-05-28 09:50:22 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26242
[Bug middle-end/24434] [4.0/4.1/4.2 Regression] get_varargs_alias_set returns 0 always
--- Comment #4 from steven at gcc dot gnu dot org 2006-05-28 09:53 --- This looks like one that the mem-ssa folks may want to give a look. Will it be easier in mem-ssa to attach alias info to INDIRECT_REF nodes? -- steven at gcc dot gnu dot org changed: What|Removed |Added CC||dnovillo at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24434
[Bug c++/27771] inlined return not optimized, overfullfills ABI calling convention
--- Comment #4 from familie dot glaser at web dot de 2006-05-28 10:12 --- Right, but this only shows that the "value tracking" based optimization works very well. The volatile crap is used to point out an example for situations in which the optimizer must loose the values track. This regular happens with I/O and controler-registers. -- familie dot glaser at web dot de changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27771
[Bug libfortran/27784] New: Comparison of strings with char(0)
$ cat string_null_compare_1.f program main character*3 str1, str2 call setval(str1, str2) if (str1 == str2) print *,'Should be unqual' end subroutine setval(str1, str2) character*3 str1, str2 str1 = 'a' // CHAR(0) // 'a' str2 = 'a' // CHAR(0) // 'c' end $ gfortran string_null_compare_1.f $ ./a.out Should be unqual $ g77 string_null_compare_1.f $ ./a.out $ -- Summary: Comparison of strings with char(0) Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tkoenig at gcc dot gnu dot org OtherBugsDependingO 19292 nThis: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27784
[Bug fortran/27655] ICE on invalid use of NULL as an argument to ASSOCIATED
-- pault at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-05-28 11:47:26 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27655
[Bug c++/27771] inlined return not optimized, overfullfills ABI calling convention
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-05-28 11:50 --- Then provide a real testcase please. With this report nothing is going to be done because in the testcase, the volatiles are just "crap". -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27771
[Bug c/27781] [4.1/4.2 Regression] weak-attribute over-optimisation
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-05-28 12:03 --- ipa-pure-const thinks that func is const, which is wrong. Then DCE comes along and deletes the function call. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||wrong-code Last reconfirmed|-00-00 00:00:00 |2006-05-28 12:03:59 date|| Summary|weak-attribute over-|[4.1/4.2 Regression] weak- |optimisation with 4.1 |attribute over-optimisation Target Milestone|--- |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27781
[Bug fortran/27765] -fbounds-check gives undue warning with
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2006-05-28 12:07 --- (In reply to comment #3) > FX, Are you comming to the GCC summit? Well, my employer has nothing to do with gfortra, so I won't be coming. But if you ever come to Paris, I'll offer you a beer! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27765
[Bug fortran/27703] Linking example programs for PLplot causes error messages about multiple definition of __gfortran_transfer_character
--- Comment #3 from pault at gcc dot gnu dot org 2006-05-28 12:11 --- Arjen, > I tried this with gfortran 4.20 too (the report file was indeed > created with 4.1, but the result with the newer version was quite the > same). It happens when I build version 5.6.1 of PLplot (http://plplot.sf.net) > using shared libraries. It does not when I disable the shared libraries > option. If you go well back into last year on the gfortran list, you will find some corespondence on shared libraries and Cygwin. I do not recall the exact details but there was something very iffy about the mixture of fortran IO, shared libraries and Cygwin. I think that you might have to stick with a static build. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27703
[Bug fortran/27470] [4.1 regression] wrong memory allocator for derived types
--- Comment #11 from tkoenig at gcc dot gnu dot org 2006-05-28 12:33 --- (In reply to comment #10) > > Not committing right now. Downloading a fresh version via svn cured that problem. I'd have commited the patch by now, but for some strange reason, I get "Authentication failed" errors with svn, and my E-Mails to the gcc and fortran mailing lists also don't go through. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27470
[Bug fortran/26801] -fbounds-check generates segfault
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2006-05-28 13:23
---
I tried with the following reduced testcase:
implicit none
integer :: i
logical :: l
type dt
integer, pointer :: a => null()
end type dt
type(dt), pointer :: obj(:) => null()
allocate(obj(2))
i = 1
l = associated(obj(i)%a)
print *, l
end
The code generated for the ASSOCIATED statement is the following when
bounds-checking is disabled:
i = 1;
l = (*(struct dt[0:] *) obj.data)[obj.dim[0].stride * i + obj.offset].a !=
0B;
When bounds-checking is enabled, it is changed into:
i = 1;
{
int4 D.924;
l = (*(struct dt[0:] *) obj.data)[obj.dim[0].stride * D.924 + obj.offset].a
!= 0B;
}
Notice that D.924 is used uninitialized. The -fbounds-check options gives a
special codepath in three occasions:
0x080ad083 in gfc_conv_ss_startstride (loop=0xbfa1813c)
at ../../../trunk/gcc/fortran/trans-array.c:2456
2456 if (flag_bounds_check)
(gdb) c
Continuing.
Hardware read watchpoint 1: flag_bounds_check
Value = 1
0x080acc2c in gfc_conv_array_ref (se=0xbfa17ab4, ar=0x87222bc)
at ../../../trunk/gcc/fortran/trans-array.c:1951
1951 if (flag_bounds_check && ar->as->type != AS_ASSUMED_SIZE)
(gdb)
Continuing.
Hardware read watchpoint 1: flag_bounds_check
Value = 1
0x080acd5c in gfc_conv_array_ref (se=0xbfa17ab4, ar=0x87222bc)
at ../../../trunk/gcc/fortran/trans-array.c:1980
1980 if (flag_bounds_check)
I don't understand where this D.924 variable is generated.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
CC||fxcoudert at gcc dot gnu dot
||org
Last reconfirmed|2006-03-22 21:22:10 |2006-05-28 13:23:39
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26801
[Bug fortran/27786] New: Bad interaction between Cray pointer, assumed-size array and bounds checking
This reduced testcase is originally from the testsuite gfortran.dg/cray_pointers_2.f90. It generates an incorrect out-of-bounds error message when run with bounds-checking enabled. $ cat cray_pointers_2.f90 integer targ(2) integer pte pointer(ptr,pte(*)) ptr = loc(targ) targ(2) = -1 print *, pte(2) end $ gfortran -fbounds-check -fcray-pointer cray_pointers_2.f90 && ./a.out Fortran runtime error: Array reference out of bounds -- Summary: Bad interaction between Cray pointer, assumed-size array and bounds checking Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: fxcoudert at gcc dot gnu dot org OtherBugsDependingO 27766 nThis: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27786
[Bug c/27781] [4.1/4.2 Regression] weak-attribute over-optimisation
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-05-28 14:00 --- I have a patch. -- 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 Last reconfirmed|2006-05-28 12:03:59 |2006-05-28 14:00:23 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27781
[Bug libfortran/27784] Comparison of strings with char(0)
-- tkoenig at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |tkoenig at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-05-28 14:04:28 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27784
[Bug fortran/25147] passing variable in place of function dummy argument not caught
--- Comment #2 from pault at gcc dot gnu dot org 2006-05-28 14:09 --- Created an attachment (id=11524) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11524&action=view) Patch for the bug exposed by the fix to this and PR25098 The patch for pr25098 fixes this bug but exposes another. module integrator interface function integrate(f,xmin,xmax) implicit none interface function f(x) real*8 :: f,x intent(in) :: x end function f end interface real*8 :: xmin, xmax, integrate end function integrate end interface end module integrator use integrator real*8, external :: f real*8 g print *,integrate (f,0d0,3d0) print *,integrate (g,0d0,3d0) end gives [EMAIL PROTECTED] prs]# /svn-4.1/bin/gfortran pr25147.f90 In file pr25147.f90:21 print *,integrate (f,0d0,3d0) 1 Error: Type/rank mismatch in argument 'f' at (1) ie. It generates an error for OK code and doesn't catch the incorrect code! The patch for PR25098 corrects the latter but still emits the Type/rank error. The attached patch combines that for PR25098 and passes the correct code. I will prepare a testcase and submit tonight. BTW It regtests on FC5/Athlon1700 I hope that the thesis is coming along, Tobi? Cheers Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25147
[Bug tree-optimization/22041] Reverse loop order for increased efficiency
--- Comment #4 from tkoenig at gcc dot gnu dot org 2006-05-28 14:10 --- (In reply to comment #3) > Dunno if tree loop reversal is already there, but Zdenek probably likes to > know > what bugs he is fixing... Loop reversal doesn't occur yet. gcc version 4.2.0 20060521 (experimental) gives us: L4: movl(%ecx), %eax addl$1, %ebx addl%edi, %ecx movl%eax, (%edx) addl%esi, %edx cmpl16(%ebp), %ebx jne L4 -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added Last reconfirmed|2005-12-24 20:30:10 |2006-05-28 14:10:44 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22041
[Bug ada/27769] cross-gnatmake needs host gcc
--- Comment #12 from berndtrog at yahoo dot com 2006-05-28 14:10 --- > --- Comment #11 from laurent at guerby dot net 2006-05-27 18:41 --- > Bernd, could you contribute (attach here) your Makefile and ada RTS changes so > that Ada build with AVR target succeeds? Since I don't like to have mutiple copies of the same thing around, I'd rather provide only a link into AVR-Ada repo.: http://svn.sourceforge.net/viewcvs.cgi/avr-ada/trunk/patches/ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27769
[Bug tree-optimization/22041] Reverse loop order for increased efficiency
--- Comment #5 from rakdver at atrey dot karlin dot mff dot cuni dot cz 2006-05-28 14:25 --- Subject: Re: Reverse loop order for increased efficiency > --- Comment #4 from tkoenig at gcc dot gnu dot org 2006-05-28 14:10 > --- > (In reply to comment #3) > > Dunno if tree loop reversal is already there, but Zdenek probably likes to > > know > > what bugs he is fixing... > > Loop reversal doesn't occur yet. > > gcc version 4.2.0 20060521 (experimental) gives us: > > L4: > movl(%ecx), %eax > addl$1, %ebx > addl%edi, %ecx > movl%eax, (%edx) > addl%esi, %edx > cmpl16(%ebp), %ebx > jne L4 loop reversal was removed with the old loop optimizer; the tree level loop reversal patch (http://gcc.gnu.org/ml/gcc-patches/2006-01/msg01851.html) was not reviewed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22041
[Bug fortran/27715] Extented ASCII characters lead to wrong "CASE" selection
--- Comment #2 from tkoenig at gcc dot gnu dot org 2006-05-28 14:53 ---
It's even worse:
$ cat cmp.f
program main
external isgreater
logical isgreater
print *,"a" > "ä"
print *,isgreater("a", "ä")
end
logical function isgreater(s1, s2)
character*1 s1, s2
isgreater = s1 > s2
end
$ gfortran cmp.f
$ ./a.out
T
F
The front end comparison is done using C's native char, whereas
the back end uses strncmp (or memcpy to fix PR 27784, hopefully soon),
which treats chars as unsigned.
Naturally, this leads to breakage when the native char type is signed.
Oh well... this doesn't look too hard to fix. The front end should
use unsigned char.
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu dot
||org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27715
[Bug c++/27771] inlined return not optimized, overfullfills ABI calling convention
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-05-28 15:20 --- volatile makes all the optimizations turn off for that variable which means nothing is going to happen. This is not a bug, if you can find a testcase without volatile, please file a new bug. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27771
[Bug middle-end/27781] [4.1/4.2 Regression] weak-attribute over-optimisation
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-05-28 15:23 --- Actually no, you have to use -fPIC to get this not to be optimized, otherwise func will be bound locally which is not what you want. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c |middle-end http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27781
[Bug fortran/25098] Variable as actual argument for procedure dummy argument allowed
--- Comment #3 from patchapp at dberlin dot org 2006-05-28 15:37 --- Subject: Bug number PR25098 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/2006-05/msg01425.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25098
[Bug bootstrap/27782] Bootstrap failure with -msse2 -ftree-vectorize
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-05-28 15:47 --- *** This bug has been marked as a duplicate of 27331 *** -- 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=27782
[Bug tree-optimization/27331] [4.2 Regression] segfault in fold_convert with -ftree-vectorize
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-05-28 15:47 --- *** Bug 27782 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||rakdver at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27331
[Bug libfortran/27784] Comparison of strings with char(0)
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2006-05-28 15:49 --- What about simply doing: Index: intrinsics/string_intrinsics.c === --- intrinsics/string_intrinsics.c (revision 113849) +++ intrinsics/string_intrinsics.c (working copy) @@ -109,7 +109,7 @@ const char *s; int len; - res = strncmp (s1, s2, (len1 < len2) ? len1 : len2); + res = memcmp (s1, s2, (len1 < len2) ? len1 : len2); if (res != 0) return res; I was told that using memcmp is safe without checking it in configury, because it is present in libiberty if not in the system. -- 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=27784
[Bug fortran/27715] Extented ASCII characters lead to wrong "CASE" selection
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2006-05-28 15:59 --- Created an attachment (id=11525) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11525&action=view) Proposed patch I'm tempted to propose the attached patch. It makes the front-end ultimately use unsigned chars to do the comparison, and also removes the use of the reverse ASCII collating table for this, because I don't understand how it is supposed to be useful :) Opinions? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27715
[Bug libfortran/27784] Comparison of strings with char(0)
--- Comment #2 from tkoenig at gcc dot gnu dot org 2006-05-28 16:05 --- (In reply to comment #1) > What about simply doing: > > Index: intrinsics/string_intrinsics.c > === > --- intrinsics/string_intrinsics.c (revision 113849) > +++ intrinsics/string_intrinsics.c (working copy) > @@ -109,7 +109,7 @@ >const char *s; >int len; > > - res = strncmp (s1, s2, (len1 < len2) ? len1 : len2); > + res = memcmp (s1, s2, (len1 < len2) ? len1 : len2); >if (res != 0) > return res; Yes, this works. I actually regtested and submitted this, but somehow E-Mail to the fortran mailing list has been broken for me. Mabe the E-Mail will appear a bit later. In the meantime, this patch is approved :-) Thomas -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27784
[Bug middle-end/26622] [4.0/4.1 Regression] ICE in extract_insn, at recog.c:2084
--- Comment #12 from kazu at gcc dot gnu dot org 2006-05-28 16:06 --- Subject: Bug 26622 Author: kazu Date: Sun May 28 16:06:36 2006 New Revision: 114167 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114167 Log: gcc/ PR tree-optimization/26622. * fold-const.c (fold_ternary) : Call fold_convert on arg1. gcc/testsuite/ PR tree-optimization/26622. * gcc.c-torture/compile/pr26622.c: New. Added: branches/gcc-4_1-branch/gcc/testsuite/gcc.c-torture/compile/pr26622.c Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/fold-const.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26622
[Bug middle-end/26622] [4.0 Regression] ICE in extract_insn, at recog.c:2084
--- Comment #13 from kazu at gcc dot gnu dot org 2006-05-28 16:07 --- Now fixed on 4.1.2 and on. -- kazu at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.0/4.1 Regression] ICE in |[4.0 Regression] ICE in |extract_insn, at|extract_insn, at |recog.c:2084|recog.c:2084 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26622
[Bug fortran/27715] Extented ASCII characters lead to wrong "CASE" selection
--- Comment #4 from tkoenig at gcc dot gnu dot org 2006-05-28 16:10 ---
(In reply to comment #3)
> Created an attachment (id=11525)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11525&action=view) [edit]
> Proposed patch
>
> I'm tempted to propose the attached patch. It makes the front-end ultimately
> use unsigned chars to do the comparison, and also removes the use of the
> reverse ASCII collating table for this, because I don't understand how it is
> supposed to be useful :)
What about using
struct
{
int length;
unsigned char *string;
}
character;
in gfc_expr? There would be a few fallout issues in
other places (I assume some "char *" pointers would have
to become "unsigned char*"), but it would be much cleaner overall.
As far as the collating sequence goes... should we eventually
support locales for sorting etc.? If so, we should leave the
code in.
in gfc
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27715
[Bug libfortran/27784] Comparison of strings with char(0)
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2006-05-28 16:28 --- (In reply to comment #2) > In the meantime, this patch is approved :-) No, your patch is approved! Please go ahead and commit :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27784
[Bug fortran/27715] Extented ASCII characters lead to wrong "CASE" selection
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2006-05-28 16:32 --- (In reply to comment #4) > unsigned char *string; Humpf, I don't know. I don't think it's the best course of action... too invasive. > As far as the collating sequence goes... should we eventually > support locales for sorting etc.? If so, we should leave the > code in. I think we don't want locales support in sorting with the default character kind, and if we ever want to implement that, I don't think we'll want to do it that way :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27715
[Bug fortran/27715] Extented ASCII characters lead to wrong "CASE" selection
--- Comment #6 from kargl at gcc dot gnu dot org 2006-05-28 16:52 --- Guys, Have you read 4.3.2.1.1? This defines the requirements on the collating of the default character type. It also defines the requirements on LGT, LGE, LLE, and LLT, which is why we use the ascii_table in simplify.c. Thomas' idea of using unsigned char does not conflict with 4.3.2.1.1. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27715
[Bug c++/27787] New: Qualified lookup fails to find inherited class template
// The code has been tested with GCC 3.4.2, 4.1.1 and 4.2.0 (alpha) and fails.
// It compiles successfully with Comeau (>= 4.2) and VisualC++ (>=7.1).
template
struct x
{
template
struct y
{
typedef Y type;
};
};
template
struct a : x
{
// supposed to fail (unqualified lookup does not look into dependent base)
// [ 14.6.2-3 ]
//
//template
//typename y::type f(B);
//
// qualified lookup should find inherited class template 'y', however
template
typename a::template y::type f(B);
};
--
Summary: Qualified lookup fails to find inherited class template
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tschwinger at neoscientists dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27787
[Bug c++/27787] Qualified lookup fails to find inherited class template
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-05-28 18:42 --- There is a defect report about this if a is really a dependent name or not (or maybe it is the one about inherite and template and name lookup I forget). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27787
[Bug c++/27787] Qualified lookup fails to find inherited class template
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-05-28 18:43 --- Replacing a with x, makes this work. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27787
[Bug c++/27787] Qualified lookup fails to find inherited class template
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-05-28 18:51 --- http://std.dkuug.dk/jtc1/sc22/wg21/docs/cwg_defects.html#213 And http://std.dkuug.dk/jtc1/sc22/wg21/docs/cwg_defects.html#108 Both seems a way to better understand this but I am confused with what the standard says with these two defect reports. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27787
[Bug preprocessor/27783] Garbage at end of #include line ignored
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-05-28 18:53 --- [kudzu:trunk/objdir/gcc] pinskia% ./xgcc -B. t.c t.c:1:20: warning: extra tokens at end of #include directive h. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27783
[Bug preprocessor/27783] Garbage at end of #include line ignored
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-05-28 18:55 --- This is a bug in Apple's GCC as I cannot reproduce it in the FSF released 3.4.0, 4.0.0, 4.1.0 or 4.2.0. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27783
[Bug preprocessor/27783] Garbage at end of #include line ignored
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-05-28 18:56 --- I should note I could reproduce it with Apple's GCC though. It has warned since 3.0.4, while 2.95.3 did: earth:~>~/ia32_linux_gcc2_95//bin/gcc t.c t.c:1: stdio.hbar: No such file or directory -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27783
[Bug c++/27665] [4.0/4.1/4.2 regression] ICE writing class instead of typename
--- Comment #2 from bangerth at dealii dot org 2006-05-28 18:58 --- (In reply to comment #0) > I'm not quite sure whether writing "class" before "A::B::C" is valid > or has to be replaced by "typename". This is the subject of DR 180. W. -- bangerth at dealii dot org changed: What|Removed |Added CC||bangerth at dealii dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27665
[Bug fortran/27757] [4.1/4.2 Regression] Problems with direct access io
--- Comment #13 from ray at ultramarine dot com 2006-05-28 19:06 --- Subject: Re: [4.1/4.2 Regression] Problems with direct access io On Sat, 28 May 2006, jvdelisle at gcc dot gnu dot org wrote: > > > --- Comment #12 from jvdelisle at gcc dot gnu dot org 2006-05-28 00:40 > --- > I am confirming this is a regression. The test program works fine on 4.0.2 > Thanks, I thought it had worked before but could not find out when! Ray -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27757
[Bug fortran/25746] Elemental assignment gives wrong result (fixed in trunk)
--- Comment #8 from pault at gcc dot gnu dot org 2006-05-28 19:47 --- Subject: Bug 25746 Author: pault Date: Sun May 28 19:46:22 2006 New Revision: 114173 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114173 Log: 2006-05-28 Paul Thomas <[EMAIL PROTECTED]> PR fortran/25082 * resolve.c (resolve_code): Add error condition that the return expression must be scalar. PR fortran/27411 * matchexp.c (gfc_get_parentheses): New function. (match_primary): Remove inline code and call above. * gfortran.h: Provide prototype for gfc_get_parentheses. * resolve.c (resolve_array_ref): Call the above, when start is a derived type variable array reference. PR fortran/27613 * primary.c (gfc_match_rvalue): Test if symbol represents a direct recursive function reference. Error if array valued, go to function0 otherwise. PR fortran/25746 * interface.c (gfc_extend_assign): Use new EXEC_ASSIGN_CALL. * gfortran.h : Put EXEC_ASSIGN_CALL in enum. * trans-stmt.c (gfc_conv_elemental_dependencies): New function. (gfc_trans_call): Call it. Add new boolian argument to flag need for dependency checking. Assert intent OUT and IN for arg1 and arg2. (gfc_trans_forall_1): Use new code EXEC_ASSIGN_CALL. trans-stmt.h : Modify prototype of gfc_trans_call. trans.c (gfc_trans_code): Add call for EXEC_ASSIGN_CALL. st.c (gfc_free_statement): Free actual for EXEC_ASSIGN_CALL. * dependency.c (gfc_check_fncall_dependency): Don't check other against itself. PR fortran/27584 * check.c (gfc_check_associated): Replace NULL assert with an error message, since it is possible to generate bad code that has us fall through to here.. PR fortran/19015 * iresolve.c (maxloc, minloc): If DIM is not present, pass the rank of ARRAY as the shape of the result. Otherwise, pass the shape of ARRAY, less the dimension DIM. (maxval, minval): The same, when DIM is present, otherwise no change. PR fortran/27709 * resolve.c (find_array_spec): Add gfc_symbol, derived, and use to track repeated component references. PR fortran/27155 PR fortran/27449 * trans-intrinsic.c (gfc_conv_intrinsic_array_transfer): Use se->string_length throughout and use memcpy to populate the expression returned to the scalarizer. (gfc_size_in_bytes): New function. * trans-intrinsic.c (gfc_conv_associated): If pointer in first arguments has zero array length of zero string length, return false. 2006-05-28 Paul Thomas <[EMAIL PROTECTED]> PR fortran/25082 * gfortran.dg/scalar_return_1.f90: New test. PR fortran/27411 * gfortran.dg/derived_comp_array_ref_1.f90: New test. PR fortran/25746 * gfortran.dg/elemental_subroutine_3.f90: New test. PR fortran/27584 * gfortran.dg/associated_target_1.f90: New test. PR fortran/19015 * gfortran.dg/maxloc_shape_1.f90: New test. PR fortran/27613 * gfortran.dg/recursive_reference_1.f90: New test. PR fortran/27709 * gfortran.dg/spec_expr_4.f90: New test. PR fortran/27155 * gfortran.dg/transfer_array_intrinsic_4.f90: New test. * gfortran.dg/associated_2.f90: New test. Modified: branches/gcc-4_1-branch/gcc/fortran/ChangeLog branches/gcc-4_1-branch/gcc/fortran/check.c branches/gcc-4_1-branch/gcc/fortran/gfortran.h branches/gcc-4_1-branch/gcc/fortran/interface.c branches/gcc-4_1-branch/gcc/fortran/iresolve.c branches/gcc-4_1-branch/gcc/fortran/matchexp.c branches/gcc-4_1-branch/gcc/fortran/primary.c branches/gcc-4_1-branch/gcc/fortran/resolve.c branches/gcc-4_1-branch/gcc/fortran/st.c branches/gcc-4_1-branch/gcc/fortran/trans-intrinsic.c branches/gcc-4_1-branch/gcc/fortran/trans-stmt.c branches/gcc-4_1-branch/gcc/fortran/trans-stmt.h branches/gcc-4_1-branch/gcc/fortran/trans.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25746
[Bug fortran/27155] Transfer of character to integer array and vice versa still doesn't work (fixed in trunk)
--- Comment #21 from pault at gcc dot gnu dot org 2006-05-28 19:47 --- Subject: Bug 27155 Author: pault Date: Sun May 28 19:46:22 2006 New Revision: 114173 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114173 Log: 2006-05-28 Paul Thomas <[EMAIL PROTECTED]> PR fortran/25082 * resolve.c (resolve_code): Add error condition that the return expression must be scalar. PR fortran/27411 * matchexp.c (gfc_get_parentheses): New function. (match_primary): Remove inline code and call above. * gfortran.h: Provide prototype for gfc_get_parentheses. * resolve.c (resolve_array_ref): Call the above, when start is a derived type variable array reference. PR fortran/27613 * primary.c (gfc_match_rvalue): Test if symbol represents a direct recursive function reference. Error if array valued, go to function0 otherwise. PR fortran/25746 * interface.c (gfc_extend_assign): Use new EXEC_ASSIGN_CALL. * gfortran.h : Put EXEC_ASSIGN_CALL in enum. * trans-stmt.c (gfc_conv_elemental_dependencies): New function. (gfc_trans_call): Call it. Add new boolian argument to flag need for dependency checking. Assert intent OUT and IN for arg1 and arg2. (gfc_trans_forall_1): Use new code EXEC_ASSIGN_CALL. trans-stmt.h : Modify prototype of gfc_trans_call. trans.c (gfc_trans_code): Add call for EXEC_ASSIGN_CALL. st.c (gfc_free_statement): Free actual for EXEC_ASSIGN_CALL. * dependency.c (gfc_check_fncall_dependency): Don't check other against itself. PR fortran/27584 * check.c (gfc_check_associated): Replace NULL assert with an error message, since it is possible to generate bad code that has us fall through to here.. PR fortran/19015 * iresolve.c (maxloc, minloc): If DIM is not present, pass the rank of ARRAY as the shape of the result. Otherwise, pass the shape of ARRAY, less the dimension DIM. (maxval, minval): The same, when DIM is present, otherwise no change. PR fortran/27709 * resolve.c (find_array_spec): Add gfc_symbol, derived, and use to track repeated component references. PR fortran/27155 PR fortran/27449 * trans-intrinsic.c (gfc_conv_intrinsic_array_transfer): Use se->string_length throughout and use memcpy to populate the expression returned to the scalarizer. (gfc_size_in_bytes): New function. * trans-intrinsic.c (gfc_conv_associated): If pointer in first arguments has zero array length of zero string length, return false. 2006-05-28 Paul Thomas <[EMAIL PROTECTED]> PR fortran/25082 * gfortran.dg/scalar_return_1.f90: New test. PR fortran/27411 * gfortran.dg/derived_comp_array_ref_1.f90: New test. PR fortran/25746 * gfortran.dg/elemental_subroutine_3.f90: New test. PR fortran/27584 * gfortran.dg/associated_target_1.f90: New test. PR fortran/19015 * gfortran.dg/maxloc_shape_1.f90: New test. PR fortran/27613 * gfortran.dg/recursive_reference_1.f90: New test. PR fortran/27709 * gfortran.dg/spec_expr_4.f90: New test. PR fortran/27155 * gfortran.dg/transfer_array_intrinsic_4.f90: New test. * gfortran.dg/associated_2.f90: New test. Modified: branches/gcc-4_1-branch/gcc/fortran/ChangeLog branches/gcc-4_1-branch/gcc/fortran/check.c branches/gcc-4_1-branch/gcc/fortran/gfortran.h branches/gcc-4_1-branch/gcc/fortran/interface.c branches/gcc-4_1-branch/gcc/fortran/iresolve.c branches/gcc-4_1-branch/gcc/fortran/matchexp.c branches/gcc-4_1-branch/gcc/fortran/primary.c branches/gcc-4_1-branch/gcc/fortran/resolve.c branches/gcc-4_1-branch/gcc/fortran/st.c branches/gcc-4_1-branch/gcc/fortran/trans-intrinsic.c branches/gcc-4_1-branch/gcc/fortran/trans-stmt.c branches/gcc-4_1-branch/gcc/fortran/trans-stmt.h branches/gcc-4_1-branch/gcc/fortran/trans.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27155
[Bug fortran/27411] crashes in sra_walk_expr and emit_move_insn (fixed in trunk)
--- Comment #9 from pault at gcc dot gnu dot org 2006-05-28 19:47 --- Subject: Bug 27411 Author: pault Date: Sun May 28 19:46:22 2006 New Revision: 114173 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114173 Log: 2006-05-28 Paul Thomas <[EMAIL PROTECTED]> PR fortran/25082 * resolve.c (resolve_code): Add error condition that the return expression must be scalar. PR fortran/27411 * matchexp.c (gfc_get_parentheses): New function. (match_primary): Remove inline code and call above. * gfortran.h: Provide prototype for gfc_get_parentheses. * resolve.c (resolve_array_ref): Call the above, when start is a derived type variable array reference. PR fortran/27613 * primary.c (gfc_match_rvalue): Test if symbol represents a direct recursive function reference. Error if array valued, go to function0 otherwise. PR fortran/25746 * interface.c (gfc_extend_assign): Use new EXEC_ASSIGN_CALL. * gfortran.h : Put EXEC_ASSIGN_CALL in enum. * trans-stmt.c (gfc_conv_elemental_dependencies): New function. (gfc_trans_call): Call it. Add new boolian argument to flag need for dependency checking. Assert intent OUT and IN for arg1 and arg2. (gfc_trans_forall_1): Use new code EXEC_ASSIGN_CALL. trans-stmt.h : Modify prototype of gfc_trans_call. trans.c (gfc_trans_code): Add call for EXEC_ASSIGN_CALL. st.c (gfc_free_statement): Free actual for EXEC_ASSIGN_CALL. * dependency.c (gfc_check_fncall_dependency): Don't check other against itself. PR fortran/27584 * check.c (gfc_check_associated): Replace NULL assert with an error message, since it is possible to generate bad code that has us fall through to here.. PR fortran/19015 * iresolve.c (maxloc, minloc): If DIM is not present, pass the rank of ARRAY as the shape of the result. Otherwise, pass the shape of ARRAY, less the dimension DIM. (maxval, minval): The same, when DIM is present, otherwise no change. PR fortran/27709 * resolve.c (find_array_spec): Add gfc_symbol, derived, and use to track repeated component references. PR fortran/27155 PR fortran/27449 * trans-intrinsic.c (gfc_conv_intrinsic_array_transfer): Use se->string_length throughout and use memcpy to populate the expression returned to the scalarizer. (gfc_size_in_bytes): New function. * trans-intrinsic.c (gfc_conv_associated): If pointer in first arguments has zero array length of zero string length, return false. 2006-05-28 Paul Thomas <[EMAIL PROTECTED]> PR fortran/25082 * gfortran.dg/scalar_return_1.f90: New test. PR fortran/27411 * gfortran.dg/derived_comp_array_ref_1.f90: New test. PR fortran/25746 * gfortran.dg/elemental_subroutine_3.f90: New test. PR fortran/27584 * gfortran.dg/associated_target_1.f90: New test. PR fortran/19015 * gfortran.dg/maxloc_shape_1.f90: New test. PR fortran/27613 * gfortran.dg/recursive_reference_1.f90: New test. PR fortran/27709 * gfortran.dg/spec_expr_4.f90: New test. PR fortran/27155 * gfortran.dg/transfer_array_intrinsic_4.f90: New test. * gfortran.dg/associated_2.f90: New test. Modified: branches/gcc-4_1-branch/gcc/fortran/ChangeLog branches/gcc-4_1-branch/gcc/fortran/check.c branches/gcc-4_1-branch/gcc/fortran/gfortran.h branches/gcc-4_1-branch/gcc/fortran/interface.c branches/gcc-4_1-branch/gcc/fortran/iresolve.c branches/gcc-4_1-branch/gcc/fortran/matchexp.c branches/gcc-4_1-branch/gcc/fortran/primary.c branches/gcc-4_1-branch/gcc/fortran/resolve.c branches/gcc-4_1-branch/gcc/fortran/st.c branches/gcc-4_1-branch/gcc/fortran/trans-intrinsic.c branches/gcc-4_1-branch/gcc/fortran/trans-stmt.c branches/gcc-4_1-branch/gcc/fortran/trans-stmt.h branches/gcc-4_1-branch/gcc/fortran/trans.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27411
[Bug fortran/19015] shape / rank mismatch in maxloc / minloc could be caught at compile time (fixed in trunk)
--- Comment #9 from pault at gcc dot gnu dot org 2006-05-28 19:47 --- Subject: Bug 19015 Author: pault Date: Sun May 28 19:46:22 2006 New Revision: 114173 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114173 Log: 2006-05-28 Paul Thomas <[EMAIL PROTECTED]> PR fortran/25082 * resolve.c (resolve_code): Add error condition that the return expression must be scalar. PR fortran/27411 * matchexp.c (gfc_get_parentheses): New function. (match_primary): Remove inline code and call above. * gfortran.h: Provide prototype for gfc_get_parentheses. * resolve.c (resolve_array_ref): Call the above, when start is a derived type variable array reference. PR fortran/27613 * primary.c (gfc_match_rvalue): Test if symbol represents a direct recursive function reference. Error if array valued, go to function0 otherwise. PR fortran/25746 * interface.c (gfc_extend_assign): Use new EXEC_ASSIGN_CALL. * gfortran.h : Put EXEC_ASSIGN_CALL in enum. * trans-stmt.c (gfc_conv_elemental_dependencies): New function. (gfc_trans_call): Call it. Add new boolian argument to flag need for dependency checking. Assert intent OUT and IN for arg1 and arg2. (gfc_trans_forall_1): Use new code EXEC_ASSIGN_CALL. trans-stmt.h : Modify prototype of gfc_trans_call. trans.c (gfc_trans_code): Add call for EXEC_ASSIGN_CALL. st.c (gfc_free_statement): Free actual for EXEC_ASSIGN_CALL. * dependency.c (gfc_check_fncall_dependency): Don't check other against itself. PR fortran/27584 * check.c (gfc_check_associated): Replace NULL assert with an error message, since it is possible to generate bad code that has us fall through to here.. PR fortran/19015 * iresolve.c (maxloc, minloc): If DIM is not present, pass the rank of ARRAY as the shape of the result. Otherwise, pass the shape of ARRAY, less the dimension DIM. (maxval, minval): The same, when DIM is present, otherwise no change. PR fortran/27709 * resolve.c (find_array_spec): Add gfc_symbol, derived, and use to track repeated component references. PR fortran/27155 PR fortran/27449 * trans-intrinsic.c (gfc_conv_intrinsic_array_transfer): Use se->string_length throughout and use memcpy to populate the expression returned to the scalarizer. (gfc_size_in_bytes): New function. * trans-intrinsic.c (gfc_conv_associated): If pointer in first arguments has zero array length of zero string length, return false. 2006-05-28 Paul Thomas <[EMAIL PROTECTED]> PR fortran/25082 * gfortran.dg/scalar_return_1.f90: New test. PR fortran/27411 * gfortran.dg/derived_comp_array_ref_1.f90: New test. PR fortran/25746 * gfortran.dg/elemental_subroutine_3.f90: New test. PR fortran/27584 * gfortran.dg/associated_target_1.f90: New test. PR fortran/19015 * gfortran.dg/maxloc_shape_1.f90: New test. PR fortran/27613 * gfortran.dg/recursive_reference_1.f90: New test. PR fortran/27709 * gfortran.dg/spec_expr_4.f90: New test. PR fortran/27155 * gfortran.dg/transfer_array_intrinsic_4.f90: New test. * gfortran.dg/associated_2.f90: New test. Modified: branches/gcc-4_1-branch/gcc/fortran/ChangeLog branches/gcc-4_1-branch/gcc/fortran/check.c branches/gcc-4_1-branch/gcc/fortran/gfortran.h branches/gcc-4_1-branch/gcc/fortran/interface.c branches/gcc-4_1-branch/gcc/fortran/iresolve.c branches/gcc-4_1-branch/gcc/fortran/matchexp.c branches/gcc-4_1-branch/gcc/fortran/primary.c branches/gcc-4_1-branch/gcc/fortran/resolve.c branches/gcc-4_1-branch/gcc/fortran/st.c branches/gcc-4_1-branch/gcc/fortran/trans-intrinsic.c branches/gcc-4_1-branch/gcc/fortran/trans-stmt.c branches/gcc-4_1-branch/gcc/fortran/trans-stmt.h branches/gcc-4_1-branch/gcc/fortran/trans.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19015
[Bug fortran/25082] Subroutine with RETURN value, ICE in gfc_conv_scalarized_array_ref (fixed in trunk)
--- Comment #5 from pault at gcc dot gnu dot org 2006-05-28 19:47 --- Subject: Bug 25082 Author: pault Date: Sun May 28 19:46:22 2006 New Revision: 114173 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114173 Log: 2006-05-28 Paul Thomas <[EMAIL PROTECTED]> PR fortran/25082 * resolve.c (resolve_code): Add error condition that the return expression must be scalar. PR fortran/27411 * matchexp.c (gfc_get_parentheses): New function. (match_primary): Remove inline code and call above. * gfortran.h: Provide prototype for gfc_get_parentheses. * resolve.c (resolve_array_ref): Call the above, when start is a derived type variable array reference. PR fortran/27613 * primary.c (gfc_match_rvalue): Test if symbol represents a direct recursive function reference. Error if array valued, go to function0 otherwise. PR fortran/25746 * interface.c (gfc_extend_assign): Use new EXEC_ASSIGN_CALL. * gfortran.h : Put EXEC_ASSIGN_CALL in enum. * trans-stmt.c (gfc_conv_elemental_dependencies): New function. (gfc_trans_call): Call it. Add new boolian argument to flag need for dependency checking. Assert intent OUT and IN for arg1 and arg2. (gfc_trans_forall_1): Use new code EXEC_ASSIGN_CALL. trans-stmt.h : Modify prototype of gfc_trans_call. trans.c (gfc_trans_code): Add call for EXEC_ASSIGN_CALL. st.c (gfc_free_statement): Free actual for EXEC_ASSIGN_CALL. * dependency.c (gfc_check_fncall_dependency): Don't check other against itself. PR fortran/27584 * check.c (gfc_check_associated): Replace NULL assert with an error message, since it is possible to generate bad code that has us fall through to here.. PR fortran/19015 * iresolve.c (maxloc, minloc): If DIM is not present, pass the rank of ARRAY as the shape of the result. Otherwise, pass the shape of ARRAY, less the dimension DIM. (maxval, minval): The same, when DIM is present, otherwise no change. PR fortran/27709 * resolve.c (find_array_spec): Add gfc_symbol, derived, and use to track repeated component references. PR fortran/27155 PR fortran/27449 * trans-intrinsic.c (gfc_conv_intrinsic_array_transfer): Use se->string_length throughout and use memcpy to populate the expression returned to the scalarizer. (gfc_size_in_bytes): New function. * trans-intrinsic.c (gfc_conv_associated): If pointer in first arguments has zero array length of zero string length, return false. 2006-05-28 Paul Thomas <[EMAIL PROTECTED]> PR fortran/25082 * gfortran.dg/scalar_return_1.f90: New test. PR fortran/27411 * gfortran.dg/derived_comp_array_ref_1.f90: New test. PR fortran/25746 * gfortran.dg/elemental_subroutine_3.f90: New test. PR fortran/27584 * gfortran.dg/associated_target_1.f90: New test. PR fortran/19015 * gfortran.dg/maxloc_shape_1.f90: New test. PR fortran/27613 * gfortran.dg/recursive_reference_1.f90: New test. PR fortran/27709 * gfortran.dg/spec_expr_4.f90: New test. PR fortran/27155 * gfortran.dg/transfer_array_intrinsic_4.f90: New test. * gfortran.dg/associated_2.f90: New test. Modified: branches/gcc-4_1-branch/gcc/fortran/ChangeLog branches/gcc-4_1-branch/gcc/fortran/check.c branches/gcc-4_1-branch/gcc/fortran/gfortran.h branches/gcc-4_1-branch/gcc/fortran/interface.c branches/gcc-4_1-branch/gcc/fortran/iresolve.c branches/gcc-4_1-branch/gcc/fortran/matchexp.c branches/gcc-4_1-branch/gcc/fortran/primary.c branches/gcc-4_1-branch/gcc/fortran/resolve.c branches/gcc-4_1-branch/gcc/fortran/st.c branches/gcc-4_1-branch/gcc/fortran/trans-intrinsic.c branches/gcc-4_1-branch/gcc/fortran/trans-stmt.c branches/gcc-4_1-branch/gcc/fortran/trans-stmt.h branches/gcc-4_1-branch/gcc/fortran/trans.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25082
[Bug fortran/27449] transfer intrinsic does not work on strict aligned systems (fixed in trunk)
--- Comment #12 from pault at gcc dot gnu dot org 2006-05-28 19:47 --- Subject: Bug 27449 Author: pault Date: Sun May 28 19:46:22 2006 New Revision: 114173 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114173 Log: 2006-05-28 Paul Thomas <[EMAIL PROTECTED]> PR fortran/25082 * resolve.c (resolve_code): Add error condition that the return expression must be scalar. PR fortran/27411 * matchexp.c (gfc_get_parentheses): New function. (match_primary): Remove inline code and call above. * gfortran.h: Provide prototype for gfc_get_parentheses. * resolve.c (resolve_array_ref): Call the above, when start is a derived type variable array reference. PR fortran/27613 * primary.c (gfc_match_rvalue): Test if symbol represents a direct recursive function reference. Error if array valued, go to function0 otherwise. PR fortran/25746 * interface.c (gfc_extend_assign): Use new EXEC_ASSIGN_CALL. * gfortran.h : Put EXEC_ASSIGN_CALL in enum. * trans-stmt.c (gfc_conv_elemental_dependencies): New function. (gfc_trans_call): Call it. Add new boolian argument to flag need for dependency checking. Assert intent OUT and IN for arg1 and arg2. (gfc_trans_forall_1): Use new code EXEC_ASSIGN_CALL. trans-stmt.h : Modify prototype of gfc_trans_call. trans.c (gfc_trans_code): Add call for EXEC_ASSIGN_CALL. st.c (gfc_free_statement): Free actual for EXEC_ASSIGN_CALL. * dependency.c (gfc_check_fncall_dependency): Don't check other against itself. PR fortran/27584 * check.c (gfc_check_associated): Replace NULL assert with an error message, since it is possible to generate bad code that has us fall through to here.. PR fortran/19015 * iresolve.c (maxloc, minloc): If DIM is not present, pass the rank of ARRAY as the shape of the result. Otherwise, pass the shape of ARRAY, less the dimension DIM. (maxval, minval): The same, when DIM is present, otherwise no change. PR fortran/27709 * resolve.c (find_array_spec): Add gfc_symbol, derived, and use to track repeated component references. PR fortran/27155 PR fortran/27449 * trans-intrinsic.c (gfc_conv_intrinsic_array_transfer): Use se->string_length throughout and use memcpy to populate the expression returned to the scalarizer. (gfc_size_in_bytes): New function. * trans-intrinsic.c (gfc_conv_associated): If pointer in first arguments has zero array length of zero string length, return false. 2006-05-28 Paul Thomas <[EMAIL PROTECTED]> PR fortran/25082 * gfortran.dg/scalar_return_1.f90: New test. PR fortran/27411 * gfortran.dg/derived_comp_array_ref_1.f90: New test. PR fortran/25746 * gfortran.dg/elemental_subroutine_3.f90: New test. PR fortran/27584 * gfortran.dg/associated_target_1.f90: New test. PR fortran/19015 * gfortran.dg/maxloc_shape_1.f90: New test. PR fortran/27613 * gfortran.dg/recursive_reference_1.f90: New test. PR fortran/27709 * gfortran.dg/spec_expr_4.f90: New test. PR fortran/27155 * gfortran.dg/transfer_array_intrinsic_4.f90: New test. * gfortran.dg/associated_2.f90: New test. Modified: branches/gcc-4_1-branch/gcc/fortran/ChangeLog branches/gcc-4_1-branch/gcc/fortran/check.c branches/gcc-4_1-branch/gcc/fortran/gfortran.h branches/gcc-4_1-branch/gcc/fortran/interface.c branches/gcc-4_1-branch/gcc/fortran/iresolve.c branches/gcc-4_1-branch/gcc/fortran/matchexp.c branches/gcc-4_1-branch/gcc/fortran/primary.c branches/gcc-4_1-branch/gcc/fortran/resolve.c branches/gcc-4_1-branch/gcc/fortran/st.c branches/gcc-4_1-branch/gcc/fortran/trans-intrinsic.c branches/gcc-4_1-branch/gcc/fortran/trans-stmt.c branches/gcc-4_1-branch/gcc/fortran/trans-stmt.h branches/gcc-4_1-branch/gcc/fortran/trans.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27449
[Bug fortran/27613] compile fails with "Unclassifiable statement" error message (fixed in trunk)
--- Comment #8 from pault at gcc dot gnu dot org 2006-05-28 19:47 --- Subject: Bug 27613 Author: pault Date: Sun May 28 19:46:22 2006 New Revision: 114173 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114173 Log: 2006-05-28 Paul Thomas <[EMAIL PROTECTED]> PR fortran/25082 * resolve.c (resolve_code): Add error condition that the return expression must be scalar. PR fortran/27411 * matchexp.c (gfc_get_parentheses): New function. (match_primary): Remove inline code and call above. * gfortran.h: Provide prototype for gfc_get_parentheses. * resolve.c (resolve_array_ref): Call the above, when start is a derived type variable array reference. PR fortran/27613 * primary.c (gfc_match_rvalue): Test if symbol represents a direct recursive function reference. Error if array valued, go to function0 otherwise. PR fortran/25746 * interface.c (gfc_extend_assign): Use new EXEC_ASSIGN_CALL. * gfortran.h : Put EXEC_ASSIGN_CALL in enum. * trans-stmt.c (gfc_conv_elemental_dependencies): New function. (gfc_trans_call): Call it. Add new boolian argument to flag need for dependency checking. Assert intent OUT and IN for arg1 and arg2. (gfc_trans_forall_1): Use new code EXEC_ASSIGN_CALL. trans-stmt.h : Modify prototype of gfc_trans_call. trans.c (gfc_trans_code): Add call for EXEC_ASSIGN_CALL. st.c (gfc_free_statement): Free actual for EXEC_ASSIGN_CALL. * dependency.c (gfc_check_fncall_dependency): Don't check other against itself. PR fortran/27584 * check.c (gfc_check_associated): Replace NULL assert with an error message, since it is possible to generate bad code that has us fall through to here.. PR fortran/19015 * iresolve.c (maxloc, minloc): If DIM is not present, pass the rank of ARRAY as the shape of the result. Otherwise, pass the shape of ARRAY, less the dimension DIM. (maxval, minval): The same, when DIM is present, otherwise no change. PR fortran/27709 * resolve.c (find_array_spec): Add gfc_symbol, derived, and use to track repeated component references. PR fortran/27155 PR fortran/27449 * trans-intrinsic.c (gfc_conv_intrinsic_array_transfer): Use se->string_length throughout and use memcpy to populate the expression returned to the scalarizer. (gfc_size_in_bytes): New function. * trans-intrinsic.c (gfc_conv_associated): If pointer in first arguments has zero array length of zero string length, return false. 2006-05-28 Paul Thomas <[EMAIL PROTECTED]> PR fortran/25082 * gfortran.dg/scalar_return_1.f90: New test. PR fortran/27411 * gfortran.dg/derived_comp_array_ref_1.f90: New test. PR fortran/25746 * gfortran.dg/elemental_subroutine_3.f90: New test. PR fortran/27584 * gfortran.dg/associated_target_1.f90: New test. PR fortran/19015 * gfortran.dg/maxloc_shape_1.f90: New test. PR fortran/27613 * gfortran.dg/recursive_reference_1.f90: New test. PR fortran/27709 * gfortran.dg/spec_expr_4.f90: New test. PR fortran/27155 * gfortran.dg/transfer_array_intrinsic_4.f90: New test. * gfortran.dg/associated_2.f90: New test. Modified: branches/gcc-4_1-branch/gcc/fortran/ChangeLog branches/gcc-4_1-branch/gcc/fortran/check.c branches/gcc-4_1-branch/gcc/fortran/gfortran.h branches/gcc-4_1-branch/gcc/fortran/interface.c branches/gcc-4_1-branch/gcc/fortran/iresolve.c branches/gcc-4_1-branch/gcc/fortran/matchexp.c branches/gcc-4_1-branch/gcc/fortran/primary.c branches/gcc-4_1-branch/gcc/fortran/resolve.c branches/gcc-4_1-branch/gcc/fortran/st.c branches/gcc-4_1-branch/gcc/fortran/trans-intrinsic.c branches/gcc-4_1-branch/gcc/fortran/trans-stmt.c branches/gcc-4_1-branch/gcc/fortran/trans-stmt.h branches/gcc-4_1-branch/gcc/fortran/trans.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27613
[Bug fortran/27584] ICE on invalid "associate(x,(y))" (fixed in trunk)
--- Comment #5 from pault at gcc dot gnu dot org 2006-05-28 19:47 --- Subject: Bug 27584 Author: pault Date: Sun May 28 19:46:22 2006 New Revision: 114173 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114173 Log: 2006-05-28 Paul Thomas <[EMAIL PROTECTED]> PR fortran/25082 * resolve.c (resolve_code): Add error condition that the return expression must be scalar. PR fortran/27411 * matchexp.c (gfc_get_parentheses): New function. (match_primary): Remove inline code and call above. * gfortran.h: Provide prototype for gfc_get_parentheses. * resolve.c (resolve_array_ref): Call the above, when start is a derived type variable array reference. PR fortran/27613 * primary.c (gfc_match_rvalue): Test if symbol represents a direct recursive function reference. Error if array valued, go to function0 otherwise. PR fortran/25746 * interface.c (gfc_extend_assign): Use new EXEC_ASSIGN_CALL. * gfortran.h : Put EXEC_ASSIGN_CALL in enum. * trans-stmt.c (gfc_conv_elemental_dependencies): New function. (gfc_trans_call): Call it. Add new boolian argument to flag need for dependency checking. Assert intent OUT and IN for arg1 and arg2. (gfc_trans_forall_1): Use new code EXEC_ASSIGN_CALL. trans-stmt.h : Modify prototype of gfc_trans_call. trans.c (gfc_trans_code): Add call for EXEC_ASSIGN_CALL. st.c (gfc_free_statement): Free actual for EXEC_ASSIGN_CALL. * dependency.c (gfc_check_fncall_dependency): Don't check other against itself. PR fortran/27584 * check.c (gfc_check_associated): Replace NULL assert with an error message, since it is possible to generate bad code that has us fall through to here.. PR fortran/19015 * iresolve.c (maxloc, minloc): If DIM is not present, pass the rank of ARRAY as the shape of the result. Otherwise, pass the shape of ARRAY, less the dimension DIM. (maxval, minval): The same, when DIM is present, otherwise no change. PR fortran/27709 * resolve.c (find_array_spec): Add gfc_symbol, derived, and use to track repeated component references. PR fortran/27155 PR fortran/27449 * trans-intrinsic.c (gfc_conv_intrinsic_array_transfer): Use se->string_length throughout and use memcpy to populate the expression returned to the scalarizer. (gfc_size_in_bytes): New function. * trans-intrinsic.c (gfc_conv_associated): If pointer in first arguments has zero array length of zero string length, return false. 2006-05-28 Paul Thomas <[EMAIL PROTECTED]> PR fortran/25082 * gfortran.dg/scalar_return_1.f90: New test. PR fortran/27411 * gfortran.dg/derived_comp_array_ref_1.f90: New test. PR fortran/25746 * gfortran.dg/elemental_subroutine_3.f90: New test. PR fortran/27584 * gfortran.dg/associated_target_1.f90: New test. PR fortran/19015 * gfortran.dg/maxloc_shape_1.f90: New test. PR fortran/27613 * gfortran.dg/recursive_reference_1.f90: New test. PR fortran/27709 * gfortran.dg/spec_expr_4.f90: New test. PR fortran/27155 * gfortran.dg/transfer_array_intrinsic_4.f90: New test. * gfortran.dg/associated_2.f90: New test. Modified: branches/gcc-4_1-branch/gcc/fortran/ChangeLog branches/gcc-4_1-branch/gcc/fortran/check.c branches/gcc-4_1-branch/gcc/fortran/gfortran.h branches/gcc-4_1-branch/gcc/fortran/interface.c branches/gcc-4_1-branch/gcc/fortran/iresolve.c branches/gcc-4_1-branch/gcc/fortran/matchexp.c branches/gcc-4_1-branch/gcc/fortran/primary.c branches/gcc-4_1-branch/gcc/fortran/resolve.c branches/gcc-4_1-branch/gcc/fortran/st.c branches/gcc-4_1-branch/gcc/fortran/trans-intrinsic.c branches/gcc-4_1-branch/gcc/fortran/trans-stmt.c branches/gcc-4_1-branch/gcc/fortran/trans-stmt.h branches/gcc-4_1-branch/gcc/fortran/trans.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27584
[Bug fortran/27709] Using size of array pointer component as dimension of function result causes gfortran internal error. (fixed in trunk)
--- Comment #8 from pault at gcc dot gnu dot org 2006-05-28 19:47 --- Subject: Bug 27709 Author: pault Date: Sun May 28 19:46:22 2006 New Revision: 114173 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114173 Log: 2006-05-28 Paul Thomas <[EMAIL PROTECTED]> PR fortran/25082 * resolve.c (resolve_code): Add error condition that the return expression must be scalar. PR fortran/27411 * matchexp.c (gfc_get_parentheses): New function. (match_primary): Remove inline code and call above. * gfortran.h: Provide prototype for gfc_get_parentheses. * resolve.c (resolve_array_ref): Call the above, when start is a derived type variable array reference. PR fortran/27613 * primary.c (gfc_match_rvalue): Test if symbol represents a direct recursive function reference. Error if array valued, go to function0 otherwise. PR fortran/25746 * interface.c (gfc_extend_assign): Use new EXEC_ASSIGN_CALL. * gfortran.h : Put EXEC_ASSIGN_CALL in enum. * trans-stmt.c (gfc_conv_elemental_dependencies): New function. (gfc_trans_call): Call it. Add new boolian argument to flag need for dependency checking. Assert intent OUT and IN for arg1 and arg2. (gfc_trans_forall_1): Use new code EXEC_ASSIGN_CALL. trans-stmt.h : Modify prototype of gfc_trans_call. trans.c (gfc_trans_code): Add call for EXEC_ASSIGN_CALL. st.c (gfc_free_statement): Free actual for EXEC_ASSIGN_CALL. * dependency.c (gfc_check_fncall_dependency): Don't check other against itself. PR fortran/27584 * check.c (gfc_check_associated): Replace NULL assert with an error message, since it is possible to generate bad code that has us fall through to here.. PR fortran/19015 * iresolve.c (maxloc, minloc): If DIM is not present, pass the rank of ARRAY as the shape of the result. Otherwise, pass the shape of ARRAY, less the dimension DIM. (maxval, minval): The same, when DIM is present, otherwise no change. PR fortran/27709 * resolve.c (find_array_spec): Add gfc_symbol, derived, and use to track repeated component references. PR fortran/27155 PR fortran/27449 * trans-intrinsic.c (gfc_conv_intrinsic_array_transfer): Use se->string_length throughout and use memcpy to populate the expression returned to the scalarizer. (gfc_size_in_bytes): New function. * trans-intrinsic.c (gfc_conv_associated): If pointer in first arguments has zero array length of zero string length, return false. 2006-05-28 Paul Thomas <[EMAIL PROTECTED]> PR fortran/25082 * gfortran.dg/scalar_return_1.f90: New test. PR fortran/27411 * gfortran.dg/derived_comp_array_ref_1.f90: New test. PR fortran/25746 * gfortran.dg/elemental_subroutine_3.f90: New test. PR fortran/27584 * gfortran.dg/associated_target_1.f90: New test. PR fortran/19015 * gfortran.dg/maxloc_shape_1.f90: New test. PR fortran/27613 * gfortran.dg/recursive_reference_1.f90: New test. PR fortran/27709 * gfortran.dg/spec_expr_4.f90: New test. PR fortran/27155 * gfortran.dg/transfer_array_intrinsic_4.f90: New test. * gfortran.dg/associated_2.f90: New test. Modified: branches/gcc-4_1-branch/gcc/fortran/ChangeLog branches/gcc-4_1-branch/gcc/fortran/check.c branches/gcc-4_1-branch/gcc/fortran/gfortran.h branches/gcc-4_1-branch/gcc/fortran/interface.c branches/gcc-4_1-branch/gcc/fortran/iresolve.c branches/gcc-4_1-branch/gcc/fortran/matchexp.c branches/gcc-4_1-branch/gcc/fortran/primary.c branches/gcc-4_1-branch/gcc/fortran/resolve.c branches/gcc-4_1-branch/gcc/fortran/st.c branches/gcc-4_1-branch/gcc/fortran/trans-intrinsic.c branches/gcc-4_1-branch/gcc/fortran/trans-stmt.c branches/gcc-4_1-branch/gcc/fortran/trans-stmt.h branches/gcc-4_1-branch/gcc/fortran/trans.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27709
[Bug fortran/27584] ICE on invalid "associate(x,(y))" (fixed in trunk)
--- Comment #6 from pault at gcc dot gnu dot org 2006-05-28 19:51 --- Subject: Bug 27584 Author: pault Date: Sun May 28 19:50:51 2006 New Revision: 114174 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114174 Log: 2006-05-28 Paul Thomas <[EMAIL PROTECTED]> PR fortran/25082 * gfortran.dg/scalar_return_1.f90: New test. PR fortran/27411 * gfortran.dg/derived_comp_array_ref_1.f90: New test. PR fortran/25746 * gfortran.dg/elemental_subroutine_3.f90: New test. PR fortran/27584 * gfortran.dg/associated_target_1.f90: New test. PR fortran/19015 * gfortran.dg/maxloc_shape_1.f90: New test. PR fortran/27613 * gfortran.dg/recursive_reference_1.f90: New test. PR fortran/27709 * gfortran.dg/spec_expr_4.f90: New test. PR fortran/27155 * gfortran.dg/transfer_array_intrinsic_4.f90: New test. * gfortran.dg/associated_2.f90: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/associated_2.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/associated_target_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/derived_comp_array_ref_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/elemental_subroutine_3.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/maxloc_shape_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/recursive_reference_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/scalar_return_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/spec_expr_4.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/transfer_array_intrinsic_4.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27584
[Bug fortran/25082] Subroutine with RETURN value, ICE in gfc_conv_scalarized_array_ref (fixed in trunk)
--- Comment #6 from pault at gcc dot gnu dot org 2006-05-28 19:51 --- Subject: Bug 25082 Author: pault Date: Sun May 28 19:50:51 2006 New Revision: 114174 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114174 Log: 2006-05-28 Paul Thomas <[EMAIL PROTECTED]> PR fortran/25082 * gfortran.dg/scalar_return_1.f90: New test. PR fortran/27411 * gfortran.dg/derived_comp_array_ref_1.f90: New test. PR fortran/25746 * gfortran.dg/elemental_subroutine_3.f90: New test. PR fortran/27584 * gfortran.dg/associated_target_1.f90: New test. PR fortran/19015 * gfortran.dg/maxloc_shape_1.f90: New test. PR fortran/27613 * gfortran.dg/recursive_reference_1.f90: New test. PR fortran/27709 * gfortran.dg/spec_expr_4.f90: New test. PR fortran/27155 * gfortran.dg/transfer_array_intrinsic_4.f90: New test. * gfortran.dg/associated_2.f90: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/associated_2.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/associated_target_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/derived_comp_array_ref_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/elemental_subroutine_3.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/maxloc_shape_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/recursive_reference_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/scalar_return_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/spec_expr_4.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/transfer_array_intrinsic_4.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25082
[Bug fortran/25746] Elemental assignment gives wrong result (fixed in trunk)
--- Comment #9 from pault at gcc dot gnu dot org 2006-05-28 19:51 --- Subject: Bug 25746 Author: pault Date: Sun May 28 19:50:51 2006 New Revision: 114174 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114174 Log: 2006-05-28 Paul Thomas <[EMAIL PROTECTED]> PR fortran/25082 * gfortran.dg/scalar_return_1.f90: New test. PR fortran/27411 * gfortran.dg/derived_comp_array_ref_1.f90: New test. PR fortran/25746 * gfortran.dg/elemental_subroutine_3.f90: New test. PR fortran/27584 * gfortran.dg/associated_target_1.f90: New test. PR fortran/19015 * gfortran.dg/maxloc_shape_1.f90: New test. PR fortran/27613 * gfortran.dg/recursive_reference_1.f90: New test. PR fortran/27709 * gfortran.dg/spec_expr_4.f90: New test. PR fortran/27155 * gfortran.dg/transfer_array_intrinsic_4.f90: New test. * gfortran.dg/associated_2.f90: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/associated_2.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/associated_target_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/derived_comp_array_ref_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/elemental_subroutine_3.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/maxloc_shape_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/recursive_reference_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/scalar_return_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/spec_expr_4.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/transfer_array_intrinsic_4.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25746
[Bug fortran/27411] crashes in sra_walk_expr and emit_move_insn (fixed in trunk)
--- Comment #10 from pault at gcc dot gnu dot org 2006-05-28 19:51 --- Subject: Bug 27411 Author: pault Date: Sun May 28 19:50:51 2006 New Revision: 114174 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114174 Log: 2006-05-28 Paul Thomas <[EMAIL PROTECTED]> PR fortran/25082 * gfortran.dg/scalar_return_1.f90: New test. PR fortran/27411 * gfortran.dg/derived_comp_array_ref_1.f90: New test. PR fortran/25746 * gfortran.dg/elemental_subroutine_3.f90: New test. PR fortran/27584 * gfortran.dg/associated_target_1.f90: New test. PR fortran/19015 * gfortran.dg/maxloc_shape_1.f90: New test. PR fortran/27613 * gfortran.dg/recursive_reference_1.f90: New test. PR fortran/27709 * gfortran.dg/spec_expr_4.f90: New test. PR fortran/27155 * gfortran.dg/transfer_array_intrinsic_4.f90: New test. * gfortran.dg/associated_2.f90: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/associated_2.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/associated_target_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/derived_comp_array_ref_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/elemental_subroutine_3.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/maxloc_shape_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/recursive_reference_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/scalar_return_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/spec_expr_4.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/transfer_array_intrinsic_4.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27411
[Bug fortran/27709] Using size of array pointer component as dimension of function result causes gfortran internal error. (fixed in trunk)
--- Comment #9 from pault at gcc dot gnu dot org 2006-05-28 19:51 --- Subject: Bug 27709 Author: pault Date: Sun May 28 19:50:51 2006 New Revision: 114174 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114174 Log: 2006-05-28 Paul Thomas <[EMAIL PROTECTED]> PR fortran/25082 * gfortran.dg/scalar_return_1.f90: New test. PR fortran/27411 * gfortran.dg/derived_comp_array_ref_1.f90: New test. PR fortran/25746 * gfortran.dg/elemental_subroutine_3.f90: New test. PR fortran/27584 * gfortran.dg/associated_target_1.f90: New test. PR fortran/19015 * gfortran.dg/maxloc_shape_1.f90: New test. PR fortran/27613 * gfortran.dg/recursive_reference_1.f90: New test. PR fortran/27709 * gfortran.dg/spec_expr_4.f90: New test. PR fortran/27155 * gfortran.dg/transfer_array_intrinsic_4.f90: New test. * gfortran.dg/associated_2.f90: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/associated_2.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/associated_target_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/derived_comp_array_ref_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/elemental_subroutine_3.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/maxloc_shape_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/recursive_reference_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/scalar_return_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/spec_expr_4.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/transfer_array_intrinsic_4.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27709
[Bug fortran/27155] Transfer of character to integer array and vice versa still doesn't work (fixed in trunk)
--- Comment #22 from pault at gcc dot gnu dot org 2006-05-28 19:51 --- Subject: Bug 27155 Author: pault Date: Sun May 28 19:50:51 2006 New Revision: 114174 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114174 Log: 2006-05-28 Paul Thomas <[EMAIL PROTECTED]> PR fortran/25082 * gfortran.dg/scalar_return_1.f90: New test. PR fortran/27411 * gfortran.dg/derived_comp_array_ref_1.f90: New test. PR fortran/25746 * gfortran.dg/elemental_subroutine_3.f90: New test. PR fortran/27584 * gfortran.dg/associated_target_1.f90: New test. PR fortran/19015 * gfortran.dg/maxloc_shape_1.f90: New test. PR fortran/27613 * gfortran.dg/recursive_reference_1.f90: New test. PR fortran/27709 * gfortran.dg/spec_expr_4.f90: New test. PR fortran/27155 * gfortran.dg/transfer_array_intrinsic_4.f90: New test. * gfortran.dg/associated_2.f90: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/associated_2.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/associated_target_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/derived_comp_array_ref_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/elemental_subroutine_3.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/maxloc_shape_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/recursive_reference_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/scalar_return_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/spec_expr_4.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/transfer_array_intrinsic_4.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27155
[Bug fortran/27613] compile fails with "Unclassifiable statement" error message (fixed in trunk)
--- Comment #9 from pault at gcc dot gnu dot org 2006-05-28 19:51 --- Subject: Bug 27613 Author: pault Date: Sun May 28 19:50:51 2006 New Revision: 114174 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114174 Log: 2006-05-28 Paul Thomas <[EMAIL PROTECTED]> PR fortran/25082 * gfortran.dg/scalar_return_1.f90: New test. PR fortran/27411 * gfortran.dg/derived_comp_array_ref_1.f90: New test. PR fortran/25746 * gfortran.dg/elemental_subroutine_3.f90: New test. PR fortran/27584 * gfortran.dg/associated_target_1.f90: New test. PR fortran/19015 * gfortran.dg/maxloc_shape_1.f90: New test. PR fortran/27613 * gfortran.dg/recursive_reference_1.f90: New test. PR fortran/27709 * gfortran.dg/spec_expr_4.f90: New test. PR fortran/27155 * gfortran.dg/transfer_array_intrinsic_4.f90: New test. * gfortran.dg/associated_2.f90: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/associated_2.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/associated_target_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/derived_comp_array_ref_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/elemental_subroutine_3.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/maxloc_shape_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/recursive_reference_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/scalar_return_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/spec_expr_4.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/transfer_array_intrinsic_4.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27613
[Bug fortran/19015] shape / rank mismatch in maxloc / minloc could be caught at compile time (fixed in trunk)
--- Comment #10 from pault at gcc dot gnu dot org 2006-05-28 19:51 --- Subject: Bug 19015 Author: pault Date: Sun May 28 19:50:51 2006 New Revision: 114174 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114174 Log: 2006-05-28 Paul Thomas <[EMAIL PROTECTED]> PR fortran/25082 * gfortran.dg/scalar_return_1.f90: New test. PR fortran/27411 * gfortran.dg/derived_comp_array_ref_1.f90: New test. PR fortran/25746 * gfortran.dg/elemental_subroutine_3.f90: New test. PR fortran/27584 * gfortran.dg/associated_target_1.f90: New test. PR fortran/19015 * gfortran.dg/maxloc_shape_1.f90: New test. PR fortran/27613 * gfortran.dg/recursive_reference_1.f90: New test. PR fortran/27709 * gfortran.dg/spec_expr_4.f90: New test. PR fortran/27155 * gfortran.dg/transfer_array_intrinsic_4.f90: New test. * gfortran.dg/associated_2.f90: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/associated_2.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/associated_target_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/derived_comp_array_ref_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/elemental_subroutine_3.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/maxloc_shape_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/recursive_reference_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/scalar_return_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/spec_expr_4.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/transfer_array_intrinsic_4.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19015
[Bug fortran/27411] crashes in sra_walk_expr and emit_move_insn
--- Comment #11 from pault at gcc dot gnu dot org 2006-05-28 19:52 --- Fixed in trunk and 4.1 Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Summary|crashes in sra_walk_expr and|crashes in sra_walk_expr and |emit_move_insn (fixed in|emit_move_insn |trunk) | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27411
[Bug fortran/25082] Subroutine with RETURN value, ICE in gfc_conv_scalarized_array_ref
--- Comment #7 from pault at gcc dot gnu dot org 2006-05-28 19:53 --- Fixed in trunk and 4.1 Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Summary|Subroutine with RETURN |Subroutine with RETURN |value, ICE in |value, ICE in |gfc_conv_scalarized_array_re|gfc_conv_scalarized_array_re |f (fixed in trunk) |f http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25082
[Bug fortran/25746] Elemental assignment gives wrong result
--- Comment #10 from pault at gcc dot gnu dot org 2006-05-28 19:54 --- Fixed in trunk and 4.1 Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Summary|Elemental assignment gives |Elemental assignment gives |wrong result (fixed in |wrong result |trunk) | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25746
[Bug fortran/27584] ICE on invalid "associate(x,(y))"
--- Comment #7 from pault at gcc dot gnu dot org 2006-05-28 19:54 --- Fixed in trunk and 4.1 Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Summary|ICE on invalid |ICE on invalid |"associate(x,(y))" (fixed in|"associate(x,(y))" |trunk) | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27584
[Bug fortran/19015] shape / rank mismatch in maxloc / minloc could be caught at compile time
--- Comment #11 from pault at gcc dot gnu dot org 2006-05-28 19:55 --- Fixed in trunk and 4.1 Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Summary|shape / rank mismatch in|shape / rank mismatch in |maxloc / minloc could be|maxloc / minloc could be |caught at compile time |caught at compile time |(fixed in trunk)| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19015
[Bug fortran/27613] compile fails with "Unclassifiable statement" error message
--- Comment #10 from pault at gcc dot gnu dot org 2006-05-28 19:56 --- Fixed in trunk and 4.1 Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Summary|compile fails with |compile fails with |"Unclassifiable statement" |"Unclassifiable statement" |error message (fixed in |error message |trunk) | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27613
[Bug fortran/27715] Extented ASCII characters lead to wrong "CASE" selection
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2006-05-28 19:56
---
(In reply to comment #6)
> Have you read 4.3.2.1.1? This defines the requirements on the
> collating of the default character type. It also defines the
> requirements on LGT, LGE, LLE, and LLT, which is why we use the
> ascii_table in simplify.c.
OK, I see. I think we don't have users around here using non ASCII-based
charsets, and I also think other parts of the front-end and library would fall
apart on such systems, but anyway, that's not the point.
Anyway, I know it's standard conforming, but having both LLE("é","è") and
LGE("é","è") returning true is... always surprising.
> Thomas' idea of using unsigned char does not conflict with
> 4.3.2.1.1.
Yes, but C strings are char by default and not unsigned char, so I guess we'd
best avoid changing that. But, a less invasive fix could be:
Index: simplify.c
===
--- simplify.c (revision 113849)
+++ simplify.c (working copy)
@@ -67,7 +67,7 @@
/* Static table for converting non-ascii character sets to ascii.
The xascii_table[] is the inverse table. */
-static int ascii_table[256] = {
+static unsigned char ascii_table[256] = {
'\0', '\0', '\0', '\0', '\0', '\0', '\0', '\0',
'\b', '\t', '\n', '\v', '\0', '\r', '\0', '\0',
'\0', '\0', '\0', '\0', '\0', '\0', '\0', '\0',
@@ -86,7 +86,7 @@
'x', 'y', 'z', '{', '|', '}', '~', '\?'
};
-static int xascii_table[256];
+static unsigned int xascii_table[256];
/* Range checks an expression node. If all goes well, returns the
@@ -1196,7 +1196,7 @@
return &gfc_bad_expr;
}
- index = xascii_table[(int) e->value.character.string[0] & 0xFF];
+ index = xascii_table[(unsigned char) e->value.character.string[0] & 0xFF];
result = gfc_int_expr (index);
result->where = e->where;
@@ -4016,9 +4016,9 @@
/* Given a collating table, create the inverse table. */
static void
-invert_table (const int *table, int *xtable)
+invert_table (const unsigned char *table, unsigned int *xtable)
{
- int i;
+ unsigned int i;
for (i = 0; i < 256; i++)
xtable[i] = 0;
Index: arith.c
===
--- arith.c (revision 113849)
+++ arith.c (working copy)
@@ -1122,9 +1122,10 @@
collating sequence. */
int
-gfc_compare_string (gfc_expr * a, gfc_expr * b, const int *xcoll_table)
+gfc_compare_string (gfc_expr * a, gfc_expr * b, const unsigned int
*xcoll_table)
{
- int len, alen, blen, i, ac, bc;
+ int len, alen, blen, i;
+ unsigned char ac, bc;
alen = a->value.character.length;
blen = b->value.character.length;
Index: arith.h
===
--- arith.h (revision 113849)
+++ arith.h (working copy)
@@ -41,7 +41,7 @@
arith gfc_range_check (gfc_expr *);
int gfc_compare_expr (gfc_expr *, gfc_expr *);
-int gfc_compare_string (gfc_expr *, gfc_expr *, const int *);
+int gfc_compare_string (gfc_expr *, gfc_expr *, const unsigned int *);
/* Constant folding for gfc_expr trees. */
gfc_expr *gfc_uplus (gfc_expr * op);
Comments on this one?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27715
[Bug fortran/27709] Using size of array pointer component as dimension of function result causes gfortran internal error.
--- Comment #10 from pault at gcc dot gnu dot org 2006-05-28 19:57 --- Fixed in trunk and 4.1 Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Summary|Using size of array pointer |Using size of array pointer |component as dimension of |component as dimension of |function result causes |function result causes |gfortran internal error.|gfortran internal error. |(fixed in trunk)| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27709
[Bug fortran/27155] Transfer of character to integer array and vice versa still doesn't work
--- Comment #23 from pault at gcc dot gnu dot org 2006-05-28 19:58 --- Fixed in trunk and 4.1 Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Summary|Transfer of character to|Transfer of character to |integer array and vice versa|integer array and vice versa |still doesn't work (fixed in|still doesn't work |trunk) | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27155
[Bug fortran/27715] Extented ASCII characters lead to wrong "CASE" selection
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-05-28 20:03 ---
(In reply to comment #7)
> (In reply to comment #6)
> > Have you read 4.3.2.1.1? This defines the requirements on the
> > collating of the default character type. It also defines the
> > requirements on LGT, LGE, LLE, and LLT, which is why we use the
> > ascii_table in simplify.c.
>
> OK, I see. I think we don't have users around here using non ASCII-based
> charsets, and I also think other parts of the front-end and library would fall
> apart on such systems, but anyway, that's not the point.
GCC does support other charatersets besides ASCII ( the IBM one is an example):
the middle-end does something like:
target_newline = lang_hooks.to_target_charset ('\n');
target_percent = lang_hooks.to_target_charset ('%');
target_c = lang_hooks.to_target_charset ('c');
target_s = lang_hooks.to_target_charset ('s');
To find %s for folding of printf, etc.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27715
[Bug fortran/27715] Extented ASCII characters lead to wrong "CASE" selection
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-05-28 20:05 --- (In reply to comment #7) > Yes, but C strings are char by default and not unsigned char, so I guess we'd > best avoid changing that. But, a less invasive fix could be: And char can either default to unsigned or signed (it is the only type which is like this in C). For an example on most OS's on PPC, char defaults to unsigned char (and not signed char). -- Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27715
[Bug fortran/27470] [4.1 regression] wrong memory allocator for derived types
--- Comment #12 from tkoenig at gcc dot gnu dot org 2006-05-28 20:36 --- Subject: Bug 27470 Author: tkoenig Date: Sun May 28 20:35:53 2006 New Revision: 114176 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114176 Log: 2005-05-28 Thomas Koenig <[EMAIL PROTECTED]> PR fortran/27470 Backport from trunk. * trans-array.c(gfc_array_allocate): If ref->next exists that is if there is a statement like ALLOCATE(foo%bar(2)), F95 rules require that bar should be a pointer. 2005-05-28 Thomas Koenig <[EMAIL PROTECTED]> PR fortran/27470 Backport from trunk. * gfortran.dg/multiple_allocation_2.f90: New test case. Added: branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/multiple_allocation_2.f90 Modified: branches/gcc-4_1-branch/gcc/fortran/ChangeLog branches/gcc-4_1-branch/gcc/fortran/trans-array.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27470
[Bug fortran/27470] [4.1 regression] wrong memory allocator for derived types
--- Comment #13 from tkoenig at gcc dot gnu dot org 2006-05-28 20:37 --- Fixed on trunk and 4.1. Closing. -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27470
[Bug tree-optimization/27768] [4.2 regression] wrong-code with vectors
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-05-28 20:47 --- Something is removing the store to _M_start. this_252 = (struct _Vector_base > *) &b; this_253 = this_252; # VUSE ; D.13530_256 = this_252->_M_impl._M_start; I think the cast there is causing the problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27768
[Bug tree-optimization/27768] [4.2 regression] wrong-code with vectors
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-05-28 20:50 --- This is related to PR 19817, the C++ front-end is producing that construct which causes us not to constant prop zero. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27768
[Bug c++/27768] [4.2 regression] wrong-code with vectors
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-05-28 20:52 --- But even without fixing PR 19817, it seems like the cast should be valid, or maybe not someone who knows if the cast is valid in C++ where the struct is not an inheirtance. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||19817 Component|tree-optimization |c++ http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27768
[Bug c++/27787] Qualified lookup fails to find inherited class template
--- Comment #4 from tschwinger at neoscientists dot org 2006-05-28 21:47
---
It seems my report is missing some detail.
Here's my apology and an attempt to outline my standard interpretation that
makes me think it is a bug.
(In reply to comment #0)
>
> template
> struct x
> {
> template
> struct y
> {
> typedef Y type;
> };
> };
>
> template
> struct a : x
> {
> //template
> //typename y::type f(B); // ill-formed
- the base class 'x' is obviously dependent (since it depends on 'A'), so
GCC validly detects an ill-formed program trying to find 'y' (and so does
Comeau)
> // qualified lookup should find inherited class template 'y', however
> template
> typename a::template y::type f(B);
- the injected class name 'a' refers to the class template specialization (same
as 'a' in this context) and should be found even by unqualified lookup
(works correctly, so far)
- qualified lookup applies to 'template y' because it's qualified by 'a',
14.6.2-3 only applies to unqualified lookup so there is no reason for 'template
y' not to be found
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27787
[Bug c++/27788] New: error casting address of a function template specialization
The well-formed program below fails to compile with gcc 4.1.0:
$ cat t.cpp && gcc -c t.cpp
template void foo (T*) { }
typedef void F ();
F* f = (F*)&foo;
t.cpp:5: error: address of overloaded function with no contextual type
information
--
Summary: error casting address of a function template
specialization
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
GCC build triplet: all
GCC host triplet: all
GCC target triplet: all
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27788
[Bug target/27789] New: attribute handling fallout from DECL_INITIAL changes
This revision to gcc/cp 2006-05-24 Mark Mitchell <[EMAIL PROTECTED]> PR c++/20103 * decl.c (cp_make_fname_decl): Don't set DECL_INITIAL to error_mark_node to indicate an initialization is OK. (start_decl): Likewise. Adjust call to start_decl_1. (start_decl_1): Add initialized parameter. Simplify. * except.c (initialize_handler_parm): Adjust call to setart_decl_1. (expand_start_catch_block): Let cp_finish_decl initialize catch parameters. * cp-tree.h (start_decl_1): Adjust prototype. * pt.c (tsubst_expr): Don't set DECL_INITIAL to error_mark_node. (instantiate_decl): Let cp_finish_decl handle initialization. * semantics.c (finish_compound_literal): Create a temporary variable for the literal. * typeck.c (build_unary_op): Remove COMPOUND_LITERAL_P special cases. * decl2.c (finish_static_data_member_decl): Don't set DECL_INITIAL. (grokfield): Do not try to initialize functions. has resulted in 3 new testsuite failures: FAIL: g++.dg/ext/dllimport4.C (test for errors, line 6) FAIL: g++.dg/ext/selectany1.C (test for excess errors) FAIL: g++.dg/ext/selectany2.C (test for excess errors) The dllimport failure is because handle_dllimport_atribute in tree.c uses DECL_INITIAL to disallow adding the attribute to the definition of a variable. The selectany failures are because ix86_handle_selectany_attribute in config/i386/winnt.c uses DECL_INITIAL to disallow adding the attribute to a variable that is _not_ initialized. For both attributes, the test for DECL_INITIAL still work in C testcases. Danny -- Summary: attribute handling fallout from DECL_INITIAL changes Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dannysmith at users dot sourceforge dot net GCC build triplet: i686-pc-mingw32 GCC host triplet: i686-pc-mingw32 GCC target triplet: i686-pc-mingw32 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27789
[Bug c++/27788] error casting address of a function template specialization
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-05-29 00:12 --- It is only valid after DR 115. This is a dup of bug 11407. *** This bug has been marked as a duplicate of 11407 *** -- 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=27788
[Bug c++/11407] [DR 115] Function cannot be resolved
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-05-29 00:12 --- *** Bug 27788 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||sebor at roguewave dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11407
[Bug target/27682] float to int conversion doesn't raise invalid exception
--- Comment #5 from amodra at bigpond dot net dot au 2006-05-29 02:48 --- Note that fctidz is used because we are converting to unsigned. gcc uses fctiwz if converting to int. Of course, it isn't correct to simply replace fctidz with fctiwz.. To get this right, gcc would need to generate something like the following fctidz 0,0 stfd 0,temp_slot(1) ld 9,temp_slot(1) rldicl 0,9,0,32 cmpd 0,9 beq .+8 mtfsb1 23 with the last three insns being the extras needed to set the invalid operation. Conversion to unsigned int on ppc32 will also need some tweaks. Hmm, there we are using code generated by optabs.c (search for comment "For an unsigned conversion, there is one more way to do it.") Why doesn't this code always subtract off 2**(n-1), convert, then add 2**(n-1)? That way we'd get the invalid op bits set correctly. -- amodra at bigpond dot net dot au changed: What|Removed |Added CC||amodra at bigpond dot net ||dot au Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-05-29 02:48:03 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27682
[Bug target/27682] float to int conversion doesn't raise invalid exception
--- Comment #6 from amodra at bigpond dot net dot au 2006-05-29 02:52 --- Oh, I suppose rounding might change the result if we always subtract off 2**(n-1). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27682
[Bug tree-optimization/27657] [4.2 regression] bogus undefined reference error to static var with -g and -O
--- Comment #1 from amodra at bigpond dot net dot au 2006-05-29 03:07 --- Confirmed. The reference is the relocation for DW_AT_const_value. $ readelf -wi test.o [snip] <1><7a>: Abbrev Number: 8 (DW_TAG_variable) DW_AT_name: (indirect string, offset: 0x0): gconf_g_utf8_skip DW_AT_decl_file : 1 DW_AT_decl_line : 2 DW_AT_type: <89> DW_AT_const_value : 0 [snip] $ readelf -r test.o Relocation section '.rela.debug_info' at offset 0x53c contains 8 entries: [snip] 0085 0b01 R_PPC_ADDR32 utf8_skip_data + 0 -- amodra at bigpond dot net dot au changed: What|Removed |Added CC||amodra at bigpond dot net ||dot au Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-05-29 03:07:05 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27657
[Bug tree-optimization/27790] New: [4.1/4.2 Regression] Unrecognizable insn with -ftree-vectorize -O1 -msse2
[EMAIL PROTECTED] ~ $ gcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.1/configure --prefix=/home/halcyon/gcc-test/bin-4.1/
--enable-languages=c,c++
Thread model: posix
gcc version 4.1.2 20060529 (prerelease)
gcc -c -ftree-vectorize -O1 -msse2 test.i
test.i: In function âbinarizeâ:
test.i:10: error: unrecognizable insn:
(insn 80 79 81 13 (set (reg:V16QI 84)
(us_minus:V16QI (mem:V16QI (plus:SI (reg:SI 62 [ D.1718 ])
(reg:SI 68 [ vect_p.39 ])) [0 S16 A128])
(reg:V16QI 82))) -1 (nil)
(nil))
test.i:10: internal compiler error: in extract_insn, at recog.c:2084
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
Reduced testcase:
void binarize ()
{
unsigned i, npixels;
unsigned char *b;
if (i == 1)
{
for (i = 0; i < npixels; i++)
b[i] = (b[i] > 225 ? 0xff : 0);
}
}
--
Summary: [4.1/4.2 Regression] Unrecognizable insn with -ftree-
vectorize -O1 -msse2
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: halcy0n at gentoo dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27790
[Bug target/27790] [4.1/4.2 Regression] Unrecognizable insn with -ftree-vectorize -O1 -msse2
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Keywords||ice-on-valid-code Target Milestone|--- |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27790
[Bug target/27790] [4.1/4.2 Regression] Unrecognizable insn with -ftree-vectorize -O1 -msse2
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-05-29 04:28 --- Confirmed, the bug is in ix86_expand_int_vcond. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-05-29 04:28:52 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27790
[Bug target/27790] [4.1/4.2 Regression] Unrecognizable insn with -ftree-vectorize -O1 -msse2
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-05-29 04:31 ---
This also can be reproduced on x86_64:
void binarize (int npixels, unsigned char *b)
{
int i;
for (i = 0; i < npixels; i++)
b[i] = (b[i] > 225 ? 0xff : 0);
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27790
[Bug libfortran/24459] [4.1 Only] gfortran namelist problem
--- Comment #19 from jvdelisle at gcc dot gnu dot org 2006-05-29 05:19 --- Subject: Bug 24459 Author: jvdelisle Date: Mon May 29 05:18:58 2006 New Revision: 114182 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114182 Log: 2006-05-28 Jerry DeLisle <[EMAIL PROTECTED]> PR libgfortran/24459 * io/list_read.c (nml_parse_qualifier): Leave loop spec end value at default value unless -std=f95 or if an array section is specified in namelist input. Warn if -pedantic. * io/io.h (st_parameter_dt): Add expanded_read flag. Modified: branches/gcc-4_1-branch/libgfortran/ChangeLog branches/gcc-4_1-branch/libgfortran/io/io.h branches/gcc-4_1-branch/libgfortran/io/list_read.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24459
[Bug libfortran/24459] [4.1 Only] gfortran namelist problem
--- Comment #20 from jvdelisle at gcc dot gnu dot org 2006-05-29 05:22 --- Subject: Bug 24459 Author: jvdelisle Date: Mon May 29 05:22:05 2006 New Revision: 114184 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114184 Log: 2006-05-28 Jerry DeLisle <[EMAIL PROTECTED]> PR libgfortran/24459 * gfortran.dg/namelist_24.f90: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/namelist_24.f90 Modified: branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24459
[Bug libfortran/24459] [4.1 Only] gfortran namelist problem
--- Comment #21 from jvdelisle at gcc dot gnu dot org 2006-05-29 05:23 --- Fixed now on 4.1 -- 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=24459
[Bug c/26818] [4.1 Regression] tree check: expected class �type�, have �exceptional� (error_mark) in finish_struct, at c-decl.c:5350 (time.c)
--- Comment #8 from reichelt at gcc dot gnu dot org 2006-05-29 06:44 --- Subject: Bug 26818 Author: reichelt Date: Mon May 29 06:44:46 2006 New Revision: 114187 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114187 Log: PR c/26818 * c-decl.c (finish_struct): Skip erroneous fields. * gcc.dg/struct-incompl-1.c: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/struct-incompl-1.c Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/c-decl.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26818
[Bug c++/27451] [4.1 regression] ICE with invalid asm statement
--- Comment #7 from reichelt at gcc dot gnu dot org 2006-05-29 06:50 --- Subject: Bug 27451 Author: reichelt Date: Mon May 29 06:50:07 2006 New Revision: 114189 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114189 Log: PR c++/27451 * stmt.c (expand_asm_operands): Skip asm statement with erroneous clobbers. * g++.dg/ext/asm9.C: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/asm9.C Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/stmt.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27451
[Bug fortran/27703] Linking example programs for PLplot causes error messages about multiple definition of __gfortran_transfer_character
--- Comment #4 from arjen dot markus at wldelft dot nl 2006-05-29 06:54 --- Subject: Re: Linking example programs for PLplot causes error messages about multiple definition of __gfortran_transfer_character pault at gcc dot gnu dot org wrote: >--- Comment #3 from pault at gcc dot gnu dot org 2006-05-28 12:11 --- >Arjen, > > > >>I tried this with gfortran 4.20 too (the report file was indeed >>created with 4.1, but the result with the newer version was quite the >>same). It happens when I build version 5.6.1 of PLplot (http://plplot.sf.net) >>using shared libraries. It does not when I disable the shared libraries >>option. >> >> > >If you go well back into last year on the gfortran list, you will find some >corespondence on shared libraries and Cygwin. I do not recall the exact >details but there was something very iffy about the mixture of fortran IO, >shared libraries and Cygwin. I think that you might have to stick with a >static build. > > Thanks for this explanation. It is a pity, because we dearly want the shared library option to work. (We had quite some problems getting it to work on Cygwin at all with GCC, but it turned out that libtool could not identify whether shared libraries worked or not because of a missing "file" command. At least that seemed to be the main cause.) Anyway, the message is clear - we will refrain from shared libraries for Fortran 95 at the moment. Regards, Arjen -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27703
[Bug c++/27716] [4.1 regression] ICE with invalid assignment
--- Comment #6 from reichelt at gcc dot gnu dot org 2006-05-29 06:56 --- Subject: Bug 27716 Author: reichelt Date: Mon May 29 06:56:07 2006 New Revision: 114190 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114190 Log: PR c++/27716 * typeck.c (build_modify_expr): Test arguments for error_operand_p. * g++.dg/other/assign1.C: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/g++.dg/other/assign1.C Modified: branches/gcc-4_1-branch/gcc/cp/ChangeLog branches/gcc-4_1-branch/gcc/cp/typeck.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27716
