[Bug fortran/26769] Implement transpose() and reshape() for real instead of using integer
--- Comment #9 from jakub at gcc dot gnu dot org 2006-04-22 07:09 --- Subject: Bug 26769 Author: jakub Date: Sat Apr 22 07:08:58 2006 New Revision: 113169 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113169 Log: PR fortran/26769 * iresolve.c (gfc_resolve_reshape): Use reshape_r16 for real(16). (gfc_resolve_transpose): Use transpose_r16 for real(16). * Makefile.am (i_transpose_c): Add generated/transpose_r16.c. (i_reshape_c): Add generated/reshape_r16.c. * Makefile.in: Regenerated. * generated/transpose_r16.c: Generated new file. * generated/redhape_r16.c: Generated new file. Added: trunk/libgfortran/generated/reshape_r16.c trunk/libgfortran/generated/transpose_r16.c Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/iresolve.c trunk/libgfortran/ChangeLog trunk/libgfortran/Makefile.am trunk/libgfortran/Makefile.in -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26769
[Bug c++/27235] goto crossing P.O.D. initialization
--- Comment #5 from acahalan at gmail dot com 2006-04-22 07:12 --- No legal C++ code would break if g++ were less incompatible with C. Why be incompatible? There are cases where gcc takes far greater liberties with the standards, breaking fully legal code. (trigraphs for example) The proposed change would allow for easier reuse of C code, which is certainly a benefit. If the new rule is to follow standards to the letter by default, then trigraphs are an urgent need. Otherwise, the goto behavior should change. I don't see how it is justified to break valid code, yet refuse a change that would allow greater compatibility with C. -- acahalan at gmail dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27235
[Bug fortran/26769] Implement transpose() and reshape() for real instead of using integer
--- Comment #10 from jakub at gcc dot gnu dot org 2006-04-22 07:13 --- Subject: Bug 26769 Author: jakub Date: Sat Apr 22 07:13:20 2006 New Revision: 113170 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113170 Log: PR fortran/26769 * iresolve.c (gfc_resolve_reshape): Use reshape_r16 for real(16). (gfc_resolve_transpose): Use transpose_r16 for real(16). * Makefile.am (i_transpose_c): Add generated/transpose_r16.c. (i_reshape_c): Add generated/reshape_r16.c. * Makefile.in: Regenerated. * generated/transpose_r16.c: Generated new file. * generated/redhape_r16.c: Generated new file. Added: branches/gcc-4_1-branch/libgfortran/generated/reshape_r16.c branches/gcc-4_1-branch/libgfortran/generated/transpose_r16.c Modified: branches/gcc-4_1-branch/gcc/fortran/ChangeLog branches/gcc-4_1-branch/gcc/fortran/iresolve.c branches/gcc-4_1-branch/libgfortran/ChangeLog branches/gcc-4_1-branch/libgfortran/Makefile.am branches/gcc-4_1-branch/libgfortran/Makefile.in -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26769
[Bug c++/27257] Error integer compare in g++ 4.1.0
--- Comment #1 from pluto at agmk dot net 2006-04-22 08:23 --- (In reply to comment #0) > int b = 0X8000; > if ((b - 10) < 0) b - 10 is 0xff(...)7ff6 and this is an integer overflow. [ cite: c++ standard / $5.5 ] if during the evaluation of an expression the result isn't mathematically defined nor in the range of representable values for its type the behaviuor is undefined, unless such an expression is a constant expression, in which case the program is ill-formed. (...) [ /cite ] so, use -fwrapv (man g++) to get not quite correct behaviour. -- pluto at agmk dot net changed: What|Removed |Added CC||pluto at agmk dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27257
[Bug c++/27255] Including C++ header declares C functions
--- Comment #3 from pcarlini at suse dot de 2006-04-22 08:27 --- (In reply to comment #2) > I don't think this is the same bug. I can see how including would > declare printf but why in the world would including or > declare printf, strcpy, etc. This is definitely allowed by the Standard. It's the same bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27255
[Bug libstdc++/27256] gcc 4.1.0 compilation fails on RHEL AS 3 (x86_64)
--- Comment #1 from pcarlini at suse dot de 2006-04-22 08:31 --- (In reply to comment #0) > /usr/bin/ld: BFD 2.14.90.0.4 20030523 internal error, aborting at > ../../bfd/elf64-x86-64.c line 2067 in elf64_x86_64_relocate_section > > /usr/bin/ld: Please report this bug. > > collect2: ld returned 1 exit status As you can see, the problem affects ld, the linker, *not* libstdc++. Please report it to the binutils project. Thanks. -- pcarlini at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27256
[Bug libstdc++/26974] hidden declarations klobber STL
--- Comment #30 from pcarlini at suse dot de 2006-04-22 08:47 ---
(In reply to comment #28)
> template
> _OutputIterator
> fill_n(_OutputIterator __first, _Size __n, const _Tp& __value)
> {
> for (; __n > 0; --__n, ++__first)
[snip]
> template
> void f(W* p) { fill_n(mine1::mini_iter(p), 1, *p); }
[snip]
> template
> T operator,(bar i, T t) { std::cerr << "interceptor\n"; return i; }
[snip]
> then the declaration does *not* intercept the STL, i.e. it does not fail.
No mistery, here, __n is an int, doesn't match bar of the overloaded operator,
Ok, let's close this one. Thanks and sorry about a bit of confusion on my part
in the first comments.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution||INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26974
[Bug libstdc++/27256] gcc 4.1.0 compilation fails on RHEL AS 3 (x86_64)
--- Comment #2 from pcarlini at suse dot de 2006-04-22 08:50 --- (In reply to comment #1) > > /usr/bin/ld: BFD 2.14.90.0.4 20030523 internal error, aborting at > As you can see, the problem affects ld, the linker, *not* libstdc++. Please > report it to the binutils project. Thanks. By the way, 2.14.90.* is *very* old: before reporting any bug anywhere about it, please consider an upgrade, in the first place. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27256
[Bug c/27259] New: undefined reference to 'sqrt'
I am using gcc compiler
Below is the program:
4. void main()
5. {
6.clrscr();
7.char z = 'y';
8.double x;
9.do
10.{
11. printf("\nGive positive number ");
12. scanf("%lf",&x);
13. if (x<0)
14.{printf("\n wrong number \n");
15. continue;
16. }
17. printf("The square root = %lf \n\n",sqrt(x));
18. printf("Do you like to continue(y/n) ");
19. z = getche();
20. }
21.while (z == 'y');
22.getch();
23. }
It doesn't work even if I remove conio.h and clrscr().
The report is: undefined reference to 'sqrt'
--
Summary: undefined reference to 'sqrt'
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: msborowi at cyf-kr dot edu dot pl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27259
[Bug middle-end/27260] New: [4.1 Regression] ICE in expand_expr_real_1, at expr.c:6750
6750 gcc_assert (GET_MODE (DECL_RTL (exp)) == pmode); (gdb) print pmode $1 = SImode (gdb) call debug_tree(exp) unit size align 32 symtab 0 alias set -1 precision 32 min max pointer_to_this > used ignored SI file cmdTrace.min.i line 28 size unit size align 32 (reg:QI 141 [ D.1351 ])> #0 fancy_abort (file=0x106e1d60 "../../gcc-4_1-branch/gcc/expr.c", line=6750, function=0x106e2268 "expand_expr_real_1") at diagnostic.c:602 #1 0x10255a6c in expand_expr_real_1 (exp=0xf7f7d930, target=0x0, tmode=VOIDmode, modifier=EXPAND_NORMAL, alt_rtl=0x0) at expr.c:6750 #2 0x10255f0c in expand_expr_real_1 (exp=0xf7f7e380, target=0x0, tmode=VOIDmode, modifier=EXPAND_NORMAL, alt_rtl=0x0) at expr.c:6844 #3 0x10254dcc in expand_expr_real (exp=0xf7f7e380, target=0x0, tmode=VOIDmode, modifier=EXPAND_NORMAL, alt_rtl=0x0) at expr.c:6523 #4 0x10160034 in expand_expr (exp=0xf7f7e380, target=0x0, mode=VOIDmode, modifier=EXPAND_NORMAL) at expr.h:493 #5 0x1015fa90 in precompute_register_parameters (num_actuals=3, args=0xffa7fbc0, reg_parm_seen=0xffa7fed4) at calls.c:662 #6 0x101649dc in expand_call (exp=0xf7f7f330, target=0xf7f76d00, ignore=0) at calls.c:2545 #7 0x1014b37c in expand_builtin_memset (arglist=0xf7f7e4e0, target=0xf7f76d00, mode=SImode, orig_exp=0xf7f79f60) at builtins.c:3520 #8 0x1015074c in expand_builtin (exp=0xf7f79f60, target=0xf7f76d00, subtarget=0x0, mode=SImode, ignore=0) at builtins.c:6069 This is caused by the patch for PR27095 -- Summary: [4.1 Regression] ICE in expand_expr_real_1, at expr.c:6750 Product: gcc Version: 4.1.1 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rguenth at gcc dot gnu dot org GCC target triplet: powerpc-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27260
[Bug middle-end/27260] [4.1 Regression] ICE in expand_expr_real_1, at expr.c:6750
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-04-22 11:04 ---
Testcase:
typedef unsigned int size_t;
typedef void *ClientData;
typedef struct Tcl_Interp { } Tcl_Interp;
extern char *addRE;
extern char *rmRE;
extern char *aproposRE;
typedef struct _mod_trace { char **re_ptr; } ModTrace;
static char module_name[] = "cmdTrace.c";
static char _all_off[] = "-.*";
static ModTrace TraceSelect[] = {
{ &addRE, "load", _all_off, 0 }
, { &rmRE, "unload", _all_off, 0 }
, { &aproposRE, "apropos", _all_off, 0 }
};
int cmdModuleTrace( ClientData client_data, Tcl_Interp *interp, int
argc, char *argv[]) {
int i, k;
int cmd_tab_size;
char *cmd_table;
cmd_tab_size = sizeof( TraceSelect) / sizeof( TraceSelect[ 0]);
if((char *) ((void *)0) == (cmd_table = (char *) malloc( cmd_tab_size)))
return((0 == Module_Error( 70, module_name, 306, ((void *)0))) ? 0 :
1); (__builtin_constant_p (cmd_tab_size) && (cmd_tab_size) == 0 ?
(__warn_memset_zero_len (), (void) (!i), (void) (cmd_tab_size), (void *)
(cmd_table)) : ((__builtin_object_size (cmd_table, 0) != (size_t) -1) ?
__builtin___memset_chk (cmd_table, !i, cmd_tab_size, __builtin_object_size
(cmd_table, 0)) : __memset_ichk (cmd_table, !i, cmd_tab_size)));
}
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||amodra at bigpond dot net
||dot au
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27260
[Bug middle-end/27260] [4.1 Regression] ICE in expand_expr_real_1, at expr.c:6750
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-04-22 11:15 ---
More reduced testcase:
void cmdModuleTrace(int i)
{
char *cmd_table;
cmd_table = (char *) __builtin_malloc( 3);
__builtin_memset (cmd_table, !i, 3);
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27260
[Bug middle-end/27260] [4.1 Regression] ICE in expand_expr_real_1, at expr.c:6750
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-04-22 13:08 ---
The problem is we expand the value in QI mode because of
val = builtin_save_expr (val);
len = builtin_save_expr (len);
len_rtx = expand_expr (len, NULL_RTX, VOIDmode, 0);
dest_mem = get_memory_rtx (dest, len);
if (TREE_CODE (val) != INTEGER_CST)
{
tree cval;
rtx val_rtx;
cval = fold_build1 (CONVERT_EXPR, unsigned_char_type_node, val);
val_rtx = expand_expr (cval, NULL_RTX, VOIDmode, 0);
The "easiest" solution is something like
Index: gcc/builtins.c
===
*** gcc/builtins.c (revision 113168)
--- gcc/builtins.c (working copy)
*** expand_builtin_memset (tree arglist, rtx
*** 3437,3442
--- 3437,3443
/* Stabilize the arguments in case we fail. */
dest = builtin_save_expr (dest);
val = builtin_save_expr (val);
+ expand_expr (val, NULL_RTX, VOIDmode, 0);
len = builtin_save_expr (len);
len_rtx = expand_expr (len, NULL_RTX, VOIDmode, 0);
which forces expansion in the original mode. This may be not the best fix
though, as we then get (subreg:QI (reg:SI)) for the expansion of cval.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27260
[Bug middle-end/27260] [4.1 Regression] ICE in expand_expr_real_1, at expr.c:6750
--- Comment #4 from aj at gcc dot gnu dot org 2006-04-22 13:12 --- The original ICE happens on PPC and IA64. I have not checked whether the reduced testcase ICEs on both. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27260
[Bug middle-end/27260] [4.1/4.2 Regression] ICE in expand_expr_real_1, at expr.c:6750
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-04-22 13:19 --- Testcase also fails on mainline x86_64 with -Os. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added GCC target triplet|powerpc-linux | Summary|[4.1 Regression] ICE in |[4.1/4.2 Regression] ICE in |expand_expr_real_1, at |expand_expr_real_1, at |expr.c:6750 |expr.c:6750 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27260
[Bug other/27261] New: -ftrapv doesn't work.
#include
int main()
{
int x = 0x8000;
std::printf( "%08x\n", x );
x *= 2;
std::printf( "%08x\n", x );
// still here?
std::puts( "-ftrapv doesn't work :(" );
return 0;
}
$ g++ signed_overflow_3.cpp; ./a.out; echo $?
8000
-ftrapv doesn't work :(
0
gcc version 4.1.1 20060419 (prerelease)
--
Summary: -ftrapv doesn't work.
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pluto at agmk dot net
GCC build triplet: x86-64-linux
GCC host triplet: x86-64-linux
GCC target triplet: x86-64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27261
[Bug other/27261] -ftrapv doesn't work.
--- Comment #1 from pluto at agmk dot net 2006-04-22 14:07 --- of course command line shoud be: $ g++ signed_overflow_3.cpp -ftrapv ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27261
[Bug libstdc++/27258] ostrstream objects and static variables cause segmentation fault
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-22 15:33 --- Can you try a 4.0.x or 4.1.0 as 3.4.x is no longer being updated and I think this fixed already. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c++ |libstdc++ http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27258
[Bug target/26885] [4.1/4.2 regression] -m64 -m32 no longer creates 32-bit object
--- Comment #6 from hjl at lucon dot org 2006-04-22 15:33 --- [EMAIL PROTECTED] stage1-gcc]$ ./xgcc -B./ -c -g -v /tmp/x.s -gstabs -gdwarf-2 Reading specs from ./specs Target: x86_64-unknown-linux-gnu Configured with: /net/gnu-13/export/gnu/src/gcc/gcc/configure --enable-clocale=gnu --with-system-zlib --with-demangler-in-ld --enable-shared --enable-threads=posix --enable-haifa --enable-checking=assert --prefix=/usr/gcc-4.2 --with-local-prefix=/usr/local Thread model: posix gcc version 4.2.0 20060421 (experimental) [trunk revision 113135 clean] ./as --gstabs -V -Qy -o x.o /tmp/x.s GNU assembler version 2.17.50.0.1 (x86_64-unknown-linux-gnu) using BFD version 2.17.50.0.1 20060417 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26885
[Bug c++/27235] goto crossing P.O.D. initialization
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-04-22 15:34 --- GCC is not going to implement by default a non standard version of C++ (well some extensions are on by default but those are usually more defined than this). -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27235
[Bug c++/27257] Error integer compare in g++ 4.1.0
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-04-22 15:35 --- This is signed int overflow being undefined, in fact I should I know because I was the one who write the patch to optimize this. -- 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=27257
[Bug libmudflap/26446] Running large program compiled with mudflap aborts even before reaching main()
--- Comment #4 from fche at redhat dot com 2006-04-22 15:37 --- (In reply to comment #3) > > I investigated further and found that it is not the size of the memory that > matters. The problem seems to be that we also use fortran code, which is not > mudflapped, but needs the gfortran library. The mudflapped C code uses > malloc(), which gets wrapped into calls to __mfwrap_malloc(). Unfortunately, > libgfortran also uses malloc(), which is instrumented by libmudflap but > shouldn't, as this exactly is causing the error. The link-time wrapping of malloc is designed precisely so that other uninstrumented libraries that call malloc by name still get registered in the libmudflap runtime. That way, pointers from these libraries may make their way to an instrumented routine, and be used without error. Does MUDFLAP_OPTIONS=-trace-calls produce anything? -- fche at redhat dot com changed: What|Removed |Added CC||fche at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26446
[Bug c/27259] undefined reference to 'sqrt'
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-22 15:37 --- Use -lm when linking the math functions have been in libm for 20 or more years now on UNIX. -- 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=27259
[Bug middle-end/27260] [4.1/4.2 Regression] ICE in expand_expr_real_1, at expr.c:6750
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Severity|normal |blocker Known to fail||4.1.1 4.2.0 Known to work||4.1.0 Target Milestone|--- |4.1.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27260
[Bug other/27261] -ftrapv doesn't work.
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-04-22 15:41 --- *** This bug has been marked as a duplicate of 19020 *** -- 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=27261
[Bug middle-end/19020] libcalls are removed (-ftrapv does not work)
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-04-22 15:41 --- *** Bug 27261 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pluto at agmk dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19020
[Bug libmudflap/26864] multithreaded mudflap not working
--- Comment #2 from fche at redhat dot com 2006-04-22 15:42 --- Indeed, -fmudflapth used to imply -fmudflap, but something broke that association. As a workaround, the test case works if both -fmudflap and -fmudflapth are specified. -- fche at redhat dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |fche at redhat dot com |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-04-22 15:42:15 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26864
[Bug fortran/27096] Automatic charlen pointer array result produces and ICE
--- Comment #5 from pault at gcc dot gnu dot org 2006-04-22 15:47 --- trunk and 4.1 have diverged too far, especially in characters, for the fix to work on 4.1. I started trying to make up the difference but it is just too much to be worthwhile. I am marking this as fixed on trunk. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27096
[Bug fortran/27113] TODO: Complex array constructors in tonto-2.2
--- Comment #5 from pault at gcc dot gnu dot org 2006-04-22 15:49 --- trunk and 4.1 have diverged too far, especially in characters, for the fix to work on 4.1. I started trying to make up the difference but it is just too much to be worthwhile. I am marking this as fixed on trunk. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27113
[Bug libmudflap/26864] multithreaded mudflap not working
--- Comment #3 from fche at redhat dot com 2006-04-22 16:22 --- patch committed to mainline -- fche at redhat dot com changed: What|Removed |Added Status|ASSIGNED|WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26864
[Bug libmudflap/26864] multithreaded mudflap not working
--- Comment #4 from fche at gcc dot gnu dot org 2006-04-22 16:22 --- Subject: Bug 26864 Author: fche Date: Sat Apr 22 16:22:54 2006 New Revision: 113179 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113179 Log: 2006-04-22 Frank Ch. Eigler <[EMAIL PROTECTED]> PR libmudflap/26864 * common.opt (flag_mudflap_threads): Overload flag_mudflap. * tree-mudflap.c (flag_mudflap_threads): Derive from flag_mudflap. Modified: trunk/gcc/ChangeLog trunk/gcc/common.opt trunk/gcc/tree-mudflap.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26864
[Bug crypto/27228] java.security.InvalidAlgorithmParameterException
--- Comment #8 from cvs-commit at developer dot classpath dot org 2006-04-22 18:11 --- Subject: Bug 27228 CVSROOT:/cvsroot/classpath Module name:classpath Branch: Changes by: Casey Marshall <[EMAIL PROTECTED]> 06/04/22 17:57:19 Modified files: . : ChangeLog gnu/javax/crypto/jce/sig: DHKeyPairGeneratorSpi.java gnu/javax/crypto/key/dh: GnuDHKeyPairGenerator.java Log message: 2006-04-22 Casey Marshall <[EMAIL PROTECTED]> Fixes PR classpath/27228. * gnu/javax/crypto/jce/sig/DHKeyPairGeneratorSpi.java (initialize): also accept `DHParameterSpec.' * gnu/javax/crypto/key/dh/GnuDHKeyPairGenerator.java (setup): handle a passed-in `DHParameterSpec' properly. (generate): don't check if the random exponent is less than `q - 1' if no `q' was specified. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/classpath/classpath/ChangeLog.diff?tr1=1.7188&tr2=1.7189&r1=text&r2=text http://cvs.savannah.gnu.org/viewcvs/classpath/classpath/gnu/javax/crypto/jce/sig/DHKeyPairGeneratorSpi.java.diff?tr1=1.1&tr2=1.2&r1=text&r2=text http://cvs.savannah.gnu.org/viewcvs/classpath/classpath/gnu/javax/crypto/key/dh/GnuDHKeyPairGenerator.java.diff?tr1=1.4&tr2=1.5&r1=text&r2=text -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27228
[Bug tree-optimization/27218] [4.1/4.2 regression] ICE in get_indirect_ref_operands, at tree-ssa-operands.c:1515, inlining produces non-gimple
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-04-22 18:13 --- The inliner is not producing the NOP_EXPR at all but instead if comes from build_fold_addr_expr_with_type And: if (TREE_TYPE (t) != ptrtype) t = build1 (NOP_EXPR, ptrtype, t); Here the types don't match but they are compatible. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27218
[Bug tree-optimization/27218] [4.1/4.2 regression] ICE in get_indirect_ref_operands, at tree-ssa-operands.c:1515, inlining produces non-gimple
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-04-22 18:29 ---
This patch fixes it for me (but I don't have time right now to test it):
Index: tree-inline.c
===
--- tree-inline.c (revision 112997)
+++ tree-inline.c (working copy)
@@ -2073,6 +2077,7 @@ expand_call_inline (basic_block bb, tree
if (CALL_EXPR_RETURN_SLOT_OPT (t))
{
return_slot_addr = build_fold_addr_expr (modify_dest);
+ STRIP_USELESS_TYPE_CONVERSION (return_slot_addr);
modify_dest = NULL;
}
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27218
[Bug c++/27224] Read twice and write on a variable in same expression
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-04-22 18:33 --- (In reply to comment #4) > One has still to use the -Wsequence-point, in C++? > It would be good if there was no need to explicitly use such a switch... For 4.1 (and maybe 4.0 I forget), -Wall includes -Wsequence-point for C++. And if you read the instructions for filing a bug, it says to use -Wall -W before filing a bug. Reopening to -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27224
[Bug c++/27224] Read twice and write on a variable in same expression
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-04-22 18:33 --- As a dup of bug 15145. *** This bug has been marked as a duplicate of 15145 *** -- 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=27224
[Bug c++/15145] Implementing -Wsequence-point for C++ would be very useful
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-04-22 18:33 --- *** Bug 27224 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||moura at kdewebdev dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15145
[Bug target/27212] vec_cmplt followed by a vec_all_ge, gives two vcmpgtuh instructions
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-04-22 18:36 --- Confirmed. Note I was talking about the internal representation in that, the instructions are not modeled correctly. -- 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-04-22 18:36:49 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27212
[Bug tree-optimization/27236] [4.1/4.2 Regression] inliner creates an INDIRECT_REF without TREE_THIS_VOLATILE set for *a
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-04-22 19:07 --- ipa-pure-const is just a symtom of the problem. TREE_THIS_VOLATILE is not set on the INDIRECT_REF. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.1/4.2 Regression] ipa- |[4.1/4.2 Regression] inliner |pure-const says functions |creates an INDIRECT_REF |which read from volatile mem|without TREE_THIS_VOLATILE |are pure|set for *a http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27236
[Bug crypto/27228] java.security.InvalidAlgorithmParameterException
--- Comment #9 from david at jpackage dot org 2006-04-22 19:18 --- Maybe we can consider moving these class before closing this bug? I am also wondering why the are Diffie Hellman classes in the `sig' package. DH is not a digital signature algorithm, unless we are accounting for the obvious similarities between DH and DSA (but then, ElGamal is similar as well). But then there are ElGamal classes are in javax.crypto.key.dh. How confusing can we get? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27228
[Bug tree-optimization/27236] [4.1/4.2 Regression] inliner creates an INDIRECT_REF without TREE_THIS_VOLATILE set for *a
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-04-22 19:19 ---
One more inliner fix:
Index: tree-inline.c
===
--- tree-inline.c (revision 112997)
+++ tree-inline.c (working copy)
@@ -590,6 +590,7 @@ copy_body_r (tree *tp, int *walk_subtree
if (n)
{
tree new;
+ tree old;
/* If we happen to get an ADDR_EXPR in n->value, strip
it manually here as we'll eventually get ADDR_EXPRs
which lie about their types pointed to. In this case
@@ -598,13 +599,17 @@ copy_body_r (tree *tp, int *walk_subtree
does other useful transformations, try that first, though. */
tree type = TREE_TYPE (TREE_TYPE ((tree)n->value));
new = unshare_expr ((tree)n->value);
+ old = *tp;
*tp = fold_indirect_ref_1 (type, new);
if (! *tp)
{
if (TREE_CODE (new) == ADDR_EXPR)
*tp = TREE_OPERAND (new, 0);
else
- *tp = build1 (INDIRECT_REF, type, new);
+ {
+ *tp = build1 (INDIRECT_REF, type, new);
+ TREE_THIS_VOLATILE (*tp) = TREE_THIS_VOLATILE (old);
+ }
}
*walk_subtrees = 0;
return NULL;
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||hubicka at gcc dot gnu dot
||org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27236
[Bug crypto/27228] java.security.InvalidAlgorithmParameterException
--- Comment #10 from csm at gnu dot org 2006-04-22 19:26 --- I don't know; a confusing internal structure doesn't impact anyone trying to use Classpath with their application, they'll just want their program to work. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27228
[Bug libstdc++/27258] ostrstream objects and static variables cause segmentation fault
--- Comment #2 from pcarlini at suse dot de 2006-04-22 19:47 --- Indeed, I can't reproduce with 4.1.0, 4.1.1 pre and mainline. The problem seems still present in 4_0-branch, but frankly I have no idea which patch fixed it, I seriously doubt was a libstdc++ patch... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27258
[Bug libstdc++/27258] ostrstream objects and static variables cause segmentation fault
--- Comment #3 from pcarlini at suse dot de 2006-04-22 19:54 --- *** This bug has been marked as a duplicate of 26123 *** -- pcarlini at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27258
[Bug libstdc++/26123] [3.4/4.0 Regression] Segmentation fault in constructor of std::ostream::sentry::sentry
--- Comment #12 from pcarlini at suse dot de 2006-04-22 19:54 --- *** Bug 27258 has been marked as a duplicate of this bug. *** -- pcarlini at suse dot de changed: What|Removed |Added CC||tim at yeung dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26123
[Bug libgcj/27262] New: org.w3c.dom.Element.getElementById returns null after manual (setIdAttribute) identifying of element in Document instance.
Parsing a Document instance from file, setting the "id" attribute of an element
on that instance to some value, and then flagging the "id" attribute for that
element to be the IdAttribute using (Element).setIdAttribute("id", true) does
not seem to work.
Retrieving that very same element via getElementById on the Document instance
will return null, where one would expect the element.
[attaching tarball demonstrating this in a simple java script (67 lines)]
--
Summary: org.w3c.dom.Element.getElementById returns null after
manual (setIdAttribute) identifying of element in
Document instance.
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgcj
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kalle at enrogue dot com
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27262
[Bug libgcj/27262] org.w3c.dom.Element.getElementById returns null after manual (setIdAttribute) identifying of element in Document instance.
--- Comment #1 from kalle at enrogue dot com 2006-04-22 20:02 --- Created an attachment (id=11316) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11316&action=view) Demonstrates the bug. This attachment contains: - CREATION (a bash-script which contains the 2 commands used in generating binary) - simple (binary result) - simple.class (class result) - simple.java (source) - simplemain.i - simplemain.o - simplemain.s - simple.o - simple.s - simple.xhtml (required supplemental file (1 line big)) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27262
[Bug tree-optimization/27218] [4.1/4.2 regression] ICE in get_indirect_ref_operands, at tree-ssa-operands.c:1515, inlining produces non-gimple
--- Comment #8 from rguenth at gcc dot gnu dot org 2006-04-22 20:05 --- Bootstrapped and tested on x86_64-unknown-linux-gnu. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27218
[Bug other/20128] ice with mudflap + profile generate
--- Comment #8 from fche at redhat dot com 2006-04-22 20:10 --- The problem is triggered for the synthetic _gcov_* type global variables that the profiling code emits. mudflap tries to register them with libmudflap. -- fche at redhat dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |fche at redhat dot com |dot org | Status|NEW |ASSIGNED Last reconfirmed|2005-12-28 06:29:27 |2006-04-22 20:10:25 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20128
[Bug middle-end/27260] [4.1/4.2 Regression] ICE in expand_expr_real_1, at expr.c:6750
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-04-22 20:22 --- Confirmed. -- 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-04-22 20:22:17 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27260
[Bug target/27234] no way to stop gcc from mucking with the stack
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-04-22 20:24 --- Use -fno-sibcalling if you cannot use this optimization because you are violating the ABI really and since GCC depends on the ABI being followed, there is almost nothing GCC can do. If the kernel wants to do tricks like this, that is their own business and not really GCC business to know the kernel is not following the ABI that has been there since day one. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27234
[Bug c++/27211] Bogus error "template definition of non-template" when there is no non-template
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-22 20:27 --- I don't know if it is that bogus. First it assumes if it is not defiend, it is a normal member function and not a templated member function which seems reasonable. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27211
[Bug c++/27227] [4.0/4.1/4.2 Regression] rejects valid code with some extern "C"
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.0.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27227
[Bug libstdc++/27258] ostrstream objects and static variables cause segmentation fault
--- Comment #4 from tim at yeung dot com 2006-04-22 20:33 --- Thank you. We will upgrade to 4.1.x -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27258
[Bug c/23577] spurious warnings about unhandled cases in switches (need VRP and control flow in front-end)
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Priority|P3 |P5 Last reconfirmed|-00-00 00:00:00 |2006-04-22 20:35:06 date|| Summary|spurious warnings about |spurious warnings about |unhandled cases in switches |unhandled cases in switches ||(need VRP and control flow ||in front-end) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23577
[Bug target/27234] no way to stop gcc from mucking with the incoming argument stack
--- Comment #6 from rguenth at gcc dot gnu dot org 2006-04-22 20:35 --- So you want __attribute__((incoming_stack_frame_read_only)). -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-04-22 20:35:44 date|| Summary|no way to stop gcc from |no way to stop gcc from |mucking with the stack |mucking with the incoming ||argument stack http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27234
[Bug target/27051] Compiler generates .sdata when -mno-sdata specified
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-04-22 20:36 --- Patch posted: http://gcc.gnu.org/ml/gcc-patches/2006-04/msg00825.html -- pinskia at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2006- ||04/msg00825.html Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||patch, wrong-code Last reconfirmed|-00-00 00:00:00 |2006-04-22 20:36:38 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27051
[Bug libfortran/25370] Bad value for sqrt of double complex
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-04-22 20:39 --- THis is not a libgfortran bug but rather a bug in the libm on your system. The libgfortran version of csqrt was fixed and works. Glibc's version was also fixed at the same time. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25370
[Bug preprocessor/26897] character \ in #include directive
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-04-22 20:42 --- Also strings have two different phases which is why the handing is different IIRC. You should point out in the standard why you think this behavior is wrong really before filing a bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26897
[Bug c++/21251] Placement into shared memory
--- Comment #13 from pinskia at gcc dot gnu dot org 2006-04-22 20:44 --- There is no way non PODs will ever work with shared memory. This is why they are called non-PODs and they never should be shared outside of the program. In fact non-PODs cannot be passed via var-args or even look at offsetof for each of the fields. -- 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=21251
[Bug middle-end/26363] disabling switch() default
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-04-22 20:52 --- This is not really that useful, the problem comes down to if the user messes up (which is 90% of the time anyways), they get a crash in their program and blame GCC. So exosing stuff like this is crazy to do really. And getting a person to annotate their code with these attributes just get more and crazy. Instead it is just better to improve the optimizers instead of adding attributes to work around the optimizers not working for your case. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26363
[Bug c/26369] value expectation attribute
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-04-22 20:52 --- This is not really that useful, the problem comes down to if the user messes up (which is 90% of the time anyways), they get a crash in their program and blame GCC. So exosing stuff like this is crazy to do really. And getting a person to annotate their code with these attributes just get more and crazy. Instead it is just better to improve the optimizers instead of adding attributes to work around the optimizers not working for your case. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26369
[Bug bootstrap/25461] fastjar is broken on i386-*-freebsd
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-04-22 20:55 --- FastJar has since been removed from GCC's sources -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25461
[Bug fastjar/20941] Incorrect case for META-INF with fastjar
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-04-22 20:56 --- FastJar has since been removed from GCC's sources -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20941
[Bug fastjar/21822] fastjar/jartool.c's usage of MAXPATHLEN
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-04-22 20:57 --- FastJar has since been removed from GCC's sources -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21822
[Bug fastjar/21826] fastjar does not look to see if mkdir takes one or two arguments
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-04-22 20:57 --- FastJar has since been removed from GCC's sources -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21826
[Bug fastjar/13020] zip-style comments
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-04-22 20:58 --- FastJar has since been removed from GCC's sources -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13020
[Bug target/27234] no way to stop gcc from mucking with the incoming argument stack
--- Comment #7 from schwab at suse dot de 2006-04-22 21:09 --- It's called __attribute__((syscall_linkage)) on ia64. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27234
[Bug tree-optimization/27236] [4.1/4.2 Regression] inliner creates an INDIRECT_REF without TREE_THIS_VOLATILE set for *a
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-04-22 21:37 --- Bootstrapped and tested on x86_64-unknown-linux-gnu. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27236
[Bug c++/26534] [4.1/4.2 Regression] bitfield wrong optimize
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |mark at codesourcery dot com |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26534
[Bug c/27263] New: armv5te-linux-gnueabi-gcc-4.1 fails to compile libquicktime-0.9.7-0.4/plugins/opendivx/encore50/text_code_mb.c
Target: armv5te-linux-gnueabi
Configured with: ../src/configure -v --enable-languages=c,c++ --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--with-gxx-include-dir=/usr/armv5te-linux-gnueabi/include/c++/4.1.0
--program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu
--enable-libstdcxx-debug --with-cpu=arm926ej-s --with-tune=arm10tdmi
--with-float=softfp --with-fpu=vfp --enable-checking=release
--program-prefix=armv5te-linux-gnueabi-
--includedir=/usr/armv5te-linux-gnueabi/include --build=i486-linux-gnu
--host=i486-linux-gnu --target=armv5te-linux-gnueabi
Thread model: posix
gcc version 4.1.0
Bug:
libquicktime-0.9.7-0.4$ (cd plugins/opendivx/encore50/;
armv5te-linux-gnueabi-gcc-4.1 -DHAVE_CONFIG_H -I. -I. -I../../..
-I../../../include/quicktime -O3 -funroll-all-loops -fomit-frame-pointer
-finline-functions -Wall -Winline -MT text_code_mb.lo -MD -MP -MF
.deps/text_code_mb.Tpo -c text_code_mb.c -fPIC -DPIC -o .libs/text_code_mb.o)
text_code_mb.c: In function 'CodeMB':
text_code_mb.c:233: error: unrecognizable insn:
(insn 1773 1770 1772 50 (set (reg:HI 12 ip)
(mem:HI (plus:SI (mult:SI (reg:SI 11 fp [orig:138 ivtmp.674 ]
[138])
(const_int 2 [0x2]))
(reg/v/f:SI 8 r8 [orig:154 rcoeff_ind ] [154])) [3 S4
A32])) -1 (nil)
(nil))
text_code_mb.c:233: internal compiler error: in extract_insn, at
recog.c:2084
Note: the same file can be compiled with -O1 (but not with -O2), or it can
be compiled with -O3 but not with -funroll-all-loops. Some buffer overflow
maybe?
Pre-processed source (relevant bit only):
Void CodeMB(Vop *curr, Vop *rec_curr, Vop *comp, Int x_pos, Int y_pos, UInt
width,
Int QP, Int Mode, Int *qcoeff)
{
Int k;
Int fblock[6][8][8];
Int coeff[384];
Int *coeff_ind;
Int *qcoeff_ind;
Int* rcoeff_ind;
Int x=0, y=0;
SInt *current=((void *)0), *recon, *compensated = ((void *)0);
UInt xwidth=0;
Int iblock[6][8][8];
Int rcoeff[6*64];
Int i, j;
Int type;
SInt tmp[64];
Int s;
int operation = curr->prediction_type;
Int max = GetVopBrightWhite(curr);
coeff_ind = coeff;
qcoeff_ind = qcoeff;
rcoeff_ind = rcoeff;
for (k = 0; k < 6; k++)
{
switch (k)
{
case 0:
x = x_pos;
y = y_pos;
xwidth = width;
current = (SInt *) GetImageData (GetVopY (curr));
break;
case 1:
x = x_pos + 8;
y = y_pos;
xwidth = width;
current = (SInt *) GetImageData (GetVopY (curr));
break;
case 2:
x = x_pos;
y = y_pos + 8;
xwidth = width;
current = (SInt *) GetImageData (GetVopY (curr));
break;
case 3:
x = x_pos + 8;
y = y_pos + 8;
xwidth = width;
current = (SInt *) GetImageData (GetVopY (curr));
break;
case 4:
x = x_pos / 2;
y = y_pos / 2;
xwidth = width / 2;
current = (SInt *) GetImageData (GetVopU (curr));
break;
case 5:
x = x_pos / 2;
y = y_pos / 2;
xwidth = width / 2;
current = (SInt *) GetImageData (GetVopV (curr));
break;
default:
break;
}
BlockPredict (current, x, y, xwidth, fblock[k]);
}
for (k = 0; k < 6; k++)
{
s = 0;
for (i = 0; i < 8; i++)
for (j = 0; j < 8; j++)
tmp[s++] = (SInt) fblock[k][i][j];
fdct_enc(tmp);
for (s = 0; s < 64; s++)
coeff_ind[s] = (Int) tmp[s];
if (k < 4) type = 1;
else type = 2;
BlockQuantH263(coeff_ind,QP,Mode,type,qcoeff_ind,
GetVopBrightWhite(curr),1);
BlockDequantH263(qcoeff_ind,QP,Mode,type,rcoeff_ind,1, 0,
GetVopBitsPerPixel(curr));
for (s = 0; s < 64; s++)
tmp[s] = (SInt) rcoeff_ind[s];
idct_enc(tmp);
s = 0;
for (i = 0; i < 8; i++)
for (j = 0; j < 8; j++)
iblock[k][i][j] = (Int)tmp[s++];
coeff_ind += 64;
qcoeff_ind += 64;
rcoeff_ind += 64;
if (Mode == 0||Mode==2)
for (i = 0; i < 8; i++)
for (j = 0; j < 8; j ++)
iblock[k][i][j] = (((GetVopBrightWhite(curr)) < 0) >
(iblock[k][i][j])) ? (0) : (iblock[k][i][j] ? (GetVopBrightWhite(curr)) :
0) > (iblock[k][i][j])) ? (0) : (iblock[k][i][j];
switch (k)
{
case 0:
case 1:
case 2:
continue;
case 3:
recon = (SInt *) GetImageData (GetVopY (rec_curr));
if (operation == 1) compensated = (SInt *) GetImageData (GetVopY (comp));
BlockRebuild (recon, compensated, operation, max, x_pos, y_pos, width, 16,
iblock[0]);
BlockRebuild (recon, compensated, operation, max, x_pos + 8, y_pos, width,
16, iblock[1]);
BlockRebuild (recon, compensated, operation, max, x_pos, y_pos + 8, width,
16, iblock[2]);
BlockRebuild (recon, compensated, operation, max, x_pos + 8, y_pos + 8,
width, 16, iblock[3]);
continue;
case 4:
recon = (SInt *) GetImageData (GetVopU (rec_curr));
if (operation == 1) compensated = (SInt *) GetImageData (GetVopU (comp));
BlockRebuild (recon, compensated, operation, max,
x_pos/2, y_pos/2, width/2, 8, iblock[4]);
continue;
case 5:
recon = (SInt *) GetImageData (GetVopV (rec_curr));
if (operation
[Bug libfortran/24459] gfortran namelist problem
-- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jvdelisle at gcc dot gnu dot |dot org |org Status|REOPENED|ASSIGNED Last reconfirmed|2005-10-21 22:27:30 |2006-04-22 23:23:31 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24459
[Bug target/27234] no way to stop gcc from mucking with the incoming argument stack
--- Comment #8 from joshudson at gmail dot com 2006-04-22 23:28 --- The code that calls all the "asmlinkage" calls does so through a vector table. Consequently, it does not know how many arguments it calls. However, the arguments live in particular registers when called, so it just pushes all of them (it has to preserve all the registers anyway). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27234
[Bug c/27264] New: gcc 4.0.1 creates unassembleable code for FFTW library
Compiling FFTW 3.1.1 on a new Intel Mac, gcc 4.0.1 generates unassemblable code for several of the main files, e.g. the following, [stp:/Users/stp/Code/MacLibs/fftw-3.1.1/kernel] make trig.lo gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../simd -O3 -fomit-frame-pointer -malign-double -fstrict-aliasing -ffast-math -march=pentiumpro -D_THREAD_SAFE -MT trig.lo -MD -MP -MF .deps/trig.Tpo -c trig.c -o trig.o /var/tmp//ccL7WCuH.s:79:operands given don't match any known 386 instruction /var/tmp//ccL7WCuH.s:83:operands given don't match any known 386 instruction /var/tmp//ccL7WCuH.s:112:operands given don't match any known 386 instruction /var/tmp//ccL7WCuH.s:114:operands given don't match any known 386 instruction /var/tmp//ccL7WCuH.s:138:operands given don't match any known 386 instruction /var/tmp//ccL7WCuH.s:144:operands given don't match any known 386 instruction make: *** [trig.lo] Error 1 I'm attaching the broken assembly file below. If I compile with no flags, it succeeds; as in, [stp:/Users/stp/Code/MacLibs/fftw-3.1.1/kernel] make CFLAGS="-O2" trig.lo gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../simd -O2 -MT trig.lo -MD -MP -MF .deps/trig.Tpo -c trig.c -o trig.o which works fine. Here's the gcc version: Target: i686-apple-darwin8 Configured with: /private/var/tmp/gcc/gcc-5250.obj~12/src/configure --disable-checking -enable-werror --prefix=/usr --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/$/-4.0/ --with-gxx-include-dir=/include/c++/4.0.0 --build=powerpc-apple-darwin8 --with-arch=pentium-m --with-tune=prescott --program-prefix= --host=i686-apple-darwin8 --target=i686-apple-darwin8 Thread model: posix gcc version 4.0.1 (Apple Computer, Inc. build 5250) Here's the broken trig.s file .text _cexpl_sqrtn_table: pushl %edi pushl %esi subl$4, %esp movl16(%esp), %ecx movl20(%esp), %edx movl24(%esp), %edi movl%edx, %eax shrl$31, %eax imull 32(%ecx), %eax addl%eax, %edx movl24(%ecx), %esi movl%edx, %eax andl20(%ecx), %eax sall$4, %eax fldl(%esi,%eax) fldl8(%esi,%eax) movl28(%ecx), %eax movl12(%ecx), %ecx sarl%cl, %edx sall$4, %edx fldl(%eax,%edx) fldl8(%eax,%edx) fld %st(3) fmul%st(2), %st fld %st(3) fmul%st(2), %st fsubrp %st, %st(1) fstpl (%edi) fmulp %st, %st(3) fmulp %st, %st(1) faddp %st, %st(1) fstpl 8(%edi) addl$4, %esp popl%esi popl%edi ret _rotate_sqrtn_table: pushl %edi pushl %esi subl$4, %esp movl16(%esp), %ecx movl20(%esp), %edx movl32(%esp), %edi movl%edx, %eax shrl$31, %eax imull 32(%ecx), %eax addl%eax, %edx movl24(%ecx), %esi movl%edx, %eax andl20(%ecx), %eax sall$4, %eax fldl(%esi,%eax) fldl8(%esi,%eax) movl28(%ecx), %eax movl12(%ecx), %ecx sarl%cl, %edx sall$4, %edx fldl(%eax,%edx) fldl8(%eax,%edx) fld %st(3) fmul%st(2), %st fld %st(3) fmul%st(2), %st fsubrp %st, %st(1) fxch%st(4) fmulp %st, %st(1) fxch%st(2) fmulp %st, %st(1) faddp %st, %st(1) flds24(%esp) flds28(%esp) fld %st(3) fmul%st(2), %st fld %st(3) fmul%st(2), %st faddp %st, %st(1) fstp(%edi) fmulp %st, %st(3) fmulp %st, %st(1) fsubrp %st, %st(1) fstp4(%edi) addl$4, %esp popl%esi popl%edi ret _cexp_zero: movl12(%esp), %edx xorl%eax, %eax movl%eax, (%edx) movl%eax, 4(%edx) ret _cexpl_zero: movl12(%esp), %eax fldz fstl(%eax) fstpl 8(%eax) ret _cexp_generic: pushl %esi subl$40, %esp movl48(%esp), %edx movl56(%esp), %esi leal16(%esp), %eax movl%eax, 8(%esp) movl52(%esp), %eax movl%eax, 4(%esp) movl%edx, (%esp) call*4(%edx) fldl16(%esp) fstp(%esi) fldl24(%esp) fstp4(%esi) addl$40, %esp popl%esi ret _rotate_generic: pushl %esi subl$40, %esp movl48(%esp), %edx movl64(%esp), %esi leal16(%esp), %eax movl%eax, 8(%esp) movl52(%esp), %eax movl%eax, 4(%esp) movl
[Bug libgcj/27265] New: ClassNotFoundException: gnu.java.awt.peer.gtk.GtkToolkit
On x86_64, the following test produces an error:
public class TestAWT {
public static void main (String args[]) {
new java.awt.Frame();
}
}
Exception in thread "main" java.awt.AWTError: Cannot load AWT toolkit:
gnu.java.awt.peer.gtk.GtkToolkit
at java.awt.Toolkit.getDefaultToolkit (libgcj.so.7)
at java.awt.GraphicsEnvironment.getLocalGraphicsEnvironment (libgcj.so.7)
at java.awt.Window. (libgcj.so.7)
at java.awt.Frame. (libgcj.so.7)
at java.awt.Frame. (libgcj.so.7)
at TestAWT.main (TestAWT.java:3)
Caused by: java.lang.ClassNotFoundException: gnu.java.awt.peer.gtk.GtkToolkit
at java.lang.Class.forName (libgcj.so.7)
at java.awt.Toolkit.getDefaultToolkit (libgcj.so.7)
...5 more
strace shows that it is not opening the 64-bit lib. It is opening the 32-bit
lib, however!
$ strace -f -e trace=file gij41 TestAWT 2>&1|grep -i gtk
[pid 20278] open("/lib/lib-gnu-java-awt-peer-gtk-GtkToolkit.la", O_RDONLY) = -1
ENOENT (No such file or directory)
[pid 20278] open("/usr/lib/lib-gnu-java-awt-peer-gtk-GtkToolkit.la", O_RDONLY)
= -1 ENOENT (No such file or directory)
[pid 20278] open("lib-gnu-java-awt-peer-gtk-GtkToolkit.la", O_RDONLY) = -1
ENOENT (No such file or directory)
[pid 20278] access("/lib/lib-gnu-java-awt-peer-gtk-GtkToolkit.so", R_OK) = -1
ENOENT (No such file or directory)
[pid 20278] access("/usr/lib/lib-gnu-java-awt-peer-gtk-GtkToolkit.so", R_OK) =
-1 ENOENT (No such file or directory)
[pid 20278] open("/usr/lib64/../lib64/lib-gnu-java-awt-peer-gtk-GtkToolkit.so",
O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 20278] open("/usr/lib64/../lib64/lib-gnu-java-awt-peer-gtk-GtkToolkit.so",
O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 20278] open("/lib64/tls/lib-gnu-java-awt-peer-gtk-GtkToolkit.so",
O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 20278] open("/lib64/lib-gnu-java-awt-peer-gtk-GtkToolkit.so", O_RDONLY) =
-1 ENOENT (No such file or directory)
[pid 20278] open("/usr/lib64/lib-gnu-java-awt-peer-gtk-GtkToolkit.so",
O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 20278] open("/lib/lib-gnu-java-awt-peer-gtk.la", O_RDONLY) = -1 ENOENT (No
such file or directory)
[pid 20278] open("/usr/lib/lib-gnu-java-awt-peer-gtk.la", O_RDONLY) = -1 ENOENT
(No such file or directory)
[pid 20278] open("lib-gnu-java-awt-peer-gtk.la", O_RDONLY) = -1 ENOENT (No such
file or directory)
[pid 20278] access("/lib/lib-gnu-java-awt-peer-gtk.so", R_OK) = -1 ENOENT (No
such file or directory)
[pid 20278] access("/usr/lib/lib-gnu-java-awt-peer-gtk.so", R_OK) = 0
[pid 20278] open("/usr/lib/lib-gnu-java-awt-peer-gtk.so", O_RDONLY) = 4
java.awt.AWTError: Cannot load AWT toolkit: gnu.java.awt.peer.gtk.GtkToolkit
Caused by: java.lang.ClassNotFoundException: gnu.java.awt.peer.gtk.GtkToolkit
--
Summary: ClassNotFoundException: gnu.java.awt.peer.gtk.GtkToolkit
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: libgcj
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: greenrd at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27265
[Bug c++/8171] Cannot compare pointer to member function of base and derived class
--- Comment #6 from patchapp at dberlin dot org 2006-04-23 01:15 --- Subject: Bug number PR c++/8171 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-04/msg00861.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8171
[Bug target/27264] gcc 4.0.1 creates unassembleable code for FFTW library
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-23 02:01 --- This should be reported to Apple since this is Apple's GCC and not the FSF and x86-darwin is not support for FSF GCC until 4.2.0. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27264
[Bug target/27264] gcc 4.0.1 creates unassembleable code for FFTW library
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-04-23 02:02 --- Second where is the preprocessed source file? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27264
[Bug libfortran/20257] Fortran runtime error: End of record occurs when writing large arrays
--- Comment #10 from jvdelisle at gcc dot gnu dot org 2006-04-23 02:05 --- Subject: Bug 20257 Author: jvdelisle Date: Sun Apr 23 02:04:58 2006 New Revision: 113190 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113190 Log: 2006-04-22 Jerry DeLisle <[EMAIL PROTECTED]> PR libgfortran/20257 * io/io.h: Add prototypes for get_internal_unit and free_internal_unit. * io/unit.c (get_internal_unit): Initialize unit number, not zero. (free_internal_unit): New function to consolidate freeing memory. (get_unit): Initialize internal_unit_desc to NULL when unit is external. * io/unix.c (mem_close): Check for not NULL before freeing memory. * io/transfer.c (read_block): Reset bytes_left and skip error if unit is preconnected and default record length is reached. (read_block_direct): Ditto. (write_block): Ditto. (write_buf): Ditto. (data_transfer_init): Only flush if not internal unit. (finalize_transfer): Ditto and delete code to free memory used by internal units. (st_read_done): Use new function - free_internal_unit. (st_write_done): Use new function - free_internal unit. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/io/io.h trunk/libgfortran/io/transfer.c trunk/libgfortran/io/unit.c trunk/libgfortran/io/unix.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20257
[Bug target/27234] no way to stop gcc from mucking with the incoming argument stack
--- Comment #9 from acahalan at gmail dot com 2006-04-23 02:05 --- Actually, there is no desire to prevent sibling calls. That's a hack. Sibling calls are desirable as long as they don't muck with the incoming argument stack. Using -fno-sibcalling is definitely out of the question. It would affect other functions. Note: the kernel uses -mregparm=3 as the default. Once indexed by Google, a query for "slightly different macro that talks less about tailcalls" ought to find some more discussion of this. Google groups has it already. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27234
[Bug target/27234] no way to stop gcc from mucking with the incoming argument stack
--- Comment #10 from acahalan at gmail dot com 2006-04-23 02:09 --- A couple quotes from Linus on the linux-kernel mailing list, in response to the idea (expressed in comment #3 above) of having the assembly set up the normal stack: -- 1 -- Sure, we could just do a slower system call entry. We always knew that. Suggesting that as the solution is pretty stupid, though. That's _the_ most timing-critical part in the whole kernel on many loads. We've literally spent time trying to remove single cycles there, and it matters. I'd much rather have an officially sanctioned way to do what Linux wants to do, but in the meantime, we can (and are forced to) rely on hacks like "prevent_tail_call()". They are hacks, and we _know_ they are hacks, but as long as gcc maintainers don't want to help us, we don't have much choice (although we could perhaps make the hacks a bit nicer ;). The fact is, the "official ABI" simply isn't appropriate. In fact, we don't use the "official ABI" _anywhere_ in the kernel any more, since we actually end up using other gcc calling conventions (ie regparm=3). Btw, this is not even unusual. A lot of embedded platforms have support for magic exception/interrupt calling conventions. Gcc even supports them: things like "__attribute__((interrupt))". This is also exactly analogous to stdcall/cdecl/regparm/longcall/naked/sp_switch/trap_exit etc attributes. So gcc already has support for the fact that people sometimes need special calling conventions. We've historically worked around it by hand instead, since our calling convention is very _close_ to the standard one In fact, the calling convention we want there is _so_ close to the standard one, that I'm not even convinced the i386 ABI really says that the callee owns the parameter space - it may well be a local gcc decision rather than any "official i386 ABI" issue. -- 2 -- I'd much rather have a real gcc attribute. I don't _like_ having horrible hacks like the above to make gcc do what I want it to do. And I know the gcc developers don't like it either when I force gcc to be my biatch. It would be much better for everybody if gcc helped a bit. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27234
[Bug target/27264] gcc 4.0.1 creates unassembleable code for FFTW library
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-04-23 02:09 --- fstp(%edi) fstp4(%edi) fstp(%esi) fstp4(%esi) Those are the instructions which are failing. So please attach the preprocessed source file. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27264
[Bug target/27234] no way to stop gcc from mucking with the incoming argument stack
--- Comment #11 from pinskia at gcc dot gnu dot org 2006-04-23 02:12 --- A couple of points. One GCC follows the ABI and with changes like regparm it still follows a defined ABI. There are a couple more cases than just sibcalling which will fail even now. Reload (and future RAs) uses where the incomming arguments are to spill for those cases so in reality it is even harder to fix the problem. So setting up the stack is only real thing to do. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27234
[Bug libgcj/27265] ClassNotFoundException: gnu.java.awt.peer.gtk.GtkToolkit
--- Comment #1 from greenrd at gcc dot gnu dot org 2006-04-23 02:14 --- Looks like ltdl's configure script is setting the wrong default search path on x86_64. I found this patch that might help: http://dev.gentoo.org/~halcy0n/patches/patch/10_all_gcc4-libltdl-multilib.patch -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27265
[Bug libgcj/27265] ClassNotFoundException: gnu.java.awt.peer.gtk.GtkToolkit
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-04-23 02:19 --- Fixed in 4.2.0, by an import of the new libltdl from libtool. 2006-03-28 Tom Tromey <[EMAIL PROTECTED]> PR libgcj/26441: * Merged libltdl 1.5.16 from vendor branch. The patch mentioned below is not complete at all. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|major |normal Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27265
[Bug target/26885] [4.1/4.2 regression] -m64 -m32 no longer creates 32-bit object
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-04-23 02:24 --- There is a patch posted: http://gcc.gnu.org/ml/gcc-patches/2006-04/msg00857.html But I feel it is the wrong approach in that the driver now needs to know about the options which is semi wrong. There must be an easier way to fix that what is done. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26885
[Bug c++/26534] [4.1/4.2 Regression] bitfield wrong optimize
--- Comment #6 from mmitchel at gcc dot gnu dot org 2006-04-23 03:16
---
Generating the explicit masking operations in the front end seems to be safe,
but suboptimal. The middle-end will not optimize code like:
struct A {int i : 3; };
struct A a;
int f() { return a.i > 3; } // Always false
unless the type of the expression "a.i" has the correct precision. When
compiled as C code, this function is optimized appropriately, because the C
front-end uses limited-precision types to represent bitfields.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26534
[Bug c++/18803] [3.4 regression] rejects access to operator() in template
--- Comment #14 from pault at gcc dot gnu dot org 2006-04-23 05:33 --- Subject: Bug 18803 Author: pault Date: Sun Apr 23 05:33:16 2006 New Revision: 113191 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113191 Log: 2006-04-23 Paul Thomas <[EMAIL PROTECTED]> PR fortran/27122 * resolve.c (resolve_function): Remove general restriction on auto character length function interfaces. (gfc_resolve_uops): Check restrictions on defined operator procedures. (resolve_types): Call the check for defined operators. PR fortran/27113 * trans-array.c (get_array_ctor_var_strlen): Remove typo in enum. Part of the fix in 4.2, which does not work in 4.1 because the divergence is now too great. PR fortran/26822 * intrinsic.c (add_functions): Mark LOGICAL as elemental. PR fortran/26787 * expr.c (gfc_check_assign): Extend scope of error to include assignments to a procedure in the main program or, from a module or internal procedure that is not that represented by the lhs symbol. Use VARIABLE rather than l-value in message. PR fortran/25597 * trans-decl.c (gfc_trans_deferred_vars): Check if an array result, is also automatic character length. If so, process the character length. Note that this fixes the bug in 4.2 but not here in 4.1 because the trees have diverged too much. Manifestly correct, so applied anyway. PR fortran/18803 PR fortran/25669 PR fortran/26834 * trans_intrinsic.c (gfc_walk_intrinsic_bound): Set data.info.dimen for bound intrinsics. * trans_array.c (gfc_conv_ss_startstride): Pick out LBOUND and UBOUND intrinsics and supply their shape information to the ss and the loop. PR fortran/27124 * trans_expr.c (gfc_trans_function_call): Add a new block, post, in to which all the argument post blocks are put. Add this block to se->pre after a byref call or to se->post, otherwise. 2006-04-23 Paul Thomas <[EMAIL PROTECTED]> PR fortran/27122 * gfortran.dg/defined_operators_1.f90: New test. * gfortran.dg/assumed_charlen_function_1.f90: Add new error and remove old ones associated, incorrectly, with Note 5.46. PR fortran/26787 * gfortran.dg/proc_assign_1.f90: New test. * gfortran.dg/procedure_lvalue.f90: Change message. * gfortran.dg/namelist_4.f90: Add new error. PR fortran/27089 * gfortran.dg/specification_type_resolution_1.f90 PR fortran/18803 PR fortran/25669 PR fortran/26834 * gfortran.dg/bounds_temporaries_1.f90: New test. PR fortran/27124 * gfortran.dg/array_return_value_1.f90: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/array_return_value_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/bounds_temporaries_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/defined_operators_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/proc_assign_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/specification_type_resolution_1.f90 Modified: branches/gcc-4_1-branch/gcc/fortran/ChangeLog branches/gcc-4_1-branch/gcc/fortran/expr.c branches/gcc-4_1-branch/gcc/fortran/intrinsic.c branches/gcc-4_1-branch/gcc/fortran/resolve.c branches/gcc-4_1-branch/gcc/fortran/trans-array.c branches/gcc-4_1-branch/gcc/fortran/trans-decl.c branches/gcc-4_1-branch/gcc/fortran/trans-expr.c branches/gcc-4_1-branch/gcc/fortran/trans-intrinsic.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/assumed_charlen_function_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/namelist_4.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/procedure_lvalue.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18803
[Bug fortran/27113] TODO: Complex array constructors in tonto-2.2
--- Comment #6 from pault at gcc dot gnu dot org 2006-04-23 05:33 --- Subject: Bug 27113 Author: pault Date: Sun Apr 23 05:33:16 2006 New Revision: 113191 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113191 Log: 2006-04-23 Paul Thomas <[EMAIL PROTECTED]> PR fortran/27122 * resolve.c (resolve_function): Remove general restriction on auto character length function interfaces. (gfc_resolve_uops): Check restrictions on defined operator procedures. (resolve_types): Call the check for defined operators. PR fortran/27113 * trans-array.c (get_array_ctor_var_strlen): Remove typo in enum. Part of the fix in 4.2, which does not work in 4.1 because the divergence is now too great. PR fortran/26822 * intrinsic.c (add_functions): Mark LOGICAL as elemental. PR fortran/26787 * expr.c (gfc_check_assign): Extend scope of error to include assignments to a procedure in the main program or, from a module or internal procedure that is not that represented by the lhs symbol. Use VARIABLE rather than l-value in message. PR fortran/25597 * trans-decl.c (gfc_trans_deferred_vars): Check if an array result, is also automatic character length. If so, process the character length. Note that this fixes the bug in 4.2 but not here in 4.1 because the trees have diverged too much. Manifestly correct, so applied anyway. PR fortran/18803 PR fortran/25669 PR fortran/26834 * trans_intrinsic.c (gfc_walk_intrinsic_bound): Set data.info.dimen for bound intrinsics. * trans_array.c (gfc_conv_ss_startstride): Pick out LBOUND and UBOUND intrinsics and supply their shape information to the ss and the loop. PR fortran/27124 * trans_expr.c (gfc_trans_function_call): Add a new block, post, in to which all the argument post blocks are put. Add this block to se->pre after a byref call or to se->post, otherwise. 2006-04-23 Paul Thomas <[EMAIL PROTECTED]> PR fortran/27122 * gfortran.dg/defined_operators_1.f90: New test. * gfortran.dg/assumed_charlen_function_1.f90: Add new error and remove old ones associated, incorrectly, with Note 5.46. PR fortran/26787 * gfortran.dg/proc_assign_1.f90: New test. * gfortran.dg/procedure_lvalue.f90: Change message. * gfortran.dg/namelist_4.f90: Add new error. PR fortran/27089 * gfortran.dg/specification_type_resolution_1.f90 PR fortran/18803 PR fortran/25669 PR fortran/26834 * gfortran.dg/bounds_temporaries_1.f90: New test. PR fortran/27124 * gfortran.dg/array_return_value_1.f90: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/array_return_value_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/bounds_temporaries_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/defined_operators_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/proc_assign_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/specification_type_resolution_1.f90 Modified: branches/gcc-4_1-branch/gcc/fortran/ChangeLog branches/gcc-4_1-branch/gcc/fortran/expr.c branches/gcc-4_1-branch/gcc/fortran/intrinsic.c branches/gcc-4_1-branch/gcc/fortran/resolve.c branches/gcc-4_1-branch/gcc/fortran/trans-array.c branches/gcc-4_1-branch/gcc/fortran/trans-decl.c branches/gcc-4_1-branch/gcc/fortran/trans-expr.c branches/gcc-4_1-branch/gcc/fortran/trans-intrinsic.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/assumed_charlen_function_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/namelist_4.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/procedure_lvalue.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27113
[Bug fortran/27122] binary operator functions should require intent(in)
--- Comment #4 from pault at gcc dot gnu dot org 2006-04-23 05:33 --- Subject: Bug 27122 Author: pault Date: Sun Apr 23 05:33:16 2006 New Revision: 113191 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113191 Log: 2006-04-23 Paul Thomas <[EMAIL PROTECTED]> PR fortran/27122 * resolve.c (resolve_function): Remove general restriction on auto character length function interfaces. (gfc_resolve_uops): Check restrictions on defined operator procedures. (resolve_types): Call the check for defined operators. PR fortran/27113 * trans-array.c (get_array_ctor_var_strlen): Remove typo in enum. Part of the fix in 4.2, which does not work in 4.1 because the divergence is now too great. PR fortran/26822 * intrinsic.c (add_functions): Mark LOGICAL as elemental. PR fortran/26787 * expr.c (gfc_check_assign): Extend scope of error to include assignments to a procedure in the main program or, from a module or internal procedure that is not that represented by the lhs symbol. Use VARIABLE rather than l-value in message. PR fortran/25597 * trans-decl.c (gfc_trans_deferred_vars): Check if an array result, is also automatic character length. If so, process the character length. Note that this fixes the bug in 4.2 but not here in 4.1 because the trees have diverged too much. Manifestly correct, so applied anyway. PR fortran/18803 PR fortran/25669 PR fortran/26834 * trans_intrinsic.c (gfc_walk_intrinsic_bound): Set data.info.dimen for bound intrinsics. * trans_array.c (gfc_conv_ss_startstride): Pick out LBOUND and UBOUND intrinsics and supply their shape information to the ss and the loop. PR fortran/27124 * trans_expr.c (gfc_trans_function_call): Add a new block, post, in to which all the argument post blocks are put. Add this block to se->pre after a byref call or to se->post, otherwise. 2006-04-23 Paul Thomas <[EMAIL PROTECTED]> PR fortran/27122 * gfortran.dg/defined_operators_1.f90: New test. * gfortran.dg/assumed_charlen_function_1.f90: Add new error and remove old ones associated, incorrectly, with Note 5.46. PR fortran/26787 * gfortran.dg/proc_assign_1.f90: New test. * gfortran.dg/procedure_lvalue.f90: Change message. * gfortran.dg/namelist_4.f90: Add new error. PR fortran/27089 * gfortran.dg/specification_type_resolution_1.f90 PR fortran/18803 PR fortran/25669 PR fortran/26834 * gfortran.dg/bounds_temporaries_1.f90: New test. PR fortran/27124 * gfortran.dg/array_return_value_1.f90: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/array_return_value_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/bounds_temporaries_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/defined_operators_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/proc_assign_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/specification_type_resolution_1.f90 Modified: branches/gcc-4_1-branch/gcc/fortran/ChangeLog branches/gcc-4_1-branch/gcc/fortran/expr.c branches/gcc-4_1-branch/gcc/fortran/intrinsic.c branches/gcc-4_1-branch/gcc/fortran/resolve.c branches/gcc-4_1-branch/gcc/fortran/trans-array.c branches/gcc-4_1-branch/gcc/fortran/trans-decl.c branches/gcc-4_1-branch/gcc/fortran/trans-expr.c branches/gcc-4_1-branch/gcc/fortran/trans-intrinsic.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/assumed_charlen_function_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/namelist_4.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/procedure_lvalue.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27122
[Bug fortran/25669] LBOUND (array), as actual arg,causes fatal error.
--- Comment #8 from pault at gcc dot gnu dot org 2006-04-23 05:33 --- Subject: Bug 25669 Author: pault Date: Sun Apr 23 05:33:16 2006 New Revision: 113191 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113191 Log: 2006-04-23 Paul Thomas <[EMAIL PROTECTED]> PR fortran/27122 * resolve.c (resolve_function): Remove general restriction on auto character length function interfaces. (gfc_resolve_uops): Check restrictions on defined operator procedures. (resolve_types): Call the check for defined operators. PR fortran/27113 * trans-array.c (get_array_ctor_var_strlen): Remove typo in enum. Part of the fix in 4.2, which does not work in 4.1 because the divergence is now too great. PR fortran/26822 * intrinsic.c (add_functions): Mark LOGICAL as elemental. PR fortran/26787 * expr.c (gfc_check_assign): Extend scope of error to include assignments to a procedure in the main program or, from a module or internal procedure that is not that represented by the lhs symbol. Use VARIABLE rather than l-value in message. PR fortran/25597 * trans-decl.c (gfc_trans_deferred_vars): Check if an array result, is also automatic character length. If so, process the character length. Note that this fixes the bug in 4.2 but not here in 4.1 because the trees have diverged too much. Manifestly correct, so applied anyway. PR fortran/18803 PR fortran/25669 PR fortran/26834 * trans_intrinsic.c (gfc_walk_intrinsic_bound): Set data.info.dimen for bound intrinsics. * trans_array.c (gfc_conv_ss_startstride): Pick out LBOUND and UBOUND intrinsics and supply their shape information to the ss and the loop. PR fortran/27124 * trans_expr.c (gfc_trans_function_call): Add a new block, post, in to which all the argument post blocks are put. Add this block to se->pre after a byref call or to se->post, otherwise. 2006-04-23 Paul Thomas <[EMAIL PROTECTED]> PR fortran/27122 * gfortran.dg/defined_operators_1.f90: New test. * gfortran.dg/assumed_charlen_function_1.f90: Add new error and remove old ones associated, incorrectly, with Note 5.46. PR fortran/26787 * gfortran.dg/proc_assign_1.f90: New test. * gfortran.dg/procedure_lvalue.f90: Change message. * gfortran.dg/namelist_4.f90: Add new error. PR fortran/27089 * gfortran.dg/specification_type_resolution_1.f90 PR fortran/18803 PR fortran/25669 PR fortran/26834 * gfortran.dg/bounds_temporaries_1.f90: New test. PR fortran/27124 * gfortran.dg/array_return_value_1.f90: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/array_return_value_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/bounds_temporaries_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/defined_operators_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/proc_assign_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/specification_type_resolution_1.f90 Modified: branches/gcc-4_1-branch/gcc/fortran/ChangeLog branches/gcc-4_1-branch/gcc/fortran/expr.c branches/gcc-4_1-branch/gcc/fortran/intrinsic.c branches/gcc-4_1-branch/gcc/fortran/resolve.c branches/gcc-4_1-branch/gcc/fortran/trans-array.c branches/gcc-4_1-branch/gcc/fortran/trans-decl.c branches/gcc-4_1-branch/gcc/fortran/trans-expr.c branches/gcc-4_1-branch/gcc/fortran/trans-intrinsic.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/assumed_charlen_function_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/namelist_4.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/procedure_lvalue.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25669
[Bug fortran/26822] Scalarization of non-elemental intrinsic: __logical_4_l4
--- Comment #9 from pault at gcc dot gnu dot org 2006-04-23 05:33 --- Subject: Bug 26822 Author: pault Date: Sun Apr 23 05:33:16 2006 New Revision: 113191 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113191 Log: 2006-04-23 Paul Thomas <[EMAIL PROTECTED]> PR fortran/27122 * resolve.c (resolve_function): Remove general restriction on auto character length function interfaces. (gfc_resolve_uops): Check restrictions on defined operator procedures. (resolve_types): Call the check for defined operators. PR fortran/27113 * trans-array.c (get_array_ctor_var_strlen): Remove typo in enum. Part of the fix in 4.2, which does not work in 4.1 because the divergence is now too great. PR fortran/26822 * intrinsic.c (add_functions): Mark LOGICAL as elemental. PR fortran/26787 * expr.c (gfc_check_assign): Extend scope of error to include assignments to a procedure in the main program or, from a module or internal procedure that is not that represented by the lhs symbol. Use VARIABLE rather than l-value in message. PR fortran/25597 * trans-decl.c (gfc_trans_deferred_vars): Check if an array result, is also automatic character length. If so, process the character length. Note that this fixes the bug in 4.2 but not here in 4.1 because the trees have diverged too much. Manifestly correct, so applied anyway. PR fortran/18803 PR fortran/25669 PR fortran/26834 * trans_intrinsic.c (gfc_walk_intrinsic_bound): Set data.info.dimen for bound intrinsics. * trans_array.c (gfc_conv_ss_startstride): Pick out LBOUND and UBOUND intrinsics and supply their shape information to the ss and the loop. PR fortran/27124 * trans_expr.c (gfc_trans_function_call): Add a new block, post, in to which all the argument post blocks are put. Add this block to se->pre after a byref call or to se->post, otherwise. 2006-04-23 Paul Thomas <[EMAIL PROTECTED]> PR fortran/27122 * gfortran.dg/defined_operators_1.f90: New test. * gfortran.dg/assumed_charlen_function_1.f90: Add new error and remove old ones associated, incorrectly, with Note 5.46. PR fortran/26787 * gfortran.dg/proc_assign_1.f90: New test. * gfortran.dg/procedure_lvalue.f90: Change message. * gfortran.dg/namelist_4.f90: Add new error. PR fortran/27089 * gfortran.dg/specification_type_resolution_1.f90 PR fortran/18803 PR fortran/25669 PR fortran/26834 * gfortran.dg/bounds_temporaries_1.f90: New test. PR fortran/27124 * gfortran.dg/array_return_value_1.f90: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/array_return_value_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/bounds_temporaries_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/defined_operators_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/proc_assign_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/specification_type_resolution_1.f90 Modified: branches/gcc-4_1-branch/gcc/fortran/ChangeLog branches/gcc-4_1-branch/gcc/fortran/expr.c branches/gcc-4_1-branch/gcc/fortran/intrinsic.c branches/gcc-4_1-branch/gcc/fortran/resolve.c branches/gcc-4_1-branch/gcc/fortran/trans-array.c branches/gcc-4_1-branch/gcc/fortran/trans-decl.c branches/gcc-4_1-branch/gcc/fortran/trans-expr.c branches/gcc-4_1-branch/gcc/fortran/trans-intrinsic.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/assumed_charlen_function_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/namelist_4.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/procedure_lvalue.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26822
[Bug fortran/26787] Assigning to function causes ice in gfortran
--- Comment #7 from pault at gcc dot gnu dot org 2006-04-23 05:33 --- Subject: Bug 26787 Author: pault Date: Sun Apr 23 05:33:16 2006 New Revision: 113191 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113191 Log: 2006-04-23 Paul Thomas <[EMAIL PROTECTED]> PR fortran/27122 * resolve.c (resolve_function): Remove general restriction on auto character length function interfaces. (gfc_resolve_uops): Check restrictions on defined operator procedures. (resolve_types): Call the check for defined operators. PR fortran/27113 * trans-array.c (get_array_ctor_var_strlen): Remove typo in enum. Part of the fix in 4.2, which does not work in 4.1 because the divergence is now too great. PR fortran/26822 * intrinsic.c (add_functions): Mark LOGICAL as elemental. PR fortran/26787 * expr.c (gfc_check_assign): Extend scope of error to include assignments to a procedure in the main program or, from a module or internal procedure that is not that represented by the lhs symbol. Use VARIABLE rather than l-value in message. PR fortran/25597 * trans-decl.c (gfc_trans_deferred_vars): Check if an array result, is also automatic character length. If so, process the character length. Note that this fixes the bug in 4.2 but not here in 4.1 because the trees have diverged too much. Manifestly correct, so applied anyway. PR fortran/18803 PR fortran/25669 PR fortran/26834 * trans_intrinsic.c (gfc_walk_intrinsic_bound): Set data.info.dimen for bound intrinsics. * trans_array.c (gfc_conv_ss_startstride): Pick out LBOUND and UBOUND intrinsics and supply their shape information to the ss and the loop. PR fortran/27124 * trans_expr.c (gfc_trans_function_call): Add a new block, post, in to which all the argument post blocks are put. Add this block to se->pre after a byref call or to se->post, otherwise. 2006-04-23 Paul Thomas <[EMAIL PROTECTED]> PR fortran/27122 * gfortran.dg/defined_operators_1.f90: New test. * gfortran.dg/assumed_charlen_function_1.f90: Add new error and remove old ones associated, incorrectly, with Note 5.46. PR fortran/26787 * gfortran.dg/proc_assign_1.f90: New test. * gfortran.dg/procedure_lvalue.f90: Change message. * gfortran.dg/namelist_4.f90: Add new error. PR fortran/27089 * gfortran.dg/specification_type_resolution_1.f90 PR fortran/18803 PR fortran/25669 PR fortran/26834 * gfortran.dg/bounds_temporaries_1.f90: New test. PR fortran/27124 * gfortran.dg/array_return_value_1.f90: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/array_return_value_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/bounds_temporaries_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/defined_operators_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/proc_assign_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/specification_type_resolution_1.f90 Modified: branches/gcc-4_1-branch/gcc/fortran/ChangeLog branches/gcc-4_1-branch/gcc/fortran/expr.c branches/gcc-4_1-branch/gcc/fortran/intrinsic.c branches/gcc-4_1-branch/gcc/fortran/resolve.c branches/gcc-4_1-branch/gcc/fortran/trans-array.c branches/gcc-4_1-branch/gcc/fortran/trans-decl.c branches/gcc-4_1-branch/gcc/fortran/trans-expr.c branches/gcc-4_1-branch/gcc/fortran/trans-intrinsic.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/assumed_charlen_function_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/namelist_4.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/procedure_lvalue.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26787
[Bug fortran/27089] Module procedure with explicit result does not pass type to specification expression.
--- Comment #4 from pault at gcc dot gnu dot org 2006-04-23 05:33 --- Subject: Bug 27089 Author: pault Date: Sun Apr 23 05:33:16 2006 New Revision: 113191 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113191 Log: 2006-04-23 Paul Thomas <[EMAIL PROTECTED]> PR fortran/27122 * resolve.c (resolve_function): Remove general restriction on auto character length function interfaces. (gfc_resolve_uops): Check restrictions on defined operator procedures. (resolve_types): Call the check for defined operators. PR fortran/27113 * trans-array.c (get_array_ctor_var_strlen): Remove typo in enum. Part of the fix in 4.2, which does not work in 4.1 because the divergence is now too great. PR fortran/26822 * intrinsic.c (add_functions): Mark LOGICAL as elemental. PR fortran/26787 * expr.c (gfc_check_assign): Extend scope of error to include assignments to a procedure in the main program or, from a module or internal procedure that is not that represented by the lhs symbol. Use VARIABLE rather than l-value in message. PR fortran/25597 * trans-decl.c (gfc_trans_deferred_vars): Check if an array result, is also automatic character length. If so, process the character length. Note that this fixes the bug in 4.2 but not here in 4.1 because the trees have diverged too much. Manifestly correct, so applied anyway. PR fortran/18803 PR fortran/25669 PR fortran/26834 * trans_intrinsic.c (gfc_walk_intrinsic_bound): Set data.info.dimen for bound intrinsics. * trans_array.c (gfc_conv_ss_startstride): Pick out LBOUND and UBOUND intrinsics and supply their shape information to the ss and the loop. PR fortran/27124 * trans_expr.c (gfc_trans_function_call): Add a new block, post, in to which all the argument post blocks are put. Add this block to se->pre after a byref call or to se->post, otherwise. 2006-04-23 Paul Thomas <[EMAIL PROTECTED]> PR fortran/27122 * gfortran.dg/defined_operators_1.f90: New test. * gfortran.dg/assumed_charlen_function_1.f90: Add new error and remove old ones associated, incorrectly, with Note 5.46. PR fortran/26787 * gfortran.dg/proc_assign_1.f90: New test. * gfortran.dg/procedure_lvalue.f90: Change message. * gfortran.dg/namelist_4.f90: Add new error. PR fortran/27089 * gfortran.dg/specification_type_resolution_1.f90 PR fortran/18803 PR fortran/25669 PR fortran/26834 * gfortran.dg/bounds_temporaries_1.f90: New test. PR fortran/27124 * gfortran.dg/array_return_value_1.f90: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/array_return_value_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/bounds_temporaries_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/defined_operators_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/proc_assign_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/specification_type_resolution_1.f90 Modified: branches/gcc-4_1-branch/gcc/fortran/ChangeLog branches/gcc-4_1-branch/gcc/fortran/expr.c branches/gcc-4_1-branch/gcc/fortran/intrinsic.c branches/gcc-4_1-branch/gcc/fortran/resolve.c branches/gcc-4_1-branch/gcc/fortran/trans-array.c branches/gcc-4_1-branch/gcc/fortran/trans-decl.c branches/gcc-4_1-branch/gcc/fortran/trans-expr.c branches/gcc-4_1-branch/gcc/fortran/trans-intrinsic.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/assumed_charlen_function_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/namelist_4.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/procedure_lvalue.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27089
[Bug fortran/26834] gfc_todo: Not Implemented: Unable to determine rank of expression
--- Comment #5 from pault at gcc dot gnu dot org 2006-04-23 05:33 --- Subject: Bug 26834 Author: pault Date: Sun Apr 23 05:33:16 2006 New Revision: 113191 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113191 Log: 2006-04-23 Paul Thomas <[EMAIL PROTECTED]> PR fortran/27122 * resolve.c (resolve_function): Remove general restriction on auto character length function interfaces. (gfc_resolve_uops): Check restrictions on defined operator procedures. (resolve_types): Call the check for defined operators. PR fortran/27113 * trans-array.c (get_array_ctor_var_strlen): Remove typo in enum. Part of the fix in 4.2, which does not work in 4.1 because the divergence is now too great. PR fortran/26822 * intrinsic.c (add_functions): Mark LOGICAL as elemental. PR fortran/26787 * expr.c (gfc_check_assign): Extend scope of error to include assignments to a procedure in the main program or, from a module or internal procedure that is not that represented by the lhs symbol. Use VARIABLE rather than l-value in message. PR fortran/25597 * trans-decl.c (gfc_trans_deferred_vars): Check if an array result, is also automatic character length. If so, process the character length. Note that this fixes the bug in 4.2 but not here in 4.1 because the trees have diverged too much. Manifestly correct, so applied anyway. PR fortran/18803 PR fortran/25669 PR fortran/26834 * trans_intrinsic.c (gfc_walk_intrinsic_bound): Set data.info.dimen for bound intrinsics. * trans_array.c (gfc_conv_ss_startstride): Pick out LBOUND and UBOUND intrinsics and supply their shape information to the ss and the loop. PR fortran/27124 * trans_expr.c (gfc_trans_function_call): Add a new block, post, in to which all the argument post blocks are put. Add this block to se->pre after a byref call or to se->post, otherwise. 2006-04-23 Paul Thomas <[EMAIL PROTECTED]> PR fortran/27122 * gfortran.dg/defined_operators_1.f90: New test. * gfortran.dg/assumed_charlen_function_1.f90: Add new error and remove old ones associated, incorrectly, with Note 5.46. PR fortran/26787 * gfortran.dg/proc_assign_1.f90: New test. * gfortran.dg/procedure_lvalue.f90: Change message. * gfortran.dg/namelist_4.f90: Add new error. PR fortran/27089 * gfortran.dg/specification_type_resolution_1.f90 PR fortran/18803 PR fortran/25669 PR fortran/26834 * gfortran.dg/bounds_temporaries_1.f90: New test. PR fortran/27124 * gfortran.dg/array_return_value_1.f90: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/array_return_value_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/bounds_temporaries_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/defined_operators_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/proc_assign_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/specification_type_resolution_1.f90 Modified: branches/gcc-4_1-branch/gcc/fortran/ChangeLog branches/gcc-4_1-branch/gcc/fortran/expr.c branches/gcc-4_1-branch/gcc/fortran/intrinsic.c branches/gcc-4_1-branch/gcc/fortran/resolve.c branches/gcc-4_1-branch/gcc/fortran/trans-array.c branches/gcc-4_1-branch/gcc/fortran/trans-decl.c branches/gcc-4_1-branch/gcc/fortran/trans-expr.c branches/gcc-4_1-branch/gcc/fortran/trans-intrinsic.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/assumed_charlen_function_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/namelist_4.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/procedure_lvalue.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26834
[Bug fortran/27124] Incorrect dependency for assignment from function with array section actual arg.
--- Comment #6 from pault at gcc dot gnu dot org 2006-04-23 05:33 --- Subject: Bug 27124 Author: pault Date: Sun Apr 23 05:33:16 2006 New Revision: 113191 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113191 Log: 2006-04-23 Paul Thomas <[EMAIL PROTECTED]> PR fortran/27122 * resolve.c (resolve_function): Remove general restriction on auto character length function interfaces. (gfc_resolve_uops): Check restrictions on defined operator procedures. (resolve_types): Call the check for defined operators. PR fortran/27113 * trans-array.c (get_array_ctor_var_strlen): Remove typo in enum. Part of the fix in 4.2, which does not work in 4.1 because the divergence is now too great. PR fortran/26822 * intrinsic.c (add_functions): Mark LOGICAL as elemental. PR fortran/26787 * expr.c (gfc_check_assign): Extend scope of error to include assignments to a procedure in the main program or, from a module or internal procedure that is not that represented by the lhs symbol. Use VARIABLE rather than l-value in message. PR fortran/25597 * trans-decl.c (gfc_trans_deferred_vars): Check if an array result, is also automatic character length. If so, process the character length. Note that this fixes the bug in 4.2 but not here in 4.1 because the trees have diverged too much. Manifestly correct, so applied anyway. PR fortran/18803 PR fortran/25669 PR fortran/26834 * trans_intrinsic.c (gfc_walk_intrinsic_bound): Set data.info.dimen for bound intrinsics. * trans_array.c (gfc_conv_ss_startstride): Pick out LBOUND and UBOUND intrinsics and supply their shape information to the ss and the loop. PR fortran/27124 * trans_expr.c (gfc_trans_function_call): Add a new block, post, in to which all the argument post blocks are put. Add this block to se->pre after a byref call or to se->post, otherwise. 2006-04-23 Paul Thomas <[EMAIL PROTECTED]> PR fortran/27122 * gfortran.dg/defined_operators_1.f90: New test. * gfortran.dg/assumed_charlen_function_1.f90: Add new error and remove old ones associated, incorrectly, with Note 5.46. PR fortran/26787 * gfortran.dg/proc_assign_1.f90: New test. * gfortran.dg/procedure_lvalue.f90: Change message. * gfortran.dg/namelist_4.f90: Add new error. PR fortran/27089 * gfortran.dg/specification_type_resolution_1.f90 PR fortran/18803 PR fortran/25669 PR fortran/26834 * gfortran.dg/bounds_temporaries_1.f90: New test. PR fortran/27124 * gfortran.dg/array_return_value_1.f90: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/array_return_value_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/bounds_temporaries_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/defined_operators_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/proc_assign_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/specification_type_resolution_1.f90 Modified: branches/gcc-4_1-branch/gcc/fortran/ChangeLog branches/gcc-4_1-branch/gcc/fortran/expr.c branches/gcc-4_1-branch/gcc/fortran/intrinsic.c branches/gcc-4_1-branch/gcc/fortran/resolve.c branches/gcc-4_1-branch/gcc/fortran/trans-array.c branches/gcc-4_1-branch/gcc/fortran/trans-decl.c branches/gcc-4_1-branch/gcc/fortran/trans-expr.c branches/gcc-4_1-branch/gcc/fortran/trans-intrinsic.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/assumed_charlen_function_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/namelist_4.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/procedure_lvalue.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27124
[Bug fortran/25597] ICE with allocate on the return value of a function, character array with a len of an argument
--- Comment #9 from pault at gcc dot gnu dot org 2006-04-23 05:33 --- Subject: Bug 25597 Author: pault Date: Sun Apr 23 05:33:16 2006 New Revision: 113191 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113191 Log: 2006-04-23 Paul Thomas <[EMAIL PROTECTED]> PR fortran/27122 * resolve.c (resolve_function): Remove general restriction on auto character length function interfaces. (gfc_resolve_uops): Check restrictions on defined operator procedures. (resolve_types): Call the check for defined operators. PR fortran/27113 * trans-array.c (get_array_ctor_var_strlen): Remove typo in enum. Part of the fix in 4.2, which does not work in 4.1 because the divergence is now too great. PR fortran/26822 * intrinsic.c (add_functions): Mark LOGICAL as elemental. PR fortran/26787 * expr.c (gfc_check_assign): Extend scope of error to include assignments to a procedure in the main program or, from a module or internal procedure that is not that represented by the lhs symbol. Use VARIABLE rather than l-value in message. PR fortran/25597 * trans-decl.c (gfc_trans_deferred_vars): Check if an array result, is also automatic character length. If so, process the character length. Note that this fixes the bug in 4.2 but not here in 4.1 because the trees have diverged too much. Manifestly correct, so applied anyway. PR fortran/18803 PR fortran/25669 PR fortran/26834 * trans_intrinsic.c (gfc_walk_intrinsic_bound): Set data.info.dimen for bound intrinsics. * trans_array.c (gfc_conv_ss_startstride): Pick out LBOUND and UBOUND intrinsics and supply their shape information to the ss and the loop. PR fortran/27124 * trans_expr.c (gfc_trans_function_call): Add a new block, post, in to which all the argument post blocks are put. Add this block to se->pre after a byref call or to se->post, otherwise. 2006-04-23 Paul Thomas <[EMAIL PROTECTED]> PR fortran/27122 * gfortran.dg/defined_operators_1.f90: New test. * gfortran.dg/assumed_charlen_function_1.f90: Add new error and remove old ones associated, incorrectly, with Note 5.46. PR fortran/26787 * gfortran.dg/proc_assign_1.f90: New test. * gfortran.dg/procedure_lvalue.f90: Change message. * gfortran.dg/namelist_4.f90: Add new error. PR fortran/27089 * gfortran.dg/specification_type_resolution_1.f90 PR fortran/18803 PR fortran/25669 PR fortran/26834 * gfortran.dg/bounds_temporaries_1.f90: New test. PR fortran/27124 * gfortran.dg/array_return_value_1.f90: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/array_return_value_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/bounds_temporaries_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/defined_operators_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/proc_assign_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/specification_type_resolution_1.f90 Modified: branches/gcc-4_1-branch/gcc/fortran/ChangeLog branches/gcc-4_1-branch/gcc/fortran/expr.c branches/gcc-4_1-branch/gcc/fortran/intrinsic.c branches/gcc-4_1-branch/gcc/fortran/resolve.c branches/gcc-4_1-branch/gcc/fortran/trans-array.c branches/gcc-4_1-branch/gcc/fortran/trans-decl.c branches/gcc-4_1-branch/gcc/fortran/trans-expr.c branches/gcc-4_1-branch/gcc/fortran/trans-intrinsic.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/assumed_charlen_function_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/namelist_4.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/procedure_lvalue.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25597
[Bug fortran/26822] Scalarization of non-elemental intrinsic: __logical_4_l4
--- Comment #10 from pault at gcc dot gnu dot org 2006-04-23 05:37 --- Fixed on trunk and 4.1 Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26822
[Bug fortran/26787] Assigning to function causes ice in gfortran
--- Comment #8 from pault at gcc dot gnu dot org 2006-04-23 05:38 --- Fixed on trunk and 4.1 Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26787
[Bug fortran/25597] ICE with allocate on the return value of a function, character array with a len of an argument
--- Comment #10 from pault at gcc dot gnu dot org 2006-04-23 05:39 --- Fixed on trunk but,sadly, not on 4.1 because divergences have become too great. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25597
