[Bug bootstrap/29825] New: ICE in

2006-11-14 Thread debian-gcc at lists dot debian dot org
the fix for PR middle-end/28915 causes a bootstrap failure with 4.1 20061113 on
i486 (using the Debian build); didn't yet check with a vanilla 4.1 branch or
the fedora 4.1 branch.

  Matthias

./xgcc -B./ -B/usr/i486-linux-gnu/bin/ -isystem /usr/i486-linux-gnu/include
-isystem /usr/i486-linux-gnu/sys-include
-L/home/packages/gcc/4.1/gcc-4.1-4.1.1ds2/build/gcc/../ld -O2  -O2 -g -O2 
-DIN_GCC-W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition  -isystem ./include  -fPIC -g -DHAVE_GTHR_DEFAULT
-DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED  -I. -I. -I../../src/gcc
-I../../src/gcc/. -I../../src/gcc/../include -I../../src/gcc/../libcpp/include 
-fexceptions -fvisibility=hidden -DHIDE_EXPORTS -c ../../src/gcc/unwind-dw2.c
-o libgcc/./unwind-dw2.o
../../src/gcc/unwind-dw2.c: In function 'uw_install_context_1':
../../src/gcc/unwind-dw2.c:1357: error: unrecognizable insn:
(insn:HI 157 44 158 4 (set (reg:SI 98)
(unspec:SI [
(symbol_ref:SI (dwarf_reg_size_table) [flags 0x2] var_decl
0x4042e6c0 dwarf_reg_size_table)
] 1)) -1 (nil)
(nil))
../../src/gcc/unwind-dw2.c:1357: internal compiler error: in extract_insn, at
recog.c:2084
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.


-- 
   Summary: ICE in
   Product: gcc
   Version: 4.1.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: debian-gcc at lists dot debian dot org


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



[Bug bootstrap/29825] ICE in extract_insn, at recog.c:2084 (unrecognizable insn)

2006-11-14 Thread debian-gcc at lists dot debian dot org


--- Comment #1 from debian-gcc at lists dot debian dot org  2006-11-14 
08:18 ---
reverting the fix for PR28915 fixes the bootstrap error

2006-11-12  Jason Merrill  [EMAIL PROTECTED]
Andrew Pinski [EMAIL PROTECTED]

PR middle-end/28915
* gimplify.c (gimplify_init_constructor): Don't reduce TREE_CONSTANT
vector ctors.
* tree-cfg.c (verify_expr): Don't look into TREE_CONSTANT
vector ctors.
* expmed.c (make_tree): Handle CONST, SYMBOL_REF.
* tree.c (build_vector): Handle non-_CST elements.


-- 

debian-gcc at lists dot debian dot org changed:

   What|Removed |Added

Summary|ICE in  |ICE in extract_insn, at
   ||recog.c:2084 (unrecognizable
   ||insn)


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



[Bug bootstrap/29825] ICE in extract_insn, at recog.c:2084 (unrecognizable insn)

2006-11-14 Thread pinskia at gcc dot gnu dot org


--- Comment #2 from pinskia at gcc dot gnu dot org  2006-11-14 08:21 ---
(In reply to comment #1)
 reverting the fix for PR28915 fixes the bootstrap error

This patch should not have any affect on bootstrap as there are no vectors
usage inside GCC.


-- 


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



[Bug ada/29802] wrong directory in makefile for ada and libada when building the src directory

2006-11-14 Thread bonzini at gnu dot org


--- Comment #2 from bonzini at gnu dot org  2006-11-14 08:26 ---
it is supported, it is just buggy.  Jean-Pierre, it seems like you have
something like a patch.  Can you expand your idea more?


-- 


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



[Bug bootstrap/29825] ICE in extract_insn, at recog.c:2084 (unrecognizable insn)

2006-11-14 Thread pinskia at gcc dot gnu dot org


--- Comment #3 from pinskia at gcc dot gnu dot org  2006-11-14 08:26 ---
building a plain 4.1 branch to prove it.


-- 


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



[Bug fortran/29711] error_print does not support %N$X

2006-11-14 Thread fxcoudert at gcc dot gnu dot org


--- Comment #4 from fxcoudert at gcc dot gnu dot org  2006-11-14 16:44 
---
Created an attachment (id=12618)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12618action=view)
Patch mentionned in previous comment


-- 


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



[Bug bootstrap/29825] [4.1 regression] ICE in extract_insn, at recog.c:2084

2006-11-14 Thread ebotcazou at gcc dot gnu dot org


--- Comment #4 from ebotcazou at gcc dot gnu dot org  2006-11-14 09:03 
---
Yep, and the aforementioned patch is indeed the culprit.


-- 

ebotcazou at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu dot
   ||org
   Severity|normal  |blocker
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2006-11-14 09:03:07
   date||
Summary|ICE in extract_insn, at |[4.1 regression] ICE in
   |recog.c:2084 (unrecognizable|extract_insn, at
   |insn)   |recog.c:2084
   Target Milestone|--- |4.1.2


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



[Bug fortran/29814] integer assignment in hexadecimal fails

2006-11-14 Thread vahtras at kth dot se


--- Comment #3 from vahtras at kth dot se  2006-11-14 09:42 ---
Subject: Re:  integer assignment in hexadecimal fails


On 14 nov 2006, at 02.23, jvdelisle at gcc dot gnu dot org wrote:

 Try -fno-range-check or use standard conforming methods.

Thank you, this was a learning experience indeed. /Olav


-- 


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



[Bug rtl-optimization/29798] [4.3 Regression] -O2 gives wrong results

2006-11-14 Thread bonzini at gcc dot gnu dot org


--- Comment #13 from bonzini at gnu dot org  2006-11-14 08:46 ---
Subject: Bug 29798

Author: bonzini
Date: Tue Nov 14 08:46:26 2006
New Revision: 118808

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118808
Log:
2006-11-14  Paolo Bonzini  [EMAIL PROTECTED]

PR rtl-optimization/29798

* fwprop.c (use_killed_between): Check that DEF_INSN dominates
TARGET_INSN before any other check.
(fwprop_init): Always calculate dominators.
(fwprop_done): Always free them.

2006-11-14  Paolo Bonzini  [EMAIL PROTECTED]

PR rtl-optimization/29798

* gcc.c-torture/execute/pr29798.c: New.


Added:
trunk/gcc/testsuite/gcc.c-torture/execute/pr29798.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/fwprop.c
trunk/gcc/testsuite/ChangeLog


-- 


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



[Bug rtl-optimization/29798] [4.3 Regression] -O2 gives wrong results

2006-11-14 Thread bonzini at gnu dot org


--- Comment #14 from bonzini at gnu dot org  2006-11-14 08:50 ---
still have to commit the patch on dataflow branch, but mainline is ok now


-- 

bonzini at gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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



[Bug c/29826] New: __attribute__ dllimport makes optimization crash on cygwin

2006-11-14 Thread Denis dot Excoffier at airbus dot com
the exact version of GCC is 4.1.1
the system type is i686-pc-cygwin
the options given when GCC was configured/built:
  --prefix=/tmp/local/unixutil/gcc-4.1.1
  --with-local-prefix=/usr/local/myCompanyName
  (myCompanyName is not the exact wording)
  (also, there is a symlink /tmp/local/unixutil/gcc - gcc-4.1.1)
the complete command line that triggers the bug:
  /tmp/local/unixutil/gcc/bin/gcc -O -Wall -Wextra -c zim.c
the compiler output (error messages, warnings, etc.):
  stdout: nothing
  stderr:
zim.c: In function '':
zim.c:16: error: unrecognizable insn:
(insn 20 19 21 2 (set (reg:SI 66)
(const:SI (plus:SI (mem:SI (symbol_ref:SI (#i.) var_decl
0x194500b0 ) [0 S4 A8])
(const_int 4 [0x4] -1 (nil)
(nil))
zim.c:16: internal compiler error: in extract_insn, at recog.c:2084
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
  zim.o: not created
the preprocessed file: see below
additional remarks:
  1) if -O is removed, all seems OK
  2) if __attribute__((dllimport)) is removed, all seems OK
  3) if -Wall or -Wextra is removed, no change (still crash)


---zim.i-
# 1 zim.c
# 1 built-in
# 1 command line
# 1 zim.c
struct  {
  const char *1;
  const char *2;
};

extern __attribute__((dllimport)) struct  [];

int ();

int () {
  int i;
  for (i = 0; i  2; i++) {
([i].2);
  };
  return(0);
};
-


-- 
   Summary: __attribute__ dllimport makes optimization crash on
cygwin
   Product: gcc
   Version: 4.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Denis dot Excoffier at airbus 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=29826



[Bug bootstrap/29825] [4.1 regression] ICE in extract_insn, at recog.c:2084

2006-11-14 Thread pinskia at gcc dot gnu dot org


--- Comment #7 from pinskia at gcc dot gnu dot org  2006-11-14 09:46 ---
So the problem is that loop.c creates a tree for:
(plus:SI (reg:SI 3 bx)
(const:SI (unspec:SI [
(symbol_ref:SI (dwarf_reg_size_table) [flags 0x2] var_decl
0xb7ce10b0 dwarf_reg_size_table)
] 1)))

From:
5106expand_mult_add (rtx x, rtx target, rtx mult, rtx add, enum
machine_mode mode,
5107 int unsignedp)



(gdb) p debug_rtx(x)
(const_int 1 [0x1])
$6 = void
(gdb) p debug_rtx(mult)
(const_int 1 [0x1])
$7 = void
(gdb) p debug_rtx(add)
(plus:SI (reg:SI 3 bx)
(const:SI (unspec:SI [
(symbol_ref:SI (dwarf_reg_size_table) [flags 0x2] var_decl
0xb7ce10b0 dwarf_reg_size_table)
] 1)))


-- 


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



[Bug bootstrap/29825] [4.1 regression] ICE in extract_insn, at recog.c:2084

2006-11-14 Thread pinskia at gcc dot gnu dot org


--- Comment #5 from pinskia at gcc dot gnu dot org  2006-11-14 09:06 ---
Looking into it, a bit more. But as far as I can tell this is a latent bug in
the x86 back-end.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Keywords||build, ice-on-valid-code


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



[Bug rtl-optimization/29798] [4.3 Regression] -O2 gives wrong results

2006-11-14 Thread bonzini at gcc dot gnu dot org


--- Comment #15 from bonzini at gnu dot org  2006-11-14 09:06 ---
Subject: Bug 29798

Author: bonzini
Date: Tue Nov 14 09:06:42 2006
New Revision: 118809

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118809
Log:
2006-11-14  Paolo Bonzini  [EMAIL PROTECTED]

Merge from mainline:

2006-11-14  Paolo Bonzini  [EMAIL PROTECTED]

PR rtl-optimization/29798

* fwprop.c (use_killed_between): Check that DEF_INSN dominates
TARGET_INSN before any other check.

Modified:
branches/dataflow-branch/gcc/ChangeLog.dataflow
branches/dataflow-branch/gcc/fwprop.c


-- 


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



[Bug target/29825] [4.1 regression] ICE in extract_insn, at recog.c:2084

2006-11-14 Thread pinskia at gcc dot gnu dot org


--- Comment #9 from pinskia at gcc dot gnu dot org  2006-11-14 09:57 ---
(In reply to comment #8)
 Hmm, isn't movl %eax, [EMAIL PROTECTED] a valid way to have an
 offset?

gas accepts that as valid so I think GCC should accept this.  I am now going to
bed but I am also going to say this is a latent bug in the x86 back-end.


-- 


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



[Bug fortran/29820] ICE in fold_convert, at fold-const.c:2146

2006-11-14 Thread rguenth at gcc dot gnu dot org


--- Comment #4 from rguenth at gcc dot gnu dot org  2006-11-14 09:50 ---
I'm confused that for

  type geodetic
 real :: h
  end type geodetic

gfortran is using a record type but still goes the scalar assignment path. 
With
gfc_trans_scalar_assign changed to read

  gcc_assert (!AGGREGATE_TYPE_P (TREE_TYPE (lse-expr))
  || TREE_TYPE (lse-expr) == TREE_TYPE (rse-expr));
  gfc_add_modify_expr (block, lse-expr,
   !AGGREGATE_TYPE_P (TREE_TYPE (lse-expr))
   ? fold_convert (TREE_TYPE (lse-expr), rse-expr)
   : rse-expr);

we can see that we don't have the required type-unification for geodetic:

(gdb) call debug_tree (lse-expr)
 indirect_ref 0x2b0877c769c0
type record_type 0x2b0877d4ea50 geodetic SF
size integer_cst 0x2b0877c6cba0 constant invariant 32
unit size integer_cst 0x2b0877c6c6c0 constant invariant 4
align 32 symtab 0 alias set -1
fields field_decl 0x2b0877d4ce40 h type real_type 0x2b0877c87210
real4
SF file t.f90 line 9 size integer_cst 0x2b0877c6cba0 32 unit size
integer_cst 0x2b0877c6c6c0 4
align 32 offset_align 128
offset integer_cst 0x2b0877c6c6f0 constant invariant 0
bit offset integer_cst 0x2b0877c842d0 constant invariant 0
context record_type 0x2b0877d4ea50 geodetic
reference_to_this reference_type 0x2b0877d4eb00 chain type_decl
0x2b0877c91680 D.1330

(gdb) call debug_tree (rse-expr)
 array_ref 0x2b0877d55180
type record_type 0x2b0877d4ec60 geodetic SF
size integer_cst 0x2b0877c6cba0 constant invariant 32
unit size integer_cst 0x2b0877c6c6c0 constant invariant 4
align 32 symtab 0 alias set -1
fields field_decl 0x2b0877d4cf00 h type real_type 0x2b0877c87210
real4
SF file t.f90 line 9 size integer_cst 0x2b0877c6cba0 32 unit size
integer_cst 0x2b0877c6c6c0 4
align 32 offset_align 128
offset integer_cst 0x2b0877c6c6f0 constant invariant 0
bit offset integer_cst 0x2b0877c842d0 constant invariant 0
context record_type 0x2b0877d4ec60 geodetic
pointer_to_this pointer_type 0x2b0877d4edc0 chain type_decl
0x2b0877c91750 D.1335

(while this should be the same type, one is record_type 0x2b0877d4ec60 and
the other is record_type 0x2b0877d4ea50, which is causing this bug)


-- 


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



Re: [Bug middle-end/28915] [4.1 regression] ICE: tree check: expected class 'constant', have 'declaration' (var_decl) in build_vector, at tree.c:973

2006-11-14 Thread Andrew Pinski
On Tue, 2006-11-14 at 09:29 +, jakub at gcc dot gnu dot org wrote:
 
 --- Comment #24 from jakub at gcc dot gnu dot org  2006-11-14 09:29 
 ---
 This change breaks bootstrap on x86_64-linux and i386-linux:

This is now PR 29825 and it is an x86 back-end issue about not accepting
the instruction which is valid as far as I can tell as the following asm
instruction is valid:
movl %eax, [EMAIL PROTECTED]

-- Pinski



[Bug target/29815] internal compiler error, if float-comparison is done with option -mfloat-gprs=yes

2006-11-14 Thread poellmann at nm dot hsd dot utc dot com


--- Comment #3 from poellmann at nm dot hsd dot utc dot com  2006-11-14 
10:10 ---
The problem maintains with gcc 4.1.1. The error-message is slightly different:

test.c: In function 'compare':
test.c:5: error: unrecognizable insn:
(insn 12 11 13 1 (set (reg:CCFP 123)
(compare:CCFP (reg:SF 121)
(reg:SF 122))) -1 (nil)
(nil))
test.c:5: internal compiler error: in extract_insn, at recog.c:2084


-- 


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



[Bug bootstrap/29825] [4.1 regression] ICE in extract_insn, at recog.c:2084

2006-11-14 Thread pinskia at gcc dot gnu dot org


--- Comment #6 from pinskia at gcc dot gnu dot org  2006-11-14 09:40 ---
This is a bug in loop.c ... which is why it works in 4.2.0 and above.


-- 


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



[Bug middle-end/28915] [4.1 regression] ICE: tree check: expected class 'constant', have 'declaration' (var_decl) in build_vector, at tree.c:973

2006-11-14 Thread jakub at gcc dot gnu dot org


--- Comment #24 from jakub at gcc dot gnu dot org  2006-11-14 09:29 ---
This change breaks bootstrap on x86_64-linux and i386-linux:
/usr/src/gcc-4.1/obj/./gcc/xgcc -B/usr/src/gcc-4.1/obj/./gcc/
-B/usr/local/x86_64-unknown-linux-gnu/bin/
-B/usr/local/x86_64-unknown-linux-gnu/lib/ -isystem
/usr/local/x86_64-unknown-linux-gnu/include -isystem
/usr/local/x86_64-unknown-linux-gnu/sys-include -O2  -O2 -g -O2  -DIN_GCC-W
-Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition  -isystem ./include  -fPIC -g -DHAVE_GTHR_DEFAULT
-DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED  -I. -I. -I../../gcc -I../../gcc/.
-I../../gcc/../include -I../../gcc/../libcpp/include  -m32 -fexceptions
-fvisibility=hidden -DHIDE_EXPORTS -c ../../gcc/unwind-dw2.c -o
libgcc/32/unwind-dw2.o
../../gcc/unwind-dw2.c: In function 'uw_install_context_1':
../../gcc/unwind-dw2.c:1334: error: unrecognizable insn:
(insn:HI 159 44 160 4 (set (reg:SI 102)
(unspec:SI [
(symbol_ref:SI (dwarf_reg_size_table) [flags 0x2] var_decl
0x2b051210 dwarf_reg_size_table)
] 1)) -1 (nil)
(nil))
../../gcc/unwind-dw2.c:1334: internal compiler error: in extract_insn, at
recog.c:2084
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.

The problematic part is the make_tree addition.


-- 


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



[Bug target/29825] [4.1 regression] ICE in extract_insn, at recog.c:2084

2006-11-14 Thread jakub at gcc dot gnu dot org


--- Comment #12 from jakub at gcc dot gnu dot org  2006-11-14 11:43 ---
While that can help in this case, I think letting make_tree/expand_expr combo
create invalid RTL is very dangerous (and, at least from i386 backend POV,
some of the PIC UNSPECs not surrounded by CONST are invalid, the backend
guarantees that wherever it creates them it adds the CONST around).


-- 


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



[Bug fortran/29711] error_print does not support %N$X

2006-11-14 Thread fxcoudert at gcc dot gnu dot org


--- Comment #2 from fxcoudert at gcc dot gnu dot org  2006-11-14 10:39 
---
I'll take that one.


-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |fxcoudert at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2006-11-04 13:28:03 |2006-11-14 10:39:46
   date||


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



[Bug c/29827] New: Assigning function with a char param emits a spurious warning

2006-11-14 Thread mike at codeweavers dot com
Assigning a function pointer with a char parameter to a pointer with an
undefined list causes gcc to emit a warning.

[EMAIL PROTECTED]:~/ntnative/loader$ cat x.c
void foo(char);
void (*f1)() = foo;

void bar(int);
void (*f2)() = bar;
[EMAIL PROTECTED]:~/ntnative/loader$ gcc -c x.c
x.c:2: warning: initialization from incompatible pointer type
[EMAIL PROTECTED]:~/ntnative/loader$ gcc -v
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu
--enable-libstdcxx-debug --enable-mpfr --enable-checking=release
x86_64-linux-gnu
Thread model: posix
gcc version 4.1.2 20061028 (prerelease) (Debian 4.1.1-19)


-- 
   Summary: Assigning function with a char param emits a spurious
warning
   Product: gcc
   Version: 4.1.2
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mike at codeweavers dot com
  GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu


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



[Bug fortran/22282] %loc is not implemented in gfortran

2006-11-14 Thread pault at gcc dot gnu dot org


--- Comment #8 from pault at gcc dot gnu dot org  2006-11-14 10:19 ---
FX,

In spite of this morning's posting to the list, I will not be submitting a
patch for %LOC but rather for %REF.  I got stuck in vms space.  Is there any
functional difference between %LOC and %REF, do you know?

Paul


-- 


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



[Bug fortran/29828] New: Fortran 2003: MIN and MAX with character variables

2006-11-14 Thread burnus at gcc dot gnu dot org
See:
13.7.76 MIN (A1, A2 [, A3, ...])
For arguments of character type, the result is the value that would be selected
by application of intrinsic relational operators; that is, the collating
sequence for characters with the kind type parameter of the arguments is
applied. If the selected argument is shorter than the longest argument, the 20
result is extended with blanks on the right to the length of the longest
argument.

Example. [...] MIN (”A”, ”YY”) has the value “A “, and
22 MIN ((/”Z”, ”A”/), (/”YY”, ”B “/)) has the value (/”YY”, ”A “/).

Analogously for:
13.7.71 MAX (A1, A2 [, A3, ...])


-- 
   Summary: Fortran 2003: MIN and MAX with character 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


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



[Bug fortran/22282] %loc is not implemented in gfortran

2006-11-14 Thread fxcoudert at gcc dot gnu dot org


--- Comment #9 from fxcoudert at gcc dot gnu dot org  2006-11-14 10:37 
---
%VAL, %REF and %DESCR have similar use and functionality, but %LOC is very
different. It should in fact be an alias for function LOC, but it simply adding
it in intrinsic.c with make_alias is not sufficient: creating a symbol name
begining with a % has to be added to the parser and the symbol-name-mangler. My
(short) attempt to do so failed, but it's probably not very difficult if you
understand the binary tree structure of symbol names.


-- 


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



[Bug fortran/29642] Fortran 2003: VALUE Attribute (call by value not call by reference for actual arguments)

2006-11-14 Thread patchapp at dberlin dot org


--- Comment #3 from patchapp at dberlin dot org  2006-11-14 10:00 ---
Subject: Bug number PR29642

A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2006-11/msg00923.html


-- 


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



[Bug middle-end/28915] [4.1 regression] ICE: tree check: expected class 'constant', have 'declaration' (var_decl) in build_vector, at tree.c:973

2006-11-14 Thread pinskia at gmail dot com


--- Comment #25 from pinskia at gmail dot com  2006-11-14 10:02 ---
Subject: Re:  [4.1 regression] ICE: tree check:
expected class 'constant', have 'declaration' (var_decl) in
build_vector,
at tree.c:973

On Tue, 2006-11-14 at 09:29 +, jakub at gcc dot gnu dot org wrote:
 
 --- Comment #24 from jakub at gcc dot gnu dot org  2006-11-14 09:29 
 ---
 This change breaks bootstrap on x86_64-linux and i386-linux:

This is now PR 29825 and it is an x86 back-end issue about not accepting
the instruction which is valid as far as I can tell as the following asm
instruction is valid:
movl %eax, [EMAIL PROTECTED]

-- Pinski


-- 


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



[Bug target/29825] [4.1 regression] ICE in extract_insn, at recog.c:2084

2006-11-14 Thread jakub at gcc dot gnu dot org


--- Comment #10 from jakub at gcc dot gnu dot org  2006-11-14 10:45 ---
The problem is in the make_tree change of PR28915.
make_tree is called with (const (unspec (something) ) ), before make_tree
would just create a dummy VAR_DECL with DECL_RTL set to this, but now
calls make_tree recursively and thus returns a dummy VAR_DECL with DECL_RTL
set to (unspec (something) ) - note that CONST is lost.
It is then folded and expanded, but CONST is never added back and i386 backend
relies on it (and I believe other backends have similar requirements).
I don't know why exactly the make_tree change was done, but certainly
it should be limited to RTLs inside CONST that the middle-end groks fully.


-- 


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



[Bug fortran/23060] %VAL, %REF and %DESCR constructs not implemented

2006-11-14 Thread pault at gcc dot gnu dot org


--- Comment #11 from pault at gcc dot gnu dot org  2006-11-14 10:16 ---
A long overdue patch for this will be submitted in the next 24hours.

Paul


-- 

pault at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |pault at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2006-11-03 14:11:48 |2006-11-14 10:16:44
   date||


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



[Bug c++/29829] New: arm-linux-g++: Internal error: Killed (program cc1plus)

2006-11-14 Thread mneehar at yahoo dot co dot in
while working in a project in C++. I tried to use  a forward declaration of a
class. Class is unders some name space. There I got the error message like
below.


arm-linux-g++: Internal error: Killed (program cc1plus)
Please submit a full bug report.
See URL:http://gcc.gnu.org/bugs.html for instructions.


-- 
   Summary: arm-linux-g++: Internal error: Killed (program cc1plus)
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: blocker
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mneehar at yahoo dot co dot in


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



[Bug ada/29802] wrong directory in makefile for ada and libada when building the src directory

2006-11-14 Thread jpvial at nerim dot net


--- Comment #3 from jpvial at nerim dot net  2006-11-14 11:10 ---
Subject: Re:  wrong directory in makefile for ada and libada
 when building the src directory

bonzini at gnu dot org wrote:
 --- Comment #2 from bonzini at gnu dot org  2006-11-14 08:26 ---
 it is supported, it is just buggy.  Jean-Pierre, it seems like you have
 something like a patch.  Can you expand your idea more?
 
 
I think that the bug is in the configure script, not in the compiler itself.
My solution cannot be called a patch, just a dirty workaround:

1: ada compiler
for each stage of the bootstrap procedure, when the Makefile halts on
the error,

/home/jp/src/bug42/gcc-4.2-20061107/prev-gcc/gnatbind -C -I- -I. -Iada
-I../.././gcc/ada -o ada/b_gnatb.c ada/gnatbind.ali
make[3]: /home/jp/src/bug42/gcc-4.2-20061107/prev-gcc/gnatbind :
commande introuvable   (this is the french for command not found or
something similar)

I change to the relevant directory
my-own-tree/gcc-4.2-20061107/host-x86_64-unknown-linux-gnu/gcc
I change the PATH to
my-own-tree/gcc-4.2-20061107/host-x86_64-unknown-linux-gnu/prev-gcc:$PATH
I launch make in the directory, and wait for make (which is actually a
sub-make) to finish.
then I go back to the main directory
my-own-tree/gcc-4.2-20061107
I restore the normal PATH and restart the main make for the next
bootstrap stage, if any.
This process is repeated for each stage.


2 libada   : much simpler, and cleaner
The Makefile for libada has a line:
GCC_DIR=../../$(HOST_SUBDIR)/gcc
but HOST_SUBDIR is nowhere defined,
so GCC_DIR take the wrong value  ../..//gcc
I add, before the offending line
HOST_SUBDIR=host-x86_64-unknown-linux-gnu
and libada is built without further difficulty

By the way, after the first answer to my bug report, I tried building in
another directory; I had different bugs (of similar nature) for the
compiler, and exactly the same problem for libada; finally it did not
work better. I did not investigate further for this case.


-- 


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



[Bug target/29825] [4.1 regression] ICE in extract_insn, at recog.c:2084

2006-11-14 Thread rguenth at gcc dot gnu dot org


--- Comment #11 from rguenth at gcc dot gnu dot org  2006-11-14 11:11 
---
The reduced testcase only fails on i?86, bootstrap also fails on x86_64 with
the same error.

At least (symbol_ref:SI (dwarf_reg_size_table) [flags 0x2] var_decl
0x2af3f74a6580 dwarf_reg_size_table) is not a valid PIC address (it's only one
in 64bit mode).

from loop.c we enter ix86_expand_move (via gen_movis) with an operand1 of

(unspec:SI [
(symbol_ref:SI (dwarf_reg_size_table) [flags 0x2] var_decl
0x2b38cd3da580 dwarf_reg_size_table)
] 1)

which we don't handle.

We reach there through loop.c:gen_add_mult called with

#11 0x0091e99b in gen_add_mult (b=0x2b38cd2ee410, m=0x2b38cd2ee410, 
a=0x2b38cd49bdc0, reg=0x2b38cd49bd20)
at /space//rguenther/src/svn/gcc-4_1-branch/gcc/loop.c:9223
9223  result = expand_mult_add (b, reg, m, a, GET_MODE (reg), 1);
(gdb) call debug_rtx (b)
(const_int 1 [0x1])
(gdb) call debug_rtx (m)
(const_int 1 [0x1])
(gdb) call debug_rtx (a)
(plus:SI (plus:SI (reg:SI 3 bx)
(const_int -1 [0x]))
(const:SI (unspec:SI [
(symbol_ref:SI (dwarf_reg_size_table) [flags 0x2] var_decl
0x2b38cd3da580 dwarf_reg_size_table)
] 1)))
(gdb) call debug_rtx (reg)
(reg:SI 82)

via expmed.c:expand_mult_add we go through expanding a tree (ugh) which looks
then like

(gdb) call debug_tree (result)
 plus_expr 0x2b38cd499410
type integer_type 0x2b38cd2f8580 unsigned int public unsigned SI
size integer_cst 0x2b38cd2e9a50 constant invariant 32
unit size integer_cst 0x2b38cd2e9570 constant invariant 4
align 32 symtab 0 alias set -1 precision 32 min integer_cst
0x2b38cd2e9b40 0 max integer_cst 0x2b38cd2e9b10 4294967295

arg 0 var_decl 0x2b38cd49c210 D.1348 type integer_type 0x2b38cd2f8580
unsigned int
used unsigned SI file t.i line 16 size integer_cst 0x2b38cd2e9a50 32
unit size integer_cst 0x2b38cd2e9570 4
align 32
(reg:SI 3 bx)
arg 1 var_decl 0x2b38cd49c160 D.1347 type integer_type 0x2b38cd2f8580
unsigned int
used unsigned SI file t.i line 16 size integer_cst 0x2b38cd2e9a50 32
unit size integer_cst 0x2b38cd2e9570 4
align 32
(unspec:SI [
(symbol_ref:SI (dwarf_reg_size_table) [flags 0x2] var_decl
0x2b38cd3da580 dwarf_reg_size_table)
] 1)

which is where we get the plain UNSPEC from.  In loop.c:scan_loop we
propagate the load into its use which is the start of the problems.

We then call validate_replace_rtx with
(gdb) call debug_rtx (from)
(reg/f:SI 72)
(gdb) call debug_rtx (to)
(plus:SI (reg:SI 3 bx)
(const:SI (unspec:SI [
(symbol_ref:SI (dwarf_reg_size_table) [flags 0x2] var_decl
0x2b22d66b7580 dwarf_reg_size_table)
] 1)))
(gdb) call debug_rtx (insn)
(insn 32 31 34 (parallel [
(set (reg:SI 71)
(plus:SI (reg:SI 66 [ ivtmp.32 ])
(reg/f:SI 72)))
(clobber (reg:CC 17 flags))
]) 208 {*addsi_1} (nil)
(nil))

In loop.c we go through lengths of discovering REG_EQUAL notes supposedly
to use them as src in those operations.  And indeed

Index: loop.c
===
*** loop.c  (revision 118809)
--- loop.c  (working copy)
*** scan_loop (struct loop *loop, int flags)
*** 1313,1326 
   ! modified_between_p (SET_SRC (set), p, user)
   no_labels_between_p (p, user)
   validate_replace_rtx (SET_DEST (set),
!  SET_SRC (set), user))
{
  /* Replace any usage in a REG_EQUAL note.  Must copy
 the new source, so that we don't get rtx sharing
 between the SET_SOURCE and REG_NOTES of insn p.  */
  REG_NOTES (user)
= replace_rtx (REG_NOTES (user), SET_DEST (set),
!  copy_rtx (SET_SRC (set)));

  delete_insn (p);
  for (i = 0; i  LOOP_REGNO_NREGS (regno, SET_DEST (set));
--- 1313,1326 
   ! modified_between_p (SET_SRC (set), p, user)
   no_labels_between_p (p, user)
   validate_replace_rtx (SET_DEST (set),
!  src, user))
{
  /* Replace any usage in a REG_EQUAL note.  Must copy
 the new source, so that we don't get rtx sharing
 between the SET_SOURCE and REG_NOTES of insn p.  */
  REG_NOTES (user)
= replace_rtx (REG_NOTES (user), SET_DEST (set),
!  copy_rtx (src));

  delete_insn (p);
  for (i = 0; i  LOOP_REGNO_NREGS (regno, SET_DEST (set));

seems to fix this particular testcase.

[Bug tree-optimization/29832] -ftree-loop-linear miscompiles scalarize.f90

2006-11-14 Thread jakub at gcc dot gnu dot org


--- Comment #1 from jakub at gcc dot gnu dot org  2006-11-14 14:27 ---
lambda_loopnest_to_gcc_loopnest interchanges the loops and we get:
L12:;
  lletmp.77_46 = 0;
  lletmp.77_38 = lletmp.77_46 + 5;
  lnivtmp.75_21 = lnivtmp.75_9 + 1;
  lnivtmp.75_12 = lnivtmp.75_9 + 1;
  if (lletmp.77_38 = lnivtmp.75_12) goto L99; else goto L86;
L86:;
  # lnivtmp.75_9 = PHI lnivtmp.75_21(13), lletmp.76_162(11);
  # S.2_165 = PHI S.2_40(13), 0(11);
L13:;
  lbvtmp.82_18 = 0;
  lbvtmp.82_145 = lnivtmp.78_8;
   lbvtmp.82_20 = lbvtmp.82_18 + lbvtmp.82_145;
  S.2_40 = lbvtmp.82_20 + 1;
  lletmp.79_154 = 0;
  # lnivtmp.78_8 = PHI lnivtmp.78_3(16), lletmp.79_154(14);
  # S.3_171 = PHI S.3_51(16), 1(14);
L15:;
  lletmp.80_22 = 0;
  lletmp.80_56 = lletmp.80_22 + 3;
  D.1393_41 = S.2_40 * 6;
  lbvtmp.81_31 = 0;
  lbvtmp.81_26 = lnivtmp.78_8;
  lbvtmp.81_106 = lbvtmp.81_26 + lbvtmp.81_31;
  D.1394_43 = 5 - lbvtmp.81_106;
  D.1395_44 = D.1394_43 * 6;
  pretmp.59_117 = D.1395_44 + -7;
  pretmp.59_121 = D.1393_41 + -7;
  D.1343_45 = pretmp.59_117;
  lbvtmp.84_161 = 0;
  lbvtmp.84_105 = lnivtmp.75_9;
  lbvtmp.84_120 = lbvtmp.84_105 + lbvtmp.84_161;
  D.1397_47 = pretmp.59_117 + lbvtmp.84_120;
  D.1342_42 = pretmp.59_121;
  lbvtmp.83_157 = 0;
  lbvtmp.83_158 = lnivtmp.75_9;
  lbvtmp.83_159 = lbvtmp.83_157 + lbvtmp.83_158;
  D.1398_48 = pretmp.59_121 + lbvtmp.83_159;
  D.1399_49 = a[D.1398_48];
  b[D.1397_47] = D.1399_49;
  lbvtmp.85_125 = 0;
  lbvtmp.85_74 = lnivtmp.75_9;
  lbvtmp.85_68 = lbvtmp.85_74 + lbvtmp.85_125;
  S.3_51 = lbvtmp.85_68 + 1;
  lnivtmp.78_3 = lnivtmp.78_8 + 1;
  lnivtmp.78_19 = lnivtmp.78_8 + 1;
  if (lletmp.80_56 = lnivtmp.78_19) goto L12; else goto L87;
L87:;
  goto bb 15 (L15);

These basic blocks are the only ones that ever mention lnivtmp.78
variable, it is set from a PHI node at L15, but used both in L15
(ok) and also in L13, which isn't dominated by L15 (L13 is where
the loop is entered).

The lnivtmp.78 use before definition is from the bumper statement which is
considered ok by perfect_nest_p.  If the bumper SSA_NAME was only used in
the bumper statement and the PHI node, this wouldn't be a big issue, eventhough
lambda_loopnest_to_gcc_loopnest would reference undefined variable, it would
be quickly optimized away (as the bumper would be optimized out as unused)
- ltrans creates new bumper vars, but unfortunately it is used.

I think either perfect_nest_p should only allow bumper variables which are
solely used in the bumper statement and PHI node and nowhere else (this would
cure this case, either it wouldn't be considered valid for ltrans or
perfect_nestify would need to try harder (e.g. by cloning the bumper statement
within the inner loop's body, in the inner loop's body it would set a different
temporary which would be used there and the original bumper var would be only
used outside of inner loop and in the PHI)), or lambda_loopnest_to_gcc_loopnest
needs to be tought to special case stmt_is_bumper_for_loop statements outside
of the innermost loop.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

   Keywords||wrong-code


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



[Bug fortran/29657] Don't allow SAVE for functions

2006-11-14 Thread burnus at gcc dot gnu dot org


--- Comment #7 from burnus at gcc dot gnu dot org  2006-11-14 15:49 ---
Fixed in trunk.


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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



[Bug ada/29802] wrong directory in makefile for ada and libada when building the src directory

2006-11-14 Thread bonzini at gnu dot org


--- Comment #4 from bonzini at gnu dot org  2006-11-14 12:23 ---
Created an attachment (id=12616)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12616action=view)
patch to fix the bug


Please try this.


-- 

bonzini at gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |bonzini at gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED


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



[Bug c/29826] __attribute__ dllimport makes optimization crash on cygwin

2006-11-14 Thread Denis dot Excoffier at airbus dot com


--- Comment #1 from Denis dot Excoffier at airbus dot com  2006-11-14 11:39 
---
To be connected to Bug 29825.


-- 


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



[Bug target/29825] [4.1 regression] ICE in extract_insn, at recog.c:2084

2006-11-14 Thread ebotcazou at gcc dot gnu dot org


--- Comment #13 from ebotcazou at gcc dot gnu dot org  2006-11-14 11:48 
---
 While that can help in this case, I think letting make_tree/expand_expr combo
 create invalid RTL is very dangerous (and, at least from i386 backend POV,
 some of the PIC UNSPECs not surrounded by CONST are invalid, the backend
 guarantees that wherever it creates them it adds the CONST around).

FWIW I agree.  Branches are not the right place to try out this kind of things.


-- 


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



[Bug c++/29830] Name lookup bug for inner template specialization

2006-11-14 Thread pluto at agmk dot net


--- Comment #1 from pluto at agmk dot net  2006-11-14 12:53 ---
this is a dup of PR29767


-- 


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



[Bug c++/29830] New: Name lookup bug for inner template specialization

2006-11-14 Thread zjasz at yahoo dot com
Hi,

I haven't found any related bug in the known bugs database.
Also I posted this problem to several forums to be shore that this code doesn't
violate the C++ standard. ~60% replies that this should work. Moreover two
other compilers can compile without any problem:

The simplified code:
//
#include stdio.h
template typename T, int v class record_descriptor {
public:
 void operator()()
 {
 printf(Global template\n);
 }
};
templatetypename T, int v, templatetypename,int class RD =
record_descriptor class TableRecord {
public:
 TableRecord()
 {
 RDT, v d;
 d();
 }
};
templatetypename A class Attr
{
public:
 template typename T, int v class i_record_descriptor
 {
 };
 template int v class i_record_descriptorA, v
 {
 public:
 void operator()()
 {
 printf(Inner spec template\n);
 }
 };
 Attr()
 {
 TableRecordA, 1, i_record_descriptor tr;
 }
};
int main()
{
 Attrint attr;
 return 0;
}
//
Message:
gccbug.cpp: In constructor 'TableRecordT, v, RD::TableRecord() [with T = int,
int v = 1, RD = Attrint::i_record_descriptor]':
gccbug.cpp:32:   instantiated from 'AttrA::Attr() [with A = int]'
gccbug.cpp:37:   instantiated from here
gccbug.cpp:15: error: no match for call to
'(Attrint::i_record_descriptorint, 1) ()'

If i_class_descriptor template has an implementation:
//
#include stdio.h
template typename T, int v class record_descriptor {
public:
 void operator()()
 {
 printf(Global template\n);
 }
};
templatetypename T, int v, templatetypename,int class RD =
record_descriptor class TableRecord {
public:
 TableRecord()
 {
 RDT, v d;
 d();
 }
};
templatetypename A class Attr
{
public:
 template typename T, int v class i_record_descriptor
 {
 public:
 void operator()()
 {
 printf(Inner template\n);
 }
 };
 template int v class i_record_descriptorA, v
 {
 public:
 void operator()()
 {
 printf(Inner spec template\n);
 }
 };
 Attr()
 {
 TableRecordA, 1, i_record_descriptor tr;
 }
};
int main()
{
 Attrint attr;
 return 0;
}
/
...compiles but the result after executing is Inner template instead of
Inner spec template

If the parameter 'A' is changed in the partial specialozation to a primitve
type, ex: 'int' then compiles fine and the result is correct.

The last version I tried was:
g++ (GCC) 4.1.2 20060901 (prerelease) (Debian 4.1.1-13)

I hope I give you all the necessary information!

Regards,
Zoltan Jasz

Software developer,
Ericsson Telecomunication Hungary Ltd.


-- 
   Summary: Name lookup bug for inner template specialization
   Product: gcc
   Version: 4.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: zjasz at yahoo dot com
 GCC build triplet: 4.1.1 20060525 (Red Hat 4.1.1-1)
  GCC host triplet: i386-redhat-linux
GCC target triplet: i386-redhat-linux


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



[Bug fortran/29828] Fortran 2003: MIN and MAX with character variables

2006-11-14 Thread pault at gcc dot gnu dot org


--- Comment #1 from pault at gcc dot gnu dot org  2006-11-14 14:17 ---
Confirmed.

Tobias,

What criterion are you chosing for the missing F2003 features?  The reason that
I ask is that it is not clear to me when you stop; eg. should we have a PR for
polymorphism or for sub-modules?  Maybe it would be better to have a meta-bug
for F2003 and point to a Wiki page in which we try to joggle up a priority
order?

Best regards

Paul 


-- 

pault at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2006-11-14 14:17:15
   date||


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



[Bug c++/29830] Name lookup bug for inner template specialization

2006-11-14 Thread zjasz at yahoo dot com


--- Comment #2 from zjasz at yahoo dot com  2006-11-14 15:02 ---
(In reply to comment #1)
 this is a dup of PR29767

Sorry for duplication, I haven't checked again after I posted to the gcc-help.


-- 


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



[Bug c/29833] gcc 4.1.2 on x86_64 Ubuntu Edgy generates incorrect prefetch instruction

2006-11-14 Thread rguenth at gcc dot gnu dot org


--- Comment #2 from rguenth at gcc dot gnu dot org  2006-11-14 15:54 ---
What does adding '-v' to the compile command say?  It seems Ubuntu is using a
default -march that enables 3dnow (k8 or opteron maybe) - it should use x86_64
instead.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING


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



[Bug preprocessor/29831] New: changed include order when symlinking prefix or moving binaries

2006-11-14 Thread michael dot haubenwallner at salomon dot at
Have built gcc with --prefix=/usr/local/gcc-4.1.1.

When /usr/local/gcc-4.1.1 is moved and symlinked to /stranger/gcc-4.1.1,
the include path order changes, so that fixed system headers are searched
before local headers.

In non-symlink case, where the searched include path is correct, I can see this
output (with focus on the include path):

$ /usr/local/gcc-4.1.1/bin/gcc -c -v xx.c
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: /ftp/pub/source/gcc/gcc-4.1.1.orig/configure
--prefix=/usr/local/gcc-4.1.1 --enable-languages=c
Thread model: posix
gcc version 4.1.1
 /usr/local/gcc-4.1.1/libexec/gcc/i686-pc-linux-gnu/4.1.1/cc1 -quiet -v xx.c
-quiet -dumpbase xx.c -mtune=pentiumpro -auxbase xx -version -o /tmp/ccL8OzjB.s
ignoring nonexistent directory
/usr/local/gcc-4.1.1/lib/gcc/i686-pc-linux-gnu/4.1.1/../../../../i686-pc-linux-gnu/include
#include ... search starts here:
#include ... search starts here:
 /usr/local/include
 /usr/local/gcc-4.1.1/include
 /usr/local/gcc-4.1.1/lib/gcc/i686-pc-linux-gnu/4.1.1/include
 /usr/include
End of search list.
GNU C version 4.1.1 (i686-pc-linux-gnu)
compiled by GNU C version 4.1.1 (Gentoo 4.1.1).
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 36febb42c74478a1ecbe6b4467b0f6b8
 as -V -Qy -o xx.o /tmp/ccL8OzjB.s
GNU assembler version 2.16.1 (i686-pc-linux-gnu) using BFD version 2.16.1


When I move and symlink /usr/local/gcc-4.1.1 to /stranger/gcc-4.1.1, the
include order changes:

$ mkdir /stranger
$ mv /usr/local/gcc-4.1.1 /stranger
$ ln -s /stranger/gcc-4.1.1 /usr/local
$ /usr/local/gcc-4.1.1/bin/gcc -c -v xx.c
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: /ftp/pub/source/gcc/gcc-4.1.1.orig/configure
--prefix=/usr/local/gcc-4.1.1 --enable-languages=c
Thread model: posix
gcc version 4.1.1
 /stranger/gcc-4.1.1/bin/../libexec/gcc/i686-pc-linux-gnu/4.1.1/cc1 -quiet -v
-iprefix /stranger/gcc-4.1.1/bin/../lib/gcc/i686-pc-linux-gnu/4.1.1/ xx.c
-quiet -dumpbase xx.c -mtune=pentiumpro -auxbase xx -version -o /tmp/cc0hiBMc.s
ignoring nonexistent directory
/stranger/gcc-4.1.1/bin/../lib/gcc/i686-pc-linux-gnu/4.1.1/../../../../i686-pc-linux-gnu/include
ignoring duplicate directory
/usr/local/gcc-4.1.1/lib/gcc/i686-pc-linux-gnu/4.1.1/include
ignoring nonexistent directory
/usr/local/gcc-4.1.1/lib/gcc/i686-pc-linux-gnu/4.1.1/../../../../i686-pc-linux-gnu/include
#include ... search starts here:
#include ... search starts here:
 /stranger/gcc-4.1.1/bin/../lib/gcc/i686-pc-linux-gnu/4.1.1/include
 /usr/local/include
 /usr/local/gcc-4.1.1/include
 /usr/include
End of search list.
GNU C version 4.1.1 (i686-pc-linux-gnu)
compiled by GNU C version 4.1.1 (Gentoo 4.1.1).
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 36febb42c74478a1ecbe6b4467b0f6b8
 as -V -Qy -o xx.o /tmp/cc0hiBMc.s
GNU assembler version 2.16.1 (i686-pc-linux-gnu) using BFD version 2.16.1


The basic difference is that cc1 gets called as:
  /stranger/gcc-4.1.1/bin/../libexec/gcc/i686-pc-linux-gnu/4.1.1/cc1
with this additional argument:
  -iprefix /stranger/gcc-4.1.1/bin/../lib/gcc/i686-pc-linux-gnu/4.1.1/


Additionally, when _moving_ to /stranger/gcc-4.1.1,
/stranger/gcc-4.1.1/include does not get searched any more, while fixed
system headers continue being searched first:

$ rm /usr/local/gcc-4.1.1
$ /stranger/gcc-4.1.1/bin/gcc -c -v xx.c
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: /ftp/pub/source/gcc/gcc-4.1.1.orig/configure
--prefix=/usr/local/gcc-4.1.1 --enable-languages=c
Thread model: posix
gcc version 4.1.1
 /stranger/gcc-4.1.1/bin/../libexec/gcc/i686-pc-linux-gnu/4.1.1/cc1 -quiet -v
-iprefix /stranger/gcc-4.1.1/bin/../lib/gcc/i686-pc-linux-gnu/4.1.1/ xx.c
-quiet -dumpbase xx.c -mtune=pentiumpro -auxbase xx -version -o /tmp/ccIr1Gz5.s
ignoring nonexistent directory
/stranger/gcc-4.1.1/bin/../lib/gcc/i686-pc-linux-gnu/4.1.1/../../../../i686-pc-linux-gnu/include
ignoring nonexistent directory /usr/local/gcc-4.1.1/include
ignoring nonexistent directory
/usr/local/gcc-4.1.1/lib/gcc/i686-pc-linux-gnu/4.1.1/include
ignoring nonexistent directory /usr/local/gcc-4.1.1/i686-pc-linux-gnu/include
#include ... search starts here:
#include ... search starts here:
 /stranger/gcc-4.1.1/bin/../lib/gcc/i686-pc-linux-gnu/4.1.1/include
 /usr/local/include
 /usr/include
End of search list.
GNU C version 4.1.1 (i686-pc-linux-gnu)
compiled by GNU C version 4.1.1 (Gentoo 4.1.1).
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 36febb42c74478a1ecbe6b4467b0f6b8
 as -V -Qy -o xx.o /tmp/ccIr1Gz5.s
GNU assembler version 2.16.1 (i686-pc-linux-gnu) using BFD version 2.16.1


This is not only on linux, but on most (all?) unices too.


-- 
   Summary: changed include order when symlinking prefix or moving
binaries
   Product: gcc
   Version: 4.1.1

[Bug tree-optimization/29832] New: -ftree-loop-linear miscompiles scalarize.f90

2006-11-14 Thread jakub at gcc dot gnu dot org
gfortran.fortran-torture/execute/scalarize.f90 is miscompiled at least
on x86_64-linux with -O2 -ftree-loop-linear (other miscompiled fortran
tests with -ftree-loop-linear are forall_1.f90 and der_type.f90).

The only linear transformed loop in scalarize.f90 is the
b(:, 5:1:-1) = a
one (i.e.
int8 S.2;

S.2 = 0;
while (1)
  {
if (S.2  4) goto L.6; else (void) 0;
{
  int8 D.1343;
  int8 D.1342;
  int8 S.3;

  D.1342 = (NON_LVALUE_EXPR S.2 + 1) * 6 + -7;
  D.1343 = (5 - S.2) * 6 + -7;
  S.3 = 1;
  while (1)
{
  if (S.3  6) goto L.5; else (void) 0;
  b[NON_LVALUE_EXPR S.3 + D.1343] = a[NON_LVALUE_EXPR S.3 +
D.1342];
  S.3 = S.3 + 1;
}
  L.5:;
}
S.2 = S.2 + 1;
  }
L.6:;
).  When entering ltrans, this is not perfect nest, but perfect_nestify
changes it.  I believe that transformation is valid:

We have before ltrans (with loop entry L13 and loop exit
L85):
L12:;
  if (S.2_40  4) goto L85; else goto L86;
L86:;
  # S.2_165 = PHI S.2_40(13), 0(11);
L13:;
  S.2_40 = S.2_165 + 1;
  D.1393_41 = S.2_40 * 6;
  D.1394_43 = 5 - S.2_165;
  D.1395_44 = D.1394_43 * 6;
  pretmp.59_117 = D.1395_44 + -7;
  pretmp.59_121 = D.1393_41 + -7;
  # S.3_171 = PHI S.3_51(16), 1(14);
L15:;
  D.1343_45 = pretmp.59_117;
  D.1397_47 = pretmp.59_117 + S.3_171;
  D.1342_42 = pretmp.59_121;
  D.1398_48 = pretmp.59_121 + S.3_171;
  D.1399_49 = a[D.1398_48];
  b[D.1397_47] = D.1399_49;
  S.3_51 = S.3_171 + 1;
  if (S.3_51  6) goto L12; else goto L87;
L87:;
  goto bb 15 (L15);
This isn't perfect nest due to the pretmp.59_* MODIFY_EXPRs
and their temporaries, and perfect_nestify transforms this into:
L12:;
  if (S.2_40  4) goto L99; else goto L86;
L86:;
  # S.2_165 = PHI S.2_40(13), 0(11);
L13:;
  S.2_40 = S.2_165 + 1;
  # S.3_171 = PHI S.3_51(16), 1(14);
L15:;
  D.1393_41 = S.2_40 * 6;
  D.1394_43 = 5 - S.2_165;
  D.1395_44 = D.1394_43 * 6;
  pretmp.59_117 = D.1395_44 + -7;
  pretmp.59_121 = D.1393_41 + -7;
  D.1343_45 = pretmp.59_117;
  D.1397_47 = pretmp.59_117 + S.3_171;
  D.1342_42 = pretmp.59_121;
  D.1398_48 = pretmp.59_121 + S.3_171;
  D.1399_49 = a[D.1398_48];
  b[D.1397_47] = D.1399_49;
  S.3_51 = S.3_171 + 1;
  if (S.3_51  6) goto L12; else goto L87;
L87:;
  goto bb 15 (L15);
...
L99:;
  goto bb 44 (L100);
  # perfectiv.73_65 = PHI 0(43), perfectiv.73_4(46);
L100:;
  uboundvar.74_155 = 4 + -1;
  perfectiv.73_4 = perfectiv.73_65 + 1;
  if (uboundvar.74_155 = perfectiv.73_4) goto L101; else goto L85;
L101:;
  goto bb 44 (L100);

(this was dumped before perfect_nest call at the end of perfect_nestify).
It looks just fine to me, all it did was move the pretmp.95_* and their
temporaries setting back into the L15 loop and create a pointless empty
loop which further optimizations surely remove.

The problem is either in perfect_nest_p (i.e. question whether what
perfect_nestify created is a valid perfect nest, but identical basic blocks
could as well come just from earlier passes without perfect_nestify being ever
called), or if lambda_loopnest_to_gcc_loopnest screw this up.

The problematic statement is the:
S.2_40 = S.2_165 + 1;
which is stmt_is_bumper_for_loop for the outer loop, but isn't used solely
as the bumper, but also in the inner loop:
D.1393_41 = S.2_40 * 6;


-- 
   Summary: -ftree-loop-linear miscompiles scalarize.f90
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org


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



[Bug c/29833] gcc 4.1.2 on x86_64 Ubuntu Edgy generates incorrect prefetch instruction

2006-11-14 Thread rguenth at gcc dot gnu dot org


--- Comment #5 from rguenth at gcc dot gnu dot org  2006-11-14 16:29 ---
Please file a bug with Ubuntu instead.


-- 


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



[Bug tree-optimization/29832] -ftree-loop-linear miscompiles scalarize.f90

2006-11-14 Thread jakub at gcc dot gnu dot org


--- Comment #2 from jakub at gcc dot gnu dot org  2006-11-14 14:28 ---
Forgot to mention, the problem is reproduceable also on gcc-4_1-branch
and gcc-4_2-branch.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

   Keywords|wrong-code  |


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



[Bug c/29833] New: gcc 4.1.2 on x86_64 Ubuntu Edgy generates incorrect prefetch instruction

2006-11-14 Thread thaytan at noraisin dot net
Actual version string from gcc: 4.1.2 20060928 (prerelease) (Ubuntu
4.1.1-13ubuntu5)

Configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu
--enable-libstdcxx-debug --enable-mpfr --enable-checking=release
x86_64-linux-gnu

Using __builtin_prefetch with the default compiler flags (i.e, mtune=generic)
generates a 3dnow prefetch instruction (prefetchw), which won't run on em64t
cpus.

Attaching test file. Compiling this with gcc -otest test.c produces a binary
that faults on em64t. Compiling with 'gcc -o test -mno-3dnow test.c' generates
a prefetcht0 instruction, which works.


-- 
   Summary: gcc 4.1.2 on x86_64 Ubuntu Edgy generates incorrect
prefetch instruction
   Product: gcc
   Version: 4.1.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: thaytan at noraisin dot net
  GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu


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



[Bug c++/14032] Specialization of inner template using outer template argument doesn't work

2006-11-14 Thread pinskia at gcc dot gnu dot org


--- Comment #10 from pinskia at gcc dot gnu dot org  2006-11-14 16:30 
---
*** Bug 29830 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||zjasz at yahoo dot com


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



[Bug target/29825] [4.1 regression] ICE in extract_insn, at recog.c:2084

2006-11-14 Thread pinskia at gcc dot gnu dot org


--- Comment #14 from pinskia at gcc dot gnu dot org  2006-11-14 16:34 
---
(In reply to comment #13)
  While that can help in this case, I think letting make_tree/expand_expr 
  combo
  create invalid RTL is very dangerous (and, at least from i386 backend POV,
  some of the PIC UNSPECs not surrounded by CONST are invalid, the backend
  guarantees that wherever it creates them it adds the CONST around).

Did you read what I wrote, I said it is not valid, the x86 back-end should
really be accepting it?


-- 


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



[Bug c++/25814] Request for warning for parser ambiguity of function declarations and variable declarations with initializations

2006-11-14 Thread Raimund dot Merkert at baesystems dot com


--- Comment #6 from Raimund dot Merkert at baesystems dot com  2006-11-14 
15:52 ---
It does not seem to warn about unused functions. I also tried the following
test case where 4.0.0 (solaris)  does not warn even about foo ( I guess because
it's referenced in Y's constructor?)

gcc  -Wunused-function test.cpp 


#include cstdio

static void foo() {}

struct Y {
  Y() { foo(); }
};

struct X {
  inline X (const Y)
  {}

  inline ~X ()
  {
::std::printf(1\n);
  }

};

int main()
{
  X x(Y());
  return 0;
}


-- 


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



[Bug fortran/29657] Don't allow SAVE for functions

2006-11-14 Thread burnus at gcc dot gnu dot org


--- Comment #6 from burnus at gcc dot gnu dot org  2006-11-14 15:35 ---
Subject: Bug 29657

Author: burnus
Date: Tue Nov 14 15:35:36 2006
New Revision: 118812

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118812
Log:
fortran/
2006-11-14  Tobias Burnus  [EMAIL PROTECTED]

PR fortran/29657
* symbol.c (check_conflict): Add further conflicts.

testsuite/
2006-11-14  Tobias Burnus  [EMAIL PROTECTED]

PR fortran/29657
* gfortran.dg/conflicts.f90: Add.


Added:
trunk/gcc/testsuite/gfortran.dg/conflicts.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/symbol.c
trunk/gcc/testsuite/ChangeLog


-- 


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



[Bug c++/25814] Request for warning for parser ambiguity of function declarations and variable declarations with initializations

2006-11-14 Thread wolfgang dot roemer at gmx dot net


--- Comment #5 from wolfgang dot roemer at gmx dot net  2006-11-14 15:35 
---
[EMAIL PROTECTED] wrote:
Usually the problem will get caught as soon as you try to invoke a method, but
if it's something like a guard object, without methods, then it can be a
problem.

At least in this case there should be a warning if -Wunused-function is used,
shouldn't it?


-- 

wolfgang dot roemer at gmx dot net changed:

   What|Removed |Added

 CC||wolfgang dot roemer at gmx
   ||dot net


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



[Bug tree-optimization/29832] -ftree-loop-linear miscompiles scalarize.f90

2006-11-14 Thread rguenth at gcc dot gnu dot org


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu dot
   ||org
   Keywords||wrong-code
  Known to fail||4.1.2 4.2.0 4.3.0
   Target Milestone|--- |4.1.2


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



[Bug c/29833] gcc 4.1.2 on x86_64 Ubuntu Edgy generates incorrect prefetch instruction

2006-11-14 Thread rguenth at gcc dot gnu dot org


--- Comment #3 from rguenth at gcc dot gnu dot org  2006-11-14 15:56 ---
For SUSE 4.1.2 I get prefetcht0 generated.  So this is an Ubuntu bug.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||INVALID


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



[Bug target/16634] arm-elf-gcc problems when generating code for __attribute__ ((interrupt (IRQ)))

2006-11-14 Thread tla at thrane dot com


--- Comment #5 from tla at thrane dot com  2006-11-14 16:28 ---
(In reply to comment #4)
 What's the status of this patch?

The bug is also present in arm-elf-gcc version 4.1.0
However, adding the -fno-omit-frame-pointer parameter, make
the compiler emit the correct code in the mentioned code example.


-- 

tla at thrane dot com changed:

   What|Removed |Added

 CC||tla at thrane dot com


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



[Bug c/29833] gcc 4.1.2 on x86_64 Ubuntu Edgy generates incorrect prefetch instruction

2006-11-14 Thread thaytan at noraisin dot net


--- Comment #4 from thaytan at noraisin dot net  2006-11-14 16:09 ---
It's using -mtune=generic:

Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu
--enable-libstdcxx-debug --enable-mpfr --enable-checking=release
x86_64-linux-gnu
Thread model: posix
gcc version 4.1.2 20060928 (prerelease) (Ubuntu 4.1.1-13ubuntu5)
 /usr/lib/gcc/x86_64-linux-gnu/4.1.2/cc1 -quiet -v test.c -quiet -dumpbase
test.c -mtune=generic -auxbase test -version -fstack-protector
-fstack-protector -o /tmp/cc5wy3wa.s
ignoring nonexistent directory /usr/local/include/x86_64-linux-gnu
ignoring nonexistent directory
/usr/lib/gcc/x86_64-linux-gnu/4.1.2/../../../../x86_64-linux-gnu/include
ignoring nonexistent directory /usr/include/x86_64-linux-gnu
#include ... search starts here:
#include ... search starts here:
 /usr/local/include
 /usr/lib/gcc/x86_64-linux-gnu/4.1.2/include
 /usr/include
End of search list.
GNU C version 4.1.2 20060928 (prerelease) (Ubuntu 4.1.1-13ubuntu5)
(x86_64-linux-gnu)
compiled by GNU C version 4.1.2 20060928 (prerelease) (Ubuntu
4.1.1-13ubuntu5).
GGC heuristics: --param ggc-min-expand=98 --param ggc-min-heapsize=128174
Compiler executable checksum: 69b037dea6ceacffa2e97527b1ac3ca3
 as -V -Qy -o /tmp/ccONENBd.o /tmp/cc5wy3wa.s
GNU assembler version 2.17 (x86_64-linux-gnu) using BFD version 2.17 Debian
GNU/Linux
 /usr/lib/gcc/x86_64-linux-gnu/4.1.2/collect2 --eh-frame-hdr -m elf_x86_64
-dynamic-linker /lib64/ld-linux-x86-64.so.2 -o test
/usr/lib/gcc/x86_64-linux-gnu/4.1.2/../../../../lib64/crt1.o
/usr/lib/gcc/x86_64-linux-gnu/4.1.2/../../../../lib64/crti.o
/usr/lib/gcc/x86_64-linux-gnu/4.1.2/crtbegin.o
-L/usr/lib/gcc/x86_64-linux-gnu/4.1.2 -L/usr/lib/gcc/x86_64-linux-gnu/4.1.2
-L/usr/lib/gcc/x86_64-linux-gnu/4.1.2/../../../../lib64 -L/lib/../lib64
-L/usr/lib/../lib64 /tmp/ccONENBd.o -lgcc --as-needed -lgcc_s --no-as-needed
-lc -lgcc --as-needed -lgcc_s --no-as-needed
/usr/lib/gcc/x86_64-linux-gnu/4.1.2/crtend.o
/usr/lib/gcc/x86_64-linux-gnu/4.1.2/../../../../lib64/crtn.o


-- 


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



[Bug c++/29834] New: g++ thinks it is a declaration when it cannot be

2006-11-14 Thread james dot kanze at gmail dot com
More cases where g++ apparently doesn't take
enough context into account when deciding that
something can be (and thus is) a declaration.

Compiled the following (legal) program using g++ -c
---
struct Doh
{
Doh( int ) {}
} ;

int x = 0 ;

int
f()
{
Doh( x ), ++ x ;
return Doh( x ), x ;
}
---
Got following errors:
---
parseError.cc: In function 'int f()':
parseError.cc:11: error: no matching function for call to 'Doh::Doh()'
parseError.cc:3: note: candidates are: Doh::Doh(int)
parseError.cc:2: note: Doh::Doh(const Doh)
parseError.cc:11: error: expected unqualified-id before '++' token
parseError.cc:12: error: cannot convert 'Doh' to 'int' in return
---
Apparently, g++ is interpreting Doh( x ) as a declaration,
although in neither case is a declaration legal.  (++x is not a
legal declarator, so the first line cannot be a declaration, and
of course, a declaration cannot start with the keyword return.)

(Note that in the actual code, Doh was boost::mutex::scoped_lock.
And I fear that using boost::mutex::scoped_lock like this is becoming
a widespread idiom.)


-- 
   Summary: g++ thinks it is a declaration when it cannot be
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: james dot kanze at gmail dot com
 GCC build triplet: sparc-sun-solaris2.8
  GCC host triplet: sparc-sun-solaris2.8
GCC target triplet: sparc-sun-solaris2.8


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



[Bug fortran/29711] error_print does not support %N$X

2006-11-14 Thread fxcoudert at gcc dot gnu dot org


--- Comment #3 from fxcoudert at gcc dot gnu dot org  2006-11-14 16:44 
---
What about:

de.f90:4:

use foo, only : bar
  1
Fehler: Bei (1) referenziertes Symbol »bar« nicht im Modul »foo« gefunden

My limited german knowledge seems to indicate that it's OK, but I'm not sure.
Could you try the attached patch on a few cases (possibly including multiple
loci and such arguments reorganizations)?


-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

   Keywords||patch
   Target Milestone|--- |4.3.0


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



[Bug c++/29830] Name lookup bug for inner template specialization

2006-11-14 Thread pinskia at gcc dot gnu dot org


--- Comment #3 from pinskia at gcc dot gnu dot org  2006-11-14 16:30 ---


*** This bug has been marked as a duplicate of 14032 ***


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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



[Bug ada/29802] [4.2/4.3 Regression] wrong directory in makefile for ada and libada when srcdir=.

2006-11-14 Thread Jean-pierre dot vial at wanadoo dot fr


--- Comment #5 from Jean-pierre dot vial at wanadoo dot fr  2006-11-14 
17:11 ---
(In reply to comment #0)
 when building ada on linux (x86-64)
 building ada fails because the makefile looks for gnatbuild in
 mydir/gcc-4.2-20061107/prev-gcc
 instead of
 mydir/gcc-4.2-20061107/host-x86_64-unknown-linux-gnu/prev-gcc
 I could not find where precisely in the makefile the bug hides.
 
 for libada it is obvious:
 the make variable
 HOST_SUBDIR
 is used, but nowhere defined. 
 If I define it, libada is built
 

(In reply to comment #4)
 Created an attachment (id=12616)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12616action=view) [edit]
 patch to fix the bug
 
 
 Please try this.
 

The patch for the compiler works

the patch for libada does not, here is the error message:
Makefile:55: ../../@HOST_SUBDIR@/gcc/libada-mk: Aucun fichier ou répertoire de
ce type   (french message for no such file or directory)
I tried the patch with HOST_SUBDIR both in lowercase and uppercase,
same result.


-- 

Jean-pierre dot vial at wanadoo dot fr changed:

   What|Removed |Added

 CC||Jean-pierre dot vial at
   ||wanadoo dot fr


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



[Bug c/29833] gcc 4.1.2 on x86_64 Ubuntu Edgy generates incorrect prefetch instruction

2006-11-14 Thread thaytan at noraisin dot net


--- Comment #1 from thaytan at noraisin dot net  2006-11-14 14:26 ---
Created an attachment (id=12617)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12617action=view)
simple test file


-- 


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



[Bug c/29827] Assigning function with a char param emits a spurious warning

2006-11-14 Thread pinskia at gcc dot gnu dot org


--- Comment #1 from pinskia at gcc dot gnu dot org  2006-11-14 10:09 ---
This is not a bug, the reason is because 
void foo(char);
void (*f1)() = foo;

For foo, the prototype is not using int but instead char (or short) and f1 is
not reallying having a prototype (old KR rules).

Comeau C rejects this code as invalid with about the same error message as our
warning.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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



[Bug target/29825] [4.1 regression] ICE in extract_insn, at recog.c:2084

2006-11-14 Thread pinskia at gcc dot gnu dot org


--- Comment #8 from pinskia at gcc dot gnu dot org  2006-11-14 09:53 ---
Hmm, isn't movl %eax, [EMAIL PROTECTED] a valid way to have an
offset?



Reduced testcase:
struct _Unwind_Context
{
  void *reg[18];
};
static unsigned char dwarf_reg_size_table[18];
uw_install_context_1 (void *current,
struct _Unwind_Context *target)
{
  long i;
  for (i = 0; i  17; ++i)
{
  void *t = target-reg[i];
  if (t)
__builtin_memcpy (current, t, dwarf_reg_size_table[i]);
}
}



-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

  Component|bootstrap   |target
 GCC target triplet||i?86-*-linux-gnu


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



[Bug c++/29829] arm-linux-g++: Internal error: Killed (program cc1plus)

2006-11-14 Thread rguenth at gcc dot gnu dot org


--- Comment #1 from rguenth at gcc dot gnu dot org  2006-11-14 12:42 ---
You need to provide a preprocessed testcase, specify what gcc version you use
and what flags to compile.

arm-linux-g++: Internal error: Killed (program cc1plus)

this means the kernel (or you) killed the compiler, it probably has gone
out-of-memory.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING


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



[Bug libmudflap/19319] Mudflap produce many violations on simple, correct c++ program

2006-11-14 Thread fche at redhat dot com


--- Comment #25 from fche at redhat dot com  2006-11-14 12:19 ---
(In reply to comment #24)
 Might the problem be that I am compiling on an old glibc?

That is possible.  Try MUDFLAP_OPTIONS=-trace-calls -verbose-trace.
If you have access to a modern glibc, you could compare traces from the two
variants.

 Or that you didn't invoke ./make and didn't in fact run the resulting exe?

I certainly ran it.  env MUDFLAP_OPTIONS=-collect-stats ./make gives some
interesting figures.


-- 


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



[Bug c++/29106] [4.0 Regression] sizeof(*var) in expression drops entire line of code out of compile

2006-11-14 Thread mmitchel at gcc dot gnu dot org


--- Comment #10 from mmitchel at gcc dot gnu dot org  2006-11-14 17:14 
---
Subject: Bug 29106

Author: mmitchel
Date: Tue Nov 14 17:13:57 2006
New Revision: 118818

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118818
Log:
PR c++/29106
* g++.dg/init/self1.C: New test.

Added:
branches/gcc-4_2-branch/gcc/testsuite/g++.dg/init/self1.C
Modified:
branches/gcc-4_2-branch/gcc/testsuite/ChangeLog


-- 


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



[Bug target/29825] [4.1 regression] ICE in extract_insn, at recog.c:2084

2006-11-14 Thread rguenth at gcc dot gnu dot org


--- Comment #15 from rguenth at gcc dot gnu dot org  2006-11-14 17:14 
---
Created an attachment (id=12619)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12619action=view)
patch

This one passes a C bootstrap  regtest on x86_64.


-- 


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



[Bug c++/29106] [4.0 Regression] sizeof(*var) in expression drops entire line of code out of compile

2006-11-14 Thread mmitchel at gcc dot gnu dot org


--- Comment #11 from mmitchel at gcc dot gnu dot org  2006-11-14 17:15 
---
Subject: Bug 29106

Author: mmitchel
Date: Tue Nov 14 17:15:08 2006
New Revision: 118819

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118819
Log:
PR c++/29106
* g++.dg/init/self1.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/init/self1.C
Modified:
trunk/gcc/testsuite/ChangeLog


-- 


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



[Bug c++/27693] [4.0 Regression] strange interaction with const and sizeof and variable declarations in g++-4.0

2006-11-14 Thread mmitchel at gcc dot gnu dot org


--- Comment #5 from mmitchel at gcc dot gnu dot org  2006-11-14 17:15 
---
Fixed in 4.1 by the patch for PR 29106.


-- 

mmitchel at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|[4.0/4.1 Regression] strange|[4.0 Regression] strange
   |interaction with const and  |interaction with const and
   |sizeof and variable |sizeof and variable
   |declarations in g++-4.0 |declarations in g++-4.0


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



[Bug fortran/29711] error_print does not support %N$X

2006-11-14 Thread burnus at gcc dot gnu dot org


--- Comment #5 from burnus at gcc dot gnu dot org  2006-11-14 17:16 ---
 Fehler: Bei (1) referenziertes Symbol »bar« nicht im Modul »foo« gefunden

 My limited german knowledge seems to indicate that it's OK, but I'm not sure.
Looks ok.

 Could you try the attached patch on a few cases (possibly including multiple
 loci and such arguments reorganizations)?

I will try. It actually effects the following strings in the following
languages (see gcc/po/):

de.po-msgid Symbol '%s' referenced at %L not found in module '%s'
de.po-msgid User operator '%s' referenced at %L not found in module '%s'
de.po-msgid Intrinsic operator '%s' referenced at %L not found in module '%s'
de.po-msgid The equivalence set for variable '%s' declared at %L violates
alignment requirents

tr.po-msgid Processing spec %c%s%c, which is '%s'\n
tr.po:msgstr '%4$s' %1$c%2$s%3$c ozelligi isleniyor\n
^ This could be a challenge!
tr.po-msgid %s: warning: using formals list from %s(%d) for function '%s'\n
tr.po-msgid collect: tweaking %s in %s\n

zh_TW.po-msgid Assumed size array '%s' in namelist '%s'at %C is not allowed.
zh_TW.po-msgid Assumed shape array '%s' in namelist '%s' at %C is an
extension.
zh_TW.po-msgid Argument '%s' of pure function '%s' at %L must be INTENT(IN)

(Reminder to self: test also %s does not support %%n$ operand number
formats.)


-- 


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



[Bug debug/29792] DWARF: Not all inline concrete instances are being generated

2006-11-14 Thread acme at mandriva dot com


--- Comment #10 from acme at mandriva dot com  2006-11-14 17:19 ---
(In reply to comment #9)
 
 I'm quite aware of what GCC outputs here :)
 
 However, past the initial declarations, we don't output debug
 information about what the state of the IR is at random points in the
 compilation, only about what the final output looks like.  Since there
 is no inlined code left, we don't end up saying there is an inlined
 subroutine.
 
 Even if we could change this, i'm not sure we'd want to.  It doesn't
 seem incorrect at all to do what we do.
 Otherwise, you'd end up with inlined subroutine dies with no low
 pc/high pc associated with them, which seems nonsensical.

OK, so I'll have to find another way of using the DWARF info to see if a inline
routine, such as __task_rq_lock was used at all in the build or was just
included in the DWARF info but not referenced anywhere, have to dig more into
the available information...

BTW, if, in these cases, DW_TAG_subroutine is not referenced, what is the
purpose of it being included? Is there a reason my limited knowledge is not
realising?


-- 


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



[Bug middle-end/27881] [4.1 Regression] Memory exhausted with -finline-functions on testsuite file alias3.C

2006-11-14 Thread mmitchel at gcc dot gnu dot org


--- Comment #9 from mmitchel at gcc dot gnu dot org  2006-11-14 17:25 
---
The following simpler test case is sufficient to show the same behavior:

struct X{};
void f(X x)
{
  f(x);
  f(x);
}

Also, it is indeed true that --param max-inline-recursive-depth-auto=3 makes
this compile instantaneously, but a value of 4 makes it go for a long time.  I
understand expoentials, but 2^4 isn't that big a number, so I wonder if we're
hitting something else super-linear in here -- perhaps something that still in
later releases as well?

I am going to downgrade this to P2, as normally -finline-functions is only used
with -O3, and as the --param option provides a work-around.


-- 

mmitchel at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P1  |P2


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



[Bug c++/27826] [4.0/4.1 Regression] ICE in copy_to_mode_reg

2006-11-14 Thread mmitchel at gcc dot gnu dot org


--- Comment #14 from mmitchel at gcc dot gnu dot org  2006-11-14 17:30 
---
I cannot getting this to fail with current GCC 4.1.2 sources.  Can others still
reproduce this problem?


-- 


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



[Bug c++/14032] Specialization of inner template using outer template argument doesn't work

2006-11-14 Thread zjasz at yahoo dot com


--- Comment #11 from zjasz at yahoo dot com  2006-11-14 17:40 ---
(In reply to comment #6)
 Work postponed to GCC 4.1.  This bug is tricky to fix.

What is the status of this bug? Will be resolved in the next release?
For us is critical because a whole framework is built up on this.:,,,(
Unfortunately we don't have any workaround!

/jz


-- 


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



[Bug middle-end/27881] [4.1 Regression] Memory exhausted with -finline-functions on testsuite file alias3.C

2006-11-14 Thread rguenth at gcc dot gnu dot org


--- Comment #10 from rguenth at gcc dot gnu dot org  2006-11-14 17:42 
---
It's true that the number of created calls is 2^N, but unfortunately the number
of created temporaries grows super-exponential:

 --param max-inline-recursive-depth-auto  grep 'struct X' t.C.t24.fixupcfg 
| wc -l
   1   3
   2  63
   3   16383 (!)

So it grows like n_i = (2*(n_{i-1}+1))**2 - 1 with n_1 = 3.
For 4 we would have 1073741823, for 5 we get 4611686018427387904 number
of temporaries ;)

Honza's patch (comment #8) fixes this on the mainline, but I guess porting that
back is not really an option.  We might instead lower the default value of
max-inline-recursive-depth[-auto], which is currently 8.

From the above numbers a limit of 2 should be appropriate.  Or we can make
it count the number of functions inlined, not the depth, to avoid exponential
behavior with multiple calls to self.


-- 


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



[Bug c++/27826] [4.0/4.1 Regression] ICE in copy_to_mode_reg

2006-11-14 Thread rguenth at gcc dot gnu dot org


--- Comment #15 from rguenth at gcc dot gnu dot org  2006-11-14 17:44 
---
Yes:

gcc41-g/gcc ./cc1plus -quiet t.C -O3
t.C: In function 'int f()':
t.C:6: internal compiler error: in copy_to_mode_reg, at explow.c:577
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 GCC target triplet|i686-pc-linux-gnu   |i?86-*-* x86_64-*-*


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



[Bug c++/14032] Specialization of inner template using outer template argument doesn't work

2006-11-14 Thread rguenth at gcc dot gnu dot org


--- Comment #12 from rguenth at gcc dot gnu dot org  2006-11-14 17:46 
---
Raising severity, some more people in CC.  This at least seems to be an often
reported problem.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|normal  |critical


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



[Bug rtl-optimization/29349] mode switching is inefficient both at compile time and at run time

2006-11-14 Thread amylaar at gcc dot gnu dot org


--- Comment #1 from amylaar at gcc dot gnu dot org  2006-11-14 17:50 ---
fpchg should also be enabled in sh.md for TARGET_SH4_300


-- 


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



[Bug c++/14032] Specialization of inner template using outer template argument doesn't work

2006-11-14 Thread pinskia at gcc dot gnu dot org


--- Comment #13 from pinskia at gcc dot gnu dot org  2006-11-14 17:54 
---
(In reply to comment #12)
 Raising severity, some more people in CC.  This at least seems to be an often
 reported problem.

It is not a regression as far as I can tell.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|critical|normal


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



[Bug fortran/29835] New: Error message of non-unknown edit descriptor needs improvement

2006-11-14 Thread burnus at gcc dot gnu dot org
gfortran writes:
read(1,'(Q,A)',iostat=i) n,line(:n)
  1
Warning: Unexpected element in format string at (1)

And if there is a long comment it may even look like:
XLINE
1
Warning: Unexpected element in format string at (1)


Expected:
read(1,'(Q,A)',iostat=i) n,line(:n)
 1
Warning: Unexpected element in format string at (1)
or even:
Warning: Unexpected element 'Q' in format string at (1)

(The run-time message is also slightly misaligned:
read(1,'(Q,A)') n,line(:n)
   1

-- Test program -
integer, parameter :: MAXLINE = 255
character(MAXLINE) line
open(1,file='whatever', access='sequential',form='formatted',action='read')
do
   read(1,'(Q,A)',iostat=i) n,line(:n)
   if (i/=0) exit
! real work here
 enddo
end
-- Test program -
Cf.
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/d968667b1e3219ab

 * * *

The Q edit descriptor is, e.g., described at
http://www.helsinki.fi/atk/unix/dec_manuals/cf77au/olrm0242.htm

It is documented but not supported in g77, seems to be a DEC extension and is
supported by ifort and sunf95.
I think, gfortran does not need to support it.


-- 
   Summary: Error message of non-unknown edit descriptor needs
improvement
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Keywords: diagnostic
  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=29835



[Bug fortran/29835] Error message of non-unknown edit descriptor needs improvement

2006-11-14 Thread burnus at gcc dot gnu dot org


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2006-11-14 18:01:30
   date||


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



[Bug tree-optimization/27755] PRE confused by control flow

2006-11-14 Thread dberlin at gcc dot gnu dot org


--- Comment #8 from dberlin at gcc dot gnu dot org  2006-11-14 18:12 ---
Subject: Bug 27755

Author: dberlin
Date: Tue Nov 14 18:12:20 2006
New Revision: 118821

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118821
Log:
2006-11-14  Daniel Berlin  [EMAIL PROTECTED]

Fix PR tree-optimization/27755

* tree-ssa-pre.c: Update comments.
(bb_bitmap_sets): Add pa_in and  deferred member.
(BB_DEFERRED): New macro.
(maximal_set): New variable.
(pre_stats): Add pa_insert member.
(bitmap_set_and): Short circuit orig == dest.
(bitmap_set_subtract_values): New function.
(bitmap_set_contains_expr): Ditto.
(translate_vuses_through_block): Add phiblock argument.
(dependent_clean): New function.
(compute_antic_aux): Update for maximal_set changes.
(compute_partial_antic_aux): New function.
(compute_antic): Handle partial anticipation.
(do_partial_partial_insertion): New function.
(insert_aux): Handle partial anticipation.
(add_to_sets): Add to maximal set.
(compute_avail): Ditto.
(init_pre): Initialize maximal_set.
(execute_pre): Do partial anticipation if -O3+.

Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-pre-16.c
Modified:
trunk/   (props changed)
trunk/gcc/ChangeLog
trunk/gcc/tree-ssa-pre.c

Propchange: trunk/
('svk:merge' modified)


-- 


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



[Bug target/29825] [4.1 regression] ICE in extract_insn, at recog.c:2084

2006-11-14 Thread jason at gcc dot gnu dot org


--- Comment #16 from jason at gcc dot gnu dot org  2006-11-14 18:21 ---
(In reply to comment #15)
 patch

Please apply this patch to 4.2 and the trunk.  I've reverted my patch on the
4.1 branch, as it seems to be too risky there.


-- 


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



[Bug c++/14032] Specialization of inner template using outer template argument doesn't work

2006-11-14 Thread bangerth at math dot tamu dot edu


--- Comment #14 from bangerth at math dot tamu dot edu  2006-11-14 18:37 
---
Subject: Re:  Specialization of inner template using outer template argument
doesn't work


 It is not a regression as far as I can tell.

True. However it does produce wrong code.
W.


-- 


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



[Bug fortran/24783] Implicit none in module overwrite explicit in procedure

2006-11-14 Thread patchapp at dberlin dot org


--- Comment #2 from patchapp at dberlin dot org  2006-11-14 18:41 ---
Subject: Bug number pr24783

A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2006-11/msg00966.html


-- 


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



[Bug ada/29802] [4.2/4.3 Regression] wrong directory in makefile for ada and libada when srcdir=.

2006-11-14 Thread bonzini at gnu dot org


--- Comment #6 from bonzini at gnu dot org  2006-11-14 18:56 ---
Created an attachment (id=12620)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12620action=view)
updated patch


Right, you need this additional hunk (I didn't include the regenerated
configure, you have to run autoconf within the libada directory).

Thanks for the quick feedback.


-- 

bonzini at gnu dot org changed:

   What|Removed |Added

  Attachment #12616|0   |1
is obsolete||


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



[Bug target/29825] [4.1 regression] ICE in extract_insn, at recog.c:2084

2006-11-14 Thread ebotcazou at gcc dot gnu dot org


--- Comment #17 from ebotcazou at gcc dot gnu dot org  2006-11-14 19:45 
---
 Please apply this patch to 4.2 and the trunk.  I've reverted my patch on the
 4.1 branch, as it seems to be too risky there.

Have you really done so?


-- 


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



[Bug preprocessor/29836] New: Concatenation operator ## doesn't work with this: / ## /

2006-11-14 Thread michael dot bishop at gdcanada dot com
To whom it may concern,

I am trying to use the macro concatenation operator to make a conditional
comment.  I want a symbol that I can sprinkle throught my C code that will be
replaced either be a C++ style // comment, or it will be replaced with nothing.
 This is useful for turning on and off debug messages and other debug code.

The basic idea is to use the ## concatenation operator in a macro definition to
paste two forward slash characters ('/') together to make a C++ style comment
of the form //.  I tried this on two other C compilers and it worked on
them.  One compiler is MinGW running on my PC which is gcc version 3.2.3 (mingw
special 20030504-1).  The other one is the latest Keil C compiler for the 8051
microcontroller.  Both of these compiled the code as I expected them to.

The problem is that the gcc compilers on our Sun system and on our HP Unix
system give errors when I try to compile the same code.  The HP Unix system has
gcc version 3.4.3.

The C code file (called t.c) is:

 #define DEBUG  / ## /// disable debug code
  // #define DEBUG  //  / ## /// enable debug code

  int
  main ( void )
  {
int i ;
DEBUG int j ;  // DEBUG is either empty or //

DEBUG j = i ;

return ( 0 ) ;
  }

The compiler error messages are:

  t.c:8:1: pasting / and / does not give a valid preprocessing token
  t.c:10:1: pasting / and / does not give a valid preprocessing token

The output from the preprocessor (using the -E command line switch) is:

  int
  main ( void )
  {
int i ;
/ / int j ;

/ / j = i ;

return ( 0 ) ;
  }

I find it strange that the preprocessor puts a blank space between the two '/'
characters.  This looks like a bug to me.  I don't think there should be a
blank space between the characters.

Sincerely,

Michael Bishop
[EMAIL PROTECTED]

P.S. I know that there are many other ways to make conditional debug code, and
I have tried several of them over the last 20 years.  I am hoping that this
method can be made to work in a portable way.


-- 
   Summary: Concatenation operator ## doesn't work with this:  / ##
/
   Product: gcc
   Version: 3.4.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: preprocessor
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: michael dot bishop at gdcanada dot com


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



[Bug c++/29704] [4.1 Regression] ICE: default non-type template argument of pointer-to-member type

2006-11-14 Thread jens dot maurer at gmx dot net


--- Comment #3 from jens dot maurer at gmx dot net  2006-11-14 20:24 ---
I agree with Wolfgang's interpretation of the standard, but can't see why it
renders my original code invalid.

14.3.2/1 says that a constant expression that evaluates to a null member
pointer value is allowed as a non-type template argument, with an explicit
reference to 4.11, which explains how to obtain one (i.e. convert a null
pointer constant, e.g. 0, to a pointer-to-member type).  That's what my
original example does.  14.3.2/5 then says The following conversions are
performed on each expression used as a non-type template-argument.  There are
indeed no conversions performed for pointer-to-members, but the expression I
supplied for the non-type template-argument was (void(C::*)(int))0, not just
0 (which would have required an implicit conversion, see 4.11).  And no
conversion is necessary to convert an expression of that type to the
parameter's type, which is  void(C::*)(int).
(EDG appears to agree with me and accepts the code, FWIW.)


-- 


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



[Bug fortran/29820] ICE in fold_convert, at fold-const.c:2146

2006-11-14 Thread pault at gcc dot gnu dot org


--- Comment #5 from pault at gcc dot gnu dot org  2006-11-14 21:08 ---
The remark in #3 that the bug clears if the order of the procedures is reversed
is a giveaway:

Index: gcc/fortran/trans-types.c
===
*** gcc/fortran/trans-types.c   (revision 118704)
--- gcc/fortran/trans-types.c   (working copy)
*** gfc_get_derived_type (gfc_symbol * deriv
*** 1592,1602 
  other_equal_dts:
/* Add this backend_decl to all the other, equal derived types and
   their components in this and sibling namespaces.  */
! 
!   for (dt = derived-ns-derived_types; dt; dt = dt-next)
! copy_dt_decls_ifequal (derived, dt-derived);
! 
!   for (ns = derived-ns-sibling; ns; ns = ns-sibling)
  for (dt = ns-derived_types; dt; dt = dt-next)
copy_dt_decls_ifequal (derived, dt-derived);

--- 1592,1599 
  other_equal_dts:
/* Add this backend_decl to all the other, equal derived types and
   their components in this and sibling namespaces.  */
!   ns = derived-ns-parent ? derived-ns-parent-contained : derived-ns;
!   for (; ns; ns = ns-sibling)
  for (dt = ns-derived_types; dt; dt = dt-next)
copy_dt_decls_ifequal (derived, dt-derived);

clears the problem by associated the derived types correctly.

I had previously convinced myself that this scan across all the contained
procedures was not necessary because it should by symmetric under the
interchange of the namespaces. I need to understand why this is not so before
submitting the patch.

Richard,

Could you explain in babytalk, please, what this does?

  gcc_assert (!AGGREGATE_TYPE_P (TREE_TYPE (lse-expr))
  || TREE_TYPE (lse-expr) == TREE_TYPE (rse-expr));
  gfc_add_modify_expr (block, lse-expr,
   !AGGREGATE_TYPE_P (TREE_TYPE (lse-expr))
   ? fold_convert (TREE_TYPE (lse-expr), rse-expr)
   : rse-expr);

Is it simply that the fold_convert is simply not doing anything here? ie. when
lse and rse are not the same stuctures, having the fold_convert simply tosses
the detection of the problem elsewhere?

Paul





-- 


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



[Bug target/29825] [4.1 regression] ICE in extract_insn, at recog.c:2084

2006-11-14 Thread debian-gcc at lists dot debian dot org


--- Comment #18 from debian-gcc at lists dot debian dot org  2006-11-14 
21:09 ---
(In reply to comment #16)
 I've reverted my patch on the
 4.1 branch, as it seems to be too risky there.

afaics the patch is not yet reverted.

  Matthias


-- 


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



[Bug fortran/29821] ICE in gfc_typenode_for_spec, at fortran/trans-types.c:666ans-types.c:666

2006-11-14 Thread pault at gcc dot gnu dot org


--- Comment #4 from pault at gcc dot gnu dot org  2006-11-14 21:24 ---

 
 If the implicit none or the module ... end module is removed, the ICE goes
 away. Probably worth running using a non-optimized front-end under valgrind.
 
or replacing a = sum (eps(i:i) * eps)
by
a = sum (eps * eps)
a = sum (eps(1:1) * eps)
a = sum (eps(i:i))

also remove the problem

integer, parameter :: i = 1
and removing the assinment to i, does likewise.


Paul


-- 


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



[Bug c++/29834] g++ thinks it is a declaration when it cannot be

2006-11-14 Thread rguenth at gcc dot gnu dot org


--- Comment #1 from rguenth at gcc dot gnu dot org  2006-11-14 21:33 ---
I you use

 ( Doh ( x ) ), ++ x;

it works.  (EDG accepts the code unmodified)


-- 


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



[Bug fortran/29821] ICE in gfc_typenode_for_spec, at fortran/trans-types.c:666ans-types.c:666

2006-11-14 Thread pault at gcc dot gnu dot org


--- Comment #5 from pault at gcc dot gnu dot org  2006-11-14 21:48 ---
It gets better and better...

module gfcbug45
  implicit none
contains
  subroutine foo 
integer :: i
real:: a
real, parameter :: eps(1) = (/ 1 /)
i = 1
a = mysum (eps(i:i) * eps)
  end subroutine foo
  real function mysum (x)
real :: x(:)
mysum = sum(x)
  end function mysum
end module gfcbug45

works just fine.

Paul


-- 


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



Paypal to e-gold, StormPay to e-gold, Moneybookers - fees 5-10%

2006-11-14 Thread PayExchange
Exchange Service from Paypal to e-gold, from StormPay to e-gold, from 
Moneybookers to e-gold


SERVICE FEES:
PayPal to E-Gold: 5% - 10%
StormPay to E-Gold: 5% - 10%
Moneybookers to E-Gold: 4%-7%

PayExchange.net

www.PayExchange.net 



[Bug preprocessor/29836] Concatenation operator ## doesn't work with this: / ## /

2006-11-14 Thread neil at daikokuya dot co dot uk


--- Comment #1 from neil at daikokuya dot co dot uk  2006-11-14 22:49 
---
Subject: Re:   New: Concatenation operator ## doesn't work with this:  / ## /

michael dot bishop at gdcanada dot com wrote:-

 I am trying to use the macro concatenation operator to make a conditional
 comment.  I want a symbol that I can sprinkle throught my C code that will be
 replaced either be a C++ style // comment, or it will be replaced with 
 nothing.

There is no such thing as a conditional comment.  Only Microsoft's
preprocessor, broken in many ways, seems to support this (and those
compilers that attempt to emulate MS).  This has been discussed before;
GCC will never support this.

 The compiler error messages are:
 
   t.c:8:1: pasting / and / does not give a valid preprocessing token
   t.c:10:1: pasting / and / does not give a valid preprocessing token

This is correct.

 The output from the preprocessor (using the -E command line switch) is:
 
   int
   main ( void )
   {
 int i ;
 / / int j ;
 
 / / j = i ;
 
 return ( 0 ) ;
   }
 
 I find it strange that the preprocessor puts a blank space between the two '/'
 characters.  This looks like a bug to me.  I don't think there should be a
 blank space between the characters.

It's because the preprocessor is taking care to avoid creating something
that looks like a comment, from two separate tokens.


-- 


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



[Bug preprocessor/29836] Concatenation operator ## doesn't work with this: / ## /

2006-11-14 Thread pinskia at gcc dot gnu dot org


--- Comment #2 from pinskia at gcc dot gnu dot org  2006-11-14 22:51 ---
Not a bug as explained by Neil.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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



[Bug tree-optimization/29791] [4.3 Regression] ICE: tree check: expected ssa_name, have symbol_memory_tag in verify_ssa, at tree-ssa.c:776

2006-11-14 Thread pinskia at gcc dot gnu dot org


--- Comment #6 from pinskia at gcc dot gnu dot org  2006-11-14 22:55 ---
Janis can you do a regression hunt on this bug?


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||janis at gcc dot gnu dot org


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



[Bug fortran/29837] New: INTERFACE overloading INTENT problem - valid code is rejected

2006-11-14 Thread enok at lysator dot liu dot se
Different INTENT parameters on the first argument of overloaded subroutines
confuse the argument matching mechanism and a compiler error is generated for
code that is correct. See attached testcase.

The problem breaks my code and I see no workaround. I hope somebody can fix it
before the release.


-- 
   Summary: INTERFACE overloading INTENT problem - valid code is
rejected
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: enok at lysator dot liu dot se
 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=29837



  1   2   >