[Bug target/21387] Unaligned writes on MIPSEL systems after typecast

[rsandifo at gcc dot gnu dot org]

--- Additional Comments From rsandifo at gcc dot gnu dot org  2005-05-05 
07:11 ---
I'm confused by this report.  You use:

*((int32_t *) a.unaligned_int) = 0x123456;

which reads the value of a.unaligned_int, casts it from an integer
to a pointer, and then dereferences the pointer.  Why do you expect
the store to be unaligned?  There's no reason to assume that,
just because the address was stored in an unaligned location,
the thing it points to is also unaligned.

Did you mean to write &a.aligned_int instead?  If so, then like
Andrew says, that's invalid.  You can't access an unaligned object
(a.unaligned_int) as though it had an aligned type (int32_t).

Richard

-- 
   What|Removed |Added

 CC||rsandifo at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |WAITING


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

[Bug fortran/21394] New: Internal compiler error, possibly due to large parameter array

[gnalle at ruc dot dk]

The following program causes my gfortran to throw an internal compiler 
error. The problem does not occur for N=10, so I gather that it happens 
due to a maximum limit on parameter array size. 

[niels:~]% cat test.f
  MODULE TEST

  integer ilocal

  integer,parameter :: N=50
  integer, parameter :: na = N/2
  integer, parameter :: nb = N-NA

  real*8, dimension(2),parameter :: masses=(/1.0,1.0/)

  real*8, dimension(3*n),parameter ::
 $  massvector = (/
 $  (masses(1),ilocal=1,Na),(masses(2),ilocal=1,Nb),
 $  (masses(1),ilocal=1,Na),(masses(2),ilocal=1,Nb),
 $  (masses(1),ilocal=1,Na),(masses(2),ilocal=1,Nb)
 $  /)

  END MODULE



[niels:~]% gfortran-4.0 -c test.f -o  test.o
test.f:0: internal compiler error: Possible frontend bug: array constructor not
expanded
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
For Debian GNU/Linux specific bug reporting instructions,
see .

[niels:~]% gfortran-4.0 -v -save-temps -c test.f -o  test.o
Using built-in specs.
Target: i486-linux
Configured with: ../src/configure -v --enable-languages=c,c++,java,f95,objc,ada
--prefix=/usr --libexecdir=/usr/lib --enable-shared --with-system-zlib
--enable-nls --enable-threads=posix --without-included-gettext
--program-suffix=-4.0 --enable-__cxa_atexit --enable-libstdcxx-allocator=mt
--enable-clocale=gnu --enable-libstdcxx-debug --enable-java-gc=boehm
--enable-java-awt=gtk --enable-gtk-cairo --enable-mpfr --enable-checking=release
i486-linux
Thread model: posix
gcc version 4.0.0 20050301 (prerelease) (Debian 4.0-0pre6ubuntu6)
 /usr/lib/gcc/i486-linux/4.0.0/f951 test.f -ffixed-form -quiet -dumpbase test.f
-mtune=i486 -auxbase-strip test.o -version -o test.s
GNU F95 version 4.0.0 20050301 (prerelease) (Debian 4.0-0pre6ubuntu6) 
(i486-linux)
compiled by GNU C version 4.0.0 20050301 (prerelease) (Debian
4.0-0pre6ubuntu6).
GGC heuristics: --param ggc-min-expand=64 --param ggc-min-heapsize=64545
test.f:0: internal compiler error: Possible frontend bug: array constructor not
expanded
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
For Debian GNU/Linux specific bug reporting instructions,
see .

-- 
   Summary: Internal compiler error, possibly due to large parameter
array
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gnalle at ruc dot dk
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug c++/21393] Internal error: Segmentation Fault (program cc1plus) on a very long cout << ... << command

[pavel dot petrovic at gmail dot com]

-- 
   What|Removed |Added

  Known to fail||3.4.3 3.3.5
  Known to work||2.95.2 2.96


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

[Bug rtl-optimization/21395] New: Performance degradation when building code that uses MMX intrinsics with gcc-4.0.0

[asuraparaju at gmail dot com]

gcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.0.0/configure --prefix=/usr/local/gcc-4.0.0
Thread model: posix
gcc version 4.0.0
chandra.anuradha% gcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.0.0/configure --prefix=/usr/local/gcc-4.0.0
Thread model: posix
gcc version 4.0.0

Compile line:
g++ -mmmx -g -O3  test_mmx_diff4.cpp

Background: Dirac video codec project uses MMX  to speed up the encoding
process. When using gcc 3.3.x and gcc-3.4.x there is a performance gain between
20-30% depending on the platform Dirac is built on. However, there was a huge
perfomance dip when the Dirac project was built using gcc-4.0.0.In fact, on 32
bit systems the Dirac system performed worse with MMX optimisations enabled than
with them turned off. 

I've incorporated a scaled down version of a Dirac class that uses MMX opts in
the attached test_mmx_diff4.cpp and compared the performance of gcc-4.0.0 with
gcc-3.4.3 / gcc-3.3.3 on different architectures. The performance comparison
results are as follows:


Compile line
g++ -mmmx -g -O3  test_mmx_diff4.cpp

1. AMD Dual Opteron Processor, Suse 9.2 (32 bit)

Results:

gcc-3.4.3  gcc-4.0.1 20050503 (prerelease)

real 1.25  real 2.87
user 1.24  user 2.87
sys 0.00   sys 0.00


2. Intel Dual Xeon 3.0 GHz, Suse 9.2 64 bit

Results:

gcc-3.4.3  gcc-4.0.0

real 1.09  real 1.58
user 1.09  user 1.54
sys 0.00   sys 0.00

3. Pentium 4 2.66GHz, Suse 9.2

Results:

gcc3.3 20030226gcc-4.0.0

real 1.35  real 4.98
user 1.32  user 4.96
sys 0.00   sys 0.00


gcc-4.0.0 performed worse than gcc-3.3.3 or gcc3.4.3 even for this simple 
program. The test results using Dirac were similar to this.

I posted a message on the gcc mailing list and here's an excerpt from one of the
replies.

---
I took a quick look at it.  It appears to be a register allocation
issue.  The gcc mainline compiled code I looked at uses 3 mmx registers,
and ends up putting one variable on the stack, thus needing two extra
loads and stores in the inner loop.  The gcc-3.3.3 compiled code I
looked at put everything in registers, using 7 mmx registers, and no
unnecessary loads/stores in the inner loop.


-- 
   Summary: Performance degradation when building code that uses MMX
intrinsics with gcc-4.0.0
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: asuraparaju at gmail dot com
CC: asuraparaju at gmail dot com,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 configured with: ../gcc-
4.0.0/configure --pref


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

[Bug rtl-optimization/21395] Performance degradation when building code that uses MMX intrinsics with gcc-4.0.0

[asuraparaju at gmail dot com]

--- Additional Comments From asuraparaju at gmail dot com  2005-05-05 09:14 
---
Created an attachment (id=8822)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8822&action=view)
A class that uses MMX intrinsics to compute block differences between two video
frames


-- 


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

[Bug inline-asm/21396] New: inline asm doesn't compile with -O2 optimization

[gleb76 at gmail dot com]

following code doesnt compile with command "gcc -c  -O2 -o a.o a.c". It compiles
with any other -O flag. The error is:
a.c: In function `main':
a.c:7: error: inconsistent operand constraints in an `asm'

Here is the code:
typedef struct {
unsigned long sig[2];
} sigset_t;

static __inline__ void sigaddset(sigset_t *set, int _sig)
{
__asm__("btsl %1,%0" : "=m"(*set) : "Ir"(_sig - 1) : "cc");
}

extern int a(void);
int main (int argc, char **argv)
{
sigset_t s;
int i;

for (i=0; i<64; i++)
sigaddset (&s, i);
a();
return 0;
}

I tested it on Red Hat Enterprise Linux AS release 4. 
$ gcc --version
gcc (GCC) 3.4.3 20041212 (Red Hat 3.4.3-9.EL4)

-- 
   Summary: inline asm doesn't compile with -O2 optimization
   Product: gcc
   Version: 3.4.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: inline-asm
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gleb76 at gmail dot com
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=21396

[Bug target/21397] New: -march selects wrong arm_tune flags

[trauscher at loytec dot com]

When using -march, wrong tuning flags are selected.
E.g., -march=armv4t selects 'tune_flags' for arm600, instead of
arm7tdmi (or similar). The error is in arm_override_options().

When "-march" is given, (sel - all_architectures) is calculated.
In contrast, "-mcpu" calculates (sel -  all_cores). This
array index is stored in 'arm_tune' (arm.c:791)

In arm.c:909 tune_flags are always taken from all_cores so 
that the calculated index references the wrong array when
using "-march"

tune_flags = all_cores[(int)arm_tune].flags;

-- 
   Summary: -march selects wrong arm_tune flags
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: trauscher at loytec dot com
CC: gcc-bugs at gcc dot gnu dot org
  GCC host triplet: i386-linux
GCC target triplet: arm-*-elf


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

[Bug target/21387] Unaligned writes on MIPSEL systems after typecast

[maarten at contemplated dot nl]

--- Additional Comments From maarten at contemplated dot nl  2005-05-05 
11:49 ---
(In reply to comment #2)

You are completely right, the code above merely demonstrates what happens when
one writes to an illegal address. The correct version,

*((int32_t *) &a.unaligned_int32) = 0x123456;

does work. Sorry, result of 'compressing' the problem.

My 'unaligned write' problem is, however, still there. I stumbled over it when
trying to compile code where copying of 16 bytes (in a char array) was
implemented as two reads and writes of int64_t. The problem occurs when
typecasting char arrays to integer types, see modified example:

1: 

#include 

int main(int argc, char *argv[]) {
char x[100];

*((int32_t *) ((char *) (x))) = 0x123456;   // ok
*((int32_t *) ((char *) (x+4))) = 0x123456; // ok
*((int32_t *) ((char *) (x+1))) = 0x123456; // fails

return(0);
}

2: (more related to original)

#include 

#pragma pack(1)
typedef struct  {
int8_t  byte;   // removing this byte, code executes
char unaligned_int32[4];
} test_unaligned;
#pragma pack()

int main(int argc, char *argv[]) {
test_unaligned a;

*((int32_t *) a.unaligned_int32) = 0x123456;// fails
 
return(0);
}



-- 


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

[Bug tree-optimization/21076] [4.1 Regression] ACATs ICE cxh1001 at tree-vrp.c:124

[laurent at guerby dot net]

--- Additional Comments From laurent at guerby dot net  2005-05-05 11:56 
---
Seems to be fixed on HEAD as of LAST_UPDATED: Thu May  5 08:05:40 UTC 2005
on x86 and x86_64-linux:

http://gcc.gnu.org/ml/gcc-testresults/2005-05/msg00284.html
http://gcc.gnu.org/ml/gcc-testresults/2005-05/msg00285.html


-- 


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

[Bug target/21387] Unaligned writes on MIPSEL systems after typecast

[maarten at contemplated dot nl]

--- Additional Comments From maarten at contemplated dot nl  2005-05-05 
11:56 ---
(In reply to comment #2)

Reading your reply further, I understand that the behavior I observere is
correct and related to the fact that the 'int32_t' type is assumed to be 
aligned. 

It is not a bug then, but merely a bit of a problem for me. Is there a typecast
to tell the compiler that the adress references an unaligned integer, i.e.
something like int32_unaligned_t?

-- 
   What|Removed |Added

 Status|WAITING |SUSPENDED


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

[Bug target/21387] Unaligned writes on MIPSEL systems after typecast

[rsandifo at gcc dot gnu dot org]

--- Additional Comments From rsandifo at gcc dot gnu dot org  2005-05-05 
12:01 ---
> Reading your reply further, I understand that the behavior I observere is
> correct and related to the fact that the 'int32_t' type is assumed to be
> aligned.

Right.

> It is not a bug then, but merely a bit of a problem for me. Is there a
> typecast to tell the compiler that the adress references an unaligned
> integer, i.e. something like int32_unaligned_t?

'Fraid not.  The "packed" attribute can't be applied to scalars
(and would in any case interfere a bit with the type system).
I think the best you can do is define a packed struct containing
a single int32_t field.  Yes, it will clutter the code a bit,
but it will be type-safe.

Richard


-- 
   What|Removed |Added

 Status|SUSPENDED   |RESOLVED
 Resolution||INVALID


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

[Bug middle-end/21285] gij fails to handle NullPointerException exception

[tsv at solvo dot ru]

--- Additional Comments From tsv at solvo dot ru  2005-05-05 13:13 ---
I put my code into try/catch block and the exception was successfully caught.
How general EH is supposed to be called? Could it be arch specific?


-- 


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

[Bug other/21398] New: gcc emits invalid operands for xchgb %b0, %h0

[pluto at pld-linux dot org]

the code like this: 
 
unsigned short swap16(unsigned short x) 
{ 
asm volatile ("xchgb %b0, %h0" : "=q" (x) : "0" (x)); 
return x; 
} 
 
produces: 
 
swap16: xchgb   %dil, %di   <== %di isn't valid high 8-bit form. 
movzwl  %di,  %eax 
ret 
 
IIRC the %rdi, %rsi, %rsp, %rbp haven't a high 8-bit form.

-- 
   Summary: gcc emits invalid operands for xchgb %b0, %h0
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pluto at pld-linux dot org
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: amd64-pld-linux
  GCC host triplet: amd64-pld-linux
GCC target triplet: amd64-pld-linux


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

[Bug other/21398] gcc emits invalid operands for xchgb %b0, %h0

[pluto at pld-linux dot org]

-- 
   What|Removed |Added

 CC||mmazur at kernel dot pl


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

[Bug other/21398] gcc emits invalid operands for xchgb %b0, %h0

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-05 
13:49 ---
"`a', b, c, or d register for the i386. For x86-64 it is equivalent to `r' 
class (for 8-bit instructions that 
do not use upper halves). "

-- 


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

[Bug c++/21363] no compilation error for inheriting Base class with private constructor when the constructor for Derived Class is compiler generated

[giovannibajo at libero dot it]

--- Additional Comments From giovannibajo at libero dot it  2005-05-05 
13:54 ---
The compiler is allowed to generate syntectic methods as lazy as possible, 
which is upon the first actual use. Thus, this is not a bug.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug java/21070] [4.1 Regression]: java compiler generates wrong code on ia64

[schwab at suse dot de]

--- Additional Comments From schwab at suse dot de  2005-05-05 14:14 ---
I'm seeing the same error in some C++-only packages.  The smallest example I 
could find is jikes 
: 
 
g++  -O2 -fmessage-length=0 -Wall   -o jikes  ast.o body.o bytecode.o case.o 
class.o code.o control.o decl.o definite.o depend.o diagnose.o double.o dump.o 
error.o expr.o incrmnt.o init.o javaact.o jikes.o jikesapi.o long.o lookup.o 
lpginput.o modifier.o op.o option.o parser.o platform.o scanner.o segment.o 
set.o stream.o symbol.o system.o tab.o unparse.o unzip.o zip.o 
/usr/lib/gcc/ia64-suse-linux/4.0.1/../../../../ia64-suse-linux/bin/ld: 
`.gnu.linkonce.t._ZN12ConstantPool9CPInvalidD1Ev' referenced in section 
`.gnu.linkonce.ia64unw._ZN12ConstantPool9CPInvalidD1Ev' of class.o: defined in 
discarded section 
`.gnu.linkonce.t._ZN12ConstantPool9CPInvalidD1Ev[ConstantPool::CPInvalid::~CPInvalid()]'
 
of class.o 
/usr/lib/gcc/ia64-suse-linux/4.0.1/../../../../ia64-suse-linux/bin/ld: final 
link failed: Bad value 
 

-- 


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

[Bug other/21398] gcc emits invalid operands for xchgb %b0, %h0

[pluto at pld-linux dot org]

--- Additional Comments From pluto at pld-linux dot org  2005-05-05 14:22 
---
in online docs i see that "q" means "byte addressable register (a,b,c,d)". 
in i386.h i see something differ for x86_64. did i miss something in docs? 
 
#define REG_CLASS_FROM_LETTER(C)\ 
  ((C) == 'r' ? GENERAL_REGS :  \ 
   (C) == 'R' ? LEGACY_REGS :   \ 
   (C) == 'q' ? TARGET_64BIT ? GENERAL_REGS : Q_REGS :  \ 
^^^ 
   (C) == 'Q' ? Q_REGS :\ 
 

-- 


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

[Bug other/21398] gcc emits invalid operands for xchgb %b0, %h0

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-05 
14:24 ---
(In reply to comment #2)
> in online docs i see that "q" means "byte addressable register (a,b,c,d)". 
> in i386.h i see something differ for x86_64. did i miss something in docs? 

Yes see comment #1 which is a quote from the docs.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug tree-optimization/21399] New: libstdc++ 12077.cc ICE

[dje at gcc dot gnu dot org]

libstdc++-v3/testsuite/ext/stdio_sync_filebuf/wchar_t/12077.cc ICEs when
compiled on AIX:

libstdc++-v3/testsuite/ext/stdio_sync_filebuf/wchar_t/12077.cc
: In function 'void test01()':
libstdc++-v3/testsuite/ext/stdio_sync_filebuf/wchar_t/12077.cc
:24: error: BB 3 can not throw but has EH edges
libstdc++-v3/testsuite/ext/stdio_sync_filebuf/wchar_t/12077.cc
:24: internal compiler error: verify_flow_info failed

-- 
   Summary: libstdc++ 12077.cc ICE
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code, ice-checking
  Severity: normal
  Priority: P2
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dje at gcc dot gnu dot org
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=21399

[Bug tree-optimization/21399] libstdc++ 12077.cc ICE

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org


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

[Bug tree-optimization/21399] libstdc++ 12077.cc ICE

[dje at gcc dot gnu dot org]

--- Additional Comments From dje at gcc dot gnu dot org  2005-05-05 14:34 
---
Created an attachment (id=8824)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8824&action=view)
pre-processed source for 12077.cc


-- 


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

[Bug tree-optimization/21399] libstdc++ 12077.cc ICE

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-05 
14:35 ---
Also happens on ppc-darwin.

-- 


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

[Bug tree-optimization/21399] libstdc++ 12077.cc ICE

[dje at gcc dot gnu dot org]

--- Additional Comments From dje at gcc dot gnu dot org  2005-05-05 14:37 
---
The failure appeared April 25.

-- 


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

[Bug c/21400] New: ppc-eabisim ICE in expand_builtin_int_roundingfn

[amylaar at gcc dot gnu dot org]

bash-2.05b$ cat tst.c
extern double floor (double);

int
f (float minX)
{
  return (int)floor(minX);
}
bash-2.05b$ ./cc1 tst.c -Os 
 f

Analyzing compilation unitPerforming intraprocedural optimizations
Assembling functions:
 f

tst.c: In function ‘f’:
tst.c:6: internal compiler error: in expand_builtin_int_roundingfn, at
builtins.c:2225
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
bash-2.05b$ ./cc1 --version
GNU C version 4.1.0 20050428 (experimental) (powerpc-eabisim)
compiled by GNU C version 3.2.3 20030502 (Red Hat Linux 3.2.3-49).
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096

-- 
   Summary: ppc-eabisim ICE in expand_builtin_int_roundingfn
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P2
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: amylaar at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: ppc-eabisim


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

[Bug other/21398] gcc emits invalid operands for xchgb %b0, %h0

[pluto at pld-linux dot org]

--- Additional Comments From pluto at pld-linux dot org  2005-05-05 14:41 
---
(In reply to comment #3) 
> (In reply to comment #2) 
> > in online docs i see that "q" means "byte addressable register (a,b,c,d)".  
> > in i386.h i see something differ for x86_64. did i miss something in docs?  
>  
> Yes see comment #1 which is a quote from the docs. 
 
ohh, i should fix my /dev/brain :)  i'll use the "=Q" format. 
 

-- 


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

[Bug middle-end/21400] ppc-eabisim ICE in expand_builtin_int_roundingfn

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-05 
14:43 ---
Time to update the sources.

This is a dup of bug 21282.

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

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
  Component|c   |middle-end
 Resolution||DUPLICATE


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

[Bug middle-end/21282] [4.1 Regression] Converting floor into lfloor built-in function

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-05 
14:43 ---
*** Bug 21400 has been marked as a duplicate of this bug. ***

-- 
   What|Removed |Added

 CC||amylaar at gcc dot gnu dot
   ||org


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

[Bug rtl-optimization/21254] [4.0/4.1 regression] Incorrect code with -funroll-loops for multiple targets with same code

[rakdver at gcc dot gnu dot org]

-- 
   What|Removed |Added

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


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

[Bug tree-optimization/21399] [4.1 Regression] libstdc++ 12077.cc ICE

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-05 
14:55 ---
Confirmed, reduced testcase:
typedef struct __FILE FILE;
extern "C" int fputs(const char *, FILE *);
struct a { ~a(); };
void f(FILE* file)
{
  a b;
  const char* str = "a";
  fputs(str, file);
}

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-05-05 14:55:48
   date||
Summary|libstdc++ 12077.cc ICE  |[4.1 Regression] libstdc++
   ||12077.cc ICE
   Target Milestone|--- |4.1.0


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

[Bug tree-optimization/21399] [4.1 Regression] libstdc++ 12077.cc ICE

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-05 
15:01 ---
A slightly more reduced testcase:
typedef struct __FILE FILE;
extern "C" int fputs(const char *, FILE *);
void f(FILE* file) throw()
{
  const char* str = "a";
  fputs(str, file);
}

The problem is somehow converting fputs to fputc does not update the exceptions 
regions correctly.


-- 


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

[Bug rtl-optimization/19210] not using do-loop for some loops

[bonzini at gcc dot gnu dot org]

-- 
   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |bonzini at gcc dot gnu dot
   |dot org |org
 Status|SUSPENDED   |ASSIGNED
   Last reconfirmed|2005-01-06 23:09:42 |2005-05-05 15:03:36
   date||


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

[Bug fortran/21401] New: INTERFACE/FUNCTION problem

[klra67 at freenet dot de]

The type of a function interface is not taken over from the 
MODULE PROCEDURE's which constitute the INTERFACE.

---BUG.f90--- start
module interface_vs_functions_bug
  implicit none
  
  private

  interface ex1 ! fails, but should be ok
 module procedure func1, func2
  end interface
  
  interface ex2 ! works by workaround below
 module procedure func1, func2
  end interface
  real :: ex2 
! This workaround should not even be allowed:
! func1 and func2 can differ in return type
! see eg Metcalf and Reid, Fortran 90/95 explained, sec. ed, p94

  interface ex3
 module procedure func1, func3
  end interface
  ! real :: ex3 !! This workaround is not possible here-
  !return types of func1 and func 3 differ...

contains

   real function func1(x)
 real, intent(in) :: x
 func1 = 1.
   end function func1

   real function func2(i)
 integer, intent(in) :: i
 func2 = ex1(real(i))
 ! workaround:func2 = func1(real(i))
   end function func2

   integer function func3(i)
 integer, intent(in) :: i
 func3 = 1
   end function func3
   
 end module Interface_vs_functions_bug
---BUG.f90--- end

Test compile:

gfortran -c BUG.f90
 In file BUG.f90:33

 func2 = ex1(real(i))
   1
Error: Symbol 'ex1' at (1) has no IMPLICIT type
--

gcc -v
Es werden eingebaute Spezifikationen verwendet.
Ziel: i686-pc-linux-gnu
Konfiguriert mit: ../configure
Thread-Modell: posix
gcc-Version 4.0.0

-- 
   Summary: INTERFACE/FUNCTION problem
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: klra67 at freenet dot de
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=21401

[Bug rtl-optimization/21402] New: wrong-code with inlining and type-punned pointer

[gcc at arbruijn dot dds dot nl]

The attached C source gives wrong output when compiled with inlined functions
(-O3 or -O2 -finline-functions) with gcc-4.1-20050501 or gcc-4.0.0. Compiling
gives the following warning twice:
dereferencing type-punned pointer will break strict-aliasing rules

The expected output is 0 0, the actual output is two large values. Without
inlined functions or with the unsigned char pointers changed to char pointers
the problem disappears.

There seem to be two problems. One seems to be using an uninitialised stack
value for the pointer which should be initialized to the empty string. The other
seems to be that a pointer (the p2 pointer in the findlast function in the first
inlined readlen call) is modified in a register and is not written back to the
stack before it is read from the stack (to calculate the return value).

On (RedHat modified) gcc 3.4 the output is 0 -1 (it has only the second problem)
and in the actual application there was no problem with gcc 3.3 and before.

-- 
   Summary: wrong-code with inlining and type-punned pointer
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gcc at arbruijn dot dds dot nl
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=21402

[Bug target/21284] AVR target: switch/case jump table is placed in .data instead of .progmem.gcc_sw_table

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-05-05 
15:36 ---
Subject: Bug 21284

CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED]   2005-05-05 15:36:34

Modified files:
gcc: ChangeLog 
gcc/config/avr : avr.c 

Log message:
PR target/21284
* config/avr/avr.c (avr_output_addr_vec_elt): Use special section
for output.

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.218&r2=2.7592.2.219
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/avr/avr.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.129.6.2&r2=1.129.6.3



-- 


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

[Bug rtl-optimization/21402] wrong-code with inlining and type-punned pointer

[gcc at arbruijn dot dds dot nl]

--- Additional Comments From gcc at arbruijn dot dds dot nl  2005-05-05 
15:38 ---
Created an attachment (id=8825)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8825&action=view)
C source exposing problem


-- 


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

[Bug target/21284] AVR target: switch/case jump table is placed in .data instead of .progmem.gcc_sw_table

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-05-05 
15:42 ---
Subject: Bug 21284

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-05-05 15:42:05

Modified files:
gcc: ChangeLog 
gcc/config/avr : avr.c 

Log message:
PR target/21284
* config/avr/avr.c (avr_output_addr_vec_elt): Use special section
for output.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.8612&r2=2.8613
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/avr/avr.c.diff?cvsroot=gcc&r1=1.134&r2=1.135



-- 


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

[Bug rtl-optimization/21402] wrong-code with inlining and type-punned pointer

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-05 
16:13 ---
"unsigned char *" and "char *" are in two different aliasing sets while char 
and unsigned char are in the 
same one, well char is every aliasing set.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug target/21284] [4.0/4.1 Regression] AVR target: switch/case jump table is placed in .data instead of .progmem.gcc_sw_table

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-05 
16:25 ---
Fixed.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED
Summary|AVR target: switch/case jump|[4.0/4.1 Regression] AVR
   |table is placed in .data|target: switch/case jump
   |instead of  |table is placed in .data
   |.progmem.gcc_sw_table   |instead of
   ||.progmem.gcc_sw_table
   Target Milestone|--- |4.0.1


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

[Bug middle-end/21362] ICE in make_edges, at cfgbuild.c:327

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-05 
16:29 ---
Patch here: .

-- 
   What|Removed |Added

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


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

[Bug middle-end/21362] ICE in make_edges, at cfgbuild.c:327

[aph at gcc dot gnu dot org]

--- Additional Comments From aph at gcc dot gnu dot org  2005-05-05 16:33 
---
This may be a dup of 20606

-- 


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

[Bug fortran/21401] INTERFACE/FUNCTION problem

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-05 
16:40 ---


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

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug fortran/18108] [gfortran] overloading does not work for functions

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-05 
16:40 ---
*** Bug 21401 has been marked as a duplicate of this bug. ***

-- 
   What|Removed |Added

 CC||klra67 at freenet dot de


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

[Bug rtl-optimization/21395] Performance degradation when building code that uses MMX intrinsics with gcc-4.0.0

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

 GCC target triplet|i686-pc-linux-gnu configured|i686-pc-linux-gnu
   |with: ../gcc-4.0.0/configure|
   |--pref  |


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

[Bug libstdc++/19781] testsuite_hooks.cc doesn't test for mkfifo

[bkoz at gcc dot gnu dot org]

--- Additional Comments From bkoz at gcc dot gnu dot org  2005-05-05 16:49 
---

This indeed can be fixed. Instead of 

#if defined (_NEWLIB_VERSION) || defined (__MINGW32_VERSION)
/* Newlib and MinGW32 do not have mkfifo.  */
exit(0);
#else

do something like

#if _GLIBCXX_HAVE_MKFIFO
mkfifo(filename, mode);
#else
exit(0);
#endif

You'd do the check for mkfifo in GLIBCXX_CONFIGURE_TESTSUITE or something like
GLIBCXX_CHECK_SETRLIMIT_ancilliary.


-- 


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

[Bug rtl-optimization/21395] Performance degradation when building code that uses MMX intrinsics with gcc-4.0.0

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-05 
16:53 ---
Note C and C++ aliasing rules are being violated in the source.

-- 


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

[Bug bootstrap/21403] New: Canadian cross build fails.

[green at redhat dot com]

A canadian cross of the compiler failed as it tried to link fix-header.
It's using a mix of build and host object files to build this.  The Makefile 
reads:

# This is nominally a 'build' program, but it's run only when host==build,
# so we can (indeed, must) use $(LIBDEPS) and $(LIBS).

I, however, don't have host==build, and it still tries to do this.

>From what I can tell, there doesn't appear to be proper host==build checks in
place.  Simply setting use_fixproto in config.gcc is enough to try to build
fix-header.

-- 
   Summary: Canadian cross build fails.
   Product: gcc
   Version: 4.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: green at redhat dot com
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i386-mingw32
GCC target triplet: i386-elf


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

[Bug rtl-optimization/21395] Performance degradation when building code that uses MMX intrinsics with gcc-4.0.0

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-05 
17:00 ---
Note with the following code, I get back to what it is without -mmx:
union b
{
  int i[2];
  __m64 j;
}a;
__m64 sum = _mm_set_pi32(0, 0);

for (int j=0 ; j < yl ; j++)
{
short *p = &pic_data[j][0];
short *r = &ref_data[j][0];

for (int i=0 ; i < xl ; i+=4, p +=4, r+=4 )
{   
   __m64 pic = *(__m64 *)p;
   __m64 ref = *(__m64 *)r;
// pic - ref
pic = _mm_sub_pi16 (pic, ref);
// abs (pic - ref)
ref = _mm_srai_pi16(pic, 15);
pic = _mm_xor_si64(pic, ref);
pic = _mm_sub_pi16 (pic, ref);
// sum += abs(pic -ref)
ref = _mm_xor_si64(ref, ref);
ref = _mm_unpackhi_pi16(pic, ref);
pic = _mm_unpacklo_pi16(pic, pic);
pic = _mm_srai_pi32 (pic, 16);
//ref = _mm_srai_pi32 (ref, 16);
pic = _mm_add_pi32 (pic, ref);
sum = _mm_add_pi32 (sum, pic);
}
}
a.j = sum;
   // int *result = (int *) ∑
_mm_empty();

   // return result[0] + result[1];
   return a.i[0] + a.i[1];

-- 


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

[Bug rtl-optimization/21404] New: wrong code for array copy in while loop

[janis at gcc dot gnu dot org]

This test case fails for GCC 3.3.x and GCC 3.4.x at any level of optimization
other than -O0:

extern void abort (void);
char buffer[20];

void foo (char *p, const char *q)
{
  int i = 0;
  while (q[i])
p[i] = q[i++];
}

int
main ()
{
  foo (buffer, "howdy");
  if (buffer[0] != 'h')
abort ();
  return 0;
}

I've tried it on powerpc64-linux and i686-linux and it fails on both.  It
doesn't fail with Red Hat's GCC 3.2.2-5 compiler (I don't have an FSF 3.2
compiler built anywhere), and doesn't fail with GCC 4.0.0 or GCC mainline.

-- 
   Summary: wrong code for array copy in while loop
   Product: gcc
   Version: 3.4.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: rtl-optimization
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


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

[Bug middle-end/20983] [4.0 regression] varargs functions force va_list variable to stack unnecessarily

[jakub at gcc dot gnu dot org]

--- Additional Comments From jakub at gcc dot gnu dot org  2005-05-05 17:11 
---
This could be fixed by expanding __builtin_va_start, __builtin_va_copy
and __builtin_va_end in or soon after pass_stdarg.
Then SRA etc. can also optimize va_list handling.
On the other side, tree-stdarg.c needs to see those builtins, otherwise it
won't be able to figure out anything.  Perhaps we can move that pass a little
bit earlier if needed, but it should certainly happen after at least DCE.

-- 
   What|Removed |Added

 CC||rth at gcc dot gnu dot org


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

[Bug rtl-optimization/21402] wrong-code with inlining and type-punned pointer

[schlie at comcast dot net]

--- Additional Comments From schlie at comcast dot net  2005-05-05 17:19 
---
(In reply to comment #2)
> "unsigned char *" and "char *" are in two different aliasing sets while char
> and unsigned char are in the same one, well char is every aliasing set.

Then I can't help but wonder if it may make sense to reconsider placing
char *, and (un)signed char * in different aliasing sets, as there seems
little if any justifiable reason to generate incorrect code for references to
types which are considered be compatible for assignment. (Just as arguably
it likely makes little sense to generate warnings for the comparison between
pointers to types which differ only in signness for the same reason). As
neither seem particularly useful, and the former is clearly needlessly
potentially dangerious.


-- 


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

[Bug c++/21280] [4.0/4.1 Regression] #pragma interface, templates, and "inline function used but never defined"

[prw at ceiriog1 dot demon dot co dot uk]

--- Additional Comments From prw at ceiriog1 dot demon dot co dot uk  
2005-05-05 17:23 ---
Bug 21306 is not the same bug.  The attached patch FIX1 fixes the
test cases for this bug, but not for 21306 - you will need to look
at the test case for that bug.



-- 


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

[Bug fortran/21203] Segfault while compiling libgfortran/intrinsics/selected_int_kind.f90

[ericw at evcohs dot com]

--- Additional Comments From ericw at evcohs dot com  2005-05-05 17:25 
---
(In reply to comment #2)
> Bootstrapping avr-rtems w/ f95 enabled trips a similar or may-be the same bug
> (also a target which probably doesn't provide REAL 8).

As a side note, it is known that Fortran does not build *at all* for the AVR
target. AFAIK there has not been any work to provide Fortran for the AVR. This
should be treated as a seperate issue.

Thanks
Eric

-- 


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

[Bug c++/20961] [4.0/4.1 Regression] ICE on pragma weak/__attribute__((weak))

[jakub at gcc dot gnu dot org]

-- 
   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jakub at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2005-04-12 08:43:31 |2005-05-05 17:43:49
   date||


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

[Bug rtl-optimization/21404] wrong code for array copy in while loop

[janis at gcc dot gnu dot org]

--- Additional Comments From janis at gcc dot gnu dot org  2005-05-05 17:49 
---
A workaround is to replace the body of the loop with:

{
  p[i] = q[i];
  i++;
}

-- 


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

[Bug tree-optimization/21380] [4.0 Regression] ICE compiling with -O

[law at redhat dot com]

--- Additional Comments From law at redhat dot com  2005-05-05 18:01 ---
I know what's causing this and I'm testing a fix now.

-- 


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

[Bug target/19636] Can't compile ethernut OS (avr-gcc)

[ericw at evcohs dot com]

--- Additional Comments From ericw at evcohs dot com  2005-05-05 18:09 
---
Will someone with the requisite permissions please set this bug to NEW? This has
been confirmed.

Thanks
Eric

-- 


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

[Bug rtl-optimization/21404] wrong code for array copy in while loop

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-05 
18:12 ---
This is invalid, there is no sequence point between the access of i and the 
increment of i so either can 
be first.

With -W -Wall we get a warning:
t.c:8: warning: operation on `i' may be undefined


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

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug c/11751] wrong evaluation order of an expression

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-05 
18:12 ---
*** Bug 21404 has been marked as a duplicate of this bug. ***

-- 
   What|Removed |Added

 CC||janis at gcc dot gnu dot org


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

Re: [Bug rtl-optimization/21402] wrong-code with inlining and type-punned pointer

[Andrew Pinski]

On May 5, 2005, at 1:19 PM, schlie at comcast dot net wrote:
--- Additional Comments From schlie at comcast dot net  2005-05-05 
17:19 ---
(In reply to comment #2)
"unsigned char *" and "char *" are in two different aliasing sets 
while char
and unsigned char are in the same one, well char is every aliasing 
set.
Then I can't help but wonder if it may make sense to reconsider placing
char *, and (un)signed char * in different aliasing sets, as there 
seems
little if any justifiable reason to generate incorrect code for 
references to
types which are considered be compatible for assignment. (Just as 
arguably
it likely makes little sense to generate warnings for the comparison 
between
pointers to types which differ only in signness for the same reason). 
As
neither seem particularly useful, and the former is clearly needlessly
potentially dangerious.
Because this is what the standard says is allowed.  The standard also
says the comparisons and assignment between pointers without a case is
invalid code and should be diagnostic.  Again this is what the standard
says for these things and GCC follows the C standard.
-- Pinski

[Bug rtl-optimization/21402] wrong-code with inlining and type-punned pointer

[pinskia at physics dot uc dot edu]

--- Additional Comments From pinskia at physics dot uc dot edu  2005-05-05 
18:41 ---
Subject: Re:  wrong-code with inlining and type-punned pointer


On May 5, 2005, at 1:19 PM, schlie at comcast dot net wrote:

>
> --- Additional Comments From schlie at comcast dot net  2005-05-05 
> 17:19 ---
> (In reply to comment #2)
>> "unsigned char *" and "char *" are in two different aliasing sets 
>> while char
>> and unsigned char are in the same one, well char is every aliasing 
>> set.
>
> Then I can't help but wonder if it may make sense to reconsider placing
> char *, and (un)signed char * in different aliasing sets, as there 
> seems
> little if any justifiable reason to generate incorrect code for 
> references to
> types which are considered be compatible for assignment. (Just as 
> arguably
> it likely makes little sense to generate warnings for the comparison 
> between
> pointers to types which differ only in signness for the same reason). 
> As
> neither seem particularly useful, and the former is clearly needlessly
> potentially dangerious.

Because this is what the standard says is allowed.  The standard also
says the comparisons and assignment between pointers without a case is
invalid code and should be diagnostic.  Again this is what the standard
says for these things and GCC follows the C standard.

-- Pinski



-- 


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

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

[tsv at solvo dot ru]

--- Additional Comments From tsv at solvo dot ru  2005-05-05 19:07 ---
gcc version 4.0.0 20050423 (Red Hat 4.0.0-2)

Here is another test case that generates unaligned access exception:


typedef union
{
   short i16;
   unsigned short u16;
   int i32;
   unsigned int u32;

   long i64;
   unsigned long u64;

   double dbl;
   unsigned char byt;
   char *str;
} DBusBasicValue;

void foo(void *p)
{
   DBusBasicValue *a;

   a = p;

   a->byt = 'a';
}

int main()
{
# include 
# include 
   unsigned int buf[2] =
 {
SSIN_UACPROC, UAC_SIGBUS | UAC_NOPRINT
 };

   char buff[100];

   syscall(__NR_osf_setsysinfo, SSI_NVPAIRS, buf, 1, 0, 0, 0);

   foo(&buff[1]);
}


-- 
   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |


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

[Bug c++/21352] [3.4/4.0/4.1 Regression] ICE on valid code with passing template function type as template type

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-05-05 
19:08 ---
Subject: Bug 21352

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-05-05 19:08:14

Modified files:
gcc/cp : ChangeLog pt.c 
gcc/testsuite  : ChangeLog 
Added files:
gcc/testsuite/g++.dg/template: crash37.C 

Log message:
PR c++/21352
* pt.c (build_non_dependent_expr): Use is_overloaded_fn.

PR c++/21352
* g++.dg/template/crash37.C: New test.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&r1=1.4731&r2=1.4732
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/pt.c.diff?cvsroot=gcc&r1=1.995&r2=1.996
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.5441&r2=1.5442
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/template/crash37.C.diff?cvsroot=gcc&r1=NONE&r2=1.1



-- 


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

[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-05-05 
19:10 ---
(In reply to comment #17)
> gcc version 4.0.0 20050423 (Red Hat 4.0.0-2)
> 
> Here is another test case that generates unaligned access exception:

That code is invalid due to the alignment requirements in standard C.

The orginal testcase has been fixed.

-- 
   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||FIXED


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

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

[tsv at solvo dot ru]

--- Additional Comments From tsv at solvo dot ru  2005-05-05 19:16 ---
I just extracted it from "dbus" package which I am testing on linux/alpha
platform. There are other packages (mozilla one of them) that started to
generate unaligned access exceptions then built by gcc 4.0.

Should not be some warning to be generated?

Thank you.


-- 


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

[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-05-05 
19:22 ---
(In reply to comment #19)
> Should not be some warning to be generated?

There is a warning if going directly from char * to the union pointer but since 
you go through a void 
pointer, the warning is gone.

-- 


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

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

[tsv at solvo dot ru]

--- Additional Comments From tsv at solvo dot ru  2005-05-05 20:03 ---
(In reply to comment #20)
> (In reply to comment #19)
> > Should not be some warning to be generated?
> 
> There is a warning if going directly from char * to the union pointer but
since you go through a void 
> pointer, the warning is gone.

Yes, it does. DEC C generates exactly the same code for "foo" function. So, I am
sorry for my wrong testcase.

I am trying to find out where unaligned pointer is came from. Going couple
functions back I found that it is the address if "unsigned char" variable
allocated on stack. Should I look at this issue or it might be possible in
theory and I should report about improper coding practice to the author of the 
code?

Thank you for your attention

-- 


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

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

[Andrew Pinski]

On May 5, 2005, at 4:03 PM, tsv at solvo dot ru wrote:
I am trying to find out where unaligned pointer is came from. Going 
couple
functions back I found that it is the address if "unsigned char" 
variable
allocated on stack. Should I look at this issue or it might be 
possible in
theory and I should report about improper coding practice to the 
author of the code?
Characters have alignment of 1.  I would report it back to the author 
of the code.

-- Pinski

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

[pinskia at physics dot uc dot edu]

--- Additional Comments From pinskia at physics dot uc dot edu  2005-05-05 
20:06 ---
Subject: Re:  [4.0/4.1 regression] ivopts produces code that generates 
"unaligned access exception"


On May 5, 2005, at 4:03 PM, tsv at solvo dot ru wrote:

> I am trying to find out where unaligned pointer is came from. Going 
> couple
> functions back I found that it is the address if "unsigned char" 
> variable
> allocated on stack. Should I look at this issue or it might be 
> possible in
> theory and I should report about improper coding practice to the 
> author of the code?

Characters have alignment of 1.  I would report it back to the author 
of the code.


-- Pinski



-- 


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

[Bug fortran/21394] Internal compiler error, possibly due to large parameter array

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-05 
20:12 ---


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

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug fortran/20925] "Possible frontend bug: array constructor not expanded"

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-05 
20:12 ---
*** Bug 21394 has been marked as a duplicate of this bug. ***

-- 
   What|Removed |Added

 CC||gnalle at ruc dot dk


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

[Bug rtl-optimization/16613] [3.4/4.0 Regression] compile time regression, when adding cerr usage

[andre dot maute at gmx dot de]

--- Additional Comments From andre dot maute at gmx dot de  2005-05-05 
20:12 ---
i want to supplement my compile time tests which shows that a regression  
was introduced between 2005/03/26 an 2005/04/02  
  
> g++-4.0-20050402 -v  
Using built-in specs.  
Target: i686-pc-linux-gnu  
Configured with: ../gcc-4.0-20050402/configure --prefix=/opt/gcc-4.0-20050402  
--program-suffix=-4.0-20050402 --enable-shared --enable-languages=c,c++  
--enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu  
--disable-nls --disable-checking --with-arch=pentium3  
Thread model: posix  
gcc version 4.0.0 20050402 (prerelease)  
  
> time g++-4.0-20050402 -c -O3 -D __NDEBUG__ compiletimetest2.cc  
real0m52.126suser0m51.187ssys 0m0.777s  
  
> time g++-4.0-20050402 -c -O3 -D __DEBUG__ compiletimetest2.cc  
real0m55.409suser0m54.280ssys 0m0.935s  
  
> g++-4.0-20050402 -c -O3 -D __NDEBUG__ compiletimetest2.cc -save-temps  
> ls -al compiletimetest2.s  
-rw-r--r--1 login500  users 1186149 May  5 22:05 compiletimetest2.s  
  
Regards Andre  

-- 


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

[Bug c++/21405] New: Template inlines have global visibility

[mike at navi dot cx]

See http://gcc.gnu.org/ml/libstdc++/2005-04/msg00173.html

If you have code like:

std::string b = "bee";
std::string c = "see";

std::string a = b + c;

Then the string + operator overload will appear in the final ELF image with
GLOBAL WEAK visibility, meaning it can be bound to the wrong version of the
symbol at runtime (ie symbol versioning is ignored).

This is serious as it means you can't mix libraries that use different C++ ABIs
into the same image even if they only interact via C ABIs, something that the
GCC docs explicitly say will work!

-- 
   Summary: Template inlines have global visibility
   Product: gcc
   Version: 3.4.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mike at navi dot cx
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug c++/21405] Template inlines have global visibility

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-05 
22:27 ---
I don't know if this is really a vaild bug, as the standard requires the inline 
function as the same so it 
would be undefined if they are different.

-- 


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

[Bug target/14839] configure does not check for the presence of 32bits libc with --disable-multilib

[gary at intrepid dot com]

--- Additional Comments From gary at intrepid dot com  2005-05-05 22:32 
---
I ran into this recently, and also would like to see configure auto-detect the 
lack of 32 bit libs.

That failing, perhaps the install documentation at
http://gcc.gnu.org/install/specific.html#x86-64-x-x
can be updated - warning installers about the need for --disable-multilibs
when there's no lib32 support (I went looking there first).



-- 


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

[Bug c++/21405] Template inlines have global visibility

[mike at navi dot cx]

--- Additional Comments From mike at navi dot cx  2005-05-05 22:39 ---
I don't understand what you mean. There's definitely a bug here because a
configuration that the docs say should work, causes mysterious crashes due to
mis-binds of symbols. I suspect building with -fvisibility-inlines-hidden can
resolve this problem but why is it not the default?

-- 


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

[Bug c++/21405] Template inlines have global visibility

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-05 
22:40 ---
So here is the story really global templates have aways global visibility in 
C++ so this is not a bug in 
GCC or binutils.  This is a bug in how you think that you can use two different 
versions. 

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug rtl-optimization/21254] [4.0/4.1 regression] Incorrect code with -funroll-loops for multiple targets with same code

[rakdver at gcc dot gnu dot org]

--- Additional Comments From rakdver at gcc dot gnu dot org  2005-05-05 
22:50 ---
http://gcc.gnu.org/ml/gcc-patches/2005-05/msg00448.html

-- 
   What|Removed |Added

   Keywords||patch


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

[Bug fortran/21406] New: gfortran barfs on READ line

[haley at ucar dot edu]

I'm trying to use gfortran version "GNU Fortran 95 (GCC 4.0.0)" on
an Opteron system:

 Linux nika 2.6.11.7 #1 SMP Wed Apr 13 13:55:17 AKDT 2005 x86_64 GNU/Linux

I'm building NCAR Graphics, which is a large Fortran 77 and C based software
package.  This software builds under various versions of g77/gcc.

I'm having multiple problems with gfortran, but I'll address the easiest one
to report:

nika:~/ncarg/ncarg2d/src/libncarg_gks/awi> gfortran -c g.f
g.f: In function 'gesc':
g.f:1: 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.
nika:~/ncarg/ncarg2d/src/libncarg_gks/awi> 



Here's the 8-line file:

  SUBROUTINE GESC(LIDR,IDR)
  INTEGER LIDR, IWKID
  CHARACTER*(*) IDR(LIDR)

  READ (IDR,501) IWKID
 501  FORMAT(I5)
  RETURN
  END

--Mary

-- 
   Summary: gfortran barfs on READ line
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: haley at ucar dot edu
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug fortran/18781] [ICE] WRITE with FMT from CHARACTER array

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-05 
23:26 ---


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

-- 
   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE


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

[Bug fortran/15966] ICE and segmentation fault on internal write

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-05 
23:26 ---
*** Bug 18781 has been marked as a duplicate of this bug. ***

-- 
   What|Removed |Added

 CC||coudert at clipper dot ens
   ||dot fr


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

[Bug fortran/21406] gfortran barfs on READ line

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-05 
23:26 ---


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

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug fortran/19276] [meta-bug] CHARACTER related bugs in gfortran

[pinskia at gcc dot gnu dot org]

-- 
Bug 19276 depends on bug 18781, which changed state.

Bug 18781 Summary: [ICE] WRITE with FMT from CHARACTER array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18781

   What|Old Value   |New Value

 Status|NEW |RESOLVED
 Resolution||DUPLICATE

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

[Bug fortran/18834] ICE on reading from internal file character array

[pinskia at gcc dot gnu dot org]

-- 
Bug 18834 depends on bug 18781, which changed state.

Bug 18781 Summary: [ICE] WRITE with FMT from CHARACTER array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18781

   What|Old Value   |New Value

 Status|NEW |RESOLVED
 Resolution||DUPLICATE

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

[Bug fortran/15966] ICE and segmentation fault on internal write

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-05 
23:26 ---
*** Bug 21406 has been marked as a duplicate of this bug. ***

-- 
   What|Removed |Added

 CC||haley at ucar dot edu


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

[Bug fortran/15966] ICE and segmentation fault on internal write

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-05 
23:26 ---
*** Bug 21406 has been marked as a duplicate of this bug. ***

-- 
   What|Removed |Added

 CC||haley at ucar dot edu


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

[Bug fortran/19292] [meta-bug] g77 features lacking in gfortran

[pinskia at gcc dot gnu dot org]

-- 
Bug 19292 depends on bug 18781, which changed state.

Bug 18781 Summary: [ICE] WRITE with FMT from CHARACTER array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18781

   What|Old Value   |New Value

 Status|NEW |RESOLVED
 Resolution||DUPLICATE

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

[Bug c++/21352] [3.4/4.0/4.1 Regression] ICE on valid code with passing template function type as template type

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-05-05 
23:30 ---
Subject: Bug 21352

CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED]   2005-05-05 23:30:27

Modified files:
gcc/cp : ChangeLog pt.c 
gcc/testsuite  : ChangeLog 
Added files:
gcc/testsuite/g++.dg/template: crash37.C 

Log message:
PR c++/21352
* pt.c (build_non_dependent_expr): Use is_overloaded_fn.

PR c++/21352
* g++.dg/template/crash37.C: New test.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.4648.2.37&r2=1.4648.2.38
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/pt.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.978.2.7&r2=1.978.2.8
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.5084.2.160&r2=1.5084.2.161
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/template/crash37.C.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.1.2.1



-- 


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

[Bug c++/21352] [3.4 Regression] ICE with passing template function type as template type

[mmitchel at gcc dot gnu dot org]

--- Additional Comments From mmitchel at gcc dot gnu dot org  2005-05-05 
23:35 ---
This code is not valid (it tries to use a non-static member function, without
taking its address to form a pointer-to-member).

The ICE has been fixed in 4.0.1 and 4.1.  This bug will not be fixed in 3.4.x.

-- 
   What|Removed |Added

 Status|NEW |RESOLVED
   Keywords|ice-on-valid-code   |ice-on-invalid-code
 Resolution||FIXED
Summary|[3.4/4.0/4.1 Regression] ICE|[3.4 Regression] ICE with
   |on valid code with passing  |passing template function
   |template function type as   |type as template type
   |template type   |
   Target Milestone|3.4.4   |4.0.1


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

[Bug target/21195] SSE intrinsics not inlined, sometimes.

[tbptbp at gmail dot com]

--- Additional Comments From tbptbp at gmail dot com  2005-05-05 23:58 
---
For future reference, i'm including my end-user offline answer to Uros regarding
always_inline usage.

Here we go:
> I was trying to take a quick look at your bugreport regarding
> always_inline attrubite. Just a quick remark - using only a plain static
> inline bool  fixes the problem for me and at -O3 code looks like it
Doesn't surprise me.

> should. Is there a specific reason to have an attribute always_inline
> declared for the function you would like to inline? (Please note, that
> Jan Hubicka is currently working in this area.)
Yes, because inline alone in practice is next to useless. You say
below that reg<->mem movements are expensive, but my prime concern in
a hot path is branches.
And if you expect code to be inlined (or more precisely, you expect no
function call) then you have no alternative but to use always_inline.
Tho once you start using always_inline you upset the compiler and you
step in a world of pain where you have to babysit it for dependant
code with combo of always_inline/noinline.

In fact, always_inline/noinline combo are the only kludge for a number
of other problems:
. when gcc gets nuts, they are useful containement measures (so the
sillyness doesn't propagate)
. as said earlier inline being an (ignored) hint, if you have, say a
member function doing just one op (like those intrinsics in the
testcase), it makes absolutely no sense to not inline them. Ever. Yet
some times it happens.
. gcc doesn't like long sequences of branchless vectorized code, which
are quite common, and a static always_inline function is a way to tell
it to look somewhere else.
. those same static always_inline functions also are a way to tell it
to look closer at some code portion and to try to map its working set
into registers; it also has to do with the lack of an unroll pragma
and generally the lack of any directive to tell the compiler to pay
special attention to specific code.

So in the hotpath my code typically ends up being a bunch of
always_inline functions coalesced into a noinline.
For the non speed critical path, i let it up to the compiler. In that
regard, gcc4.x (and specifically gcc4.1) got a lot wiser, perhaps as
good as icc, but obviously not failproof :)



-- 


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

[Bug c++/21405] Template inlines have global visibility

[mike at navi dot cx]

--- Additional Comments From mike at navi dot cx  2005-05-06 00:17 ---
No, there is very definitely a bug here even if it's just in the documentation.

The GCC docs say in very clear and unambiguous terms that this will work, by
design. Not by accident, by design. That's the whole point of applying symbol
versions to the standard C++ library.

It only affects methods that have been inlined into the headers. Methods that
are defined as external work correctly. So either:

a) No methods should be inlined

or

b) GCC should not emit them as GLOBAL WEAK so they can be overridden by other
definitions elsewhere in the image

The latter is what the new -fvisibility-inlines-hidden switch does. So why is it
not on by default?

-- 


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

[Bug tree-optimization/21407] New: [4.1 Regression] wrong code with upcast in C++

[pinskia at gcc dot gnu dot org]

The is huge bug which effects a large amount of C++, we should not abort.
extern "C" void abort(void);
struct T1 {int a, b; virtual void f(){}};
struct T : T1 { struct T1 w;  int b; };
void foo (struct T1 *p) { struct T *q = dynamic_cast(p); if (q->b != 2) 
abort (); }
int main () { struct T c; c.b = 2; foo (&c); return 0; }

-- 
   Summary: [4.1 Regression] wrong code with upcast in C++
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: critical
  Priority: P2
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
CC: dberlin at gcc dot gnu dot org,gcc-bugs at gcc dot gnu
dot org


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

[Bug tree-optimization/21407] [4.1 Regression] wrong code with upcast in C++

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Target Milestone|--- |4.1.0
Version|4.0.0   |4.1.0


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

[Bug tree-optimization/21407] [4.1 Regression] wrong code with upcast in C++

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-06 
00:25 ---
Oh, I got the idea for this testcase after ssb asked about what the kernel was 
doing was valid and his 
example code but unlike that code, this is valid as C++ works slightly 
different than C.

-- 


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

[Bug tree-optimization/21407] [4.1 Regression] wrong code with upcast in C++

[belyshev at depni dot sinp dot msu dot ru]

--- Additional Comments From belyshev at depni dot sinp dot msu dot ru  
2005-05-06 00:27 ---
Confirmed.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-05-06 00:27:48
   date||


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

[Bug c/21408] New: DAZ related macros are improperly guarded in pmmintrin.h

[tbptbp at gmail dot com]

In GCC's version of pmmintrin.h we have:
#ifdef __SSE3__
#include 
#include 

/* Additional bits in the MXCSR.  */
#define _MM_DENORMALS_ZERO_MASK 0x0040
#define _MM_DENORMALS_ZERO_ON   0x0040
#define _MM_DENORMALS_ZERO_OFF  0x

#define _MM_SET_DENORMALS_ZERO_MODE(mode) \
  _mm_setcsr ((_mm_getcsr () & ~_MM_DENORMALS_ZERO_MASK) | (mode))
#define _MM_GET_DENORMALS_ZERO_MODE() \
  (_mm_getcsr() & _MM_DENORMALS_ZERO_MASK)

... and then SSE3 intrinsics.

But those addtionnal MXCSR bits can be found, for example, on a k8 with only 
SSE2.
Side note: they aren't guarded this way either in Intel headers.

-- 
   Summary: DAZ related macros are improperly guarded in pmmintrin.h
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tbptbp at gmail dot com
CC: gcc-bugs at gcc dot gnu dot org
  GCC host triplet: x86*


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

[Bug target/21408] DAZ related macros are improperly guarded in pmmintrin.h

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

  Component|c   |target
   Keywords||ssemmx


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

[Bug fortran/21409] New: Attached fortran 95 code generates error

[joe at confucius dot gnacademy dot org]

[EMAIL PROTECTED] hcol]$ gfortran -c difq3.F -o difq3.o
 In file difq3.F:693

 ams(1:ngmax)=
   1
Error: The FORALL with index 'j' cause more than one assignment to this object
at (1)
 In file difq3.F:696

 p2m(1:ngmax)=0.5d0*(3.0d0*ams(1:ngmax)-1d0)
   1
Error: The FORALL with index 'j' cause more than one assignment to this object
at (1)
 In file difq3.F:697

 fi(1:ngmax)=yb(j,1:ngmax,nutype)*enu(1:ngmax)
  1
Error: The FORALL with index 'j' cause more than one assignment to this object
at (1)
[EMAIL PROTECTED] hcol]$ make
../bin/prefort n comdecks abcd0.srs
 input files from 2 to 3: comdecks   abcd0.srs
  open file=abcd0.f

-- 
   Summary: Attached fortran 95 code generates error
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: joe at confucius dot gnacademy dot org
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=21409

[Bug fortran/21409] Attached fortran 95 code generates error

[joe at confucius dot gnacademy dot org]

--- Additional Comments From joe at confucius dot gnacademy dot org  
2005-05-06 00:59 ---
Created an attachment (id=8826)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8826&action=view)
Sample fortran file which generates error


-- 


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

[Bug fortran/21409] Attached fortran 95 code generates error

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-06 
01:24 ---
Reduced testcase (I tried not to reduce it too much):
  subroutine  difq3 (jmax, ngmax, ams)
  implicit none
  integer*4 :: jmax, ngmax
  real*8, dimension(32) ::  ams
  real*8, dimension(32) ::  edd
  integer*4 :: j
  forall (j=2:jmax)
 ams(1:ngmax)= edd(j-1)
  end forall
  end


But note I get a warning with ICC:
fortcom: Warning: t.f, line 8: All active combinations of index-names are not 
used within the variable 
being defined (i.e., leftside) of this assignment-stmt.   [AMS]
 ams(1:ngmax)= edd(j-1)
.^

So I don't know if this code is valid or not.

-- 


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