[Bug preprocessor/33415] Can't compile .cpp file with UTF-8 BOM.

2007-09-14 Thread pinskia at gcc dot gnu dot org 


--- Comment #2 from pinskia at gcc dot gnu dot org  2007-09-14 09:28 ---
Actually I already know this is not handled.  In fact any of the BOMs are not
handled.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|WAITING |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-09-14 09:28:32
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33415

[Bug fortran/33430] New: Improve -finit-*: Initialization of derived types, equivalenced variables

2007-09-14 Thread burnus at gcc dot gnu dot org 
The following features are missing from the current version of the -finit-*
patch (PR 20441):

- Optional initialization of INTENT(OUT) variables: PR 31447

- Derived types are not initialized; there are two cases:
  (a) no initializer, (b) initializer which initializes not all variables

- Equivalenced variables: g77 initialized them with -finit-local-zero. The
challenge is of cause if the variables have different types and
-finit-real/-finit-integer etc. is used instead of -finit-local-zero.


-- 
   Summary: Improve -finit-*: Initialization of derived types,
equivalenced variables
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
 BugsThisDependsOn: 20441


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33430

[Bug fortran/31447] set intent(out) arguments to uninitialized

2007-09-14 Thread burnus at gcc dot gnu dot org 


--- Comment #2 from burnus at gcc dot gnu dot org  2007-09-14 09:53 ---
Initializing INTENT(OUT) variables should not be the default with
-finit-local-zero; otherwise I'm in favour of this option.

See also PR 33430 for other omissions of the -finit-* patch (cf. PR 20441).


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu dot
   ||org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31447

[Bug fortran/33430] Improve -finit-*: Initialization of derived types, equivalenced variables

2007-09-14 Thread burnus at gcc dot gnu dot org 


--- Comment #1 from burnus at gcc dot gnu dot org  2007-09-14 09:55 ---
... and of cause:

- Signalling NaN (sNaN) should be supported as well.
(mpfr currently only supports qNaN - last not least as IEEE 754 does not
specify the bitpattern for sNaN/qNaN; IEEE 754r does, but it has not been
accepted yet.)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33430

[Bug target/33431] New: [SH4] performance regression between 3.4.6 and 4.x

2007-09-14 Thread nbkolchin at gmail dot com 
I've found serious performance regression between GCC version 3.4.6 and
4.2/4.3.

SciMark2 Numeric Benchmark, see http://math.nist.gov/scimark

   GCC: 3.4.6   4.2.1   4.3.0 (20070907)
 Composite:  6.055.014.82
   FFT:  4.904.154.21
   SOR: 10.108.367.64
MonteCarlo:  3.683.063.04
Sparse matmult:  5.454.454.03
LU:  6.105.035.18


BYTEmark* Native Mode Benchmark ver. 2 (10/95)

 GCC:  3.4.6  4.2.1  4.3.0 (20070907)
NUMERIC SORT: 35.459   32.2  29.327
 STRING SORT: 0.59430.57604  0.8603
BITFIELD: 1.0585e+07  9.269e+06  9.4138e+06
FP EMULATION: 4.4944 4.6012   5.364
 FOURIER: 272.28 241.34  259.12
  ASSIGNMENT:0.359970.38373 0.39683
IDEA: 124.11 95.057  100.07
 HUFFMAN: 45.593 52.083  56.391
  NEURAL NET:0.361530.30922 0.31348
LU DECOMPOSITION: 11.331 9.4938   8.255


The "real world application" has 20%-200% performance regression with GCC 4.x.

All tests were compiled with this arguments:
 -O3 -ffast-math -fomit-frame-pointer -funroll-loops -ftracer
 -funit-at-a-time
 -m4 -ml

This arguments were tuned for the best results under 3.4.6. I've played with
various settings under 4.x, but can't achieve any performance improvement.

I can rerun them with any key combination you want.

This tests compilable under Linux can be downloaded from:
- scimark: http://oktetlabs.ru/~snob/scimark.tgz
- nbench: http://oktetlabs.ru/~snob/nbench.tgz

I can attach this files to bugreport if this is acceptable and will not pollute
bugzilla.

Our target hardware has SH7750 processor running in little endian mode under
RTEMS. Unfortunetaly there is no way to boot linux there.

Can I ask you to run this tests under linux-sh? At least scimark one.

After lurking inside backend sources, I found that m4 has several variants in
GCC 4.x: m4-100, m4-200, etc. I've tried to compile this tests with m4-200
switch, but it looks like m4-200 enforces big-endian.

Backend sources show, that there is a lot of work going on SH4 GCC part.

I also wrote simple stupid tests to compare code generation between different
compiler versions (I can mail/attach them to you, but they are really stupid)
to
understand what can cause such performance regression. But generated assembler
is really different across versions. I can found only two obvious things:
- GCC4 has a much more aggressive inline and loop unrolling. (-funroll-loops
  was dropped from compiler arguments with no positive result)
- GCC4 has different command scheduling, which probably leads to performance
  regression.


-- 
   Summary: [SH4] performance regression between 3.4.6 and 4.x
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: nbkolchin at gmail dot com
 GCC build triplet: x86_64-unknown-linux-gnu
  GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: sh-unknown-rtemself


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33431

[Bug fortran/33432] New: g77 extension: Support for the .XOR. operator

2007-09-14 Thread burnus at gcc dot gnu dot org 
The .XOR. operator is supported by several vendor compilers including IBM's XL
fortran, DEC fortran, SUN fortran and even GNU f77!

A patch has been proposed at:

See: "[PATCH] Support .XOR. as a -std=legacy extension"
http://gcc.gnu.org/ml/fortran/2007-09/msg00070.html

The only problem is that this patch rejects (with -std=gnu/legacy) a
user-implemented .XOR., which is valid Fortran 90/95/2003.
Other compilers such as ifort and sunf95 implemented .XOR. such that by default
both the intrinsic .XOR. as also a user-implemented .XOR. work; see also
http://gcc.gnu.org/ml/fortran/2007-09/msg00082.html


-- 
   Summary: g77 extension: Support for the .XOR. operator
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Keywords: patch
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33432

[Bug target/29473] -masm=intel combined with -march=athlon64 has some issues.

2007-09-14 Thread rask at gcc dot gnu dot org 


--- Comment #11 from rask at gcc dot gnu dot org  2007-09-14 10:15 ---
Yes, that worked.
It is quite obvious from trying a bootstrap with -masm=intel that nobody ever
uses Intel syntax, because there are assorted issues around the edges.
Additionally, I'm now blocked by binutils bug gas/5034.
http://sourceware.org/bugzilla/show_bug.cgi?id=5034


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29473

[Bug libfortran/21185] libgfortran unusable for cross-testing for newlib targets

2007-09-14 Thread rask at gcc dot gnu dot org 


--- Comment #10 from rask at gcc dot gnu dot org  2007-09-14 10:42 ---
I'm testing mipsisa64-unknown-elf, sh-unknown-elf and v850-unknown-elf right
now.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21185

[Bug tree-optimization/33389] [4.3 Regression] Revision 128239 causes libgomp failure

2007-09-14 Thread jakub at gcc dot gnu dot org 


--- Comment #28 from jakub at gcc dot gnu dot org  2007-09-14 11:32 ---
Thanks, Jim.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33389

[Bug libfortran/25561] Eventually get rid of the Alloc Stream Facility

2007-09-14 Thread fxcoudert at gcc dot gnu dot org 


--- Comment #3 from fxcoudert at gcc dot gnu dot org  2007-09-14 11:33 
---
Why marking this as blocking asynchronous I/O?


-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||fxcoudert at gcc dot gnu dot
   ||org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25561

[Bug libfortran/31546] add --enable-intermodule

2007-09-14 Thread fxcoudert at gcc dot gnu dot org 


--- Comment #8 from fxcoudert at gcc dot gnu dot org  2007-09-14 11:37 
---
Wasn't the patch for this approved?
(http://gcc.gnu.org/ml/fortran/2007-08/msg00517.html) Since stage3 has started,
it probably would be best to commit rather soon.


-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||fxcoudert at gcc dot gnu dot
   ||org
 AssignedTo|unassigned at gcc dot gnu   |aldot at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31546

[Bug target/33431] [SH4] performance regression between 3.4.6 and 4.x

2007-09-14 Thread kkojima at gcc dot gnu dot org 


--- Comment #1 from kkojima at gcc dot gnu dot org  2007-09-14 11:46 ---
I've run scimark on my box:
sh4-unknown-linux-gnu / linux-kernel 2.6.22-rc4 / SH7751R

with -O3 -ffast-math -fomit-frame-pointer -funroll-loops -ftracer
-funit-at-a-time:

   gcc-3.4.6gcc-4.2.1gcc-4.3.0(20070910)
Composite Score:   16.7616.8616.99
FFT  Mflops:12.9213.3613.36
SOR  Mflops:27.8826.7628.01
MonteCarlo:Mflops: 9.96 9.73 9.67
Sparse matmult Mflops:14.9516.0614.84
LU   Mflops:18.0818.3919.05

Hmm... I can't reproduce the regression in linux-sh, at least
for SH7751R.


-- 

kkojima at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||kkojima at gcc dot gnu dot
   ||org
Summary|[SH4] performance regression|[SH4] performance regression
   |between 3.4.6 and 4.x   |between 3.4.6 and 4.x


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33431

[Bug libfortran/21881] Array descriptors limit derived type sizes

2007-09-14 Thread fxcoudert at gcc dot gnu dot org 


--- Comment #4 from fxcoudert at gcc dot gnu dot org  2007-09-14 11:31 
---
I think this is related to the check in trans-types.c:

  if (size && INTEGER_CST_P (size))
{
  if (tree_int_cst_lt (gfc_max_array_element_size, size))
internal_error ("Array element size too big");

  i += TREE_INT_CST_LOW (size) << GFC_DTYPE_SIZE_SHIFT;
}
  dtype = build_int_cst (gfc_array_index_type, i);

which is triggered by code such as:

  type t
integer i001(268435456)
  end type t

  type(t), allocatable :: x(:)

  allocate(x(1))
  print *, size(x)
  print *, shape(x)
  end


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21881

[Bug tree-optimization/33434] New: [4.3 Regression] -fipa-cp miscompilation

2007-09-14 Thread belyshev at depni dot sinp dot msu dot ru 
Found this while trying to bootstrap with BOOT_CFLAGS="-O3 -fipa-cp" and it
miscompiled libcpp/macro.c at the stage2.  Appeared somewhere in between
r122374 and r124593:

/* { dg-do run } */
/* { dg-options "-O3 -fipa-cp" } */

int k;

void f1 (int a, int b)
{
  if (a)
while (b --)
  k = 1;
  else
if (b != 1)
  __builtin_abort ();
}

int main (void)
{
  f1 (1, 1);
  if (k != 1)
__builtin_abort ();
  return 0;
}


-- 
   Summary: [4.3 Regression] -fipa-cp miscompilation
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: belyshev at depni dot sinp dot msu dot ru


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33434

[Bug libfortran/21185] libgfortran unusable for cross-testing for newlib targets

2007-09-14 Thread hp at gcc dot gnu dot org 


--- Comment #11 from hp at gcc dot gnu dot org  2007-09-14 12:10 ---
(In reply to comment #9)
> Patch submitted at http://gcc.gnu.org/ml/gcc-patches/2007-09/msg01219.html. 
> I'd
> be glad if some with access to cris-axis-elf

I'll test that.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21185

[Bug c++/33435] New: internal compiler error with templates and openmp

2007-09-14 Thread E dot Kuemmerle at fz-juelich dot de 
I get the error message

bug.cpp:16: internal compiler error: in create_tmp_var, at gimplify.c:487

when compiling the following code with

g++ -fopenmp -DTVMET_OPTIMIZE -c bug.cpp

where bug.cpp contains:

#include// Tiny Vector Matrix library using
Expression Templates
#include   // http://tvmet.sourceforge.net/
using namespace tvmet;

int main() {
  Vector a[10];
  int i;
#pragma omp parallel
  {
#pragma omp for schedule(dynamic)
for (i=0; i<10; ++i) {
  // do something
}
#pragma omp master
{
a[0] = a[1];
}
#pragma omp for schedule(dynamic)
for (i=0; i<10; ++i) {
  // do something
}
  }
}

The problem is definitely related to openmp because the following code compiles
without any error:

#include// Tiny Vector Matrix library using
Expression Templates
#include   // http://tvmet.sourceforge.net/
using namespace tvmet;

int main() {
  Vector a[10];
  int i;
#pragma omp parallel for schedule(dynamic)
  for (i=0; i<10; ++i) {
// do something
  }
  a[0] = a[1];
#pragma omp parallel for schedule(dynamic)
  for (i=0; i<10; ++i) {
// do something
  }
}


-- 
   Summary: internal compiler error with templates and openmp
   Product: gcc
   Version: 4.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: E dot Kuemmerle at fz-juelich dot de
 GCC build triplet: x86_64-linux-gnu
  GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33435

[Bug libfortran/21185] libgfortran unusable for cross-testing for newlib targets

2007-09-14 Thread rask at gcc dot gnu dot org 


--- Comment #12 from rask at gcc dot gnu dot org  2007-09-14 13:12 ---
Testing on v850-unknown-elf suggests that getcwd() is also needed by
libgfortran.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21185

[Bug libfortran/21185] libgfortran unusable for cross-testing for newlib targets

2007-09-14 Thread hp at gcc dot gnu dot org 


--- Comment #13 from hp at gcc dot gnu dot org  2007-09-14 13:19 ---
Sorry, build fails for cris-elf with:
libtool: compile:  /home/hp/combe/cris-regobj/./gcc/xgcc
-B/home/hp/combe/cris-regobj/./gcc/ -nostdinc -B/home/hp/combe/cris-rego\
bj/cris-unknown-elf/newlib/ -isystem
/home/hp/combe/cris-regobj/cris-unknown-elf/newlib/targ-include -isystem
/home/hp/combe/comb\
ined/newlib/libc/include
-B/home/hp/combe/cris-regobj/cris-unknown-elf/libgloss/cris
-L/home/hp/combe/cris-regobj/cris-unknown-el\
f/libgloss/libnosys -L/home/hp/combe/combined/libgloss/cris
-B/tmp/reg-cris/cris-unknown-elf/bin/ -B/tmp/reg-cris/cris-unknown-el\
f/lib/ -isystem /tmp/reg-cris/cris-unknown-elf/include -isystem
/tmp/reg-cris/cris-unknown-elf/sys-include -L/home/hp/combe/cris-\
regobj/./ld -DHAVE_CONFIG_H -I. -I/home/hp/combe/combined/libgfortran -I.
-iquote/home/hp/combe/combined/libgfortran/io -I/home/h\
p/combe/combined/libgfortran/../gcc
-I/home/hp/combe/combined/libgfortran/../gcc/config -I../.././gcc -D_GNU_SOURCE
-std=gnu99 -W\
all -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wextra
-Wwrite-strings -O2 -g -O2 -MT unix.lo -MD -MP -MF .d\
eps/unix.Tpo -c /home/hp/combe/combined/libgfortran/io/unix.c -o unix.o
/home/hp/combe/combined/libgfortran/io/unix.c:1794: error: static declaration
of 'access' follows non-static declaration
/home/hp/combe/combined/newlib/libc/include/sys/unistd.h:19: error: previous
declaration of 'access' was here
/home/hp/combe/combined/libgfortran/io/unix.c: In function 'access':
/home/hp/combe/combined/libgfortran/io/unix.c:1795: error: 'amod' undeclared
(first use in this function)
/home/hp/combe/combined/libgfortran/io/unix.c:1795: error: (Each undeclared
identifier is reported only once
/home/hp/combe/combined/libgfortran/io/unix.c:1795: error: for each function it
appears in.)
/home/hp/combe/combined/libgfortran/io/unix.c:1793: warning: unused parameter
'amode'
make[5]: *** [unix.lo] Error 1
make[5]: Leaving directory
`/home/hp/combe/cris-regobj/cris-unknown-elf/libgfortran'

Besides the obvious s/amod/amode/ typo, maybe use a different name for the
internal function, and
#ifndef HAVE_ACCESS
... libgfortran_access implementation
#else
#define libgfortran_access access
#endif
to avoid problems with the access prototype.

I'm testing such an updated patch.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21185

[Bug libfortran/21185] libgfortran unusable for cross-testing for newlib targets

2007-09-14 Thread hp at gcc dot gnu dot org 


--- Comment #14 from hp at gcc dot gnu dot org  2007-09-14 13:22 ---
(In reply to comment #13)
Oops, I mean:
#ifndef HAVE_ACCESS
... libgfortran_access implementation
#undef access
#define access libgfortran_access
#endif


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21185

[Bug libfortran/21185] libgfortran unusable for cross-testing for newlib targets

2007-09-14 Thread fxcoudert at gcc dot gnu dot org 


--- Comment #15 from fxcoudert at gcc dot gnu dot org  2007-09-14 13:38 
---
Created an attachment (id=14208)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14208&action=view)
Updated patch

(In reply to comment #13)
> /home/hp/combe/combined/libgfortran/io/unix.c:1794: error: static declaration
> of 'access' follows non-static declaration
> /home/hp/combe/combined/newlib/libc/include/sys/unistd.h:19: error: previous
> declaration of 'access' was here

Oh, you have a prototype for access() in standard headers but no function in
the libc? That's weird! Embedded targets will always surprise me.

> Besides the obvious s/amod/amode/ typo

Hum, how did that even get past my testing? I thought I had commented out
HAVE_ACCESS on my x86_64-linux.

> maybe use a different name for the internal function

Yup, you're right (the second version). I'm attaching an updated patch that
should do the same thing you did.

(In reply to comment #12)
> Testing on v850-unknown-elf suggests that getcwd() is also needed by
> libgfortran.

Also fixed in the attached new patch.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21185

[Bug libfortran/21185] libgfortran unusable for cross-testing for newlib targets

2007-09-14 Thread rask at gcc dot gnu dot org 


--- Comment #16 from rask at gcc dot gnu dot org  2007-09-14 13:43 ---
I get the same build failure on sh-unknown-elf and mipsisa64-unknown-elf. I'm
continuing without the static keyword and with s/amod/amode/g.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21185

[Bug libfortran/21185] libgfortran unusable for cross-testing for newlib targets

2007-09-14 Thread hp at gcc dot gnu dot org 


--- Comment #17 from hp at gcc dot gnu dot org  2007-09-14 14:13 ---
(In reply to comment #14)
The build succeeds with my locally fixed version.
We'll see whether the test-results are meaningful; it's likely there's more to
fix.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21185

[Bug middle-end/33436] New: Bad constant output with TARGET_ASM_ALIGNED_DI_OP

2007-09-14 Thread danglin at gcc dot gnu dot org 
Executing on host: /mnt/gnu/gcc/objdir/gcc/xgcc -B/mnt/gnu/gcc/objdir/gcc/
/mnt/
gnu/gcc/gcc/gcc/testsuite/gcc.dg/pr32912-2.c   -O2 -w -fno-show-column  -lm  
-o
 ./pr32912-2.exe(timeout = 300)
/var/tmp//cclFD5RH.s: Assembler messages:
/var/tmp//cclFD5RH.s:5: Warning: bignum truncated to 8 bytes
output is:
/var/tmp//cclFD5RH.s: Assembler messages:
/var/tmp//cclFD5RH.s:5: Warning: bignum truncated to 8 bytes

FAIL: gcc.dg/pr32912-2.c (test for excess errors)
Excess errors:
/var/tmp//cclFD5RH.s:5: Warning: bignum truncated to 8 bytes

Setting LD_LIBRARY_PATH to :/mnt/gnu/gcc/objdir/gcc::/mnt/gnu/gcc/objdir/gcc
FAIL: gcc.dg/pr32912-2.c execution test

.LEVEL 2.0w
.section.rodata
.align 8
L$C:
.dword  0x
...

Mainline is ok.


-- 
   Summary: Bad constant output with TARGET_ASM_ALIGNED_DI_OP
   Product: gcc
   Version: 4.2.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: danglin at gcc dot gnu dot org
 GCC build triplet: hppa64-hp-hpux11.11
  GCC host triplet: hppa64-hp-hpux11.11
GCC target triplet: hppa64-hp-hpux11.11


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33436

[Bug ada/33392] ACATS cxa5a09, cxa5a10 and controlled2.adb failure

2007-09-14 Thread anhvofrcaus at gmail dot com 


--- Comment #5 from anhvofrcaus at gmail dot com  2007-09-14 15:16 ---
Yes, you are absolutely correct that my tree is skewed. After updating my tree
again, all ACATS tests passed beautifully. One more thing to say you guys are
fantastic.

AV


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33392

[Bug c/33437] New: potentially valid construct rejected

2007-09-14 Thread jbeulich at novell dot com 
extern char x[] __attribute__((__weak__));
int i = (long)x;

results in 'initializer element is not computable at load time'. However, the
compiler really can't know this, as x may be either zero (since it's weak) or
may be used as C-level place holder for an assembler/linker defined absolute
symbol. While emitting a warning here (that should have a control for
suppressing) seems appropriate, failing the compilation isn't - that decision
should be left to the assembler (in case the target doesn't have an
appropriately sized relocation type) or the linker.


-- 
   Summary: potentially valid construct rejected
   Product: gcc
   Version: 4.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jbeulich at novell dot com
 GCC build triplet: x86_64-linux-gnu
  GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33437

[Bug rtl-optimization/26449] [4.2/4.3 Regression] ICE in loop invariant motion

2007-09-14 Thread rakdver at gcc dot gnu dot org 


--- Comment #20 from rakdver at gcc dot gnu dot org  2007-09-14 15:57 
---
(In reply to comment #19)
> Zdenek, the fix in Comment #5 is wrong (please look at Comment #11 why), as
> cofirmed by a couple of dupes. From PR 33428:

actually the fix in loop-invariant is correct for the original problem (where
expand_simple_binop fails and returns NULL_RTX).


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26449

[Bug target/33431] [SH4] performance regression between 3.4.6 and 4.x

2007-09-14 Thread nbkolchin at gmail dot com 


--- Comment #2 from nbkolchin at gmail dot com  2007-09-14 16:10 ---
Thank you for your reply. 

Variants:
- you are not using: "-m4 -ml", but some other architecture settings.
- SH7751R and SH7750R have different instruction pipeline (probably not, both 
  are SH4-200 variants as I know).
- gcc for linux is different from gcc for RTEMS (how this can be checked?)
- processor endians are different.


-- 

nbkolchin at gmail dot com changed:

   What|Removed |Added

 CC||nbkolchin at gmail dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33431

[Bug debug/33429] debug info for class2 in g++.dg/other/unused1.C requires -femit-class-debug-always

2007-09-14 Thread pinskia at gcc dot gnu dot org 


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |spark at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33429

[Bug target/33438] New: [4.3 Regression] ICE in cselib_record_set, at cselib.c:1515 on x86

2007-09-14 Thread belyshev at depni dot sinp dot msu dot ru 
Compile with -O1:

long double f (long double x)
{
  return __builtin_remainderl (x, x);
}

bug.c: In function 'f':
bug.c:4: internal compiler error: in cselib_record_set, at cselib.c:1515


-- 
   Summary: [4.3 Regression] ICE in cselib_record_set, at
cselib.c:1515 on x86
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: belyshev at depni dot sinp dot msu dot ru
GCC target triplet: x86_64-*-*, i?86-*-*


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33438

[Bug target/33438] [4.3 Regression] ICE in cselib_record_set, at cselib.c:1515 on x86

2007-09-14 Thread pinskia at gcc dot gnu dot org 


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org
   Target Milestone|--- |4.3.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33438

Couldn't install GCC properly in my cygwin!

2007-09-14 Thread poovizhi 

Hello,
I've CYGWIN_NT-5.0 (1.3.22) version installed in my system. Here I try to
install a fresh GCC version (GCC-3.4.6). But I don't have already any
compiled version of GCC in my system. So I took GCC-3.4.6 tarballs from the
recommended GNU source. Downloaded properly. As a first step, when I do
"configure" for native compiler I get the following error.

../gcc-3.4.6/configure --prefix=/opt/gcc-3.4.6  
  
loading cache ./config.cache
checking host system type... i686-pc-cygwin
checking target system type... i686-pc-cygwin
checking build system type... i686-pc-cygwin
checking for a BSD compatible install... /bin/install -c
*** This configuration is not supported in the following subdirectories:
 target-libffi target-boehm-gc target-zlib target-libjava
(Any other directories should still work fine.)
gcc: installation problem, cannot exec `cc1': No such file or directory
*** The command 'gcc -o conftest -O2   conftest.c' failed.
*** You must set the environment variable CC to a working compiler.

1. To set environment variable tried all the posibities as mentioned in this
link
http://forums.fedoraforum.org/archive/index.php/t-207.html

2. Then to avoid subdirectories problem I tried the following and got the
error mentioned like above
../gcc-3.4.6/configure --prefix=/opt/gcc-3.4.6 --verbose
--enable-languages=c --disable-libgcj

3. Tried downloading pre compiled RPM version of GCC-3.3.3-1 to rectify the
Set Env to CC working directory problem
Here downloaded RPM version but don't have RPM installed in my system. So
went to setup the RPM tool in my system. Downloaded this tool and did untar,
but no luck, still RPM command is not working. But there is a RPM.exe etc.
So when I search the solution for this, I found "There should be a proper
GCC compiler to get this RPM tool to be installed propely" 

Somehow I'm in dead lock condition. Please help me to rectify this problem.
My ultimate aim is to install proper GCC compiler in my cygwin system when
there is no existing working compiler.

Really tried so much to solve this problem, couldn't. Finally come to you
guys to get an advanced mind.

Help me ! Thanks in advance!

Regards, Poovizhi
-- 
View this message in context: 
http://www.nabble.com/Couldn%27t-install-GCC-properly-in-my-cygwin%21-tf080.html#a12680112
Sent from the gcc - bugs mailing list archive at Nabble.com.

[Bug fortran/33439] New: Incorrect error message for chunksize variable

2007-09-14 Thread longb at cray dot com 
The GNU compiler is asking that when a default(none)
clause is present on the OMP PARALLEL DO, and a chunk-size expression (in this
case just the variable fsize) appears in a schedule clause, that the variable
must appear in a shared or private clause.  Other compilers (PGI, Pathscale) do
not require that this be done.

I cannot find a justification for requiring that fsize be listed in a
private or shared clause.  It is referenced before the construct begins
execution, but not within the construct itself.  Admittedly, the OpenMP 2.5 
spec is a bit weak on scoping rules in this case, but the text at page 63 lines
25-28 hints to me that a variable that appears in a schedule clause is not
automatically a reference.  The text on page 36 lines 1-19 says that IF the
variable is declared private then the value used is not the private copy but
rather the value of the version external to the construct.  Again this
suggests that the variable in the schedule clause is outside the scope
of the construct.

> gfortran -c -fopenmp test.f90
test.f90: In function 'MAIN__':
test.f90:16: error: 'fsize' not specified in enclosing parallel
test.f90:16: error: enclosing parallel

> cat test.f90
program OMP_program
! derived from ISU's RTED_OpenMP/FORTRAN/SECTION_C/F_C_3_2_a.f90
!RTED_OpenMP/FORTRAN/SECTION_C/F_C_3_2_d.f90
  integer, parameter ::  nt=4
  double precision :: s,tmp
  double precision :: ARR(100)
  integer :: fsize,i

  call omp_set_num_threads(nt)
  s = 0.d0
  arr = 1.0d0
  tmp = 4.d0*atan(1.d0)
  fsize = int(sin(-0.25*tmp)*10.0)
  write(*,*) 'tmp, fsize',tmp, fsize

!$omp parallel do  default(none) shared(arr) private(i) reduction(+:s)
schedule(static,fsize)
  do i=1,100
 s = s + arr(i)
  end do
!$omp end parallel do

  print *,'s =', s

end program OMP_program


-- 
   Summary: Incorrect error message for chunksize variable
   Product: gcc
   Version: 4.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: longb at cray dot com
 GCC build triplet: x86_64-suse-linux
  GCC host triplet: x86_64-suse-linux
GCC target triplet: x86_64-suse-linux


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33439

[Bug target/33406] [4.3 Regression] At revision 128385 Bootstraping PPC Darwin still fail in Java

2007-09-14 Thread howarth at nitro dot med dot uc dot edu 


--- Comment #6 from howarth at nitro dot med dot uc dot edu  2007-09-14 
18:00 ---
Is anyone working on this bug? I ask because Apple's regress server has
effectively stopped showing testresults because of this bug. Also, I am a tad
confused by the comments that -enable-checking is now used. Does this imply
that this bug has been latent in prior gcc releases and that the new default
use of -enable-checking has exposed it? Also would I be able to suppress this
problem with --disable-checking? I was hoping to test the new vectorization
changes in gcc branch without disabling the java build on powerpc Darwin.
Lastly, if this is the same bug that is breaking the libgomp build on powerpc64
linux, those testresults are now all being posted with libgomp disabled.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33406

[Bug bootstrap/21335] [meta-bug] bootstrap fails with -ftree-vectorize

2007-09-14 Thread dorit at gcc dot gnu dot org 


--- Comment #7 from dorit at gcc dot gnu dot org  2007-09-14 18:49 ---
(In reply to comment #6)
> I can bootstrap current trunk (r128479) with -ftree-vectorize on
> x86_64-unknown-linux-gnu for some time now, and, according to
> http://gcc.gnu.org/ml/gcc-patches/2007-09/msg00327.html, this problem is gone
> on powerpc64 too.

actually the link you give above explicitly states that "we don't pass
bootstrap with vectorization enabled on powerpc-linux", but there's already a
PR for that (PR32582) so it's ok to close this one

> So closing as fixed.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21335

[Bug tree-optimization/33373] [4.3 Regression] ICE in vectorizable_type_demotion, at tree-vect-transform.c:4098

2007-09-14 Thread belyshev at depni dot sinp dot msu dot ru 


--- Comment #4 from belyshev at depni dot sinp dot msu dot ru  2007-09-14 
19:15 ---
Very similar testcase with the difference that it is not fixed by r128415 and
makes current trunk segfault in VEC_tree_base_pop():

void f (unsigned int *d, unsigned int *s, int w)
{
  int i;
  for (i = 0; i < w; ++i)
d [i] = s [i] * (unsigned short) (~d [i] >> 24);
}


-- 

belyshev at depni dot sinp dot msu dot ru changed:

   What|Removed |Added

 CC||belyshev at depni dot sinp
   ||dot msu dot ru
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
  GCC build triplet|x86_64-unknown-linux-gnu|
   GCC host triplet|x86_64-unknown-linux-gnu|
 GCC target triplet|i586-unknown-linux-gnu  |
   Last reconfirmed|-00-00 00:00:00 |2007-09-14 19:15:21
   date||
Summary|ICE in  |[4.3 Regression] ICE in
   |vectorizable_type_demotion, |vectorizable_type_demotion,
   |at tree-vect-   |at tree-vect-
   |transform.c:4098|transform.c:4098
   Target Milestone|--- |4.3.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33373

[Bug target/33438] [4.3 Regression] ICE in cselib_record_set, at cselib.c:1515 on x86

2007-09-14 Thread ubizjak at gmail dot com 


--- Comment #2 from ubizjak at gmail dot com  2007-09-14 19:27 ---
Fixed.


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33438

[Bug target/33438] [4.3 Regression] ICE in cselib_record_set, at cselib.c:1515 on x86

2007-09-14 Thread uros at gcc dot gnu dot org 


--- Comment #1 from uros at gcc dot gnu dot org  2007-09-14 19:24 ---
Subject: Bug 33438

Author: uros
Date: Fri Sep 14 19:24:26 2007
New Revision: 128502

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=128502
Log:
PR target/33438
* config/i386/i386.md (fmodxf3): Copy operands[2] to temporary register
when operands[2] equals operands[1].
(remainderxf3): Ditto.

testsuite/ChangeLog:

PR target/33438
* gcc.target/i386/pr33438.c: New test.


Added:
trunk/gcc/testsuite/gcc.target/i386/pr33483.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.md
trunk/gcc/testsuite/ChangeLog


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33438

[Bug tree-optimization/33373] [4.3 Regression] ICE in vectorizable_type_demotion, at tree-vect-transform.c:4098

2007-09-14 Thread dorit at gcc dot gnu dot org 


--- Comment #5 from dorit at gcc dot gnu dot org  2007-09-14 20:53 ---
(In reply to comment #4)
> Very similar testcase with the difference that it is not fixed by r128415 and
> makes current trunk segfault in VEC_tree_base_pop():
> void f (unsigned int *d, unsigned int *s, int w)
> {
>   int i;
>   for (i = 0; i < w; ++i)
> d [i] = s [i] * (unsigned short) (~d [i] >> 24);
> }

this should fix it:

Index: tree-vect-transform.c
===
*** tree-vect-transform.c   (revision 128501)
--- tree-vect-transform.c   (working copy)
*** vect_get_vec_defs_for_stmt_copy (enum ve
*** 1938,1944 
vec_oprnd = vect_get_vec_def_for_stmt_copy (dt[0], vec_oprnd);
VEC_quick_push (tree, *vec_oprnds0, vec_oprnd);

!   if (vec_oprnds1)
  {
vec_oprnd = VEC_pop (tree, *vec_oprnds1);
vec_oprnd = vect_get_vec_def_for_stmt_copy (dt[1], vec_oprnd);
--- 1938,1944 
vec_oprnd = vect_get_vec_def_for_stmt_copy (dt[0], vec_oprnd);
VEC_quick_push (tree, *vec_oprnds0, vec_oprnd);

!   if (vec_oprnds1 && *vec_oprnds1)
  {
vec_oprnd = VEC_pop (tree, *vec_oprnds1);
vec_oprnd = vect_get_vec_def_for_stmt_copy (dt[1], vec_oprnd);

(and by the way, I think this is a totally different issue than what this PR
was originally opened for, and should be a separate PR. I think this regression
is due to r128289)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33373

[Bug libfortran/21185] libgfortran unusable for cross-testing for newlib targets

2007-09-14 Thread hp at gcc dot gnu dot org 


--- Comment #18 from hp at gcc dot gnu dot org  2007-09-14 21:31 ---
(In reply to comment #17)
> We'll see whether the test-results are meaningful; it's likely there's more to
> fix.

Unfortunately not very meaningful without a getcwd.  I got curious why getcwd
would be needed, so I looked around, and it seems the stored absolute exe path
is only reachable by full_exe_path(), called only from
runtime/backtrace.c:show_backtrace()
- which is #if GLIBC_BACKTRACE'd out; empty for newlib targets!
So, I'll update your patch to get rid of the getcwd call, attach the result and
start a new test.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21185

[Bug libfortran/21185] libgfortran unusable for cross-testing for newlib targets

2007-09-14 Thread hp at gcc dot gnu dot org 


--- Comment #19 from hp at gcc dot gnu dot org  2007-09-14 21:36 ---
(In reply to comment #18)
> So, I'll update your patch to get rid of the getcwd call, attach the result 
> and
> start a new test.

Never mind, I see you've taken care of it in the access_dup2 patch here. Doh!
Starting test...


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21185

[Bug target/33431] [SH4] performance regression between 3.4.6 and 4.x

2007-09-14 Thread kkojima at gcc dot gnu dot org 


--- Comment #3 from kkojima at gcc dot gnu dot org  2007-09-14 22:10 ---
-ml and -m4 are default on sh4-unknown-linux-gnu compilers.
For 4.3.0, you could see how the default target specific options
are set with 'cc1 --target-help'.  I've got the following result
on my linux box.  You can compare it with your RETMS's one.

The following options are target specific:
  -m4   [enabled]
  -m4-100   [disabled]
  -m4-200   [disabled]
  -m4-300   [disabled]
  -m4a  [disabled]
  -mb   [disabled]
  -mbigtable[disabled]
  -mbranch-cost=0x
  -mcbranchdi   [enabled]
  -mcmpeqdi [disabled]
  -mcut2-workaround [disabled]
  -mdalign  [disabled]
  -mdiv=
  -mdivsi3_libfunc=
  -mexpand-cbranchdi[enabled]
  -mfused-madd  [disabled]
  -mgettrcost=  0x
  -mglibc   [enabled]
  -mhitachi [disabled]
  -mieee[disabled]
  -minline-ic_invalidate[disabled]
  -misize   [disabled]
  -ml   [enabled]
  -mnomacsave   [disabled]
  -mpadstruct   [disabled]
  -mprefergot   [disabled]
  -mpretend-cmove   [disabled]
  -mrelax   [disabled]
  -mrenesas [disabled]
  -mspace   [disabled]
  -muclibc  [disabled]
  -multcost=0x
  -musermode[enabled]


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33431

[Bug c/33440] New: gcc-compiled program possibly reporting wrong variable address to gdb

2007-09-14 Thread sethdgrover at gmail dot com 
Environment:
gcc (GCC) 4.1.2 (Ubuntu 4.1.2-0ubuntu4) from Ubuntu repositories
Ubuntu 7.04 2.6.20-16-generic kernel
GNU gdb 6.6-debian

I run this program in GDB, and put a breakpoing right before the call to
whatever(). At this point, I print "a", and the value is no good, but the
variable is uninitialized so that's expected. However, after the other
statements which set the value of "a", printing "a" still show the
uninitialized value.

This was compiled simply using "gcc -g test.c" and run using "gdb ./a.out".

=== test.c ===
int
main (
  int argc,
  char *argv[])
{
  int a;

  void whatever ()
  {
a = 123;
  }

  whatever();
  a = 321;

  return 0;
}
==

It looks like gdb decodes the address as 4 bytes too low, gcc says its location
is DW_OP_fbreg -16. I don't know if this is a gdb or a gcc problem, but from
what I've been told a variable not updating is almost always a compiler bug.
I've also submitted the issue to gdb's bugtracking system
(http://sourceware.org/cgi-bin/gnatsweb.pl) as issue 2319.

Thanks,

Seth Grover


-- 
   Summary: gcc-compiled program possibly reporting wrong variable
address to gdb
   Product: gcc
   Version: 4.1.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sethdgrover at gmail dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33440

[Bug debug/33440] gcc-compiled program possibly reporting wrong variable address to gdb

2007-09-14 Thread pinskia at gcc dot gnu dot org 


--- Comment #1 from pinskia at gcc dot gnu dot org  2007-09-14 22:57 ---
This works for me on the trunk with gdb 6.3-debian.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33440

Re: Couldn't install GCC properly in my cygwin!

2007-09-14 Thread Jim Wilson 

poovizhi wrote:

I've CYGWIN_NT-5.0 (1.3.22) version installed in my system. Here I try to
install a fresh GCC version (GCC-3.4.6). But I don't have already any
compiled version of GCC in my system.


If you don't already have a compiler, then you won't be able to compile 
the gcc sources on your cygwin system.  Download a gcc binary from the 
www.cygwin.com site.  See the docs on this site for more info.


Jim

Haunted Halloween fun at Mountain Village 1890!

2007-09-14 Thread Mountain Village 1890 

Central Arkansas Society for Paranormal Research

http://www.casprquest.com/privateten.htm

Haunted Mountain Village 1890

http://www.1890village.com/

Mountain Village 1890
Bull Shoals Caverns
1011 C. S. Woods Boulevard
P. O. Box 444
Bull Shoals, Arkansas 72619
Phone: (870) 445-7177
Toll free: (800) 445-7177

As quoted from their web site:  "Mountain Village 1890, an historic re-creation of 
an Ozark settlement, is a living tribute to the pioneers who first settled this remote 
part of the country. These were hardy men and women who followed the trails into our 
mountains from the Carolinas, Virginia, Tennessee and Georgia. The village is a Bull 
Shoals, Arkansas, attraction that draws families, particularly those interested in local 
or living history, from across the United States."

Find out more by visiting the village at www.1890village.com

Current Sightings and Experiences:

The 1890s Village was bought in October, 2006 by the Oates family and is 
currently under the management of siblings, David, Steve, and Ginger. Steve's 
girlfriend and bride to be, Stephanie, helps with day to day operations as well.

The family is from Tampa, Florida, and had no idea that the Village and Caverns 
they just purchased were inhabited by ghostly spirits. Each one was equally 
surprised by their own personal encounters with the paranormal on the grounds, 
inside the buildings and even inside the ancient caverns.  Finally, after many 
unexplainable experiences, they called in our team of investigators to validate 
the hauntings.

As related to CASPR investigators, all of the owners and employees experience what they 
call a sense of being "watched" as if someone is standing right behind them. 
Many people have reported seeing ghostly figures dressed in Civil War uniforms as well as 
dark, shadowy figures that disappear when you turn to look directly at them.

Steve said, "I was in the back of the cave in Diamond Chapel sweeping water out the back gate 
when I heard a voice in the room say "what are you doing?"  I looked around and I was 
thinking that Marvin was in there or some of the kids that were coming for a field trip that day, 
so I didn't think much of it at the moment and kept on sweeping. Then, I started hearing 
whisperings, kind of like mumblings and murmurings and thought the kids were coming in.  I went out 
of the cave and all the way to the top of the hill before I saw anyone.  At that time I was getting 
very anxious and nervous and called up everyone to see where they were, to see if anyone was 
playing a joke on me. Marvin and Ginger were up front in the Depot talking with the kids so I had 
been all alone in the cave."

Ginger Oates said, "Around midnight a few weeks ago, we (she and brothers, Steve and 
David) noticed that one of the shutters had come open on the Jordan house. Steve said 
that was odd and shouldn't have happened. We had a flashlight so we walked over there to 
check it out.  Just a few feet away from the shutter, we heard laughter. I thought the 
guys were cutting up, but it wasn't them. Whatever this thing was seemed to be right 
behind us, the laughter was very loud, and it just seemed like another person was in the 
room.  It didn't feel sinister at all.  It sounded like a young person, but you couldn't 
really tell if it was a young girl or boy. Something was definitely in there with 
us."

David Oates had a slightly different experience that night in the Jordan house, 
which is not unusual with paranormal occurrences. CASPR has discovered that 
although a group of people may all hear or feel the same unexplainable event, 
some come away with more of an experience than others.

David said, "The first thing I heard that night in the Jordan house was a very loud, 
heavy sigh.  Then came the child-like laughter.  It didn't feel threatening at all."

Equipment Used:

6 Super Night Shot Video Cameras

5 DVR's (Digital Voice Recorders)

6 Digital Cameras and EMF Meters

Reported Sightings and Experiences:

The Church:

Upon arrival, CASPR Director, Karen went to the church to set up her video 
equipment. She took out her Gauss EMF meter and began to sweep the pews and 
pulpit area.  Nothing registered, then, as she moved to the other side of the 
church, her EMF detector went off while sweeping it across one of the pews.  
The meter chirped loudly, then silenced as she moved to the right.  
Immediately, upon hearing the tone, she swept back across the same area and it 
sounded off again.  Then, it was gone.  She says that it was as if someone 
unseen was sitting in the pew. There is no electricity in the church and later 
an extension cord was run from the depot to accommodate the cameras. At this 
time, there was absolutely nothing inside the church that could have caused the 
EMF detector to go off.

If anyone has information regarding this church from Blue Eye, MO, please 
contact us at [EMAIL PROTECTED]

The Coffin Shop: An investigator was asking questions while attempti

[Bug middle-end/33423] [4.2/4.3 regression]: internal compiler error: in expand_expr_real_1, at expr.c:8670

2007-09-14 Thread hjl at lucon dot org 


--- Comment #2 from hjl at lucon dot org  2007-09-15 03:43 ---
It also fails on Linux/ia32 and Linux/x86-64.


-- 

hjl at lucon dot org changed:

   What|Removed |Added

 GCC target triplet|ia64-unknown-linux-gnu  |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33423

[Bug ada/26797] [4.3 regression] ACATS cxh1001 fails

2007-09-14 Thread law at redhat dot com 


--- Comment #46 from law at redhat dot com  2007-09-15 06:35 ---
Subject: Re:  [4.3 regression] ACATS cxh1001 fails

On Wed, 2007-09-12 at 15:55 +, ebotcazou at gcc dot gnu dot org
wrote:
> 
> --- Comment #45 from ebotcazou at gcc dot gnu dot org  2007-09-12 15:55 
> ---
> At long last.
Woo hoo.

An oldie, but a goodie.

jeff


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26797