[Bug bootstrap/27963] [4.2 Regression] libjava fails to build if it isn't built by default
--- Comment #9 from ayers at gcc dot gnu dot org 2006-06-12 07:04 --- Fixed for 4.2.0 -- ayers at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27963
[Bug web/12821] dead link on onlinedocs/gccint/Top-Level.html
--- Comment #3 from jv244 at cam dot ac dot uk 2006-06-12 07:18 --- (In reply to comment #0) still failing ... since it has been opened about 2.5y ago, should it be closed as wontfix ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12821
[Bug fortran/27996] New: Compile time warn for: character(2) :: str = 'ABC' (expression truncated)
In the following, the assignment to str gets truncated twice. gfortran -Wall does not give any warning. Expected: As similar warning as NAG gives: Warning: trunc.f90, line 2: Initialisation expression for STR truncated At least the first initalization should be detected, possibly also the second. Such error messaging works for real, dimension(3) :: [1.0, 2.0, 3.0] at both places: Error: different shape for Array assignment at (1) on dimension 1 (2/3) --- program test character(2) :: c = 'AAA' c = 'ABC' print *, c end program test --- -- Summary: Compile time warn for: character(2) :: str = 'ABC' (expression truncated) Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tobias dot burnus at physik dot fu-berlin dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27996
[Bug tree-optimization/27105] ICE with -O3 -ftree-loop-linear
--- Comment #4 from micis at gmx dot de 2006-06-12 10:24 --- I tried an actual snapshot of gcc (gcc-4.2-20060603) on this source and the ICE no longer occured. Michael Cieslinski -- micis at gmx dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27105
[Bug c++/26577] [4.0/4.1/4.2 regression] ICE in cp_expr_size with volatile and call to static
--- Comment #7 from dnovillo at redhat dot com 2006-06-12 12:12 --- Subject: Re: [4.0/4.1/4.2 regression] ICE in cp_expr_size with volatile and call to static mmitchel at gcc dot gnu dot org wrote on 06/05/06 18:37: > Diego, what say you? > Shouldn't COMPLETE_TYPE_P imply that we can compute the size of the type? That's the requisite we need in this case to emit the load from the volatile reference. Otherwise, we have no other choice but to throw it away. ISTM that if COMPLETE_TYPE_P had the right sizeof semantics, we wouldn't need the workaround added for 23167. The only thing the gimplifier can do in this case is throw the reference out, but -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26577
[Bug target/27861] [4.0/4.1/4.2 regression] ICE in expand_expr_real_1, at expr.c:6916
--- Comment #4 from tbm at cyrius dot com 2006-06-12 12:15 --- (In reply to comment #3) > I'm really on mipsel. ... but you can also see it with a x from i386 to mipsel. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27861
[Bug libstdc++/27993] Compile error: .libs/complex_io.o: could not read symbols: Bad value
--- Comment #2 from m_ansoor at yahoo dot com 2006-06-12 12:43 --- Hi, An echo of $PATH shows: /toolkit/newbin:/usr/local/bin:/usr/bin:/etc:/usr/sbin:/usr/ucb:/usr/bin/X11:/sbin:/usr/java14/jre/bin:/usr/java14/bin On the configure line, I had specified --prefix=/toolkit Is it possible that at some point during the 'make bootstrap' the prefix is picked up and an ld is put into the /toolkit/powerpc-ibm-aix5.2/ directory. I think this might be true since the directory /toolkit/powerpc-ibm-aix5.2/ did not even exist when I did the configure -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27993
[Bug fortran/27954] ICE on garbage in DATA statement
--- Comment #2 from reichelt at gcc dot gnu dot org 2006-06-12 12:45 --- Well, the "Internal Error" at the end of the eror message doesn't look like "the right thing" to me: Internal Error at (1): gfc_get_default_type(): Bad symbol And this happens since GCC 4.0.0. I.e. GCC 4.0.x, 4.1.x, and mainline are affected. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27954
[Bug fortran/27997] New: Fortran 2003: Support type-spec for array constructor, i.e. (/ real :: 1., 2., 3. /)
See Fortran 2003 standard, section 4.8. Example (F2003, "Note 4.70"): (/ CHARACTER(LEN=7) :: Takata, Tanaka, Hayashi /) Currently, this gives the error: a = (/ character(len=7) :: 'Takata', 'Tanaka', 'Hayashi' /) 1 Error: Syntax error in array constructor at (1) - program test character(15) :: a(3) a = (/ character(len=7) :: 'Takata', 'Tanaka', 'Hayashi' /) print '(a)',a end program test - -- Summary: Fortran 2003: Support type-spec for array constructor, i.e. (/ real :: 1., 2., 3. /) Product: gcc Version: unknown Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tobias dot burnus at physik dot fu-berlin dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27997
[Bug fortran/27998] New: character arrays: warn if erray constructor values have different lengths
The following constructor seems to be invalid according to the Fortran 2003 standard: (/ 'Takata', 'Tanaka', 'Hayashi' /) as first two strings are 6 whereas the last one is 7 character long. NAG f95 fails with the following error: Error: string.f90, line 3: Array constructor values have differing CHARACTER lengths (6 and 7) [f95 error termination] Thus a warning would be nice, at least with -Wall, maybe even a default warning. In the Fortran 2003 standard, I cannot find the line which forbids the usage of different length strings. However, in "NOTE 4.70" of implicitly states that it is not allowed: "An example of an array constructor that specifies a nonkind type parameter: (/ CHARACTER(LEN=7) :: Takata, Tanaka, Hayashi /) In this constructor, without the type specification, it would have been necessary to specify all of the constants with the same character length." (This currently does not work in gfortran, see bug 27997.) Example: program test character(15) :: a(3) ! invalid as the constants have different character lengths a = (/ 'Takata', 'Tanaka', 'Hayashi' /) ! This is valid Fortran 95/2003 !a = (/ 'Takata ', 'Tanaka ', 'Hayashi' /) ! And this is valid Fortran 2003 !a = (/ character(len=7) :: 'Takata ', 'Tanaka ', 'Hayashi' /) print '(a)',a end program test -- Summary: character arrays: warn if erray constructor values have different lengths Product: gcc Version: unknown Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tobias dot burnus at physik dot fu-berlin dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27998
[Bug tree-optimization/25737] [4.1/4.2 Regression] ACATS c974001 c974013 hang with struct aliasing
--- Comment #28 from danglin at gcc dot gnu dot org 2006-06-12 13:21 --- See hang on hppa1.1-hp-hpux10.20 for c974013. I don't know whether these are the same problem but c974004 and c974005 are also failing on this target: ,.,. C974004 ACATS 2.5 06-06-11 23:43:09 C974004 Asynchronous Select: Trigger is queued on a task entry and is completed first by an exception. raised C974004_0.PROPAGATED_FROM_TASK : s-tasini.adb:286 ,.,. C974005 ACATS 2.5 06-06-11 23:44:16 C974005 ATC: trigger is queued but task terminates before call is serviced. raised TASKING_ERROR : s-tasini.adb:286 -- danglin at gcc dot gnu dot org changed: What|Removed |Added CC||danglin at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25737
[Bug ada/27999] New: FAIL: c64005c
raised STORAGE_ERROR : stack overflow detected Stack size is set to 8192 kbytes. This doesn't happen all the time. -- Summary: FAIL: c64005c Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu dot org GCC build triplet: hppa-unknown-linux-gnu GCC host triplet: hppa-unknown-linux-gnu GCC target triplet: hppa-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27999
[Bug libstdc++/27878] GCC 4.1.1 build fails on mips-sgi-irix6.5 (libstdc++)/GCC 4.1.0 worked.
--- Comment #12 from martinol at nrlssc dot navy dot mil 2006-06-12 13:39 --- Created an attachment (id=11652) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11652&action=view) mips-sgi-irix6.5/libstdc++-v3/config.log from gcc-4.1-20060428 build -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27878
[Bug fortran/27954] ICE on garbage in DATA statement
--- Comment #3 from kargl at gcc dot gnu dot org 2006-06-12 14:23 --- I don't see the internal error. laptop:kargl[205] cat > r.f90 subroutine FOO character*20 X 0 data X /'A'/0 end subroutine FOO laptop:kargl[206] gfc -c r.f90 In file r.f90:3 character*20 X 0 1 Error: Syntax error in data declaration at (1) In file r.f90:4 data X /'A'/0 1 Error: Syntax error in DATA statement at (1) In file r.f90:4 data X /'A'/0 1 Error: Incompatible types in assignment at (1), CHARACTER(1) to REAL(4) laptop:kargl[208] gfc -c r.f In file r.f:4 data X /'A'/0 1 Error: Syntax error in DATA statement at (1) In file r.f:4 data X /'A'/0 1 Error: Incompatible types in assignment at (1), CHARACTER(1) to REAL(4) laptop:kargl[209] gfc --version GNU Fortran 95 (GCC) 4.2.0 20060610 (experimental) Copyright (C) 2006 Free Software Foundation, Inc. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27954
[Bug target/18748] first instruction in each procedure isn't unwindable
--- Comment #3 from matz at gcc dot gnu dot org 2006-06-12 14:40 --- Is this still a problem David? On x86_64 the libunwind-0.98.5 doesn't work for ptrace (missing implemented functions), so I can't reproduce anything on that platform. And on ia64-linux with a 4.1.x compiler test-ptrace doesn't spit out any errors. -- matz at gcc dot gnu dot org changed: What|Removed |Added CC||matz at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18748
[Bug fortran/27954] ICE on garbage in DATA statement
--- Comment #4 from reichelt at gcc dot gnu dot org 2006-06-12 15:32 --- Maybe it's target dependent? Are you using --enable-checking? I have % gfortran -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ../gcc/configure --enable-languages=c,c++,fortran,java,objc,obj-c++ --enable-threads --enable-checking --prefix=/somepath/gcc-4.2-20060612 --with-gmp=/somepath/GMP --with-mpfr=/somepath/MPFR Thread model: posix gcc version 4.2.0 20060612 (experimental) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27954
[Bug target/27363] ARM gcc 4.1 optimization bug
--- Comment #7 from dirk dot behme at googlemail dot com 2006-06-12 15:34 --- Until a fix for this bug is found, there are two possible workarounds: - Compile kernels sound system as modules and compile these modules with -O1 instead of default -Os or -O2 (e.g. by changing main Makefile). - Use this patch from Fengwei Yin <[EMAIL PROTECTED]> (then -Os or -O2 should work): -- linux/include/sound/pcm_params.h2005-03-02 09:31:53.0 +0800 +++ linux-ok/include/sound/pcm_params.h 2006-06-08 09:57:11.0 +0800 @@ -196,6 +196,11 @@ INLINE int snd_mask_refine(snd_mask_t *m snd_mask_t old; assert(!snd_mask_empty(mask)); snd_mask_copy(&old, mask); + /* +* add the barrier to fix the optimization +* error of GCC 4.1 + */ + mb(); snd_mask_intersect(mask, v); if (snd_mask_empty(mask)) return -EINVAL; Note that this is only a workaround. It will drop the Alsa subsystem performance. -- dirk dot behme at googlemail dot com changed: What|Removed |Added CC||dirk dot behme at googlemail ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27363
[Bug c/28001] New: incrementing a variable produces smaller code than an explicit assignment
I'd expect that at least the same code is generated for both cases as opposed
to creating worse code for the case where an explicit assignment is done.
I had hoped that the explicit assignment actually creates smaller code.
$ gcc -DDOINC -Os -march=i386 -c -o scan.o.orig scan.c
$ gcc -UDOINC -Os -march=i386 -c -o scan.o scan.c
$ size scan.o*
textdata bss dec hex filename
127 0 0 127 7f scan.o
123 0 0 123 7b scan.o.orig
$ cat scan.c
#include
#include
static void check(int pid) { fprintf(stderr,"found %i\n", pid); }
int main (void)
{
DIR *procdir;
struct dirent *entry;
int foundany, pid;
procdir = opendir ("/proc");
foundany = 0;
while ((entry = readdir (procdir)) != NULL)
{
if (sscanf (entry->d_name, "%d", &pid) != 1)
continue;
#ifdef DOINC
foundany++;
#else
foundany = 1;
#endif
check (pid);
}
closedir (procdir);
if (!foundany)
return 1; /* bb_perror_msg_and_die("nothing in /proc - not mounted?");*/
return 0;
}
--
Summary: incrementing a variable produces smaller code than an
explicit assignment
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: aldot at gcc dot gnu dot org
GCC build triplet: i386-linux-gnu
GCC host triplet: i386-linux-gnu
GCC target triplet: i386-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28001
[Bug libfortran/27046] [mingw32] mixed C-Fortran I/O doesn't flush
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2006-06-12 16:30
---
This is not DLL-related, the following code doesn't have the expected behaviour
(although it works fine on i686-linux, even in the static case):
$ cat ctesti.c
#include
void print_from_gcc(char* txt) {
printf("%s\n",txt);
}
int main(int argc, char** argv) {
print_from_gcc ("c");
print_from_gfortran_("f");
print_from_gcc ("c");
print_from_gfortran_("f");
return 0;
}
$ cat ftesti.f90
subroutine print_from_gfortran(txt)
implicit none
character :: txt
print *,txt
end subroutine print_from_gfortran
$ ../gfortran/bin/gfortran.exe ftesti.f90 ctesti.c
$ ./a.exe
c
c
f
f
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Last reconfirmed|2006-05-21 14:03:39 |2006-06-12 16:30:13
date||
Summary|[mingw32] gfortran print|[mingw32] mixed C-Fortran
|flush in dll|I/O doesn't flush
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27046
[Bug other/28002] New: decNumber sources need GPL+exception for use in libgcc
The decNumber sources files in libdecnumber were contributed by IBM and are currently covered by the GPL. When GCC is configured with --enable-decimal-float, some of these functions are included in the static version of libgcc. The license needs to change from GPL to GPL plus exception. I've assigned this to myself as a reminder to contact the appropriate people within IBM and then the FSF. -- Summary: decNumber sources need GPL+exception for use in libgcc Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: janis at gcc dot gnu dot org ReportedBy: janis at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28002
[Bug ada/27937] [4.2 Regression] Ada bootstrap failure on Solaris 10/x86
--- Comment #4 from ro at techfak dot uni-bielefeld dot de 2006-06-12 17:45 --- Subject: Re: [4.2 Regression] Ada bootstrap failure on Solaris 10/x86 ebotcazou at gcc dot gnu dot org writes: > Right, it's another kind of SJLJ exceptions, purely front-end based. Excerpt > from system-solaris-x86.ads: > >ZCX_By_Default: constant Boolean := False; >GCC_ZCX_Support : constant Boolean := False; Ok, I see. Thanks for the explanation. Any reason this is done this way? Solaris/SPARC doesn't use this, nor does Linux/x86, so it seems like both the Solaris and x86 parts of the code are there. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27937
[Bug tree-optimization/27882] [4.2 regression] segfault in ipa-inline.c, if (e->callee->local.disregard_inline_limits
--- Comment #19 from tbm at cyrius dot com 2006-06-12 18:03 --- Created an attachment (id=11654) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11654&action=view) C test case Here's a C test case (from the Linux kernel). 5289:[EMAIL PROTECTED]: ~] /usr/local/bin/gcc -c -O2 --param ggc-min-expand=0 --param ggc-min-heapsize=0 net.i net/tipc/net.c:311: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. zsh: exit 1 /usr/local/bin/gcc -c -O2 --param ggc-min-expand=0 --param ggc-min-heapsize=0 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27882
[Bug libstdc++/27878] GCC 4.1.1 build fails on mips-sgi-irix6.5 (libstdc++)/GCC 4.1.0 worked.
--- Comment #13 from martinol at nrlssc dot navy dot mil 2006-06-12 18:04 --- Created an attachment (id=11655) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11655&action=view) ./mips-sgi-irix6.5/libstdc++-v3/config.log This is from gcc-4.1-20060512 snapshot. So between 20060428 and 20060512, it stopped compiling. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27878
[Bug ada/27937] [4.2 Regression] Ada bootstrap failure on Solaris 10/x86
--- Comment #5 from ebotcazou at gcc dot gnu dot org 2006-06-12 18:11 --- > Ok, I see. Thanks for the explanation. Any reason this is done this way? > Solaris/SPARC doesn't use this, nor does Linux/x86, so it seems like both > the Solaris and x86 parts of the code are there. Short answer: seamless support for synchronous signals. Long answer: we want to be able to turn synchronous signals into regular Ada exceptions. This means unwinding through signal handler frames (easy) and unwinding through kernel frames (tricky). With SJLJ exceptions, the latter turns out to be transparent; but with DWARF-2 EH exceptions, you need specific support code under the form of MD_FALLBACK_FRAME_STATE_FOR macros, defined in the *-unwind.h files. The FSF tree contains some M_F_F_S_F macros, we have a few more, in particular for SPARC/Solaris but not for x86/Solaris. We should already have contributed them, but there is a discrepancy between Java and Ada in this domain that should be sorted out first. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27937
[Bug target/28001] incrementing a variable produces smaller code than an explicit assignment
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-06-12 18:43 --- The reason why increment is smaller is because the inc instruction is smaller than loading a constant. This is a target specific optimization as most other targets, it is going to be about the same. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement Status|UNCONFIRMED |NEW Component|middle-end |target Ever Confirmed|0 |1 GCC build triplet|i386-linux-gnu | GCC host triplet|i386-linux-gnu | GCC target triplet|i386-linux-gnu |i?86-*-* Last reconfirmed|-00-00 00:00:00 |2006-06-12 18:43:47 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28001
[Bug c++/21210] [4.0/4.1/4.2 Regression] Trouble with __complex__ types default construction
--- Comment #9 from sayle at gcc dot gnu dot org 2006-06-12 18:55 --- Subject: Bug 21210 Author: sayle Date: Mon Jun 12 18:50:22 2006 New Revision: 114573 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114573 Log: PR c++/21210 * typeck2.c (build_functional_cast): Use cp_convert to construct non-aggregate initializers instead of the user-level build_c_cast. * g++.dg/init/complex1.C: New test case. Added: trunk/gcc/testsuite/g++.dg/init/complex1.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/typeck2.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21210
[Bug inline-asm/23399] ICE in create_tmp_var, at gimplify.c:387
--- Comment #3 from pluto at agmk dot net 2006-06-12 19:15 --- still ice. -- pluto at agmk dot net changed: What|Removed |Added Known to fail|2.95 3.0.4 3.2.2 4.0.0 3.4.0|2.95 3.0.4 3.2.2 4.0.0 3.4.0 |3.3.3 |3.3.3 4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23399
[Bug c++/28003] New: optimizer bug
I will attach a small reproducer. /* Reproducer for optimizer bug in gcc svn trunk revision 114570 (as checked out 2006_06_12_0834 PDT) To produce correct output: g++ -Wall -O0 gcc_trunk_2006_06_12_0834_fc5_x86_64.cpp ./a.out To see the bug: g++ -Wall -O1 gcc_trunk_2006_06_12_0834_fc5_x86_64.cpp ./a.out Note the difference in the last line of the output: Correct: 1 0 0 Incorrect: 0 0 0 The output is also incorrect for -O2 and -O3. The last line of the output is correct if compiled with: g++ -Wall -O1 -DBAD_WORKAROUND gcc_trunk_2006_06_12_0834_fc5_x86_64.cpp ./a.out Platform: Fedora Core release 5 (Bordeaux) Linux rosie.lbl.gov 2.6.15-1.2054_FC5 #1 SMP Tue Mar 14 15:48:20 EST 2006 x 86_64 x86_64 x86_64 GNU/Linux % g++ -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: /net/rosie/scratch1/rwgk/gcc_trunk/configure --prefix=/usr /local_cci/gcc_trunk_2006_06_12_0834_fc5_x86_64 --enable-languages=c,c++ Thread model: posix gcc version 4.2.0 20060612 (experimental) */ -- Summary: optimizer bug Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rwgk at yahoo dot com GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28003
[Bug c++/28003] optimizer bug
--- Comment #1 from rwgk at yahoo dot com 2006-06-12 19:28 --- Created an attachment (id=11656) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11656&action=view) short reproducer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28003
[Bug target/28001] incrementing a variable produces smaller code than an explicit assignment
--- Comment #2 from steven at gcc dot gnu dot org 2006-06-12 19:43 --- This will never be implemented. -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28001
[Bug fortran/28004] New: Warn if intent(out) dummy variable is not set
GNU Fortran 95 (GCC) 4.2.0 20060612. If I write a program with a intent(out) variable and this varibale is not set, gfortran only writes: warning: unused variable C Expected: Default warning like ifort/NAG f95/g95: In file ff.f90:7 subroutine sub(a) 1 Warning (158): INTENT(OUT) variable 'a' at (1) is never set --- Warning: ff.f90, line 11: INTENT(OUT) dummy argument A never set --- fortcom: Warning: ff.f90, line 7: A dummy argument with an explicit INTENT(OUT) declaration is not given an explicit value. [A] subroutine sub(a) ---^ Test program: - program test implicit none real :: a call sub(a) end program test subroutine sub(a) implicit none real, intent(out) :: a print *,a end subroutine sub - If you want, you can also -Wall warn that 'a' is used before it has gotten any value assiged. (And Fortran does not guarantee for intent(out) that the variable is set, even if I had add an a = 4.0 before the call sub(a).) Actually, none of the other compilers detects this at compile time, at run time NAG f95 (-nan or -C=undefined) does. -- Summary: Warn if intent(out) dummy variable is not set Product: gcc Version: unknown Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tobias dot burnus at physik dot fu-berlin dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28004
[Bug tree-optimization/27882] [4.2 regression] segfault in ipa-inline.c, if (e->callee->local.disregard_inline_limits
--- Comment #20 from tbm at cyrius dot com 2006-06-12 20:18 ---
Finally, a *small* test case.
5336:[EMAIL PROTECTED]: ~/tmp/delta/bin] /usr/local/bin/gcc -c -O1 --param
ggc-min-expand=0 --param ggc-min-heapsize=0 mini.c
mini.c:27: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
5337:[EMAIL PROTECTED]: ~/tmp/delta/bin] /usr/local/bin/gcc -c --param
ggc-min-expand=0
--param ggc-min-heapsize=0 mini.c
5338:[EMAIL PROTECTED]: ~/tmp/delta/bin] cat mini.c
struct sk_buff
{
}
raw_hdlc_proto;
struct tipc_msg *buf_msg (struct sk_buff *skb)
{
}
void buf_discard (struct sk_buff *skb)
{
}
void tipc_net_route_msg (struct sk_buff *buf);
static inline __attribute__ ((always_inline))
tipc_port_recv_msg (struct sk_buff *buf)
{
{
tipc_net_route_msg (buf);
}
}
void
tipc_net_route_msg (struct sk_buff *buf)
{
{
{
tipc_port_recv_msg (buf);
}
}
}
5339:[EMAIL PROTECTED]: ~/tmp/delta/bin]
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27882
[Bug c++/27951] [4.0/4.1/4.2 regression] ICE with invalid anonymous union
--- Comment #2 from reichelt at gcc dot gnu dot org 2006-06-12 20:51 --- Subject: Bug 27951 Author: reichelt Date: Mon Jun 12 20:50:53 2006 New Revision: 114577 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114577 Log: PR c++/27951 * decl2.c (finish_anon_union): Return early if build_anon_union_vars fails. * g++.dg/other/anon4.C: New test. Added: trunk/gcc/testsuite/g++.dg/other/anon4.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl2.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27951
[Bug c++/27951] [4.0/4.1/4.2 regression] ICE with invalid anonymous union
--- Comment #3 from reichelt at gcc dot gnu dot org 2006-06-12 20:55 --- Subject: Bug 27951 Author: reichelt Date: Mon Jun 12 20:55:42 2006 New Revision: 114578 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114578 Log: PR c++/27951 * decl2.c (finish_anon_union): Return early if build_anon_union_vars fails. * g++.dg/other/anon4.C: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/g++.dg/other/anon4.C Modified: branches/gcc-4_1-branch/gcc/cp/ChangeLog branches/gcc-4_1-branch/gcc/cp/decl2.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27951
[Bug c++/27951] [4.0/4.1/4.2 regression] ICE with invalid anonymous union
--- Comment #4 from reichelt at gcc dot gnu dot org 2006-06-12 21:00 --- Subject: Bug 27951 Author: reichelt Date: Mon Jun 12 21:00:31 2006 New Revision: 114579 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114579 Log: PR c++/27951 * decl2.c (finish_anon_union): Return early if build_anon_union_vars fails. * g++.dg/other/anon4.C: New test. Added: branches/gcc-4_0-branch/gcc/testsuite/g++.dg/other/anon4.C Modified: branches/gcc-4_0-branch/gcc/cp/ChangeLog branches/gcc-4_0-branch/gcc/cp/decl2.c branches/gcc-4_0-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27951
[Bug c++/27951] [4.0/4.1/4.2 regression] ICE with invalid anonymous union
--- Comment #5 from reichelt at gcc dot gnu dot org 2006-06-12 21:03 --- Fixed on mainline, 4.1 branch, and 4.0 branch. -- reichelt at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27951
[Bug libgomp/26165] Cannot find libgomp.spec after 'make install' on x86_64 and ppc64
--- Comment #7 from dnovillo at gcc dot gnu dot org 2006-06-12 21:10 --- This is still an issue. http://gcc.gnu.org/ml/fortran/2006-06/msg00178.html -- dnovillo at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|WORKSFORME | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26165
[Bug c++/27933] [4.0/4.1/4.2 Regression] ICE with invalid "using"
--- Comment #2 from reichelt at gcc dot gnu dot org 2006-06-12 21:13 --- Subject: Bug 27933 Author: reichelt Date: Mon Jun 12 21:12:52 2006 New Revision: 114580 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114580 Log: PR c++/27933 * name-lookup.c (lookup_qualified_name): Always return error_mark_node if lookup fails. * g++.dg/lookup/using15.C: New test. Added: trunk/gcc/testsuite/g++.dg/lookup/using15.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/name-lookup.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27933
Re: [Bug libgomp/26165] Cannot find libgomp.spec after 'make install' on x86_64 and ppc64
> > > > --- Comment #7 from dnovillo at gcc dot gnu dot org 2006-06-12 21:10 > --- > > This is still an issue. http://gcc.gnu.org/ml/fortran/2006-06/msg00178.html I think this is only an issue when you have a normal multi lib x86_64 but use --disable-multilib. -- Pinski
[Bug libgomp/26165] Cannot find libgomp.spec after 'make install' on x86_64 and ppc64
--- Comment #8 from pinskia at physics dot uc dot edu 2006-06-12 21:18 --- Subject: Re: Cannot find libgomp.spec after 'make install' on x86_64 and ppc64 > > > > --- Comment #7 from dnovillo at gcc dot gnu dot org 2006-06-12 21:10 > --- > > This is still an issue. http://gcc.gnu.org/ml/fortran/2006-06/msg00178.html I think this is only an issue when you have a normal multi lib x86_64 but use --disable-multilib. -- Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26165
[Bug c++/27933] [4.0/4.1/4.2 Regression] ICE with invalid "using"
--- Comment #3 from reichelt at gcc dot gnu dot org 2006-06-12 21:18 --- Subject: Bug 27933 Author: reichelt Date: Mon Jun 12 21:18:20 2006 New Revision: 114581 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114581 Log: PR c++/27933 * name-lookup.c (lookup_qualified_name): Always return error_mark_node if lookup fails. * g++.dg/lookup/using15.C: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/g++.dg/lookup/using15.C Modified: branches/gcc-4_1-branch/gcc/cp/ChangeLog branches/gcc-4_1-branch/gcc/cp/name-lookup.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27933
[Bug c++/27933] [4.0/4.1/4.2 Regression] ICE with invalid "using"
--- Comment #4 from reichelt at gcc dot gnu dot org 2006-06-12 21:23 --- Subject: Bug 27933 Author: reichelt Date: Mon Jun 12 21:23:30 2006 New Revision: 114582 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114582 Log: PR c++/27933 * name-lookup.c (lookup_qualified_name): Always return error_mark_node if lookup fails. * g++.dg/lookup/using15.C: New test. Added: branches/gcc-4_0-branch/gcc/testsuite/g++.dg/lookup/using15.C Modified: branches/gcc-4_0-branch/gcc/cp/ChangeLog branches/gcc-4_0-branch/gcc/cp/name-lookup.c branches/gcc-4_0-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27933
[Bug c++/27933] [4.0/4.1/4.2 Regression] ICE with invalid "using"
--- Comment #5 from reichelt at gcc dot gnu dot org 2006-06-12 21:24 --- Fixed on mainline, 4.1 branch, and 4.0 branch. -- reichelt at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27933
[Bug fortran/28005] New: gfortran: mathmul produces wrong result
From http://groups.google.com/group/comp.lang.fortran/browse_frm/thread/cf9a1ed1754c6f4a/ed236efb2be07bc0?tvc=1#ed236efb2be07bc0 The program -- program tmatmul implicit none integer, parameter :: nmax = 3 integer:: n = 2 real, dimension(nmax,nmax) :: B=0.0, C=1.0, X=0.0 B(1,1) = 1.0 B(1,2) = 2.0 B(2,1) = 3.0 B(2,2) = 5.0 X(1:n,1) = matmul( B(2,1:n),C(1:n,1:n) ) print *, X(:,1) print *, " Should be: 8.0 8.0 0.0" end program tmatmul -- produces with gfortran (4.2.0 20060612 and 4.1.0 (SUSE Linux)): 3.00 3.00 0.00 Should be: 8.0 8.0 0.0 ifort, g95 and NAG f95 give the correct result (8. 8. 0.0). -- Summary: gfortran: mathmul produces wrong result Product: gcc Version: unknown Status: UNCONFIRMED Severity: major Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tobias dot burnus at physik dot fu-berlin dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28005
[Bug target/27421] [4.0/4.1 regression] ICE with invalid array in struct
--- Comment #16 from reichelt at gcc dot gnu dot org 2006-06-12 21:34 --- Subject: Bug 27421 Author: reichelt Date: Mon Jun 12 21:34:32 2006 New Revision: 114583 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114583 Log: PR target/27421 * config/i386/i386.c (classify_argument): Skip fields with invalid types in unions. * gcc.dg/union-3.c: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/union-3.c Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/config/i386/i386.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27421
[Bug target/27421] [4.0/4.1 regression] ICE with invalid array in struct
--- Comment #17 from reichelt at gcc dot gnu dot org 2006-06-12 21:39 --- Subject: Bug 27421 Author: reichelt Date: Mon Jun 12 21:39:10 2006 New Revision: 114584 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114584 Log: PR target/27421 * config/i386/i386.c (classify_argument): Skip fields with invalid types in unions. * gcc.dg/union-3.c: New test. Added: branches/gcc-4_0-branch/gcc/testsuite/gcc.dg/union-3.c Modified: branches/gcc-4_0-branch/gcc/ChangeLog branches/gcc-4_0-branch/gcc/config/i386/i386.c branches/gcc-4_0-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27421
[Bug target/27421] [4.0/4.1/4.2 regression] ICE with invalid array in struct
--- Comment #18 from reichelt at gcc dot gnu dot org 2006-06-12 21:40 --- Now also fixed for unions (mainline, 4.1 branch, and 4.0 branch). -- reichelt at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Summary|[4.0/4.1 regression] ICE|[4.0/4.1/4.2 regression] ICE |with invalid array in struct|with invalid array in struct http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27421
[Bug fortran/27980] Wrong allocation for zero-sized function result
--- Comment #1 from tkoenig at gcc dot gnu dot org 2006-06-12 21:57 --- Created an attachment (id=11657) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11657&action=view) patch Here's a patch (regression-tested). I'm not 100% sure this is the most elegant method, though. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27980
[Bug fortran/28006] New: Negative-sized array should be empty array, not try to allocate negative memory
Based on http://groups.google.com/group/comp.lang.fortran/browse_frm/thread/c46c14d9d8879bad/14517cbe22d222bc#14517cbe22d222bc If one uses an array with a upper bound lower than the lower bound, the array contains zero items. However, gfortran tries to allocate negative MEMORY when one uses this. Example: - program xint_func print *, 'intfunc', -1, int_func(-3) contains function int_func(n) result(ivec) integer, intent(in) :: n integer :: ivec(n) integer :: i forall (i=1:n) ivec(i) = i end function int_func end program xint_func - This produces in gfortran: Fortran runtime error: Attempt to allocate a negative amount of memory. intfunc -1 Tested with 4.2.0 20060612 (experimental) and 4.1.0 (SUSE Linux). -- Summary: Negative-sized array should be empty array, not try to allocate negative memory Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tobias dot burnus at physik dot fu-berlin dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28006
[Bug libstdc++/27878] GCC 4.1.1 build fails on mips-sgi-irix6.5 (libstdc++)/GCC 4.1.0 worked.
--- Comment #14 from pcarlini at suse dot de 2006-06-12 22:40 --- Ok, thanks for your feedback. Indeed, the only possible "cause" of the problem are the finer grained checks for wchar_t vs C99 wchar_t proper functions which are now carried out after my 2006-05-03 commit (which fixed regressions on solaris and hpux). In fact, looking at the 20060428 log what was happening before the patch is that ac_c99_wchar was "no" and then wchar_t ended up being *completely disabled*. Currently, instead, the autoconf tests try to enable wchar_t support (all the configure tests pass) but then something very misteriously fails at build time. All in all, waiting for someone to kick-in and shed some light about MIPS vs MIPS64 and all that, you can certainly force by hand the old (4.1.0) behavior by passing explicitely --disable-wchar_t at build time. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27878
[Bug c++/27601] [4.0/4.1/4.2 Regression] ICE (in fold_offsetof_1, at c-common.c:5998) on strange offsetof
--- Comment #14 from reichelt at gcc dot gnu dot org 2006-06-12 22:56 --- Subject: Bug 27601 Author: reichelt Date: Mon Jun 12 22:56:07 2006 New Revision: 114588 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114588 Log: PR c++/27601 * semantics.c (finish_offsetof): Handle pseudo-destructors. * g++.dg/ext/offsetof1.C: Add test for pseudo-destructors. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/semantics.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/ext/offsetof1.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27601
[Bug fortran/28006] Negative-sized array should be empty array, not try to allocate negative memory
--- Comment #1 from kargl at gcc dot gnu dot org 2006-06-12 22:56 --- *** This bug has been marked as a duplicate of 27980 *** -- kargl at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28006
[Bug fortran/27980] Wrong allocation for zero-sized function result
--- Comment #2 from kargl at gcc dot gnu dot org 2006-06-12 22:56 --- *** Bug 28006 has been marked as a duplicate of this bug. *** -- kargl at gcc dot gnu dot org changed: What|Removed |Added CC||tobias dot burnus at physik ||dot fu-berlin dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27980
[Bug c++/27601] [4.0/4.1/4.2 Regression] ICE (in fold_offsetof_1, at c-common.c:5998) on strange offsetof
--- Comment #15 from reichelt at gcc dot gnu dot org 2006-06-12 23:00 --- Subject: Bug 27601 Author: reichelt Date: Mon Jun 12 23:00:00 2006 New Revision: 114589 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114589 Log: PR c++/27601 * semantics.c (finish_offsetof): Handle pseudo-destructors. * g++.dg/ext/offsetof1.C: Add test for pseudo-destructors. Modified: branches/gcc-4_1-branch/gcc/cp/ChangeLog branches/gcc-4_1-branch/gcc/cp/semantics.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog branches/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/offsetof1.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27601
[Bug c++/27601] [4.0/4.1/4.2 Regression] ICE (in fold_offsetof_1, at c-common.c:5998) on strange offsetof
--- Comment #16 from reichelt at gcc dot gnu dot org 2006-06-12 23:03 --- Subject: Bug 27601 Author: reichelt Date: Mon Jun 12 23:03:36 2006 New Revision: 114590 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114590 Log: PR c++/27601 * semantics.c (finish_offsetof): Handle pseudo-destructors. * g++.dg/ext/offsetof1.C: Add test for pseudo-destructors. Modified: branches/gcc-4_0-branch/gcc/cp/ChangeLog branches/gcc-4_0-branch/gcc/cp/semantics.c branches/gcc-4_0-branch/gcc/testsuite/ChangeLog branches/gcc-4_0-branch/gcc/testsuite/g++.dg/ext/offsetof1.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27601
[Bug fortran/27954] ICE on garbage in DATA statement
--- Comment #5 from sgk at troutmask dot apl dot washington dot edu 2006-06-12 23:04 --- Subject: Re: ICE on garbage in DATA statement On Mon, Jun 12, 2006 at 03:32:15PM -, reichelt at gcc dot gnu dot org wrote: >- Comment #4 from reichelt at gcc dot gnu dot org 2006-06-12 15:32 --- > Maybe it's target dependent? I'm guessing this is the case. > Are you using --enable-checking? I had not checking on i386-*-freebsd and this morning I rebuilt with --enable-checking on amd64-*-freebsd. I do not see the Internal Compiler Error. troutmask:sgk[203] gfc4x -v Using built-in specs. Target: amd64-unknown-freebsd7.0 Configured with: ../gcc4x/configure --prefix=/home/sgk/work/4x --enable-languages=c,fortran --enable-checking Thread model: posix gcc version 4.2.0 20060612 (experimental) troutmask:sgk[204] gfc4x -c l.f90 In file l.f90:3 character*20 X 0 1 Error: Syntax error in data declaration at (1) In file l.f90:4 data X /'A'/0 1 Error: Syntax error in DATA statement at (1) In file l.f90:4 data X /'A'/0 1 Error: Incompatible types in assignment at (1), CHARACTER(1) to REAL(4) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27954
[Bug c++/27601] [4.0/4.1/4.2 Regression] ICE (in fold_offsetof_1, at c-common.c:5998) on strange offsetof
--- Comment #17 from reichelt at gcc dot gnu dot org 2006-06-12 23:07 --- Now the ICE with pseudo-destructors described in http://gcc.gnu.org/ml/gcc-patches/2006-06/msg00677.html is also fixed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27601
[Bug c/28007] New: sse autovectorizer emits wrong code involving shifts
Here is a simple example which shows the bug when compiled with
-arch i386 -O2 -msse3 -funroll-loops -ftree-vectorize -msse3-ftree-vectorize
and -funroll-loops
#include
#include
int main (int, char * const)
{
const int count = 5;
uint32_t x[count];
for (int i = 0; i < count; ++i)
x[i] = 1;
for (int i = 0; i < count; ++i)
x[i] = x[i] << 24;
for (int i = 0; i < count; ++i)
std::printf("%x ", x[i]);
return 0;
}
The compiler is vectorizing the shifts in the loop, but it's generating the
wrong shift constant. It's putting the shift value (24) into each element of
the __v4si vector instead of setting the __m128 value to 24. These means that
each element is shifted by 8208 instead of 24 and the result is 0.
<+0029> movdqa 8208,%xmm0
<+0037> movdqa (%eax),%xmm1
<+0041> pslld %xmm0,%xmm1
--
Summary: sse autovectorizer emits wrong code involving shifts
Product: gcc
Version: 4.0.1
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: elronayellin at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28007
[Bug libstdc++/27878] GCC 4.1.1 build fails on mips-sgi-irix6.5 (libstdc++)/GCC 4.1.0 worked.
--- Comment #15 from pcarlini at suse dot de 2006-06-12 23:22 --- Not waiting anymore, but not confirmed either: we badly need an independent confirmation. -- pcarlini at suse dot de changed: What|Removed |Added Status|WAITING |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-06-12 23:22:47 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27878
[Bug libstdc++/26970] -O3 -Wformat=2 complains about floats written to ostream
--- Comment #8 from paolo at gcc dot gnu dot org 2006-06-12 23:24 --- Subject: Bug 26970 Author: paolo Date: Mon Jun 12 23:24:22 2006 New Revision: 114591 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114591 Log: 2006-06-12 Paolo Carlini <[EMAIL PROTECTED]> PR libstdc++/26970 * config/locale/gnu/c_locale.h (__convert_from_v<>): Change to variadic function, instead of template function. * config/locale/generic/c_locale.h (__convert_from_v<>): Likewise. * include/bits/locale_facets.tcc (num_put<>::_M_insert_float): Adjust. (money_put<>::do_put(long double)): Likewise. * src/locale-misc-inst.cc: Remove. * src/Makefile.am: Adjust. * src/Makefile.in: Regenerate. Removed: trunk/libstdc++-v3/src/locale-misc-inst.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/config/locale/generic/c_locale.h trunk/libstdc++-v3/config/locale/gnu/c_locale.h trunk/libstdc++-v3/include/bits/locale_facets.tcc trunk/libstdc++-v3/src/Makefile.am trunk/libstdc++-v3/src/Makefile.in -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26970
[Bug target/28007] sse autovectorizer emits wrong code involving shifts
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-06-12 23:24 --- -arch i386 Hmm, you are using Apple's compiler and you really should report this to Apple first. It might actually be fixed in the FSF GCC already (maybe it was never broken here either). -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|critical|normal Component|c |target GCC target triplet||i?86-*-linux-gnu Keywords||wrong-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28007
[Bug libstdc++/26970] -O3 -Wformat=2 complains about floats written to ostream
--- Comment #9 from pcarlini at suse dot de 2006-06-12 23:25 --- Fixed. -- pcarlini at suse dot de changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26970
[Bug fortran/27954] ICE on garbage in DATA statement
--- Comment #6 from reichelt at gcc dot gnu dot org 2006-06-12 23:26 --- I can reproduce the bug also on i686-pc-linux-gnu. Does freebsd vs. linux really matter that much here? Or could GMP or MPFR be the culprit? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27954
[Bug c++/27601] [4.0/4.1/4.2 Regression] ICE (in fold_offsetof_1, at c-common.c:5998) on strange offsetof
--- Comment #18 from patchapp at dberlin dot org 2006-06-13 00:10 --- Subject: Bug number PR c++/27601 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-06/msg00677.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27601
[Bug fortran/27954] ICE on garbage in DATA statement
--- Comment #7 from sgk at troutmask dot apl dot washington dot edu 2006-06-13 00:35 --- Subject: Re: ICE on garbage in DATA statement On Mon, Jun 12, 2006 at 11:26:16PM -, reichelt at gcc dot gnu dot org wrote: > > I can reproduce the bug also on i686-pc-linux-gnu. > Does freebsd vs. linux really matter that much here? > Or could GMP or MPFR be the culprit? > I doubt it is gmp or mpfr. There is nothing in the program that uses either library. Can you run the executable under valgrind? The difference may be in the memory allocators, which do differ between linux and freebsd. Yep. That's the problem. troutmask:sgk[211] setenv MALLOC_OPTIONS AJ troutmask:sgk[213] troutmask:sgk[213] gfc4x -c l.f90 In file l.f90:3 character*20 X 0 1 Error: Syntax error in data declaration at (1) In file l.f90:4 data X /'A'/0 1 Error: Syntax error in DATA statement at (1) l.f90:0: internal compiler error: Bus error: 10 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27954
[Bug fortran/27954] ICE on garbage in DATA statement
--- Comment #8 from sgk at troutmask dot apl dot washington dot edu 2006-06-13 00:56 --- Subject: Re: ICE on garbage in DATA statement On Mon, Jun 12, 2006 at 05:34:52PM -0700, Steve Kargl wrote: > On Mon, Jun 12, 2006 at 11:26:16PM -, reichelt at gcc dot gnu dot org > wrote: > > > > I can reproduce the bug also on i686-pc-linux-gnu. > > Does freebsd vs. linux really matter that much here? > > Or could GMP or MPFR be the culprit? > > > > I doubt it is gmp or mpfr. There is nothing in > the program that uses either library. Can you > run the executable under valgrind? The difference > may be in the memory allocators, which do differ > between linux and freebsd. > > Yep. That's the problem. > > troutmask:sgk[211] setenv MALLOC_OPTIONS AJ > troutmask:sgk[213] > troutmask:sgk[213] gfc4x -c l.f90 > In file l.f90:3 > > character*20 X 0 >1 > Error: Syntax error in data declaration at (1) > In file l.f90:4 > > data X /'A'/0 > 1 > Error: Syntax error in DATA statement at (1) > l.f90:0: internal compiler error: Bus error: 10 > Please submit a full bug report, > with preprocessed source if appropriate. > See http://gcc.gnu.org/bugs.html> for instructions. > Program received signal SIGBUS, Bus error. 0x004458c3 in gfc_resolve_expr (e=0x201520240) at ../../gcc4x/gcc/fortran/resolve.c:2793 2793 if (sym->attr.flavor == FL_PROCEDURE && !sym->attr.function) (gdb) bt #0 0x004458c3 in gfc_resolve_expr (e=0x201520240) at ../../gcc4x/gcc/fortran/resolve.c:2793 #1 0x00447413 in resolve_data_variables (d=0x2014212c0) at ../../gcc4x/gcc/fortran/resolve.c:5867 #2 0x00447671 in resolve_types (ns=0x2014a2000) at ../../gcc4x/gcc/fortran/resolve.c:5896 #3 0x00449cbd in gfc_resolve (ns=0x2014a2000) at ../../gcc4x/gcc/fortran/resolve.c:6558 #4 0x0043f958 in gfc_parse_file () at ../../gcc4x/gcc/fortran/parse.c:3190 #5 0x0045e90e in gfc_be_parse_file (set_yydebug=Variable "set_yydebug" is not available. ) at ../../gcc4x/gcc/fortran/f95-lang.c:303 #6 0x0074595e in toplev_main (argc=Variable "argc" is not available. ) at ../../gcc4x/gcc/toplev.c:999 -- Steve -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27954
[Bug libgomp/28008] New: [4.2 Regression] build failure due to PTHREAD_STACK_MIN not being declared
From http://gcc.gnu.org/ml/gcc-patches/2006-06/msg00595.html /work/rearnsha/gnu/gcc/trunk/./gcc/xgcc -B/work/rearnsha/gnu/gcc/trunk/./gcc/ -B/work/rearnsha/gnu/testinstall/arm-netbsdelf2/bin/ -B/work/rearnsha/gnu/testinstall/arm-netbsdelf2/lib/ -isystem /work/rearnsha/gnu/testinstall/arm-netbsdelf2/include -isystem /work/rearnsha/gnu/testinstall/arm-netbsdelf2/sys-include -DHAVE_CONFIG_H -I. -I/home/rearnsha/gnusrc/gcc/trunk/libgomp -I. -I/home/rearnsha/gnusrc/gcc/trunk/libgomp/config/posix -I/home/rearnsha/gnusrc/gcc/trunk/libgomp -Wall -pthread -Werror -O2 -g -O2 -MT env.lo -MD -MP -MF .deps/env.Tpo -c /home/rearnsha/gnusrc/gcc/trunk/libgomp/env.c -fPIC -DPIC -o .libs/env.o /home/rearnsha/gnusrc/gcc/trunk/libgomp/env.c: In function 'initialize_env': /home/rearnsha/gnusrc/gcc/trunk/libgomp/env.c:172: error: 'PTHREAD_STACK_MIN' undeclared (first use in this function) IIRC libjava had the same problem at one point, so presumably the same fix will apply here. -- Summary: [4.2 Regression] build failure due to PTHREAD_STACK_MIN not being declared Product: gcc Version: 4.2.0 Status: UNCONFIRMED Keywords: build Severity: blocker Priority: P3 Component: libgomp AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pinskia at gcc dot gnu dot org GCC target triplet: arm-netbsdelf http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28008
[Bug libgomp/28008] [4.2 Regression] build failure due to PTHREAD_STACK_MIN not being declared
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-06-13 01:57 --- Also read http://gcc.gnu.org/ml/gcc-patches/2006-06/msg00494.html Where I mentioned this should not have been applied. -- 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-06-13 01:57:16 date|| Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28008
[Bug ada/27944] [4.2 Regression] s-taprop.adb:66:06: warning: redundant with clause in body
--- Comment #3 from danglin at gcc dot gnu dot org 2006-06-13 02:09 --- Subject: Bug 27944 Author: danglin Date: Tue Jun 13 02:08:53 2006 New Revision: 114598 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114598 Log: PR ada/27944 * s-taprop-hpux-dce.adb: Delete redundant 'with System.Parameters'. Modified: trunk/gcc/ada/ChangeLog trunk/gcc/ada/s-taprop-hpux-dce.adb -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27944
[Bug target/26792] [4.2 Regression] C++ is broken on *-*-darwin*
--- Comment #3 from howarth at nitro dot med dot uc dot edu 2006-06-13 02:10 --- It appears that on Macintel, simply unsetting MACOSX_DEPLOYMENT_TARGET is insufficient to eliminate the undefined symbols for _Unwind_GETIPInfo when building gcj. This doesn't happen on ppc Darwin. Currently the fink developers have decided to leave MACOSX_DEPLOYMENT_TARGET set to 10.4 and use the http://gcc.gnu.org/ml/gcc-patches/2006-02/msg02041.html patch. Would it be better for them to unset MACOSX_DEPLOYMENT_TARGET and use Jakub's recommendation of adding... #define _Unwind_GetIPInfo(ctx, ip) (*(ip) = 0, _Unwind_GetIP (ctx) to a darwin specific unwind.h? I am trying to get them from forking the libstdc++ in fink. Jack -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26792
[Bug ada/27944] [4.2 Regression] s-taprop.adb:66:06: warning: redundant with clause in body
--- Comment #4 from danglin at gcc dot gnu dot org 2006-06-13 02:14 --- Fixed by patch on trunk. -- danglin at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27944
[Bug target/28007] sse autovectorizer emits wrong code involving shifts
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-06-13 03:15 --- This is correct on the FSF GCC. In 4.0.x, we don't vectorize the loop and in 4.1.x, we produce: pslld $24, %xmm1 So please report this bug to Apple. -- 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=28007
[Bug target/28007] sse autovectorizer emits wrong code involving shifts
--- Comment #3 from steven at gcc dot gnu dot org 2006-06-13 04:22 --- Could it be an issue on the autovect branch? -- steven at gcc dot gnu dot org changed: What|Removed |Added CC||dorit at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28007
[Bug target/28007] sse autovectorizer emits wrong code involving shifts
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-06-13 04:24 --- (In reply to comment #3) > Could it be an issue on the autovect branch? No because we do vectorize the look in 4.1.0 correctly. Witness pslld $24, %xmm1 This was most likely at one point a problem on the autovec branch but it was fixed by the time it was merged into 4.1.0 for this case. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28007
[Bug tree-optimization/28003] [4.2 Regression] optimizer bug
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-06-13 04:41 ---
Hmm, we get after dce, just:
reduced_cell_two_folds[26] = {};
And DCE removes:
this_616 = &reduced_cell_two_folds[26].u;
# SMT.68_1055 = V_MAY_DEF ;
this_616->elems[0] = 1;
# SMT.68_1056 = V_MAY_DEF ;
this_616->elems[1] = 0;
# SMT.68_1057 = V_MAY_DEF ;
this_616->elems[2] = 0;
...
this_621 = &reduced_cell_two_folds[26].h;
...
# SMT.68_1058 = V_MAY_DEF ;
this_621->elems[0] = 2;
# SMT.68_1059 = V_MAY_DEF ;
this_621->elems[1] = 1;
# SMT.68_1060 = V_MAY_DEF ;
this_621->elems[2] = 1;
Which does not make sense. Nothing is special in alias shows what is going
wrong.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
||org
Severity|normal |critical
Component|c++ |tree-optimization
Keywords||alias, wrong-code
Summary|optimizer bug |[4.2 Regression] optimizer
||bug
Target Milestone|--- |4.2.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28003
[Bug fortran/27715] [4.1 only] Extented ASCII characters lead to wrong "CASE" selection
--- Comment #14 from fxcoudert at gcc dot gnu dot org 2006-06-13 06:26 --- Thomas, could you backport your patch to 4.1? (when you have some time, of course) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27715
