[Bug java/25239] gij failed to execute JREProperties.java

[pluto at agmk dot net]

--- Comment #3 from pluto at agmk dot net  2005-12-03 09:35 ---
I think this is a dup of PR25121


-- 


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

[Bug fortran/19669] [gfortran] ICE (segfault) on legal code

[fxcoudert at gcc dot gnu dot org]

--- Comment #9 from fxcoudert at gcc dot gnu dot org  2005-12-03 09:49 
---
(In reply to comment #8)
> The bug seems to have disappeared from current mainline and is not present
> on gomp branch either. Should it be closed?

It is fixed on both mainline and 4.1 (probably by one of Paul T's module
patches a few months ago). I think we can close it.


-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
  Known to work|4.2.0   |4.2.0 4.1.0
 Resolution||FIXED
   Target Milestone|--- |4.1.0


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

[Bug preprocessor/25240] New: _Pragma parsing problem on the gomp branch

[jakub at gcc dot gnu dot org]

#define weak_extern(symbol) _weak_extern (weak symbol)
#define _weak_extern(expr) _Pragma (#expr)
extern void foo (void);
weak_extern (foo)

void bar (void)
{
  if (foo)
foo ();
}

gives:
./xgcc -B ./ -O2 a.c -S
a.c:4: warning: malformed #pragma weak, ignored
a.c: In function ar':
a.c:8: warning: the address of oo', will always evaluate as


-- 
   Summary: _Pragma parsing problem on the gomp branch
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: preprocessor
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=25240

[Bug preprocessor/25240] _Pragma parsing problem on the gomp branch

[jakub at gcc dot gnu dot org]

--- Comment #1 from jakub at gcc dot gnu dot org  2005-12-03 10:06 ---
This prevents glibc build.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||rth at gcc dot gnu dot org
   Keywords||openmp


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

[Bug testsuite/25241] New: DejaGNU does not distinguish between errors and warnings

[gdr at gcc dot gnu dot org]

Our testsuite should be distinguishing between errors and warnings
based on GCC diagnostic markers "error: ", "warning: ", etc.


-- 
   Summary: DejaGNU does not distinguish between errors and warnings
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gdr at gcc dot gnu dot org
  GCC host triplet: platform independent


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

[Bug other/25028] TImode-to-floating conversions broken

[jsm28 at gcc dot gnu dot org]

--- Comment #2 from jsm28 at gcc dot gnu dot org  2005-12-03 13:36 ---
Patch posted  which
fixes the problems except for on ia64-hpux, and includes a discussion of the
problems on ia64-hpux and how they might be fixed.


-- 

jsm28 at gcc dot gnu dot org changed:

   What|Removed |Added

URL||http://gcc.gnu.org/ml/gcc-
   ||patches/2005-
   ||12/msg00253.html
   Keywords||patch


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

[Bug target/25242] New: [3.4] testsuite failure in i386-sse-2.c on x86_64-unknown-linux-gnu

[ghazi at gcc dot gnu dot org]

When running the 3.4 testsuite on x86_64-unknown-linux-gnu, I'm getting the
following error:

FAIL: gcc.dg/i386-sse-2.c (test for excess errors)

as shown here:
http://gcc.gnu.org/ml/gcc-testresults/2005-12/msg00083.html

The logfile says:

In file included from gcc/include/xmmintrin.h:1216,
 from testsuite/gcc.dg/i386-sse-2.c:12:
gcc/include/emmintrin.h: In function `_mm_sqrt_sd':
gcc/include/emmintrin.h:248: internal compiler error: in
instantiate_virtual_regs_lossage, at function.c:3765

Other than comments, the testcase merely has these lines:

#define static
#define __inline
#include 


-- 
   Summary: [3.4] testsuite failure in i386-sse-2.c on x86_64-
unknown-linux-gnu
   Product: gcc
   Version: 3.4.6
Status: UNCONFIRMED
  Keywords: ssemmx
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ghazi at gcc dot gnu dot org
GCC target triplet: x86_64-unknown-linux-gnu


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

[Bug tree-optimization/25243] New: Jump threading opportunity missed in tree-ssa but caught in jump1

[steven at gcc dot gnu dot org]

static const int e[4] = { 16, 16, 20, 20 };

extern void foo (unsigned long *);

void
baz (unsigned long *r)
{
  unsigned long i;

  for (i = 0; i < 4; i++)
if (e[i] == 16)
  break;

  if (i == 4)
{
  foo (r);
}
}

We have the following in the .vars tree dump:

;; Function baz (baz)

baz (r)
{
  long unsigned int i;

:
  i = 0;

:;
  if (MEM[symbol: e, index: (int *) i, step: 4B] == 16) goto ; else goto
;

:;
  i = i + 1;
  if (i != 4) goto ; else goto ;

:;
  if (i == 4) goto ; else goto ;

:;
  foo (r);

:;
  return;

}

The first jump pass on RTL immediately optimizes away the redundant jump.

This kind of jump threading opportunity occurs very often.  About half of the
jump threadings on RTL in jump1 that I have looked at so far (several dozen)
are of this form.
I'm seeing this for AMD64 and i686, but I guess it happens everywhere.


-- 
   Summary: Jump threading opportunity missed in tree-ssa but caught
in jump1
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: missed-optimization, TREE
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: steven at gcc dot gnu dot org


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

[Bug tree-optimization/25243] Jump threading opportunity missed in tree-ssa but caught in jump1

[steven at gcc dot gnu dot org]

--- Comment #1 from steven at gcc dot gnu dot org  2005-12-03 14:22 ---
I should have said, this is at "-O1 -fthread-jumps".  I guess VRP catches this
at -O2 and better.


-- 


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

[Bug tree-optimization/25243] Jump threading opportunity missed in tree-ssa but caught in jump1

[steven at gcc dot gnu dot org]

--- Comment #2 from steven at gcc dot gnu dot org  2005-12-03 14:37 ---
Actually VRP doesn't catch it.

Do:
-if (e[i] == 16)
+if (e[i] == 16)
so that store-CCP doesn't load e[0] anymore to find that it is 16.  With that,
the .vrp dump at -O2 looks like this:

baz (r)
{
  long unsigned int i;
  int D.1638;
  long unsigned int i.0;

:
  goto  ();

:;
  i_4 = i_1;
  D.1638_6 = e[i_1];
  if (D.1638_6 == 17) goto ; else goto ;

:;
  i_7 = i_1 + 1;

  # i_1 = PHI <0(0), i_7(2)>;
:;
  if (i_1 <= 3) goto ; else goto ;

:;
  if (i_1 == 4) goto ; else goto ;

:;
  foo (r_3);

:;
  return;

}

The tree loop optimizers turn "(i_1 <= 3)" into "(i_1 != 4)", but there are no
passes after VRP that use the ASSERT_EXPRs to propagate "i_1 == 4" down along
the false-edge going to the block starting with label L3.

So even at -O2 we don't catch this jump threading opportunity at the tree
level.


-- 


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

[Bug fortran/25106] statement label is zero

[fxcoudert at gcc dot gnu dot org]

--- Comment #3 from fxcoudert at gcc dot gnu dot org  2005-12-03 15:32 
---
Subject: Bug 25106

Author: fxcoudert
Date: Sat Dec  3 15:32:04 2005
New Revision: 107999

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107999
Log:
PR fortran/25106
* parse.c (next_free): Use new prototype for gfc_match_st_label.
Correctly emit hard error if a label is zero.
* match.c (gfc_match_st_label): Never allow zero as a valid
label.
(gfc_match, gfc_match_do, gfc_match_goto): Use new prototype for
gfc_match_st_label.
* primary.c (): Use new prototype for gfc_match_st_label.
* io.c (): Likewise.
* match.h: Likewise.

Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/io.c
trunk/gcc/fortran/match.c
trunk/gcc/fortran/match.h
trunk/gcc/fortran/parse.c
trunk/gcc/fortran/primary.c


-- 


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

[Bug fortran/25106] [4.0/4.1] statement label is zero

[fxcoudert at gcc dot gnu dot org]

--- Comment #4 from fxcoudert at gcc dot gnu dot org  2005-12-03 15:33 
---
Patch commited to mainline, waiting some time before commiting to 4.1.


-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||fxcoudert at gcc dot gnu dot
   ||org
   Keywords||patch
  Known to work||4.2.0
Summary|statement label is zero |[4.0/4.1] statement label is
   ||zero


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

[Bug tree-optimization/25243] Jump threading opportunity missed in tree-ssa but caught in jump1

[steven at gcc dot gnu dot org]

--- Comment #3 from steven at gcc dot gnu dot org  2005-12-03 15:46 ---
With a minor hack, we optimize the test case in dom3:

Index: tree-ssa-dom.c
===
--- tree-ssa-dom.c  (revision 107822)
+++ tree-ssa-dom.c  (working copy)
@@ -2776,7 +2776,9 @@ cprop_operand (tree stmt, use_operand_p
   /* If the operand has a known constant value or it is known to be a
  copy of some other variable, use the value or copy stored in
  CONST_AND_COPIES.  */
-  val = SSA_NAME_VALUE (op);
+  val = op;
+  while (TREE_CODE (val) == SSA_NAME && SSA_NAME_VALUE (val))
+val = SSA_NAME_VALUE (val);
   if (val && val != op && TREE_CODE (val) != VALUE_HANDLE)
 {
   tree op_type, val_type;


Jeff, thoughts?


-- 

steven at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2005-12-03 15:46:50
   date||


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

[Bug fortran/25244] New: ICE when building libgfortran

[fxcoudert at gcc dot gnu dot org]

Trying to build mainline on ia64-hpux, I get an error when building
libgfortran, which is due to the following ICE:

$ cat tmp28181.f90  
  integer (kind=1) :: i
  end
$ /tmp/debug/ibin//gcc/f951 tmp28181.f90
:0: internal compiler error: Segmentation fault


-- 
   Summary: ICE when building libgfortran
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Keywords: build
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: fxcoudert at gcc dot gnu dot org
 GCC build triplet: ia64-hp-hpux11.23
  GCC host triplet: ia64-hp-hpux11.23
GCC target triplet: ia64-hp-hpux11.23


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

[Bug web/25198] svn.html

[steven at gcc dot gnu dot org]

-- 

steven at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||gerald at pfeifer dot com
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2005-12-03 16:29:38
   date||


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

[Bug fortran/25244] ICE when building libgfortran

[fxcoudert at gcc dot gnu dot org]

--- Comment #1 from fxcoudert at gcc dot gnu dot org  2005-12-03 16:30 
---
Backtrace:

(gdb) where
#0  0x4d4f690:0 in __gmpn_copyi+0xa0 ()
#1  0x4d38180:0 in __gmpz_set () at set.c:53
#2  0x425cd80:0 in gfc_arith_init_1 () at gmp.h:1629
#3  0x42d1750:0 in gfc_init_1 () at /tmp/debug/gcc/gcc/fortran/misc.c:257
#4  0x4320990:0 in gfc_init () at /tmp/debug/gcc/gcc/fortran/f95-lang.c:313
#5  0x48b5050:0 in lang_dependent_init () at /tmp/debug/gcc/gcc/toplev.c:1842
#6  0x48b5710:0 in do_compile () at /tmp/debug/gcc/gcc/toplev.c:1947
#7  0x48b5870:0 in toplev_main (argc=2, argv=0x7830)
at /tmp/debug/gcc/gcc/toplev.c:1980
#8  0x43961f0:0 in main (argc=2, argv=0x7830)
at /tmp/debug/gcc/gcc/main.c:35


-- 


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

[Bug c/25240] [OPENMP] _Pragma parsing problem on the gomp branch

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|normal  |blocker
  Component|preprocessor|c
Summary|_Pragma parsing problem on  |[OPENMP] _Pragma parsing
   |the gomp branch |problem on the gomp branch


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

[Bug testsuite/25241] DejaGNU does not distinguish between errors and warnings

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2005-12-03 16:39 ---
Confirmed.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2005-12-03 16:39:16
   date||


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

[Bug fortran/25244] ICE when building libgfortran

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2005-12-03 16:44 ---
You have a broken GMP installed, for some reason there have been a couple
reports about this.  Maybe gfortran is the stress tester of GMP which nothing
else was before.


-- 

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=25244

[Bug tree-optimization/25243] [4.1/4.2 Regression] Jump threading opportunity missed in tree-ssa but caught in jump1

[pinskia at gcc dot gnu dot org]

--- Comment #4 from pinskia at gcc dot gnu dot org  2005-12-03 17:01 ---
This looks very much related to PR 21829.

Hmm, in 4.0.0 we got Before DOM (likewise for 4.1.0 and above):
:;
  i_2 = i_10 + 1;
  if (i_2 != 4) goto ; else goto ;

  # i_7 = PHI ;
:;
  if (i_7 == 4) goto ; else goto ;

but after:
:;
  i_2 = i_10 + 1;
  if (i_2 != 4) goto ; else goto ;

Invalid sum of incoming frequencies 2375, should be 0
  # i_7 = PHI ;
:;
  foo (r_3);

Which means that GCC got it right in 4.0.0


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

  BugsThisDependsOn||21829
  Known to fail||4.1.0 4.2.0
  Known to work||4.0.0 4.0.2
Summary|Jump threading opportunity  |[4.1/4.2 Regression] Jump
   |missed in tree-ssa but  |threading opportunity missed
   |caught in jump1 |in tree-ssa but caught in
   ||jump1
   Target Milestone|--- |4.2.0


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

[Bug java/25239] gij failed to execute JREProperties.java

[pinskia at gcc dot gnu dot org]

--- Comment #4 from pinskia at gcc dot gnu dot org  2005-12-03 17:04 ---
It might be, it works correctly on i686-linux-gnu.


-- 


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

[Bug tree-optimization/25243] [4.1/4.2 Regression] Jump threading opportunity missed in tree-ssa but caught in jump1

[steven at gcc dot gnu dot org]

--- Comment #5 from steven at gcc dot gnu dot org  2005-12-03 17:46 ---
Actually, it's more related to Bug 21488.  What happens is that we record a
value for the left hand side of a single-argument PHI node (i.e. for
"rhs=PHI(lhs)" we record an equivalence rhs==lhs), but the left hand side also
already has a value (in this case, lhs==4).

Later on we don't copy propagate lhs into the uses of rhs because lhs is
defined in a loop and we don't copy propagate out of loops, so we never see
that rhs==4 too.

My hack in comment #3 propagates the value "4" by following SSA_NAME_VALUE
links as deeply as possible.  What we should probably do instead is look
through SSA_NAME_VALUE chains in record_equivalences_from_phis.


-- 


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

[Bug ada/25245] New: Discriminant is left uninitialized.

[listor1 dot rombobeorn at comhem dot se]

The attached file uninitialized_field.adb demonstrates a case where a 
discriminant of a record isn't initialized. I compile and run it like this:

$ gnatmake uninitialized_field.adb
gcc -c uninitialized_field.adb
gnatbind -x uninitialized_field.ali
gnatlink uninitialized_field.ali
$ ./uninitialized_field
Initialized with Unified_Encoding_Record aggregate:
With predefined "=" - A1a and A2a: equal
Initialized with Character_Encoding aggregate:
With predefined "=" - A1b and A2b: not equal
With redefined "=" - B1c and B2c: equal
OS of A1a: LINUX
OS of A2a: LINUX
OS of A1b: OS2
OS of A2b:

raised CONSTRAINT_ERROR : uninitialized_field.adb:117 invalid data

Correct output would be:

Initialized with Unified_Encoding_Record aggregate:
With predefined "=" - A1a and A2a: equal
Initialized with Character_Encoding aggregate:
With predefined "=" - A1b and A2b: equal
With redefined "=" - B1c and B2c: equal
OS of A1a: LINUX
OS of A2a: LINUX
OS of A1b: LINUX
OS of A2b: LINUX

The other attached file, convert_to_pointer.ada, contains relevant parts 
of the code in uninitialized_field.adb, but here the declarations are in 
a package and are referenced from the main program. This causes a very 
strange error message:

$ gnatmake convert_to_pointer_package.ads
gcc -c convert_to_pointer_package.ads
$ LANG=en_US gnatmake convert_to_pointer_main.adb
gcc -c convert_to_pointer_main.adb
convert_to_pointer_package.ads: In function `Convert_To_Pointer_Main':
convert_to_pointer_package.ads:37: error: cannot convert to a pointer type
gnatmake: "convert_to_pointer_main.adb" compilation error

Both these test cases fail on all of the following compilers:

$ LANG=C gcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.1-20051112/configure
--prefix=/home/bjorn/ada/gcc-4.1-20051112-inst --enable-libada
--enable-languages=ada,c
Thread model: posix
gcc version 4.1.0 20051112 (experimental)

$ LANG=C gcc -v
Using built-in specs.
Target: i386-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-libgcj-multifile
--enable-languages=c,c++,objc,java,f95,ada --enable-java-awt=gtk
--with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre
--host=i386-redhat-linux
Thread model: posix
gcc version 4.0.2 20051125 (Red Hat 4.0.2-8)

$ gcc -v
Reading specs from
/home/bjorn/ada/gcc-3.4.0-inst/lib/gcc/i686-pc-linux-gnu/3.4.0/specs
Configured with: /home/bjorn/ada/gcc-3.4.0/configure
--prefix=/home/bjorn/ada/gcc-3.4.0-inst
Thread model: posix
gcc version 3.4.0

Note: I originally submitted these test cases to bug 17160, but that bug has
been fixed, and indeed that ICE no longer happens. These tests still fail
though, so I'm making a separate report for them.


-- 
   Summary: Discriminant is left uninitialized.
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: listor1 dot rombobeorn at comhem 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=25245

[Bug ada/25245] Discriminant is left uninitialized.

[listor1 dot rombobeorn at comhem dot se]

--- Comment #1 from listor1 dot rombobeorn at comhem dot se  2005-12-03 
17:54 ---
Created an attachment (id=10397)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10397&action=view)
demonstrates uninitialized discriminant


-- 


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

[Bug ada/25245] Discriminant is left uninitialized.

[listor1 dot rombobeorn at comhem dot se]

--- Comment #2 from listor1 dot rombobeorn at comhem dot se  2005-12-03 
17:55 ---
Created an attachment (id=10398)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10398&action=view)
demonstrates strange error message


-- 


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

[Bug tree-optimization/25243] [4.1/4.2 Regression] Jump threading opportunity missed in tree-ssa but caught in jump1

[law at redhat dot com]

--- Comment #6 from law at redhat dot com  2005-12-03 18:27 ---
Subject: Re:  [4.1/4.2 Regression] Jump
threading opportunity missed in tree-ssa but caught in jump1

On Sat, 2005-12-03 at 17:46 +, steven at gcc dot gnu dot org wrote:
> 
> --- Comment #5 from steven at gcc dot gnu dot org  2005-12-03 17:46 
> ---
> Actually, it's more related to Bug 21488.  What happens is that we record a
> value for the left hand side of a single-argument PHI node (i.e. for
> "rhs=PHI(lhs)" we record an equivalence rhs==lhs), but the left hand side also
> already has a value (in this case, lhs==4).
> 
> Later on we don't copy propagate lhs into the uses of rhs because lhs is
> defined in a loop and we don't copy propagate out of loops, so we never see
> that rhs==4 too.
> 
> My hack in comment #3 propagates the value "4" by following SSA_NAME_VALUE
> links as deeply as possible.  What we should probably do instead is look
> through SSA_NAME_VALUE chains in record_equivalences_from_phis.
The reason we don't generally walk through those chains is it is
possible to get loops in the value chain.  I've always considered
this a semi-bug in DOM.

Jeff


-- 


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

[Bug c++/25236] FAIL: g++.dg/warn/huge-val1.C (test for excess errors)

[danglin at gcc dot gnu dot org]

--- Comment #5 from danglin at gcc dot gnu dot org  2005-12-03 19:16 ---
The problem went away when I removed the old headers, so closing as
invalid.


-- 

danglin at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug c/25246] New: [gomp] #pragma pack() inside of structure

[jakub at gcc dot gnu dot org]

#pragma pack(1)
struct S
{
  char h;
  int i;
#pragma pack()
  int j;
};
struct S s;
void *i = &s.i, *j = &s.j;

(distilled from Linux kernel) used to compile in 4.0.x, though the whole struct
wasn't really packed at all (i at offset 4, j at offset 8).
gomp #pragma handling rejects this.

Another testcase is:
#pragma pack(1)
struct S
{
  char h;
  struct T { int h1; char h2[3]; } t;
  int i;
#pragma pack()
  int j;
};
struct S s;
void *i = &s.i, *j = &s.j;
void *h1 = &s.t.h1, *h2 = &s.t.h2[0];

Here, h1 was s+1, h2 s+5, i s+8 and j s+12, i.e. struct T used to be packed
and struct S wasn't packed.


-- 
   Summary: [gomp] #pragma pack() inside of structure
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Keywords: openmp
  Severity: normal
  Priority: P3
 Component: c
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=25246

[Bug target/25242] [3.4] testsuite failure in i386-sse-2.c on x86_64-unknown-linux-gnu

[ghazi at gcc dot gnu dot org]

--- Comment #1 from ghazi at gcc dot gnu dot org  2005-12-03 19:39 ---
I configured with --enable-checking=yes,rtl however I don't think that's
necessary to trigger the error.  I see another report without checking here
that fails the test.

http://gcc.gnu.org/ml/gcc-testresults/2005-12/msg00129.html


-- 


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

[Bug target/25242] [3.4] testsuite failure in i386-sse-2.c on x86_64-unknown-linux-gnu

[ghazi at gcc dot gnu dot org]

--- Comment #2 from ghazi at gcc dot gnu dot org  2005-12-03 19:41 ---
Here's a reduced testcase, compile it with cc1 targetted to
x86_64-unknown-linux-gnu:

cc1 -fpreprocessed i386-sse-2.i -quiet -dumpbase i386-sse-2.c -msse -mtune=k8
-auxbase-strip i386-sse-2.s -O0 -version -o i386-sse-2.s


typedef double __v2df __attribute__ ((mode (V2DF)));
 __v2df
_mm_sqrt_sd (__v2df __A, __v2df __B)
{
  __v2df __tmp = __builtin_ia32_movsd ((__v2df)__A, (__v2df)__B);
  return (__v2df)__builtin_ia32_sqrtsd ((__v2df)__tmp);
}


-- 


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

[Bug target/25203] [4.0] enable checking failure in g++.dg/opt/mmx2.C

[ghazi at gcc dot gnu dot org]

--- Comment #1 from ghazi at gcc dot gnu dot org  2005-12-03 20:06 ---
Here's a reduced testcase, configure 4.0.x with --enable-checking=yes,rtl
--target=i686-pc-linux-gnu and compile with:

cc1plus -fpreprocessed mmx2.ii -quiet -dumpbase mmx2.C -mmmx -mtune=pentiumpro
-auxbase mmx2 -O2 -version -fmessage-length=0 -o mmx2.s


typedef int __m64 __attribute__ ((__vector_size__ (8)));

static __inline void
_mm_empty (void)
{
  __builtin_ia32_emms ();
}

static __inline __m64
_mm_set_pi32 (int __i1, int __i0)
{
  return (__m64) __builtin_ia32_vec_init_v2si (__i0, __i1);
}

static union u { __m64 m; long long l; } u;
extern "C" void abort (void);

__attribute__((noinline))
void bar (__m64 x)
{
  u.m = x;
}

int
main ()
{
  bar (_mm_set_pi32 (0x00FF,0x00FF));
  _mm_empty ();
  if (u.l != 0xff00ffLL)
abort ();
  return 0;
}


-- 


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

help outport

[david pasha]

Hi,
i want send word (16 bit) to I/O
in borland C V3.0  i write for send 0xf
to port address ox56

#include 
int main(void)
{
asm {
 mov dx,0x56
 mov ax,0xf
 out dx,ax
}
return 0;
}

OR

#include 
int main(void)
{
outport(0x56,0xf);
return 0;
}

but when write this code in one file
and compile with  gcc
it send error 
please send to me correct code
for this work.
i have just problem in  out
thanks




__ 
Yahoo! DSL – Something to write home about. 
Just $16.99/mo. or less. 
dsl.yahoo.com 

asm outport

[david pasha]

Hi,
i want send word (16 bit) to I/O
in borland C V3.0  i write for send 0xf
to port address ox56

#include 
int main(void)
{
asm {
 mov dx,0x56
 mov ax,0xf
 out dx,ax
}
return 0;
}

OR

#include 
int main(void)
{
outport(0x56,0xf);
return 0;
}

but when write this code in one file
and compile with  gcc
it send error 
please send to me correct code
for this work.
i have just problem in  out  & in
or outport and inport.
thanks




__ 
Start your day with Yahoo! - Make it your home page! 
http://www.yahoo.com/r/hs

[Bug web/25198] svn.html

[gerald at pfeifer dot com]

-- 

gerald at pfeifer dot com changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |gerald at pfeifer dot com
   |dot org |
 Status|NEW |ASSIGNED


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

[Bug c++/23307] [3.4 Regression] ICE in cp_parser_template_id, at cp/parser.c:8564 with Boost remote_call_manager

[reichelt at gcc dot gnu dot org]

--- Comment #11 from reichelt at gcc dot gnu dot org  2005-12-03 23:18 
---
Taking care of the backport.


-- 

reichelt at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|mark at codesourcery dot com|reichelt at gcc dot gnu dot
   ||org
URL||http://gcc.gnu.org/ml/gcc-
   ||patches/2005-
   ||12/msg00282.html
 Status|REOPENED|ASSIGNED


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

[Bug c++/22464] [3.4 Regression] ICE on classes in template functions which attempt closure

[reichelt at gcc dot gnu dot org]

--- Comment #12 from reichelt at gcc dot gnu dot org  2005-12-03 23:20 
---
Taking care of the backport.


-- 

reichelt at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|mark at codesourcery dot com|reichelt at gcc dot gnu dot
   ||org
URL||http://gcc.gnu.org/ml/gcc-
   ||patches/2005-
   ||12/msg00283.html
 Status|REOPENED|ASSIGNED
   Keywords||patch


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

[Bug middle-end/25022] [3.4 regression] failure to transform the unlocked stdio calls

[ghazi at gcc dot gnu dot org]

--- Comment #8 from ghazi at gcc dot gnu dot org  2005-12-03 23:32 ---
3.4 patch here:
http://gcc.gnu.org/ml/gcc-patches/2005-12/msg00284.html


-- 

ghazi at gcc dot gnu dot org changed:

   What|Removed |Added

URL||http://gcc.gnu.org/ml/gcc-
   ||patches/2005-
   ||12/msg00284.html


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

[Bug testsuite/25247] New: syntax error in target selector for gcc.dg/torture/fp-int-convert-float128-timode.c

[billingd at gcc dot gnu dot org]

Test gcc.dg/torture/fp-int-convert-float128-timode.c fails with

ERROR: gcc.dg/torture/fp-int-convert-float128-timode.c: syntax error in target
selector "target ia64-*-* && lp64" for " dg-xfail-if 5 "" { "ia64-*-* && lp64"
} { "*" } { "" } "

This happens several platforms, including:
 i686-pc-cygwin 
 ia64-unknown-linux-gnu
 86_64-unknown-linux-gnu


See:
http://gcc.gnu.org/ml/gcc-testresults/2005-12/msg00173.html
http://gcc.gnu.org/ml/gcc-testresults/2005-12/msg00171.html
http://gcc.gnu.org/ml/gcc-testresults/2005-12/msg00156.html


Most likely due to patch:

2005-11-29  Joseph S. Myers  <[EMAIL PROTECTED]>

* gcc.dg/torture/fp-int-convert-timode.c: XFAIL only on lp64
targets.
* gcc.dg/torture/fp-int-convert-float128-timode.c: XFAIL also for
LP64 ia64.


-- 
   Summary: syntax error in target selector for gcc.dg/torture/fp-
int-convert-float128-timode.c
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: billingd at gcc dot gnu dot org
 GCC build triplet: i686-pc-cygwin
  GCC host triplet: i686-pc-cygwin
GCC target triplet: i686-pc-cygwin


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

[Bug testsuite/25247] syntax error in target selector for gcc.dg/torture/fp-int-convert-float128-timode.c

[billingd at gcc dot gnu dot org]

--- Comment #1 from billingd at gcc dot gnu dot org  2005-12-03 23:35 
---
Seen on multiple platforms by different testers.


-- 

billingd at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2005-12-03 23:35:21
   date||


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

[Bug testsuite/25247] syntax error in target selector for gcc.dg/torture/fp-int-convert-float128-timode.c

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2005-12-03 23:35 ---
Confirmed.


-- 


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

[Bug testsuite/25247] syntax error in target selector for gcc.dg/torture/fp-int-convert-float128-timode.c

[jsm28 at gcc dot gnu dot org]

--- Comment #3 from jsm28 at gcc dot gnu dot org  2005-12-03 23:42 ---
Janis is testing a patch:
.


-- 

jsm28 at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||janis187 at us dot ibm dot
   ||com


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

[Bug c/25240] [OPENMP] _Pragma parsing problem on the gomp branch

[rth at gcc dot gnu dot org]

-- 

rth at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |rth at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2005-12-03 23:45:41
   date||


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

[Bug libstdc++/25025] Failure to build, :1:2: error: missing '(' after predicate

[pda at freeshell dot org]

--- Comment #7 from pda at freeshell dot org  2005-12-04 00:06 ---
Subject: Re:  Failure to build, :1:2: error: missing '(' after
predicate

On Tue, Nov 29, 2005 at 10:00:39PM -, dave at hiauly1 dot hia dot nrc dot
ca wrote:
> 
> --- Comment #6 from dave at hiauly1 dot hia dot nrc dot ca  2005-11-29 
> 22:00 ---
> Subject: Re:  Failure to build, :1:2: error: missing '(' after
> predicate
> 
> > On Sun, Nov 27, 2005 at 06:57:05PM -, danglin at gcc dot gnu dot org 
> > wrote:
> > > The "-Aa" option is likely the problem.  It's probably set in
> > > CFLAGS.  If you're using the HP tools, put the "-Aa" in your CC
> > > define.  There's more info in the manual on this.
> > 
> > No, I never put "-Aa" in CFLAGS, it's being added inside the gcc build
> > itself.  I tried your suggestion of adding "-Aa" to CC, but my build
> > fails much earlier in that case, due to not finding a definition of
> > "struct stat".  Do you care to know more about that?
> 
> Ok, this is comming from the configure test "checking for $CC option to
> accept ANSI C".  This option shouldn't be used for the libstdc++ build
> but obviously it is...

Thanks for your help, it turns out you were almost right the first time.
Although I wasn't setting CFLAGS, I unwittingly had "-Aa" in my CXXFLAGS.
Stopping that solved my problem.

> In order to build GCC 3.4 and later, you need an ANSI compiler.  You
> also need to include the full HP-UX namespace   The  "struct stat" error
> probably is a result of not providing the appropriate namespace defines
> in you CC define.  -Aa provides strict ANSI.  For example, these are
> the defines that I use for GCC builds prior to 4.0 under HP-UX 11.11:
> 
> -D_HPUX_SOURCE -D_XOPEN_UNIX -D_XOPEN_SOURCE_EXTENDED
> -D_INCLUDE__STDC_A1_SOURCE -D_INCLUDE_XOPEN_SOURCE_500
> 
> -D_HPUX_SOURCE is the important define.  The others are needed for C++
> library support (wide characters, etc).

I've mostly always used HP's ANSI compiler in the default -Ae mode,
which includes -D_HPUX_SOURCE, however I discovered it also add +e,
which allows `long long'.  All 3.4 and 4.0 gcc's I tried had `long
long' variables that required this.  I found this odd, given that I
was building 64-bit code.  I'd say this is a bug -- would you agree?

> Instead of trying to build C++ starting with an HP compiler, it's easier
> to just build C and then use this compiler to rebuild GCC with the additional
> languages that you want.  It's always been tricky to bootstrap GCC using
> an HP compiler and its not tested much.  You should use binutils (current
> CVS version is needed with GCC 4.1 and later for EH exception support).

I can appreciate that, and was almost about to resort to C only, but
my C++ is good now.  Is binutils-2.16.1 fine for 4.0?  I'll run the
tests and find out for myself anyway.

Thanks again.


-- 


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

[Bug c/25248] New: 2.6.15-rc4 arch/powerpc/mm/hash_utils_64.c miscompiled

[olh at suse dot de]

current kernels do not boot, they hang after 'returning from prom_init'
gcc4.1 and mainline miscompile arch/powerpc/mm/hash_utils_64.c.
Taking the object file from a gcc4.0 compiled tree fixes booting.

gcc-mainline r108000 binutils-mainline -> fails
gcc-4_0-branch r107977 binutils-mainline -> works
gcc-4_1-branch r106530 (+patch r106693 from bug #24644) binutils-mainline
2005-11-05 -> fails


-- 
   Summary: 2.6.15-rc4 arch/powerpc/mm/hash_utils_64.c miscompiled
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: olh at suse dot de
 GCC build triplet: powerpc64-linux
  GCC host triplet: powerpc64-linux
GCC target triplet: powerpc64-linux


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

[Bug c/25248] 2.6.15-rc4 arch/powerpc/mm/hash_utils_64.c miscompiled

[olh at suse dot de]

--- Comment #1 from olh at suse dot de  2005-12-04 01:36 ---
Created an attachment (id=10400)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10400&action=view)
PR25248.tar.bz2

buildscripts and preprocessed files.


-- 


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

[Bug middle-end/25022] [3.4 regression] failure to transform the unlocked stdio calls

[ghazi at gcc dot gnu dot org]

--- Comment #9 from ghazi at gcc dot gnu dot org  2005-12-04 01:37 ---
Subject: Bug 25022

Author: ghazi
Date: Sun Dec  4 01:37:23 2005
New Revision: 108010

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108010
Log:
2005-12-03  Kaveh R. Ghazi  <[EMAIL PROTECTED]>

PR middle-end/25022
* builtins.c (expand_builtin_fputs, expand_builtin_printf,
expand_builtin_fprintf): Lookup the explicit replacement functions
for any unlocked stdio builtin transformations.

* builtins.c (expand_builtin_fputs): Defer check for missing
replacement functions.

testsuite:
* gcc.c-torture/execute/stdio-opt-1.c,
gcc.c-torture/execute/stdio-opt-2.c,
gcc.c-torture/execute/stdio-opt-3.c: Test the unlocked style.


Modified:
branches/gcc-3_4-branch/gcc/ChangeLog
branches/gcc-3_4-branch/gcc/builtins.c
branches/gcc-3_4-branch/gcc/testsuite/ChangeLog
branches/gcc-3_4-branch/gcc/testsuite/gcc.c-torture/execute/stdio-opt-1.c
branches/gcc-3_4-branch/gcc/testsuite/gcc.c-torture/execute/stdio-opt-2.c
branches/gcc-3_4-branch/gcc/testsuite/gcc.c-torture/execute/stdio-opt-3.c


-- 


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

[Bug middle-end/25022] failure to transform the unlocked stdio calls

[ghazi at gcc dot gnu dot org]

--- Comment #10 from ghazi at gcc dot gnu dot org  2005-12-04 01:54 ---
Fixed on all active branches


-- 

ghazi at gcc dot gnu dot org changed:

   What|Removed |Added

URL|http://gcc.gnu.org/ml/gcc-  |
   |patches/2005-   |
   |12/msg00284.html|
 Status|ASSIGNED|RESOLVED
  Known to fail|3.4.5   |
  Known to work|4.0.3 4.1.0 4.2.0   |3.4.5 4.0.3 4.1.0 4.2.0
 Resolution||FIXED
Summary|[3.4 regression] failure to |failure to transform the
   |transform the unlocked stdio|unlocked stdio calls
   |calls   |
   Target Milestone|4.0.3   |3.4.6


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

[Bug libstdc++/25191] exception_defines.h #defines try/catch

[hhinnant at apple dot com]

--- Comment #16 from hhinnant at apple dot com  2005-12-04 02:12 ---
(In reply to comment #15)
> Subject: Re:  exception_defines.h #defines try/catch
> 
> I don't think anybody is disputing that.  It is also a simple fact
> that GCC documents what happens with -fno-exceptions.

I think it is good that gcc documents what it does, and I am also impressed
with the gcc documentation in general.  But just because something is
documented doesn't make it the best answer.  Thank you for letting me know this
behaivor is documented (I hadn't even tried to look that up, and still haven't
found it).  It is still a customer-hostile solution.

> Trying not to abide by the rules and getting back and shouting for
> hostility is a joke.  A sad one, Howard :-(

I'm not shouting (no caps, not even an exlamation point), but perhaps my
vocabulary needs explaining.  I'm a pretty simple guy.  And I'm also very
customer focused in everything I do (even in situations that are not
traditionally vendor/customer).  If a solution seems to work for customers very
well, I'll often call it customer-friendly.  If a solution seems to work for
customers very poorly, I'll often call it customer-hostile.  I'm not trying to
shout or make any jokes.  It is simply the way I work.  My apologies for not
explaining that up front.

But I won't apologize for being customer focused.  That focus has served me
well over the past two decades.  If I provide a service, and those who I'm
providing the service to don't find that service useful, I'll look inward first
- every single time.  I'll continue to think about solutions from the
customer's viewpoint as best I am able.  And if or when I ever find myself
having trouble doing that, I pray I'm able to retire.

> No. ObjC++ is messing with itself.

I don't know what that means.  Or even how it would be relevant.  ObjC++ is
what it is.  If you or I don't like ObjC++, is that relevant?

> Either you don't want to use it, and you don't.  Or you want to use it
> and you have to abide by what it does.  

Maybe it does the wrong thing.  We have customer complaints.

> Then, why what is this PR is about in the first place?

My bad for not explaining it better in the original post.

This PR is about the fact that although our customers find the compiler's
definition of -fno-exceptions useful, and want use it, but they find the
libstdc++'s reaction to this compiler flag unhelpful.  Furthermore, making
libstdc++'s behavior under -fno-exceptions to actually be useful for our
customers is nearly trivial.  Yes readability takes a minor hit.  But
functionality/usefulness increases.

I really don't even understand why this is controversial.  This is a minor
issue that will have absolutely no impact on our C++ customers, and will make
our ObjC++ customers much happier.  If someone had raised a point about how we
are harming our C++ customers with this fix, I would have been alarmed and
searched for a solution that didn't harm our C++ customers.  If it was a major
imposition from an implementation point of view, I would be alarmed.  But as it
is, all I'm hearing is that there is an objection to helping our ObjC++
customers at the expense of a very minor readability hit in libstdc++
internals.  I'm honestly very confused by that response.

-Howard


-- 


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

[Bug middle-end/25248] 2.6.15-rc4 arch/powerpc/mm/hash_utils_64.c miscompiled

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2005-12-04 02:19 ---
As far as I can see, the tree level is fine.


-- 


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

[Bug libstdc++/25191] exception_defines.h #defines try/catch

[gdr at integrable-solutions dot net]

--- Comment #17 from gdr at integrable-solutions dot net  2005-12-04 02:54 
---
Subject: Re:  exception_defines.h #defines try/catch

"hhinnant at apple dot com" <[EMAIL PROTECTED]> writes:

[...]

| But I won't apologize for being customer focused.

Geeat!  And people disagreeing with you on this point are not necessary
customer unfocused.

[...]

| > No. ObjC++ is messing with itself.
| 
| I don't know what that means.  Or even how it would be relevant.  ObjC++ is
| what it is.  If you or I don't like ObjC++, is that relevant?

I'm quite disappointed you reduced this issue to liking/disliking ObjC++.
If you believe that is the appropriate reduction, this is my last
message on the issue.  The rest clarifies what I said earlier.

This issue has nothing to do with liking or disliking ObjC++, not
matter how much of "hostility" or other "emotion" you would like to
inject into it.  ObjC++ got it wrong, it got it wrong.  The place to
fix it is in ObjC++.  That has nothing to do with liking or disliking
ObjC++. 

[...]

| I'm honestly very confused by that response.

I would not guess that it is partly because you seem to approach the
issue only from ObjC++-centric point of view.  This is issue is not
just fixing ObjC++ by uglifying libstdc++.  Those macro definitions of
try/catch when -fno-exceptions have been there long before ObjC++ came
in.  It is not like we're suddenly changing them.  
The uglification you're proposing is also breaking interfaces:  All
user codes that worked with both -fexceptions and -fno-exceptions and
used try/catch now will break.  I don't think I'm prepared to accept
that breakage.  The fix is simple for ObjC++: #undef them if it thinks
it wants both -fno-exceptions, libstdc++ headers.

-- Gaby


-- 


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

[Bug middle-end/25125] [4.1/4.2 Regression] (short) ((int)(unsigned short) + (int)) is done in the wrong type

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|normal  |critical


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

[Bug c++/24009] [4.0/4.1/4.2 regression] C++ fails to print #include stack

[pinskia at gcc dot gnu dot org]

--- Comment #9 from pinskia at gcc dot gnu dot org  2005-12-04 04:22 ---
(In reply to comment #8)
> What are the issues that get in the way of having --enable-mapped-location
> always?

Getting Ada fixed and getting some regressions fixed with
--enable-mapped-location.


-- 


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

[Bug tree-optimization/15458] Combine ~ and ^.

[pinskia at gcc dot gnu dot org]

--- Comment #6 from pinskia at gcc dot gnu dot org  2005-12-04 04:27 ---
I am no longer going to fix the fold issue, it is too much hasle to get this
fixed.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug middle-end/23673] fold does not fold (a^b) != 0 to a != b

[pinskia at gcc dot gnu dot org]

--- Comment #5 from pinskia at gcc dot gnu dot org  2005-12-04 04:28 ---
I am no longer going to work on this, it is too much hasle to get this fixed.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|pinskia at gcc dot gnu dot  |unassigned at gcc dot gnu
   |org |dot org
URL|http://gcc.gnu.org/ml/gcc-  |
   |patches/2005-   |
   |12/msg00286.html|
 Status|ASSIGNED|NEW
   Keywords|patch   |


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

[Bug rtl-optimization/25195] code fails at -O1, works at -O0

[duraid at octopus dot com dot au]

--- Comment #2 from duraid at octopus dot com dot au  2005-12-04 04:36 
---
Marking this bug invalid - the code in question turned out to have a GC that
did not correctly support IA64's RSE. With optimization, stuff was getting
hidden from the GC in the RSE backing store and incorrectly being freed.


-- 

duraid at octopus dot com dot au changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug c++/22252] [4.0 Regression] pragma interface/implementation still break synthesized methods

[halcy0n at gentoo dot org]

--- Comment #9 from halcy0n at gentoo dot org  2005-12-04 04:49 ---
Created an attachment (id=10401)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10401&action=view)
preprocessed output that causes ICE

This patch seems to cause another ICE.  I applied the patch on gcc-4.0 to fix
this bug, and now the attached output causes an ICE with >= -O1 (the same seems
to be true on gcc-4.1 as well).  Reverting the patch seems to stop the new ICE.


-- 


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

[Bug c++/25156] [3.4/4.0/4.1/4.2 Regression] wrong error message (int instead of bool)

[gdr at gcc dot gnu dot org]

--- Comment #6 from gdr at gcc dot gnu dot org  2005-12-04 05:00 ---
Working on a patch.
Fixing this issue has a deep "type" implications on the way we currently
hand inputs with erronous types whereas trying to progress as much as possible.


-- 

gdr at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |gdr at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2005-11-29 16:40:35 |2005-12-04 05:00:09
   date||


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

[Bug c++/25137] Warning "missing braces around initializer" causing problems with tr1::array

[gdr at gcc dot gnu dot org]

--- Comment #8 from gdr at gcc dot gnu dot org  2005-12-04 05:04 ---
(In reply to comment #0)
> The following code:
> 
> struct S
> { int x[3]; };
> 
> void f()
> { S s = {1,2,3};}
> 
> With -Wmissing-braces (which is implied by -Wall, among others) gives:
> 
> warning: missing braces around initializer for 'int [3]'
> 
> In the specific case where a struct contains only a single array, adding the
> extra braces doesn't really seem that useful.
> 
> The reason it would be nice to fix this that in the definition of tr1::array 
> in
> the TR1 specification (page 88, 6.2.2) says

After more thoughts on this issue, it appears to me that it is asking for
a special casing  justforo tr1::array<> to work.  I don't know whether
that is a workable approach.  I would reommend -Wno-missing-braces in this
specific case.  Thoughts?


-- 

gdr at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||gdr at gcc dot gnu dot org


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

[Bug c++/24702] Koenig found functoid ref, but "cannot be used as a function"

[gdr at gcc dot gnu dot org]

--- Comment #4 from gdr at gcc dot gnu dot org  2005-12-04 05:09 ---
this issue should be resolved one way of the other based on the
core issue about argument dependent lookup specification, when a
non-function is found.  The "obvious" solution would be to do overload
resolution based on the signatures (whether actual function, constructor, 
function objects, or references to those).  However, all that needs
tracking the open core issue.


-- 

gdr at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||gdr at gcc dot gnu dot org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2005-12-04 05:09:46
   date||


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

[Bug c++/24594] name lookup and partial ordering

[gdr at gcc dot gnu dot org]

--- Comment #2 from gdr at gcc dot gnu dot org  2005-12-04 05:14 ---
The behaviour is what Standard C++ mandates.  Explicit qualification in 
the template instructs the compiler to consider only the overload set 
avaliable at the definition context, not instantiation context,

-- Gaby


-- 

gdr at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||gdr at gcc dot gnu dot org
 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug c++/24222] The gimplifier shouldn't emit warnings or errors

[gdr at gcc dot gnu dot org]

--- Comment #7 from gdr at gcc dot gnu dot org  2005-12-04 05:17 ---
(In reply to comment #3)
> right now if we don't gimplify with -fsyntax-only, we would not be able to
> diagnostic the following:
> void f(void)
> {
>   break;
> }

If that is true, then it should be considered a bug in the C++ front-end. 


-- 

gdr at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||gdr at gcc dot gnu dot org


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