[Bug fortran/31608] wrong types in array transfer
--- Comment #7 from Tobias dot Schlueter at physik dot uni-muenchen dot de 2007-04-19 09:08 --- Subject: Re: wrong types in array transfer burnus at gcc dot gnu dot org wrote: > --- Comment #6 from burnus at gcc dot gnu dot org 2007-04-19 07:44 > --- >> Nevertheless, the accepts-invalid is also an embarassing problem (unless we >> collectively misunderstand Fortran rules :) > > Well, we do. That doesn't make it any less embarassing :) But indeed this is the same as "1 .eq. (/1,2/)" which evaluates to (/.true.,.false./), should have thought of this earlier. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31608
[Bug fortran/31608] wrong types in array transfer
--- Comment #8 from pault at gcc dot gnu dot org 2007-04-19 10:37 --- (In reply to comment #7) I am completely trapped by the workshop that I am running and have not even managed to do what I promised last night. Realistically, it might have to wait until the weekend. If you can develop a description of what the real PR should be, I would be grateful. BTW - thanks to Richard for noticing it.. might I ask how you came across it? Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31608
[Bug middle-end/31631] New: Folding of A & (1 << B) pessimizes FRE
void
foo (int control2, unsigned long *state, int size)
{
int i;
for(i=0; i:;
D.1989_4 = (long unsigned int) i_1;
D.1990_5 = D.1989_4 * 8;
D.1991_6 = (long unsigned int *) D.1990_5;
D.1992_8 = D.1991_6 + state_7(D);
# VUSE
D.1993_9 = *D.1992_8;
D.1994_11 = D.1993_9 >> control2_10(D);
D.1995_12 = (int) D.1994_11;
D.1996_13 = D.1995_12 & 1;
if (D.1996_13 != 0) goto ; else goto ;
:;
D.1989_19 = D.1989_4;
D.1990_20 = D.1990_5;
D.1991_21 = D.1991_6;
D.1992_22 = D.1992_8;
D.1993_23 = D.1993_9;
D.1998_24 = 1 << control2_10(D);
D.1999_25 = D.1993_23 ^ D.1998_24;
# SMT.4_30 = VDEF
*D.1992_22 = D.1999_25;
This is related to PR29789 where this transformation causes other
pessimization.
--
Summary: Folding of A & (1 << B) pessimizes FRE
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31631
[Bug fortran/31608] wrong types in array transfer
--- Comment #9 from rguenth at gcc dot gnu dot org 2007-04-19 12:08 --- The patch in http://gcc.gnu.org/ml/gcc-patches/2007-04/msg01075.html makes the testcase ICE because of the type mismatch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31608
[Bug rtl-optimization/29841] [4.2/4.3 regression] ICE with scheduling and __builtin_trap
--- Comment #18 from ebotcazou at gcc dot gnu dot org 2007-04-19 12:19 --- Subject: Bug 29841 Author: ebotcazou Date: Thu Apr 19 12:19:16 2007 New Revision: 123970 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123970 Log: PR rtl-optimization/29841 * cfgbuild.c (control_flow_insn_p): Return TRUE for unconditional trap instructions. * sched-deps.c (sched_analyze_insn): Prevent all non-jump instructions that may cause control flow transfer from being moved. Added: trunk/gcc/testsuite/gcc.dg/invalid-call-1.c Modified: trunk/gcc/ChangeLog trunk/gcc/cfgbuild.c trunk/gcc/sched-deps.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29841
[Bug rtl-optimization/29841] [4.2/4.3 regression] ICE with scheduling and __builtin_trap
--- Comment #19 from ebotcazou at gcc dot gnu dot org 2007-04-19 12:19 --- Subject: Bug 29841 Author: ebotcazou Date: Thu Apr 19 12:19:39 2007 New Revision: 123971 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123971 Log: PR rtl-optimization/29841 * cfgbuild.c (control_flow_insn_p): Return TRUE for unconditional trap instructions. * sched-deps.c (sched_analyze_insn): Prevent all non-jump instructions that may cause control flow transfer from being moved. Added: branches/gcc-4_2-branch/gcc/testsuite/gcc.dg/invalid-call-1.c Modified: branches/gcc-4_2-branch/gcc/ChangeLog branches/gcc-4_2-branch/gcc/cfgbuild.c branches/gcc-4_2-branch/gcc/sched-deps.c branches/gcc-4_2-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29841
[Bug rtl-optimization/29841] [4.2/4.3 regression] ICE with scheduling and __builtin_trap
--- Comment #20 from ebotcazou at gcc dot gnu dot org 2007-04-19 12:21 --- Should work now. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org URL||http://gcc.gnu.org/ml/gcc- ||patches/2007- ||04/msg01114.html Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29841
[Bug tree-optimization/31632] New: [4.1 regression]
-- Summary: [4.1 regression] Product: gcc Version: 4.1.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jakub at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31632
[Bug tree-optimization/31632] [4.1 regression] ICE in compare_values
--- Comment #1 from jakub at gcc dot gnu dot org 2007-04-19 12:40 ---
struct S
{
long int l;
void *m;
};
int
foo (struct S *x)
{
unsigned long a;
a = x->l;
if (a <= ((void *) 0))
x->m = 0;
return 0;
}
ICEs at -O2 on both x86_64-linux and ppc-linux.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||ice-on-valid-code
Known to fail||4.1.3
Known to work||3.4.6 4.2.0 4.3.0
Summary|[4.1 regression]|[4.1 regression] ICE in
||compare_values
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31632
[Bug tree-optimization/31632] [4.1 regression] ICE in compare_values
--- Comment #2 from jakub at gcc dot gnu dot org 2007-04-19 12:56 --- I'd say this is a frontend bug (in all of 4.1/4.2/4.3 at least), it shouldn't have created unit size align 8 symtab 0 alias set -1 precision 1 min max > arg 0 unit size align 64 symtab 0 alias set -1 precision 64 min max > var def_stmt version 3> arg 1 constant invariant 0> A.c:12> i.e. a comparison with integral type on one size and pointer on another one. In 4.2+ forwprop1 fixes this up to comparison against 0L, but in 4.1 it makes it through that up to vrp which asserts this is not the case. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31632
[Bug fortran/31561] FAIL: gfortran.dg/vect/vect-4.f90
--- Comment #8 from tprince at computer dot org 2007-04-19 14:35 --- 4.2 branch appears to have the identical problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31561
[Bug tree-optimization/31632] [4.1 regression] ICE in compare_values
--- Comment #3 from jakub at gcc dot gnu dot org 2007-04-19 14:58 --- Actually a bug in fold-const. -- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-04-19 14:58:05 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31632
[Bug fortran/31608] wrong types in array transfer
--- Comment #10 from pault at gcc dot gnu dot org 2007-04-19 15:20 --- (In reply to comment #5) > For the record, the problem Richard is pointing out is in the body of the > function Up, namely in the expression for MERGE, probably caused by TRANSFER. Duuh! You are right about where the problem is. Look, I am not in a position to usefully contribute right now. Please take such action as you see fit; eg. withdraw the testcase and restore the PR, so that Richard can get going. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31608
[Bug fortran/31608] wrong types in array transfer
--- Comment #11 from rguenth at gcc dot gnu dot org 2007-04-19 15:55 --- It's not blocking me atm as a different patch got accepted which doesn't expose this problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31608
[Bug fortran/25071] dummy argument larger than actual argument
--- Comment #2 from burnus at gcc dot gnu dot org 2007-04-19 16:16 --- Analogously for character lengths: program test character(len=10) :: x call foo(x) write(*,*) 'X=',x contains subroutine foo(y) character(len=20) :: y y = 'hello world' end subroutine end Taken from: http://ftp.aset.psu.edu/pub/ger/fortran/test/ test17.f90 (slightly modified). g95: Actual character argument at (1) is shorter in length than the formal argument NAG f95: Character length too short for arg Y (no. 1) of FOO ifort: Character length argument mismatch. [X] -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25071
[Bug c/31633] New: Calling an uninitialized function pointer does not trigger a warning
See:
% cat gcc-bug.c
int foo(void) {
int (*bar)(int);
return bar(33);
}
% gcc -c -Wall gcc-bug.c
^ NO WARNING
% gcc -v
Using built-in specs.
Target: x86_64-pc-linux-gnu
Configured with:
/var/tmp/portage/sys-devel/gcc-4.1.1-r3/work/gcc-4.1.1/configure --prefix=/usr
--b
indir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.1.1
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/in
clude --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.1.1
--mandir=/usr/share/gcc-data/x86_64-p
c-linux-gnu/4.1.1/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.1.1/info --with-gxx-inclu
de-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/include/g++-v4
--host=x86_64-pc-linux-gnu --build=x86
_64-pc-linux-gnu --disable-altivec --enable-nls --without-included-gettext
--with-system-zlib --dis
able-checking --disable-werror --enable-secureplt
--disable-libunwind-exceptions --enable-multilib
--disable-libmudflap --disable-libssp --disable-libgcj --enable-languages=c,c++
--enable-shared --e
nable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu
Thread model: posix
gcc version 4.1.1 (Gentoo 4.1.1-r3)
--
Summary: Calling an uninitialized function pointer does not
trigger a warning
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: carottegcc at therodox dot com
GCC target triplet: x86_64-pc-linux-gnu, arm-lpc-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31633
[Bug c/31633] Calling an uninitialized function pointer does not trigger a warning
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-04-19 17:24 --- Use -O1 if you want to find unitialized variables (including function pointers): [pinskia-laptop:gcc/objdir-noboot/gcc] pinskia% ./cc1 -quiet -W -Wall t5.c -O1 t5.c: In function 'foo': t5.c:4: warning: 'bar' is used uninitialized in this function This is documented as a limitation also. -- 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=31633
[Bug target/26290] [4.1 Regression]: code pessimization wrt. GCC 4.0 probably due to TARGET_MEM_REF
--- Comment #17 from opruz at centrum dot cz 2007-04-19 17:29 --- 4.1.2 -m32 -O2 .L6: movl8(%ebp), %ebx movl4(%edx), %ecx movl-4(%ebx,%eax,4), %ebx movl%ecx, -20(%ebp) cmpl%ecx, %ebx movl%ebx, -16(%ebp) jle .L7 movl8(%ebp), %ebx movl%ecx, -4(%ebx,%eax,4) movl-16(%ebp), %ecx movl%ecx, 4(%edx) .L7: incl-24(%ebp) addl$4, %edx cmpl-24(%ebp), %esi jle .L12 jmp .L6 4.1.2 -m32 -O2 .L6: movl-4(%rdx), %r10d movl(%rcx), %r8d cmpl%r8d, %r10d jle .L7 movl%r8d, -4(%rdx) movl%r10d, (%rcx) .L7: incl%edi addq$4, %rcx cmpl%edi, %esi jle .L4 jmp .L6 Looks like noone gives a shit though... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26290
[Bug java/31622] Segment violation in the “toString” method on a mathematical expression
--- Comment #3 from eduardo dot iniesta at aquiline dot es 2007-04-19 17:39 --- (In reply to comment #1) Thanks... The exact version is: $ gcj --version gcj (GCC) 4.3.0 20061212 (experimental) ... > Are you sure you are using gcj 4.3? > > I see a SEGV with 4.1 and 4.2. But with 4.3 I see an error: > > opsy. gcj -C Fail.java > Fail.java:5: error: Cannot invoke toString() on the primitive type long > r=(a-b).toString(); > > 1 problem (1 error) > > (Note that, in all likelihood, we won't fix front end bugs of this nature > in 4.1 or 4.2.) > (In reply to comment #1) > Are you sure you are using gcj 4.3? > > I see a SEGV with 4.1 and 4.2. But with 4.3 I see an error: > > opsy. gcj -C Fail.java > Fail.java:5: error: Cannot invoke toString() on the primitive type long > r=(a-b).toString(); > > 1 problem (1 error) > > (Note that, in all likelihood, we won't fix front end bugs of this nature > in 4.1 or 4.2.) > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31622
[Bug target/31429] [4.3 Regression] __builtin_setjmp/__builtin_longjmp is broken on ppc-darwin
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-04-19 17:39 --- Fixed by: Author: echristo Date: Wed Apr 18 23:27:51 2007 New Revision: 123960 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123960 Log: 2007-04-18 Eric Christopher <[EMAIL PROTECTED]> * config/rs6000/darwin.md (load_macho_picbase): Use link register only. Update operands. * config/rs6000/rs6000.c (rs6000_emit_prologue): Update caller. * config/rs6000/rs6000.md (builtin_setjmp_receiver): Ditto. Move from link register to pic register. Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/darwin.md trunk/gcc/config/rs6000/rs6000.c trunk/gcc/config/rs6000/rs6000.md -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31429
[Bug target/28623] [4.1/4.2/4.3 regression] ICE in extract_insn, at recog.c:2077 (nrecognizable insn) [alpha]
-- rth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|-00-00 00:00:00 |2007-04-19 18:18:30 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28623
[Bug pch/31634] New: *_SECTION_ASM_OP storage has undocumented constraints
The macros TEXT_SECTION_ASM_OP, DATA_SECTION_ASM_OP, SDATA_SECTION_ASM_OP, READONLY_DATA_SECTION_ASM_OP, CTORS_SECTION_ASM_OP, DTORS_SECTION_ASM_OP, BSS_SECTION_ASM_OP and SBSS_SECTION_ASM_OP are used by varasm.c:init_varasm_once to pass their value to get_unnamed_section; the result of that function call is then stored into a ggc root. That means that pch fails if the string value one of these macros is in storage that is not pch-safe, and the string is subsequently used in a compilation useing a precompiled header. In particular, ggc-allocated strings are safe; string literals might be safe, if they come from a cc1 binary (rather than a dso), and no address space randomization is in effect. (x)malloced emmory is not safe. What I see with some gcc/dg/pch test cases for a port which uses xmalloed memory is that the sections are swaitched around, most often .text against .data (for valid-2.c Letext0 ended up in .data), but also .text or .rodata against nothing (i.e. carry on in previous section), or just some garbage string. We should either remove this restriction, or document it. Considering that many ports use string literals, and many hosts in the wild now use address space randomization, I think we should remove this restriction by copying the string to ggc-allocated memory. As far as I can see, all uses of get_unnamed_section pass a NULL or string as third parameter, except for the rs6000, which passes pointers to global variables - which in the case of address space randomization on the host is just as unsuitable as a string literal. The rs6000 cannot be converted trivially to using strings, since the variables addresses are used in code called from backend_init, while the initialization of the variables is called from do_compile, which is three lines down in toplev.c:do_compile. So I think the easiest solution is change get_unnamed_section to take a char* for the third argument, which is copied to ggc-ed memory if not NULL, and have another function providing the old functionality of get_unnamed_section for the rs6000 target non-string usages. The rs6000 target port could presumably be fixed to work on a host with address space randomization by using indices into an array instead of pointers, or by forcing initialization of the section names from rs6000_xcoff_asm_init_sections, but this is really a separate issue. -- Summary: *_SECTION_ASM_OP storage has undocumented constraints Product: gcc Version: 4.2.0 Status: UNCONFIRMED Keywords: wrong-code, ice-on-valid-code, wrong-debug, link- failure, assemble-failure Severity: normal Priority: P3 Component: pch AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: amylaar at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31634
[Bug target/31635] New: -mno-vrsave ignored on ppc64
The -mno-vrsave switch as well as the old -mvrsave=no is ignored on 64bit target. Testcase is an empty file. Results with powerpc64-unknown-linux-gnu-gcc -o a.s -c b.c -maltivec -mno-vrsave -S -fverbose-asm -m64 into: # rs6000/powerpc options: -msdata=none .section".toc","aw" .section".text" # GNU C version 4.1.2 (Gentoo 4.1.2) (powerpc64-unknown-linux-gnu) # compiled by GNU C version 4.1.1 (Gentoo 4.1.1-r3). # GGC heuristics: --param ggc-min-expand=44 --param ggc-min-heapsize=27672 # options passed: -D__unix__ -D__gnu_linux__ -D__linux__ -Dunix -D__unix # -Dlinux -D__linux -Asystem=linux -Asystem=unix -Asystem=posix # -msecure-plt -maltivec -mno-vrsave -m64 -auxbase-strip -fverbose-asm # options enabled: -falign-loops -fargument-alias -fbranch-count-reg # -fcommon -fearly-inlining -feliminate-unused-debug-types -ffunction-cse # -fgcse-lm -fident -finline-functions-called-once -fivopts # -fkeep-static-consts -fleading-underscore -floop-optimize2 -fmath-errno # -fpeephole -freg-struct-return -fsched-interblock -fsched-spec # -fsched-stalled-insns-dep -fshow-column -fsplit-ivs-in-unroller # -ftrapping-math -ftree-loop-im -ftree-loop-ivcanon -ftree-loop-optimize # -ftree-vect-loop-version -fverbose-asm -fzero-initialized-in-bss -m64 # -maix-struct-return -maltivec -mbig -mbig-endian -mfp-in-toc # -mfused-madd -mhard-float -mnew-mnemonics -mpowerpc -mpowerpc-gfxopt # -mpowerpc64 -msched-prolog -msecure-plt -mupdate -mvrsave # Compiler executable checksum: 9f98a4867284f64c17c8db6425da4d5f .ident "GCC: (GNU) 4.1.2 (Gentoo 4.1.2)" Somehow -mvrsave comes into "option enabled" -m32 does not pass this. -- Summary: -mno-vrsave ignored on ppc64 Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: gcc at breakpoint dot cc GCC build triplet: powerpc64-linux-gnu GCC host triplet: powerpc64-linux-gnu GCC target triplet: powerpc64-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31635
[Bug pch/31634] *_SECTION_ASM_OP storage has undocumented constraints
--- Comment #1 from amylaar at gcc dot gnu dot org 2007-04-19 19:27 --- On second thought, the implementation is simpler when NULL is not treated specially. But then there is a slight majority of the uses in the config directory that wants the old behaviour of get_unnamed_section, so it makes sense to use a new name for the new function - or macro - which does an ggc_strdup of the third argument. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31634
[Bug tree-optimization/31636] New: ICE in GCC 4.2 with dllimport attribute returns
I know this is being reported again, but this seems to be occuring again after
being fixed.
This is the same bug that was reported in #29826 but it has now happened again
in gcc-4.2.
The test program is essentially the same as was given in the old version.
# 1 "test.c"
# 1 ""
# 1 ""
# 1 "test.c"
struct s
{
const char *x1;
const char *x2;
};
extern __attribute__((dllimport)) struct s v[];
int z();
int f()
{
int i;
for (i = 0; i < 2; i++)
{
z(v[i].x2);
}
return 0;
}
The error output which occurs is.
test.c: In function 'f':
test.c:19: error: unrecognizable insn:
(insn 15 13 16 3 (set (reg/f:SI 64)
(const:SI (plus:SI (mem:SI (symbol_ref:SI ("#i.v") ) [0 S4 A8])
(const_int 4 [0x4] -1 (nil)
(nil))
test.c:19: internal compiler error: in extract_insn, at recog.c:2077
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
And my gcc information is.
Using built-in specs.
Target: i686-pc-mingw32
Configured with: ../gcc-4.2/configure --target=i686-pc-mingw32
--prefix=/crosstools/gccwin-4.2 --enable-shared --enable-threads --disable-nls
--disable-multilib --enable-c99 --enable-long-long --enable-sjlj-exceptions
--enable-languages=c,c++,ada,fortran,objc,obj-c++,java --enable-libada
--enable-boehm-gc
Thread model: win32
gcc version 4.2.0 20070419 (prerelease)
I have tried to report this using the old thread twice now, but it hasn't been
replied to so I decided to start a new bug report for it, forgive me if I made
a mistake.
--
Summary: ICE in GCC 4.2 with dllimport attribute returns
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: arcangelpip at hotmail dot com
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-mingw32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31636
[Bug target/31636] ICE in GCC 4.2 with dllimport attribute returns
--- Comment #1 from arcangelpip at hotmail dot com 2007-04-19 19:51 --- Forgot to mention, it works the same as before. If the optimisations are removed then it will compile, but if you have -O1 -O2 or -O3 in the command line then it will ICE. Also, if the dllimport is removed then it will work. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31636
[Bug target/31636] ICE in GCC 4.2 with dllimport attribute returns
--- Comment #2 from arcangelpip at hotmail dot com 2007-04-19 19:55 --- Forgot to mention 2. -_-; memory is getting worse, I'm sure of it. Command line used. With the executable in the path. i686-pc-mingw32-gcc -c -O2 -o test.o test.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31636
[Bug c++/31579] [4.3 regression] ICE when compiling attached code
--- Comment #3 from bangerth at dealii dot org 2007-04-19 20:06 --- Confirmed. This is a regression on at least mainline. I don't have my set of compilers around here to verify if it is also a regression on 4.1 and 4.2.x. It seems to work with 4.0.x. W. -- bangerth at dealii dot org changed: What|Removed |Added CC||bangerth at dealii dot org Summary|ICE when compiling attached |[4.3 regression] ICE when |code|compiling attached code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31579
[Bug c++/31596] Internal compiler error (Segmentation fault)
--- Comment #2 from bangerth at dealii dot org 2007-04-19 20:08 --- This appears fixed since gcc 3.4.x. -- bangerth at dealii dot org changed: What|Removed |Added CC||bangerth at dealii dot org Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31596
[Bug c++/31579] [4.3 regression] ICE when compiling attached code
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added GCC build triplet|i686-pc-linux-gnu | GCC host triplet|i686-pc-linux-gnu | GCC target triplet|i686-pc-linux-gnu | Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31579
[Bug c++/31597] Unrecognized ambiguity in function overloading
--- Comment #2 from bangerth at dealii dot org 2007-04-19 20:10 --- Fixed since 4.0.x. W. -- bangerth at dealii dot org changed: What|Removed |Added CC||bangerth at dealii dot org Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31597
[Bug c++/31579] [4.3 regression] ICE when compiling attached code
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-04-19 20:15 --- (In reply to comment #3) > Confirmed. This is a regression on at least mainline. I don't > have my set of compilers around here to verify if it is also a > regression on 4.1 and 4.2.x. It seems to work with 4.0.x. I tried it out with 4.1.1 and 4.2.0 and it works there. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Known to work|4.1.1 |4.1.1 4.2.0 Last reconfirmed|-00-00 00:00:00 |2007-04-19 20:15:32 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31579
[Bug fortran/31637] New: warn about implicit conversion causing loss of precision
For the program program main implicit none real :: xx double precision :: yy call random_seed() call random_number(yy) xx = yy ! assign double to single print*,"yy =",yy print*,"xx =",xx end program main g95 -Wall -Wextra says In file xreal_dp.f90:7 xx = yy 1 Warning (140): Implicit conversion at (1) may cause precision loss I request a similar warning from gfortran. None is currently given when compiling with gfortran -Wall -pedantic -std=f2003 xreal_dp.f90 . Vivek Rao -- Summary: warn about implicit conversion causing loss of precision Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: vivekrao4 at yahoo dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31637
[Bug fortran/31610] ICE with transfer, merge in gfc_conv_expr_descriptor
--- Comment #2 from pault at gcc dot gnu dot org 2007-04-19 20:47 ---
(In reply to comment #1)
This does the trick but I haven't checked against the standard, nor have I
regtested.
Paul
Index: /svn/trunk/gcc/fortran/check.c
===
*** /svn/trunk/gcc/fortran/check.c (revision 123643)
--- /svn/trunk/gcc/fortran/check.c (working copy)
*** static try
*** 218,224
same_type_check (gfc_expr *e, int n, gfc_expr *f, int m)
{
if (gfc_compare_types (&e->ts, &f->ts))
! return SUCCESS;
gfc_error ("'%s' argument of '%s' intrinsic at %L must be the same type "
"and kind as '%s'", gfc_current_intrinsic_arg[m],
--- 218,241
same_type_check (gfc_expr *e, int n, gfc_expr *f, int m)
{
if (gfc_compare_types (&e->ts, &f->ts))
! {
! if (e->ts.type != BT_CHARACTER)
! return SUCCESS;
!
! else if (e->ts.cl->length
! && e->ts.cl->length->expr_type == EXPR_CONSTANT
! && f->ts.cl->length
! && f->ts.cl->length->expr_type == EXPR_CONSTANT
! && mpz_cmp (e->ts.cl->length->value.integer,
! f->ts.cl->length->value.integer) != 0)
! {
! gfc_error ("'%s' argument of '%s' intrinsic at %L must have "
!"the same character length as '%s'",
!gfc_current_intrinsic_arg[m], gfc_current_intrinsic,
!&f->where, gfc_current_intrinsic_arg[n]);
! return FAILURE;
! }
! }
gfc_error ("'%s' argument of '%s' intrinsic at %L must be the same type "
"and kind as '%s'", gfc_current_intrinsic_arg[m],
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31610
[Bug libfortran/30694] minval/maxval with +/-Inf
--- Comment #15 from tkoenig at gcc dot gnu dot org 2007-04-19 21:03
---
(In reply to comment #14)
> (In reply to comment #13)
> > The tree stuff is hard, btw. Still trying :-)
>
> Tree stuff? Do we generate inline code?
We generate inline code for rank 0 minval and minloc, i.e.
real :: a(3)
print *,minloc(a,dim=1)
Here's a partial patch for this case:
Index: gfortran.h
===
--- gfortran.h (revision 123958)
+++ gfortran.h (working copy)
@@ -1351,7 +1351,7 @@ extern gfc_logical_info gfc_logical_kind
typedef struct
{
- mpfr_t epsilon, huge, tiny, subnormal;
+ mpfr_t epsilon, huge, tiny, subnormal, infinity;
int kind, radix, digits, min_exponent, max_exponent;
int range, precision;
Index: arith.c
===
--- arith.c (revision 123958)
+++ arith.c (working copy)
@@ -247,6 +247,10 @@ gfc_arith_init_1 (void)
if (i == real_info->radix)
real_info->precision++;
+ /* Infinity. */
+ mpfr_init (real_info->infinity);
+ mpfr_set_inf (real_info->infinity, 1);
+
mpfr_clear (a);
mpfr_clear (b);
mpfr_clear (c);
@@ -277,6 +281,7 @@ gfc_arith_done_1 (void)
mpfr_clear (rp->huge);
mpfr_clear (rp->tiny);
mpfr_clear (rp->subnormal);
+ mpfr_clear (rp->infinity);
}
}
Index: trans-intrinsic.c
===
--- trans-intrinsic.c (revision 123958)
+++ trans-intrinsic.c (working copy)
@@ -1926,8 +1926,10 @@ gfc_conv_intrinsic_minmaxloc (gfc_se * s
tree limit;
tree type;
tree tmp;
+ tree tmp2;
tree elsetmp;
tree ifbody;
+ tree execute_loop;
gfc_loopinfo loop;
gfc_actual_arglist *actual;
gfc_ss *arrayss;
@@ -1967,11 +1969,14 @@ gfc_conv_intrinsic_minmaxloc (gfc_se * s
maskss = NULL;
limit = gfc_create_var (gfc_typenode_for_spec (&arrayexpr->ts), "limit");
+ execute_loop = gfc_create_var (boolean_type_node, "execute_loop");
+
n = gfc_validate_kind (arrayexpr->ts.type, arrayexpr->ts.kind, false);
switch (arrayexpr->ts.type)
{
case BT_REAL:
- tmp = gfc_conv_mpfr_to_tree (gfc_real_kinds[n].huge,
arrayexpr->ts.kind);+ tmp = gfc_conv_mpfr_to_tree
(gfc_real_kinds[n].infinity,
+ arrayexpr->ts.kind);
break;
case BT_INTEGER:
@@ -2007,14 +2012,18 @@ gfc_conv_intrinsic_minmaxloc (gfc_se * s
gcc_assert (loop.dimen == 1);
- /* Initialize the position to zero, following Fortran 2003. We are free
- to do this because Fortran 95 allows the result of an entirely false
- mask to be processor dependent. */
- gfc_add_modify_expr (&loop.pre, pos, gfc_index_zero_node);
+ /* Initialize the position to one. */
+ gfc_add_modify_expr (&loop.pre, pos, gfc_index_one_node);
gfc_mark_ss_chain_used (arrayss, 1);
if (maskss)
gfc_mark_ss_chain_used (maskss, 1);
+
+ /* Check whether the loop is evaluated at all. */
+
+ tmp2 = fold_build2 (GE_EXPR, boolean_type_node, loop.to[0], loop.from[0]);
+ gfc_add_modify_expr (&se->pre, execute_loop, tmp2);
+
/* Generate the loop body. */
gfc_start_scalarized_body (&loop, &body);
@@ -2050,10 +2059,9 @@ gfc_conv_intrinsic_minmaxloc (gfc_se * s
ifbody = gfc_finish_block (&ifblock);
- /* If it is a more extreme value or pos is still zero. */
- tmp = build2 (TRUTH_OR_EXPR, boolean_type_node,
- build2 (op, boolean_type_node, arrayse.expr, limit),
- build2 (EQ_EXPR, boolean_type_node, pos,
gfc_index_zero_node));
+ /* If it is a more extreme value. */
+ tmp = build2 (op, boolean_type_node, arrayse.expr, limit);
+
tmp = build3_v (COND_EXPR, tmp, ifbody, build_empty_stmt ());
gfc_add_expr_to_block (&block, tmp);
@@ -2066,36 +2074,41 @@ gfc_conv_intrinsic_minmaxloc (gfc_se * s
}
else
tmp = gfc_finish_block (&block);
+
gfc_add_expr_to_block (&body, tmp);
gfc_trans_scalarizing_loops (&loop, &body);
- /* For a scalar mask, enclose the loop in an if statement. */
+ /* Enclose the loop in an if statement. We don't execute it if the
+ trip count would be zero, or if a scalar mask is false. */
+
if (maskexpr && maskss == NULL)
{
gfc_init_se (&maskse, NULL);
gfc_conv_expr_val (&maskse, maskexpr);
- gfc_init_block (&block);
- gfc_add_block_to_block (&block, &loop.pre);
- gfc_add_block_to_block (&block, &loop.post);
- tmp = gfc_finish_block (&block);
- /* For the else part of the scalar mask, just initialize
-the pos variable the same way as above. */
+ execute_loop = fold_build2 (TRUTH_AND_EXPR, boolean_type_node,
execute_loop,
+ maskse.expr);
+}
+
+ gfc_init_block (&block);
+ gfc_add_block_to_block (&block, &loop.pre);
+ gfc_add_block_to_block (&block, &loop.post);
- gfc_init_block (&elseblock);
- gfc_add_
[Bug fortran/31618] backspace intrinsic is not working on an unformatted file
--- Comment #3 from tkoenig at gcc dot gnu dot org 2007-04-19 21:35 --- (In reply to comment #2) > Confirming. g77 does not do it right either. :) gfortran 4.1 doesn't get this right either, so at least this isn't a regression. Uff :-) -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added CC||tkoenig at gcc dot gnu dot ||org Keywords||wrong-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31618
[Bug fortran/31637] warn about implicit conversion causing loss of precision
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-04-19 21:45 --- *** This bug has been marked as a duplicate of 27866 *** -- 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=31637
[Bug fortran/27866] Warn when casting, e.g. assigning a double precision to a real
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-04-19 21:45 --- *** Bug 31637 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||vivekrao4 at yahoo dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27866
[Bug fortran/31612] -fsyntax-only documentation is not accurate
--- Comment #1 from tobi at gcc dot gnu dot org 2007-04-19 22:42 --- module a end module a use a end How are you going to handle this? There's no meaningful syntax checking without also creating modules. One could maybe create the modules in a temporary place? -- tobi at gcc dot gnu dot org changed: What|Removed |Added CC||tobi at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31612
[Bug fortran/31612] -fsyntax-only documentation is not accurate
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-04-19 22:44 --- Simply fixing the doc is also fine with me :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31612
[Bug target/31480] [4.1/4.2 Regression] ICE with -O -fomit-frame-pointer on SH
--- Comment #1 from kkojima at gcc dot gnu dot org 2007-04-20 00:05 --- I've confirmed that the testcase doesn't fail with 3.4 compiler and fails with 4.0, 4.1 and 4.2. Although it doesn't fail with the current trunk compiler, it might be simply latent. The segfault occurs in insn_current_length when evaluating GET_CODE for a null rtx. Now I'm testing the patch below. --- ORIG/trunk/gcc/config/sh/sh.md 2007-03-29 08:44:33.0 +0900 +++ LOCAL/trunk/gcc/config/sh/sh.md 2007-04-19 11:02:06.0 +0900 @@ -420,10 +420,12 @@ (eq_attr "type" "jump") (cond [(eq_attr "med_branch_p" "yes") (const_int 2) - (and (eq (symbol_ref "GET_CODE (prev_nonnote_insn (insn))") - (symbol_ref "INSN")) - (eq (symbol_ref "INSN_CODE (prev_nonnote_insn (insn))") - (symbol_ref "code_for_indirect_jump_scratch"))) + (and (ne (symbol_ref "prev_nonnote_insn (insn)") +(const_int 0)) +(and (eq (symbol_ref "GET_CODE (prev_nonnote_insn (insn))") + (symbol_ref "INSN")) + (eq (symbol_ref "INSN_CODE (prev_nonnote_insn (insn))") + (symbol_ref "code_for_indirect_jump_scratch" (cond [(eq_attr "braf_branch_p" "yes") (const_int 6) (eq (symbol_ref "flag_pic") (const_int 0)) -- kkojima at gcc dot gnu dot org changed: What|Removed |Added CC||kkojima at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Known to fail||4.0.4 4.1.2 4.2.0 Known to work||3.4.6 Last reconfirmed|-00-00 00:00:00 |2007-04-20 00:05:05 date|| Summary|internal compiler error:|[4.1/4.2 Regression] ICE |Segmentation fault |with -O -fomit-frame-pointer ||on SH http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31480
[Bug libstdc++/31638] New: [4.0/4.1/4.2/4.3 Regression] string usage leads to warning with -Wcast-align
[ Forwarded from http://bugs.debian.org/382153 This issue has been reported
by Margarita Manterola who also provided the testcase ]
If you compile the following testcase with -Wcast-align you get a warning
on certain architectures, including alpha, arm, hppa, ia64 and sparc.
I've verified this on ia64 with gcc 4.0, 4.1 and 4.3. 3.3 and 3.4 don't
show this warning. The warning goes away when you include in
addition to .
[EMAIL PROTECTED]:~/src$ /usr/lib/gcc-snapshot/bin/g++ -Wcast-align x.c
/usr/lib/gcc-snapshot/lib/gcc/ia64-linux-gnu/4.3.0/../../../../include/c++/4.3.0/bits/basic_string.h:
In member function 'std::basic_string<_CharT, _Traits, _Alloc>::_Rep*
std::basic_string<_CharT, _Traits, _Alloc>::_M_rep() const [with _CharT = char,
_Traits = std::char_traits, _Alloc = std::allocator]':
/usr/lib/gcc-snapshot/lib/gcc/ia64-linux-gnu/4.3.0/../../../../include/c++/4.3.0/bits/basic_string.h:496:
instantiated from 'std::basic_string<_CharT, _Traits,
_Alloc>::~basic_string() [with _CharT = char, _Traits = std::char_traits,
_Alloc = std::allocator]'
x.c:6: instantiated from here
/usr/lib/gcc-snapshot/lib/gcc/ia64-linux-gnu/4.3.0/../../../../include/c++/4.3.0/bits/basic_string.h:288:
warning: cast from 'char*' to 'std::basic_string,
std::allocator >::_Rep*' increases required alignment of target type
Testcase:
#include
using namespace std;
int main (int argc, char **argv) {
string hi;
hi = "Hi";
return 0;
}
--
Summary: [4.0/4.1/4.2/4.3 Regression] string usage leads to
warning with -Wcast-align
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tbm at cyrius dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31638
[Bug libstdc++/31638] [4.0/4.1/4.2/4.3 Regression] string usage leads to warning with -Wcast-align
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-04-20 00:49 --- I think this is really the same as PR 19495. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31638
[Bug fortran/31639] New: [4.1/4.2/4.3] ICE in gfc_conv_constant, at fortran/trans-const.c:348 with len
[ forwarded from http://bugs.debian.org/401496 The report and original testcase came from Jonathan Stott. I further reduced it down in size. ] I've confirmed this bug with 4.1.2 20061115 and 4.3.0 20070326. (sid)18753:[EMAIL PROTECTED]: ~/src/t] gfortran -c c.f90 c.f90: In function âxstrcmpâ: c.f90:5: internal compiler error: in gfc_conv_constant, at fortran/trans-const.c:348 Please submit a full bug report, with preprocessed source if appropriate. Testcase: module cfgfile contains integer function xstrcmp(s1) character*(*), intent(in) :: s1 integer :: n1 = len(s1) n1 = 1 return end function xstrcmp end module cfgfile -- Summary: [4.1/4.2/4.3] ICE in gfc_conv_constant, at fortran/trans-const.c:348 with len Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tbm at cyrius dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31639
[Bug fortran/31639] [4.1/4.2/4.3] ICE in gfc_conv_constant, at fortran/trans-const.c:348 with len
--- Comment #1 from brooks at gcc dot gnu dot org 2007-04-20 01:52 --- This is invalid code, since initialization expressions must be constants, and the length of an assumed-length string argument is not a constant. Regardless, we shouldn't be ICE'ing on it. -- brooks at gcc dot gnu dot org changed: What|Removed |Added CC||brooks at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||ice-on-invalid-code Known to fail||4.1.2 4.3.0 Last reconfirmed|-00-00 00:00:00 |2007-04-20 01:52:43 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31639
[Bug fortran/30285] gfortran excessive memory usage with large modules
--- Comment #11 from bdavis at gcc dot gnu dot org 2007-04-20 03:41 --- i think not. i must have confued myself (rather easy to do!). will dig through the source this weekend. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30285
[Bug libfortran/27740] libgfortran should use versioned symbols
--- Comment #13 from patchapp at dberlin dot org 2007-04-20 07:45 --- Subject: Bug number PR 27740 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-04/msg01253.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27740
[Bug libfortran/27740] libgfortran should use versioned symbols
--- Comment #14 from jb at gcc dot gnu dot org 2007-04-20 07:45 --- Patch here: http://gcc.gnu.org/ml/gcc-patches/2007-04/msg01253.html Also removed the dependency on PR25709 (ISO_C_BINDING), since we don't depend on that one anymore for this functionality. -- jb at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn|25709 | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27740
[Bug target/29826] __attribute__ dllimport makes optimization crash on cygwin
--- Comment #14 from dannysmith at users dot sourceforge dot net 2007-04-20 07:49 --- (In reply to comment #13) > I'm going to try again since it seems my last post was just ignored. > The test case works fine on 4.2 but it still occurs under some circumstances. If you provide preprocessed source that reproduces the circumstances , as suggested, I will not ignore it. Danny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29826
