[Bug tree-optimization/33953] [4.3 regression] internal compiler error: vector VEC(tree,base) index domain error, in vectorizable_operation at tree-vect-transform.c:4017

[irar at gcc dot gnu dot org]

--- Comment #9 from irar at gcc dot gnu dot org  2007-11-12 09:32 ---
Subject: Bug 33953

Author: irar
Date: Mon Nov 12 09:32:13 2007
New Revision: 130096

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130096
Log:
PR tree-optimization/33953
* tree-vect-transform.c (vectorizable_operation): In case of SLP,
allocate vec_oprnds1 according to the number of created vector
statements. In case of shift with scalar argument, store scalar operand
for every vector statement to be created for the SLP node. Fix a
comment.


Added:
trunk/gcc/testsuite/gcc.dg/vect/pr33953.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vect-transform.c


-- 


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

[Bug fortran/34067] gfortran.dg/char_cshift_2.f90 fails with -O3 -funroll-loops fails on Intel Darwin

[dominiq at lps dot ens dot fr]

--- Comment #2 from dominiq at lps dot ens dot fr  2007-11-12 10:22 ---
Looking at the test results, the failures seem to happen only on a Core2Duo
Darwin8 (may be only my build). They require both -O(2-3) and
-funroll(-all)-loops. I have also compared the results of -fdump-tree-optimized
with -O2 -funroll-loops and with

-O1 -funroll-loops -ftree-pre -ftree-vrp -fschedule-insns -fschedule-insns2
-fstrict-aliasing -fgcse --param max-aliased-vops=500 -fgcse-lm -falign-loops
-falign-jumps -falign-functions -fregmove -freorder-blocks -freorder-functions
-frerun-cse-after-loop -fsched-interblock -fsched-spec -fthread-jumps
-fcse-follow-jumps -fcse-skip-blocks -foptimize-sibling-calls -fpeephole2
-fexpensive-optimizations -fdelete-null-pointer-checks -fstrict-overflow
-fcrossjumping -fcaller-saves -falign-labels

(according the manual the later (no abort) should be equivalent to the former
(abort), but is not) and there is no difference. However the assembly codes are
quite differents.


-- 


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

[Bug c/34070] New: Wrong code for (int)x%4

[simonmar at microsoft dot com]

The following code generates the wrong result:


#include 

int f(unsigned int x)
{
printf("%x %d\n", x, (int)x);
return ((int)x) % 4;
}

int main(int argc, char *argv[])
{
printf("%d\n", f((unsigned int)(-1)));
return 0;
}


I expect this:

$ gcc-3.4.3 ctest33.c -Wall  && ./a.out
 -1
-1

and with gcc-4 and greater I get this:

$ gcc-4.2.1 ctest33.c -Wall  && ./a.out
 -1
3

Why do I think this is a bug?  Well, initially I thought I'd run into undefined
behaviour, but on closer reading of the C spec it seems the behaviour should be
implementation-defined, and gcc is not implementing the documented behaviour. 
Furthermore, gcc's behaviour is not consistent, as implementation-defined
behaviour should be.

The bug appears to be centered around conversion from unsigned to signed
integers.  We convert from unsigned to signed in f(), and the value passed is
0x.  The result is therefore implementation-defined (C99 6.3.1.3), and
gcc defines it (section 4.5 of the gcc docs) as: "For conversion to a type of
width N, the value is reduced modulo 2^N to be within range of the type".  I
presume this means that the value is truncated to N bits and the result
interpreted as twos-complement, which in this case should mean that (int)x is
-1, and the expression is (-1 % 4), which has value -1.

We can see from the printf output that (int)x has value -1.  Since this is its
implementation-defined value, it should have the same value in the expression
(int)x % 4.

Indeed, several minor variations of this code give the expected output. 
Substituting 0xU for x in the definition of f(), for example.

Optimisation level has no effect.  Bug also observed on i686-unknown-linux.


-- 
   Summary: Wrong code for (int)x%4
   Product: gcc
   Version: 4.2.1
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: simonmar at microsoft dot com
 GCC build triplet: x86_64-unknown-linux-gnu
  GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu


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

[Bug fortran/34067] gfortran.dg/char_cshift_2.f90 fails with -O3 -funroll-loops fails on Intel Darwin

[fxcoudert at gcc dot gnu dot org]

--- Comment #3 from fxcoudert at gcc dot gnu dot org  2007-11-12 10:27 
---
(In reply to comment #2)
> according the manual the later (no abort) should be equivalent to the former
> (abort), but is not

The manual only says "-On turns on the following optimization flags", but it
does a few other things that are not controlled by individual -f flags.


-- 


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

[Bug fortran/22244] dimension information is lost for multi-dimension array

[jakub at gcc dot gnu dot org]

--- Comment #11 from jakub at gcc dot gnu dot org  2007-11-12 10:50 ---
Attempt to deal with assumed shape, allocated etc. arrays:
http://gcc.gnu.org/ml/gcc-patches/2007-11/msg00612.html
Does not yet implement the DW_AT_associated and DW_AT_allocated attributes.
For those, guess for ALLOCATABLE, but non-POINTER, DW_AT_allocated could be
just
a test whether varx.data != NULL.  For POINTER I have no idea yet.
Any help would be appreciated.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jakub at gcc dot gnu dot org
   |dot org |
URL||http://gcc.gnu.org/ml/gcc-
   ||patches/2007-
   ||11/msg00612.html
 Status|NEW |ASSIGNED
   Last reconfirmed|2005-12-30 19:36:08 |2007-11-12 10:50:45
   date||


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

[Bug tree-optimization/33953] [4.3 regression] internal compiler error: vector VEC(tree,base) index domain error, in vectorizable_operation at tree-vect-transform.c:4017

[jakub at gcc dot gnu dot org]

--- Comment #10 from jakub at gcc dot gnu dot org  2007-11-12 11:15 ---
Fixed.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug bootstrap/34045] gcc does not build on Debian etch AMD64

[laurent dot bonnaud at inpg dot fr]

--- Comment #5 from laurent dot bonnaud at inpg dot fr  2007-11-12 11:28 
---
The --disable-multilib options allowed me to build gcc.  Thank you for the tip!

However, it was my understanding that if "./configure" does not fail, "make
bootstrap" should not fail.


-- 


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

[Bug c/34071] New: Poor behaviour of complex division in 64-bit on Intel

[nmm1 at cam dot ac dot uk]

-m64 changes the default from -mfp-math=387 to something else.  That is clearly
a good idea, but has an unexpected downside for complex division, in that the
boundary case handling degrades badly.  This was detected for C under 4.1.2 but
is almost certainly more general.

It is worth considering whether complex division should be a special case, and
use Intel arithmetic when it is available, irrespective of the arithmetic used
for most floating-point calculations.  Sigh - another hack :-(

Take the following example:

#include 
#include 
complex f(double complex a, double complex b) { return a/b;}

int main()
{   double complex X = 1.0e308;
int n;
for (n = 0; n<20; n++)
{   double complex a = X + X*I, b = X + (n/10.0)*X*I;
double complex r = f(a,b);
printf("(%.3e,%.3e)/(%.3e,%.3e) => (%.3e,%.3e)\n",a,b,r);
}
return 0;
}

This produces the following output with -m32 or -mfpmath=387:

(1.000e+308,1.000e+308)/(1.000e+308,0.000e+00) => (1.000e+00,1.000e+00)
(1.000e+308,1.000e+308)/(1.000e+308,1.000e+307) => (1.089e+00,8.911e-01)
(1.000e+308,1.000e+308)/(1.000e+308,2.000e+307) => (1.154e+00,7.692e-01)
(1.000e+308,1.000e+308)/(1.000e+308,3.000e+307) => (1.193e+00,6.422e-01)
(1.000e+308,1.000e+308)/(1.000e+308,4.000e+307) => (1.207e+00,5.172e-01)
(1.000e+308,1.000e+308)/(1.000e+308,5.000e+307) => (1.200e+00,4.000e-01)
(1.000e+308,1.000e+308)/(1.000e+308,6.000e+307) => (1.176e+00,2.941e-01)
(1.000e+308,1.000e+308)/(1.000e+308,7.000e+307) => (1.141e+00,2.013e-01)
(1.000e+308,1.000e+308)/(1.000e+308,8.000e+307) => (1.098e+00,1.220e-01)
(1.000e+308,1.000e+308)/(1.000e+308,9.000e+307) => (1.050e+00,5.525e-02)
(1.000e+308,1.000e+308)/(1.000e+308,1.000e+308) => (1.000e+00,0.000e+00)
(1.000e+308,1.000e+308)/(1.000e+308,1.100e+308) => (9.502e-01,-4.525e-02)
(1.000e+308,1.000e+308)/(1.000e+308,1.200e+308) => (9.016e-01,-8.197e-02)
(1.000e+308,1.000e+308)/(1.000e+308,1.300e+308) => (8.550e-01,-1.115e-01)
(1.000e+308,1.000e+308)/(1.000e+308,1.400e+308) => (8.108e-01,-1.351e-01)
(1.000e+308,1.000e+308)/(1.000e+308,1.500e+308) => (7.692e-01,-1.538e-01)
(1.000e+308,1.000e+308)/(1.000e+308,1.600e+308) => (7.303e-01,-1.685e-01)
(1.000e+308,1.000e+308)/(1.000e+308,1.700e+308) => (6.941e-01,-1.799e-01)
(1.000e+308,1.000e+308)/(1.000e+308,inf) => (0.000e+00,-0.000e+00)
(1.000e+308,1.000e+308)/(1.000e+308,inf) => (0.000e+00,-0.000e+00)

[ Actually, with -mfpmath=387, the last two lines are:
  (1.000e+308,1.000e+308)/(nan,inf) => (nan,nan)
  (1.000e+308,1.000e+308)/(nan,inf) => (nan,nan) ]

This produces the following output with -m64 or -mfpmath=sse:

(1.000e+308,1.000e+308)/(1.000e+308,0.000e+00) => (1.000e+00,1.000e+00)
(1.000e+308,1.000e+308)/(1.000e+308,1.000e+307) => (1.089e+00,8.911e-01)
(1.000e+308,1.000e+308)/(1.000e+308,2.000e+307) => (1.154e+00,7.692e-01)
(1.000e+308,1.000e+308)/(1.000e+308,3.000e+307) => (1.193e+00,6.422e-01)
(1.000e+308,1.000e+308)/(1.000e+308,4.000e+307) => (1.207e+00,5.172e-01)
(1.000e+308,1.000e+308)/(1.000e+308,5.000e+307) => (1.200e+00,4.000e-01)
(1.000e+308,1.000e+308)/(1.000e+308,6.000e+307) => (1.176e+00,2.941e-01)
(1.000e+308,1.000e+308)/(1.000e+308,7.000e+307) => (1.141e+00,2.013e-01)
(1.000e+308,1.000e+308)/(1.000e+308,8.000e+307) => (inf,1.220e-01)
(1.000e+308,1.000e+308)/(1.000e+308,9.000e+307) => (nan,0.000e+00)
(1.000e+308,1.000e+308)/(1.000e+308,1.000e+308) => (nan,0.000e+00)
(1.000e+308,1.000e+308)/(1.000e+308,1.100e+308) => (nan,-0.000e+00)
(1.000e+308,1.000e+308)/(1.000e+308,1.200e+308) => (nan,-0.000e+00)
(1.000e+308,1.000e+308)/(1.000e+308,1.300e+308) => (0.000e+00,-0.000e+00)
(1.000e+308,1.000e+308)/(1.000e+308,1.400e+308) => (0.000e+00,-0.000e+00)
(1.000e+308,1.000e+308)/(1.000e+308,1.500e+308) => (0.000e+00,-0.000e+00)
(1.000e+308,1.000e+308)/(1.000e+308,1.600e+308) => (0.000e+00,-0.000e+00)
(1.000e+308,1.000e+308)/(1.000e+308,1.700e+308) => (0.000e+00,-0.000e+00)
(1.000e+308,1.000e+308)/(nan,inf) => (nan,nan)
(1.000e+308,1.000e+308)/(nan,inf) => (nan,nan)

Note the particularly horrible case, where a value that should be small
is actually infinite!


-- 
   Summary: Poor behaviour of complex division in 64-bit on Intel
   Product: gcc
   Version: 4.1.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: nmm1 at cam dot ac dot uk


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

[Bug tree-optimization/33870] [4.3 Regression] miscompiles sqlite

[rguenth at gcc dot gnu dot org]

--- Comment #22 from rguenth at gcc dot gnu dot org  2007-11-12 12:04 
---
Re-opening, the following testcase still fails (the original underlying problem
has not been fully fixed).


extern void abort (void);

typedef struct PgHdr PgHdr;
typedef unsigned char u8;
struct PgHdr {
int y;
struct {
 unsigned int pgno;
 PgHdr *pNextHash, *pPrevHash;
 PgHdr *pNextFree, *pPrevFree;
 PgHdr *pNextAll;
 u8 inJournal;
 short int nRef;
 PgHdr *pDirty, *pPrevDirty;
 unsigned int notUsed;
} x;
};
volatile PgHdr **xx;
static inline PgHdr *merge_pagelist(PgHdr *pA, PgHdr *pB)
{
 PgHdr result;
 PgHdr *pTail;
 xx = &result.x.pDirty;
 pTail = &result;
 while( pA && pB ){
   if( pA->x.pgnox.pgno ){
 pTail->x.pDirty = pA;
 pTail = pA;
 pA = pA->x.pDirty;
   }else{
 pTail->x.pDirty = pB;
 pTail = pB;
 pB = pB->x.pDirty;
   }
 }
 if( pA ){
   pTail->x.pDirty = pA;
 }else if( pB ){
   pTail->x.pDirty = pB;
 }else{
   pTail->x.pDirty = 0;
 }
 return result.x.pDirty;
}

PgHdr * __attribute__((noinline)) sort_pagelist(PgHdr *pIn)
{
 PgHdr *a[25], *p;
 int i;
 __builtin_memset (a, 0, sizeof (a));
 while( pIn ){
   p = pIn;
   pIn = p->x.pDirty;
   p->x.pDirty = 0;
   for(i=0; i<25 -1; i++){
 if( a[i]==0 ){
   a[i] = p;
   break;
 }else{
   p = merge_pagelist(a[i], p);
   a[i] = 0;
   a[i] = 0;
 }
   }
   if( i==25 -1 ){
 a[i] = merge_pagelist(a[i], p);
   }
 }
 p = a[0];
 for(i=1; i<25; i++){
   p = merge_pagelist (p, a[i]);
 }
 return p;
}

int main()
{
 PgHdr a[5];
 PgHdr *p;
 a[0].x.pgno = 5;
 a[0].x.pDirty = &a[1];
 a[1].x.pgno = 4;
 a[1].x.pDirty = &a[2];
 a[2].x.pgno = 1;
 a[2].x.pDirty = &a[3];
 a[3].x.pgno = 3;
 a[3].x.pDirty = 0;
 p = sort_pagelist (&a[0]);
 if (p->x.pDirty == p)
   abort ();
 return 0;
}


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |


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

[Bug rtl-optimization/34070] [4.1/4.2/4.3 Regression] Wrong code for (int)x%4

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2007-11-12 12:41 ---
The difference is that we now generate

f:
.LFB2:
andl$3, %edi
movl%edi, %eax
ret

while previously we'd get the correct

f:
.LFB3:
leal3(%rdi), %eax
cmpl$-1, %edi
cmovg   %edi, %eax
andl$-4, %eax
subl%eax, %edi
movl%edi, %eax
ret

for

int f(unsigned int x)
{
return ((int)x) % 4;
}

This is a problem in fold, as we get initially:

;; Function f (f)
;; enabled by -tree-original


{
  return (int) x & 3;
}

which is wrong.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
  Component|c   |rtl-optimization
 Ever Confirmed|0   |1
   Keywords||wrong-code
   Last reconfirmed|-00-00 00:00:00 |2007-11-12 12:41:59
   date||
Summary|Wrong code for (int)x%4 |[4.1/4.2/4.3 Regression]
   ||Wrong code for (int)x%4


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

[Bug rtl-optimization/34070] [4.1/4.2/4.3 Regression] Wrong code for (int)x%4

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2007-11-12 12:45 ---
Mine.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |rguenth at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2007-11-12 12:41:59 |2007-11-12 12:45:59
   date||


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

[Bug middle-end/34070] [4.1/4.2/4.3 Regression] Wrong code for (int)x%4

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

  Component|rtl-optimization|middle-end
  Known to fail||4.1.0
  Known to work||4.0.4
   Target Milestone|--- |4.2.3


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

[Bug tree-optimization/34027] [4.3 regression] -Os code size nearly doubled

[rguenth at gcc dot gnu dot org]

--- Comment #8 from rguenth at gcc dot gnu dot org  2007-11-12 13:24 ---
Subject: Bug 34027

Author: rguenth
Date: Mon Nov 12 13:24:06 2007
New Revision: 130097

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130097
Log:
2007-11-12  Richard Guenther  <[EMAIL PROTECTED]>

PR middle-end/34027
* fold-const.c (fold_binary): Fold n - (n / m) * m to n % m.
(fold_binary): Fold unsinged FLOOR_DIV_EXPR to TRUNC_DIV_EXPR.

* gcc.dg/pr34027-1.c: New testcase.
* gcc.dg/pr34027-2.c: Likewise.

Added:
trunk/gcc/testsuite/gcc.dg/pr34027-1.c
trunk/gcc/testsuite/gcc.dg/pr34027-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/fold-const.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug tree-optimization/34027] [4.3 regression] -Os code size nearly doubled

[rguenth at gcc dot gnu dot org]

--- Comment #9 from rguenth at gcc dot gnu dot org  2007-11-12 13:28 ---
We now generate with -Os -m32

foobar:
pushl   %ebp
movl%esp, %ebp
subl$8, %esp
pushl   $0
pushl   $10
pushl   12(%ebp)
pushl   8(%ebp)
call__umoddi3
addl$16, %esp
leave
ret

and with -O2 -m32:

foobar:
pushl   %ebp
movl%esp, %ebp
subl$24, %esp
movl12(%ebp), %edx
movl8(%ebp), %eax
cmpl$0, %edx
ja  .L5
cmpl$9, %eax
ja  .L5
leave
ret

which for -Os is smaller than what we generated with 4.2 (and for -O2 it
is slightly larger).

So, fixed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug c/34071] Poor behaviour of complex division in 64-bit on Intel

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2007-11-12 13:41 ---
We open-code complex division in libgcc and benefit from the extra precision on
x87 in this case (so this is related to PR323).  But surely __divdc3 has
QOI issues here:

#if defined(L_divsc3) || defined(L_divdc3) \
|| defined(L_divxc3) || defined(L_divtc3)

CTYPE
CONCAT3(__div,MODE,3) (MTYPE a, MTYPE b, MTYPE c, MTYPE d)
{
  MTYPE denom, ratio, x, y; 

  /* ??? We can get better behavior from logarithmic scaling instead of
 the division.  But that would mean starting to link libgcc against
 libm.  We could implement something akin to ldexp/frexp as gcc builtins
 fairly easily...  */
  if (FABS (c) < FABS (d))
{
  ratio = c / d;
  denom = (c * ratio) + d;
  x = ((a * ratio) + b) / denom;
  y = ((b * ratio) - a) / denom;
}
  else
{
  ratio = d / c;
  denom = (d * ratio) + c;
  x = ((b * ratio) + a) / denom;
  y = (b - (a * ratio)) / denom;
}

  /* Recover infinities and zeros that computed as NaN+iNaN; the only cases
 are nonzero/zero, infinite/finite, and finite/infinite.  */
  if (isnan (x) && isnan (y))
{
  if (c == 0.0 && d == 0.0 && (!isnan (a) || !isnan (b)))
{
  x = COPYSIGN (INFINITY, c) * a;
  y = COPYSIGN (INFINITY, c) * b;
}
  else if ((isinf (a) || isinf (b)) && isfinite (c) && isfinite (d))
{
  a = COPYSIGN (isinf (a) ? 1 : 0, a);
  b = COPYSIGN (isinf (b) ? 1 : 0, b);
  x = INFINITY * (a * c + b * d);
  y = INFINITY * (b * c - a * d);
}
  else if ((isinf (c) || isinf (d)) && isfinite (a) && isfinite (b))
{ 
  c = COPYSIGN (isinf (c) ? 1 : 0, c);
  d = COPYSIGN (isinf (d) ? 1 : 0, d);
  x = 0.0 * (a * c + b * d);
  y = 0.0 * (b * c - a * d);
}
}

  return x + I * y;
}
#endif /* complex divide */


I bet we have a duplicate bug of this somewhere, but I can't find it right
now.


-- 


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

[Bug fortran/31608] wrong types in character array/scalar binop

[pault at gcc dot gnu dot org]

--- Comment #55 from pault at gcc dot gnu dot org  2007-11-12 14:04 ---
(In reply to comment #40)

> ! { dg-final { scan-tree-dump-times "\\\[S\.5\\\]\\\[1\\\]" 2 "original" } }
> The tree (dump) itself seems to be ok.

I hadn't noticed that this one had come back over the horizon.  I do not feel
up to this continuing part of the problem and so have unassigned myself.

However, I would like to point out that the immediate problem could be fixed by
counting the occurrences of "5\\\]\\\[1\\\]" in the testcase.

Cheers

Paul


-- 

pault at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|pault at gcc dot gnu dot org|unassigned at gcc dot gnu
   ||dot org
 Status|REOPENED|NEW


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

[Bug middle-end/34070] [4.1/4.2/4.3 Regression] Wrong code for (int)x%4

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2007-11-12 14:16 ---
Subject: Bug 34070

Author: rguenth
Date: Mon Nov 12 14:16:05 2007
New Revision: 130098

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130098
Log:
2007-11-12  Richard Guenther  <[EMAIL PROTECTED]>

PR middle-end/34070
* fold-const.c (fold_binary): If testing for non-negative
operands with tree_expr_nonnegative_warnv_p make sure to
use op0 which has all (sign) conversions retained.

* gcc.c-torture/execute/pr34070-1.c: New testcase.
* gcc.c-torture/execute/pr34070-2.c: Likewise.

Added:
trunk/gcc/testsuite/gcc.c-torture/execute/pr34070-1.c
trunk/gcc/testsuite/gcc.c-torture/execute/pr34070-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/fold-const.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug middle-end/34070] [4.1/4.2 Regression] Wrong code for (int)x%4

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2007-11-12 14:16 ---
Fixed for 4.3.0.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

  Known to work|4.0.4   |4.0.4 4.3.0
Summary|[4.1/4.2/4.3 Regression]|[4.1/4.2 Regression] Wrong
   |Wrong code for (int)x%4 |code for (int)x%4


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

[Bug c/34071] Poor precision of complex division __divdc3 in 64-bit on Intel

[nmm1 at cam dot ac dot uk]

--- Comment #2 from nmm1 at cam dot ac dot uk  2007-11-12 14:25 ---
Well, yes and no.  I am sorry, but that reply has raised several separate
points, so there is a threat of a thread split.

1) It is vaguely related to PR323, yes, but not simply.  What I was saying
could
be considered is special-casing complex division and not putting it through all
of the code generation stages.  I.e. forcibly using native Intel arithmetic,
irrespective of the fpmath setting.  The instruction scheduling etc. can still
be performed.  That technique was common on mainframes for conversion to and
from integers.

2) Yes, there are QoI issues with __divdc3 - several.  The basic code is more
robust than the crude code, but still gets some non-overflowing boundary cases
wrong.  The only system I have used that got those right was AIX on POWER4, and
it used a heavyweight function (of course).  If anyone has the urge to pursue
this, I can help, but I am not sure if it is worth the effort.  Personally,
I think that the basic _divdc3 code is by-and-large good enough.

3) __divdc3 makes a complete mess of NaN and infinity handling, I am afraid,
but it isn't clear how soluble that is.  The root cause is that C99 has done
precisely the same, so there isn't even a mathematically sensible target to
aim at.  It can't be got properly 'right' until there is a reasonable
NaN/infinity model for complex numbers, and you don't want to start with a
Cartesian floating-point representation if you are going there.


-- 


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

[Bug target/34072] New: unoptimal byte extraction.

[pluto at agmk dot net]

$ cat b.cpp

unsigned char byte0( unsigned long long x ) { return x; }
unsigned char byte1( unsigned long long x ) { return ( x >> 8 ); }
unsigned char byte6( unsigned long long x ) { return ( x >> 48 ); }
unsigned char byte7( unsigned long long x ) { return ( x >> 56 ); }

$ /opt/gcc43/bin/g++ b.cpp -fomit-frame-pointer -m32 -O2 -c && objdump -dC b.o

 :
   0:   0f b6 44 24 04  movzbl 0x4(%esp),%eax
   5:   c3  ret

0010 :
  10:   8b 44 24 04 mov0x4(%esp),%eax  \
  14:   8b 54 24 08 mov0x8(%esp),%edx   = why not movzbl
5(esp)?
  18:   0f ac d0 08 shrd   $0x8,%edx,%eax  /
  1c:   c3  ret

0020 :
  20:   0f b7 44 24 0a  movzwl 0xa(%esp),%eax
  25:   c3  ret

0030 :
  30:   0f b6 44 24 0b  movzbl 0xb(%esp),%eax
  35:   c3  ret


-- 
   Summary: unoptimal byte extraction.
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pluto at agmk dot net
GCC target triplet: ix86-gnu-linux


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

[Bug tree-optimization/34027] [4.3 regression] -Os code size nearly doubled

[rguenth at gcc dot gnu dot org]

--- Comment #10 from rguenth at gcc dot gnu dot org  2007-11-12 15:01 
---
of course in the -O2 case I forgot to paste the rest of the fn in, here it is:

.p2align 4,,7
.p2align 3
.L5:
addl$-10, %eax
adcl$-1, %edx
movl$10, 8(%esp)
movl$0, 12(%esp)
movl%eax, (%esp)
movl%edx, 4(%esp)
call__umoddi3
leave
ret

so unfortunately the expanders don't deal with modulus the same way as with
the div/mul sequence.


-- 


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

[Bug fortran/33759] Unequal character lengths in MERGE intrinsic not detected at run time

[pault at gcc dot gnu dot org]

--- Comment #7 from pault at gcc dot gnu dot org  2007-11-12 15:03 ---
(In reply to comment #6)
> > and survives "dg.exp=gfortran/transfer*".
> Let me just point out that gfortran.dg/transfer_simplify_4.f90 fails
> with any optimization starting at -O1 due to the failure of the reduced test:

Note that this failure occurs without the patch and is a problem with the
scalar branch of transfer.  This patch is OK.

A peculiar feature of this failure is that 'i' can be changed to INTEGER(1,2,8)
and the test succeeds at any level of optimisation.  It is only at the default
logical length that it fails!

Puzzled

Paul


-- 

pault at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu dot
   ||org


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

[Bug c++/32402] Error while allocating array of pointers to objects of a pure virtual class

[gcc at waisse dot org]

--- Comment #2 from gcc at waisse dot org  2007-11-12 15:06 ---
same kind of problem here, I'm currently porting an application from PGI/MFC to
gcc/QT and I'm not able to build this code with the error message :

/opt/cimlib/gcc_scali/AssembleurLocalPetsc.h:49: error: cannot allocate an
object of abstract type ‘CimSystemeLineaire::ALPetscPar’
/opt/cimlib/gcc_scali/AssembleurLocalPetsc.h:33: note: because the following
virtual functions are pure within ‘CimSystemeLineaire::ALPetscPar’:
/opt/cimlib/gcc_scali/AssembleurLocal.h:36: note: virtual CIMint
CimSystemeLineaire::AssembleurLocal::ajout_contributions_matrice(CIMint,
CIMint*, CIMint*, CIMdouble*)
/opt/cimlib/gcc_scali/AssembleurLocal.h:70: note: virtual CIMint
CimSystemeLineaire::AssembleurLocal::ajout_contributions_second_membre(CIMint,
CIMint*, CIMdouble*)

 This happens with a create() method returning a new object, depending on the
implementation of the abstract class ( some kind of virtual creator with a
differnt code for each implementation ).


-- 

gcc at waisse dot org changed:

   What|Removed |Added

 CC||gcc at waisse dot org


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

[Bug target/33923] [4.3 Regression] ICE in reload_cse_simplify_operands (insn does not satisfy its constraints)

[ebotcazou at gcc dot gnu dot org]

--- Comment #7 from ebotcazou at gcc dot gnu dot org  2007-11-12 15:18 
---
> Eric, the PRE issue you mention was fixed (xf. bug 32540).  The target issue 
> is
> still open.

OK, thanks.  I guess the testcase doesn't fail anymore with the default
options.


-- 


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

[Bug c++/34073] New: overloaded template function resolves differently if one type is included in a namespace

[adl at gnu dot org]

Two files are appended at the end of this report: temp1.cc and temp2.cc.

temp1.cc is the only file that causes a problem with recent releases
of GCC.  It contains :

1. a template definition of  Structure
2. a template definition of  op_is_finite(const Structure*)
3. a template definition of  algebra::AlphabetSet inheriting from Structure
4. a template definition of  Element 
   that calls op_is_finite(const algebra::AlphabetSet*) in its ctor
5. a template overloaded definition for 
 op_is_finite(const algebra::AlphabetSet*)
6. a main function that instantiate Element.

Because all definitions but main() are template, I expect the call to
op_is_finite() in the ctor of Element (#4) to be resolved during the 
instantiation of Element (#6) after the second definition
of op_is_finite() (#5) has been read.  So the call would be bound
to that second definition and not to the first.

I have tested three GCC versions :
g++-3.4 (GCC) 3.4.6 (Debian 3.4.6-6)
g++-4.1 (GCC) 4.1.3 20070718 (prerelease) (Debian 4.1.2-14)
g++-4.2 (GCC) 4.2.3 20071014 (prerelease) (Debian 4.2.2-3)

Both 4.1 and 4.2 behave identically: they seem to ignore the second
definition of op_is_finite and try to call the first.

3.4 does what we expect: it calls the second definition.


We have found at least two ways to alter temp1.cc such that 4.2 will
compile it.

- One is to move the second definition of op_is_finite() (#5) before its
  use in the constructor of Element (#4).  

  This ordering would make sense to me if the functions were not
  template, but it's not clear why this would change anything in
  the resolution of template overloaded functions.  I might be
  missing something.

- Another possibility is to move AlphabetSet struct out of 
  the "algebra::" namespace.  temp2.cc contains the updated
  code.  

  I'm really surprized that 4.2 compiles temp2.cc
  without problem and fails on temp1.cc.




//
 temp1.cc starts here 
//

template struct Structure {};

template
bool op_is_finite (const Structure*)
{
  // Error on purpose, this function is not expected to be instantiated.
  return Structure();
}

namespace algebra
{
  template 
  struct AlphabetSet : public Structure > {};
}

template 
struct Element
{
  Element()
  {
op_is_finite(static_cast*>(0));
  }
};

template 
bool op_is_finite(const algebra::AlphabetSet*)
{
  // This is the function we want to be called.
  return true;
}

int main()
{
  Element alpha;
}

// % g++-3.4 -Wall -W temp1.cc
// % g++-4.2 -Wall -W temp1.cc
// temp1.cc: In function 'bool op_is_finite(const Structure*) [with S =
algebra::AlphabetSet]':
// temp1.cc:21:   instantiated from 'Element::Element() [with L = char]'
// temp1.cc:34:   instantiated from here
// temp1.cc:7: error: cannot convert 'Structure >'
to 'bool' in return

//
 temp2.cc starts here 
//

template struct Structure {};

template
bool op_is_finite (const Structure*)
{
  // Error on purpose, this function is not expected to be instantiated.
  return Structure();
}

template 
struct AlphabetSet : public Structure > {};

template 
struct Element
{
  Element()
  {
op_is_finite(static_cast*>(0));
  }
};

template 
bool op_is_finite(const AlphabetSet*)
{
  // This is the function that is called, as we expected.
  return true;
}

int main()
{
  Element alpha;
}

// % g++-3.4 -Wall -W temp2.cc
// % g++-4.2 -Wall -W temp2.cc


-- 
   Summary: overloaded template function resolves differently if one
type is included in a namespace
   Product: gcc
   Version: 4.2.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: adl at 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=34073

[Bug tree-optimization/34074] New: Segmentation fault with -ftree-loop-linear

[b0ntrict0r at yandex dot ru]

Every time I try to build any project with -ftree-loop-linear gcc fault with
segmentaion fault while processing some function from some file. Place which
crash happens differs from project to project but presents in every project.


-- 
   Summary: Segmentation fault with -ftree-loop-linear
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: b0ntrict0r at yandex dot ru
 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=34074

[Bug rtl-optimization/34035] [4.3 Regression] ICE in calc_dfs_tree with -O2 -fnon-call-exceptions -ffast-math -fno-gcse

[ebotcazou at gcc dot gnu dot org]

--- Comment #4 from ebotcazou at gcc dot gnu dot org  2007-11-12 15:25 
---
> The option list should have included -O2.  This is one of the failures found
> compiling SPEC CPU2000 with lots of sets of options and running with the test
> input, as described in http://gcc.gnu.org/ml/gcc/2007-09/msg00496.html.

OK, thanks for explaining again. :-)


-- 


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

[Bug fortran/33759] Unequal character lengths in MERGE intrinsic not detected at run time

[pault at gcc dot gnu dot org]

--- Comment #8 from pault at gcc dot gnu dot org  2007-11-12 15:34 ---
(In reply to comment #7)

> A peculiar feature of this failure is that 'i' can be changed to INTEGE(1,2,8)
> and the test succeeds at any level of optimisation.  It is only at the default
> logical length that it fails!
> Puzzled

For -O1 and above, .true. == 1_defaultint, whereas it is  .true. ==
>0_defaultint for no optimization.  Try setting ip1 to 1.

Paul


-- 


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

[Bug c++/32402] Error while allocating array of pointers to objects of a pure virtual class

[gcc at waisse dot org]

--- Comment #3 from gcc at waisse dot org  2007-11-12 15:42 ---
 My problem is exactly the same as the one shown in the example code posted by
Patrick Vestjens, all of the pure functions are re-implemented in the
inherithing clas, so the inheriting class is no more pure but its still
impossible to build.

 Why is this bug not confirmed since 2007-06-19 ? 


-- 


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

[Bug middle-end/34046] [4.3 Regression] verify_flow_info failed

[ebotcazou at gcc dot gnu dot org]

--- Comment #4 from ebotcazou at gcc dot gnu dot org  2007-11-12 16:15 
---
At the end of the tree DOM pass this time.


-- 

ebotcazou at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-11-12 16:15:52
   date||


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

[Bug tree-optimization/34046] [4.3 Regression] verify_flow_info failed

[ebotcazou at gcc dot gnu dot org]

--- Comment #5 from ebotcazou at gcc dot gnu dot org  2007-11-12 16:16 
---
Investigating.


-- 

ebotcazou at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |ebotcazou at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
  Component|middle-end  |tree-optimization
  GCC build triplet||x86_64-*-*
   GCC host triplet|suse-linux-x86_64   |x86_64-*-*
 GCC target triplet||x86_64-*-*
   Last reconfirmed|2007-11-12 16:15:52 |2007-11-12 16:16:48
   date||


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

[Bug c++/29225] [4.0/4.1/4.2/4.3 regression] ICE in gimplify_expr, at gimplify.c:4513

[jakub at gcc dot gnu dot org]

--- Comment #7 from jakub at gcc dot gnu dot org  2007-11-12 16:20 ---
Testing a fix.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|aldyh at gcc dot gnu dot org|jakub at gcc dot gnu dot org


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

[Bug c/34071] Poor precision of complex division __divdc3 in 64-bit on Intel

[joseph at codesourcery dot com]

--- Comment #3 from joseph at codesourcery dot com  2007-11-12 16:29 ---
Subject: Re:  Poor precision of complex division __divdc3 in
 64-bit on Intel

Excess overflows in complex arithmetic is noted on 
 but I don't think there's a specific 
bug for it.  Bug 24581 deals with cases GCC gets wrong through always 
converting real operands of complex arithmetic to complex type.  Bug 30789 
is the bug that constant folding of complex multiplication and division is 
worse than the runtime arithmetic because it doesn't handle any of the 
special cases at all.

Complex multiplication and division in libgcc do essentially follow what 
C99 Annex G says (but GCC does not have support for imaginary types - I'm 
not sure how useful or otherwise such support would be).

Some libgcc function do use wider types for internal computations (in 
particular the conversions from long long to floating types) - the 
suggested solution for this bug would effectively be to use XFmode in 
__divdc3 instead of DFmode.  You may want to avoid using the soft-float 
TFmode __float128, however, and only select wider types that are 
reasonably fast (or compile-time options could select implementations 
with different trade-offs).


-- 


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

[Bug fortran/34067] gfortran.dg/char_cshift_2.f90 fails with -O3 -funroll-loops fails on Intel Darwin

[dominiq at lps dot ens dot fr]

--- Comment #4 from dominiq at lps dot ens dot fr  2007-11-12 16:33 ---
> The manual only says "-On turns on the following optimization flags", but it
> does a few other things that are not controlled by individual -f flags.

At least it seems to do the same thing up to -fdump-tree-optimized. So the
problem appears from here to the assembly code!-(I won't comment about the
missing controls after ~30 flags;-).

Note that the failures disappear with -m64 (missing/bad conversion).

> The possible culprits are: 130071 (probably not), 130069, 130067, 130052, 
> 130050, 130045,
> 130043, 130042, 130041, 130040, 130039.

I have reverted revisions 130039, 130045, 130067, and 130072, and I have also
done a clean bootstrap without changes.


-- 


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

[Bug fortran/33759] Unequal character lengths in MERGE intrinsic not detected at run time

[dominiq at lps dot ens dot fr]

--- Comment #9 from dominiq at lps dot ens dot fr  2007-11-12 16:48 ---
Subject: Re:  Unequal character lengths in MERGE intrinsic
 not detected at run time

> This patch is OK.

Yes indeed, I have applied it a long time ago. 

I have only pointed to the last bug on transfer I know of.

> It is only at the default logical length that it fails!

What is the default logical length with -m64? because it fails
only for integer(4) with or without -m64 (PPC Darwin8)


-- 


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

[Bug tree-optimization/34074] Segmentation fault with -ftree-loop-linear

[spop at gcc dot gnu dot org]

--- Comment #1 from spop at gcc dot gnu dot org  2007-11-12 17:56 ---
Subject: Re:  New: Segmentation fault with -ftree-loop-linear

> Every time I try to build any project with -ftree-loop-linear gcc fault with
> segmentaion fault while processing some function from some file. Place which
> crash happens differs from project to project but presents in every project.
>

Please send a preprocessed testcase.


-- 


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

[Bug c++/33885] member reference to a temporary object being deleted too early

[james dot kanze at gmail dot com]

--- Comment #2 from james dot kanze at gmail dot com  2007-11-12 17:56 
---
(In reply to comment #0)
> class A{
> // 
> };

> class B{
> public:
>   explicit B(const A& a)
> : i_a(a)
>   {
>   }
>   ~B()
>   {
>   }
> private:
>   const A& i_a;
> };

> A returnA( const char* arg )
> {
>return A(/*arg*/);
> }

> foo()
> {
>const A& aRef = returnA("FirstObject");  // . (1)
>{
>  const B b(returnA("SecondObject"));// . (2)

Undefined behavior here.  The temporary returned by returnA
must be destructed at the end of the full expression.

>  ///...
>  typedef int outofscope_block;  // . (3)  
>}
>typedef char outofscope_function;// . (4)
> }

> temporary object created and referenced by aRef is being
> deleted when aRef goes out of scope in foo, as Expected.

> temporary object created and referenced by B::i_a is being
> deleted right after object b's construction, Not expected.  It
> should(?) have the same life time as the B::i_a(thus b), such
> as deleted _after_ line (3) --- If this assumpsion is false,
> then what's the difference between a 'plain reference' and
> 'member reference' herein??

The difference is that the temporary is not used to initialize
the member reference.  The temporary is used to initialize the
reference argument of B's constructor.  It's lifetime is that of
the reference argument of B's constructor (or the end of the
full expression, which ever is longer).

There is a special rule concerning temporaries used to
initialize member references, however.  If you'd have written:

B::B()
: i_a( returnA() )
{
}

the temporary would only have the lifetime of the constructor,
despite having been bound to a reference with a longer lifetime.
I presume that this is mainly because it would be almost
impossible to implement otherwise.

> BTW, it works as expected on SunCC compiler. It core dumps on
> gcc 3.3.3 while having (empty/invalid) data for i_a on gcc
> 4.1.2 but not coring.

It doesn't work with Sun CC *if* the compiler is invoked with
the necessary options for standard conformance.  In this case,
you need -features=tmplife.  For historical reasons, Sun
destructs temporaries later (much later, in fact) than required
by the standard.

-- 
James Kanze (GABI Software) email:[EMAIL PROTECTED]
Conseils en informatique orientée objet/
   Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34


-- 


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

[Bug c++/33975] [4.1/4.2/4.3 Regression] Incomplete types may be derefenced

[janis at gcc dot gnu dot org]

--- Comment #2 from janis at gcc dot gnu dot org  2007-11-12 18:01 ---
Mainline now reports an error for this code:

elm3b187% /opt/gcc-nightly/trunk/bin/g++ 33975.cc
33975.cc: In function ‘int main()’:
33975.cc:8: error: invalid use of incomplete type ‘struct S’
33975.cc:1: error: forward declaration of ‘struct S’
33975.cc:8: error:   initializing argument 1 of ‘int f(S)’

The patch that fixed this for mainline:

http://gcc.gnu.org/viewcvs?view=rev&rev=129968

r129968 | jakub | 2007-11-07 19:27:27 + (Wed, 07 Nov 2007)

Here's the source file I used:

struct S;
int f(S s);

int
main ()
{
  S *p;
  int i = f(*p);
}


-- 


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

[Bug c++/33984] [4.2/4.3 Regression] bit-fields, references and overloads

[janis at gcc dot gnu dot org]

--- Comment #2 from janis at gcc dot gnu dot org  2007-11-12 18:04 ---
The mainline patch that caused this test to be accepted:

http://gcc.gnu.org/viewcvs?view=rev&rev=113199

r113199 | mmitchel | 2006-04-23 18:04:33 + (Sun, 23 Apr 2006)


-- 

janis at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||mmitchel at gcc dot gnu dot
   ||org


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

[Bug c++/30293] [4.0/4.1/4.2/4.3 regression] ICE with extern "Java" in store_init_value

[tromey at gcc dot gnu dot org]

--- Comment #6 from tromey at gcc dot gnu dot org  2007-11-12 18:07 ---
Yeah, for both this and for PR 30294, I think we can just reject some
constructs very early.  I don't think it makes sense to declare variables,
fields, or functions with "java" types that are not pointers.
The only question here, I think, is whether libgcj uses this construct.

Maybe there could still be a bug for 30293 though.


-- 


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

[Bug c++/34075] New: temporary used in ?: expression tho second and third expr. lvalues

[james dot kanze at gmail dot com]

Note: I get the same error on i686-pc-linux-gnu.

The easiest is to give a short example:

- reftmp.cc --
typedef int S ;
//  struct S { int i ; } ;

class C
{
public:
struct D { S d[ 64 ] ; } ;

S const& g( int i ) const ;

private:
D* pD ;
S  dflt ;

S const& g1( D* pd, int i ) const ;
} ;

S const&
C::g( int i ) const
{
return g1( pD, i ) ;
}

S const&
C::g1( D* pd, int i ) const
{
return pd == 0 ? dflt : pd->d[ i ] ;
}

int
main()
{
C aC ;
aC.g( 1 ) ;
return 0 ;
}
- reftmp.cc --

When compiled without any options, this warns about returning a
reference to a temporary in the line:
return pd == 0 ? dflt : pd->d[ i ] ;
And in fact, the generated code does create a temporary and
return a reference to a temporary.  (According to the standard,
if the second and third expressions in a ?: are both lvalues,
and have the same type, then the results are an lvalue.)

If I replace the typedef in the first line with the commented
out struct, then the code works correctly.  (In the actual code,
the class C is a template, and I can't control how the user
instantiates it.)

For the moment, as a work-around, I've replaced the line in
question with:
return *(pd == 0 ? &dflt : &pd->d[ i ]) ;
This works, and generates the code which should have been
generated by the original line.

-- 
James Kanze (GABI Software) email:[EMAIL PROTECTED]
Conseils en informatique orientée objet/
   Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34


-- 
   Summary: temporary used in ?: expression tho second and third
expr. lvalues
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: james dot kanze at gmail dot com
 GCC build triplet: sparc-sun-solaris2.8
  GCC host triplet: sparc-sun-solaris2.8
GCC target triplet: sparc-sun-solaris2.8


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

[Bug tree-optimization/34074] Segmentation fault with -ftree-loop-linear

[b0ntrict0r at yandex dot ru]

--- Comment #2 from b0ntrict0r at yandex dot ru  2007-11-12 18:30 ---
Created an attachment (id=14531)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14531&action=view)
Preprocessed source


-- 


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

[Bug tree-optimization/34074] Segmentation fault with -ftree-loop-linear

[b0ntrict0r at yandex dot ru]

--- Comment #3 from b0ntrict0r at yandex dot ru  2007-11-12 18:32 ---
(From update of attachment 14531)
Some corrections. gcc faults only if -O is also set.

Building mjpegtools.
Error message:
imageplanes.cc: In static member function 'static void
ImagePlanes::BorderMark(uint8_t*, int, int, int, int)':
imageplanes.cc:54: internal compiler error: Segmentation fault


-- 


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

[Bug c++/34063] [4.3 Regression] ICE: build2_stat, at tree.c:3115

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org
   Keywords||ice-on-valid-code
Summary|ICE: build2_stat, at|[4.3 Regression] ICE:
   |tree.c:3115 |build2_stat, at tree.c:3115
   Target Milestone|--- |4.3.0


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

[Bug c/34071] Poor precision of complex division __divdc3 in 64-bit on Intel

[pinskia at gcc dot gnu dot org]

--- Comment #4 from pinskia at gcc dot gnu dot org  2007-11-12 18:36 ---
What happens if you use -std=gnu99  because as far as I remember C99 complex
division is not enabled except with -std=gnu99/-std=c99 in 4.1 and before.


-- 


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

[Bug tree-optimization/34036] [4.2/4.3 Regression] ICE with control flow in the middle of basic block for -fnon-call-exceptions

[janis at gcc dot gnu dot org]

--- Comment #6 from janis at gcc dot gnu dot org  2007-11-12 18:44 ---
In response to comment #2, the options are indeed weird.  This is one of the
failures discovered by using combinations of options as described in
http://gcc.gnu.org/ml/gcc/2007-09/msg00496.html.  The correct fix might be to
simply disallow combinations of options that don't make sense, or to report
that the combination doesn't make sense and that one of them is ignored.


-- 


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

[Bug c/34071] Poor precision of complex division __divdc3 in 64-bit on Intel

[nmm1 at cam dot ac dot uk]

--- Comment #5 from nmm1 at cam dot ac dot uk  2007-11-12 18:58 ---
To Andrew Pinski:  nothing - it was one of the first things I tried.

To [EMAIL PROTECTED]:  PLEASE don't try to follow Annex G - that is about as
broken as it is possible to be; I use it as a horrible example in my course
on computer numerics!  And imaginary types are almost completely useless; it
isn't irrelevant that nobody has seriously suggested them being added to
Fortran
in 50 years.

This report wasn't about complex in general, but specifically about the
approach
on Intel architecture systems.  As Kahan says, the great advantage of Intel
arithmetic is precisely that it DOES allow you a bit of extra leeway for this
sort of calculation.


-- 


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

[Bug c++/34073] overloaded template function resolves differently if one type is included in a namespace

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2007-11-12 19:02 ---
And this is expected behavior of C++ Lookup in templates.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug middle-end/31862] Loop IM and other optimizations harmful for -fopenmp

[jakub at gcc dot gnu dot org]

--- Comment #15 from jakub at gcc dot gnu dot org  2007-11-12 19:11 ---
Sorry for the delay.

Unfortunately that doesn't help in this case:
on foo from #c7 it is not cselim pass, but lim, which changes:
foo (x, y)
{
  int i;

:

:
  # i_12 = PHI 
  if (x_3(D) < i_12)
goto ;
  else
goto ;

:
  v = y_4(D);

:
  i_5 = i_12 + 1;
  if (i_5 <= 99)
goto ;
  else
goto ;

:
  goto ;

:
  return;

}

into:

foo (x, y)
{
  int v_lsm.12;
  int i;

:
  v_lsm.12_11 = v;

:
  # v_lsm.12_1 = PHI 
  # i_12 = PHI 
  if (x_3(D) < i_12)
goto ;
  else
goto ;

:
  v_lsm.12_10 = y_4(D);

:
  # v_lsm.12_7 = PHI 
  i_5 = i_12 + 1;
  if (i_5 <= 99)
goto ;
  else
goto ;

:
  goto ;

:
  # v_lsm.12_15 = PHI 
  v = v_lsm.12_15;
  return;

}

which is unsafe, as there is no guarantee v is ever written within the loop.


-- 


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

[Bug rtl-optimization/34040] [4.3 Regression] ICE: in simplify_subreg, at simplify-rtx.c:4921 building libgfortran

[ebotcazou at gcc dot gnu dot org]

--- Comment #2 from ebotcazou at gcc dot gnu dot org  2007-11-12 19:21 
---
Confirmed with "-fallow-leading-underscore -O2 -m2e".


-- 

ebotcazou at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-11-12 19:21:33
   date||


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

[Bug rtl-optimization/34040] [4.3 Regression] ICE: in simplify_subreg, at simplify-rtx.c:4921 building libgfortran

[ebotcazou at gcc dot gnu dot org]

--- Comment #3 from ebotcazou at gcc dot gnu dot org  2007-11-12 19:21 
---
Investigating.


-- 

ebotcazou at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |ebotcazou at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2007-11-12 19:21:33 |2007-11-12 19:21:48
   date||


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

[Bug libgomp/33720] A negative value in OpenMP clause num_threads is not detected at runtime

[jakub at gcc dot gnu dot org]

--- Comment #2 from jakub at gcc dot gnu dot org  2007-11-12 19:37 ---
I'm not sure we should do anything about this.
We have a warning if the compiler can detect non-positive value at compile
time,
but we certainly can't ever issue any diagnostic at runtime for num_threads
0 (because the implementation uses that value to mean no num_threads clause was
present) and I'm not convinced the runtime library needs to be verbose to
stderr.  So e.g. silently assuming just one thread is IMHO better than doing
gomp_fatal in there.  You shouldn't expect any particular behavior from program
which triggers undefined behavior.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||rth at gcc dot gnu dot org


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

[Bug c++/32402] Error while allocating array of pointers to objects of a pure virtual class

[zackw at panix dot com]

--- Comment #4 from zackw at panix dot com  2007-11-12 19:41 ---
I am no C++ expert, so I don't know what

  new pure (*[3])

actually means, but I am nearly certain it does *not* mean "allocate an array
of 3 pointers to type pure".  That would be

  new pure *[3]

without the parentheses.


-- 


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

[Bug c++/33468] [4.1/4.2/4.3 Regression] C++: Invalid interpretation of friendness with nested classes

[janis at gcc dot gnu dot org]

--- Comment #3 from janis at gcc dot gnu dot org  2007-11-12 19:42 ---
On the 4.0 branch, the behavior of the test changed with:

http://gcc.gnu.org/viewcvs?view=rev&rev=115209

r115209 | jason | 2006-07-05 20:40:06 + (Wed, 05 Jul 2006)


-- 

janis at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||jason at gcc dot gnu dot org


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

[Bug c/34076] New: inline attribute seems to mess with const qualifier.

[alexandre dot nunes at gmail dot com]

On the following code:

#ifndef NOINLINES
#define EINLINE __inline__
#else
#define EINLINE
#endif

EINLINE int a(void *value)
{
  return *(char *)value;
}

int b(const char *val)
{
  return a((char *)val);
}

int c(void)
{
  return b("whatever");
}

... compiling it with these flags: -W -Wall -Winline -Wshadow -Werror -O
... gives this warning (treated as an error as requested):

pqp.c: In function ‘b’:
pqp.c:16: warning: passing argument 1 of ‘a’ discards qualifiers from pointer
target type

if you pass -DNOINLINES on the command line, i.e. take away the inline
attribute, this goes away, except if I compile with -O3 (which tries to inline
it anyway). Please note the explicit cast to (char *) at a; without that cast
gcc should (and it does) warn both with and without attribute inline, but I
couldn't find a way to make the explicit cast respected when gcc is inlining
functions.

I couldn't reproduce this on gcc 4.1.x, i.e. it behaves ok.


-- 
   Summary: inline attribute seems to mess with const qualifier.
   Product: gcc
   Version: 4.2.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: alexandre dot nunes at gmail dot com
 GCC build triplet: i486-linux-gnu
  GCC host triplet: i486-linux-gnu
GCC target triplet: i486-linux-gnu


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

[Bug c/34076] inline attribute seems to mess with const qualifier.

[alexandre dot nunes at gmail dot com]

--- Comment #1 from alexandre dot nunes at gmail dot com  2007-11-12 19:46 
---
Created an attachment (id=14532)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14532&action=view)
the original file from the bug report.

gcc -DNOINLINES -W -Wall -Winline -Wshadow -Werror -O -c pqp.c
gcc -W -Wall -Winline -Wshadow -Werror -O -c pqp.c
cc1: warnings being treated as errors
pqp.c: In function ‘b’:
pqp.c:16: warning: passing argument 1 of ‘a’ discards qualifiers from pointer
target type


-- 


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

[Bug c/34076] inline attribute seems to mess with const qualifier.

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2007-11-12 19:47 ---
*** This bug has been marked as a duplicate of 29478 ***

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


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug middle-end/29478] [4.2 Regression] optimization generates warning for casts

[pinskia at gcc dot gnu dot org]

--- Comment #22 from pinskia at gcc dot gnu dot org  2007-11-12 19:47 
---
*** Bug 34076 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||alexandre dot nunes at gmail
   ||dot com


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

[Bug c++/33501] [4.1/4.2 regression] Copy constructor assumed to exist for undefined class

[pinskia at gcc dot gnu dot org]

--- Comment #6 from pinskia at gcc dot gnu dot org  2007-11-12 19:50 ---
*** Bug 33975 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||andrew dot stubbs at st dot
   ||com


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

[Bug c++/33975] [4.1/4.2/4.3 Regression] Incomplete types may be derefenced

[pinskia at gcc dot gnu dot org]

--- Comment #3 from pinskia at gcc dot gnu dot org  2007-11-12 19:50 ---
The issue here is an exact dup of bug 33501.

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


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE


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

[Bug fortran/33904] OpenMP: Default(shared) and wrong "lastprivate variable is private in outer context"

[jakub at gcc dot gnu dot org]

--- Comment #1 from jakub at gcc dot gnu dot org  2007-11-12 20:03 ---
I believe the testcase is invalid, though I'm not 100% sure.
The thing is that in OpenMP 2.5, 2.8.1.1 we have:
"Variables used as loop iteration variables in sequential loops in a parallel
construct are private in the parallel construct."
i1 and i2 are used in sequential loops within the parallel construct.
Which means that i1 and i2 are predetermined private (though can be explicitly
mentioned in private/firstprivate/lastprivate/shared/reduction clauses) and for
variables with predetermined data sharing the default clause shouldn't have any
influence.

OpenMP 3.0 draft wording here is
"Variables used as loop iteration variables in sequential loops in an implicit
or explicit task region are private in the task region."
which can shed even more light into this, because "task region" is
"A region consisting of all code encountered during the execution of a task."
and "implicit task" is "A task generated by the implicit parallel region or
generated when a parallel construct is encountered during execution."
So when a thread encounters $omp do, it doesn't create a new task region.


-- 


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

[Bug target/34042] Segfault in mips_cannot_change_mode_class

[rsandifo at gcc dot gnu dot org]

--- Comment #5 from rsandifo at gcc dot gnu dot org  2007-11-12 20:05 
---
Subject: Bug 34042

Author: rsandifo
Date: Mon Nov 12 20:05:46 2007
New Revision: 130119

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130119
Log:
gcc/
PR target/34042
* config/mips/mips.c (mips_return_fpr_single): New function.
(mips_function_value): Use it when returning single-field
aggregates in FPRs.
(mips_expand_call): Handle the PARALLELs created by
mips_return_fpr_single.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/mips/mips.c


-- 


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

[Bug target/34042] Segfault in mips_cannot_change_mode_class

[rsandifo at gcc dot gnu dot org]

--- Comment #6 from rsandifo at gcc dot gnu dot org  2007-11-12 20:10 
---
Thanks for the testing.  Now fixed on mainline.


-- 

rsandifo at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug middle-end/29478] [4.2 Regression] optimization generates warning for casts

[alexandre dot nunes at gmail dot com]

--- Comment #23 from alexandre dot nunes at gmail dot com  2007-11-12 20:11 
---
(In reply to comment #20)
> Change target milestone to 4.2.3, as 4.2.2 has been released.
> 

Does this means it'll get fixed by 4.2.3, or the 4.2.x series will stay bugged
indefinitely?


-- 


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

[Bug middle-end/29478] [4.2 Regression] optimization generates warning for casts

[fang at csl dot cornell dot edu]

--- Comment #24 from fang at csl dot cornell dot edu  2007-11-12 20:19 
---
Subject: Re:  [4.2 Regression] optimization generates
 warning for casts

> --- Comment #23 from alexandre dot nunes at gmail dot com  2007-11-12 
> 20:11 ---
> (In reply to comment #20)
>> Change target milestone to 4.2.3, as 4.2.2 has been released.
>>
>
> Does this means it'll get fixed by 4.2.3, or the 4.2.x series will stay bugged
> indefinitely?

Just means the current *intent* is to fix by 4.2.3 (or target milestone). 
A nudge might encourage someone to do it sooner on the 4.2 branch before 
the next release (since 4.2.2 was just out recently).


-- 


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

[Bug middle-end/29478] [4.2 Regression] optimization generates warning for casts

[fang at csl dot cornell dot edu]

--- Comment #25 from fang at csl dot cornell dot edu  2007-11-12 20:22 
---
Subject: Re:  [4.2 Regression] optimization generates
 warning for casts

> Just means the current *intent* is to fix by 4.2.3 (or target milestone).
> A nudge might encourage someone to do it sooner on the 4.2 branch before
> the next release (since 4.2.2 was just out recently).

... but the audit trail suggests otherwise.  :S


-- 


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

[Bug c/29172] --combine can't handle #pragma once

[tromey at gcc dot gnu dot org]

--- Comment #6 from tromey at gcc dot gnu dot org  2007-11-12 20:24 ---
Testing a patch.


-- 

tromey at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |tromey at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2007-09-27 22:04:24 |2007-11-12 20:24:41
   date||


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

[Bug target/34077] New: GCC -O1 -minline-all-stringops -minline-stringops-dynamically fails for spec 2006 bzip2, gobmk, and h264ref benchmarks

[michael dot meissner at amd dot com]

I was building SPEC 2006 with the options: -minline-all-stringops
-minline-stringops-dynamically in addition to my normal options.  If you use
both options together, GCC generates the following error:
foo.c: In function ‘spec_random_load’:
foo.c:24: internal compiler error: in int_mode_for_mode, at stor-layout.c:258
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Tracing it down, emit_cmp_and_jump_insns is called to compare and jump with two
constant values:
Breakpoint 3, emit_cmp_and_jump_insns (x=0x2dff3c50, y=0x2dff3480,
comparison=LTU, size=0x0, mode=SImode, unsignedp=1, label=0x2e134fa0)
at /proj/gcc/fsf-src/trunk/gcc/optabs.c:4428
(gdb) print x
$7 = (rtx) 0x2dff3c50
(gdb) pr
(const_int 131072 [0x2])
(gdb) print y
$8 = (rtx) 0x2dff3480
(gdb) pr
(const_int 8 [0x8])
(gdb) up
#1  0x008adab6 in ix86_expand_movmem (dst=0x2e136a60,
src=0x2e136a80, count_exp=0x2dff3c50, align_exp=, 
expected_align_exp=, expected_size_exp=) at /proj/gcc/fsf-src/trunk/gcc/config/i386/i386.c:15362

The failure comes because integer constants have VOIDmode type, rather than an
integer type.

Either emit_cmp_and_jump_insns should handle the constant/constant case, or
ix86_expand_movemem should not call emit_cmp_and_jump_insns with constant
tests.


-- 
   Summary: GCC -O1 -minline-all-stringops -minline-stringops-
dynamically fails for spec 2006 bzip2, gobmk, and
h264ref benchmarks
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: michael dot meissner at amd dot com
 GCC build triplet: x86_64-unknown-linux-gnu
  GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu


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

[Bug target/34077] GCC -O1 -minline-all-stringops -minline-stringops-dynamically fails for spec 2006 bzip2, gobmk, and h264ref benchmarks

[michael dot meissner at amd dot com]

--- Comment #1 from michael dot meissner at amd dot com  2007-11-12 20:38 
---
Created an attachment (id=14533)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14533&action=view)
Reduced testcase for bug 34077 from 401.bzip2

This is the reduced testcase from 401.bzip2.


-- 


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

[Bug middle-end/29478] [4.2 Regression] optimization generates warning for casts

[alexandre dot nunes at gmail dot com]

--- Comment #26 from alexandre dot nunes at gmail dot com  2007-11-12 20:40 
---
(In reply to comment #25)
> 
> ... but the audit trail suggests otherwise.  :S
> 

Ok, now I'm confused :-)


-- 


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

[Bug c/24068] Unconditional warning when using -combine

[tromey at gcc dot gnu dot org]

--- Comment #11 from tromey at gcc dot gnu dot org  2007-11-12 20:43 ---
We unconditionally warn for a prototype following an old-style definition.
The oddity here is that these are in different files, glommed together
with --combine, and so don't represent exactly the same sort of style violation
as the warning is apparently intended to prevent.

I think the point behind comment #9 is that it is important that a prototype
always be visible, because one argument may require widening; in a case like
the sample code, if this were true, it would result in bugs.  See the
info node "Prototypes and Old-Style Function Definitions" for details.


-- 

tromey at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||tromey at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-11-12 20:43:26
   date||


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

[Bug middle-end/29478] [4.2 Regression] optimization generates warning for casts

[fang at csl dot cornell dot edu]

--- Comment #27 from fang at csl dot cornell dot edu  2007-11-12 20:59 
---
Subject: Re:  [4.2 Regression] optimization generates
 warning for casts

> Ok, now I'm confused :-)

Sorry, see comment #19.


-- 


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

[Bug fortran/34040] [4.3 Regression] ICE: in simplify_subreg, at simplify-rtx.c:4921 building libgfortran

[ebotcazou at gcc dot gnu dot org]

--- Comment #4 from ebotcazou at gcc dot gnu dot org  2007-11-12 21:06 
---
Nothing to do with optimization, it's a Fortran front-end problem:

(gdb) p debug_tree(from)
 
unit size 
align 32 symtab 0 alias set -1 canonical type 0x2a959ec680 precision 32
pointer_to_this >

fn 
unsigned SI size  unit size

align 32 symtab 0 alias set -1 canonical type 0x2a95a36a90>
readonly constant invariant
arg 0 
readonly public external built-in SI file pr34040.f95 line 0
align 16 built-in BUILT_IN_NORMAL:BUILT_IN_COPYSIGN
(mem:SI (symbol_ref:SI ("copysign") [flags 0x41] ) [0 S4 A32]) chain >>
arg 0 
unit size 
align 32 symtab 0 alias set -1 canonical type 0x2a959ec750
precision 64
pointer_to_this  reference_to_this
>

arg 0 
readonly used unsigned SI file pr34040.f95 line 1 size
 unit size 
align 32 context  initial 
(reg/v/f:SI 161 [ p1 ]) arg-type 
incoming-rtl (reg:SI 4 r4 [ p1 ]) chain >>
arg 1 

arg 0 
readonly used unsigned SI file pr34040.f95 line 1 size
 unit size 
align 32 context  initial 
(reg/v/f:SI 162 [ p2 ]) arg-type 
incoming-rtl (reg:SI 5 r5 [ p2 ])>>
pr34040.f95:4>

__builtin_copysign has got SFmode(*)(SFmode, SFmode) prototype and is invoked
on DFmode arguments.


-- 

ebotcazou at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|ebotcazou at gcc dot gnu dot|unassigned at gcc dot gnu
   |org |dot org
 Status|ASSIGNED|NEW
  Component|rtl-optimization|fortran


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

[Bug c++/34073] overloaded template function resolves differently if one type is included in a namespace

[steven at gcc dot gnu dot org]

--- Comment #2 from steven at gcc dot gnu dot org  2007-11-12 21:17 ---
Perhaps you can give a little more verbose explanation why this is invalid?


-- 

steven at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug rtl-optimization/34035] [4.3 Regression] ICE in calc_dfs_tree with -O2 -fnon-call-exceptions -ffast-math -fno-gcse

[ebotcazou at gcc dot gnu dot org]

--- Comment #5 from ebotcazou at gcc dot gnu dot org  2007-11-12 21:21 
---
Subject: Bug 34035

Author: ebotcazou
Date: Mon Nov 12 21:21:37 2007
New Revision: 130122

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130122
Log:
PR rtl-optimization/34035
* cse.c (cse_cfg_altered): New global variable.
(cse_jumps_altered): Make boolean.
(recorded_label_ref): Likewise.
(cse_insn): Adjust for above changes.
(cse_extended_basic_block): Likewise.  Set cse_cfg_altered
if dead edges have been purged.
(cse_main): Change return value specification and adjust code.
(rest_of_handle_cse): Adjust for above change.
(rest_of_handle_cse2): Likewise.
* gcse.c (rest_of_handle_gcse): Likewise.


Added:
trunk/gcc/testsuite/g++.dg/opt/cfg5.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/cse.c
trunk/gcc/gcse.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug rtl-optimization/34035] [4.3 Regression] ICE in calc_dfs_tree with -O2 -fnon-call-exceptions -ffast-math -fno-gcse

[ebotcazou at gcc dot gnu dot org]

--- Comment #6 from ebotcazou at gcc dot gnu dot org  2007-11-12 21:24 
---
This should work now.


-- 

ebotcazou at gcc dot gnu dot org changed:

   What|Removed |Added

URL||http://gcc.gnu.org/ml/gcc-
   ||patches/2007-
   ||11/msg00666.html
 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug rtl-optimization/34035] [4.3 Regression] ICE in calc_dfs_tree with -O2 -fnon-call-exceptions -ffast-math -fno-gcse

[steven at gcc dot gnu dot org]

--- Comment #7 from steven at gcc dot gnu dot org  2007-11-12 21:28 ---
The fix increases compile time, please reconsider.


-- 

steven at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |


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

[Bug c++/34073] overloaded template function resolves differently if one type is included in a namespace

[pinskia at gcc dot gnu dot org]

--- Comment #3 from pinskia at gcc dot gnu dot org  2007-11-12 21:29 ---
Basically the namelookup for op_is_finite in Element will lookup the previous
declared ones (at definition time) and then will do argument dependent lookup
(at instaintation time).  Argument dependent lookup only looks at definition in
the namespace containing that argument type.  So in the second case the
argument type (AlphabetSet) is in the global namespace so it will see the
function, while in the first case it is located in algebra namespace and there
is no matching function in that namespace.


-- 


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

[Bug fortran/33904] OpenMP: Default(shared) and wrong "lastprivate variable is private in outer context"

[jakub at gcc dot gnu dot org]

--- Comment #2 from jakub at gcc dot gnu dot org  2007-11-12 21:46 ---
Confirmed: http://openmp.org/pipermail/omp/2007/001101.html


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID


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

[Bug regression/33928] [4.3 Regression] 22% performance slowdown from 4.2.2 to 4.3.0 in floating-point code

[lucier at math dot purdue dot edu]

--- Comment #11 from lucier at math dot purdue dot edu  2007-11-12 21:50 
---
I suspected that the slowdown had nothing to do with computed gotos, so I
regenerated the C code using a switch instead of the computed gotos and got the
following:

For that same copy of mainline

gcc version 4.3.0 20071026 (experimental) [trunk revision 129664] (GCC) 

:

(time (direct-fft-recursive-4 a table))
470 ms real time
470 ms cpu time (470 user, 0 system)
no collections
64 bytes allocated
no minor faults
no major faults

For 4.2.2:

(time (direct-fft-recursive-4 a table))
384 ms real time
384 ms cpu time (383 user, 1 system)
no collections
64 bytes allocated
no minor faults
no major faults

So that's almost exactly the same slowdown as with computed gotos.

I changed the subject line to use 22% instead of 33% (I don't know how I got
33% before, perhaps I just mistyped it) and removed the phrase "with computed
gotos".

I'll include the new .i and .s files as attachments.


-- 

lucier at math dot purdue dot edu changed:

   What|Removed |Added

Summary|[4.3 Regression] 33%|[4.3 Regression] 22%
   |performance slowdown from   |performance slowdown from
   |4.2.2 to 4.3.0 in floating- |4.2.2 to 4.3.0 in floating-
   |point code with computed|point code
   |gotos   |


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

[Bug regression/33928] [4.3 Regression] 22% performance slowdown from 4.2.2 to 4.3.0 in floating-point code

[lucier at math dot purdue dot edu]

--- Comment #12 from lucier at math dot purdue dot edu  2007-11-12 21:51 
---
Created an attachment (id=14534)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14534&action=view)
.i file using a switch instead of computed gotos

This is the generated code with a switch instead of computed gotos.


-- 


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

[Bug regression/33928] [4.3 Regression] 22% performance slowdown from 4.2.2 to 4.3.0 in floating-point code

[lucier at math dot purdue dot edu]

--- Comment #13 from lucier at math dot purdue dot edu  2007-11-12 21:52 
---
Created an attachment (id=14535)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14535&action=view)
4.2.2 assembly for code using switch.


-- 


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

[Bug regression/33928] [4.3 Regression] 22% performance slowdown from 4.2.2 to 4.3.0 in floating-point code

[lucier at math dot purdue dot edu]

--- Comment #14 from lucier at math dot purdue dot edu  2007-11-12 21:53 
---
Created an attachment (id=14536)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14536&action=view)
4.3.0 assembly for code using a switch


-- 


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

[Bug rtl-optimization/34035] [4.3 Regression] ICE in calc_dfs_tree with -O2 -fnon-call-exceptions -ffast-math -fno-gcse

[ebotcazou at gcc dot gnu dot org]

--- Comment #8 from ebotcazou at gcc dot gnu dot org  2007-11-12 21:55 
---
The bug is nevertheless fixed.


-- 

ebotcazou at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||FIXED


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

[Bug c++/33468] [4.1/4.2/4.3 Regression] C++: Invalid interpretation of friendness with nested classes

[jason at gcc dot gnu dot org]

--- Comment #4 from jason at gcc dot gnu dot org  2007-11-12 22:05 ---
Not a bug under DR 45.


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID


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

[Bug c++/34073] overloaded template function resolves differently if one type is included in a namespace

[adl at gnu dot org]

--- Comment #4 from adl at gnu dot org  2007-11-12 22:08 ---
Thank you for the very clear explanation, Andrew.

Indeed, adding a "namespace algebra" around the second definition of
op_is_finite() will solve my problem.


-- 


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

[Bug fortran/34067] [4.3 regression] gfortran.dg/char_cshift_2.f90 fails with -O3 -funroll-loops fails on Intel Darwin

[dominiq at lps dot ens dot fr]

--- Comment #5 from dominiq at lps dot ens dot fr  2007-11-12 22:23 ---
The regression was caused by revision 130043:

PR rtl-optimization/34012
* fwprop.c (try_fwprop_subst): Do not replace if the new
SET_SRC has a higher cost than the old one.

* gcc.target/i386/pr34012.c: New test.

If I revert it, the failures disappear.


-- 

dominiq at lps dot ens dot fr changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu dot org


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

[Bug target/34067] [4.3 regression] gfortran.dg/char_cshift_2.f90 fails with -O3 -funroll-loops fails on Intel Darwin

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org
  Component|fortran |target
   Target Milestone|--- |4.3.0


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

[Bug c++/29225] [4.0/4.1/4.2/4.3 regression] ICE in gimplify_expr, at gimplify.c:4513

[jakub at gcc dot gnu dot org]

--- Comment #8 from jakub at gcc dot gnu dot org  2007-11-12 23:17 ---
Subject: Bug 29225

Author: jakub
Date: Mon Nov 12 23:17:18 2007
New Revision: 130126

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130126
Log:
PR c++/29225
* call.c (build_new_op): Call resolve_args before calling
build_over_call.

* g++.dg/template/crash72.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/template/crash72.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/call.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug c++/29225] [4.0/4.1/4.2 regression] ICE in gimplify_expr, at gimplify.c:4513

[jakub at gcc dot gnu dot org]

--- Comment #9 from jakub at gcc dot gnu dot org  2007-11-12 23:23 ---
Fixed on the trunk so far.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|[4.0/4.1/4.2/4.3 regression]|[4.0/4.1/4.2 regression] ICE
   |ICE in gimplify_expr, at|in gimplify_expr, at
   |gimplify.c:4513 |gimplify.c:4513


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

[Bug middle-end/29478] [4.2 Regression] optimization generates warning for casts

[manu at gcc dot gnu dot org]

--- Comment #28 from manu at gcc dot gnu dot org  2007-11-13 01:15 ---
(In reply to comment #26)
> (In reply to comment #25)
> > 
> > ... but the audit trail suggests otherwise.  :S
> > 
> 
> Ok, now I'm confused :-)
> 

Mark does not actually read the full list of messages when changing the target
milestone. I think this should be closed as WONTFIX since there is no easy way
to fix this for 4.2 but it is fixed in 4.3. As a workaround, you should be able
to use -Wno-cast-qual to avoid the warning. 

I don't remember if 4.2 supports -Wno-error=cast-qual. If it does, you can
still get the warning as a warning even when using -Werror.


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WONTFIX


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

[Bug c/32528] -save-temps when compiling standard input fails

[manu at gcc dot gnu dot org]

--- Comment #1 from manu at gcc dot gnu dot org  2007-11-13 03:27 ---
This is confirmed. I think the problem is in the specs in gcc.c:

   %{!combine:\
  %{save-temps|traditional-cpp|no-integrated-cpp:%(trad_capable_cpp) \
%(cpp_options) -o %{save-temps:%b.i} %{!save-temps:%g.i} \n\
cc1 -fpreprocessed %{save-temps:%b.i} %{!save-temps:%g.i} \
%(cc1_options)}\
  %{!save-temps:%{!traditional-cpp:%{!no-integrated-cpp:\


when cc1 -fpreprocessed %{save-temps:%b.i} is expanded to cc1 -fpreprocessed
-.i

No idea how this can be fixed without a "--" or an "--input" option.


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||manu at gcc dot gnu dot org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-11-13 03:27:26
   date||


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

[Bug fortran/31608] wrong types in character array/scalar binop

[jvdelisle at gcc dot gnu dot org]

--- Comment #56 from jvdelisle at gcc dot gnu dot org  2007-11-13 03:46 
---
On x86-64-linux-gnu the only failure I could find using
--enable-checking=yes,types was achar_4.f90.

achar_4.f90: In function ‘up’:
achar_4.f90:8: error: non-trivial conversion at assignment
char[1:1]
char
(*D.1000)[S.24] = D.1018
achar_4.f90:8: internal compiler error: verify_gimple failed


-- 


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

[Bug middle-end/21579] memory overflow

[manu at gcc dot gnu dot org]

--- Comment #1 from manu at gcc dot gnu dot org  2007-11-13 03:54 ---
Please, submit a preprocessed testcase with a recent version of GCC.


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug translation/26987] German translation of gcc 4.1

[manu at gcc dot gnu dot org]

--- Comment #7 from manu at gcc dot gnu dot org  2007-11-13 04:12 ---
Is this still valid?


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug other/29972] typos in the manual

[manu at gcc dot gnu dot org]

--- Comment #5 from manu at gcc dot gnu dot org  2007-11-13 04:17 ---
Has this patch been applied? If not, please send it to gcc-patches.


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug other/29972] typos in the manual

[manu at gcc dot gnu dot org]

--- Comment #6 from manu at gcc dot gnu dot org  2007-11-13 04:36 ---
Most of the typos are gone. And updated patch:

Index: gcc/doc/passes.texi
===
--- gcc/doc/passes.texi (revision 130092)
+++ gcc/doc/passes.texi (working copy)
@@ -490,7 +490,7 @@
 @item Folding built-in functions

 This pass simplifies built-in functions, as applicable, with constant
-arguments or with inferrable string lengths.  It is located in
+arguments or with inferable string lengths.  It is located in
 @file{tree-ssa-ccp.c} and is described by @code{pass_fold_builtins}.

 @item Split critical edges
Index: gcc/doc/invoke.texi
===
--- gcc/doc/invoke.texi (revision 130092)
+++ gcc/doc/invoke.texi (working copy)
@@ -1786,7 +1786,7 @@
 of the language, you can save some space by using this flag.  Note that
 exception handling uses the same information, but it will generate it as
 needed. The @samp{dynamic_cast} operator can still be used for casts that
-do not require runtime type information, i.e. casts to @code{void *} or to
+do not require runtime type information, i.e., casts to @code{void *} or to
 unambiguous base classes.

 @item -fstats
@@ -6716,7 +6716,7 @@
 For small units this might be too tight (consider unit consisting of function
A
 that is inline and B that just calls A three time.  If B is small relative to
 A, the growth of unit is 300\% and yet such inlining is very sane.  For very
-large units consisting of small inlininable functions however the overall unit
+large units consisting of small inlineable functions however the overall unit
 growth limit is needed to avoid exponential explosion of code size.  Thus for
 smaller units, the size is increased to @option{--param large-unit-insns}
 before applying @option{--param inline-unit-growth}.  The default is 1
@@ -7077,7 +7077,7 @@
 @item integer-share-limit
 Small integer constants can use a shared data structure, reducing the
 compiler's memory usage and increasing its speed.  This sets the maximum
-value of a shared integer constant's.  The default value is 256.
+value of a shared integer constant.  The default value is 256.

 @item min-virtual-mappings
 Specifies the minimum number of virtual mappings in the incremental
@@ -7092,7 +7092,7 @@
 ratio is 3.

 @item ssp-buffer-size
-The minimum size of buffers (i.e. arrays) that will receive stack smashing
+The minimum size of buffers (i.e., arrays) that will receive stack smashing
 protection when @option{-fstack-protection} is used.

 @item max-jump-thread-duplication-stmts
@@ -10049,7 +10049,7 @@
 @option{--with-ld} configure option, GCC's program search path, and
 finally by the user's @env{PATH}.  The linker used by GCC can be printed
 using @samp{which `gcc -print-prog-name=ld`}.  This option is only available
-on the 64 bit HP-UX GCC, i.e. configured with @samp{hppa*64*-*-hpux*}.
+on the 64 bit HP-UX GCC, i.e., configured with @samp{hppa*64*-*-hpux*}.

 @item -mhp-ld
 @opindex hp-ld
@@ -10062,7 +10062,7 @@
 configure option, GCC's program search path, and finally by the user's
 @env{PATH}.  The linker used by GCC can be printed using @samp{which
 `gcc -print-prog-name=ld`}.  This option is only available on the 64 bit
-HP-UX GCC, i.e. configured with @samp{hppa*64*-*-hpux*}.
+HP-UX GCC, i.e., configured with @samp{hppa*64*-*-hpux*}.

 @item -mlong-calls
 @opindex mno-long-calls
@@ -10219,16 +10219,16 @@
 @item k6
 AMD K6 CPU with MMX instruction set support.
 @item k6-2, k6-3
-Improved versions of AMD K6 CPU with MMX and 3dNOW! instruction set support.
+Improved versions of AMD K6 CPU with MMX and 3dNOW!@: instruction set support.
 @item athlon, athlon-tbird
-AMD Athlon CPU with MMX, 3dNOW!, enhanced 3dNOW! and SSE prefetch instructions
+AMD Athlon CPU with MMX, 3dNOW!, enhanced 3dNOW!@: and SSE prefetch
instructions
 support.
 @item athlon-4, athlon-xp, athlon-mp
-Improved AMD Athlon CPU with MMX, 3dNOW!, enhanced 3dNOW! and full SSE
+Improved AMD Athlon CPU with MMX, 3dNOW!, enhanced 3dNOW!@: and full SSE
 instruction set support.
 @item k8, opteron, athlon64, athlon-fx
 AMD K8 core based CPUs with x86-64 instruction set support.  (This supersets
-MMX, SSE, SSE2, 3dNOW!, enhanced 3dNOW! and 64-bit instruction set
extensions.)
+MMX, SSE, SSE2, 3dNOW!, enhanced 3dNOW!@: and 64-bit instruction set
extensions.)
 @item k8-sse3, opteron-sse3, athlon64-sse3
 Improved versions of k8, opteron and athlon64 with SSE3 instruction set
support.
 @item amdfam10, barcelona
@@ -10239,10 +10239,10 @@
 IDT Winchip C6 CPU, dealt in same way as i486 with additional MMX instruction
 set support.
 @item winchip2
-IDT Winchip2 CPU, dealt in same way as i486 with additional MMX and 3dNOW!
+IDT Winchip2 CPU, dealt in same way as i486 with additional MMX and 3dNOW!@:
 instruction set support.
 @item c3
-Via C3 CPU with MMX and 3dNOW! instruction set support.  (No scheduling is
+Via C3 CPU with MM

[Bug translation/26987] German translation of gcc 4.1

[stigge at antcom dot de]

--- Comment #8 from stigge at antcom dot de  2007-11-13 04:38 ---
Fixed now. Thanks for your care.


-- 


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

Modulo operation in C for -ve values

[Deepak Gaur]

The Modulo operation as specified in
http://xenia.media.mit.edu/~bdenckla/thesis/texts/htthe/node13.html says that
for a fraction like n/k which can be expressed as n/k = i + j/k the C division
and mod operation should yeild
n div k = i (integer part)
n mod k = j (remainder part)
For n +ve above is true
For n -ve
-n/k = -i + j/k
-n div k = -i
-n mod k = j (+ve remainder)

But running a sample program on Redhat enterprise Linux EL4
with libc-2.3.4 gcc version 3.4.3 20041212 (Red Hat 3.4.3-9.EL4)
#include 
#include 
#include 
int main()
{
int n,k,j;
n=-3;
k=8;
j=(n/k);
printf("\n n div k %d", j);
j=(n%k);
printf("\n n mod k %d", j);
}
gives following output for n = -3 k = 8
n div k 0
n mod k  -3
though it should have been as per hypothesis proposed in
http://xenia.media.mit.edu/~bdenckla/thesis/texts/htthe/node13.html
n div k -1
n mod k  5

Which is correct(0,-3) or (-1,5)?

Thanks

Deepak Gaur
--- End of Forwarded Message ---


Deepak Gaur

[Bug translation/26987] German translation of gcc 4.1

[manu at gcc dot gnu dot org]

--- Comment #9 from manu at gcc dot gnu dot org  2007-11-13 04:41 ---
Thanks to you!


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||FIXED


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