[Bug middle-end/19304] [4.0 Regression] wrong code for spec test from emit_move_change_mode

[rth at gcc dot gnu dot org]

--- Additional Comments From rth at gcc dot gnu dot org  2005-01-13 08:11 
---
My new code, so I'll own the bug.  But I'm a bit confused by this.  In what 
sort of situation are we requiring the subreg built, and simplify_subreg is
rejecting the subreg as illegal?

Could you run the compiler with your patch, but instead of a call to 
simplify_gen_subreg, call simplify_subreg (like below), but abort if it
returns NULL?  And then see if it triggers within the gcc source tree or
something handy like that where it's legally easier to give me .i file?
If you can't find anything but spec to produce this, we'll work something
out, but I'm lazy and wanna try this the easy way first.

-- 
   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |rth at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2005-01-07 12:24:56 |2005-01-13 08:11:21
   date||


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

[Bug middle-end/19304] [4.0 Regression] wrong code for spec test from emit_move_change_mode

[rth at gcc dot gnu dot org]

-- 
   What|Removed |Added

 Status|ASSIGNED|WAITING


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

[Bug bootstrap/19420] New: make install fails

[uros at kss-loka dot si]

Currently, this procedure fails:
- create gcc-build directory.
- enter directory
- './configure'
- 'make install'


This will result in:
/bin/sh ../gcc/mkinstalldirs /usr/local /usr/local
/bin/sh: line 1: cd: fixincludes: No such file or directory
gmake: *** [install-fixincludes] Error 1

-- 
   Summary: make install fails
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Keywords: build
  Severity: normal
  Priority: P2
 Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: uros at kss-loka dot si
CC: gcc-bugs at gcc dot gnu dot org
 BugsThisDependsOn: 17383


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

[Bug bootstrap/17383] [4.0 Regression] Building in src dir fails

[uros at kss-loka dot si]

-- 
   What|Removed |Added

OtherBugsDependingO||19420
  nThis||


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

[Bug target/11628] movd support for _mm_cvtsi32_si64 and _mm_cvtsi64_si32

[uros at kss-loka dot si]

--- Additional Comments From uros at kss-loka dot si  2005-01-13 09:26 
---
Fixed on mainline.

-- 
   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.0.0


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

[Bug c++/19403] [4.0 Regression] name lookup is broken with friends

[Woebbeking at web dot de]

--- Additional Comments From Woebbeking at web dot de  2005-01-13 10:07 
---
Subject: Re:  [4.0 Regression] name lookup is broken with friends

On Wednesday 12 January 2005 20:37, gdr at integrable-solutions dot net wrote:
>
> Excuse me?
>
> The behaviour mandated by the C++ standard is that if there is no
> declaration for type A in the innermost enclosing namespace then an
> implicit one is added -- because A is used unqualified.  In
> particular, the global A should not be found. Thus the code is
> ill-formed.

So B's ctor uses the global A without the friend declaration and with the 
friend declaration the local injected A? Sometimes the holy standard confuses 
me a bit.


André


-- 


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

[Bug target/19421] New: [4.0 regression] ICE

[corsepiu at gcc dot gnu dot org]

The code from the attachment cause m68k-rtems-gcc to ICE if being compiled with
-msoft-float -O2.

# m68k-rtems4.7-gcc -O2 -msoft-float -o tmp.o -c paranoia.c
paranoia.c: In function 'paranoia':
paranoia.c:1238: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.

# m68k-rtems4.7-gcc --version
m68k-rtems4.7-gcc (GCC) 4.0.0 20050112 (experimental)

Optimization levels less than -02 do not trigger the ICE.

-- 
   Summary: [4.0 regression] ICE
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P2
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: corsepiu at gcc dot gnu dot org
CC: cjohns at cybertec dot com dot au,gcc-bugs at gcc dot
gnu dot org,joel at oarcorp dot com
GCC target triplet: m68k-*


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

[Bug target/19421] [4.0 regression] ICE

[corsepiu at gcc dot gnu dot org]

--- Additional Comments From corsepiu at gcc dot gnu dot org  2005-01-13 
10:18 ---
Created an attachment (id=7948)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7948&action=view)
Code to reproduce the ICE

Sorry for the size of the example (stripped down from RTEMS paranoia.c), but I
have not been able to further reduce it.


-- 


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

[Bug target/19421] [4.0 regression] ICE

[corsepiu at gcc dot gnu dot org]

-- 
   What|Removed |Added

  Known to fail||4.0.0
  Known to work||3.2.3


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

[Bug libstdc++/19322] std::isnan<>() is broken on FreeBSD

[pcarlini at suse dot de]

--- Additional Comments From pcarlini at suse dot de  2005-01-13 10:41 
---
Gaby, can you spot something fundamentally wrong in the proposed patch? I'm
testing the slightly tweaked attached version on x86-linux and everything seems
still ok: I would suggest Lorenz regtesting it on freebsd or at least checking
that 26_numerics/cmath/c_math_dynamic.cc does not regress there.

-- 
   What|Removed |Added

 CC||pcarlini at suse dot de
 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-01-13 10:41:09
   date||


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

[Bug middle-end/19410] Overlapping memcpy with big struct copies (ACATS c64106a)

[baldrick at free dot fr]

--- Additional Comments From baldrick at free dot fr  2005-01-13 10:47 
---
Subject: Re:  Overlapping memcpy with big struct copies (ACATS c64106a)

> > Would you like me to file a separate report for them?  Here is cxa4009 by 
> > the way:
> 
> Yes please because this is a related issue but I think it might be an Ada 
> front-end bug rather than what 
> C64106A is which is a middle-end one as shown by the C example.

I filed a separate bug report for CXA4009 and CXA4020: [Bug ada/19419].

By the way, I've tried to imagine how a memcpy with source==target can cause 
problems, without much
success.  Any hints? :)  The only thing I could come up with was: if there are 
two copies of the
same bit of memory (eg: one in cache, the other in main memory; or one in 
backing store, one in memory),
with one copy being out of date; and the memcpy causing the out-of-date one to 
be written on top of the
up-to-date one somehow...


-- 


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

[Bug libstdc++/7706] asinh, acosh, atanh are not put in std:: by

[pcarlini at suse dot de]

--- Additional Comments From pcarlini at suse dot de  2005-01-13 11:00 
---
As per Comment #7...

-- 
   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||INVALID


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

[Bug libgcj/17784] Thread.interrupt doesn't do security checks

[konqueror at gmx dot de]

--- Additional Comments From konqueror at gmx dot de  2005-01-13 11:38 
---
A patch can be found here: 
http://gcc.gnu.org/ml/java-patches/2005-q1/msg00077.html 

-- 


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

[Bug c++/19422] New: assoc. containers: ctor taking range is O(n log n) even if the range is sorted

[SWElef at post dot sk]

The template constructor of associative containers with range [first,last)
should have linear complexity if the range is sorted. libstdc++ fails to
comply.

This is quite evident when looking at the include file bits/stl_tree.h,
more precisely the functions insert_unique and insert_equal taking ranges.

To be sure I made some runtime tests. The complexity is really O(n log n),
where n=distance(first,last). It is not evident with the default allocator,
but one can see the trend. I also tested with a self-made single-threaded
pool allocator and the results were very clear. I can submit the source
if need be.

Regards,
Vladimir Marko

-- 
   Summary: assoc. containers: ctor taking range is O(n log n) even
if the range is sorted
   Product: gcc
   Version: 3.4.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: SWElef at post dot sk
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug libstdc++/19422] assoc. containers: ctor taking range is O(n log n) even if the range is sorted

[SWElef at post dot sk]

-- 
   What|Removed |Added

  Component|c++ |libstdc++


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

[Bug libstdc++/19422] assoc. containers: ctor taking range is O(n log n) even if the range is sorted

[pcarlini at suse dot de]

--- Additional Comments From pcarlini at suse dot de  2005-01-13 12:25 
---
> ... I can submit the source if need be.

Please do, that would help. Thanks in advance.


-- 


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

[Bug bootstrap/19420] make install fails if not preceded by make all

[bonzini at gcc dot gnu dot org]

--- Additional Comments From bonzini at gcc dot gnu dot org  2005-01-13 
13:03 ---
The problem is that install-* does not depend on all-*

On the other hand, that would slow down the installation process.  Making
install-* depend on configure-* is not enough as well, because even if the 'all'
target is run in the subdirectory, the installation process would not be sorted
according to the build dependencies (e.g. no guarantee that gcc is installed
before libiberty, which is ok usually but not when both still have to be built).

Paolo

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
  Known to fail||3.4.3 4.0.0
   Last reconfirmed|-00-00 00:00:00 |2005-01-13 13:03:41
   date||
Summary|make install fails  |make install fails if not
   ||preceded by make all


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

[Bug libstdc++/19422] assoc. containers: ctor taking range is O(n log n) even if the range is sorted

[pcarlini at suse dot de]

--- Additional Comments From pcarlini at suse dot de  2005-01-13 13:05 
---
A naive idea (I haven't really studied the issue in detail): wouldn't be of help
calling in the insert_unique/insert_equal loops the overloads taking an iterator
(which would be end()) and a value?

-- 


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

[Bug bootstrap/19420] make install fails if not preceded by make all

[bonzini at gcc dot gnu dot org]

--- Additional Comments From bonzini at gcc dot gnu dot org  2005-01-13 
13:19 ---
Looking at the pre-autogen Makefile.in it looks like it never worked actually.
 
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/Makefile.in?rev=1.111&content-type=text/x-cvsweb-markup

-- 


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

[Bug target/19326] [4.0 Regression] gcc.c-torture/execute/simd-6.c fails on x86-64

[uros at kss-loka dot si]

--- Additional Comments From uros at kss-loka dot si  2005-01-13 13:19 
---
(In reply to comment #1)
> These two fail with similiar ICEs: 
>gcc.dg/i386-sse-1.c (test for excess errors) 
>gcc.dg/i386-sse-2.c (test for excess errors) 

The ICE in both cases is in fact (produced with a crosscompiler):

In file included from
/usr/local.uros/lib/gcc/i686-pc-linux-gnu/4.0.0/include/xmmintrin.h:1211,
 from i386-sse-2.c:12:
/usr/local.uros/lib/gcc/i686-pc-linux-gnu/4.0.0/include/emmintrin.h: In function
'_mm_cvtsi128_si64x':
/usr/local.uros/lib/gcc/i686-pc-linux-gnu/4.0.0/include/emmintrin.h:207:
internal compiler error: Segmentation fault


-- 


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

[Bug c/19423] New: -Os causes internal compiler error in gcc-3.4-20050107

[dcb314 at hotmail dot com]

I ran the compiler

[EMAIL PROTECTED] src]$ ~/gnu/20050107/results/bin/gcc -Os -c b.c
b.c: In function `__ansicon_write':
b.c:57: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.

I tried valgrind

[EMAIL PROTECTED] src]$ ~/valgrind/results.220/bin/valgrind -q 
--trace-children=yes
--tool=memcheck ~/gnu/20050107/results/bin/gcc -Os -c b.c
==5131== Invalid read of size 2
==5131==at 0x8290EB5: memory_operand (recog.c:1336)
==5131==by 0x81AE70D: get_attr_memory (insn-attrtab.c:24474)
==5131==by 0x81C7BBD: result_ready_cost (insn-attrtab.c:19373)
==5131==by 0x835C78B: priority (haifa-sched.c:881)
==5131==  Address 0xABABABAB is not stack'd, malloc'd or (recently) free'd

The source code is


typedef unsigned char uint8_t;
typedef unsigned short uint16_t;
typedef unsigned int size_t;
typedef signed int ptrdiff_t;
typedef ptrdiff_t ssize_t;

struct curxy {
  uint8_t x, y;
} __attribute__((packed));

enum ansi_state {
  st_init,
  st_esc,
  st_csi,
};

struct term_state {
  int disabled;
  enum ansi_state state;
};

static struct term_state st;

static void ansicon_putchar(int ch)
{
  const int rows = (*(uint8_t *)0x484) ? (*(uint8_t *)0x484)+1 : 25;
  const int cols = (*(uint16_t *)0x44A);
  const int page = (*(uint8_t *)0x462);
  struct curxy xy = ((struct curxy *)0x450)[page];

  switch ( st.state ) {
  case st_init:
switch ( ch ) {
case '\b':
  if ( xy.x > 0 ) xy.x--;
  break;
}
break;
  }

  while ( xy.y >= rows ) {
  }
}

ssize_t __ansicon_write( const void *buf, size_t count)
{
  const unsigned char *bufp = buf;
  size_t n = 0;

  while ( count-- ) {
ansicon_putchar(*bufp++);
  }

  return n;
}
---

-- 
   Summary: -Os causes internal compiler error in gcc-3.4-20050107
   Product: gcc
   Version: 3.4.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dcb314 at hotmail dot com
CC: gcc-bugs at gcc dot gnu dot org
  GCC host triplet: i686-pc-linux-gnu


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

[Bug libstdc++/19322] std::isnan<>() is broken on FreeBSD

[gdr at integrable-solutions dot net]

--- Additional Comments From gdr at integrable-solutions dot net  
2005-01-13 13:27 ---
Subject: Re:  std::isnan<>() is broken on FreeBSD

"pcarlini at suse dot de" <[EMAIL PROTECTED]> writes:

| Gaby, can you spot something fundamentally wrong in the proposed patch? I'm
| testing the slightly tweaked attached version on x86-linux and everything 
seems
| still ok: I would suggest Lorenz regtesting it on freebsd or at least checking
| that 26_numerics/cmath/c_math_dynamic.cc does not regress there.

I think the patch is OK -- modulo testing on different targets,
especially
*BSD, linux and another non-glibc system (solaris for example).

thanks.

-- Gaby


-- 


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

[Bug target/19424] New: Error: suffix or operands invalid for `movlps'

[uros at kss-loka dot si]

gcc -O0 -msse i386-sse-1.c
/tmp/cc9PodHq.s: Assembler messages:
/tmp/cc9PodHq.s:4557: Error: suffix or operands invalid for `movlps'
/tmp/cc9PodHq.s:4558: Error: suffix or operands invalid for `movlps'
/tmp/cc9PodHq.s:4579: Error: suffix or operands invalid for `movlps'
/tmp/cc9PodHq.s:4580: Error: suffix or operands invalid for `movlps'

These movlps errors refer to:
_mm_set_ps:
pushl   %ebp
movl%esp, %ebp
subl$24, %esp
movss   20(%ebp), %xmm1
movss   16(%ebp), %xmm0
unpcklps%xmm0, %xmm1
movss   12(%ebp), %xmm2
movss   8(%ebp), %xmm0
movaps  %xmm2, %xmm3
unpcklps%xmm0, %xmm3
(*) movlps  %xmm3, %xmm0
(*) movlps  %xmm1, %xmm2
movlhps %xmm0, %xmm2
movaps  %xmm2, %xmm0
movaps  %xmm0, -24(%ebp)
movaps  -24(%ebp), %xmm0
leave
ret

and

_mm_setr_ps:
pushl   %ebp
movl%esp, %ebp
subl$24, %esp
movss   8(%ebp), %xmm1
movss   12(%ebp), %xmm0
unpcklps%xmm0, %xmm1
movss   16(%ebp), %xmm2
movss   20(%ebp), %xmm0
movaps  %xmm2, %xmm3
unpcklps%xmm0, %xmm3
(*) movlps  %xmm3, %xmm0
(*) movlps  %xmm1, %xmm2
movlhps %xmm0, %xmm2
movaps  %xmm2, %xmm0
movaps  %xmm0, -24(%ebp)
movaps  -24(%ebp), %xmm0
leave
ret

Note that movlps cannot handle two registers as its operands.

-- 
   Summary: Error: suffix or operands invalid for `movlps'
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Keywords: ssemmx
  Severity: normal
  Priority: P2
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: uros at kss-loka dot si
CC: gcc-bugs at gcc dot gnu dot org
 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=19424

[Bug libstdc++/15523] [DR 408] Can't have vectors of vector::const_iterator

[polzin_spamprotect_ at gmx dot de]

--- Additional Comments From polzin_spamprotect_ at gmx dot de  2005-01-13 
13:30 ---
I just want to add the information that unfortunately already
"-D_GLIBCXX_DEBUG" turns on the abort, you don't need the PEDANTIC.

I find this annoying, because in my case rewriting is not so easy, because
I store a struct of different iterators in a vector, and this information
is gathered together one after the other and there is no scope, where all 
containers exist together. Thus, it´s not possible to initialize the struct
without a GLIBCXX_DEBUG abort.

-- 


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

[Bug target/19379] [4.0 Regression] ICE during build of newlib's e_atan2.c when soft-float

[corsepiu at gcc dot gnu dot org]

--- Additional Comments From corsepiu at gcc dot gnu dot org  2005-01-13 
13:31 ---
(In reply to comment #11)
> (In reply to comment #10)
> One thing that I notice about this is that -msoft-float and -mhard-float are
> no longer inverses. 
Good point. How about these alternatives:

1. Systematically substitute all occurences of MASK_80387 with
(MASK_80387|MASK_FLOAT_RETURN) in i386.h.
This would keep -msoft-float and -mno-80387, rsp. -mno-soft-float, -mhard-float
and -m80387 as synonyms.
IMO, this would be the least intrusive way of a proper fix.

2. Completely eliminate MASK_FLOAT_RETURN and to use 
MASK_80837, instead.  This would be a pretty radical way, I am not sure about
its consquences, but I don't expect it to do much harm.

3. Keep -[no-]hard-float, -m[no-]80387 and -m[no-]fp-ret-in-387 as they
currently are, but only change soft-float to (MASK_80387|MASK_FLOAT_RETURN) and
-mno-soft-float to -(MASK_80387|MASK_FLOAT_RETURN).
This would satisfy RTEMS without disturbing other targets/OSes (We'd have to
change our multilibs, but this wouldn't be an issue).
I'd consider this to be a more a hack than an actual fix ;)

4. Fix the cause of this PR. I.e. prevent GCC from generating FPU code in the
case this breakdown occurred. Unfortunately, I don't know the cause nor how to
work around it.

> Perhaps it would be better to modify override_options to
> notice when, after all options are processed, that MASK_80387 is off and then
> turn off MASK_FLOAT_RETURNS to match.
I don't understand. Could you elaborate?

-- 


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

[Bug target/19424] Error: suffix or operands invalid for `movlps'

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Keywords||wrong-code


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

[Bug c/19423] -Os causes internal compiler error in gcc-3.4-20050107

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-13 
13:39 ---
This is a dup of bug 19012 which is fixed on the 8th on the 3.4 branch.

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

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug target/19012] [3.4 Regression] ICE on testsuite/gcc.c-torture/execute/930208-1.c with -fpack-struct -Os

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-13 
13:39 ---
*** Bug 19423 has been marked as a duplicate of this bug. ***

-- 
   What|Removed |Added

 CC||dcb314 at hotmail dot com


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

[Bug target/19421] [4.0 regression] ICE with solf-float on m68k

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

Summary|[4.0 regression] ICE|[4.0 regression] ICE with
   ||solf-float on m68k
   Target Milestone|--- |4.0.0


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

[Bug tree-optimization/19337] [4.0 Regression] ada does not compile at -O3 (nested functions related)

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-13 
13:42 ---
Patch here: .

-- 
   What|Removed |Added

   Keywords||patch


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

[Bug target/19424] [4.0 Regression] Error: suffix or operands invalid for `movlps'

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

Summary|Error: suffix or operands   |[4.0 Regression] Error:
   |invalid for `movlps'|suffix or operands invalid
   ||for `movlps'
   Target Milestone|--- |4.0.0


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

[Bug tree-optimization/19401] Trivial loop not unrolled

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org
   Severity|normal  |enhancement


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

[Bug fortran/19425] New: Duplicate SAVE attribute problem

[tow21 at cam dot ac dot uk]

Consider the following program: 
parabrisas:~/test% cat C578.f  
  subroutine s( ) 
  logical frstme 
  save frstme 
  save 
  continue 
  end 
 
Under constraint C578 of the f95 standard this is illegal, since a global save 
is not permitted in the same scoping unit as any other explicit use of the 
save attribute or save statement. gfortran correctly recognises this and 
diagnoses an error. 
 
However, this constraint did not exist in F77 (I am unsure about F90). 
Therefore, the above is a perfectly legal F77 program (and, indeed g77 
compiles it without complaint).

-- 
   Summary: Duplicate SAVE attribute problem
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tow21 at cam dot ac dot uk
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug c++/19426] New: template class and method with different parameter names

[douze at enseeiht dot fr]

When a class and one of its methods depend on templates, when the method is
defined, the name of the parameters must be the same as in the definition.

-- 
   Summary: template class and method with different parameter names
   Product: gcc
   Version: 3.4.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: douze at enseeiht dot fr
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: i586-mandrake-linux-gnu
  GCC host triplet: i586-mandrake-linux-gnu
GCC target triplet: i586-mandrake-linux-gnu


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

[Bug c++/19426] template class and method with different parameter names

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-13 
14:33 ---
Do you have an example code?

-- 


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

[Bug c++/19426] template class and method with different parameter names

[douze at enseeiht dot fr]

--- Additional Comments From douze at enseeiht dot fr  2005-01-13 14:35 
---
Created an attachment (id=7951)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7951&action=view)
short c++ code that fails

result with g++ -c 
x.i: In member function `void* Cl::me(T) [with T = T, int N = 1]':
x.i:10: error: `b' undeclared

-- 


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

[Bug c++/19426] template class and method with different parameter names

[douze at enseeiht dot fr]

--- Additional Comments From douze at enseeiht dot fr  2005-01-13 14:37 
---
Created an attachment (id=7952)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7952&action=view)
the code that works

compiles ok

-- 


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

[Bug c++/19426] template class and method with different parameter names

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-13 
14:39 ---
This is a dup of bug 18962 which is fixed in 3.4.4 (which is not released yet) 
and above.

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

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

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug c++/18962] [3.4 Regression] specialization of template class with inner template members and parameter

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-13 
14:39 ---
*** Bug 19426 has been marked as a duplicate of this bug. ***

-- 
   What|Removed |Added

 CC||douze at enseeiht dot fr


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

[Bug c++/19403] [4.0 Regression] name lookup is broken with friends

[lerdsuwa at gcc dot gnu dot org]

--- Additional Comments From lerdsuwa at gcc dot gnu dot org  2005-01-13 
14:52 ---
> So B's ctor uses the global A without the friend declaration and with the 
> friend declaration the local injected A? Sometimes the holy standard confuses 
> me a bit.

No. With or without friend declaration, the B's ctor should always pick
the global A.  This is one weird rule in C++ standard.  
The idea is that name lookup for 'friend struct A;' only find A within 
one level outside the classes enclosing the friend declaration:

  namespace N {
class A {
  class B {
friend class C; // Classes A and B enclosing this friend.
// one level up is namespace N.
// Since there is no B::C nor A::C,
// this refers to N::C
  };
};
  }

  void f() {
class D {
  friend class E;   // Since there is no D::E, one level up
// is the local class E inside function f.
};
  }

When refer to A without the prefix 'class' or 'struct', any name
can be used.  However the name introduced by friend must be
explicitly declared first to be visible.

Now it's your example, expanded with more cases and comment describing
the way it should be handled.

  struct A {}; 
 
  namespace Boo 
  { 
 struct B 
 { 
   friend struct A; // Since there is no B::A, this means Boo::A
// It introduces Boo::A but still invisible
// since there is no Boo::A declaration prior
// to this friend.
 
   B(const A&) {}; // Boo::A is still not visible,
   // so ::A is chosen here
 };

 void f(const A&) {} // Boo::A is still not visible, choose ::A

 struct A; // Declare Boo::A explicitly, so Boo::A is now visible

 void g(const A&) {} // Choose Boo::A
  }

-- 


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

[Bug c++/14513] Friend name injection problem (implicit declaration)

[lerdsuwa at gcc dot gnu dot org]

--- Additional Comments From lerdsuwa at gcc dot gnu dot org  2005-01-13 
14:55 ---
It is already described in changes.html:

  When declaring a friend class using an unqualified name, classes outside
  the innermost non-class scope are not searched ...

-- 


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

[Bug fortran/19425] Duplicate SAVE attribute problem

[tow21 at cam dot ac dot uk]

--- Additional Comments From tow21 at cam dot ac dot uk  2005-01-13 14:59 
---
Brief correction - the reference to C578 is actually from the F2003 standard. 
In f95 is it is the second, unnumbered, constraint in section 5.2.4. 

-- 


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

[Bug target/19326] [4.0 Regression] gcc.c-torture/execute/simd-6.c fails on x86-64

[uros at kss-loka dot si]

--- Additional Comments From uros at kss-loka dot si  2005-01-13 15:10 
---
The same failure for these, for both x86_64 and i686 with -msse2:

Running target unix
FAIL: gcc.c-torture/execute/simd-1.c compilation,  -O0 
UNRESOLVED: gcc.c-torture/execute/simd-1.c execution,  -O0 
FAIL: gcc.c-torture/execute/simd-1.c compilation,  -O1 
UNRESOLVED: gcc.c-torture/execute/simd-1.c execution,  -O1 
FAIL: gcc.c-torture/execute/simd-1.c compilation,  -O2 
UNRESOLVED: gcc.c-torture/execute/simd-1.c execution,  -O2 
FAIL: gcc.c-torture/execute/simd-1.c compilation,  -O3 -fomit-frame-pointer 
UNRESOLVED: gcc.c-torture/execute/simd-1.c execution,  -O3 -fomit-frame-pointer 
FAIL: gcc.c-torture/execute/simd-1.c compilation,  -O3 -g 
UNRESOLVED: gcc.c-torture/execute/simd-1.c execution,  -O3 -g 
FAIL: gcc.c-torture/execute/simd-1.c compilation,  -Os 
UNRESOLVED: gcc.c-torture/execute/simd-1.c execution,  -Os 

simd-1.c:74: error: unrecognizable insn:
(insn:HI 52 51 53 0 (set (reg:SI 94)
(vec_select:SI (reg:V4SI 95)
(parallel [
(const_int 1 [0x1])
]))) -1 (insn_list:REG_DEP_TRUE 51 (nil))
(expr_list:REG_DEAD (reg:V4SI 95)
(nil)))
simd-1.c:74: internal compiler error: in extract_insn, at recog.c:2020

I can't reproduce the failure for gcc.c-torture/execute/simd-2.c compilation as
reported in http://gcc.gnu.org/ml/gcc-testresults/2005-01/msg00595.html. Is
there a problem with:

simd-2.c: In function 'verify':
simd-2.c:26: warning: incompatible implicit declaration of built-in function 
'abort'
simd-2.c: In function 'main':
simd-2.c:71: warning: incompatible implicit declaration of built-in function 
'exit'

gcc.dg/simd-2.c crashes with:
gcc.dg/simd-2.c:48: internal compiler error: in gen_lowpart_general, at
rtlhooks.c:58
Please submit a full bug report,
with preprocessed source if appropriate.

gcc.c-torture/execute/simd-6.c failure is fixed on current mainline.

-- 


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

[Bug c/5675] [4.0 regression] const variables wrongly considered part of constant expressions

[ian at airs dot com]

--- Additional Comments From ian at airs dot com  2005-01-13 15:16 ---
Partial patch: http://gcc.gnu.org/ml/gcc-patches/2005-01/msg00725.html

-- 


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

[Bug target/19427] New: gcc.c-torture/execute/simd-1.c compilation fails for x64_86 and i686 with -msse2

[uros at kss-loka dot si]

This testsuite failure can be reproduced for both x86_64 and i686 with -msse2:

FAIL: gcc.c-torture/execute/simd-1.c compilation,  -O0 
UNRESOLVED: gcc.c-torture/execute/simd-1.c execution,  -O0 
FAIL: gcc.c-torture/execute/simd-1.c compilation,  -O1 
UNRESOLVED: gcc.c-torture/execute/simd-1.c execution,  -O1 
FAIL: gcc.c-torture/execute/simd-1.c compilation,  -O2 
UNRESOLVED: gcc.c-torture/execute/simd-1.c execution,  -O2 
FAIL: gcc.c-torture/execute/simd-1.c compilation,  -O3 -fomit-frame-pointer 
UNRESOLVED: gcc.c-torture/execute/simd-1.c execution,  -O3 -fomit-frame-pointer 
FAIL: gcc.c-torture/execute/simd-1.c compilation,  -O3 -g 
UNRESOLVED: gcc.c-torture/execute/simd-1.c execution,  -O3 -g 
FAIL: gcc.c-torture/execute/simd-1.c compilation,  -Os 
UNRESOLVED: gcc.c-torture/execute/simd-1.c execution,  -Os 

simd-1.c:74: error: unrecognizable insn:
(insn 47 46 48 0 (set (reg:SI 78 [ D.1529 ])
(vec_select:SI (reg:V4SI 154)
(parallel [
(const_int 1 [0x1])
]))) -1 (nil)
(expr_list:REG_DEAD (reg:V4SI 154)
(nil)))
simd-1.c:74: internal compiler error: in extract_insn, at recog.c:2020

However, on i686 with -msse, the error is different:

simd-1.c:74: error: unrecognizable insn:
(insn 24 23 25 0 (set (reg:V4SF 218)
(vec_select:V4SF (vec_concat:V8SF (subreg:V4SF (reg:V4SI 207 [ i.0 ]) 0)
(subreg:V4SF (reg:V4SI 207 [ i.0 ]) 0))
(parallel [
(const_int 1 [0x1])
(const_int 1 [0x1])
(const_int 1 [0x1])
(const_int 1 [0x1])
]))) -1 (nil)
(nil))
simd-1.c:74: internal compiler error: in extract_insn, at recog.c:2020

-- 
   Summary: gcc.c-torture/execute/simd-1.c compilation fails for
x64_86 and i686 with -msse2
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Keywords: ssemmx
  Severity: normal
  Priority: P2
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: uros at kss-loka dot si
CC: gcc-bugs at gcc dot gnu dot org
  GCC host triplet: i686-*, x86_64-*


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

[Bug rtl-optimization/16104] [3.3/3.4 regression] ICE in reload_cse_simplify_operands, at postreload.c:378 with SSE2 code on -O2

[jakub at gcc dot gnu dot org]

--- Additional Comments From jakub at gcc dot gnu dot org  2005-01-13 15:28 
---
Patch here: 

-- 
   What|Removed |Added

   Keywords||patch
  Known to fail|3.3.3 3.3.4 3.4.0 3.4.1 |3.3.3 3.3.4 3.4.0 3.4.1
   |3.4.2 3.4.3 |3.4.2 3.4.3 4.0.0
  Known to work|4.0.0   |


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

[Bug libstdc++/19322] std::isnan<>() is broken on FreeBSD

[pcarlini at suse dot de]

-- 
   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |pcarlini at suse dot de
   |dot org |
 Status|NEW |ASSIGNED


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

[Bug target/19399] [4.0 Regression] mutexes support broken

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-01-13 
15:50 ---
Subject: Bug 19399

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-01-13 15:50:13

Modified files:
gcc: ChangeLog gthr-rtems.h 

Log message:
2005-01-13  Ralf Corsepius  <[EMAIL PROTECTED]>
Joel Sherrill  <[EMAIL PROTECTED]>

PR target/19399
* gthr-rtems.h (__gthread_recursive_mutex_t): New type.
(__GTHREAD_RECURSIVE_MUTEX_INIT_FUNCTION): Define to
rtems_gxx_recursive_mutex_init.
(__gthread_recursive_mutex_lock): New function.
(__gthread_recursive_mutex_trylock): Likewise.
(__gthread_recursive_mutex_unlock): Likewise.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.7108&r2=2.7109
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/gthr-rtems.h.diff?cvsroot=gcc&r1=1.10&r2=1.11



-- 


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

[Bug c/19428] New: inet_ntoa returns 0.0.0.0 using -maix64

[gcc-bugzilla at gcc dot gnu dot org]

gcc -maix64 code generated :-
lwz r3,116(r31)
bl 
cc -q64 (AIX compiler) code generated :-
lwz r3,116(r1)
rldicr 3,3,32,31
bl 

Environment:
System: AIX ibmbj 2 5 000972024C00



host: powerpc-ibm-aix5.2.0.0
build: powerpc-ibm-aix5.2.0.0
target: powerpc-ibm-aix5.2.0.0
configured with: ../gcc-3.3.2/configure  : (reconfigured) 
../gcc-3.3.2/configure --disable-nls : (reconfigured) ../gcc-3.3.2/configure 
--disable-nls

How-To-Repeat:

#include 
#include 
#include 
#include 
#include 

main()
{
char buf[] = { 0xC2, 0x48, 0xA4, 0x47};
struct in_addr ipaddr;
char *rfc1006;

memcpy(&ipaddr, buf, sizeof(struct in_addr));
rfc1006 = inet_ntoa(ipaddr);
printf("Address is : %s\n", rfc1006);
}
--- Additional Comments From root at ibmbj dot bj dot co dot uk  2005-01-13 
16:13 ---
Fix:
None.

-- 
   Summary: inet_ntoa returns 0.0.0.0 using -maix64
   Product: gcc
   Version: 3.3.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: root at ibmbj dot bj dot co dot uk
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: powerpc-ibm-aix5.2.0.0
  GCC host triplet: powerpc-ibm-aix5.2.0.0
GCC target triplet: powerpc-ibm-aix5.2.0.0


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

[Bug c/19429] New: ()?: with sizeof does not work correctly

[wintermute101 at wp dot pl]

Reading specs from /usr/lib/gcc/i686-pc-linux-gnu/3.4.3/specs
Configured with: /var/tmp/portage/gcc-3.4.3-r1/work/gcc-3.4.3/configure
--enable-version-specific-runtime-libs --prefix=/usr
--bindir=/usr/i686-pc-linux-gnu/gcc-bin/3.4.3
--includedir=/usr/lib/gcc/i686-pc-linux-gnu/3.4.3/include
--datadir=/usr/share/gcc-data/i686-pc-linux-gnu/3.4.3
--mandir=/usr/share/gcc-data/i686-pc-linux-gnu/3.4.3/man
--infodir=/usr/share/gcc-data/i686-pc-linux-gnu/3.4.3/info
--with-gxx-include-dir=/usr/lib/gcc/i686-pc-linux-gnu/3.4.3/include/g++-v3
--host=i686-pc-linux-gnu --disable-altivec --enable-nls
--without-included-gettext --enable-__cxa_atexit --enable-clocale=gnu
--with-system-zlib --disable-checking --disable-werror
--disable-libunwind-exceptions --enable-shared --enable-threads=posix
--disable-multilib --disable-libgcj --enable-languages=c,c++,f77
Thread model: posix
gcc version 3.4.3 20041125 (Gentoo Linux 3.4.3-r1, ssp-3.4.3-0, pie-8.7.7)

$gcc test.c -o t

$./t

# 1 "test.c"
# 1 ""
# 1 ""
# 1 "test.c"
# 1 "/usr/include/stdio.h" 1 3 4
# 28 "/usr/include/stdio.h" 3 4
# 1 "/usr/include/features.h" 1 3 4
# 314 "/usr/include/features.h" 3 4
# 1 "/usr/include/sys/cdefs.h" 1 3 4
# 315 "/usr/include/features.h" 2 3 4
# 337 "/usr/include/features.h" 3 4
# 1 "/usr/include/gnu/stubs.h" 1 3 4
# 338 "/usr/include/features.h" 2 3 4
# 29 "/usr/include/stdio.h" 2 3 4





# 1 "/usr/lib/gcc/i686-pc-linux-gnu/3.4.3/include/stddef.h" 1 3 4
# 213 "/usr/lib/gcc/i686-pc-linux-gnu/3.4.3/include/stddef.h" 3 4
typedef unsigned int size_t;
# 35 "/usr/include/stdio.h" 2 3 4

# 1 "/usr/include/bits/types.h" 1 3 4
# 28 "/usr/include/bits/types.h" 3 4
# 1 "/usr/include/bits/wordsize.h" 1 3 4
# 29 "/usr/include/bits/types.h" 2 3 4


# 1 "/usr/lib/gcc/i686-pc-linux-gnu/3.4.3/include/stddef.h" 1 3 4
# 32 "/usr/include/bits/types.h" 2 3 4


typedef unsigned char __u_char;
typedef unsigned short int __u_short;
typedef unsigned int __u_int;
typedef unsigned long int __u_long;


typedef signed char __int8_t;
typedef unsigned char __uint8_t;
typedef signed short int __int16_t;
typedef unsigned short int __uint16_t;
typedef signed int __int32_t;
typedef unsigned int __uint32_t;




__extension__ typedef signed long long int __int64_t;
__extension__ typedef unsigned long long int __uint64_t;







__extension__ typedef long long int __quad_t;
__extension__ typedef unsigned long long int __u_quad_t;
# 129 "/usr/include/bits/types.h" 3 4
# 1 "/usr/include/bits/typesizes.h" 1 3 4
# 130 "/usr/include/bits/types.h" 2 3 4






__extension__ typedef __u_quad_t __dev_t;
__extension__ typedef unsigned int __uid_t;
__extension__ typedef unsigned int __gid_t;
__extension__ typedef unsigned long int __ino_t;
__extension__ typedef __u_quad_t __ino64_t;
__extension__ typedef unsigned int __mode_t;
__extension__ typedef unsigned int __nlink_t;
__extension__ typedef long int __off_t;
__extension__ typedef __quad_t __off64_t;
__extension__ typedef int __pid_t;
__extension__ typedef struct { int __val[2]; } __fsid_t;
__extension__ typedef long int __clock_t;
__extension__ typedef unsigned long int __rlim_t;
__extension__ typedef __u_quad_t __rlim64_t;
__extension__ typedef unsigned int __id_t;
__extension__ typedef long int __time_t;
__extension__ typedef unsigned int __useconds_t;
__extension__ typedef long int __suseconds_t;

__extension__ typedef int __daddr_t;
__extension__ typedef long int __swblk_t;
__extension__ typedef int __key_t;


__extension__ typedef int __clockid_t;


__extension__ typedef int __timer_t;


__extension__ typedef long int __blksize_t;




__extension__ typedef long int __blkcnt_t;
__extension__ typedef __quad_t __blkcnt64_t;


__extension__ typedef unsigned long int __fsblkcnt_t;
__extension__ typedef __u_quad_t __fsblkcnt64_t;


__extension__ typedef unsigned long int __fsfilcnt_t;
__extension__ typedef __u_quad_t __fsfilcnt64_t;

__extension__ typedef int __ssize_t;



typedef __off64_t __loff_t;
typedef __quad_t *__qaddr_t;
typedef char *__caddr_t;


__extension__ typedef int __intptr_t;


__extension__ typedef unsigned int __socklen_t;
# 37 "/usr/include/stdio.h" 2 3 4









typedef struct _IO_FILE FILE;





# 62 "/usr/include/stdio.h" 3 4
typedef struct _IO_FILE __FILE;
# 72 "/usr/include/stdio.h" 3 4
# 1 "/usr/include/libio.h" 1 3 4
# 32 "/usr/include/libio.h" 3 4
# 1 "/usr/include/_G_config.h" 1 3 4
# 14 "/usr/include/_G_config.h" 3 4
# 1 "/usr/lib/gcc/i686-pc-linux-gnu/3.4.3/include/stddef.h" 1 3 4
# 325 "/usr/lib/gcc/i686-pc-linux-gnu/3.4.3/include/stddef.h" 3 4
typedef long int wchar_t;
# 354 "/usr/lib/gcc/i686-pc-linux-gnu/3.4.3/include/stddef.h" 3 4
typedef unsigned int wint_t;
# 15 "/usr/include/_G_config.h" 2 3 4
# 24 "/usr/include/_G_config.h" 3 4
# 1 "/usr/include/wchar.h" 1 3 4
# 48 "/usr/include/wchar.h" 3 4
# 1 "/usr/lib/gcc/i686-pc-linux-gnu/3.4.3/include/stddef.h" 1 3 4
# 49 "/usr/include/wchar.h" 2 3 4

# 1 "/usr/include/bits/wchar.h" 1 3 4
# 51 "/usr/include/wchar.h" 2 3 4
# 76 "/usr/include/wchar.h" 3 4
typede

[Bug c/19429] ()?: with sizeof does not work correctly

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-13 
16:53 ---
sizeof is unsigned so this is invalid.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug target/4214] powerpc64: wrong code from optimized mask and shift

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

  Component|c   |target
   Target Milestone|--- |3.0.x


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

[Bug libstdc++/19422] assoc. containers: ctor taking range is O(n log n) even if the range is sorted

[SWElef at post dot sk]

--- Additional Comments From SWElef at post dot sk  2005-01-13 16:59 ---
Created an attachment (id=7953)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7953&action=view)
performance test

This is my test program.

After giving it some thought I believe that calling the
insert_unique/insert_equal function is wrong. I don't think that any hint
(position) can help to make the running time linear in distance(first,last).
A special function should be writen for this purpose.

Regards,
Vladimir Marko


-- 


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

[Bug target/19428] inet_ntoa returns 0.0.0.0 using -maix64

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-13 
17:00 ---
Make sure you read .

-- 
   What|Removed |Added

  Component|c   |target


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

[Bug middle-end/19304] [4.0 Regression] wrong code for spec test from emit_move_change_mode

[janis187 at us dot ibm dot com]

--- Additional Comments From janis187 at us dot ibm dot com  2005-01-13 
17:02 ---
What does the "(like below)" in comment #4 refer to?

I can try to come up with a minimized test case if that's necessary, I just
didn't want to put the work into that if the problem was obvious.

-- 


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

[Bug target/19399] [4.0 Regression] mutexes support broken

[corsepiu at gcc dot gnu dot org]

--- Additional Comments From corsepiu at gcc dot gnu dot org  2005-01-13 
17:04 ---
Patches applied to trunk.


-- 
   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug libstdc++/19422] assoc. containers: ctor taking range is O(n log n) even if the range is sorted

[pcarlini at suse dot de]

--- Additional Comments From pcarlini at suse dot de  2005-01-13 17:20 
---
> This is my test program.

Thanks.

> After giving it some thought I believe that calling the
> insert_unique/insert_equal function is wrong. I don't think that any hint
> (position) can help to make the running time linear in distance(first,last).
> A special function should be writen for this purpose.

Why? Are you aware of the fact that insert with hint has amortized *constant*
complexity if t is inserted after p? (Table 69)




-- 


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

[Bug libstdc++/19422] assoc. containers: ctor taking range is O(n log n) even if the range is sorted

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-13 
17:29 ---
Just a note, here is the fits of x/1 vs ts:
The first time:
8.666+4.8264 x + 0.04201 x^2 - 0.0003 x^3

The second time:
5.628 + 1.19516 x - 0.0004 x^2 + 0.000127 x^3

So the second one is O(n) but the first is about O(n^2).

-- 


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

[Bug libstdc++/19422] assoc. containers: ctor taking range is O(n log n) even if the range is sorted

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-13 
17:30 ---
(In reply to comment #5)
One note about number numbers, they come from the mainline from today on a 
powerpc-darwin on a 
1.5GHz G4 and only with 60 lengths.

-- 


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

[Bug libstdc++/19422] assoc. containers: ctor taking range is O(n log n) even if the range is sorted

[pcarlini at suse dot de]

--- Additional Comments From pcarlini at suse dot de  2005-01-13 17:40 
---
Thanks Andrew.

-- 
   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |pcarlini at suse dot de
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-01-13 17:40:30
   date||


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

[Bug target/19326] [4.0 Regression] gcc.c-torture/execute/simd-6.c fails on x86-64

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-13 
18:14 ---
Fixed by:
* config/i386/i386.c (ix86_expand_fp_absneg_operator): Use elt_mode
for converting the mask.

-- 
   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug middle-end/19164] [3.3/3.4/4.0 Regression] ICE in digest_init or build_vector

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-13 
18:17 ---
Patch here: .

-- 
   What|Removed |Added

   Keywords||patch


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

[Bug c/17297] [3.4/4.0 Regression] ICE with FP vector constructor containing qnan calculation

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-13 
18:17 ---
Patch here: .

-- 
   What|Removed |Added

   Keywords||patch


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

[Bug libstdc++/19322] std::isnan<>() is broken on FreeBSD

[lminder at gmx dot net]

--- Additional Comments From lminder at gmx dot net  2005-01-13 18:22 
---
Subject: Re:  std::isnan<>() is broken on FreeBSD

gdr at integrable-solutions dot net wrote:
> I think the patch is OK -- modulo testing on different targets,
> especially
> *BSD, linux and another non-glibc system (solaris for example).

Ok, I'll try to regtest the patch later today on FreeBSD (I'll have to
RTFM first on how exactly this is done). I'll report back.

I don't have access to a solaris box at the moment.

--Lorenz


-- 


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

[Bug libstdc++/19322] std::isnan<>() is broken on FreeBSD

[pcarlini at suse dot de]

--- Additional Comments From pcarlini at suse dot de  2005-01-13 18:27 
---
> Ok, I'll try to regtest the patch later today on FreeBSD (I'll have to
> RTFM first on how exactly this is done). I'll report back.

Thanks. If it's the first time, probably you have to install DejaGnu and Expect.
Have a look to:

  http://gcc.gnu.org/install/test.html

I'm taking care of Solaris testing.

-- 


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

[Bug middle-end/19304] [4.0 Regression] wrong code for spec test from emit_move_change_mode

[janis187 at us dot ibm dot com]

--- Additional Comments From janis187 at us dot ibm dot com  2005-01-13 
18:57 ---
Never mind the question in the last comment, I've bootstrapped C with that
change and it aborts compiling the spec test.  I'm doing more testing to find
a test for which I can post the .i file.

-- 


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

[Bug middle-end/18029] an xor of a single bit bitfield is inefficient

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Target Milestone|--- |4.1.0


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

[Bug middle-end/18030] OR is inefficient in 2-bit bitfield

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Target Milestone|--- |4.1.0


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

[Bug tree-optimization/9895] [SH] GCC unable to retain array values in registers

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-13 
19:06 ---
Now the problem is two fold, we don't do SRA after loop unrolling and we have a 
problem in that the 
invariant not being updated for an ADDR_EXPR (both of these have been filed).

See PR 18754 and PR 18755.

-- 
   What|Removed |Added

  BugsThisDependsOn||18754, 18755
   Last reconfirmed|2004-08-22 07:41:43 |2005-01-13 19:06:18
   date||


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

[Bug middle-end/16172] simple function generates an inappropriate memmove() call

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-13 
19:25 ---
Here is a testcase which I can reproduce it with on powerpc-darwin (it just has 
more elements in the 
struct):
struct fn_hash_idx_t {
  unsigned datum;
  unsigned datum2;
  unsigned datum3;
  unsigned datumi4;
  unsigned datum5;
  unsigned datum6;
  unsigned datum7;
  unsigned datum8;
  unsigned datum9;
};

struct fn_hash_idx_t
fn_hash(unsigned h)
{
  return *(struct fn_hash_idx_t*)&h;
}

-- 


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

[Bug c/19430] New: Missing warning

[terra at gnome dot org]

the program below should result in a warning that "j" might be used
uninitialized.  If the "baz" call is replaced with an explicit assignment
to "j" a warning is generated as expected.

> gcc-3.4.2 -c -Wall -O2 ~/foo.c
(stunning silence)


extern int bar (int);
extern void baz (int *);

int
foo (int i)
{
  int j;

  if (bar (i)) {
// These should do the same with respect to `j':
baz (&j);
// j = 1;
  } else {
  }

  return j;
}

-- 
   Summary: Missing warning
   Product: gcc
   Version: 3.4.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: terra at gnome dot org
CC: gcc-bugs at gcc dot gnu dot org
GCC target triplet: sparc-sun-solaris2.8, i586-suse-linux


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

[Bug c/19430] Missing warning

[dnovillo at gcc dot gnu dot org]

--- Additional Comments From dnovillo at gcc dot gnu dot org  2005-01-13 
20:14 ---

Confirmed.  It doesn't work on mainline either.  The warning machinery is
getting confused with the first V_MAY_DEF to j in the first call to 'bar()'.

It would probably not be too hard to fix for 4.0.


:
  #   j_7 = V_MAY_DEF ;
  D.1124_2 = bar (i_1);
  if (D.1124_2 != 0) goto ; else goto ;

:;
  #   j_8 = V_MAY_DEF ;
  baz (&j);

  # j_6 = PHI ;
:;
  #   VUSE ;
  D.1125_4 = j;
  return D.1125_4;


-- 
   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |dnovillo at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-01-13 20:14:30
   date||


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

[Bug ada/19414] ACATS cxb4003 - valgrind detects wrong code (invalid read)

[laurent at guerby dot net]

--- Additional Comments From laurent at guerby dot net  2005-01-13 20:26 
---
Probably a real bug, ping'ed Robert Dewar as COBOL expert :)

http://gcc.gnu.org/ml/gcc/2005-01/msg00778.html

-- 


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

[Bug libgcj/17784] Thread.interrupt doesn't do security checks

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-01-13 
20:27 ---
Subject: Bug 17784

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-01-13 20:26:39

Modified files:
libjava: ChangeLog 
libjava/java/lang: Thread.java natThread.cc 

Log message:
2005-01-13  Michael Koch  <[EMAIL PROTECTED]>

PR libgcj/17784
* java/lang/Thread.java
(Thread): Call checkAccess().
(stop): Fixed argument name to match javadoc.
* java/lang/natThread.cc
(interrupt): Call checkAccess().
(stop): Likewise.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/ChangeLog.diff?cvsroot=gcc&r1=1.3285&r2=1.3286
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/java/lang/Thread.java.diff?cvsroot=gcc&r1=1.34&r2=1.35
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/java/lang/natThread.cc.diff?cvsroot=gcc&r1=1.28&r2=1.29



-- 


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

[Bug middle-end/19430] Missing uninitialized warning

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Severity|normal  |minor
  Component|c   |middle-end
   Keywords||diagnostic
   Priority|P2  |P3
Summary|Missing warning |Missing uninitialized
   ||warning


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

[Bug libgcj/17784] Thread.interrupt doesn't do security checks

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-13 
20:36 ---
Fixed.

-- 
   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.0.0


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

[Bug libgcj/13603] [meta-bug] Java security model tracking PR

[pinskia at gcc dot gnu dot org]

-- 
Bug 13603 depends on bug 17784, which changed state.

Bug 17784 Summary: Thread.interrupt doesn't do security checks
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17784

   What|Old Value   |New Value

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

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

[Bug tree-optimization/18880] DSE is not doing its job for global variables

[steven at gcc dot gnu dot org]

--- Additional Comments From steven at gcc dot gnu dot org  2005-01-13 
20:38 ---
Hmpf, does DSE do anything *at* *all*??? 
 
Test cases: 
--- 
int x; 
 
int 
f1 (int i, int j, int k) 
{ 
  int *p = k ? &i : &j; 
  i = 3; /* Dead store.  */ 
  *p = 5; 
  x = j; 
} 
 
int 
f2 (int l, int m, int n) 
{ 
  int *q = n ? &l : &m; 
  *q = 3; /* Dead store.  */ 
  *q = 5; 
  x = m; 
} 
--- 
 
 
.optimized dump at -O2: 
--- 
;; Function f1 (f1) 
 
Analyzing Edge Insertions. 
f1 (i, j, k) 
{ 
  int * p; 
  int j.1; 
  int * iftmp.0; 
 
: 
  if (k != 0) goto ; else goto ; 
 
:; 
  p = &i; 
  goto  (); 
 
:; 
  p = &j; 
 
:; 
  i = 3; 
  *p = 5; 
  x = j; 
  return; 
 
} 
 
 
;; Function f2 (f2) 
 
Analyzing Edge Insertions. 
f2 (l, m, n) 
{ 
  int * q; 
  int m.3; 
  int * iftmp.2; 
 
: 
  if (n != 0) goto ; else goto ; 
 
:; 
  q = &l; 
  goto  (); 
 
:; 
  q = &m; 
 
:; 
  *q = 3; 
  *q = 5; 
  x = m; 
  return; 
 
} 
--- 
 
 
 

-- 


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

[Bug target/19427] [4.0 Regression] gcc.c-torture/execute/simd-1.c compilation fails for x64_86 and i686 with -msse2

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-13 
20:45 ---
Does this work now after RTH's patches?

-- 
   What|Removed |Added

   GCC host triplet|i686-*, x86_64-*|
 GCC target triplet||i686-*, x86_64-*
   Keywords||ice-on-valid-code
Summary|gcc.c-torture/execute/simd- |[4.0 Regression] gcc.c-
   |1.c compilation fails for   |torture/execute/simd-1.c
   |x64_86 and i686 with -msse2 |compilation fails for x64_86
   ||and i686 with -msse2
   Target Milestone|--- |4.0.0


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

[Bug debug/19192] [4.0 Regression] Current development gcc generates incorrect line info for example code

[fnf at specifixinc dot com]

--- Additional Comments From fnf at specifixinc dot com  2005-01-13 20:56 
---
Subject: Re:  [4.0 Regression] Current development gcc generates incorrect line 
info for example code

On Wednesday 12 January 2005 11:46, amacleod at redhat dot com wrote:
> Give this a try.

Unfortunately, for my original example, this seems to have made things worse.
The differences are:

  $ diff -w ../old/z.m ../new/z.m
  6,8c6,7
  <   Special opcode 234: advance Address by 16 to 0x80483c1 and Line by 5 to 13
  <   Advance PC by constant 17 to 0x80483d2
  <   Special opcode 34: advance Address by 2 to 0x80483d4 and Line by 1 to 14
  ---
  >   Advance PC by 35 to 80483d4
  >   Special opcode 11: advance Address by 0 to 0x80483d4 and Line by 6 to 14
  20,23c19,22
  < 13 80483c1: c7 04 24 c8 84 04 08movl   $0x80484c8,(%esp)
  < 13 80483c8: 83 c0 02add$0x2,%eax
  < 13 80483cb: 89 44 24 04 mov%eax,0x4(%esp)
  < 13 80483cf: e8 dc fe ff ff  call   80482b0 <[EMAIL PROTECTED]>
  ---
  >  8 80483c1:  c7 04 24 c8 84 04 08movl   $0x80484c8,(%esp)
  >  8 80483c8:  83 c0 02add$0x2,%eax
  >  8 80483cb:  89 44 24 04 mov%eax,0x4(%esp)
  >  8 80483cf:  e8 dc fe ff ff  call   80482b0 <[EMAIL PROTECTED]>
  
I.E. gcc now associates the code to print the results with line 8 instead
of line 13.



-- 


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

[Bug other/6588] throw() takes 20,000 cycles : is it expected ?

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-13 
21:23 ---
Hmm, this is one of the cases where we should be able optimize away really but 
the general case we 
can try to.

-- 
   What|Removed |Added

  Component|rtl-optimization|other
   Last reconfirmed|2004-02-08 05:35:11 |2005-01-13 21:23:12
   date||


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

[Bug tree-optimization/19431] New: missed optimization with ifs and deferencing

[pinskia at gcc dot gnu dot org]

I found this while looking into PR 8361 for missed optimization.
The following two programs should produce the same asm:
int f(int k, int i1, int j1)
{
  int *f1;
  if(k)
   f1 = &i1;
  else
   f1 = &j1;
  return *f1;
}
int g(int k, int i1, int j1)
{
  int *f1;
  if(k)
   return i1;
  else
   return j1;
}

-- 
   Summary: missed optimization with ifs and deferencing
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: enhancement
  Priority: P2
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug tree-optimization/19431] missed optimization with ifs and deferencing

[steven at gcc dot gnu dot org]

--- Additional Comments From steven at gcc dot gnu dot org  2005-01-13 
21:41 ---
...and of course you are going to show what you *actually* get now? 
 

-- 


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

[Bug tree-optimization/19431] missed optimization with ifs and deferencing

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-13 
21:43 ---
This is what I get with the mainline on ppc-darwin:
_f:
cmpwi cr7,r3,0
stw r4,28(r1)
stw r5,32(r1)
addi r3,r1,28
beq- cr7,L7
lwz r3,0(r3)
blr
L7:
addi r3,r1,32
lwz r3,0(r3)
blr
.align 2
.globl _g
_g:
cmpwi cr7,r3,0
mr r3,r4
bnelr+ cr7
mr r3,r5
blr

Note the stores in the f case but non otherwise.

-- 


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

[Bug tree-optimization/19431] missed optimization with ifs and deferencing

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-13 
21:54 ---
This comes from "std::_Deque_base<_Tp, _Alloc>::_M_initialize_map" in libstdc++.

Here is the last SSA tree dump:
f (k, i1, j1)
{
  int * f1;
  int D.1116;

:
  if (k_2 != 0) goto ; else goto ;

:;

  # f1_1 = PHI <&i1(0), &j1(1)>;
:;
  #   VUSE ;
  #   VUSE ;
  D.1116_3 = *f1_1;
  return D.1116_3;

}

And the .final_cleanup one:
f (k, i1, j1)
{
  int * f1;

:
  if (k != 0) goto ; else goto ;

:;
  f1 = &i1;
  goto  ();

:;
  f1 = &j1;

:;
  return *f1;

}

-- 


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

[Bug libfortran/18982] open(status="new") does not generate an error if the file exists

[Thomas dot Koenig at online dot de]

--- Additional Comments From Thomas dot Koenig at online dot de  2005-01-13 
22:14 ---
(In reply to comment #3)
> Sligtly updated patch:

.. which was broken; http://gcc.gnu.org/ml/gcc-patches/2005-01/msg00024.html
was correct (although it fails due to whitespace changes).

This patch does not fix all that's broken, though.  The following
test cases still fail with my patch:

program open_readonly
  call system("touch tst2.dat ; chmod 100 tst2.dat")
  open(unit=10,file="tst2.dat", err=9000)
  goto 30
9000 continue
  print *,"Opening read-only file failed"
  call abort
30 continue
end program open_readonly

program open_writeonly
  call system("touch tst1.dat ; chmod 200 tst1.dat")
  open(unit=10,file="tst1.dat", err=9000)
  goto 30
9000 continue
  print *,"Opening write-only file failed"
  call abort
30 continue
end program open_writeonly

so something else is needed.

I've removed the "patch" keyword.

-- 
   What|Removed |Added

   Keywords|patch   |


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

[Bug c++/10611] operations on vector mode not recognized in C++

[wilson at specifixinc dot com]

--- Additional Comments From wilson at specifixinc dot com  2005-01-13 
22:36 ---
Subject: Re:  operations on vector mode not recognized in C++

On Wed, 2005-01-12 at 01:44, rguenth at tat dot physik dot uni-tuebingen
dot de wrote:
> --- Additional Comments From rguenth at tat dot physik dot uni-tuebingen 
> dot de  2005-01-12 09:44 ---
> What is the status on this issue?

It is waiting for someone who works on the C++ FE to look at it.


-- 


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

[Bug libgcj/18222] [4.0 Regression] libjava bootstrap failure on Tru64 UNIX: CPPFLAGS changed in libltdl

[gerald at pfeifer dot com]

--- Additional Comments From gerald at pfeifer dot com  2005-01-13 22:45 
---
I can confirm that the patch addresses the issue from comment #1, which is a
good reason to go for that patch (even in case the alpha issue might not be
addressed).  Thanks!

-- 


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

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

[rakdver at gcc dot gnu dot org]

--- Additional Comments From rakdver at gcc dot gnu dot org  2005-01-13 
22:55 ---
http://gcc.gnu.org/ml/gcc-patches/2005-01/msg00761.html

-- 
   What|Removed |Added

   Keywords||patch


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

[Bug c++/19432] New: misaligned SSE-datatype

[Pferdebert at west dot de]

This is my first bug I report. I hope I do everything well:   
  
If I want to use SSE-instruction I use the build-in datatype. As long as you  
only use this one everything goes well.  
If this type is am member of a class then there occures a misalignment when  
allocating this with new:  
Here is a sample code:  
  
#include   
#include   
  
typedef float V4SF __attribute__ ((mode(V4SF)));  
  
#define ALIGN16 __attribute__((aligned(16)))  
#define __class16 class __attribute__((__aligned__(16)))  
  
//ALIGN16 struct SVector //neither ALIGN16   
__class16 SVector  //nor this variant works  
{  
public:  
  V4SF v;  
};  
  
using namespace std;  
  
int main(int argc, char *argv[])  
{  
  V4SF* pv = new V4SF;  
  cout << "Alignment (that should be): " << __alignof__(V4SF) << endl;  
  cout << "Adress dividable through 16? " << unsigned(&(*pv))%16 << endl;//This 
works  
   
  SVector* ps = new SVector; 
  cout << "Alignment (that should be): " << __alignof__(SVector) << endl;  
  cout << "Adress dividable through 16? " << unsigned(&(*ps))%16 << endl;//This 
doesn't work  
  //as you can see a movaps or similar instruction will crash the System  
   
  return EXIT_SUCCESS;  
}

-- 
   Summary: misaligned SSE-datatype
   Product: gcc
   Version: 3.4.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Pferdebert at west dot de
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug c++/15795] No way to teach operator new anything about alignment requirements

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-13 
23:20 ---
*** Bug 19432 has been marked as a duplicate of this bug. ***

-- 
   What|Removed |Added

 CC||Pferdebert at west dot de


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

[Bug c++/19432] misaligned SSE-datatype

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-13 
23:20 ---
This is a dup of bug 15795, which is not a GCC bug really, this is a bug in 
your OS (because malloc 
requires the largest alignment for all supported data types).

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

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug libstdc++/19433] New: set, multiset, map, multimap misuse hint on insert

[chris at bubblescope dot net]

Unless I'm misreading the source (possible) in bits/stl_tree.h in
insert_unique(iterator, const value_type&) and insert_equal(iterator, const
value_type&), it looks like we use the passed hint by trying to insert BEFORE
it, rather than after it. I'd imagine this bug is present in all versions of
libstdc++-v3.

This doesn't cause incorrect behaviour, just log(n) inserts rather than constant
time ones. In theory this shouldn't be too hard to fix, but playing with the
tree code may require being careful. I'm submitting a bug report just so it
doesn't get forgotten about :)

-- 
   Summary: set, multiset, map, multimap misuse hint on insert
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P2
 Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: chris at bubblescope dot net
CC: caj at cs dot york dot ac dot uk,gcc-bugs at gcc dot gnu
dot org


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

[Bug libstdc++/19433] set, multiset, map, multimap misuse hint on insert

[pcarlini at suse dot de]

--- Additional Comments From pcarlini at suse dot de  2005-01-13 23:53 
---
Indeed, will look into it. Thanks!

-- 
   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |pcarlini at suse dot de
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-01-13 23:53:08
   date||


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

[Bug target/19252] sub optimal use of fpu comparisons in SSE code

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-01-14 
00:34 ---
Subject: Bug 19252

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-01-14 00:33:51

Modified files:
gcc: ChangeLog 
gcc/config/i386: i386-protos.h i386.c i386.md 

Log message:
PR target/19099
PR target/19250
PR target/19252
* config/i386/i386.md (cmpdf, cmpsf, bunordered, bordered, buneq,
bunge, bungt, bunle, bunlt, bltgt): Enable for TARGET_SSE_MATH,
not just TARGET_SSE.
(cmpfp_i_387): Rename from cmpfp_i.  Move after sse patterns.
(cmpfp_i_mixed): Rename from cmpfp_i_sse; use for TARGET_MIX_SSE_I387.
(cmpfp_i_sse): Rename from cmpfp_i_sse_only; use for TARGET_SSE_MATH.
(cmpfp_iu_mixed, cmpfp_iu_sse, cmpfp_iu_387): Similarly.
(fp_jcc_1_mixed, fp_jcc_1_sse, fp_jcc_1_387): Similarly.
(fp_jcc_2_mixed, fp_jcc_2_sse, fp_jcc_2_387): Similarly.
(fp_jcc_3_387, fp_jcc_4_387, fp_jcc_5_387, fp_jcc_6_387,
fp_jcc_7_387, fp_jcc_8_387): Rename from fp_jcc_N.
(movdicc_c_rex64): Rename with '*'.
(movsfcc, movdfcc): Add checks for 387 and sse math to condition.
(movsfcc_1_sse_min, movsfcc_1_sse_max, movsfcc_1_sse): New.
(movsfcc_1_387): Rename from movsfcc_1.
(movdfcc_1_sse_min, movdfcc_1_sse_max, movdfcc_1_sse): New.
(movdfcc_1, movdfcc_1_rex64): Add check for 387.
(sminsf3, smaxsf3, smindf3, smaxdf3): New.
(minsf3, minsf, minsf_nonieee, minsf_sse, mindf3, mindf,
mindf_nonieee, mindf_sse, maxsf3, maxsf, maxsf_nonieee, maxsf_sse,
maxdf3, maxdf, maxdf_nonieee, maxdf_sse, sse_movsfcc, sse_movsfcc_eq,
sse_movdfcc, sse_movdfcc_eq, sse_movsfcc_const0_1,
sse_movsfcc_const0_2, sse_movsfcc_const0_3, sse_movsfcc_const0_4,
sse_movdfcc_const0_1, sse_movdfcc_const0_2, sse_movdfcc_const0_3,
sse_movdfcc_const0_4): Remove.
* config/i386/i386.c (ix86_expand_fp_movcc): For TARGET_SSE_MATH,
recognize min/max early.  Update for changed sse cmove patterns.
(ix86_split_sse_movcc): New.
* config/i386/i386-protos.h: Update.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.7114&r2=2.7115
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/i386/i386-protos.h.diff?cvsroot=gcc&r1=1.125&r2=1.126
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/i386/i386.c.diff?cvsroot=gcc&r1=1.776&r2=1.777
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/i386/i386.md.diff?cvsroot=gcc&r1=1.605&r2=1.606



-- 


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

[Bug c/19099] No warning for uninitialized local variable use

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-01-14 
00:34 ---
Subject: Bug 19099

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-01-14 00:33:51

Modified files:
gcc: ChangeLog 
gcc/config/i386: i386-protos.h i386.c i386.md 

Log message:
PR target/19099
PR target/19250
PR target/19252
* config/i386/i386.md (cmpdf, cmpsf, bunordered, bordered, buneq,
bunge, bungt, bunle, bunlt, bltgt): Enable for TARGET_SSE_MATH,
not just TARGET_SSE.
(cmpfp_i_387): Rename from cmpfp_i.  Move after sse patterns.
(cmpfp_i_mixed): Rename from cmpfp_i_sse; use for TARGET_MIX_SSE_I387.
(cmpfp_i_sse): Rename from cmpfp_i_sse_only; use for TARGET_SSE_MATH.
(cmpfp_iu_mixed, cmpfp_iu_sse, cmpfp_iu_387): Similarly.
(fp_jcc_1_mixed, fp_jcc_1_sse, fp_jcc_1_387): Similarly.
(fp_jcc_2_mixed, fp_jcc_2_sse, fp_jcc_2_387): Similarly.
(fp_jcc_3_387, fp_jcc_4_387, fp_jcc_5_387, fp_jcc_6_387,
fp_jcc_7_387, fp_jcc_8_387): Rename from fp_jcc_N.
(movdicc_c_rex64): Rename with '*'.
(movsfcc, movdfcc): Add checks for 387 and sse math to condition.
(movsfcc_1_sse_min, movsfcc_1_sse_max, movsfcc_1_sse): New.
(movsfcc_1_387): Rename from movsfcc_1.
(movdfcc_1_sse_min, movdfcc_1_sse_max, movdfcc_1_sse): New.
(movdfcc_1, movdfcc_1_rex64): Add check for 387.
(sminsf3, smaxsf3, smindf3, smaxdf3): New.
(minsf3, minsf, minsf_nonieee, minsf_sse, mindf3, mindf,
mindf_nonieee, mindf_sse, maxsf3, maxsf, maxsf_nonieee, maxsf_sse,
maxdf3, maxdf, maxdf_nonieee, maxdf_sse, sse_movsfcc, sse_movsfcc_eq,
sse_movdfcc, sse_movdfcc_eq, sse_movsfcc_const0_1,
sse_movsfcc_const0_2, sse_movsfcc_const0_3, sse_movsfcc_const0_4,
sse_movdfcc_const0_1, sse_movdfcc_const0_2, sse_movdfcc_const0_3,
sse_movdfcc_const0_4): Remove.
* config/i386/i386.c (ix86_expand_fp_movcc): For TARGET_SSE_MATH,
recognize min/max early.  Update for changed sse cmove patterns.
(ix86_split_sse_movcc): New.
* config/i386/i386-protos.h: Update.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.7114&r2=2.7115
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/i386/i386-protos.h.diff?cvsroot=gcc&r1=1.125&r2=1.126
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/i386/i386.c.diff?cvsroot=gcc&r1=1.776&r2=1.777
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/i386/i386.md.diff?cvsroot=gcc&r1=1.605&r2=1.606



-- 


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

[Bug target/19250] minss/maxss SSE insn not generated for -mfpmath=sse

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-01-14 
00:34 ---
Subject: Bug 19250

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-01-14 00:33:51

Modified files:
gcc: ChangeLog 
gcc/config/i386: i386-protos.h i386.c i386.md 

Log message:
PR target/19099
PR target/19250
PR target/19252
* config/i386/i386.md (cmpdf, cmpsf, bunordered, bordered, buneq,
bunge, bungt, bunle, bunlt, bltgt): Enable for TARGET_SSE_MATH,
not just TARGET_SSE.
(cmpfp_i_387): Rename from cmpfp_i.  Move after sse patterns.
(cmpfp_i_mixed): Rename from cmpfp_i_sse; use for TARGET_MIX_SSE_I387.
(cmpfp_i_sse): Rename from cmpfp_i_sse_only; use for TARGET_SSE_MATH.
(cmpfp_iu_mixed, cmpfp_iu_sse, cmpfp_iu_387): Similarly.
(fp_jcc_1_mixed, fp_jcc_1_sse, fp_jcc_1_387): Similarly.
(fp_jcc_2_mixed, fp_jcc_2_sse, fp_jcc_2_387): Similarly.
(fp_jcc_3_387, fp_jcc_4_387, fp_jcc_5_387, fp_jcc_6_387,
fp_jcc_7_387, fp_jcc_8_387): Rename from fp_jcc_N.
(movdicc_c_rex64): Rename with '*'.
(movsfcc, movdfcc): Add checks for 387 and sse math to condition.
(movsfcc_1_sse_min, movsfcc_1_sse_max, movsfcc_1_sse): New.
(movsfcc_1_387): Rename from movsfcc_1.
(movdfcc_1_sse_min, movdfcc_1_sse_max, movdfcc_1_sse): New.
(movdfcc_1, movdfcc_1_rex64): Add check for 387.
(sminsf3, smaxsf3, smindf3, smaxdf3): New.
(minsf3, minsf, minsf_nonieee, minsf_sse, mindf3, mindf,
mindf_nonieee, mindf_sse, maxsf3, maxsf, maxsf_nonieee, maxsf_sse,
maxdf3, maxdf, maxdf_nonieee, maxdf_sse, sse_movsfcc, sse_movsfcc_eq,
sse_movdfcc, sse_movdfcc_eq, sse_movsfcc_const0_1,
sse_movsfcc_const0_2, sse_movsfcc_const0_3, sse_movsfcc_const0_4,
sse_movdfcc_const0_1, sse_movdfcc_const0_2, sse_movdfcc_const0_3,
sse_movdfcc_const0_4): Remove.
* config/i386/i386.c (ix86_expand_fp_movcc): For TARGET_SSE_MATH,
recognize min/max early.  Update for changed sse cmove patterns.
(ix86_split_sse_movcc): New.
* config/i386/i386-protos.h: Update.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.7114&r2=2.7115
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/i386/i386-protos.h.diff?cvsroot=gcc&r1=1.125&r2=1.126
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/i386/i386.c.diff?cvsroot=gcc&r1=1.776&r2=1.777
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/i386/i386.md.diff?cvsroot=gcc&r1=1.605&r2=1.606



-- 


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

[Bug c++/19434] New: this->baseMemberTemplate() in derived doesnt compile

[johill at lanl dot gov]

The attached snippet does not compile with the attached compiler version.

class base {
protected:
template  P fred ( T & ) {return 0;};
};

template 
class derived : public base {
public:
void jane () {T t; this->fred(t);}
};

main ()
{
derived d;
d.jane ();
}

Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.2.3/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--disable-checking --with-system-zlib --enable-__cxa_atexit 
--host=i386-redhat-linux
Thread model: posix
gcc version 3.2.3 20030502 (Red Hat Linux 3.2.3-42)

-- 
   Summary: this->baseMemberTemplate() in derived doesnt compile
   Product: gcc
   Version: 3.2.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: johill at lanl dot gov
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: i386-redhat-linux
  GCC host triplet: i386-redhat-linux
GCC target triplet: i386-redhat-linux


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

[Bug c++/19434] this->baseMemberTemplate() in derived doesnt compile

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-14 
00:41 ---
This is a dup of one of the most reported bugs, PR 795.  And it is fixed in 
3.4.0.
The workaround is to do:
this->template fred(t);

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

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
   Keywords||rejects-valid
 Resolution||DUPLICATE


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

[Bug c++/795] parse error in member template method

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-14 
00:41 ---
*** Bug 19434 has been marked as a duplicate of this bug. ***

-- 
   What|Removed |Added

 CC||johill at lanl dot gov


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