[Bug target/37581] IEEE inexact-flag not working on the Alpha
--- Comment #2 from ubizjak at gmail dot com 2009-01-23 08:47 ---
Works for me with:
--cut here--
#define _GNU_SOURCE
#include fenv.h
#include signal.h
#include stdlib.h
static void foo (int sig)
{
exit (0);
}
float __attribute__((noinline)) test (float x) { return 2.0f / x; };
int main()
{
volatile float x;
signal (SIGFPE, foo);
feclearexcept (FE_ALL_EXCEPT);
feenableexcept (FE_INEXACT);
x = test (3.0f);
abort ();
}
--cut here--
$ gcc -O2 -lm -mieee-with-inexact sf.c
$ ./a.out
$
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution||INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37581
[Bug tree-optimization/38943] New: Optimization removes trapping instruction
Following test:
--cut here--
#define _GNU_SOURCE
#include fenv.h
#include signal.h
#include stdlib.h
static void foo (int sig)
{
exit (0);
}
float __attribute__((noinline)) test (float x) { return 2.0f / x; };
int main()
{
signal (SIGFPE, foo);
feclearexcept (FE_ALL_EXCEPT);
feenableexcept (FE_INEXACT);
test (3.0f);
abort ();
}
--cut here--
aborts when compiled with optimizations, since the call to a procedure with a
trapping insn is removed.
$ gcc -O2 -fnon-call-exceptions -ftrapping-math -lm sf.c
$ ./a.out
Aborted
$ gcc -lm sf.c
$ ./a.out
$ [...works OK...]
A wild guess is to blame tree optimizers, since in 123t.optimized we already
have the call removed:
main ()
{
bb 2:
signal (8, foo);
feclearexcept (61);
feenableexcept (32);
abort ();
}
--
Summary: Optimization removes trapping instruction
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ubizjak at gmail dot com
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38943
[Bug tree-optimization/38943] Optimization removes trapping instruction
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-01-23 09:21 --- FENV access is not implemented. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added GCC target triplet|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38943
[Bug c/38942] possible integer codegen error
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-01-23 10:33 --- Seems to work for me. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38942
[Bug target/38384] shared link/execute fails for cross gcc from linux to target hppa64-hp-hpux11.00
--- Comment #46 from r dot emrich at de dot tecosim dot com 2009-01-23 10:45 --- Created an attachment (id=17164) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17164action=view) Verbose output of static link step As you can see for all libraries except libdld archives are used. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38384
[Bug target/38384] shared link/execute fails for cross gcc from linux to target hppa64-hp-hpux11.00
--- Comment #47 from r dot emrich at de dot tecosim dot com 2009-01-23 10:50 --- Created an attachment (id=17165) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17165action=view) chatr output for the resulting object As you can see there is one dependency to libdl.1 what is ok AFAIK. There is no libdl archive. In the segment index there are two unknown segments. That is with cvs binutils as of yesterday. But I think it's the same with binutils-2.16.1. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38384
[Bug c/38944] New: internal compiler error: Segmentation faul
comiling common.c of conky-1.6.1
CFLAGS=-O2 -march=native -mtune=native -pipe -fomit-frame-pointer -ffast-math
i486-slackware-linux-gcc -DHAVE_CONFIG_H -I.
-DSYSTEM_CONFIG_FILE=\/etc/conky/c
onky.conf\-O2 -march=native -mtune=native -pipe -fomit-frame-pointer
-ffast
-math -pthread -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include
-I/usr/includ
e/gtk-2.0 -I/usr/include/pango-1.0 -I/usr/include/cairo
-I/usr/include/libmowgli
-I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -I/usr/lib/gtk-2.0/include
-I/usr/include/atk-1.0 -I/usr/include/freetype2 -I/usr/include/libpng12
-I/usr/i
nclude/pixman-1 -I/usr/include/libxml2 -I/usr/include/freetype2
-I
/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -Wall -W -MT common.o -MD
-M
P -MF .deps/common.Tpo -c -o common.o common.c
common.c: In function 'update_stuff':
common.c:399: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
make[2]: *** [common.o] Error 1
make[2]: Leaving directory `/tmp/SBo/conky-1.6.1/src'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/tmp/SBo/conky-1.6.1/src'
make: *** [all-recursive] Error 1
source :
/* Conky, a system monitor, based on torsmo
*
* Any original torsmo code is licensed under the BSD license
*
* All code written since the fork of torsmo is licensed under the GPL
*
* Please see COPYING for details
*
* Copyright (c) 2004, Hannu Saransaari and Lauri Hakkarainen
* Copyright (c) 2005-2008 Brenden Matthews, Philip Kovacs, et. al.
* (see AUTHORS)
* All rights reserved.
*
* This program is free software: you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation, either version 3 of the License, or
* (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
* You should have received a copy of the GNU General Public License
* along with this program. If not, see http://www.gnu.org/licenses/.
*
* $Id: common.c 1193 2008-06-21 20:37:58Z ngarofil $ */
#include conky.h
#include ctype.h
#include errno.h
#include sys/time.h
#include pthread.h
#ifndef HAVE_STRNDUP
// use our own strndup() if it's not available
char *strndup(const char *s, size_t n)
{
if (strlen(s) + 1 n) {
char *ret = malloc(n);
strncpy(ret, s, n);
return ret;
} else {
return strdup(s);
}
}
#endif /* HAVE_STRNDUP */
void update_uname(void)
{
uname(info.uname_s);
}
double get_time(void)
{
struct timeval tv;
gettimeofday(tv, 0);
return tv.tv_sec + (tv.tv_usec / 100.0);
}
FILE *open_file(const char *file, int *reported)
{
FILE *fp = fopen(file, r);
if (!fp) {
if (!reported || *reported == 0) {
ERR(can't open %s: %s, file, strerror(errno));
if (reported) {
*reported = 1;
}
}
return 0;
}
return fp;
}
void variable_substitute(const char *s, char *dest, unsigned int n)
{
while (*s n 1) {
if (*s == '$') {
s++;
if (*s != '$') {
char buf[256];
const char *a, *var;
unsigned int len;
/* variable is either $foo or ${foo} */
if (*s == '{') {
s++;
a = s;
while (*s *s != '}') {
s++;
}
} else {
a = s;
while (*s (isalnum((int) *s) || *s
== '_')) {
s++;
}
}
/* copy variable to buffer and look it up */
len = (s - a 255) ? 255 : (s - a);
strncpy(buf, a, len);
buf[len] = '\0';
if (*s == '}') {
s++;
}
var = getenv(buf);
if (var) {
/* add var to dest */
len =
[Bug other/38783] [Regression] - The triplet i386-pc-solaris2.11 is ambiguous
--- Comment #3 from rob1weld at aol dot com 2009-01-23 12:25 --- From: Ben Elliston b...@air.net.au To: rob1w...@aol.com Sent: Thu, 22 Jan 2009 8:12 pm Subject: Re: Patch for config.guess Hi Rob, Thanks for your report. The script config.guess lumps together many of Sun's Operating Systems into one identifier. To save attempting to parse all the names of the various versions it is easier to rely on the Kernel version number. This is discussed here: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38783 I read the bug report. Solaris is no different to other operating systems that we have detected in config.guess for many years. We have traditionally tried to strike a balance between providing enough information for GNU packages that care (ie. GCC) and providing too much information (such as the specific build number of the kernel). If there are specific kernel problems that you are trying to work around, it is usually more reliable to have a configure test that switches on the config.guess triplet and then actually detects the presence of the problem. Cheers, Ben Thanks for considering my request and reading my Bug Report over at gcc's Bugzilla. ... tried to strike a balance between providing enough information for GNU packages that care (ie. GCC) and providing too much information ... Agreed. It would not have been great to make the Identifier larger and it would certainly not have been pretty, but there is a lot of overlap between different OSes. Since My Operating System is correctly reported (or you could file a Bug Report) I have nothing to worry about. The people who program gcc (and other software) will simply have to figure out from the given Identifier which OS they are dealing with and know what to test for. Thanks, Rob -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38783
[Bug c/38945] New: No warning when using unset variable
The 4.x compilers does not warn when using unset variables.
The 3.x compilers did warn on this:
Example:
int use_unset_variable(int y)
{
int x;
switch(y) {
case 0:
x = 0;
break;
default:
break;
}
x++;
return x;
}
Variable x could be unset when returning.
I use all warnings possible:
-Wall -W -Wextra
Best Regards
Fredrik
--
Summary: No warning when using unset variable
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: fredrik at hederstierna dot com
GCC build triplet: arm-elf-gcc
GCC host triplet: x86-intel
GCC target triplet: arm-elf-gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38945
[Bug fortran/38946] New: gcc trunk 143562 - Testsuite - gfortran failing tests that worked previously
I built gcc and submitted a Test Report here:
http://gcc.gnu.org/ml/gcc-testresults/2009-01/msg02341.html
http://gcc.gnu.org/ml/gcc-testresults/2009-01/msg02197.html
...
=== gfortran tests ===
FAIL: gfortran.dg/array_constructor_23.f -O3 -fomit-frame-pointer execution
test
FAIL: gfortran.dg/array_constructor_23.f -O3 -fomit-frame-pointer
-funroll-loops execution test
FAIL: gfortran.dg/array_constructor_23.f -O3 -fomit-frame-pointer
-funroll-all-loops -finline-functions execution test
FAIL: gfortran.dg/array_constructor_23.f -O3 -g execution test
...
When I view the log I see this (dupe blank lines removed):
Executing on host:
/usr/share/src/gcc_build/gcc/testsuite/gfortran/../../gfortran
-B/usr/share/src/gcc_build/gcc/testsui$
/usr/share/src/gcc_trunk/gcc/testsuite/gfortran.dg/array_constructor_26.f03:13.26:
CHARACTER (MAX_FLD_HED, 1) :: DWFdHd(MAXFLD) = [( , i = 1, MAXFLD)]
1
Error: Symbol 'max_fld_hed' at (1) has no IMPLICIT type
/usr/share/src/gcc_trunk/gcc/testsuite/gfortran.dg/array_constructor_26.f03:13.15:
CHARACTER (MAX_FLD_HED, 1) :: DWFdHd(MAXFLD) = [( , i = 1, MAXFLD)]
1
Error: Character length of component 'dwfdhd' needs to be a constant
specification expression at (1)
compiler exited with status 1
/usr/share/src/gcc_trunk/gcc/testsuite/gfortran.dg/array_constructor_27.f03:11.14:
character (a) :: arr (1) = [ a ]
1
Error: Symbol 'a' at (1) has no IMPLICIT type
/usr/share/src/gcc_trunk/gcc/testsuite/gfortran.dg/array_constructor_27.f03:11.13:
character (a) :: arr (1) = [ a ]
1
Error: Character length of component 'arr' needs to be a constant specification
expression at (1)
/usr/share/src/gcc_trunk/gcc/testsuite/gfortran.dg/array_constructor_28.f03:8.35:
character (2) :: arr (2) = [ a, ab ] ! { dg-error Different CHARACTER }
1
Error: Different CHARACTER lengths (1/2) in array constructor at (1)
compiler exited with status 1
FAIL: gfortran.dg/default_format_denormal_2.f90 -Os execution test
Executing on host:
/usr/share/src/gcc_build/gcc/testsuite/gfortran/../../gfortran
-B/usr/share/src/gcc_build/gcc/testsui$
/usr/share/src/gcc_trunk/gcc/testsuite/gfortran.dg/default_initialization_1.f90:17.34:
type (default_initialization) t ! { dg-error default initialization }
1
Error: Object 't' at (1) must have the SAVE attribute for default
initialization of a component
compiler exited with status 1
Executing on host:
/usr/share/src/gcc_build/gcc/testsuite/gfortran/../../gfortran
-B/usr/share/src/gcc_build/gcc/testsui$
/usr/share/src/gcc_trunk/gcc/testsuite/gfortran.dg/defined_operators_1.f90:14.69:
module procedure foo_1_OK ! { dg-error Ambiguous interfaces }
1
Error: Ambiguous interfaces 'foo_1_ok' and 'foo_1' in operator interface 'foo'
at (1)
/usr/share/src/gcc_trunk/gcc/testsuite/gfortran.dg/defined_operators_1.f90:20.23:
subroutine bad_foo (chr) ! { dg-error must be a FUNCTION }
1
Error: User operator procedure 'bad_foo' at (1) must be a FUNCTION
...
There were far fewer errors here, these issues are a week old:
Results for 4.4.0 20090117 (experimental) [trunk revision 143454] (GCC)
testsuite on i386-pc-solaris2.11
http://gcc.gnu.org/ml/gcc-testresults/2009-01/msg01790.html
Thanks,
Rob
--
Summary: gcc trunk 143562 - Testsuite - gfortran failing tests
that worked previously
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rob1weld at aol dot com
GCC build triplet: i386-pc-solaris2.11
GCC host triplet: i386-pc-solaris2.11
GCC target triplet: i386-pc-solaris2.11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38946
[Bug tree-optimization/37021] Fortran Complex reduction / multiplication not vectorized
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-01-23 15:33 --- The testcase should be subroutine to_product_of(self,a,b,a1,a2) complex(kind=8) :: self (:) complex(kind=8), intent(in) :: a(:,:) complex(kind=8), intent(in) :: b(:) integer a1,a2 do i = 1,a1 do j = 1,a2 self(i) = self(i) + a(j,i)*b(j) end do end do end subroutine to be meaningful - otherwise we are accessing a in non-continuous ways in the inner loop which would prevent vectorization. With the versioning for stride == 1 I get then .L13: movupd 16(%rax), %xmm1 movupd (%rax), %xmm3 incl%ecx movupd (%rdx), %xmm4 addq$32, %rax movapd %xmm3, %xmm0 unpckhpd%xmm1, %xmm3 unpcklpd%xmm1, %xmm0 movupd 16(%rdx), %xmm1 movapd %xmm4, %xmm2 addq$32, %rdx movapd %xmm3, %xmm9 cmpl%ecx, %r8d unpcklpd%xmm1, %xmm2 unpckhpd%xmm1, %xmm4 movapd %xmm4, %xmm1 movapd %xmm2, %xmm4 mulpd %xmm1, %xmm9 mulpd %xmm0, %xmm4 mulpd %xmm3, %xmm2 mulpd %xmm1, %xmm0 subpd %xmm9, %xmm4 addpd %xmm2, %xmm0 addpd %xmm4, %xmm6 addpd %xmm0, %xmm5 ja .L13 haddpd %xmm5, %xmm5 cmpl%r15d, %edi movl-4(%rsp), %ecx haddpd %xmm6, %xmm6 addsd %xmm5, %xmm8 addsd %xmm6, %xmm7 jne .L12 jmp .L14 for the innermost loop, followed by a tail loop (peel for niters). This is about 15% faster on AMD K10 than the non-vectorized loop (if you disable the cost-model and make sure to have enough iterations in the inner loop to pay back for the extra guarding conditions). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37021
[Bug tree-optimization/37021] Fortran Complex reduction / multiplication not vectorized
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-01-23 15:36 --- So, 4) The vectorized version sucks because we have to use peeling for niters because we need to unroll the loop once and cannot apply SLP here. Q1: does SLP work with reductions at all? Q2: does SLP do pattern recognition? First of all we would need to recognize a complex reduction as a single vectorized reduction. Second we need to vectorize the complex multiplication with SLP, feeding the reduction with one resulting complex vector. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37021
[Bug middle-end/38932] [4.3/4.4 Regression] ICE in set_value_range, at tree-vrp.c:398
--- Comment #12 from bonzini at gnu dot org 2009-01-23 15:57 --- Subject: Bug 38932 Author: bonzini Date: Fri Jan 23 15:57:19 2009 New Revision: 143588 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143588 Log: 2008-01-23 Paolo Bonzini bonz...@gnu.org PR tree-optimization/38932 * fold-const.c (fold_unary_no_overflow): New. * tree.h (fold_unary_no_overflow): Declare. * tree-ssa-ccp.c (ccp_fold): Use fold_unary_no_overflow. * tree-ssa-sccvn.c (visit_reference_op_load, simplify_unary_expression): Likewise. testsuite: 2008-01-23 Paolo Bonzini bonz...@gnu.org PR tree-optimization/38932 * gcc.dg/pr38932.c: New. Added: trunk/gcc/testsuite/gcc.dg/pr38932.c Modified: trunk/gcc/ChangeLog trunk/gcc/fold-const.c trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-ccp.c trunk/gcc/tree-ssa-sccvn.c trunk/gcc/tree.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38932
[Bug target/38941] CX isn't preserved with shift
--- Comment #7 from vmakarov at redhat dot com 2009-01-23 15:58 --- If it is a problem, it is not a problem of IRA. The usage of the old RA results in the same abort. Neither the old RA, nor IRA assigns CX to pseudos. CX is started to be used by reload, so I think it is reload responsibility to save/restore CX if it is proved to be a problem. And implementing the save/restore will be not easy to do. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38941
[Bug middle-end/38932] [4.3 Regression] ICE in set_value_range, at tree-vrp.c:398
--- Comment #13 from rguenth at gcc dot gnu dot org 2009-01-23 16:18 --- Fixed on the trunk. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Known to fail|4.3.3 4.4.0 |4.3.3 Known to work|4.2.3 |4.2.3 4.4.0 Priority|P1 |P2 Summary|[4.3/4.4 Regression] ICE in |[4.3 Regression] ICE in |set_value_range, at tree- |set_value_range, at tree- |vrp.c:398 |vrp.c:398 Target Milestone|--- |4.3.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38932
[Bug c/38869] [4.4 Regression] valgrind find problem with -O -mtune=generic
--- Comment #10 from rguenth at gcc dot gnu dot org 2009-01-23 16:18 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38869
[Bug target/38824] [4.4 Regression] performance regression of sse code from 4.2/4.3
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Keywords||missed-optimization Summary|[4.4 regression] performance|[4.4 Regression] performance |regression of sse code from |regression of sse code from |4.2/4.3 |4.2/4.3 Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38824
[Bug c++/29883] i686-pc-cygwin/3.4.4 - internal compiler error: Segmentation fault
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-01-23 16:22 --- GCC 3.4.4 is no longer maintained. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29883
[Bug rtl-optimization/38740] [4.4 Regression] Incorrect delayed branch optimization
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38740
[Bug fortran/38947] New: openmp, fortran - request for extension allowing usage of equivalence statement for threadprivate data
Legacy f77 code often uses equivalence statements between array elements and common members extensively, e.g.: COMMON/GCPARM/IPARAM,PCUTGA,PCUTEL,PCUTNE,PCUTHA,PCUTMU + ,NSPARA,MPSTAK,NPGENE REAL PACUTS(5) EQUIVALENCE (PACUTS(1),PCUTGA) When parallelizing such code with OpenMP one would aspire to achieve this with the following pragma: !$omp threadprivate(/GCPARM/, PACUTS) OpenMP specification states that common members and variables with the threadprivate specifier must not be present in equivalence statements. The proposed extension would lift this restriction for cases when the equivalence is requested among variables that are all threadprivate within the same compilation unit. -- Summary: openmp, fortran - request for extension allowing usage of equivalence statement for threadprivate data Product: gcc Version: 4.3.2 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: matevz dot tadel at cern dot ch 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=38947
[Bug fortran/38471] [4.3/4.4 Regression] ICE with subreference pointer assignment
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38471
[Bug rtl-optimization/38948] New: unrecognizable insn, postreload.c:395
Noticed with gcc-4_3-branch revision 143533 and -march=v32 -O2 -fno-tree-sra.
The attached test-case (from ghostscript-5.50) goes:
/h/hp/gcc/cris/bugs/20090122/gs42.i: In function 'append_outline':
/h/hp/gcc/cris/bugs/20090122/gs42.i:1387: error: insn does not satisfy its
constraints:
(insn 1860 610 611 51 /h/hp/gcc/cris/bugs/20090122/gs42.i:1298 (set (reg:SI 16
srp [374])
(reg:SI 17 mof)) 38 {*movsi_internal} (nil))
/h/hp/gcc/cris/bugs/20090122/gs42.i:1387: internal compiler error: in
reload_cse_simplify_operands, at postreload.c:395
--
Summary: unrecognizable insn, postreload.c:395
Product: gcc
Version: 4.3.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hp at gcc dot gnu dot org
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: cris-*-* and crisv32-*-*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38948
[Bug rtl-optimization/38948] unrecognizable insn, postreload.c:395
-- hp at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-01-23 16:30:50 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38948
[Bug rtl-optimization/38948] unrecognizable insn, postreload.c:395
-- hp at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |hp at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2009-01-23 16:30:50 |2009-01-23 16:30:59 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38948
[Bug rtl-optimization/38948] unrecognizable insn, postreload.c:395
--- Comment #1 from hp at gcc dot gnu dot org 2009-01-23 16:33 --- Created an attachment (id=17166) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17166action=view) test-case Compile with -O2 -march=v32 -fno-tree-sra for cris-axis-elf (or crisv32-axis-elf). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38948
[Bug fortran/38471] [4.3/4.4 Regression] ICE with subreference pointer assignment
-- burnus at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.3.3 |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38471
[Bug middle-end/38503] [4.4 regression] warnings from -isystem headers strikes back.
--- Comment #12 from rguenth at gcc dot gnu dot org 2009-01-23 16:52
---
this is placement-new related.
D.20941_8 = ox
ox = { } no-tbaa-pruning
D.20941_8 = { ox }
alias warning for D.20941_8
After alias:
ox.D.20531.m_initialized = 0;
D.20941_8 = (struct X *) ox.D.20531.m_storage.dummy_.data[0];
D.20941_8-e_ = 0;
ox.D.20531.m_initialized = 1;
D.20946_10 = ox.D.20531.m_initialized;
Before:
ox.D.20531.m_initialized ={v} 0;
change_dynamic_type (struct X *) ox.D.20531.m_storage.dummy_.data[0])
D.20941_8 = (struct X *) ox.D.20531.m_storage.dummy_.data[0];
D.20941_8-e_ ={v} 0;
ox.D.20531.m_initialized ={v} 1;
D.20946_10 = ox.D.20531.m_initialized;
so it looks like we do placement new on _parts_ of an object that
continues to live over that placement new.
Uh oh. Is this even legal?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38503
[Bug c/38944] internal compiler error: Segmentation faul
--- Comment #1 from ubizjak at gmail dot com 2009-01-23 17:02 --- 1) The source as inlined in bugreport is useless, please see [1] for a detailed bug report instructions and _attach_ generated preprocessed source (unless it is a couple of tens of lines long...). 2) -march=native automatically sets -march and -mtune, depending on the processor the compiler is running on. Please paste full output, as generated with -v. 3) Try to compile with gcc-4.3 or gcc-4.4. gcc-4.2 will be EOL-d in a couple of weeks, and fixing 4.2 bugs is very low on developers priority lists. [1] http://gcc.gnu.org/bugs.html#detailed -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38944
[Bug rtl-optimization/38948] unrecognizable insn, postreload.c:395
--- Comment #2 from hp at gcc dot gnu dot org 2009-01-23 17:08 --- Created an attachment (id=17167) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17167action=view) Reduced test-case, suggested for gcc.dg/torture but untested in framework. Also -fstrict-aliasing (the default) is required to trig the bug. -- hp at gcc dot gnu dot org changed: What|Removed |Added Attachment #17166|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38948
[Bug target/38384] shared link/execute fails for cross gcc from linux to target hppa64-hp-hpux11.00
--- Comment #48 from dave at hiauly1 dot hia dot nrc dot ca 2009-01-23 17:41 --- Subject: Re: shared link/execute fails for cross gcc from linux to target hppa64-hp-hpux11.00 As you can see there is one dependency to libdl.1 what is ok AFAIK. There is no libdl archive. Yes, there are a number of libraries that don't have archive versions. I believe libdld needs the dynamic loader. Another library is librt. We try to handle this problem in the LIB_SPEC define. In the segment index there are two unknown segments. That is with cvs binutils as of yesterday. But I think it's the same with binutils-2.16.1. Advise using recent version. There are no recent fixes affecting GNU ld on hpux, but there have been some assembler fixes. I've seen the segment issue but don't have a fix. There's something going wrong in the core code. I think this is the main issue with shared libraries. I tried a full native build last night with GNU ld. It failed with a broken f951 compiler. The problem is pc-relative calls are broken (no stub, or incorrect offset to stub) when the call distance exceeds the maximum branch distance for the 22-bit pc-relative relocation. This should be relatively straightforward to fix. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38384
[Bug testsuite/38949] New: Link failures in new stackalign tests
I'm seeing all these test failures in regression runs on HEAD: FAIL: g++.dg/torture/stackalign/unwind-0.C (test for excess errors) WARNING: g++.dg/torture/stackalign/unwind-0.C compilation failed to produce executable FAIL: g++.dg/torture/stackalign/unwind-0.C (test for excess errors) WARNING: g++.dg/torture/stackalign/unwind-0.C compilation failed to produce executable FAIL: g++.dg/torture/stackalign/unwind-0.C (test for excess errors) WARNING: g++.dg/torture/stackalign/unwind-0.C compilation failed to produce executable FAIL: g++.dg/torture/stackalign/unwind-0.C (test for excess errors) WARNING: g++.dg/torture/stackalign/unwind-0.C compilation failed to produce executable FAIL: g++.dg/torture/stackalign/unwind-0.C (test for excess errors) WARNING: g++.dg/torture/stackalign/unwind-0.C compilation failed to produce executable FAIL: g++.dg/torture/stackalign/unwind-0.C (test for excess errors) WARNING: g++.dg/torture/stackalign/unwind-0.C compilation failed to produce executable FAIL: g++.dg/torture/stackalign/unwind-1.C (test for excess errors) WARNING: g++.dg/torture/stackalign/unwind-1.C compilation failed to produce executable FAIL: g++.dg/torture/stackalign/unwind-1.C (test for excess errors) WARNING: g++.dg/torture/stackalign/unwind-1.C compilation failed to produce executable FAIL: g++.dg/torture/stackalign/unwind-1.C (test for excess errors) WARNING: g++.dg/torture/stackalign/unwind-1.C compilation failed to produce executable FAIL: g++.dg/torture/stackalign/unwind-1.C (test for excess errors) WARNING: g++.dg/torture/stackalign/unwind-1.C compilation failed to produce executable FAIL: g++.dg/torture/stackalign/unwind-1.C (test for excess errors) WARNING: g++.dg/torture/stackalign/unwind-1.C compilation failed to produce executable FAIL: g++.dg/torture/stackalign/unwind-1.C (test for excess errors) WARNING: g++.dg/torture/stackalign/unwind-1.C compilation failed to produce executable FAIL: g++.dg/torture/stackalign/unwind-2.C (test for excess errors) WARNING: g++.dg/torture/stackalign/unwind-2.C compilation failed to produce executable FAIL: g++.dg/torture/stackalign/unwind-2.C (test for excess errors) WARNING: g++.dg/torture/stackalign/unwind-2.C compilation failed to produce executable FAIL: g++.dg/torture/stackalign/unwind-2.C (test for excess errors) WARNING: g++.dg/torture/stackalign/unwind-2.C compilation failed to produce executable FAIL: g++.dg/torture/stackalign/unwind-2.C (test for excess errors) WARNING: g++.dg/torture/stackalign/unwind-2.C compilation failed to produce executable FAIL: g++.dg/torture/stackalign/unwind-2.C (test for excess errors) WARNING: g++.dg/torture/stackalign/unwind-2.C compilation failed to produce executable FAIL: g++.dg/torture/stackalign/unwind-2.C (test for excess errors) WARNING: g++.dg/torture/stackalign/unwind-2.C compilation failed to produce executable FAIL: g++.dg/torture/stackalign/unwind-3.C (test for excess errors) WARNING: g++.dg/torture/stackalign/unwind-3.C compilation failed to produce executable FAIL: g++.dg/torture/stackalign/unwind-3.C (test for excess errors) WARNING: g++.dg/torture/stackalign/unwind-3.C compilation failed to produce executable FAIL: g++.dg/torture/stackalign/unwind-3.C (test for excess errors) WARNING: g++.dg/torture/stackalign/unwind-3.C compilation failed to produce executable FAIL: g++.dg/torture/stackalign/unwind-3.C (test for excess errors) WARNING: g++.dg/torture/stackalign/unwind-3.C compilation failed to produce executable FAIL: g++.dg/torture/stackalign/unwind-3.C (test for excess errors) WARNING: g++.dg/torture/stackalign/unwind-3.C compilation failed to produce executable FAIL: g++.dg/torture/stackalign/unwind-3.C (test for excess errors) WARNING: g++.dg/torture/stackalign/unwind-3.C compilation failed to produce executable FAIL: g++.dg/torture/stackalign/unwind-4.C (test for excess errors) WARNING: g++.dg/torture/stackalign/unwind-4.C compilation failed to produce executable FAIL: g++.dg/torture/stackalign/unwind-4.C (test for excess errors) WARNING: g++.dg/torture/stackalign/unwind-4.C compilation failed to produce executable FAIL: g++.dg/torture/stackalign/unwind-4.C (test for excess errors) WARNING: g++.dg/torture/stackalign/unwind-4.C compilation failed to produce executable FAIL: g++.dg/torture/stackalign/unwind-4.C (test for excess errors) WARNING: g++.dg/torture/stackalign/unwind-4.C compilation failed to produce executable FAIL: g++.dg/torture/stackalign/unwind-4.C (test for excess errors) WARNING: g++.dg/torture/stackalign/unwind-4.C compilation failed to produce executable FAIL: g++.dg/torture/stackalign/unwind-4.C (test for excess errors) WARNING: g++.dg/torture/stackalign/unwind-4.C compilation failed to produce executable FAIL: g++.dg/torture/stackalign/unwind-4.C (test for excess errors) WARNING: g++.dg/torture/stackalign/unwind-4.C compilation failed to produce executable FAIL: g++.dg/torture/stackalign/unwind-4.C (test for excess errors) WARNING: g++.dg/torture/stackalign/unwind-4.C compilation
[Bug testsuite/38949] Link failures in new stackalign tests
--- Comment #1 from dave dot korn dot cygwin at gmail dot com 2009-01-23 18:10 --- Created an attachment (id=17168) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17168action=view) Force assembler labels to match. Now testing this fairly straightforward approach to making the names match precisely regardless of platform's preference for an underscore prefix or no. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38949
[Bug testsuite/38949] Link failures in new stackalign tests
--- Comment #2 from dannysmith at users dot sourceforge dot net 2009-01-23 18:53 --- There is an alternative patch at http://gcc.gnu.org/ml/gcc-patches/2008-10/msg00044.html which i had forgotten about. It has been tested on i686-pc-mingw32 and i686-pc-linux -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38949
[Bug testsuite/38949] Link failures in new stackalign tests
--- Comment #3 from dave dot korn dot cygwin at gmail dot com 2009-01-23 19:02 --- Right you are. Either one should work, but I don't have any more spare time than you for testing things on Linux right now. It's non-critical, so I'll keep a patch in my local tree and maybe we should set the target milestone to 4.5.0? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38949
[Bug c++/38908] [4.4 regression] Unexplained 'anonymous' is used uninitialized in this function warning in cc1plus -m64
--- Comment #3 from bangerth at dealii dot org 2009-01-23 19:26 --- I see this as well. It triggers a ton of time in boost::graph code. I think it should have higher priority than P3. W. -- bangerth at dealii dot org changed: What|Removed |Added CC||bangerth at dealii dot org, ||mmitchel at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38908
[Bug middle-end/38851] [4.4 regression] Compiler warns about uninitialized variable that is an object with a constructor
--- Comment #7 from bangerth at dealii dot org 2009-01-23 19:31 ---
I see this as well. It triggers a lot when using boost::graph which
uses empty classes as tags all over the place. A simple case with
boost::graph would be this:
--
#include boost/graph/adjacency_list.hpp
using namespace boost;
adjacency_listvecS, vecS, undirectedS,
propertyvertex_color_t, default_color_type,
propertyvertex_degree_t,int g;
void create_graph () { add_edge(1,2, g); }
--
boost/graph/detail/adjacency_list.hpp: In function 'void create_graph()':
boost/graph/detail/adjacency_list.hpp:819: warning: 'p' may be used
uninitialized in this function
boost/graph/detail/adjacency_list.hpp:2210: note: 'p' was declared here
This problem makes -Wuninitialize pretty much useless for anyone who uses
boost::graph. I think it would be a shame if we shipped a compiler that
has a problem with this.
W.
--
bangerth at dealii dot org changed:
What|Removed |Added
CC||mmitchel at gcc dot gnu dot
||org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38851
[Bug fortran/38946] gcc trunk 143562 - Testsuite - gfortran failing tests that worked previously
--- Comment #1 from mikael at gcc dot gnu dot org 2009-01-23 20:04 --- (In reply to comment #0) === gfortran tests === FAIL: gfortran.dg/array_constructor_23.f -O3 -fomit-frame-pointer execution test FAIL: gfortran.dg/array_constructor_23.f -O3 -fomit-frame-pointer -funroll-loops execution test FAIL: gfortran.dg/array_constructor_23.f -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions execution test FAIL: gfortran.dg/array_constructor_23.f -O3 -g execution test Those were failing in your previous report too. ;) When I view the log I see this (dupe blank lines removed): Executing on host: /usr/share/src/gcc_build/gcc/testsuite/gfortran/../../gfortran -B/usr/share/src/gcc_build/gcc/testsui$ /usr/share/src/gcc_trunk/gcc/testsuite/gfortran.dg/array_constructor_26.f03:13.26: CHARACTER (MAX_FLD_HED, 1) :: DWFdHd(MAXFLD) = [( , i = 1, MAXFLD)] 1 Error: Symbol 'max_fld_hed' at (1) has no IMPLICIT type This error (like the others) is expected: we test that the compiler gives the expected output. Look for lines starting with FAIL for real failures. But as they are run-time, it won't help probably. Quite many of the newly-failing tests are about I/O; I suspect the following to be the culprit. Could you try before/after this? r143462 | pault | 2009-01-17 12:32:02 +0100 (sam. 17 janv. 2009) | 17 lines 2009-01-17 Paul Thomas pa...@gcc.gnu.org PR fortran/34955 * trans-intrinsic.c (gfc_conv_intrinsic_array_transfer): Note that some of the tests require specific features (such as denormalized long doubles) and are x-failed(which means: known to fail) on some targets or have some dg-require-effective-targets conditions on them. Thus, maybe the correct behaviour for these tests is to fail on solaris. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38946
[Bug driver/38864] Incorrect interaction between --with-arch=native and -mARCH
--- Comment #2 from nemet at gcc dot gnu dot org 2009-01-23 21:19 --- The fixed-point tests fail to compile when configure with --disable-fixed-point. I think the easiest would be to extend Richard's new infrastructure with a new keyword and then skip these tests completely. I take a look if this sounds good. -- nemet at gcc dot gnu dot org changed: What|Removed |Added CC||nemet at gcc dot gnu dot ||org, rsandifo at gcc dot gnu ||dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38864
[Bug c++/38950] New: ICE: deducing function template arguments for array type.
The following snippet makes GCC 4.3.2 (and SVN versions as of 09/2008 still)
cause an ICE:
template typename T, T N void f(T()[N]);
int main() {
int x[2];
unsigned int y[2];
f(x); // works
f(y); // ICE
}
Getting this output:
test.cpp: In function 'int main()':
test.cpp:7: internal compiler error: in dependent_type_p, at cp/pt.c:15585
More information about this issue:
http://stackoverflow.com/questions/472530/how-to-pass-an-array-size-as-a-template-with-template-type
--
Summary: ICE: deducing function template arguments for array
type.
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: schaub-johannes at web dot de
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38950
[Bug bootstrap/38892] gcc 4.4.0 20090104 - natVMVirtualMachine.cc:903: error: request for member 'frame_type' in ...
--- Comment #1 from rob1weld at aol dot com 2009-01-23 22:31 --- The adding of these assertions to replace an error message might have been first discussed here: http://gcc.gnu.org/ml/java-patches/2007-q1/msg00478.html Rob -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38892
[Bug fortran/38951] New: Fortran 2003: MINVAL/MAXVAL/MINLOC/MAXLOC for character arrays
Hi, this is just to mention that support for MINVAL/MAXVAL/MINLOC/MAXLOC for character arrays is required in Fortran 2003. Example: print *, minval ( [ A ] ) print *, minloc ( [ A ] ) should both work. -- Summary: Fortran 2003: MINVAL/MAXVAL/MINLOC/MAXLOC for character arrays Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: anlauf at gmx dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38951
[Bug target/38952] New: [4.4 Regression] EH does not work.
SjLj EH (the default) is completely broken on Cygwin (and MinGW, confirmed by Danny in private email). The failures have been occurring since at least November: see, e.g. http://gcc.gnu.org/ml/gcc-testresults/2008-11/msg02144.html (The distro maintainers have all been so focussed recently on getting DW2 EH to work on our platforms that this flew in under our radar; sorry for not noticing sooner). A simple test case and some complicated low-level analysis will follow in comments and attachments. So far it looks like an error in frame pointer elimination caused by a miscalculation of the initial frame pointer offset. I have filed this as a target problem since elimination is driven by the backend but it could just as well be a bug in rtl-optimisation; we'll know more soon. cheers, DaveK -- Summary: [4.4 Regression] EH does not work. Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dave dot korn dot cygwin at gmail dot com GCC build triplet: i686-pc-cygwin GCC host triplet: i686-pc-cygwin GCC target triplet: i686-pc-cygwin http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38952
[Bug target/38952] [4.4 Regression] EH does not work.
--- Comment #1 from dave dot korn dot cygwin at gmail dot com 2009-01-23 23:31 --- Created an attachment (id=17169) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17169action=view) Simple throw-catch testcase Test cases don't come much simpler than this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38952
[Bug target/38952] [4.4 Regression] EH does not work.
--- Comment #2 from dave dot korn dot cygwin at gmail dot com 2009-01-23 23:31 --- Created an attachment (id=17170) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17170action=view) Pre-processed source of testcase. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38952
[Bug target/38952] [4.4 Regression] EH does not work.
--- Comment #3 from dave dot korn dot cygwin at gmail dot com 2009-01-23 23:32 --- Created an attachment (id=17171) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17171action=view) Generated assembler for testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38952
[Bug target/38952] [4.4 Regression] EH does not work.
--- Comment #4 from dave dot korn dot cygwin at gmail dot com 2009-01-23 23:44 --- The bug manifests itself as a crash on exit from main(); $eip is set to zero and we get a SEGV. On entry to main(), the registers show: esp0x22cc40 0x22cc40 ebp0x22cca8 0x22cca8 Just before the epilogue at the end of main, we see: esp0x22cc40 0x22cc40 ebp0x22cc90 0x22cc90 (gdb) x/32xw 0x22cc40 0x22cc40: 0x0022cc5c 0x0040e7e0 0x 0x004f0584 0x22cc50: 0x005005c2 0x32200060 0x0022cc78 0x 0x22cc60: 0x 0x100325b8 0x0001 0x61010173 0x22cc70: 0x0001 0x00407600 0x00407bd4 0x0022cc90 0x22cc80: 0x004010ec 0x0022cc40 0x 0x610df2c7 0x22cc90: 0x100324fa 0x 0x611021a0 0x0040546c 0x22cca0: 0x611021a0 0x0040546c 0x0022cd98 0x610060e8 0x22ccb0: 0x0001 0x100324a0 0x10030090 0x6003 (gdb) and so when we come to the ret instruction, ... (gdb) Breakpoint 2, 0x00401125 in main () at ./eh.C:11 11 } (gdb) info reg eax0x0 0 ecx0x22cb30 2280240 edx0x0 0 ebx0x0 0 esp0x22cc94 0x22cc94 ebp0x100324fa 0x100324fa esi0x611021a0 1628447136 edi0x40546c 4215916 eip0x401125 0x401125 main+181 eflags 0x202[ IF ] cs 0x1b 27 ss 0x23 35 ds 0x23 35 es 0x23 35 fs 0x38 56 gs 0x0 0 (gdb) stepi 0x in ?? () Next comment will analyze how $ebp comes to have the wrong value. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38952
[Bug target/38941] CX isn't preserved with shift
--- Comment #8 from hjl dot tools at gmail dot com 2009-01-24 00:08 ---
Reload can't deal with:
[...@gnu-6 reg-1]$ cat f.i
int
bar (int g)
{
register int x __asm__(ecx);
x = 8;
if ((1 g) != x)
return 0;
return x;
}
[...@gnu-6 reg-1]$ /export/build/gnu/gcc-work/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc-work/build-x86_64-linux/gcc/ -m32 -O0 f.i -S -o f.s
f.i: In function ‘bar’:
f.i:9: error: unable to find a register to spill in class ‘CREG’
f.i:9: error: this is the insn:
(insn 8 7 9 2 f.i:6 (parallel [
(set (reg:SI 1 dx [orig:60 D.1249 ] [60])
(ashift:SI (reg:SI 1 dx [63])
(subreg:QI (reg:SI 0 ax [62]) 0)))
(clobber (reg:CC 17 flags))
]) 495 {*ashlsi3_1} (expr_list:REG_DEAD (reg:SI 1 dx [63])
(expr_list:REG_DEAD (reg:SI 0 ax [62])
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil)
f.i:9: internal compiler error: in spill_failure, at reload1.c:2093
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
[...@gnu-6 reg-1]$
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38941
[Bug target/38952] [4.4 Regression] EH does not work.
--- Comment #5 from dave dot korn dot cygwin at gmail dot com 2009-01-24
00:10 ---
Here is a disassembly of the start of the main function:
(gdb) disass main
Dump of assembler code for function main:
0x00401070 main+0:push %ebp
0x00401071 main+1:mov%esp,%ebp
0x00401073 main+3:and$0xfff0,%esp
0x00401076 main+6:sub$0x60,%esp
0x00401079 main+9:mov%ebx,0x54(%esp)
0x0040107d main+13: mov%esi,0x58(%esp)
0x00401081 main+17: mov%edi,0x5c(%esp)
0x00401085 main+21: movl $0x407600,0x34(%esp)
0x0040108d main+29: movl $0x407bd4,0x38(%esp)
0x00401095 main+37: lea0x3c(%esp),%eax
0x00401099 main+41: lea0x50(%esp),%edx
0x0040109d main+45: mov%edx,(%eax)
0x0040109f main+47: movl $0x4010ec,0x4(%eax)
0x004010a6 main+54: mov%esp,0x8(%eax)
0x004010a9 main+57: lea0x1c(%esp),%eax
0x004010ad main+61: mov%eax,(%esp)
0x004010b0 main+64: call 0x405068 _Unwind_SjLj_Register
0x004010b5 main+69: call 0x40515c __main
0x004010ba main+74: movl $0x4,(%esp)
0x004010c1 main+81: call 0x406b00 __cxa_allocate_exception
0x004010c6 main+86: movl $0x1,(%eax)
0x004010cc main+92: movl $0x0,0x8(%esp)
0x004010d4 main+100: movl $0x40e7e0,0x4(%esp)
0x004010dc main+108: mov%eax,(%esp)
0x004010df main+111: movl $0x1,0x20(%esp)
0x004010e7 main+119: call 0x4075a0 __cxa_throw
0x004010ec main+124: mov0x24(%esp),%eax
0x004010f0 main+128: mov%eax,(%esp)
0x004010f3 main+131: call 0x406da0 __cxa_begin_catch
If we set a breakpoint on every function call, and run through it:
(gdb) r
Starting program: /win/i/FSF-Gcc/obj-sjlj/gcc/testsuite/g++/eh.exe
[New thread 648.0x754]
[New thread 648.0x31c]
Breakpoint 1, main () at ./eh.C:4
4 {
(gdb) print $esp
$2 = (void *) 0x22ccac
(gdb) c
Continuing.
Breakpoint 3, 0x004010b0 in main () at ./eh.C:4
4 {
(gdb) print $esp
$3 = (void *) 0x22cc40
(gdb) print $ebp
$14 = (void *) 0x22cca8
(gdb) c
Continuing.
Breakpoint 4, main () at ./eh.C:4
4 {
(gdb) print $ebp
$4 = (void *) 0x22cca8
(gdb) c
Continuing.
Breakpoint 5, 0x004010c1 in main () at ./eh.C:6
6 throw 1;
(gdb) print $ebp
$5 = (void *) 0x22cca8
(gdb) c
Continuing.
Breakpoint 6, 0x004010e7 in main () at ./eh.C:6
6 throw 1;
(gdb) print $ebp
$6 = (void *) 0x22cca8
(gdb) c
Continuing.
Breakpoint 10, _Unwind_SjLj_RaiseException (exc=0x100325b8)
at /gnu/gcc/gcc/libgcc/../gcc/unwind-sjlj.c:148
148 if (use_fc_key 0)
Current language: auto; currently c
(gdb) print $ebp
$7 = (void *) 0x22cc18
(gdb) c
Continuing.
Breakpoint 7, 0x004010f3 in main () at ./eh.C:8
8 catch (...) {
Current language: auto; currently c++
(gdb) print $ebp
$8 = (void *) 0x22cc90
(gdb) c
Continuing.
Breakpoint 8, 0x00401100 in main () at ./eh.C:8
8 catch (...) {
(gdb) print $ebp
$9 = (void *) 0x22cc90
(gdb) c
Continuing.
Breakpoint 9, 0x0040110c in main () at ./eh.C:8
8 catch (...) {
(gdb) print $ebp
$10 = (void *) 0x22cc90
(gdb) c
Continuing.
Breakpoint 11, 0x00401122 in main () at ./eh.C:11
11 }
(gdb) print $ebp
$11 = (void *) 0x22cc90
(gdb) c
Continuing.
Breakpoint 2, 0x00401125 in main () at ./eh.C:11
11 }
(gdb) print $ebp
$12 = (void *) 0x100324fa
(gdb) c
Continuing.
Program received signal SIGSEGV, Segmentation fault.
0x in ?? ()
(gdb)
... we can see that $ebp is correct right up until the call to __cxa_throw at
0x004010e7, but when we return to the catch landing site at 0x004010f3, $ebp is
incorrect.
This incorrect value is calculated in the code at the start of main(), where
the code generated by sjlj_emit_function_enter calls
expand_builtin_setjmp_setup to initialise the jbuf[] member of the struct
SjLj_Function_Context that it then passes to _Unwind_SjLj_Register. From that
call:
0x004010a9 main+57: lea0x1c(%esp),%eax
0x004010ad main+61: mov%eax,(%esp)
0x004010b0 main+64: call 0x405068 _Unwind_SjLj_Register
the struct is at an offset of 0x1c on the stack. Looking at the memory dump,
just before the call:
0x22cc40: 0x0022cc5c 0xbdbdbdbd 0xbdbdbdbd 0xbdbdbdbd
0x22cc50: 0xbdbdbdbd 0xbdbdbdbd 0xbdbdbdbd 0xbdbdbdbd
0x22cc60: 0xbdbdbdbd 0xbdbdbdbd 0xbdbdbdbd 0xbdbdbdbd
0x22cc70: 0xbdbdbdbd 0x00407600 0x00407bd4 0x0022cc90
0x22cc80: 0x004010ec 0x0022cc40 0xbdbdbdbd 0xbdbdbdbd
0x22cc90: 0xbdbdbdbd 0x 0x611021a0 0x0040546c
0x22cca0: 0xbdbdbdbd 0xbdbdbdbd 0x0022cd98 0x610060e8
0x22ccb0: 0x0001 0x100324a0 0x10030090 0x6003
.. shows that the struct has been initialised like so:
OFFS:0x001c: prev = 0xbdbdbdbd, call_Site 0xbdbdbdbd
OFFS:0x0024: data[4] = { 0xbdbdbdbd, 0xbdbdbdbd, 0xbdbdbdbd, 0xbdbdbdbd }
OFFS:0x0034: personality = 0x00407600 = __gxx_personality_sj0
OFFS:0x0038: lsda = 0x00407bd4 = __DTOR_LIST__+16:0x010d00ff
[Bug tree-optimization/38953] New: [graphite] loop closed SSA not maintained by graphite code generation
This problem happened in the graphite branch where after the graphite pass we scheduled a pass of loop invariant motion (LIM). LIM does expect to see the loop closed SSA form, but that property is not maintained by the code generator of graphite. The testcase is extracted from the polyhedron benchmark aermod.f90 and it failed on graphite branch when compiled with -O3 that implies -floop-block and -fgraphite-identity. -- Summary: [graphite] loop closed SSA not maintained by graphite code generation Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: spop at gcc dot gnu dot org ReportedBy: spop at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38953
[Bug tree-optimization/38953] [graphite] loop closed SSA not maintained by graphite code generation
--- Comment #1 from spop at gcc dot gnu dot org 2009-01-24 00:47 --- Created an attachment (id=17172) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17172action=view) patch -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38953
[Bug tree-optimization/38953] [graphite] loop closed SSA not maintained by graphite code generation
--- Comment #2 from spop at gcc dot gnu dot org 2009-01-24 01:00 --- Subject: Bug 38953 Author: spop Date: Sat Jan 24 00:59:51 2009 New Revision: 143599 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143599 Log: 2009-01-24 Sebastian Pop sebastian@amd.com PR tree-optimization/38953 * graphite.c (graphite_verify): Add a call to verify_loop_closed_ssa. (scop_adjust_phis_for_liveouts): Initialize false_i to zero. (gloog): Split the exit of the scop when the scop exit is a loop exit. (graphite_transform_loops): Only call cleanup_tree_cfg if gloog changed the CFG. * gfortran.dg/graphite/pr38953.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/graphite/pr38953.f90 Modified: trunk/gcc/ChangeLog trunk/gcc/graphite.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38953
[Bug tree-optimization/38953] [graphite] loop closed SSA not maintained by graphite code generation
--- Comment #3 from spop at gcc dot gnu dot org 2009-01-24 01:00 --- Fixed. -- spop at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38953
[Bug target/38952] [4.4 Regression] EH does not work.
--- Comment #6 from dave dot korn dot cygwin at gmail dot com 2009-01-24
01:08 ---
Here is the RTL that is created by the .130r.eh pass: everything between note 2
and call_insn 3, was added after expand.
try_optimize_cfg iteration 2
(note 1 0 4 NOTE_INSN_DELETED)
(note 4 1 2 2 [bb 2] NOTE_INSN_BASIC_BLOCK)
(note 2 4 46 2 NOTE_INSN_FUNCTION_BEG)
(insn 46 2 47 2 (set (mem/c:SI (plus:SI (reg/f:SI 54 virtual-stack-vars)
(const_int -28 [0xffe4])) [0 S4 A32])
(symbol_ref:SI (__gxx_personality_sj0) [flags 0x43])) -1 (nil))
(insn 47 46 48 2 (set (mem/c:SI (plus:SI (reg/f:SI 54 virtual-stack-vars)
(const_int -24 [0xffe8])) [0 S4 A32])
(symbol_ref:SI (*LLSDA0) [flags 0x2])) -1 (nil))
(insn 48 47 49 2 (parallel [
(set (reg:SI 63)
(plus:SI (reg/f:SI 54 virtual-stack-vars)
(const_int -20 [0xffec])))
(clobber (reg:CC 17 flags))
]) -1 (nil))
(insn 49 48 50 2 (set (mem:SI (reg:SI 63) [0 S4 A8])
(reg/f:SI 54 virtual-stack-vars)) -1 (nil))
(insn 50 49 51 2 (set (reg/f:SI 64)
(label_ref:SI 56)) -1 (insn_list:REG_LABEL_OPERAND 56 (nil)))
(insn 51 50 52 2 (set (mem:SI (plus:SI (reg:SI 63)
(const_int 4 [0x4])) [0 S4 A8])
(reg/f:SI 64)) -1 (nil))
(insn 52 51 53 2 (set (mem:SI (plus:SI (reg:SI 63)
(const_int 8 [0x8])) [0 S4 A8])
(reg/f:SI 7 sp)) -1 (nil))
(insn 53 52 54 2 (parallel [
(set (reg:SI 65)
(plus:SI (reg/f:SI 54 virtual-stack-vars)
(const_int -52 [0xffcc])))
(clobber (reg:CC 17 flags))
]) -1 (nil))
(insn 54 53 55 2 (set (mem:SI (reg/f:SI 56 virtual-outgoing-args) [0 S4 A32])
(reg:SI 65)) -1 (nil))
(call_insn 55 54 3 2 (call (mem:QI (symbol_ref:SI (_Unwind_SjLj_Register)
[flags 0x43]) [0 S1 A8])
(const_int 16 [0x10])) -1 (expr_list:REG_EH_REGION (const_int 0 [0x0])
(nil))
(nil))
(call_insn 3 55 6 2 ./eh.C:4 (call (mem:QI (symbol_ref:SI (__main) [flags
0x43]) [0 S1 A8])
(const_int 0 [0x0])) -1 (expr_list:REG_EH_REGION (const_int 0 [0x0])
(nil))
(nil))
Pass 133r.vregs turns this into:
(insn 46 2 47 2 (set (mem/c:SI (plus:SI (reg/f:SI 20 frame)
(const_int -28 [0xffe4])) [0 S4 A32])
(symbol_ref:SI (__gxx_personality_sj0) [flags 0x43])) 41 {*movsi_1}
(nil))
(insn 47 46 48 2 (set (mem/c:SI (plus:SI (reg/f:SI 20 frame)
(const_int -24 [0xffe8])) [0 S4 A32])
(symbol_ref:SI (*LLSDA0) [flags 0x2])) 41 {*movsi_1} (nil))
(insn 48 47 49 2 (parallel [
(set (reg:SI 63)
(plus:SI (reg/f:SI 20 frame)
(const_int -20 [0xffec])))
(clobber (reg:CC 17 flags))
]) 213 {*addsi_1} (nil))
(insn 49 48 50 2 (set (mem:SI (reg:SI 63) [0 S4 A8])
(reg/f:SI 20 frame)) 41 {*movsi_1} (nil))
(insn 50 49 51 2 (set (reg/f:SI 64)
(label_ref:SI 56)) 41 {*movsi_1} (insn_list:REG_LABEL_OPERAND 56
(nil)))
(insn 51 50 52 2 (set (mem:SI (plus:SI (reg:SI 63)
(const_int 4 [0x4])) [0 S4 A8])
(reg/f:SI 64)) 41 {*movsi_1} (nil))
(insn 52 51 53 2 (set (mem:SI (plus:SI (reg:SI 63)
(const_int 8 [0x8])) [0 S4 A8])
(reg/f:SI 7 sp)) 41 {*movsi_1} (nil))
(insn 53 52 54 2 (parallel [
(set (reg:SI 65)
(plus:SI (reg/f:SI 20 frame)
(const_int -52 [0xffcc])))
(clobber (reg:CC 17 flags))
]) 213 {*addsi_1} (nil))
(insn 54 53 55 2 (set (mem:SI (reg/f:SI 7 sp) [0 S4 A32])
(reg:SI 65)) 41 {*movsi_1} (nil))
(call_insn 55 54 3 2 (call (mem:QI (symbol_ref:SI (_Unwind_SjLj_Register)
[flags 0x43]) [0 S1 A8])
(const_int 16 [0x10])) 466 {*call_0} (expr_list:REG_EH_REGION
(const_int 0 [0x0])
(nil))
(nil))
Note that insn 49 is the crucial one here that stores the (later miscalculated)
value of the frame pointer (i.e., $ebp - before elimination) into the jmp_buf.
At pass 174r.ira, this becomes:
(insn 48 47 73 2 (parallel [
(set (reg/f:SI 0 ax [63])
(plus:SI (reg/f:SI 7 sp)
(const_int 60 [0x3c])))
(clobber (reg:CC 17 flags))
]) 213 {*addsi_1} (expr_list:REG_EQUIV (plus:SI (reg/f:SI 7 sp)
(const_int 60 [0x3c]))
(nil)))
(insn 73 48 49 2 (set (reg:SI 1 dx)
(plus:SI (reg/f:SI 7 sp)
(const_int 80 [0x50]))) 209 {*lea_1} (nil))
(insn 49 73 51 2 (set (mem:SI (reg/f:SI 0 ax [63]) [0 S4 A8])
(reg:SI 1 dx)) 41 {*movsi_1} (nil))
And this is the point at which the incorrect offset first appears.
Ouch. I hope this isn't an IRA bug, I know nothing about that. Is it valid to
do frame pointer elimination before reload like that? Because the other
possibility is that the x86 backend is suddenly growing the frame size during
some later pass. (Well, I guess we
[Bug target/38941] CX isn't preserved with shift
--- Comment #9 from hjl dot tools at gmail dot com 2009-01-24 01:32 --- From gcc doc: --- Sometimes you need to make an `asm' operand be a specific register, but there's no matching constraint letter for that register _by itself_. To force the operand into that register, use a local variable for the operand and specify the register in the variable declaration. *Note Explicit Reg Vars::. Then for the `asm' operand, use any register constraint letter that matches the register: register int *p1 asm (r0) = ...; register int *p2 asm (r1) = ...; register int *result asm (r0); asm (sysint : =r (result) : 0 (p1), r (p2)); In the above example, beware that a register that is call-clobbered by the target ABI will be overwritten by any function call in the assignment, including library calls for arithmetic operators. --- So the current gcc behaviour is reasonable. Maybe we need to extend document to cover cases where some registers may be clobbered by some operations. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38941
[Bug c++/38055] key for compilation -Wconversion
--- Comment #1 from manu at gcc dot gnu dot org 2009-01-24 01:40 --- Quoting the FAQ at http://gcc.gnu.org/wiki/NewWconversion#faq Why Wconversion is not enabled by -Wall or at least by -Wextra? Implicit conversions are very common in C. This tied with the fact that there is no data-flow in front-ends (see next question) results in hard to avoid warnings for perfectly working and valid code. Wconversion is designed for a niche of uses (security audits, porting 32 bit code to 64 bit, etc.) where the programmer is willing to accept and workaround invalid warnings. Therefore, it shouldn't be enabled if it is not explicitly requested. -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38055
[Bug libstdc++/36164] abi breakage, stdio_sync_filebuf routines missing
--- Comment #6 from bkoz at gcc dot gnu dot org 2009-01-24 01:52 --- Mine. -- bkoz at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |bkoz at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-01-24 01:52:15 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36164
[Bug c/38954] New: AVR-GCC: internal compiler error: in start_function, at c-decl.c:6248
I was instructed by avr-gcc 4.3.2 to send a bug report. Here's the command line: $ avr-gcc -v -save-temps -Os -g -Wall -I. -I../usbtiny -mmcu=attiny2313 -c -o main.o main.c Using built-in specs. Target: avr Configured with: ../configure --disable-libssp --disable-nls --enable-languages=c,c++ --mandir=/usr/share/man --prefix=/usr --target=avr --with-gnu-as --with-gnu-ld --with-as=/usr/bin/avr-as --with-ld=/usr/bin/avr-ld : (reconfigured) ../configure --disable-libssp --disable-nls --enable-languages=c,c++ --infodir=/usr/share/info --libexecdir=/usr/lib --mandir=/usr/share/man --prefix=/usr --target=avr --with-gnu-as --with-gnu-ld --with-as=/usr/bin/avr-as --with-ld=/usr/bin/avr-ld Thread model: single gcc version 4.3.2 (GCC) COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Os' '-g' '-Wall' '-I.' '-I../usbtiny' '-mmcu=attiny2313' '-c' '-o' 'main.o' /usr/lib/gcc/avr/4.3.2/cc1 -E -quiet -v -I. -I../usbtiny -imultilib avr25 main.c -mmcu=attiny2313 -Wall -fworking-directory -Os -fpch-preprocess -o main.i ignoring nonexistent directory /usr/lib/gcc/avr/4.3.2/../../../../avr/sys-include #include ... search starts here: #include ... search starts here: . ../usbtiny /usr/lib/gcc/avr/4.3.2/include /usr/lib/gcc/avr/4.3.2/include-fixed /usr/lib/gcc/avr/4.3.2/../../../../avr/include End of search list. COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Os' '-g' '-Wall' '-I.' '-I../usbtiny' '-mmcu=attiny2313' '-c' '-o' 'main.o' /usr/lib/gcc/avr/4.3.2/cc1 -fpreprocessed main.i -quiet -dumpbase main.c -mmcu=attiny2313 -auxbase-strip main.o -g -Os -Wall -version -o main.s GNU C (GCC) version 4.3.2 (avr) compiled by GNU C version 4.3.2, GMP version 4.2.4, MPFR version 2.3.2. GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: 2d5f5dc20dcc192172a3e9de347166ce main.c:168: internal compiler error: in start_function, at c-decl.c:6248 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. And here's the main.i it generates (the source is GPLed): # 1 main.c # 1 /home/toxite/usbtiny-1.4/ir// # 1 built-in # 1 command-line # 1 main.c # 102 main.c # 1 /usr/lib/gcc/avr/4.3.2/../../../../avr/include/avr/io.h 1 3 # 99 /usr/lib/gcc/avr/4.3.2/../../../../avr/include/avr/io.h 3 # 1 /usr/lib/gcc/avr/4.3.2/../../../../avr/include/avr/sfr_defs.h 1 3 # 126 /usr/lib/gcc/avr/4.3.2/../../../../avr/include/avr/sfr_defs.h 3 # 1 /usr/lib/gcc/avr/4.3.2/../../../../avr/include/inttypes.h 1 3 # 37 /usr/lib/gcc/avr/4.3.2/../../../../avr/include/inttypes.h 3 # 1 /usr/lib/gcc/avr/4.3.2/../../../../avr/include/stdint.h 1 3 # 121 /usr/lib/gcc/avr/4.3.2/../../../../avr/include/stdint.h 3 typedef int int8_t __attribute__((__mode__(__QI__))); typedef unsigned int uint8_t __attribute__((__mode__(__QI__))); typedef int int16_t __attribute__ ((__mode__ (__HI__))); typedef unsigned int uint16_t __attribute__ ((__mode__ (__HI__))); typedef int int32_t __attribute__ ((__mode__ (__SI__))); typedef unsigned int uint32_t __attribute__ ((__mode__ (__SI__))); typedef int int64_t __attribute__((__mode__(__DI__))); typedef unsigned int uint64_t __attribute__((__mode__(__DI__))); # 142 /usr/lib/gcc/avr/4.3.2/../../../../avr/include/stdint.h 3 typedef int16_t intptr_t; typedef uint16_t uintptr_t; # 159 /usr/lib/gcc/avr/4.3.2/../../../../avr/include/stdint.h 3 typedef int8_t int_least8_t; typedef uint8_t uint_least8_t; typedef int16_t int_least16_t; typedef uint16_t uint_least16_t; typedef int32_t int_least32_t; typedef uint32_t uint_least32_t; typedef int64_t int_least64_t; typedef uint64_t uint_least64_t; # 213 /usr/lib/gcc/avr/4.3.2/../../../../avr/include/stdint.h 3 typedef int8_t int_fast8_t; typedef uint8_t uint_fast8_t; typedef int16_t int_fast16_t; typedef uint16_t uint_fast16_t; typedef int32_t int_fast32_t; typedef uint32_t uint_fast32_t; typedef int64_t int_fast64_t; typedef uint64_t uint_fast64_t; # 273 /usr/lib/gcc/avr/4.3.2/../../../../avr/include/stdint.h 3 typedef int64_t intmax_t; typedef uint64_t uintmax_t; # 38 /usr/lib/gcc/avr/4.3.2/../../../../avr/include/inttypes.h 2 3 # 77 /usr/lib/gcc/avr/4.3.2/../../../../avr/include/inttypes.h 3 typedef int32_t int_farptr_t; typedef uint32_t uint_farptr_t; # 127 /usr/lib/gcc/avr/4.3.2/../../../../avr/include/avr/sfr_defs.h 2 3 # 100 /usr/lib/gcc/avr/4.3.2/../../../../avr/include/avr/io.h 2 3 # 274 /usr/lib/gcc/avr/4.3.2/../../../../avr/include/avr/io.h 3 # 1 /usr/lib/gcc/avr/4.3.2/../../../../avr/include/avr/iotn2313.h 1 3 # 275 /usr/lib/gcc/avr/4.3.2/../../../../avr/include/avr/io.h 2 3 # 334 /usr/lib/gcc/avr/4.3.2/../../../../avr/include/avr/io.h 3 # 1 /usr/lib/gcc/avr/4.3.2/../../../../avr/include/avr/portpins.h 1 3 # 335 /usr/lib/gcc/avr/4.3.2/../../../../avr/include/avr/io.h 2 3 # 1 /usr/lib/gcc/avr/4.3.2/../../../../avr/include/avr/common.h 1 3 # 337 /usr/lib/gcc/avr/4.3.2/../../../../avr/include/avr/io.h 2 3
[Bug fortran/38955] New: testsuite/gfortran.dg/array_constructor_24.f fails due to floating point comparison
With recent trunk (4.4.0 20090107), test gfortran.dg/array_constructor_24.f fails on i686-pc-cygwin for the four -O3 execution tests. The failure is in subroutine FA6013. program try_fa6013 call fa6013 (10, 1, -1) call fa6077 (10, 1, -1, (/1,2,3,4,5,6,7,8,9,10/)) call fa2083 end program subroutine FA6013 (nf10, nf1, mf1) integer, parameter :: kv = 4 REAL(KV) DDA1(10) REAL(KV) DDA2(10) REAL(KV) DDA(10), dval dda = (/1,2,3,4,5,6,7,8,9,10/) DDA1 = ATAN2 ((/(REAL(J1,KV),J1=1,10)/), $ REAL((/(J1,J1=nf10,nf1,mf1)/), KV)) !fails DDA2 = ATAN2 (DDA, DDA(10:1:-1)) if (any (abs(DDA1-DDA2) .gt. 1.0e-6)) call abort () END On investigation, I found that all the components of arrays DDA1 and DDA2 were equal, but the test (any (DDA1 .ne. DDA2)) fails. It looks like a typical ix86 excess precision problem when comparing floating point number for equality. The following patch allows the test to pass. --- array_constructor_24.f.orig 2009-01-24 13:14:35.828125000 +1100 +++ array_constructor_24.f 2009-01-24 12:43:50.203125000 +1100 @@ -19,7 +19,7 @@ DDA1 = ATAN2 ((/(REAL(J1,KV),J1=1,10)/), $ REAL((/(J1,J1=nf10,nf1,mf1)/), KV)) !fails DDA2 = ATAN2 (DDA, DDA(10:1:-1)) - if (any (DDA1 .ne. DDA2)) call abort () + if (any (abs(DDA1-DDA2) .gt. 1.0e-6)) call abort () END subroutine FA6077 (nf10,nf1,mf1, ida) -- Summary: testsuite/gfortran.dg/array_constructor_24.f fails due to floating point comparison Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: billingd at gcc dot gnu dot org GCC build triplet: i686-pc-cygwin GCC host triplet: i686-pc-cygwin GCC target triplet: i686-pc-cygwin http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38955
[Bug fortran/38955] testsuite/gfortran.dg/array_constructor_24.f fails due to floating point comparison
-- billingd at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |billingd at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-01-24 02:25:38 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38955
[Bug libstdc++/36164] abi breakage, stdio_sync_filebuf routines missing
--- Comment #7 from bkoz at gcc dot gnu dot org 2009-01-24 02:30 --- Please note there are no ABI baseline files checked in to the FSF GCC repository for darwin for this (or any) release on this (or any) architecture. Without these, there can be no automated ABI testing by the GCC community. Thus, there is no ABI to break for your release/target, and this bug is invalid. If this is something you'd like to see supported on your target in the future, please consider activating the make check-abi rule and checking in the ABI baseline files (baseline_symbols.txt) to the config/abi/post/[powerpc|i686]_darwin directories. There appears to be scripts/make_exports.pl that intends to generate the appropriate baseline files for darwin. It appears to be unused. Is this still in an experimental state? Now, to answer the stated question. On x86_64-linux-gnu, gcc-4.0.4 has the following stdio_sync_exports in baseline_symbols.txt: OBJECT:54:_ZTSN9__gnu_cxx18stdio_sync_filebufIcSt11char_traitsIcEEE@@GLIBCXX_3.4 OBJECT:54:_ZTSN9__gnu_cxx18stdio_sync_filebufIwSt11char_traitsIwEEE@@GLIBCXX_3.4 FUNC:_ZN9__gnu_cxx18stdio_sync_filebufIcSt11char_traitsIcEE4fileEv@@GLIBCXX_3.4.2 FUNC:_ZN9__gnu_cxx18stdio_sync_filebufIwSt11char_traitsIwEE4fileEv@@GLIBCXX_3.4.2 OBJECT:24:_ZTIN9__gnu_cxx18stdio_sync_filebufIcSt11char_traitsIcEEE@@GLIBCXX_3.4 OBJECT:24:_ZTIN9__gnu_cxx18stdio_sync_filebufIwSt11char_traitsIwEEE@@GLIBCXX_3.4 OBJECT:54:_ZTSN9__gnu_cxx18stdio_sync_filebufIcSt11char_traitsIcEEE@@GLIBCXX_3.4 OBJECT:54:_ZTSN9__gnu_cxx18stdio_sync_filebufIwSt11char_traitsIwEEE@@GLIBCXX_3.4 These match gcc-4.2.4. Analysis of prior baseline_symbols.txt files (from gcc-3.4.6) show similar exports for this class. So, 000252d2 T __gnu_cxx::stdio_sync_filebufchar, std::char_traitschar ::file() 0002530e T __gnu_cxx::stdio_sync_filebufwchar_t, std::char_traitswchar_t ::file() was exported from gcc-3.4.6 to gcc-4.2.4 inclusive, and remains exported. The remaining functions were not exported. For the record, later versions of gcc, starting with gcc-4.3.0, started exporting these stdio_sync_filebuf member functions in the GLIBCXX_3.4.10 namespace. This is not especially relevant to your question about gcc-4.0.0 to gcc-4.2.1 versioning. If darwin exported these additional member functions in gcc-4.0.0, then it did so in divergence with the linux baselines. Hope this helps. -- bkoz at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36164
[Bug libstdc++/36173] abi breakage, stdio_filebuf routines missing
--- Comment #2 from bkoz at gcc dot gnu dot org 2009-01-24 02:33 --- Mine. -- bkoz at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |bkoz at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-01-24 02:33:35 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36173
[Bug fortran/38955] testsuite/gfortran.dg/array_constructor_24.f fails due to floating point comparison
--- Comment #1 from billingd at gcc dot gnu dot org 2009-01-24 02:44 --- Patch http://gcc.gnu.org/ml/gcc-patches/2009-01/msg01181.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38955
[Bug libstdc++/36173] abi breakage, stdio_filebuf routines missing
--- Comment #3 from bkoz at gcc dot gnu dot org 2009-01-24 02:45 --- Please note there are no ABI baseline files checked in to the FSF GCC repository for darwin for this (or any) release on this (or any) architecture. Without these, there can be no automated ABI testing by the GCC community. Thus, there is no ABI to break for your release/target, and this bug is invalid. If this is something you'd like to see supported on your target in the future, please consider activating the make check-abi rule and checking in the ABI baseline files (baseline_symbols.txt) to the config/abi/post/[powerpc|i686]_darwin directories. Now, to answer the stated question. On x86_64-linux-gnu, gcc-4.0.4 has the following stdio_filebuf exports in baseline_symbols.txt: OBJECT:24:_ZTIN9__gnu_cxx13stdio_filebufIcSt11char_traitsIcEEE@@GLIBCXX_3.4 OBJECT:24:_ZTIN9__gnu_cxx13stdio_filebufIwSt11char_traitsIwEEE@@GLIBCXX_3.4 OBJECT:49:_ZTSN9__gnu_cxx13stdio_filebufIcSt11char_traitsIcEEE@@GLIBCXX_3.4 OBJECT:49:_ZTSN9__gnu_cxx13stdio_filebufIwSt11char_traitsIwEEE@@GLIBCXX_3.4 These match gcc-4.2.4. Analysis of prior baseline_symbols.txt files (from gcc-3.4.6) show similar exports for this class. For the record, later versions of gcc, starting with gcc-4.3.0, still have only these exports. If darwin exported additional member functions in gcc-4.0.0 for stdio_filebuf, then it did so in divergence with the linux baselines. Hope this helps. -- bkoz at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36173
[Bug driver/38864] Incorrect interaction between --with-arch=native and -mARCH
--- Comment #3 from nemet at gcc dot gnu dot org 2009-01-24 02:47 ---
It was actually Richard's mips.exp rewrite that removed { target { fixed_point
} } from these tests.
Richard, was this intentional? It seems to me that since fixed-point is not
dependent on a command-line flag (-mdsp is orthogonal) the effective-target
check is correct here.
Should I revert it like this:
Index: fixed-vector-type.c
===
--- fixed-vector-type.c (revision 143450)
+++ fixed-vector-type.c (working copy)
@@ -1,5 +1,5 @@
/* Test vector fixed-point instructions */
-/* { dg-do compile } */
+/* { dg-do compile { target { fixed_point } } } */
/* { dg-options -mdspr2 -O2 } */
/* { dg-final { scan-assembler-times \taddq_s.ph\t 2 } } */
/* { dg-final { scan-assembler-times \tsubq_s.ph\t 2 } } */
Index: fixed-scalar-type.c
===
--- fixed-scalar-type.c (revision 143450)
+++ fixed-scalar-type.c (working copy)
@@ -1,5 +1,5 @@
/* Test scalar fixed-point instructions */
-/* { dg-do compile } */
+/* { dg-do compile { target { fixed_point } } } */
/* { dg-options -mdspr2 -O2 } */
/* { dg-final { scan-assembler-times \taddu\t 10 } } */
/* { dg-final { scan-assembler-times \tsubu\t 10 } } */
Index: dpaq_sa_l_w.c
===
--- dpaq_sa_l_w.c (revision 143450)
+++ dpaq_sa_l_w.c (working copy)
@@ -1,4 +1,4 @@
-/* { dg-do compile } */
+/* { dg-do compile { target { fixed_point } } } */
/* { dg-options -O2 -mgp32 -mdsp } */
/* { dg-final { scan-assembler-times \tdpaq_sa.l.w\t\\\$ac 3 } } */
Index: dpsq_sa_l_w.c
===
--- dpsq_sa_l_w.c (revision 143450)
+++ dpsq_sa_l_w.c (working copy)
@@ -1,4 +1,4 @@
-/* { dg-do compile } */
+/* { dg-do compile { target { fixed_point } } } */
/* { dg-options -O2 -mgp32 -mdsp } */
/* { dg-final { scan-assembler-times \tdpsq_sa.l.w\t\\\$ac 2 } } */
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38864
[Bug libstdc++/35934] abi breakage in search (4.0.0 - 4.2.1)
--- Comment #2 from bkoz at gcc dot gnu dot org 2009-01-24 02:57 --- Mine. -- bkoz at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |bkoz at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-01-24 02:57:56 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35934
[Bug fortran/38956] New: test gfortran.dg/chmod_1.f90 fails on i686-pc-cygwin
Test gfortran.dg/chmod_1.f90 fails on i686-pc-cygwin. The part of the test that fails is: call chmod (n, a-w, i if (i == 0 .and. getuid() /= 0) then if (access(n,w) == 0 .or. access(n,W) == 0) call abort end if n = foobar_file, and after the test we have $ ls -l foobar_file -r-xr-xr-x 1 DABilling Domain_Users 0 Jan 24 13:58 foobar_file so it appears thet the chmod function works. -- Summary: test gfortran.dg/chmod_1.f90 fails on i686-pc-cygwin Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: billingd at gcc dot gnu dot org GCC build triplet: i686-pc-cygwin GCC host triplet: i686-pc-cygwin GCC target triplet: i686-pc-cygwin http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38956
[Bug fortran/38956] test gfortran.dg/chmod_1.f90 fails on i686-pc-cygwin
--- Comment #1 from billingd at gcc dot gnu dot org 2009-01-24 03:06 --- This is with cygwin-1.7. -- billingd at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |billingd at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-01-24 03:06:19 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38956
[Bug libstdc++/35934] abi breakage in search (4.0.0 - 4.2.1)
--- Comment #3 from bkoz at gcc dot gnu dot org 2009-01-24 03:20 --- Please note there are no ABI baseline files checked in to the FSF GCC repository for darwin for this (or any) release on this (or any) architecture. Without these, there can be no automated ABI testing by the GCC community. Thus, there is no ABI to break for your release/target, and this bug is invalid. If this is something you'd like to see supported on your target in the future, please consider activating the make check-abi rule and checking in the ABI baseline files (baseline_symbols.txt) to the config/abi/post/[powerpc|i686]_darwin directories. Now, to answer the stated question. On x86_64-linux-gnu, gcc-4.0.4 has no search exports in baseline_symbols.txt. Analysis of prior baseline_symbols.txt files (from gcc-3.4.6 to gcc-4.4.0-preliminary) show no exports for this function. Looking at the binary, I see: %eu-readelf -s libstdc++.so.6.0.7 | grep search 296: 00096d60325 FUNCLOCAL DEFAULT 11 _ZSt6searchIPKcS1_PFbRS0_S2_EET_S5_S5_T0_S6_T1_ 529: 000af2e0293 FUNCLOCAL DEFAULT 11 _ZSt6searchIPKwS1_PFbRS0_S2_EET_S5_S5_T0_S6_T1_ So, these were LOCAL, ie not able to be linked against on linux, which is why they did not end up in the baseline_symbols.txt file, and why to this platform, it doesn't matter that the instantiations went away. If darwin exported these functions in gcc-4.0.0, then it did so in divergence with the linux baselines. Hope this helps. -- bkoz at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35934
[Bug libstdc++/28125] Cannot build cross compiler for Solaris: configure: error: Link tests are not allowed after GCC_NO_EXECUTABLES
--- Comment #21 from bkoz at gcc dot gnu dot org 2009-01-24 03:42 --- This is fixed for hpux on trunk, and I believe it should be fixed for solaris as well. Can some solaris tester confirm? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28125
[Bug libstdc++/36164] abi breakage, stdio_sync_filebuf routines missing
--- Comment #8 from mrs at apple dot com 2009-01-24 04:18 --- First, you didn't test 4.0.0, so all your reasoning is invalid. Second, claiming no ABI breakage when there is abi breakage is silly. I guess if you have no customers with no software, with do previously deployed software and you don't care about abi breakage, you can get away with it. Unfortunately, this doesn't apply in our case. I'd rather you close this out as won't fix, if you can't be bothered to even actually check the abi of gcc-4.0.0 and compare it against 4.2.1, it is more honest. Closing it as invalid is wrong. :-( -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36164
[Bug libstdc++/36173] abi breakage, stdio_filebuf routines missing
--- Comment #4 from mrs at apple dot com 2009-01-24 04:22 --- First, you didn't test 4.0.0, so all your reasoning is invalid. Second, claiming no ABI breakage when there is abi breakage is silly. I guess if you have no customers with no software, with do previously deployed software and you don't care about abi breakage, you can get away with it. Unfortunately, this doesn't apply in our case. I'd rather you close this out as won't fix, if you can't be bothered to even actually check the abi of gcc-4.0.0 and compare it against 4.2.1, it is more honest. Closing it as invalid is wrong. :-( -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36173
[Bug target/38824] [4.4 Regression] performance regression of sse code from 4.2/4.3
--- Comment #8 from xuepeng dot guo at intel dot com 2009-01-24 05:12 --- Created an attachment (id=17173) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17173action=view) An extracted test case for this bug. Hi tim, I extracted this test case from your website. But I can't exactly reproduce this bug on my machine with a core2 quard micor processor. Can you help me to check whether my test case is valid firstly? Here I post what I got on my machine for your reference: [xg...@shgcc-10 38824]$ /home/xguo2/app/trunk/bin/g++ -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ../src/configure --enable-checking=assert --disable-bootstrap --enable-languages=c,c++,fortran Thread model: posix gcc version 4.4.0 20090121 (experimental) [trunk revision 143537] (GCC) [xg...@shgcc-10 38824]$ /home/xguo2/app/trunk/bin/g++ -O3 -msse -mfpmath=sse simd_unroll_benchmarks.cpp -o 44.out [xg...@shgcc-10 38824]$ time ./44.out real0m1.877s user0m1.876s sys 0m0.001s [xg...@shgcc-10 38824]$ time ./44.out real0m1.877s user0m1.877s sys 0m0.000s [xg...@shgcc-10 38824]$ time ./44.out real0m1.881s user0m1.882s sys 0m0.000s [xg...@shgcc-10 38824]$ /home/xguo2/app/usr/gcc-4.2/bin/g++ -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: /net/gnu-13/export/gnu/src/gcc-4.2/gcc/configure --enable-clocale=gnu --with-system-zlib --with-demangler-in-ld --enable-shared --enable-threads=posix --enable-haifa --enable-checking=assert --prefix=/usr/gcc-4.2 --with-local-prefix=/usr/local Thread model: posix gcc version 4.2.0 [xg...@shgcc-10 38824]$ /home/xguo2/app/usr/gcc-4.2/bin/g++ -O3 -msse -mfpmath=sse simd_unroll_benchmarks.cpp -o 42.out [xg...@shgcc-10 38824]$ time ./42.out real0m1.991s user0m1.991s sys 0m0.000s [xg...@shgcc-10 38824]$ time ./42.out real0m1.991s user0m1.989s sys 0m0.001s [xg...@shgcc-10 38824]$ time ./42.out real0m1.991s user0m1.990s sys 0m0.000s [xg...@shgcc-10 38824]$ g++ -v Using built-in specs. Target: x86_64-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-libgcj-multifile --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --enable-plugin --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --with-cpu=generic --host=x86_64-redhat-linux Thread model: posix gcc version 4.1.2 20071124 (Red Hat 4.1.2-42) [xg...@shgcc-10 38824]$ g++ -O3 -msse -mfpmath=sse simd_unroll_benchmarks.cpp -o 41.out [xg...@shgcc-10 38824]$ time ./41.out real0m1.465s user0m1.464s sys 0m0.002s [xg...@shgcc-10 38824]$ time ./41.out real0m1.465s user0m1.465s sys 0m0.000s [xg...@shgcc-10 38824]$ time ./41.out real0m1.465s user0m1.464s sys 0m0.002s -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38824
[Bug target/37581] IEEE inexact-flag not working on the Alpha
--- Comment #3 from abramobagnara at tin dot it 2009-01-24 05:43 ---
The test case you have used it's different from the original that showed the
bug.
Nevertheless it's useful to understand the possible nature of the bug.
It seems that if feenableexcept(FE_INEXACT) is not called
fetestexcept(FE_INEXACT) doesn't work as expected (and as C99 standard
provides).
Please note that according to documentation GNU extension
feenableexcept/fedisablexcept does not enable/disable inexact detection, but
does enable/disable inexact *trapping* via SIGFPE signal.
Here below there is a new test case that shows the wrong behaviour.
$ cat sf2.c
#define _GNU_SOURCE
#include fenv.h
#include signal.h
#include stdio.h
static void foo (int sig)
{
printf(inexact\n);
}
float __attribute__((noinline)) test (float x) {
printf(%f / %f\n, 2.0f, x);
return 2.0f / x;
}
void t()
{
volatile float x;
feclearexcept (FE_ALL_EXCEPT);
x = test (3.0f);
printf(fetestexcept(FE_INEXACT) = %d\n, fetestexcept(FE_INEXACT));
feclearexcept (FE_ALL_EXCEPT);
x = test (2.0f);
printf(fetestexcept(FE_INEXACT) = %d\n, fetestexcept(FE_INEXACT));
}
int main() {
printf(\nWith FE_INEXACT SIGFPE disabled\n);
t();
printf(\nWith FE_INEXACT SIGFPE enabled\n);
signal (SIGFPE, foo);
feenableexcept (FE_INEXACT);
t();
}
$ gcc -O2 -lm -mieee-with-inexact sf2.c
$ ./a.out
With FE_INEXACT SIGFPE disabled
2.00 / 3.00
fetestexcept(FE_INEXACT) = 0
2.00 / 2.00
fetestexcept(FE_INEXACT) = 0
With FE_INEXACT SIGFPE enabled
2.00 / 3.00
inexact
fetestexcept(FE_INEXACT) = 2097152
2.00 / 2.00
fetestexcept(FE_INEXACT) = 0
$
--
abramobagnara at tin dot it changed:
What|Removed |Added
CC||abramobagnara at tin dot it
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37581
[Bug regression/38223] segfault in glib testsuite with trunk
--- Comment #5 from dirtyepic at gentoo dot org 2009-01-24 05:53 --- Just tested again w/ r143592 with no issues. -- dirtyepic at gentoo dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38223
[Bug c++/38055] key for compilation -Wconversion
--- Comment #2 from lisp2d at lisp2d dot net 2009-01-24 06:00 ---
The niche is selected incorrectly. Basically the considerable quantity of
errors of programming is linked to implicit type conversion.
void insert(char*,char,unsigned int){..}
insert(..,..,size_t);
Example
double d = 1.0;
int i;
i = d;
correctly and necessary to write so:
double d = 1.0;
int i;
i = (int)d;
In the program text this obvious conversion will be visible.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38055
[Bug target/38952] [4.4 Regression] EH does not work.
--- Comment #7 from dave dot korn dot cygwin at gmail dot com 2009-01-24
06:23 ---
Not IRA-related, it seems, but reload-backend interaction. -fno-ira doesn't
make any difference to the generated code to calculate the frame pointer for
the jmp_buf. In a non-IRA build, pass 172r.lreg has:
(insn 49 48 51 2 (set (mem:SI (reg/f:SI 63) [0 S4 A8])
(reg/f:SI 20 frame)) 41 {*movsi_1} (nil))
and pass 173r.greg has
(insn 73 48 49 2 (set (reg:SI 1 dx)
(plus:SI (reg/f:SI 7 sp)
(const_int 80 [0x50]))) 209 {*lea_1} (nil))
(insn 49 73 51 2 (set (mem:SI (reg/f:SI 0 ax [63]) [0 S4 A8])
(reg:SI 1 dx)) 41 {*movsi_1} (nil))
and here we can see that it's reload doing the FP elimination:
Reloads for insn # 49
Reload 0: reload_out (SI) = (mem:SI (reg/f:SI 0 ax [63]) [0 S4 A8])
NO_REGS, RELOAD_FOR_OUTPUT (opnum = 0), optional
reload_out_reg: (mem:SI (reg/f:SI 0 ax [63]) [0 S4 A8])
Reload 1: reload_in (SI) = (plus:SI (reg/f:SI 7 sp)
(const_int 80 [0x50]))
GENERAL_REGS, RELOAD_FOR_INPUT (opnum = 1)
reload_in_reg: (plus:SI (reg/f:SI 7 sp)
(const_int 80 [0x50]))
reload_reg_rtx: (reg:SI 1 dx)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38952
[Bug fortran/38956] test gfortran.dg/chmod_1.f90 fails on i686-pc-cygwin
--- Comment #2 from billingd at gcc dot gnu dot org 2009-01-24 07:41
---
This looks like a problem with the access function on cygwin-1.7
$ touch foobar_file
$ chmod a-w foobar_file
$ cat test_access.c
#include stdio.h
#include unistd.h
int main (void) {
char *file=foobar_file;
int m = W_OK;
printf(access = %d\n,access(file,m));
}
$ touch foobar_file
$ chmod a-w foobar_file
Under cygwin-1.5
$ ./test_access
access = -1
Under cygwin-1.7
$ ./test_access.exe
access = -1
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38956
