[Bug c++/4672] [4.0 only] [DR 214] Template parameter deduction fails for overloaded template functions.

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-04-07 
07:04 ---
This was fixed on the mainline by the patch for PR 19203.

-- 
   What|Removed |Added

  BugsThisDependsOn||19203
Summary|[DR 214] Template parameter |[4.0 only] [DR 214] Template
   |deduction fails for |parameter deduction fails
   |overloaded template |for overloaded template
   |functions.  |functions.
   Target Milestone|--- |4.0.1


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

[Bug c++/12536] [DR 214/200] partial ordering bug

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-04-07 
07:06 ---
Hmm, on the mainline we reject this code:
t.cc: In function 'int main()':
t.cc:31: error: call of overloaded 'foo(int)' is ambiguous
t.cc:7: note: candidates are: some_type foo(const A&) [with A = int]
t.cc:13: note: some_type foo(const A&) [with R = int, A = 
int]
t.cc:32: error: call of overloaded 'bar(int)' is ambiguous
t.cc:19: note: candidates are: some_type bar(const A&, const A&) [with A = 
int]
t.cc:25: note: some_type bar(const A&, const R&) [with R = 
int, A = int]

-- 


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

[Bug c++/15674] [4.0 only] [DR214] template argument binding differs between member and static fumctions

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-04-07 
07:09 ---
On the mainline we reject this code:
t.cc: In function 'int main()':
t.cc:25: error: call of overloaded 'S(int [5])' is ambiguous
t.cc:16: note: candidates are: void S(T*) [with T = int]
t.cc:19: note: void S(T (&)[n]) [with T = int, long unsigned 
int n = 5ul]

Which is correct as we now implement DR 214.

Depending on PR 19203 as this only is a 4.0 bug.

-- 
   What|Removed |Added

  BugsThisDependsOn||19203
Summary|[DR214] template argument   |[4.0 only] [DR214] template
   |binding differs between |argument binding differs
   |member and static fumctions |between member and static
   ||fumctions
   Target Milestone|--- |4.0.1


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

[Bug rtl-optimization/17088] poor fortran optimisation at -O2/3

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-04-07 
07:24 ---
This seems to be fixed on the mainline at least for me:
gold:~>gfortran -O1 t.f90 
gold:~>!./
./a.out ; ./a.out ; ./a.out
  2.220446049250313E-016
   1.626753   0.9908500 
  2.220446049250313E-016
   1.5797601.008847 
  2.220446049250313E-016
   1.647750   0.9998480 
gold:~>gfortran -O2 t.f90
gold:~>!./
./a.out ; ./a.out ; ./a.out
  4.440892098500626E-016
   1.494772   0.7228900 
  4.440892098500626E-016
   1.532766   0.7168920 
  4.440892098500626E-016
   1.534767   0.7078920 
gold:~>gfortran -O3 t.f90
gold:~>!./
./a.out ; ./a.out ; ./a.out
  4.440892098500626E-016
   1.512770   0.7848810 
  4.440892098500626E-016
   1.524769   0.7228900 
  4.440892098500626E-016
   1.542766   0.7108920  

Though MATMUL should be able to improved still.

-- 


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

[Bug c++/19203] [3.4/4.0 Regression] [DR 214] Partial ordering failure between function reference and generic const reference

[igodard at pacbell dot net]

--- Additional Comments From igodard at pacbell dot net  2005-04-07 07:25 
---
Flagging it as ambiguous may be correct, but I agree with Nathan that it's
wrong :-)

Ivan

-- 


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

[Bug c++/15674] [4.0 only] [DR214] template argument binding differs between member and static fumctions

[igodard at pacbell dot net]

--- Additional Comments From igodard at pacbell dot net  2005-04-07 07:27 
---
Reporting it as ambiguous (as opposed to identifying the array) may be correct,
but I agree with Nathan that it's wrong :-)

-- 


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

[Bug c/20562] no unused warning for static arrays

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Target Milestone|4.0.0   |---


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

[Bug target/19672] Performance regression in simple loop code

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Target Milestone|3.4.4   |---


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

[Bug middle-end/12966] x86 array comparison optimization

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org
   Last reconfirmed|2004-10-29 14:05:26 |2005-04-07 07:59:45
   date||


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

[Bug target/20799] [4.0/4.1 Regression] bad relocs for new/delete overrides

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-04-07 08:17:48
   date||


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

[Bug target/20093] [4.0/4.1 Regression] 23_containers/deque/cons/2.cc execution test fails on ia64-hpux, -milp32

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-04-07 
08:22 ---
Subject: Bug 20093

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-04-07 08:21:36

Modified files:
gcc: ChangeLog simplify-rtx.c 

Log message:
PR target/20093
* simplify-rtx.c (simplify_unary_operation_1): Check
SUBREG_PROMOTED_UNSIGNED_P (op) > 0 for zero-extension.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.8178&r2=2.8179
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/simplify-rtx.c.diff?cvsroot=gcc&r1=1.235&r2=1.236



-- 


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

[Bug target/20093] [4.0/4.1 Regression] 23_containers/deque/cons/2.cc execution test fails on ia64-hpux, -milp32

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-04-07 
08:26 ---
Subject: Bug 20093

CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED]   2005-04-07 08:25:46

Modified files:
gcc: ChangeLog simplify-rtx.c 

Log message:
PR target/20093
* simplify-rtx.c (simplify_unary_operation): Check
SUBREG_PROMOTED_UNSIGNED_P (op) > 0 for zero-extension.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=2.7592.2.145&r2=2.7592.2.146
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/simplify-rtx.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.230.2.2&r2=1.230.2.3



-- 


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

[Bug target/18421] ICE in reload_cse_simplify_operands, at postreload.c:391

[corsepiu at gcc dot gnu dot org]

--- Additional Comments From corsepiu at gcc dot gnu dot org  2005-04-07 
08:26 ---
I can reproduce it with gcc-4.0.0 (20050406)

Interestingly, http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18421#c7
does not ICE with -mO0, -mO2, -mO3!

-- 
   What|Removed |Added

  Known to fail|3.4.3 3.4.4 |3.4.3 3.4.4 4.0.0


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

[Bug ada/20515] "stdcall" imports are not handled correctly

[dannysmith at users dot sourceforge dot net]

--- Additional Comments From dannysmith at users dot sourceforge dot net  
2005-04-07 08:29 ---
"So, what about the proposal on #4 ?"

OK with me.
Danny


-- 


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

[Bug libstdc++/20806] New: basic_filebuf::xsgetn() fails with text mode and

[dannysmith at users dot sourceforge dot net]

 

-- 
   Summary: basic_filebuf::xsgetn()  fails with text mode and
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dannysmith at users dot sourceforge dot net
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: i686-pc-mingw32
  GCC host triplet: i686-pc-mingw32
GCC target triplet: i686-pc-mingw32


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

[Bug libstdc++/20806] basic_filebuf::xsgetn() fails with text mode and DOS line endings and large buffers

[dannysmith at users dot sourceforge dot net]

--- Additional Comments From dannysmith at users dot sourceforge dot net  
2005-04-07 08:35 ---

This optimization in basic_filebuf::xsgetn() causes problems on DOS based file 
sytstem when ifstreams are opened in text mode (\r\n line endings) and the 
user suppled buffer length exceeds _M_buf_size. 

2004-09-13  Paolo Carlini  <[EMAIL PROTECTED]>

PR libstdc++/11722
* include/std/std_fstream.h (xsgetn): Declare only.
* include/bits/fstream.tcc (xsgetn): Define, optimize for the
always_noconv() case: when __n > __buflen, copy the available
buffer and issue a direct read.

The problem is that the native read translates the input \r\n to
\n,  returning the number of chars written, so this test:

fstream.tcc:line 550 
   if (__len == __n)
 {
   _M_set_buffer(0);
   _M_reading = true;
 }
 
fails.

Attached is a testcase submitted by a mingw user, The input file,
c:\winnt\schedlog.txt, has DOS line endings and is 32667 bytes in size.
The testcase stops after the first read with:

Is EOF? 1   gcount: 494

The first 512 bytes contain 18 line endings  

After reverting the xsgetn patch, or disabling for test mode files
with:

*** fstream.tcc.origSun Jan 30 17:44:23 2005
--- fstream.tcc Wed Apr  6 21:48:11 2005
*** namespace std
*** 521,530 
 // future: when __n > __buflen we read directly instead of using the
 // buffer repeatedly.
 const bool __testin = _M_mode & ios_base::in;
 const streamsize __buflen = _M_buf_size > 1 ? _M_buf_size - 1
 : 1;
 if (__n > __buflen && __check_facet(_M_codecvt).always_noconv()
!  && __testin && !_M_writing)
 {
   // First, copy the chars already present in the buffer.
   const streamsize __avail = this->egptr() - this->gptr();
--- 521,531 
 // future: when __n > __buflen we read directly instead of using the
 // buffer repeatedly.
 const bool __testin = _M_mode & ios_base::in;
+const bool __testbinary = _M_mode & ios_base::binary;
 const streamsize __buflen = _M_buf_size > 1 ? _M_buf_size - 1
 : 1;
 if (__n > __buflen && __check_facet(_M_codecvt).always_noconv()
!  && __testin && __testbinary && !_M_writing)
 {
   // First, copy the chars already present in the buffer.
   const streamsize __avail = this->egptr() - this->gptr();

the testcase produces:

Is EOF? 0   gcount: 512
Is EOF? 0   gcount: 512

  

Is EOF? 0   gcount: 512
Is EOF? 1   gcount: 294


Disabling this optimization for non-binary input streams on all platforms is a
bit extreme.   Should this be conditional on an os_defines.h define?

Danny


Testcase modified from:
https://sourceforge.net/tracker/?
func=detail&atid=102435&aid=1171379&group_id=2435

#include 
using namespace std;

#define BS 512

int main (void)
{
  char buf [BS+1];
  // change to any DOS text file > BS bytes
  ifstream f ("c:\\winnt\\schedlog.txt") ;
  int r;
  while (!f.eof ())
   {
 f.read (buf, BS);
 r = f.gcount ();
 buf [r] = 0;

fprintf (stderr, "%d %d: %s\n", f.eof (), r, buf);
   }

return 0;
}


-- 
   What|Removed |Added

Summary|basic_filebuf::xsgetn() |basic_filebuf::xsgetn()
   |fails with text mode and|fails with text mode and DOS
   ||line endings and large
   ||buffers


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

[Bug fortran/20807] New: compilation crashes when a module contains a procedure with the same name

[guillemborrell at yahoo dot es]

module fitness

  use modinit

   implicit none

  contains

  ...

  function fitness(word,totalsize)

 implicit none

 real:: fitness
 integer :: totalsize
 integer, dimension(totalsize) :: word
 
   ...

gives internal compiler error instead of showing the error in the code

[EMAIL PROTECTED] ~/DM $ gfc -c modinit.f90
[EMAIL PROTECTED] ~/DM $ gfc -c modfitness.f90
modfitness.f90:0: 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.

-- 
   Summary: compilation crashes when a module contains a procedure
with the same name
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: guillemborrell at yahoo dot es
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=20807

[Bug fortran/20807] compilation crashes when a module contains a procedure with the same name

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-04-07 
08:43 ---
Of course, I tried to reproduce this with the snip of code but cannot.

-- 


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

[Bug c/20808] New: Unrecognizable insn

[shubham_jain at da-iict dot org]

System type:Red Hat Linux 8.0 3.2-7

gcc Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--disable-checking --host=i386-redhat-linux --with-system-zlib 
--enable-__cxa_atexit

Command line:
avr-gcc -mmcu=atmega128 avr1.c
-Wl,--defsym=__heap_start=0x801100,--defsym=__heap_end=0x80

Compiler output:
avr1.c: In function `main':
avr1.c:16: error: unrecognizable insn:
(insn 29 27 73 0 0x400178c4 (set (reg:HI 55)
(const_int 44838 [0xaf26])) -1 (nil)
(nil))
avr1.c:16: internal compiler error: in extract_insn, at recog.c:2175
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.

-- 
   Summary: Unrecognizable insn
   Product: gcc
   Version: 3.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: shubham_jain at da-iict dot org
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug libstdc++/20806] [3.4/4.0/4.1 Regression] basic_filebuf::xsgetn() fails with text mode and DOS line endings and large buffers

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

Summary|basic_filebuf::xsgetn() |[3.4/4.0/4.1 Regression]
   |fails with text mode and DOS|basic_filebuf::xsgetn()
   |line endings and large  |fails with text mode and DOS
   |buffers |line endings and large
   ||buffers


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

[Bug target/20808] Unrecognizable insn

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

  Component|c   |target
 GCC target triplet||avr


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

[Bug target/20808] Unrecognizable insn

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Keywords||ice-on-valid-code


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

[Bug target/20808] Unrecognizable insn

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-04-07 
08:46 ---
Make sure that you attach the preprocessed source as requested by 
.

-- 


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

[Bug target/20808] Unrecognizable insn

[shubham_jain at da-iict dot org]

--- Additional Comments From shubham_jain at da-iict dot org  2005-04-07 
08:46 ---
Created an attachment (id=8552)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8552&action=view)
The source code with a simple for loop causing the error.

A simple for loop when removed removes the error. The problem is because of the
size of the declared arrays. But I cannot reduce the array size.

-- 


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

[Bug target/20808] Unrecognizable insn

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-04-07 
08:51 ---
Of course, the stack size is just huge (well huge for avr really).
Though with 4.0.0 and above, we remove these arrays as they are unused though 
if you used them, 
there will be still a bug.

Anyways this is a target bug.

-- 


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

[Bug middle-end/20648] [4.0/4.1 regression] ICE in cfg_layout_redirect_edge_and_branch_force

[schwab at suse dot de]

--- Additional Comments From schwab at suse dot de  2005-04-07 09:03 ---
Needs to be fixed on 4.0 branch as well. 

-- 
   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |


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

[Bug rtl-optimization/15242] [3.3/3.4 regression] pessimization of "goto *"

[schwab at suse dot de]

-- 
Bug 15242 depends on bug 20648, which changed state.

Bug 20648 Summary: [4.0/4.1 regression] ICE in 
cfg_layout_redirect_edge_and_branch_force
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20648

   What|Old Value   |New Value

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |

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

[Bug c/20809] New: ICE in gimplify_addr_expr, at gimplify.c:3253

[marcus at jet dot franken dot de]

attached when compiuled with -O2 shows for i386, x86_64 and ppc: 
 
gcc -v  
... 4.0.0 20050405 (prerelease) ... 
 
gcc -O2 xx.i 
xx.i: In function ‘f’: 
xx.i:11: internal compiler error: in gimplify_addr_expr, at gimplify.c:3253

-- 
   Summary: ICE in gimplify_addr_expr, at gimplify.c:3253
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: marcus at jet dot franken dot de
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: ppc-linux-gnu
  GCC host triplet: ppc-linux-gnu
GCC target triplet: ppc-linux-gnu


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

[Bug c/20809] ICE in gimplify_addr_expr, at gimplify.c:3253

[marcus at jet dot franken dot de]

--- Additional Comments From marcus at jet dot franken dot de  2005-04-07 
09:04 ---
Created an attachment (id=8553)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8553&action=view)
xx.i

testcase extracted from ncurses, compile with -O2.

-- 


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

[Bug c/20809] ICE in gimplify_addr_expr, at gimplify.c:3253

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-04-07 
09:05 ---


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

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug middle-end/20739] [4.0/4.1 regression] ICE in gimplify_addr_expr

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-04-07 
09:05 ---
*** Bug 20809 has been marked as a duplicate of this bug. ***

-- 
   What|Removed |Added

 CC||marcus at jet dot franken
   ||dot de


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

[Bug middle-end/20648] [4.0 regression] ICE in cfg_layout_redirect_edge_and_branch_force

[steven at gcc dot gnu dot org]

-- 
   What|Removed |Added

  Known to fail|4.0.0 4.1.0 |4.0.0
Summary|[4.0/4.1 regression] ICE in |[4.0 regression] ICE in
   |cfg_layout_redirect_edge_and|cfg_layout_redirect_edge_and
   |_branch_force   |_branch_force
   Target Milestone|4.1.0   |4.0.0


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

[Bug middle-end/20648] [4.0 regression] ICE in cfg_layout_redirect_edge_and_branch_force

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

 Status|REOPENED|ASSIGNED


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

[Bug fortran/20807] compilation crashes when a module contains a procedure with the same name

[guillemborrell at gmail dot com]

--- Additional Comments From guillemborrell at gmail dot com  2005-04-07 
09:09 ---
Subject: Re:  compilation crashes when a module contains
 a procedure with the same name

pinskia at gcc dot gnu dot org wrote:

>--- Additional Comments From pinskia at gcc dot gnu dot org  2005-04-07 
>08:43 ---
>Of course, I tried to reproduce this with the snip of code but cannot.
>
>  
>
Sorry, it crashes for something else, not just for the name conflict.  I
thought this because of the intel compiler output.

Now trying to find the real cause of the compiler's segmentation fault

regards

guillem

-- 
Guillem Borrell Nogueras

website http://torroja.dmt.upm.es/~guillem/

[EMAIL PROTECTED]
[EMAIL PROTECTED]

tf. 655388683




-- 


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

[Bug middle-end/20648] [4.0 regression] ICE in cfg_layout_redirect_edge_and_branch_force

[steven at gcc dot gnu dot org]

--- Additional Comments From steven at gcc dot gnu dot org  2005-04-07 
09:10 ---
The same patch as the one on mainline should work for 4.0.  

-- 
   What|Removed |Added

 AssignedTo|steven at gcc dot gnu dot   |unassigned at gcc dot gnu
   |org |dot org
 Status|ASSIGNED|NEW
   Keywords||patch


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

[Bug libstdc++/20806] [3.4/4.0/4.1 Regression] basic_filebuf::xsgetn() fails with text mode and DOS line endings and large buffers

[pcarlini at suse dot de]

--- Additional Comments From pcarlini at suse dot de  2005-04-07 09:14 
---
> The problem is that the native read translates the input \r\n to
> \n,  returning the number of chars written,

This is a very fundamental assumption to break, which is likely to case much
more problems elsewhere, maybe only latent now. The correct solution cannot
be just working around it in this function, instead something like using
unconditionally binary mode on mingw + libstdc++-v3. Ideas?

-- 


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

[Bug libstdc++/20806] [3.4/4.0/4.1 Regression] basic_filebuf::xsgetn() fails with text mode and DOS line endings and large buffers

[pcarlini at suse dot de]

--- Additional Comments From pcarlini at suse dot de  2005-04-07 09:14 
---
> The problem is that the native read translates the input \r\n to
> \n,  returning the number of chars written,

This is a very fundamental assumption to break, which is likely to cause much
more problems elsewhere, maybe only latent now. The correct solution cannot
be just working around it in this function, instead something like using
unconditionally binary mode on mingw + libstdc++-v3. Ideas?

-- 


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

[Bug rtl-optimization/20800] [4.0 regression] cris-elf testsuite failure: gcc.c-torture/execute/931004-6.c -O3

[hp at gcc dot gnu dot org]

--- Additional Comments From hp at gcc dot gnu dot org  2005-04-07 09:43 
---
In response to comment #1, you can (at least as the sole cause) rule out
PR rtl-optimization/20527, as I regression-tested that before committing.

-- 


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

[Bug libstdc++/20806] [3.4/4.0/4.1 Regression] basic_filebuf::xsgetn() fails with text mode and DOS line endings and large buffers

[pcarlini at suse dot de]

-- 
   What|Removed |Added

 CC||pcarlini at suse dot de


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

[Bug tree-optimization/19626] Aliasing says stores to local memory do alias

[rguenth at gcc dot gnu dot org]

--- Additional Comments From rguenth at gcc dot gnu dot org  2005-04-07 
10:30 ---
Created an attachment (id=8554)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8554&action=view)
Revised testcase without confusing casts

This changes the testcase to not cast int* to Loc<1>*, but use Loc<1>[2] as
storage for Loc<2> while retaining the initialization properties.  It requires
the testcase be compiled with tree-level loop-unrolling enabled, as the empty
constructors/destructors for array members are created as loops by the C++
frontend.

Other than that, struct aliasing (or just removing the casts) doesn't fix the
aliasing problems - though struct aliasing doesn't handle array elements at
the moment(?).

-- 
   What|Removed |Added

Attachment #8062 is|0   |1
   obsolete||


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

[Bug libstdc++/20806] [3.4/4.0/4.1 Regression] basic_filebuf::xsgetn() fails with text mode and DOS line endings and large buffers

[pcarlini at suse dot de]

--- Additional Comments From pcarlini at suse dot de  2005-04-07 10:31 
---
Ok, now I see the real, underlying problem: in config/io/basic_file_stdio.cc we
don't deal properly with "short read", that is, we don't try to loop if the
number of read chars is < n but > 0. Fixing that should also fix this specific
issue, but seems a bit risky for 4.0 :( I'm going to prepare a patch, anyway.

-- 
   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-04-07 10:31:03
   date||


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

[Bug c++/20805] Another debug info emitting bug

[greenrd at greenrd dot org]

--- Additional Comments From greenrd at greenrd dot org  2005-04-07 11:06 
---
gdb PR 1903 has already been filed for that.

-- 


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

[Bug c++/20805] Another debug info emitting bug

[jakub at gcc dot gnu dot org]

--- Additional Comments From jakub at gcc dot gnu dot org  2005-04-07 11:58 
---
Simplified testcase:
int *v;

int
*foo ()
{
  extern int *v;
  return static_cast (v);
}

compiled with just -g on e.g. x86-64 or i386.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-04-07 11:58:11
   date||


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

[Bug c++/20805] Another debug info emitting bug

[jakub at gcc dot gnu dot org]

--- Additional Comments From jakub at gcc dot gnu dot org  2005-04-07 12:13 
---
int *v;

int *
foo ()
{
  extern int *v;
  return v;
}

The section .debug_info contains:

  Compilation Unit @ 0:
   Length:208
   Version:   2
   Abbrev Offset: 0
   Pointer Size:  8
 <0>: Abbrev Number: 1 (DW_TAG_compile_unit)
 DW_AT_stmt_list   : 0
 DW_AT_high_pc : 0xd
 DW_AT_low_pc  : 0
 DW_AT_producer: GNU C++ 4.1.0 20050405 (experimental)
 DW_AT_language: 4  (C++)
 DW_AT_name: /tmp/23.ii
 <1><52>: Abbrev Number: 2 (DW_TAG_subprogram)
 DW_AT_sibling : <9a>
 DW_AT_external: 1
 DW_AT_name: foo
 DW_AT_decl_file   : 1
 DW_AT_decl_line   : 4
 DW_AT_MIPS_linkage_name: _Z3foov
 DW_AT_type: <9a>
 DW_AT_low_pc  : 0
 DW_AT_high_pc : 0xd
 DW_AT_frame_base  : 1 byte block: 56   (DW_OP_reg6)
 <2><7c>: Abbrev Number: 3 (DW_TAG_lexical_block)
 DW_AT_low_pc  : 0x4
 DW_AT_high_pc : 0xb
 <3><8d>: Abbrev Number: 4 (DW_TAG_variable)
 DW_AT_name: v
 DW_AT_decl_file   : 1
 DW_AT_decl_line   : 6
 DW_AT_type: <9a>
 DW_AT_external: 1
 DW_AT_declaration : 1
 <1><9a>: Abbrev Number: 5 (DW_TAG_pointer_type)
 DW_AT_byte_size   : 8
 DW_AT_type: 
 <1>: Abbrev Number: 6 (DW_TAG_base_type)
 DW_AT_name: int
 DW_AT_byte_size   : 4
 DW_AT_encoding: 5  (signed)
 <1>: Abbrev Number: 7 (DW_TAG_namespace)
 DW_AT_sibling : 
 DW_AT_name: ::
 DW_AT_decl_file   : 2
 DW_AT_decl_line   : 0
 <2>: Abbrev Number: 4 (DW_TAG_variable)
 DW_AT_name: v
 DW_AT_decl_file   : 1
 DW_AT_decl_line   : 6
 DW_AT_type: <9a>
 DW_AT_external: 1
 DW_AT_declaration : 1
 <2>: Abbrev Number: 8 (DW_TAG_variable)
 DW_AT_specification: <8d>
 DW_AT_decl_line   : 1
 DW_AT_declaration : 1
 <1>: Abbrev Number: 9 (DW_TAG_variable)
 DW_AT_specification: 
 DW_AT_location: 9 byte block: 3 0 0 0 0 0 0 0 0(DW_OP_addr: 0)

The gdb ICE happens when trying too lookup the 0x8d specification.

-- 


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

[Bug c++/20805] Another debug info emitting bug

[drow at gcc dot gnu dot org]

--- Additional Comments From drow at gcc dot gnu dot org  2005-04-07 12:31 
---
I have a GDB patch that will avoid the internal error.  I'll dig it up.

I suppose there's room to argue that GCC's output is correct.  Am I right in
thinking that the function-local extern could, in some cases, change the result
of name lookup?


-- 


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

[Bug libfortran/20766] gfortran - run time error when calling fortran subroutine from c

[dir at lanl dot gov]

--- Additional Comments From dir at lanl dot gov  2005-04-07 12:44 ---
Andrew, Is there a patch for this ?

-- 


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

[Bug tree-optimization/19626] Aliasing says stores to local memory do alias

[dberlin at dberlin dot org]

--- Additional Comments From dberlin at gcc dot gnu dot org  2005-04-07 
12:48 ---
Subject: Re:  Aliasing says stores to local
memory do alias


> Other than that, struct aliasing (or just removing the casts) doesn't fix the
> aliasing problems - though struct aliasing doesn't handle array elements at
> the moment(?).

Correct, it does not.

> 



-- 


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

[Bug tree-optimization/19626] Aliasing says stores to local memory do alias

[rguenth at tat dot physik dot uni-tuebingen dot de]

--- Additional Comments From rguenth at tat dot physik dot uni-tuebingen 
dot de  2005-04-07 12:50 ---
Subject: Re:  Aliasing says stores to local
 memory do alias

On 7 Apr 2005, dberlin at dberlin dot org wrote:

>
> --- Additional Comments From dberlin at gcc dot gnu dot org  2005-04-07 
> 12:48 ---
> Subject: Re:  Aliasing says stores to local
>   memory do alias
>
>
> > Other than that, struct aliasing (or just removing the casts) doesn't fix 
> > the
> > aliasing problems - though struct aliasing doesn't handle array elements at
> > the moment(?).
>
> Correct, it does not.

Ok, at least the RTL optimizers figure out that these stack locals
cannot alias.  Hope we get this for the tree optimizers, too.

Richard.

--
Richard Guenther 
WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/



-- 


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

[Bug libstdc++/20806] [3.4/4.0/4.1 Regression] basic_filebuf::xsgetn() fails with text mode and DOS line endings and large buffers

[pcarlini at suse dot de]

--- Additional Comments From pcarlini at suse dot de  2005-04-07 13:02 
---
Actually, we are not already doing that for a reason: doesn't work with pipes
(fifos), because, after the first succesful, short read, they block...

-- 


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

[Bug target/20810] New: [ARM thumb] ICE with C++ bitsets in thumb mode

[jifl-bugzilla at jifvik dot org]

Compile the following testcase with arm-elf-gcc 3.4.3 as follows:
arm-elf-gcc -c -mcpu=arm7tdmi -O2 -mthumb  bitset1.cxx

With bitset1.cxx containing:
#include 
extern void check(void);

// 64 works, 65 doesn't
//#define N 64
#define N 65

int main( int argc, char *argv[] )
{
typedef std::bitset B;
unsigned int i, j;

B b1, b2;

b2 = ~b1;
if ( b2 != ~b1 )
;

b2.reset();
for ( i = j = 0; i < N; i++ ) {
b2.set( j );
if ( i != b1.test(j) )
check();
j++;
}
b2 = ~b2;
}

The result is:
bitset1.cxx: In function `int main(int, char**)':
bitset1.cxx:27: error: insn does not satisfy its constraints:
(insn:HI 472 471 473 5 (set (reg:SI 3 r3 [169])
(mem/s:SI (plus:SI (reg:SI 1 r1 [304])
(reg/f:SI 13 sp)) [7 ._M_w S4 A32])) 126
{*thumb_movsi_insn} (nil)
(expr_list:REG_EQUIV (mem/s:SI (plus:SI (reg:SI 1 r1 [304])
(reg/f:SI 13 sp)) [7 ._M_w S4 A32])
(nil)))
bitset1.cxx:27: internal compiler error: in reload_cse_simplify_operands, at
postreload.c:391
Please submit a full bug report,
with preprocessed source if appropriate.

The testcase is a pared down fragment of a much larger function so it doesn't
make much sense any more, but it still reproduces the ICE.

I will attach the .ii file separately.

-- 
   Summary: [ARM thumb] ICE with C++ bitsets in thumb mode
   Product: gcc
   Version: 3.4.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jifl-bugzilla at jifvik dot org
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: arm-elf


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

[Bug target/20810] [ARM thumb] ICE with C++ bitsets in thumb mode

[jifl-bugzilla at jifvik dot org]

--- Additional Comments From jifl-bugzilla at jifvik dot org  2005-04-07 
13:56 ---
Created an attachment (id=8555)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8555&action=view)
Preprocessed testcase


-- 


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

[Bug libfortran/20766] gfortran - run time error when calling fortran subroutine from c

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-04-07 
13:57 ---
(In reply to comment #4)
> Andrew, Is there a patch for this ?

Not yet, I will to implement it later today after my classes are finished (at 
2pm).

-- 


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

[Bug c++/20805] Another debug info emitting bug

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-04-07 
14:03 ---
Jakub, do you know if this is a regression?

-- 
   What|Removed |Added

   Keywords||wrong-debug


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

[Bug middle-end/20794] [4.0/4.1 Regression] Miscompilation with __attribute ((aligned))

[jakub at gcc dot gnu dot org]

--- Additional Comments From jakub at gcc dot gnu dot org  2005-04-07 14:08 
---
This is caused by the big Ada patch that introduced the extra 2 ARRAY_REF
arguments.  Unfortunately, I couldn't find the reason why is the last
ARRAY_REF's argument measured in aligment units and not in bytes
(and what was the reason for adding this argument).

The size_zero_node in last ARRAY_REF's argument is created in
gimplify.c (canonicalize_addr_expr), because the element type has
TYPE_ALIGN_UNIT 16, but TYPE_SIZE_UNIT 4, therefore it is 0 strides and
when array_ref_element_size multiplies it again by TYPE_ALIGN_UNIT, the result
is 0 and not 4.

-- 
   What|Removed |Added

 CC||rth at gcc dot gnu dot org,
   ||kenner at gcc dot gnu dot
   ||org


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

[Bug c++/20805] Another debug info emitting bug

[jakub at gcc dot gnu dot org]

--- Additional Comments From jakub at gcc dot gnu dot org  2005-04-07 14:11 
---
It is a regression since 3.4.x in the sense that the same testcase
was debuggable by gdb.
But the main question now is I think whether what g++ 4.0 emits is correct
or not.

-- 


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

[Bug middle-end/20794] [4.0/4.1 Regression] Miscompilation with __attribute ((aligned))

[kenner at vlsi1 dot ultra dot nyu dot edu]

--- Additional Comments From kenner at vlsi1 dot ultra dot nyu dot edu  
2005-04-07 14:13 ---
Subject: Re:   [4.0/4.1 Regression] Miscompilation with __attribute ((aligned))

This is caused by the big Ada patch that introduced the extra 2
ARRAY_REF arguments.  Unfortunately, I couldn't find the reason why is
the last ARRAY_REF's argument measured in aligment units and not in
bytes (and what was the reason for adding this argument).

It has to do with the way MEM_ALIGN is computed.  What happens is that
when we compute the address of the MEM, we do it by multiplying the index
by the size in some units.  The second operand of that multiply is the only
way that RTL generation can know what the alignment is.  If the units
were in bytes, the multiplication wouldn't show the alignment.  We have
the same issue with DECL_FIELD_OFFSET.

There most definitely needs to be a better way to do this, but this goes back
years and I haven't found one.

The element type has TYPE_ALIGN_UNIT 16, but TYPE_SIZE_UNIT 4,

That's wrong.  The size always needs to be a multiple of the alignment.
That's fundamental.


-- 


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

[Bug middle-end/20648] [4.0 regression] ICE in cfg_layout_redirect_edge_and_branch_force

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-04-07 
14:21 ---
Subject: Bug 20648

CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED]   2005-04-07 14:21:22

Modified files:
gcc: ChangeLog bb-reorder.c 

Log message:
2005-04-03  Steven Bosscher  <[EMAIL PROTECTED]>

PR middle-end/20648
* bb-reorder.c (duplicate_computed_gotos): Do not unfactor
a computed goto if the edge to the computed goto block has
incoming abnormal edges.  Clarify how the function works.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=2.7592.2.146&r2=2.7592.2.147
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/bb-reorder.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.92.2.1&r2=1.92.2.2



-- 


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

[Bug middle-end/20794] [4.0/4.1 Regression] Miscompilation with __attribute ((aligned))

[jakub at gcc dot gnu dot org]

--- Additional Comments From jakub at gcc dot gnu dot org  2005-04-07 14:26 
---
> That's wrong.  The size always needs to be a multiple of the alignment.
> That's fundamental.

With user defined alignment, size certainly is not necessarily a multiple of the
alignment and with the exception of arrays it shouldn't cause any problems.
In arrays I agree this is a problem.  Now, the question is what to do:
1) issue error whenever a type with alignment bigger than size is used in
   an array
2) align the whole array and change the element type silently to a type
   with alignment equal to the element size


-- 


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

[Bug c++/20805] Another debug info emitting bug

[drow at gcc dot gnu dot org]

--- Additional Comments From drow at gcc dot gnu dot org  2005-04-07 14:28 
---
As for whether the debug information is correct:
  - It would be preferable if the full declaration was the one outside the
function rather than inside, but I don't think there's anything in the
standard to require this.
  - What the heck is the DW_TAG_namespace DIE for '::' doing there?  We 
shouldn't
be using an explicit namespace qualifier for things not in a namespace.

-- 


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

[Bug fortran/20811] New: gfortran include problem (regression from g77)

[afranck at gmx dot de]

Hello,

doing some experiments with gfortran, I stumbled across the following
bug/regression with respect to g77:

consider these two files in a directory "test":

$ cat test/foo.f:
  subroutine foo
  include   'test.h'
  end

$ cat test/test.h
c  just a comment

Now, compiling with g77:

~ $ g77 -c test/foo.f
[works ok]

and with gfortran:

~ $ gfortran -c test/foo.f
Error: Can't open included file 'test.h'

If I compile within "test":

~/test $ gfortran -c foo.f
[works ok]

everything is fine.

But "include" is IMHO supposed to include from where the source file is located,
not only in the current directory?

Greetings,
Andreas

-- 
   Summary: gfortran include problem (regression from g77)
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: afranck at gmx dot de
CC: gcc-bugs 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=20811

[Bug c++/20805] Another debug info emitting bug

[drow at false dot org]

--- Additional Comments From drow at false dot org  2005-04-07 14:39 ---
Subject: Re:  Another debug info emitting bug

On Thu, Apr 07, 2005 at 12:31:35PM -, drow at gcc dot gnu dot org wrote:
> I have a GDB patch that will avoid the internal error.  I'll dig it up.

See:
  http://sources.redhat.com/ml/gdb-patches/2005-04/msg00066.html



-- 


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

[Bug middle-end/20794] [4.0/4.1 Regression] Miscompilation with __attribute ((aligned))

[kenner at vlsi1 dot ultra dot nyu dot edu]

--- Additional Comments From kenner at vlsi1 dot ultra dot nyu dot edu  
2005-04-07 14:41 ---
Subject: Re:   [4.0/4.1 Regression] Miscompilation with __attribute ((aligned))

With user defined alignment, size certainly is not necessarily a
multiple of the alignment and with the exception of arrays it
shouldn't cause any problems.

Well, I always thought that was invalid.  Indeed for Ada, I make a new
type with the larger size.  We've never actually *documented* anywhere
that the size is a multiple of the alignment, but I think lots of stuff
all over the place silently assumes it.

In arrays I agree this is a problem.  Now, the question is what to do:
1) issue error whenever a type with alignment bigger than size is used in
   an array
2) align the whole array and change the element type silently to a type
   with alignment equal to the element size

I think (2) is best.


-- 


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

[Bug middle-end/20648] [4.0 regression] ICE in cfg_layout_redirect_edge_and_branch_force

[schwab at suse dot de]

--- Additional Comments From schwab at suse dot de  2005-04-07 14:44 ---
Really fixed now. 

-- 
   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug rtl-optimization/15242] [3.3/3.4 regression] pessimization of "goto *"

[schwab at suse dot de]

-- 
Bug 15242 depends on bug 20648, which changed state.

Bug 20648 Summary: [4.0 regression] ICE in 
cfg_layout_redirect_edge_and_branch_force
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20648

   What|Old Value   |New Value

 Status|REOPENED|ASSIGNED
 Status|ASSIGNED|NEW
 Status|NEW |RESOLVED
 Resolution||FIXED

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

[Bug tree-optimization/19626] Aliasing says stores to local memory do alias

[dberlin at dberlin dot org]

--- Additional Comments From dberlin at gcc dot gnu dot org  2005-04-07 
16:43 ---
Subject: Re:  Aliasing says stores to local
memory do alias

> >
> >
> > > Other than that, struct aliasing (or just removing the casts) doesn't fix 
> > > the
> > > aliasing problems - though struct aliasing doesn't handle array elements 
> > > at
> > > the moment(?).
> >
> > Correct, it does not.
> 
> Ok, at least the RTL optimizers figure out that these stack locals
> cannot alias.  Hope we get this for the tree optimizers, too.

It's already in my plans. It's just the implementation is a bit trickier
than one would like :)




-- 


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

[Bug fortran/20811] gfortran include problem (regression from g77)

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-04-07 
16:45 ---
Confirmed.

-- 
   What|Removed |Added

OtherBugsDependingO||19292
  nThis||
 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Keywords||rejects-valid
   Last reconfirmed|-00-00 00:00:00 |2005-04-07 16:45:11
   date||


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

[Bug other/20594] Building AVR cross compiler: cannot build libgcc2

[ericw at evcohs dot com]

--- Additional Comments From ericw at evcohs dot com  2005-04-07 16:47 
---
According to this related thread:


There is a patch on the MinGW project here:


This patch works on Win2K according to the related thread, and it works for me
for  WinXP.

-- 
   What|Removed |Added

 CC||dannysmith at users dot
   ||sourceforge dot net


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

[Bug other/20594] Building AVR cross compiler: cannot build libgcc2

[ericw at evcohs dot com]

--- Additional Comments From ericw at evcohs dot com  2005-04-07 16:50 
---
Created an attachment (id=8556)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8556&action=view)
Patch from MinGW project that fixes the problem on Win2k,XP

This patch is from the MinGW project, at this bug report:


-- 


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

[Bug other/20594] Building AVR cross compiler: cannot build libgcc2

[ericw at evcohs dot com]

-- 
   What|Removed |Added

   Keywords||patch


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

[Bug libgcj/20693] javax-imageio.lo failed to build

[hjl at lucon dot org]

--- Additional Comments From hjl at lucon dot org  2005-04-07 17:39 ---
Another patch is needed to fully fix the bug:

http://gcc.gnu.org/ml/gcc-patches/2005-04/msg00787.html

BTW, special charactor isn't supported by libtool:

http://lists.gnu.org/archive/html/bug-libtool/2005-04/msg00015.html


-- 


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

[Bug middle-end/20794] [4.0/4.1 Regression] Miscompilation with __attribute ((aligned))

[rth at gcc dot gnu dot org]

--- Additional Comments From rth at gcc dot gnu dot org  2005-04-07 17:52 
---
For the record, this has come up on the lists before in some slightly other
context and Mark has advocated (1).  I'm of a mind to agree.

-- 


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

[Bug middle-end/20794] [4.0/4.1 Regression] Miscompilation with __attribute ((aligned))

[kenner at vlsi1 dot ultra dot nyu dot edu]

--- Additional Comments From kenner at vlsi1 dot ultra dot nyu dot edu  
2005-04-07 17:54 ---
Subject: Re:   [4.0/4.1 Regression] Miscompilation with __attribute ((aligned))

For the record, this has come up on the lists before in some slightly
other context and Mark has advocated (1).  I'm of a mind to agree.

I should add that I understand both arguments and don't have a very
strong feeling either way.


-- 


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

[Bug middle-end/20794] [4.0/4.1 Regression] Miscompilation with __attribute ((aligned))

[mmitchel at gcc dot gnu dot org]

--- Additional Comments From mmitchel at gcc dot gnu dot org  2005-04-07 
18:00 ---
Yes, I still think that we ought to declare this invalid code.

If a particular front end (e.g., Ada) wants to adjust the types of the array
elements, etc., that's its business -- but the C/C++ front-ends should not.  And
the middle end should be able to expect that the size of the elements is at
least as large as their alignments.  

I think that once we agree on this, actually issuing the error will be easy to
do.  And, once we agree, we should change this PR to accepts-invalid.

-- 


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

[Bug c++/20812] New: contextual overload resolution failure for a member name found in two base classes

[SWElef at post dot sk]

The problem is best demonstrated by a code snippet. The following snippet
shows it as a wrong-code, but if we remove the first function template test
we get a rejects-valid case:

#include 
#include 

struct B1 { int foo; };
struct B2 { double foo; };
struct D: B1, B2 { };

template 
void test(...){
  std::cout << "the class does not have member foo with type 'int B1::*'" << 
std::endl;
}

template 
struct void_holder { typedef void type; };

template 
typename void_holder::type test(T*){
  std::cout << "the class has member foo with type 'int B1::*'" << std::endl;
}

int main(){
  test(0);
}

A specialization of the second function template test should be chosen because
the ambiguity between &B1::foo and &B2::foo can be resolved based on the
context, but a specialization of the first function template test is mistakenly
chosen. (Should we call it "overload" even though I chose non-function members?
Doesn't matter, it's the same with function members anyway.)

There is also a closely connected accepts-invalid case where the ambiguity
causes deduction failure instead of an error, but it's on the edge of core
issue #339. In PR6424 it was decided to say "sorry, unimplemented: call_expr
cannot be mangled due to a defect in the C++ ABI" for most of the cases
covered by core issue #339, but not for all. And this is a failure in one of
those that work:

struct B1 { int foo; };
struct B2 { double foo; };
struct D: B1, B2 { };

template 
void test(...){ }

template 
struct void_holder { typedef void type; };

template 
typename void_holder::type test(T*);

int main(){
  test(0); // should cause an error, not a deduction failure
  // for the second function template test
}

Regards,
Vladimir Marko

-- 
   Summary: contextual overload resolution failure for a member name
found in two base classes
   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=20812

[Bug middle-end/20794] [4.0/4.1 Regression] Miscompilation with __attribute ((aligned))

[kenner at vlsi1 dot ultra dot nyu dot edu]

--- Additional Comments From kenner at vlsi1 dot ultra dot nyu dot edu  
2005-04-07 18:03 ---
Subject: Re:   [4.0/4.1 Regression] Miscompilation with __attribute ((aligned))

And the middle end should be able to expect that the size of the
elements is at least as large as their alignments.

Are you suggesting that this be true just for *array* elements, for all
elements (including record components), or for all decls?


-- 


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

[Bug middle-end/20794] [4.0/4.1 Regression] Miscompilation with __attribute ((aligned))

[mark at codesourcery dot com]

--- Additional Comments From mark at codesourcery dot com  2005-04-07 18:08 
---
Subject: Re:  [4.0/4.1 Regression] Miscompilation with
 __attribute ((aligned))

kenner at vlsi1 dot ultra dot nyu dot edu wrote:
> --- Additional Comments From kenner at vlsi1 dot ultra dot nyu dot edu  
> 2005-04-07 18:03 ---
> Subject: Re:   [4.0/4.1 Regression] Miscompilation with __attribute 
> ((aligned))
> 
> And the middle end should be able to expect that the size of the
> elements is at least as large as their alignments.
> 
> Are you suggesting that this be true just for *array* elements, for all
> elements (including record components), or for all decls?

For array elements.  I don't see the same problem with record components 
or stand-along objects.  The problem comes only in arrays because that 
is where pointer-arithmetic is allowed, and then, either:

1. &a[1] != &a[0] + sizeof (a[0]), or

2. &a[1] is not aligned as per the element type

Both of those invariants are inviolate in C, in my opinion.



-- 


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

[Bug c++/20812] contextual overload resolution failure for a member name found in two base classes

[SWElef at post dot sk]

--- Additional Comments From SWElef at post dot sk  2005-04-07 18:12 ---
I forgot to write that I used gcc-3.4.2-mingw, gcc-3.4.3-cygwin and
gcc-4.0.0-experimental-20050130 and the results were the same, i.e. buggy.

Vladimir Marko



-- 
   What|Removed |Added

   Keywords||accepts-invalid, rejects-
   ||valid, wrong-code


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

[Bug c++/20812] contextual overload resolution failure for a member name found in two base classes

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-04-07 
18:14 ---
Just a note as I don't know if this is not a bug or not but ICC 8.1 also has 
the same behavior as GCC.

-- 
   What|Removed |Added

   Keywords|accepts-invalid, rejects-   |
   |valid, wrong-code   |


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

[Bug target/20093] [4.0/4.1 Regression] 23_containers/deque/cons/2.cc execution test fails on ia64-hpux, -milp32

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-04-07 
19:07 ---
Fixed.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED
   Target Milestone|4.1.0   |4.0.0


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

[Bug libfortran/20766] [darwin] - run time error when calling fortran subroutine from c

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-04-07 
19:08 ---
I am testing a patch right now.

-- 
   What|Removed |Added

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


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

[Bug libfortran/20766] [darwin] - run time error when calling fortran subroutine from c

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-04-07 
19:29 ---
Patch here: .

-- 
   What|Removed |Added

   Keywords||patch


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

[Bug target/20813] New: ICE in gen_reg_rtx for 3 spec tests

[janis at gcc dot gnu dot org]

Current GCC mainline fails to build SPEC CPU2000 tests gzip, bzip2,
and mesa on powerpc64-linux with -m64.  The same ICE is seen with
test gcc.c-torture/execute/930106-1.c:

elm3b149% /home/janis/tools/gcc-mline-20050407/bin/gcc -m64 -c 930106-1.c
930106-1.c: In function ‘f’:
930106-1.c:20: internal compiler error: in gen_reg_rtx, at emit-rtl.c:778
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.

This problem was introduced with the following patch, which might
have merely exposed a latent bug:

  http://gcc.gnu.org/ml/gcc-cvs/2005-03/msg01264.html

-- 
   Summary: ICE in gen_reg_rtx for 3 spec tests
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: janis at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org,geoffk at gcc dot gnu
dot org
 GCC build triplet: powerpc64-linux
  GCC host triplet: powerpc64-linux
GCC target triplet: powerpc64-linux


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

[Bug fortran/13082] Function entries and entries with alternate returns not implemented

[twilson at ems dot jsc dot nasa dot gov]

--- Additional Comments From twilson at ems dot jsc dot nasa dot gov  
2005-04-07 20:14 ---
I agree with both Federico Carminati and Alfredo Ferrari at CERN.  The compiler
is not usable and the impact is serious for thousands of existing fortran
programs.  Please fix it soon.

-- 
   What|Removed |Added

 CC||twilson at ems dot jsc dot
   ||nasa dot gov


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

[Bug target/20813] [4.1 Regression] ICE in gen_reg_rtx for 3 spec tests

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org
   Keywords||ice-on-valid-code
Summary|ICE in gen_reg_rtx for 3|[4.1 Regression] ICE in
   |spec tests  |gen_reg_rtx for 3 spec tests
   Target Milestone|--- |4.1.0


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

[Bug target/20813] [4.1 Regression] ICE in gen_reg_rtx for 3 spec tests

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-04-07 
20:50 ---
-m64 -mcpu=rs64a is enough to reproduce the bug.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-04-07 20:50:02
   date||


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

[Bug libstdc++/20758] operator-(const T&, const complex&) vs operator-(const complex&, const complex

[kreckel at ginac dot de]

--- Additional Comments From kreckel at ginac dot de  2005-04-07 20:51 
---
(In reply to comment #11)
> I think we need more careful analysis and tracking of both C99, C++ and
> LIA-3. 

Apart from looking at standards, we could also try to use our brains, right?  It
must be possible to answer the question whether the current behavior is right or
not by analogy with real numbers, ie. simply by looking at the imaginary part 
alone.

On systems without signed zero, there is no problem.

On systems with -0.0, the code is trying to compute 0.0 - 0.0.  Can that
possibly be -0.0?  If the answer is _no_, then this is a bug and it ought to be
fixed.  Period.  If the asnwer is _yes_, then, well, then I'm bemazed and 
confused.

BTW: I've always tought that systems that distinguish between 0.0 and -0.0, but
not between 0.0 and +0.0 are slightly broken from a mathematical point of view.
 I would much rather have three zeros: two with signs and one without a sign
that would have to be interpreted as having an indeterminate sign (or even
complex phase).  The "indetermanacy" of the sign could then be reliably
propagated to the result in additions, like this:
 +0.0 + +0.0 == +0.0
 +0.0 +  0.0 ==  0.0
 +0.0 + -0.0 ==  0.0
  0.0 +  0.0 ==  0.0
  0.0 + -0.0 ==  0.0
 -0.0 + -0.0 == -0.0
In such a scheme the sign carries more information than it does on my box which
asymetrically cares about a - sign but not about a + sign.  Sigh.


-- 


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

[Bug SWING/20804] JFrames not using insets to calculate size.

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-04-07 
20:51 ---
Confirmed.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-04-07 20:51:24
   date||


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

[Bug middle-end/15443] ICE with void f () __attribute__ ((__malloc__));

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-04-07 
20:52 ---
Fixed checked into the mainline for 4.1.0.

-- 
   What|Removed |Added

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


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

[Bug c++/19312] [3.4 Regression] ICE in stabilize_call when throwing a copy

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-04-07 
20:58 ---
Fixed.

-- 
   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug other/20792] [4.1 Regression] target.opt messages missing from gcc.pot

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-04-07 
20:58 ---
Fixed.

-- 
   What|Removed |Added

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


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

[Bug target/20625] [4.0/4.1 regression] ivopts produces code that generates "unaligned access exception"

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-04-07 
21:00 ---
Fixed.

-- 
   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug c++/19317] [4.1 Regression] removing a temporary return value when we cannot

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-04-07 
21:01 ---
Work around applied to the 4.0 branch so this is only 4.1 regression now

-- 
   What|Removed |Added

  Known to fail|4.0.0   |
  Known to work|3.4.0   |3.4.0 4.0.0
Summary|[4.0/4.1 Regression]|[4.1 Regression] removing a
   |removing a temporary return |temporary return value when
   |value when we cannot|we cannot
   Target Milestone|4.0.0   |4.1.0


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

[Bug libfortran/20766] [darwin] - run time error when calling fortran subroutine from c

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-04-07 
21:06 ---
Subject: Bug 20766

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-04-07 21:06:27

Modified files:
libgfortran: ChangeLog Makefile.am Makefile.in configure 
 configure.ac 

Log message:
2005-04-07  Andrew Pinski  <[EMAIL PROTECTED]>

PR libfortran/20766
* configure.ac (extra_ldflags_libgfortran): Set for *-darwin* to
"-Wl,-single_module".
* configure: Regenerate.
* Makefile.am (libgfortran_la_LDFLAGS): Add extra_ldflags_libgfortran.
* Makefile.in: Regenerate.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/ChangeLog.diff?cvsroot=gcc&r1=1.182&r2=1.183
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/Makefile.am.diff?cvsroot=gcc&r1=1.31&r2=1.32
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/Makefile.in.diff?cvsroot=gcc&r1=1.32&r2=1.33
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/configure.diff?cvsroot=gcc&r1=1.28&r2=1.29
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/configure.ac.diff?cvsroot=gcc&r1=1.22&r2=1.23



-- 


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

[Bug libstdc++/20758] operator-(const T&, const complex&) vs operator-(const complex&, const complex

[pcarlini at suse dot de]

--- Additional Comments From pcarlini at suse dot de  2005-04-07 21:17 
---
> Apart from looking at standards, we could also try to use our brains, right?
> It must be possible to answer the question whether the current behavior is 
> right or not by analogy with real numbers, ie. simply by looking at the 
> imaginary part alone.

Well, Richard, numerical analysis is not a game, is a well defined branch of
applied mathematics, with its theorems and well defined laws: we cannot
reinvent entire parts of it as part of our work. Which here basically is
about implementing standards, to our best, nothing more, nothing less. In
the specific case at issue, Gaby correctly mentions "LIA-3", one of our refs.
I must say, the copy I'm browsing ("Working draft of the First edition,
2002-07-10"), Section 5.2.5, says explicitly that (I'm using here a, more
practical in text mode, simplified, notation):

   x - (z + i * w) -> (x - z) + i * (-w)

We cannot disregard that, I think: before implementing something else we
should at least try to understand why "LIA-3" mandates that.

-- 


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

[Bug target/20814] New: ICE in extract_insn for test vmx/varargs-1.c

[janis at gcc dot gnu dot org]

Current GCC mainline gets an ICE on powerpc64-linux building the
test gcc.dg/vmx/varargs-1.c:

elm3b149% /home/janis/tools/gcc-mline-20050407/bin/gcc -m64 -O3 -maltivec
varargs-1.c
varargs-1.c: In function ‘f1’:
varargs-1.c:28: error: unrecognizable insn:
(insn 87 36 42 2 (set (reg:DI 10 10)
(and:DI (reg:DI 9 9 [orig:125 ap.25 ] [125])
(const_int -16 [0xfff0]))) -1 (nil)
(nil))
varargs-1.c:28: internal compiler error: in extract_insn, at recog.c:2042
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.

The failure starts with this patch, which might merely uncover a
latent bug:

  http://gcc.gnu.org/ml/gcc-cvs/2005-02/msg01069.html

-- 
   Summary: ICE in extract_insn for test vmx/varargs-1.c
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: janis at gcc dot gnu dot org
CC: dje at gcc dot gnu dot org,gcc-bugs at gcc dot gnu dot
org
 GCC build triplet: powerpc64-linux
  GCC host triplet: powerpc64-linux
GCC target triplet: powerpc64-linux


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

[Bug rtl-optimization/20815] New: -fprofile-use barfs with "coverage mismatch for function '...' while reading counter 'arcs'."

[dank at kegel dot com]

This problem is present in at least gcc-3.4.[123], gcc-3.4-20050401, and
gcc-4.0-20050305.  I have not tested a later gcc-4.0 yet.

Create a test file pgo.cc:
 #include 
 namespace {
   void
   func() {
 std::cout << "In func" << std::endl;
   }
 }
 int main() { func(); } 

Compile it, run it, and recompile it as follows:
  i686-unknown-linux-gnu-g++  -fprofile-generate -o pgo pgo.cc 
  ./pgo
  i686-unknown-linux-gnu-g++  -fprofile-use -o pgo pgo.cc 

The -fprofile-use compilation fails with
pgo.cc: In function 'void::func()':
pgo.cc:6: error: coverage mismatch for function
'_ZN35_GLOBAL__N_pgo.cc__8B40D3D54funcEv' while reading counter 'arcs'.
pgo.cc:6: error: checksum is 5c057dbb instead of 3746c244

Commenting out the namespace makes the problem go away.
This keeps me from building some real apps with profile-driven optimization,
which may result in switching from gcc to icc for this app.

Thanks to Simon Baldwin for finding such a nice little test case for this.

-- 
   Summary: -fprofile-use barfs with "coverage mismatch for function
'...' while reading counter 'arcs'."
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dank at kegel dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC target triplet: i686-linux


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

[Bug c++/20816] New: Can't find member function of template

[igodard at pacbell dot net]

In the attached code the compiler can find data members of the template, but 
not a
function member.

-- 
   Summary: Can't find member function of template
   Product: gcc
   Version: 3.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: igodard at pacbell dot net
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug c++/20816] Can't find member function of template

[igodard at pacbell dot net]

--- Additional Comments From igodard at pacbell dot net  2005-04-07 21:58 
---
Created an attachment (id=8557)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8557&action=view)
compiler output


-- 


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

[Bug c++/20816] Can't find member function of template

[igodard at pacbell dot net]

--- Additional Comments From igodard at pacbell dot net  2005-04-07 21:58 
---
Created an attachment (id=8558)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8558&action=view)
source code (compressed)


-- 


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

[Bug libstdc++/20758] operator-(const T&, const complex&) vs operator-(const complex&, const complex

[kreckel at ginac dot de]

--- Additional Comments From kreckel at ginac dot de  2005-04-07 22:06 
---
(In reply to comment #15)
> Well, Richard, numerical analysis is not a game, ...

Right, but a logical argument is not a game.

>x - (z + i * w) -> (x - z) + i * (-w)
> 
> We cannot disregard that, I think: before implementing something else we
> should at least try to understand why "LIA-3" mandates that.

Indeed.  Has that standard been released yet?  What's the exact reference, and
is there some public access, maybe to drafts?


-- 


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