Bugzilla administrator

[Jarl Friis]

Can anyone here tell me who is (and the email of) the GCC bugzilla
administrator 

Thanks in advance.

Jarl

[Bug fortran/30783] New: "character(*), value" produces SEGV at runtime

[burnus at gcc dot gnu dot org]

The combination of the VALUE attribute with CHARACTER(*) gives segmentation
faults (SIGSEGV, SIGBUS). Without VALUE or with "CHARACTER(10), VALUE" it
works.

-- Test case 
program x
  implicit none
  character(10) :: c
  c = 'Main'
  print *, c
  call foo(c)
  print *, c
contains
  subroutine foo(a)
character(*) :: a
value :: a
print *, 'Foo: ',a
a = 'Hello'
print *, 'Foo: ',a
  end subroutine foo
end program x
-- Test case 

I don't know whether it can be made to work, if not, one could do something
like   Chris does in the Fortran-Experiments branch (except of only disallowing
the length "*"):

  /* Character strings are a hassle because they may be length 1,
 or assumed length (*), etc., so we need to find a way to
 prevent by-value dummy char args from being anything but
 length 1 constants, because C will only pass a pointer in
 any other cases.  However, we can't help the following with the
 logic being used below:
 character(c_char), value :: my_char
 character(kind=c_char, len=1), value :: my_char_str
 hope the user does the right thing.  */
 if (sym->attr.value == 1 && sym->ts.type == BT_CHARACTER)
   /* if we can't verify the length of 1...error */
   if (sym->ts.cl == NULL || sym->ts.cl->length == NULL
   || (sym->ts.cl->length->value.character.length != 1))
 gfc_error_now ("VALUE attribute at %L cannot be used "
"for character strings", &(sym->declared_at));


-- 
   Summary: "character(*), value" produces SEGV at runtime
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org


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

[Bug fortran/29975] [meta-bugs] ICEs with CP2K

[jv244 at cam dot ac dot uk]

--- Comment #60 from jv244 at cam dot ac dot uk  2007-02-13 09:20 ---
> When you have a moment, could you confirm that all is now well with trunk,
> please? Once again, I am sorry about the breakage.  Now I see Daniel's
> testcase, I realise that I could easily have devised a test... with 20:20
> hindsight:)
Yes, current trunk compiles CP2K again at -O0 (still blocked by PR 30391 at
-O1). No need to apologize, I realize that many of the change you make fall
into the 'subtle' category and do not pop-up with the normal regtesting. As
said before, I'm, unfortunately, used to the fact that even good commercial
compilers (say NAG's f95, IBM's xlf90, Intel's ifort) regress on CP2K from time
to time. It is very annoying to have to fight compilers, after the computer
center upgraded a machine. My hope is that CP2K being freely available (even in
a handy single file format, see initial comment) could prevent this from
happening. Ultimately, I want to see some runtime regression tester... maybe I
should try to get CP2K in a future version of SPEC ... any hints on how to do
that ??


-- 


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

[Bug target/30778] [4.3 Regression] invalid code generation for memset() with -mtune=k8

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2007-02-13 09:43 ---
Confirmed.


-- 

rguenth 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-02-13 09:43:50
   date||


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

[Bug fortran/30783] "character(*), value" produces SEGV at runtime

[dominiq at lps dot ens dot fr]

--- Comment #1 from dominiq at lps dot ens dot fr  2007-02-13 09:54 ---
Compiling the test with xlf gives:

"pr30783.f90", line 6.12: 1513-061 (S) Actual argument attributes do not match
those specified by an accessible explicit interface.
"pr30783.f90", line 11.14: 1516-181 (S) Objects of type CHARACTER with length
greater than 1, with run time length, or with assumed length must not be
declared with the VALUE attribute.

and with g95

Error: Character dummy variable 'a' at (1) with the VALUE attribute must have a
constant length


-- 


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

[Bug rtl-optimization/29841] [4.2/4.3 regression] ICE with scheduling and __builtin_trap

[patchapp at dberlin dot org]

--- Comment #17 from patchapp at dberlin dot org  2007-02-13 10:15 ---
Subject: Bug number PR rtl-optimization/29841

A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-02/msg01134.html


-- 


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

[Bug middle-end/30784] New: ICE on loop vectorization (-O1 -march=athlon-xp -ftree-vectorize)

[fxcoudert at gcc dot gnu dot org]

$ cat a.c
void foo(void)
{
  static int irows[5];
  int i;

  for (i = 1; i < 1000; i++)
irows[i-1] = i;
}

$ gcc -c -O1 -march=athlon-xp -ftree-vectorize a.c
a.c: In function ‘foo’:
a.c:8: internal compiler error: in expand_simple_binop, at optabs.c:1192
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.

$ gcc -v  
Using built-in specs.
Target: i386-pc-linux-gnu
Configured with: /home/fxcoudert/gfortran_nightbuild/trunk/configure
--prefix=/home/fxcoudert/gfortran_nightbuild/irun-20070209
--enable-languages=c,fortran --host=i386-pc-linux-gnu --enable-checking=release
--with-gmp=/home/fxcoudert/gfortran_nightbuild/software
Thread model: posix
gcc version 4.3.0 20070209 (experimental)


The original bug report (http://gcc.gnu.org/ml/fortran/2007-02/msg00288.html)
was about the follow Fortran code:

  subroutine gaussj2_cvb(n)
  dimension irows(n)
  do 100 i=1,n
100   irows(i)=i
  end

When someone fixes this, can you verify that the ICE is also gone on the
Fortran code (same optimization options)?


-- 
   Summary: ICE on loop vectorization (-O1 -march=athlon-xp -ftree-
vectorize)
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: fxcoudert at gcc dot gnu dot org
 GCC build triplet: i386-pc-linux-gnu
  GCC host triplet: i386-pc-linux-gnu
GCC target triplet: i386-pc-linux-gnu


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

[Bug middle-end/30784] ICE on loop vectorization (-O1 -march=athlon-xp -ftree-vectorize)

[fxcoudert at gcc dot gnu dot org]

-- 

fxcoudert 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-02-13 10:27:36
   date||


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

[Bug target/30784] ICE on loop vectorization (-O1 -march=athlon-xp -ftree-vectorize)

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2007-02-13 10:33 ---
This works fine with me on powerpc-darwin with -O1 -ftree-vectorize -maltivec 
plus the loop was vectorized also.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

  Component|middle-end  |target


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

[Bug target/30052] possible quadratic behaviour.

[pluto at agmk dot net]

--- Comment #9 from pluto at agmk dot net  2007-02-13 10:37 ---
(In reply to comment #8)
> Does this work on mainline with no real issue?
> 
> If so, i'll try to backport the solver changes.
> 

gcc43 works faster, but still needs lot of memory.

(...)
 tree PTA  :   1.33 ( 2%) usr   0.01 ( 1%) sys   1.41 ( 2%) wall  
10753 kB ( 2%) ggc
 tree alias analysis   :  14.10 (21%) usr   0.08 ( 8%) sys  14.75 (21%) wall  
55882 kB (10%) ggc
(...)
 TOTAL :  68.67 1.0371.55
537971 kB

btw.
sipQtGuipart0.ii from PyQt-x11-gpl-4.1.1 needs over 1GB of ram at -O1 :(


-- 


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

[Bug c/30785] New: Test to null pointer optimised away at -O2

[etienne_lorrain at yahoo dot fr]

$ cat tmp.c
typedef unsigned size_t;
char *xxcpy(  char *pDest, const char *pSrc, size_t n);
char *strncpy(  char *pDest, const char *pSrc, size_t n) {
  if (pDest == 0 || pSrc == 0) {
  if (pDest)
  *pDest = 0;
  return pDest;
  }
  return xxcpy (pDest, pSrc, n);
  }
$ powerpc-eabi-gcc -Wall -S tmp.c -o tmp.s -O2 -mcpu=440
$ cat tmp.s .file   "tmp.c"
.section".text"
.align 2
.globl strncpy
.type   strncpy, @function strncpy: stwu 1,-8(1)
mflr 0
stw 0,12(1)
bl xxcpy
lwz 0,12(1)
addi 1,1,8
mtlr 0
blr
.size   strncpy, .-strncpy
.ident  "GCC: (GNU) 4.1.1"
$ powerpc-eabi-gcc -Wall -S tmp.c -o tmp.s -O1 -mcpu=440
$ cat tmp.s .file   "tmp.c"
.section".text"
.align 2
.globl strncpy
.type   strncpy, @function strncpy: stwu 1,-8(1)
mflr 0
stw 0,12(1)
cmpwi 0,3,0
beq- 0,.L2
cmpwi 7,4,0
bne+ 7,.L4
stb 4,0(3)
b .L2 .L4: bl xxcpy .L2: lwz 0,12(1)
mtlr 0
addi 1,1,8
blr
.size   strncpy, .-strncpy
.ident  "GCC: (GNU) 4.1.1"
$ powerpc-eabi-gcc -v
Using built-in specs.
Target: powerpc-eabi Configured with: ../gcc-4.1.1/configure
--target=powerpc-eabi --with-cpu=440 --enable-languages=c,c++
Thread model: single
gcc version 4.1.1 

  Seems quite clear some optimisation assumes pointers cannot be null.
  Is there a flag to disable this option?
  Thanks,
  Etienne.


-- 
   Summary: Test to null pointer optimised away at -O2
   Product: gcc
   Version: 4.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: etienne_lorrain at yahoo dot fr
 GCC build triplet: i686-pc-cygwin
  GCC host triplet: i686-pc-cygwin
GCC target triplet: powerpc-eabi


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

[Bug target/30784] ICE on loop vectorization (-O1 -march=athlon-xp -ftree-vectorize)

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2007-02-13 12:48 ---
I get

./cc1 -quiet -O -march=athlon-xp -m32 -ftree-vectorize x.i
x.i: In function 'foo':
x.i:2: error: invalid reference prefix
{4, 4, 4, 4}

x.i:2: error: invalid reference prefix
{4, 4, 4, 4}

x.i:2: error: invalid reference prefix
{4, 4, 4, 4}

x.i:2: error: invalid reference prefix
{4, 4, 4, 4}

x.i:2: internal compiler error: verify_stmts failed
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.

After vectorization:

:
  stmp_var_.29_22 = 2;
  stmp_var_.30_23 = stmp_var_.29_22 + 1;
  stmp_var_.31_24 = stmp_var_.30_23 + 1;
  vect_cst_.32_25 = {1, stmp_var_.29_22, stmp_var_.30_23, stmp_var_.31_24};
  vect_cst_.33_26 = {4, 4, 4, 4};
  vect_pirows.39_29 = (vector int *) &irows;
  vect_pirows.35_30 = vect_pirows.39_29;

  # ivtmp.41_33 = PHI 
  # ivtmp.40_31 = PHI 
  # vect_vec_iv_.34_27 = PHI 
  # ivtmp.25_1 = PHI 
  # i_10 = PHI 
:;
  D.1842_3 = i_10 + -1;
  vect_vec_iv_.34_28 = vect_vec_iv_.34_27 + vect_cst_.33_26;
  *ivtmp.40_31 = vect_vec_iv_.34_27;
  i_4 = i_10 + 1;
  ivtmp.25_5 = ivtmp.25_1 - 1;
  ivtmp.40_32 = ivtmp.40_31 + 16B;
  ivtmp.41_34 = ivtmp.41_33 + 1;
  if (ivtmp.41_34 < 249) goto ; else goto ;

(looks good)

but then veclower does

  # ivtmp.41_33 = PHI 
  # ivtmp.40_31 = PHI 
  # vect_vec_iv_.34_27 = PHI 
  # ivtmp.25_1 = PHI 
  # i_10 = PHI  
:;
  D.1842_3 = i_10 + -1;
  D.1899_20 = BIT_FIELD_REF ;
  D.1900_19 = BIT_FIELD_REF ;
  D.1901_17 = D.1899_20 + D.1900_19;
  D.1902_35 = BIT_FIELD_REF ;
  D.1903_36 = BIT_FIELD_REF ;
  D.1904_37 = D.1902_35 + D.1903_36;
  D.1905_38 = BIT_FIELD_REF ;
  D.1906_39 = BIT_FIELD_REF ;
  D.1907_40 = D.1905_38 + D.1906_39;
  D.1908_41 = BIT_FIELD_REF ;
  D.1909_42 = BIT_FIELD_REF ;
  D.1910_43 = D.1908_41 + D.1909_42;
  vect_vec_iv_.34_28 = {D.1901_17, D.1904_37, D.1907_40, D.1910_43};
  *ivtmp.40_31 = vect_vec_iv_.34_27;
  i_4 = i_10 + 1;
  ivtmp.25_5 = ivtmp.25_1 - 1;
  ivtmp.40_32 = ivtmp.40_31 + 16B;
  ivtmp.41_34 = ivtmp.41_33 + 1;
  if (ivtmp.41_34 < 249) goto ; else goto ;

but then DOM const-props into the BIT_FIELD_REFs which confuses us:

  # ivtmp.44_8 = PHI 
  # vect_vec_iv_.34_27 = PHI 
:;
  D.1899_20 = BIT_FIELD_REF ;
  D.1900_19 = BIT_FIELD_REF <{4, 4, 4, 4}, 32, 0>;
  D.1901_17 = D.1899_20 + D.1900_19;
  D.1902_35 = BIT_FIELD_REF ;
  D.1903_36 = BIT_FIELD_REF <{4, 4, 4, 4}, 32, 32>;
  D.1904_37 = D.1902_35 + D.1903_36;
  D.1905_38 = BIT_FIELD_REF ;
  D.1906_39 = BIT_FIELD_REF <{4, 4, 4, 4}, 32, 64>;
  D.1907_40 = D.1905_38 + D.1906_39;
  D.1908_41 = BIT_FIELD_REF ;
  D.1909_42 = BIT_FIELD_REF <{4, 4, 4, 4}, 32, 96>;
  D.1910_43 = D.1908_41 + D.1909_42;
  vect_vec_iv_.34_28 = {D.1901_17, D.1904_37, D.1907_40, D.1910_43};
  MEM[symbol: irows, index: ivtmp.44_8] = vect_vec_iv_.34_27;
  ivtmp.44_45 = ivtmp.44_8 + 16;
  if (ivtmp.44_45 != 3984) goto ; else goto ;

so we fail to fold BIT_FIELD_REF <{4, 4, 4, 4}, 32, 96> to a constant for
example.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||law at redhat dot com,
   ||rguenth at gcc dot gnu dot
   ||org


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

[Bug c/30785] Test to null pointer optimised away at -O2

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2007-02-13 13:00 ---
I suppose this is done by the VRP pass (-f[no-]tree-vrp) so target independent.
 If so, this is fixed on current 4.1 branch.  Can you verify this indeed is
broken by VRP by looking at and before the vrp tree dumps? (-fdump-tree-all)


-- 


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

[Bug rtl-optimization/28772] scheduler is too slow and O(n^2) for ia64

[patchapp at dberlin dot org]

--- Comment #5 from patchapp at dberlin dot org  2007-02-13 13:20 ---
Subject: Bug number PR28772

A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-02/msg01137.html


-- 


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

[Bug bootstrap/30753] [4.3 Regression] checking for correct version of gmp.h... no

[drow at gcc dot gnu dot org]

--- Comment #7 from drow at gcc dot gnu dot org  2007-02-13 13:39 ---
Subject: Bug 30753

Author: drow
Date: Tue Feb 13 13:39:19 2007
New Revision: 121882

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=121882
Log:
PR bootstrap/30753
* configure.ac: Remove obsolete build / host tests.  Use AC_PROG_CC
unconditionally.  Use AC_PROG_CXX.  Use ACX_TOOL_DIRS to find $prefix.
* configure: Regenerated.

Modified:
trunk/ChangeLog
trunk/configure
trunk/configure.ac


-- 


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

[Bug bootstrap/30753] [4.3 Regression] checking for correct version of gmp.h... no

[drow at gcc dot gnu dot org]

--- Comment #8 from drow at gcc dot gnu dot org  2007-02-13 13:40 ---
Should be better now.


-- 

drow at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug c/30785] Test to null pointer optimised away at -O2

[etienne_lorrain at yahoo dot fr]

--- Comment #2 from etienne_lorrain at yahoo dot fr  2007-02-13 13:44 
---
 Problem is fixed by -fno-tree-vrp and -O2
 I am not a specialist of -fdump-tree-all, but it seems like that:
 tmp.c.t35.copyprop1:

;; Function strncpy (strncpy)

strncpy (pDest, pSrc, n)
{
  char * D.1282;
  char * D.1281;

:
  if (pDest_2 == 0B) goto ; else goto ;

:;
  if (pSrc_5 == 0B) goto ; else goto ;

:;
  if (pDest_2 != 0B) goto ; else goto ;

:;
  *pDest_2 = 0;

:;
  pDest_4 = pDest_2;
  goto  ();

:;
  pDest_7 = xxcpy (pDest_2, pSrc_5, n_6);
  pDest_8 = pDest_7;

  # pDest_1 = PHI ;
:;
  return pDest_1;

}
---
  tmp.t36.vrp, the test disappear:

;; Function strncpy (strncpy)


SSA replacement table
N_i -> { O_1 ... O_j } means that N_i replaces O_1, ..., O_j

pDest_12 -> { pDest_2 }
pDest_13 -> { pDest_2 }
pDest_14 -> { pDest_2 }
pDest_15 -> { pDest_2 }
pSrc_16 -> { pSrc_5 }

Number of virtual NEW -> OLD mappings:   0
Number of real NEW -> OLD mappings:  5
Number of total NEW -> OLD mappings: 5

Number of virtual symbols: 0


Incremental SSA update started at block: 0

Number of blocks in CFG: 9
Number of blocks to update: 9 (100%)




Value ranges after VRP:

pDest_1: VARYING
pDest_2: ~[0B, 0B]  EQUIVALENCES: { } (0 elements)
_3: VARYING
pSrc_5: ~[0B, 0B]  EQUIVALENCES: { } (0 elements)
pDest_7: VARYING
pDest_8: [pDest_7, pDest_7]  EQUIVALENCES: { pDest_7 } (1 elements)
pDest_15: ~[0B, 0B]  EQUIVALENCES: { pDest_2 } (1 elements)
pSrc_16: ~[0B, 0B]  EQUIVALENCES: { pSrc_5 } (1 elements)


Folding predicate pDest_2 == 0B to 0
Folding predicate pSrc_5 == 0B to 0
Folding predicate pDest_2 != 0B to 1
Removing basic block 7
Removing basic block 2
Removing basic block 8
Removing basic block 3
Removing basic block 4
Removing basic block 1
Merging blocks 0 and 5
Merging blocks 0 and 6
strncpy (pDest, pSrc, n)
{
  char * D.1282;
  char * D.1281;

:
  pDest_7 = xxcpy (pDest_2, pSrc_5, n_6);
  pDest_8 = pDest_7;
  return pDest_7;

}

  Thanks,
  Etienne.


-- 


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

[Bug fortran/29975] [meta-bugs] ICEs with CP2K

[pault at gcc dot gnu dot org]

--- Comment #61 from pault at gcc dot gnu dot org  2007-02-13 13:51 ---
(In reply to comment #60)

> Yes, current trunk compiles CP2K again at -O0 

Great!

> to time. It is very annoying to have to fight compilers, after the computer
> center upgraded a machine. My hope is that CP2K being freely available (even 
> in
> a handy single file format, see initial comment) could prevent this from
> happening.

I have been meaning to get ito into service, ever since you posted it.

Ultimately, I want to see some runtime regression tester... maybe I
> should try to get CP2K in a future version of SPEC ... any hints on how to do
> that ??

Apparently, you. offer it.

Paul


-- 


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

[Bug c/30785] Test to null pointer optimised away at -O2

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2007-02-13 13:57 ---
This is indeed fixed on the branch.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
  Known to fail||4.1.1 4.1.0
  Known to work||4.1.2 4.0.3
 Resolution||FIXED
   Target Milestone|--- |4.1.2


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

[Bug target/30222] gcc.target/i386/vectorize1.c ICEs

[Wolfgang_Lietz at t-online dot de]

--- Comment #3 from Wolfgang_Lietz at t-online dot de  2007-02-13 14:21 
---
Created an attachment (id=13046)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13046&action=view)
log file with compiler info and *.i

4.2.0 20070212
ICE found while running the test suite


-- 


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

[Bug preprocessor/30786] New: ICE on _Pragma at end of file

[truedfx at gentoo dot org]

Compiling or preprocessing a file that ends immediately after _Pragma leads to
an ICE:

:1:1: error: _Pragma takes a parenthesized string literal
:0: internal compiler error: Segmentation fault

Simply `echo _Pragma | cpp` is enough to show it.

I'm using gcc 4.1.1.


-- 
   Summary: ICE on _Pragma at end of file
   Product: gcc
   Version: 4.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: preprocessor
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: truedfx at gentoo dot org


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

[Bug c++/7302] -Wnon-virtual-dtor should't complain of protected dtor

[manu at gcc dot gnu dot org]

--- Comment #11 from manu at gcc dot gnu dot org  2007-02-13 15:12 ---
(In reply to comment #8)
> Created an attachment (id=11520)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11520&action=view) [edit]
> proposed patch (with doc and test changes)
> 

Thanks for the patch. However, formal submissions are sent to
[EMAIL PROTECTED] An attachment in bugzilla is not considered a formal
submission and it may go unnoticed. Please, consider submitting to
[EMAIL PROTECTED] (and perhaps also adding it to the patch queue:
http://www.dberlin.org/patchdirections.html )


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||manu at gcc dot gnu dot org


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

[Bug preprocessor/30786] ICE on _Pragma at end of file

[tromey at gcc dot gnu dot org]

--- Comment #1 from tromey at gcc dot gnu dot org  2007-02-13 15:55 ---
Confirmed, with svn head and the FC6 gcc 4.1.


-- 

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-02-13 15:55:12
   date||


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

[Bug rtl-optimization/28772] scheduler is too slow and O(n^2) for ia64

[ebotcazou at gcc dot gnu dot org]

--- Comment #6 from ebotcazou at gcc dot gnu dot org  2007-02-13 15:59 
---
The algorithm is O(n^2) in the number of ready insns at any given time in the
worst case.


-- 

ebotcazou at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-02-13 15:59:00
   date||


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

[Bug c++/7302] -Wnon-virtual-dtor should't complain of protected dtor

[ben at decadent dot org dot uk]

--- Comment #12 from ben at decadent dot org dot uk  2007-02-13 16:16 
---
Already posted as ,
with no response. 


-- 


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

[Bug target/30052] possible quadratic behaviour.

[dberlin at dberlin dot org]

--- Comment #10 from dberlin at gcc dot gnu dot org  2007-02-13 16:17 
---
Subject: Re:  possible quadratic behaviour.

On 13 Feb 2007 10:37:55 -, pluto at agmk dot net
<[EMAIL PROTECTED]> wrote:
>
>
> --- Comment #9 from pluto at agmk dot net  2007-02-13 10:37 ---
> (In reply to comment #8)
> > Does this work on mainline with no real issue?
> >
> > If so, i'll try to backport the solver changes.
> >
>
> gcc43 works faster, but still needs lot of memory.

Yeah, but you need to show me that the reason it needs a lot of memory
is due to pta:

>
> (...)
>  tree PTA  :   1.33 ( 2%) usr   0.01 ( 1%) sys   1.41 ( 2%) wall
> 10753 kB ( 2%) ggc
>  tree alias analysis   :  14.10 (21%) usr   0.08 ( 8%) sys  14.75 (21%) wall
> 55882 kB (10%) ggc
> (...)
>  TOTAL :  68.67 1.0371.55
> 537971 kB
>

Except that 55 meg and 10 meg of 512meg of gc memory is not a lot,
relatively speaking (It's not like it's 90% of the ggc memory or
something).

Also, alias analysis and PTA use heap memory that will not show up here.


-- 


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

[Bug libgcj/30606] [4.3 Regression] natVMURLConnection.cc:21: error: 'magic_t' does not name a typet name a type

[danglin at gcc dot gnu dot org]

--- Comment #10 from danglin at gcc dot gnu dot org  2007-02-13 16:17 
---
The R_CODE_ONE_SYMBOL error was caused by my inadvertantly using
an experimental (buggy) version of gas.  Closing PR as fixed.


-- 

danglin at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||FIXED
Summary|[4.3 Regression]|[4.3 Regression]
   |natVMURLConnection.cc:21:   |natVMURLConnection.cc:21:
   |error: 'magic_t' does not   |error: 'magic_t' does not
   |name a type |name a typet name a type
   |t name a type   |


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

[Bug rtl-optimization/30787] New: [4.1 Regression] Strength reduction bug

[jakub at gcc dot gnu dot org]

struct S
{
  int *s;
};

void
test (int x, struct S *y)
{
  int i;
  for (i = 0; i < x; i++)
{
  if (y)
y->s[i] += 1;
}
}

int
main ()
{
  test (1, (void *) 0);
  return 0;
}

is miscompiled at -O2 in 4.1.x, works with -O2 -fno-strength-reduction or
-O2 -floop-optimize2, works with 3.2.x, 3.4.x and 4.2.


-- 
   Summary: [4.1 Regression] Strength reduction bug
   Product: gcc
   Version: 4.1.2
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org
GCC target triplet: x86_64-linux, i?86-linux


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

[Bug rtl-optimization/30787] [4.1 Regression] Strength reduction bug

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2007-02-13 16:24 ---
Confirmed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
  Known to fail||4.1.2
  Known to work||4.2.0 3.4.6
   Last reconfirmed|-00-00 00:00:00 |2007-02-13 16:24:17
   date||


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

[Bug testsuite/30788] New: testsuite for libmudflap failed while using -DSTATIC

[Wolfgang_Lietz at t-online dot de]

All tests compiled with -DSTATIC failed while other passed 
FAIL: libmudflap.cth/pass37-frag.c (-static -DSTATIC) execution test
FAIL: libmudflap.cth/pass37-frag.c (-static -DSTATIC) output pattern test


-- 
   Summary: testsuite for libmudflap failed while using -DSTATIC
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Wolfgang_Lietz at t-online dot de
 GCC build triplet: pentiumpro-pc-linux-gnu
  GCC host triplet: pentiumpro-pc-linux-gnu
GCC target triplet: pentiumpro-pc-linux-gnu


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

[Bug c/16302] gcc fails to warn about some common logic errors

[manu at gcc dot gnu dot org]

--- Comment #8 from manu at gcc dot gnu dot org  2007-02-13 16:55 ---
I wish to answer this because I am also a newbie and I understand your
frustration. On the other hand, I also understand why the current situation is
as it is now.

(In reply to comment #2)
> It is not practical for gcc outsiders to submit patches,
> the requirements are too exacting and complex.  E.g. see
> http://gcc.gnu.org/ml/gcc-patches/2004-07/msg00072.html
> which demands a testcase (something which is IMO unclear
> in the "contributing" URL you gave).

The requirements are documented. Unfortunately, the documentation is divided
among many places and not in the best form. It would be superb and very welcome
if someone took the responsibility of summarizing, re-writting and improving
the different pieces, so they can be as clear and simple as possible. (Like a
step by step guide on how to contribute, maybe especialised for different
user-cases).

Sadly, experienced people don't have time (and perhaps are not very well
suited) for this job. Someone brave needs to step up and take the burden,
perhaps seek collaborators among other frustrated newbies.

Another problem is that as soon as a newbie becomes experienced with the
procedure, then the interest in improving the docs fades away :(

> It is unlikely my first (or second) attempt at a testcase
> will be flawless.

It doesn't matter, reviewers should catch any flaw and patches are regularly
submitted many times. It is part of the learning proccess. Flawless patches are
accepted earlier, though. ;-)

> Similarly, I am asked to document this warning
> (which I find odd, since there are lots of undocumented -Wextra warnings).
> Do I need to fix the "broken" existing warnings too?  The response was 
> unclear.

That is not an excuse. There are things that are historically wrong. New
mistakes cannot be justified based on past mistakes. New warnings should be
documented.

Normally, you don't need to fix anything that is broken already as long as it
is not closely related to your patch. 

If the response was unclear, you have to insist. No all mails are neccessarily
read by all people and people are busy busy busy (or on holidays), so sometimes
your mail will get lost. Wait one week and insist again. Wait another week and
keep insisting. Eventually someone will answer. Short and polite emails get
more answers than angry, long rants.

This also applies to patches. If you patch is not reviewed: wait one week and
insist. Repeat until reviewed.

> The only requirement I can confidently handle is fixing the warning strings.
> And are these *all* the requirements?  I doubt it.

It is very likely that if a reviewer finds an obvious mistake in your patch,
he/she will not review in deep the rest of it and just move on to the next
patch. You will need to send it again and wait for the answer. At first you
will make a lot of mistakes but that is normal. My first patch was rejected
several times just for the Changelog format. In a few iterations your patches
will be almost perfect.

> On the other hand, such issues are trivial for veterans such as yourself.
> Could you please handle this for me?  I would greatly appreciate it.

That is a sad misconception. Bootstrapping + testing take time even if there
are no failures at all. Adding testcases takes time. Having patches around
takes thinking time. Keeping track of submitted patches and pinging reviewers
take time. Fixing minor issues in patches takes time. Committing patches takes
also a  little amount of time. Of course, the total time could be trivial if
you had nothing else to do. But if the issue is minor and you are busy (or you
are not paid for fixing it and just prefer to invest your time in something
else like your family), then it is already too much time.

Also there is the issue (I guess) that if sloppy patches are regularly fixed by
reviewers, that will advocate more sloppy patches which in turn will make
reviewers more unwilling to review patches.

So please, reconsiderate your stance, and resubmit your patch. I am sure your
contribution will be appreciated.

Thanks in advance.


-- 


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

[Bug testsuite/30788] testsuite for libmudflap failed while using -DSTATIC

[Wolfgang_Lietz at t-online dot de]

--- Comment #1 from Wolfgang_Lietz at t-online dot de  2007-02-13 16:57 
---
Created an attachment (id=13047)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13047&action=view)
log file with compiler info and error message


-- 


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

[Bug c++/7302] -Wnon-virtual-dtor should't complain of protected dtor

[manu at gcc dot gnu dot org]

--- Comment #13 from manu at gcc dot gnu dot org  2007-02-13 17:19 ---
(In reply to comment #12)
> Already posted as ,
> with no response. 
> 

You need to insist. A week is normally considered an acceptable interval
between pings. You need to bootstrap + regression test.
http://gcc.gnu.org/contribute.html#testing

Short version:
make && make -k check 

Then, compare with the output without your patch.

What I normally do is, for an unpatched tree:
make && (make -k check &> pristine)

then patch and do the same saving the output in another file. Compare the two
outputs (there is a compare tests script in the contrib/ directory).

Of course, this is a very dirty and rough explanation. It is better to read the
docs.


-- 


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

[Bug fortran/30783] "character(*), value" produces SEGV at runtime

[burnus at gcc dot gnu dot org]

--- Comment #2 from burnus at gcc dot gnu dot org  2007-02-13 18:19 ---
>From the Fortran 2003 standard:
--
C528 (R501) If the VALUE attribute is specified, the length type parameter
values shall be omitted or specified by initialization expressions.
--

Which rules out deferred type parameters such as "*" or ":".

However, I fail to see anything which rules out "(10)" even though also sunf95
and NAG f95 claim that anything but nothing or "(1)" is wrong.

ifort and g95 allow "(10)" but crash or at least access uninitialized memory.

And as said: gfortran allows "(10)" and it works properly.


-- 


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

[Bug fortran/30783] "character(*), value" produces SEGV at runtime

[burnus at gcc dot gnu dot org]

-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |burnus at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-02-13 18:30:14
   date||


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

[Bug middle-end/30789] New: complex folding inexact

[jsm28 at gcc dot gnu dot org]

The constant folding of arithmetic on complex numbers is inexact and doesn't
support any of the C99 special cases and avoiding overflow done in libgcc.

Compile and run the following testcase with -std=c99.

#include 

int printf (const char *, ...);

#define C1 (DBL_MAX * 0.5 + DBL_MAX * 0.5i)
#define C2 (DBL_MAX * 0.25 + DBL_MAX * 0.25i)

_Complex double c1 = C1;
_Complex double c2 = C2;
_Complex double c = C1 / C2;

int
main (void)
{
  _Complex double cr = c1 / c2;
  printf ("%f %f\n%f %f\n", __real__ c, __imag__ c, __real__ cr, __imag__ cr);
  return 0;
}

It prints:

nan nan
2.00 0.00

That is, the libgcc code handled the division correctly, the folding allowed it
to overflow.

It should be reasonably straightforward to fold complex multiplication exactly
using MPFR: compute ac and bd with results in double the input precision, then
compute ac-bd with result in the original input precision (so rounding just
once to that precision) and similarly with the imaginary part.  Getting
division exact (correctly rounded) may be trickier, but doing better than at
present should be straightforward (simply by taking advantage of the greater
exponent range in MPFR).  The folding code also needs to handle the C99 Annex G
special cases like the libgcc code does.


-- 
   Summary: complex folding inexact
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jsm28 at gcc dot gnu dot org


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

[Bug target/19087] Overflowed address in dwarf debug line information

[eweddington at cso dot atmel dot com]

--- Comment #29 from eweddington at cso dot atmel dot com  2007-02-13 19:00 
---
Can a bug master please close this bug as fixed?

Thanks
Eric Weddington


-- 


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

[Bug target/30406] ICE in LOGICAL(8) functions

[fxcoudert at gcc dot gnu dot org]

--- Comment #34 from fxcoudert at gcc dot gnu dot org  2007-02-13 19:04 
---
(In reply to comment #32)
> This was on my list of patches to submit today really, I finally actually got
> time to able to submit patches today.  I was able to submit two other patches
> today and I have another one in testing right now.

Patch approved here: http://gcc.gnu.org/ml/gcc-patches/2007-02/msg01053.html,
but I'm in no position to commit now (until March 5th).


-- 


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

[Bug target/27386] AVR: wrong code generated when passing three uint64_t arguments to function

[eweddington at cso dot atmel dot com]

--- Comment #9 from eweddington at cso dot atmel dot com  2007-02-13 19:12 
---
5 months later and this bug still needs to be marked as NEW. Will a bug master
please do this?


-- 


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

[Bug bootstrap/30790] New: [4.3 regression] Bootstrap comparison failure i386:

[gerald at pfeifer dot com]

Both on FreeBSD and GNU/Linux, bootstrap is broken on i386.

Comparing stages 2 and 3
warning: ./cc1-checksum.o differs
warning: ./cc1plus-checksum.o differs
warning: ./cc1obj-checksum.o differs
Bootstrap comparison failure!
./cp/call.o differs
./cp/expr.o differs
./cp/decl.o differs
./cp/typeck2.o differs


-- 
   Summary: [4.3 regression] Bootstrap comparison failure i386:
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gerald at pfeifer dot com
  GCC host triplet: i386-suse-linux, i386-unknown-freebsd5.4


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

[Bug bootstrap/30790] [4.3 regression] Bootstrap comparison failure i386:

[gerald at pfeifer dot com]

-- 

gerald at pfeifer dot com changed:

   What|Removed |Added

   Severity|normal  |blocker
Summary|[4.3 regression] Bootstrap  |[4.3 regression] Bootstrap
   |comparison failure i386:|comparison failure i386:


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

[Bug fortran/29975] [meta-bugs] ICEs with CP2K

[kargl at gcc dot gnu dot org]

--- Comment #62 from kargl at gcc dot gnu dot org  2007-02-13 19:50 ---
(In reply to comment #48)
> Currently, there is a new ICE on CP2K (see initial comment) that happens at 
> any
> optimisation level:
> 
> > gfortran -c all_cp2k_gfortran.f90
> all_cp2k_gfortran.f90:118549: 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.
> 
> this is a new regression. I really think CP2K should be added to some nightly
> tester somewhere by gfortran developers...

Well, I'd add it to my testsuite if weren't a PITA to figure out how to
make it build.

troutmask:sgk[246] tools/get_arch_code
###
have a look at cp2k/tools/get_arch_code
your system is a FreeBSD-FreeBSD 7.0-CURRENT #1: Fri Feb  9 12:01:52 PST 2007  
  [EMAIL PROTECTED]:/usr/obj/usr/src/sys/SPEW
-7.0-CURRENT-amd64
but get_arch_code is not able to deal with that 

unknown


-- 


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

[Bug tree-optimization/30791] New: Need to run may-alias early in IPA

[dnovillo at gcc dot gnu dot org]

Without aliasing information some passes and cleanups cannot be scheduled
early.  See http://gcc.gnu.org/ml/gcc-patches/2007-02/msg01176.html


-- 
   Summary: Need to run may-alias early in IPA
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: dnovillo at gcc dot gnu dot org
ReportedBy: dnovillo at gcc dot gnu dot org


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

[Bug fortran/29975] [meta-bugs] ICEs with CP2K

[jv244 at cam dot ac dot uk]

--- Comment #63 from jv244 at cam dot ac dot uk  2007-02-13 20:04 ---
> Well, I'd add it to my testsuite if weren't a PITA to figure out how to
> make it build.

wget http://www.pci.unizh.ch/vandevondele/tmp/all_cp2k_gfortran.f90.gz
gunzip all_cp2k_gfortran.f90.gz
gfortran -c all_cp2k_gfortran.f90


-- 


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

[Bug rtl-optimization/30787] [4.1 Regression] Strength reduction bug

[ebotcazou at gcc dot gnu dot org]

--- Comment #2 from ebotcazou at gcc dot gnu dot org  2007-02-13 20:13 
---
Too bad 4.1.2 is being packaged...  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
  Known to fail|4.1.2   |4.1.1 4.1.2
   Last reconfirmed|2007-02-13 16:24:17 |2007-02-13 20:13:14
   date||


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

[Bug rtl-optimization/30643] CSE regression

[janis at gcc dot gnu dot org]

--- Comment #1 from janis at gcc dot gnu dot org  2007-02-13 20:37 ---
Dan requested a regression hunt for this.  An i686-linux cross compiler starts
failing with this mainline patch:

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

r115614 | pbrook | 2006-07-20 13:57:31 + (Thu, 20 Jul 2006)

For powerpc-linux there are no calls to abort.


-- 

janis at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||pbrook at gcc dot gnu dot
   ||org


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

[Bug target/30757] [4.3 Regression] ICE with -march=athlon-xp -mfpmath=sse

[stuart at apple dot com]

--- Comment #4 from stuart at apple dot com  2007-02-13 21:00 ---
Committed a fix:

http://gcc.gnu.org/ml/gcc-patches/2007-02/msg01171.html


-- 


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

[Bug fortran/30779] incomplete file triggers ICE

[pault at gcc dot gnu dot org]

--- Comment #3 from pault at gcc dot gnu dot org  2007-02-13 21:00 ---
Jerry is our expert on this side of things.  Although he has said that he is in
temporary hiding from gfortran, I have CC'd him:)

Paul


-- 

pault at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||pault at gcc dot gnu dot org


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

[Bug middle-end/30751] [4.3 Regression] internal compiler error: in extract_insn, at recog.c:2108

[ian at gcc dot gnu dot org]

--- Comment #5 from ian at gcc dot gnu dot org  2007-02-13 22:18 ---
Subject: Bug 30751

Author: ian
Date: Tue Feb 13 22:18:26 2007
New Revision: 121894

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=121894
Log:
PR middle-end/30751
* lower-subreg.c (resolve_simple_move): Decompose subregs in
addresses.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/lower-subreg.c


-- 


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

[Bug middle-end/30751] [4.3 Regression] internal compiler error: in extract_insn, at recog.c:2108

[ian at airs dot com]

--- Comment #6 from ian at airs dot com  2007-02-13 22:22 ---
Fixed.  Thanks for reporting it.


-- 

ian at airs dot com changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug middle-end/30391] [4.3 regression] ICE at -O1 with conditional expressions and GIMPLE_MODIFY_STMT

[sandra at codesourcery dot com]

--- Comment #8 from sandra at codesourcery dot com  2007-02-14 00:04 ---
Testing of the CALL_EXPR representation patch turned up a related ICE in
tree_ssa_useless_type_conversion() while compiling
libjava/java/lang/reflect/natMethod.cc.  It was failing because the expansion
of memcpy produced by fold_builtin_memory_op includes a GIMPLE_MODIFY_STMT, and
expansion of builtins happens long before the gimplifier is invoked by the C++
front end.  See http://gcc.gnu.org/ml/gcc-patches/2007-02/msg01193.html for
more discussion.

As a temporary solution, the CALL_EXPR patch includes a tweak to use
GENERIC_TREE_TYPE in tree_ssa_useless_type_conversion().  This should be
revisited as part of a general solution.


-- 


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

[Bug libfortran/30780] cpu_time produces a floating point exception when used with -O0

[jvdelisle at gcc dot gnu dot org]

--- Comment #7 from jvdelisle at gcc dot gnu dot org  2007-02-14 00:37 
---
OK, then there is a similar, not necessarily related problem in write.c.


-- 


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

[Bug fortran/30779] incomplete file triggers ICE

[jvdelisle at gcc dot gnu dot org]

--- Comment #4 from jvdelisle at gcc dot gnu dot org  2007-02-14 00:43 
---
I'll give it a go.  Just be patient please. :)


-- 

jvdelisle at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jvdelisle at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2007-02-12 19:29:56 |2007-02-14 00:43:31
   date||


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

[Bug gcov-profile/30650] [4.3 Regression] ICE with -fprofile-use

[hubicka at gcc dot gnu dot org]

--- Comment #9 from hubicka at gcc dot gnu dot org  2007-02-14 01:24 ---
Hi,
the reason is -msse3 that is supposed to be at both invocations.  -msse3
enables the SSE builtins that do change declarations UIDs that in turn changes
function names:
< ;; Function ddx (ddx.1401)
---
> ;; Function ddx (ddx.1390)
so profiles can't match.  While it is possible to ignore the SSA names, I don't
think there is actual need to mess with this - the use of different swtiches
that do affect input language clearly can't be much accepted in between train
and compilation run
(I am hoping that optimization switches like -funroll-loops will run, but for
language features, like SSE is we will get different divergences anyway)

The other problem was fixed, so I am closing the PR.
Honza


-- 

hubicka at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug middle-end/30768] [4.3 regression]: ICE in ext/pb_ds/regression/list_update_data_map_rand.cc

[hp at gcc dot gnu dot org]

--- Comment #6 from hp at gcc dot gnu dot org  2007-02-14 05:08 ---
Identical failure also seen for native x86_64-unknown-linux-gnu since at least
r121846 (presumably the same cause), so I'm a bit worried that it wasn't
noticed when 121819 was committed. It seems best to xfail for cris-* until this
PR gets attention - preprocessed test-case is in place so I guess it's as usual
just a matter of priorities.  Presumably patch reversion isn't on the table,
but it'd be nice to see this PR being assigned.  (Mark?)


-- 

hp at gcc dot gnu dot org changed:

   What|Removed |Added

 GCC target triplet|cris-axis-elf   |cris-axis-elf, x86_64-
   ||unknown-linux-gnu


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

[Bug middle-end/30768] [4.3 regression]: ICE in ext/pb_ds/regression/list_update_data_map_rand.cc

[mmitchel at gcc dot gnu dot org]

--- Comment #7 from mmitchel at gcc dot gnu dot org  2007-02-14 05:14 
---
It's certainly my responsibility to fix it.  

Personally, I don't think it's necessary to revert it, and I will try to get to
it soon, but if it's getting in other people's way, then we could potentially
revert.  As I mentioned upthread, I didn't see the test fail, but presumably
that's either me being a moron, or some environmental difference.

Keep after me about it.


-- 

mmitchel at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |mark at codesourcery dot com
   |dot org |
 Status|NEW |ASSIGNED


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

[Bug tree-optimization/30771] ice for legal code with -O2 -ftree-vectorize

[patchapp at dberlin dot org]

--- Comment #5 from patchapp at dberlin dot org  2007-02-14 05:26 ---
Subject: Bug number PR tree-optimization/30771

A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-02/msg01186.html


-- 


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

[Bug middle-end/26061] error and warning count

[patchapp at dberlin dot org]

--- Comment #11 from patchapp at dberlin dot org  2007-02-14 05:26 ---
Subject: Bug number PR26061

A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-02/msg01190.html


-- 


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