[Bug target/36174] [4.4 Regression]: Failed to boostrap

[ubizjak at gmail dot com]

-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

   Target Milestone|--- |4.4.0


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

[Bug bootstrap/36169] [4.4 Regression] gcc/fortran/simplify.c:3956: internal compiler error: in gen_reg_rtx, at emit-rtl.c:868

[ubizjak at gmail dot com]

--- Comment #8 from ubizjak at gmail dot com  2008-05-08 06:56 ---
Fixed.


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

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


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

[Bug c++/36178] rand() combined with vectors negates setw()

[pmaconi at gmail dot com]

--- Comment #5 from pmaconi at gmail dot com  2008-05-08 05:58 ---
Sorry. When I ran that code from visual studio, rand() always returned no more
than 5 digits. I didn't realize that RAND_MAX was different between the
compilers. 


-- 

pmaconi at gmail dot com changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||INVALID


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

[Bug c++/36178] rand() combined with vectors negates setw()

[pinskia at gcc dot gnu dot org]

--- Comment #4 from pinskia at gcc dot gnu dot org  2008-05-08 04:13 ---
I don't see the issue here, rand returns numbers which are greater than 6
digits.  The first number is 16807 which is 5 digits and then the next one is
282475249 which is 9 digits.  setw just sets the minimal  space to be outputted
so if it is more, it will print out more and not pad it.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING


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

[Bug c++/36178] rand() combined with vectors negates setw()

[pmaconi at gmail dot com]

--- Comment #3 from pmaconi at gmail dot com  2008-05-08 03:30 ---
Created an attachment (id=15617)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15617&action=view)
Test .cpp file


-- 


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

[Bug c++/36178] rand() combined with vectors negates setw()

[pmaconi at gmail dot com]

--- Comment #2 from pmaconi at gmail dot com  2008-05-08 03:29 ---
Created an attachment (id=15616)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15616&action=view)
Output file from --save-temps (.s)


-- 


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

[Bug c++/36178] rand() combined with vectors negates setw()

[pmaconi at gmail dot com]

--- Comment #1 from pmaconi at gmail dot com  2008-05-08 03:29 ---
Created an attachment (id=15615)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15615&action=view)
Output file from --save-temps


-- 


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

[Bug c++/36178] New: rand() combined with vectors negates setw()

[pmaconi at gmail dot com]

Assigning a rand() value to a vector element and then accessing the element
seems to negate setw() - no spaces are added to the output. I attempted to
access the element via iterators as well as integer subscripts, neither caused
any change. The console reported no errors or warnings during compile. 

--- g++ -v output 

Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--with-gxx-include-dir=/usr/include/c++/4.2 --program-suffix=-4.2
--enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.2.3 (Ubuntu 4.2.3-2ubuntu7)

-- Sample File ---

#include 
#include 
#include 
#include 
using namespace std;
void showVector(vector &v);

int main()
{
vector v(100);



for(int i=0; i  &v)

{

//--

// Display elements of a vector, 10 per line

//--

vector ::iterator p ;

int count=0 ;

for(p=v.begin(); p!=v.end(); p++)

{

cout << setw(6) << *p ;

count = (count+1)%10 ;

if( count==0 ) 

cout << endl ;

}

cout << endl ;

}


-- 
   Summary: rand() combined with vectors negates setw()
   Product: gcc
   Version: 4.2.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pmaconi at gmail dot com
 GCC build triplet: x86_64-linux-gnu
  GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu


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

[Bug middle-end/36177] [4.4 Regression] g++.dg/tree-ssa/pr19637.C ICEs with 135041 -> 135057

[hp at gcc dot gnu dot org]

-- 

hp at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-05-08 01:00:25
   date||
   Target Milestone|--- |4.4.0


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

[Bug middle-end/36177] New: [4.4 Regression] g++.dg/tree-ssa/pr19637.C ICEs with 135041 -> 135057

[hp at gcc dot gnu dot org]

This test passed with 135041 for cris-elf.  It fails with 135057 as follows:
FAIL: g++.dg/opt/pr23714.C (internal compiler error)
FAIL: g++.dg/opt/pr23714.C (test for excess errors)

with g++.log saying (cutnpasted):

Executing on host:
/tmp/hpautotest-gcc1/cris-elf/gccobj/gcc/testsuite/g++/../../g++
-B/tmp/hpautote\
st-gcc1/cris-elf/gccobj/gcc/testsuite/g++/../../
/tmp/hpautotest-gcc1/gcc/gcc/testsuite/g++.dg/opt/\
pr23714.C  -nostdinc++
-I/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/libstdc++-v3/include/cris-el\
f -I/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/libstdc++-v3/include
-I/tmp/hpautotest-gcc1/gcc/l\
ibstdc++-v3/libsupc++ -I/tmp/hpautotest-gcc1/gcc/libstdc++-v3/include/backward
-I/tmp/hpautotest-gc\
c1/gcc/libstdc++-v3/testsuite/util -fmessage-length=0  -O2
-fnon-call-exceptions  -fno-show-column \
-S   -isystem
/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/./newlib/targ-include -isystem
/tmp/hpa\
utotest-gcc1/gcc/newlib/libc/include  -o pr23714.s(timeout = 300)
/tmp/hpautotest-gcc1/gcc/gcc/testsuite/g++.dg/opt/pr23714.C: In function 'void
run()':^M
/tmp/hpautotest-gcc1/gcc/gcc/testsuite/g++.dg/opt/pr23714.C:16: internal
compiler error: in pre_and_rev_post_order_compute, at cfganal.c:1042^M
Please submit a full bug report,^M
with preprocessed source if appropriate.^M
See  for instructions.^M
compiler exited with status 1

Author of the suspect changes CC:ed.


-- 
   Summary: [4.4 Regression] g++.dg/tree-ssa/pr19637.C ICEs with
135041 -> 135057
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hp at gcc dot gnu dot org
  GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: cris-axis-elf


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

[Bug c++/36089] [4.1/4.2/4.3/4.4 Regression] Funny rejects valid with constant integral expression

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2008-05-07 23:18 ---
This patch works for me:
Index: cp/parser.c
==
=
--- cp/parser.c (revision 2473)
+++ cp/parser.c (working copy)
@@ -4659,6 +4659,10 @@ cp_parser_parenthesized_expression_list 
   if (identifier)
 expression_list = tree_cons (NULL_TREE, identifier, expression_list);

+  /* If we have a constant, just return the value.  */
+  if (non_constant_p && !*non_constant_p)
+return TREE_VALUE (expression_list);
+
   return expression_list;
 }


-- 


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

[Bug debug/35896] [4.4 Regression] gfortran TLS symbols broken with debug info

[jakub at gcc dot gnu dot org]

--- Comment #6 from jakub at gcc dot gnu dot org  2008-05-07 23:16 ---
Subject: Bug 35896

Author: jakub
Date: Wed May  7 23:15:50 2008
New Revision: 135060

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=135060
Log:
PR debug/35896
* dwarf2out.c (dw_expand_expr, common_check): Removed.
(fortran_common): New function.
(gen_variable_die): Call fortran_common instead of common_check,
adjust for it returning tree instead of rtx.Formatting.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/dwarf2out.c


-- 


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

[Bug middle-end/36172] [4.4 Regression] ice for legal code with -O3

[rguenth at gcc dot gnu dot org]

--- Comment #11 from rguenth at gcc dot gnu dot org  2008-05-07 21:54 
---
I have a patch.


-- 

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|2008-05-07 21:10:58 |2008-05-07 21:54:03
   date||


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

[Bug middle-end/36172] [4.4 Regression] ice for legal code with -O3

[rguenth at gcc dot gnu dot org]

--- Comment #10 from rguenth at gcc dot gnu dot org  2008-05-07 21:50 
---
operand_equal_p returns true for (float *) VH.11 and (long unsigned int) VH.11.


-- 


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

[Bug middle-end/36172] [4.4 Regression] ice for legal code with -O3

[rguenth at gcc dot gnu dot org]

--- Comment #9 from rguenth at gcc dot gnu dot org  2008-05-07 21:47 ---
PA_IN/OUT computes different for s/(unsigned long)/(long)/ in the following
testcase (long works):

int f(float * );
unsigned long FcCharSetFreeze (int *fcs, int b)
{
  int i;
  int a = 0;
  for (i = 0; i < *fcs; i++)
  {
float *leaf = (float *)fcs;
int hash = f (leaf);
if (hash)
  a = b;
if (!a)
  return;
  }
  return (unsigned long) fcs;
}


-- 


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

[Bug middle-end/36172] [4.4 Regression] ice for legal code with -O3

[rguenth at gcc dot gnu dot org]

--- Comment #8 from rguenth at gcc dot gnu dot org  2008-05-07 21:37 ---
More reduced:

int f(float * );
__SIZE_TYPE__ FcCharSetFreeze (int *fcs, int b)
{
  int i;
  int a = 0;
  for (i = 0; i < *fcs; i++)
  {
float *leaf = (float *)fcs;
int hash = f (leaf);
if (hash)
  a = b;
if (!a)
  return;
  }
  return (__SIZE_TYPE__) fcs;
}


-- 


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

[Bug fortran/36176] New: TRANSFER of constant substrings

[fxcoudert at gcc dot gnu dot org]

Well, we simply don't handle simplification of TRANSFER with constant
substrings, so it gives ICEs here and there:

$ cat b.f90 
  character(len=1), parameter :: t = "x"
  write (*,*) transfer(t(1:1),0)
  end
$ gfortran b.f90 
f951: internal compiler error: in gfc_target_encode_expr, at
fortran/target-memory.c:234


-- 
   Summary: TRANSFER of constant substrings
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: fxcoudert at gcc dot gnu dot org


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

[Bug c++/36175] Definition of list not working inside structure

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2008-05-07 21:16 ---
We need your preprocessed source.


-- 


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

[Bug middle-end/36172] [4.4 Regression] ice for legal code with -O3

[pinskia at gcc dot gnu dot org]

--- Comment #7 from pinskia at gcc dot gnu dot org  2008-05-07 21:10 ---
Better reduced testcase:
typedef unsigned long int uintptr_t;
typedef struct _FcCharLeaf { } FcCharLeaf;
struct _FcCharLeafEnt {
  unsigned int hash;
  int leaf;
};
struct _FcCharSetFreezer
{
  int orig_hash_table[67];
};
struct _FcCharLeafEnt *ent;
int a, f(FcCharLeaf * );
void FcCharSetFreeze (struct _FcCharSetFreezer *freezer, int *fcs)
{
  int i;
  for (i = 0;  i < *fcs;  i++)
  {
FcCharLeaf *leaf = (FcCharLeaf *)fcs;
unsigned int hash = f (leaf);
if (ent->hash == hash)
  a = ent->leaf;
if (!a)
  return;
  }
  freezer->orig_hash_table[((uintptr_t) fcs) & 67] = 0;
}


PRE is creating the mismatched PHI nodes.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-05-07 21:10:58
   date||


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

[Bug c++/36175] New: Definition of list not working inside structure

[zweifel at gmail dot com]

Hello,

I tried to include a list  inside a structure and it does not worked.
And everytime I compile I get a linker error like that:
 error: no matching function for call to `

Character.cpp:365: error: no matching function for call to
'std::list
>::remove(Character* const)'
/usr/lib/gcc/i686-pc-linux-gnu/4.1.2/include/g++-v4/bits/list.tcc:174: note:
candidates are: void std::list<_Tp, _Alloc>::remove(const _Tp&) [with _Tp =
Character_Data*, _Alloc = std::allocator]

I tried to compile something similar on Visual Studio and it had compiled, then
I think it could be something related to g++.
I hope this information could help.


-- 
   Summary: Definition of list not working inside structure
   Product: gcc
   Version: 4.1.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: zweifel at gmail dot com


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

[Bug middle-end/36172] [4.4 Regression] ice for legal code with -O3

[rguenth at gcc dot gnu dot org]

--- Comment #6 from rguenth at gcc dot gnu dot org  2008-05-07 20:45 ---
Created an attachment (id=15614)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15614&action=view)
somehwat reduced testcase

It's probably PPRE that messes up (-O3 -fno-tree-pre is fine, -O2
-finline-functions as well).


-- 


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

[Bug middle-end/36172] [4.4 Regression] ice for legal code with -O3

[pinskia at gcc dot gnu dot org]

--- Comment #5 from pinskia at gcc dot gnu dot org  2008-05-07 20:30 ---
  # prephitmp.1564_417 = PHI 


  long unsigned int pretmp.1563;


prephitmp.1561 is a pointer.


-- 


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

[Bug tree-optimization/35501] Wrong value returned from const int

[hjl dot tools at gmail dot com]

--- Comment #3 from hjl dot tools at gmail dot com  2008-05-07 20:29 ---
Created an attachment (id=15613)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15613&action=view)
A testcase

[EMAIL PROTECTED] pic-1]$ make
/export/build/gnu/gcc-expand/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc-expand/build-x86_64-linux/gcc/ -O2   -c -o main.o
main.c
/export/build/gnu/gcc-expand/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc-expand/build-x86_64-linux/gcc/ -O2 -fPIC -shared -o
libx.so foo.c bar.c
/export/build/gnu/gcc-expand/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc-expand/build-x86_64-linux/gcc/ -o x main.o libx.so
-Wl,-rpath,.
./x
4 ! = 3
3 ! = 4
[EMAIL PROTECTED] pic-1]$ 


-- 


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

[Bug target/36174] [4.4 Regression]: Failed to boostrap

[hjl dot tools at gmail dot com]

--- Comment #4 from hjl dot tools at gmail dot com  2008-05-07 20:08 ---
Revision 135047 works.


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug middle-end/36172] [4.4 Regression] ice for legal code with -O3

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2008-05-07 20:08 ---
Reducing.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu dot
   ||org


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

[Bug middle-end/36154] [4.3 Regression] internal compiler error: in get_constraint_for_component_ref, at tree-ssa-structalias.c:2727

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2008-05-07 20:07 ---
We don't generate _any_ fields for packet, but the memcmp is folded to

:
  p.0_2 = (const unsigned char * {ref-all}) p_1(D);
  D.1186_3 = *p.0_2;
  D.1187_4 = (int) D.1186_3;
  D.1188_5 = (const unsigned char * {ref-all}) &pkt_unaligned.packet;
  D.1189_6 = *D.1188_5;
  D.1190_7 = (int) D.1189_6;
  D.1184_8 = D.1187_4 - D.1190_7;
  return D.1184_8;

taking the address of the missing field.  This has gone "latent" on the
trunk by not generating subvariables for PTA anymore.


-- 

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|2008-05-07 20:04:30 |2008-05-07 20:07:19
   date||


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

[Bug middle-end/36154] [4.3 Regression] internal compiler error: in get_constraint_for_component_ref, at tree-ssa-structalias.c:2727

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2008-05-07 20:04 ---
Reduced testcase, fails at -O:

struct eth_test_pkt {
  unsigned short len;
  unsigned short ctr;
  unsigned char packet[];
} __attribute__ ((packed));
struct eth_test_pkt pkt_unaligned = { .packet = { 0xFC } };
int cmd_unaligned(const void *p)
{
  return memcmp(p, pkt_unaligned.packet, 1);
}


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
  GCC build triplet|x86_64-unknown-linux-gnu|
   GCC host triplet|x86_64-unknown-linux-gnu|
 GCC target triplet|powerpc-eabispe |
   Keywords||ice-on-valid-code
  Known to fail||4.3.0
  Known to work||4.2.3 4.4.0
   Last reconfirmed|-00-00 00:00:00 |2008-05-07 20:04:30
   date||
Summary|internal compiler error: in |[4.3 Regression] internal
   |get_constraint_for_component|compiler error: in
   |_ref, at tree-ssa-  |get_constraint_for_component
   |structalias.c:2727  |_ref, at tree-ssa-
   ||structalias.c:2727
   Target Milestone|--- |4.3.1


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

[Bug middle-end/36172] [4.4 Regression] ice for legal code with -O3

[pinskia at gcc dot gnu dot org]

--- Comment #3 from pinskia at gcc dot gnu dot org  2008-05-07 20:00 ---
  gcc_assert (POINTER_TYPE_P (TREE_TYPE (val1))
  == POINTER_TYPE_P (TREE_TYPE (val2)));

:)


-- 


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

[Bug middle-end/36172] [4.4 Regression] ice for legal code with -O3

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|ice for legal code with -O3 |[4.4 Regression] ice for
   ||legal code with -O3
   Target Milestone|--- |4.4.0


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

[Bug middle-end/36172] ice for legal code with -O3

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2008-05-07 19:58 ---
This worked with 20080325.


-- 


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

[Bug middle-end/36154] internal compiler error: in get_constraint_for_component_ref, at tree-ssa-structalias.c:2727

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2008-05-07 19:56 ---
Reducing.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu dot
   ||org


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

[Bug bootstrap/36169] [4.4 Regression] gcc/fortran/simplify.c:3956: internal compiler error: in gen_reg_rtx, at emit-rtl.c:868

[dominiq at lps dot ens dot fr]

--- Comment #7 from dominiq at lps dot ens dot fr  2008-05-07 19:54 ---
> Should be fixed now.

I am now at stage 3, so it seems fixed.


-- 


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

[Bug tree-optimization/35501] Wrong value returned from const int

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2008-05-07 19:45 ---
Right.  I believe there was even some ELF reasoning here... Micha?


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu dot
   ||org, matz at gcc dot gnu dot
   ||org


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

[Bug c++/33887] [4.1/4.2 Regression] Reference to bitfield gets wrong value when optimizing

[rguenth at gcc dot gnu dot org]

--- Comment #44 from rguenth at gcc dot gnu dot org  2008-05-07 19:43 
---
*** Bug 36122 has been marked as a duplicate of this bug. ***


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||john dot spelis at 3dlabs
   ||dot com


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

[Bug c++/36122] Arm EABI C++ optimiser handles bit fields incorrectly

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2008-05-07 19:43 ---


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


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug middle-end/36124] conditional loop becomes infinite loop in -O2 (gcc 4.2 -> 4.3 regression)

[rguenth at gcc dot gnu dot org]

--- Comment #9 from rguenth at gcc dot gnu dot org  2008-05-07 19:42 ---
decrementing a NULL pointer invokes undefined behavior, incrementing not.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug c++/36128] [4.4 regression] ICE with invalid argument for builtin

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2008-05-07 19:35 ---
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|2008-05-05 06:39:48 |2008-05-07 19:35:40
   date||


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

[Bug target/36133] GCC creates suboptimal ASM : Code includes unneeded TST instructions

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2008-05-07 19:33 ---
It would have been nice to check at least gcc 4.3 (or better current trunk).


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|normal  |enhancement


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

[Bug target/36134] GCC creates suboptimal ASM : usage of ADDA.L where LEA could be used

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2008-05-07 19:33 ---
It would have been nice to check at least gcc 4.3 (or better current trunk).


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|normal  |enhancement


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

[Bug target/36135] GCC creates suboptimal ASM : suboptimal Adressing-Modes used

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2008-05-07 19:33 ---
It would have been nice to check at least gcc 4.3 (or better current trunk).


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|normal  |enhancement
   Keywords||missed-optimization


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

[Bug target/36136] GCC creates suboptimal ASM : constant work registers are set up inside work loops and not outside of the loop

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2008-05-07 19:32 ---
It would have been nice to check at least gcc 4.3 (or better current trunk).


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|normal  |enhancement


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

[Bug middle-end/36137] gcc can't do math

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

  Known to fail||4.2.3
  Known to work||4.3.1
   Target Milestone|--- |4.3.1


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

[Bug c++/36149] -O2 optimization generates wrong code

[rguenth at gcc dot gnu dot org]

--- Comment #10 from rguenth at gcc dot gnu dot org  2008-05-07 19:29 
---
Note that gcc 4.1 is known to have some wrong-code bugs regarding aliasing.


-- 


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

[Bug libstdc++/36164] abi breakage, stdio_sync_filebuf routines missing

[rguenth at gcc dot gnu dot org]

--- Comment #5 from rguenth at gcc dot gnu dot org  2008-05-07 19:27 ---
Please confirm with current 4.2 branch head.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Keywords||ABI


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

[Bug libstdc++/36173] abi breakage, stdio_filebuf routines missing

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2008-05-07 19:24 ---
Please confirm this on the top of the 4.2 branch.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Keywords||ABI


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

[Bug bootstrap/36169] [4.4 Regression] gcc/fortran/simplify.c:3956: internal compiler error: in gen_reg_rtx, at emit-rtl.c:868

[ubizjak at gmail dot com]

--- Comment #6 from ubizjak at gmail dot com  2008-05-07 19:11 ---
Should be fixed now.

Sorry for the breakage, I didn't notice one postreload usage of loadlpd.


-- 


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

[Bug target/36174] [4.4 Regression]: Failed to boostrap

[hjl dot tools at gmail dot com]

--- Comment #3 from hjl dot tools at gmail dot com  2008-05-07 19:11 ---
I am testing the patch on PR 36169 now.


-- 


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

[Bug target/36174] [4.4 Regression]: Failed to boostrap

[andreast at gcc dot gnu dot org]

--- Comment #2 from andreast at gcc dot gnu dot org  2008-05-07 19:09 
---
I see a similar ICE on x86_64-darwin: jni.cc:812 ICE in gen_reg_rtx, at
emit-rtl.c:868


-- 

andreast at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||andreast at gcc dot gnu dot
   ||org


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

[Bug bootstrap/36169] [4.4 Regression] gcc/fortran/simplify.c:3956: internal compiler error: in gen_reg_rtx, at emit-rtl.c:868

[hjl dot tools at gmail dot com]

--- Comment #5 from hjl dot tools at gmail dot com  2008-05-07 19:04 ---
This may be related to PR 36174.


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

OtherBugsDependingO||36174
  nThis||


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

[Bug target/36174] [4.4 Regression]: Failed to boostrap

[hjl dot tools at gmail dot com]

--- Comment #1 from hjl dot tools at gmail dot com  2008-05-07 19:01 ---
I have verified that revision 135041 is the cause. x86 backend
calls gen_reg_rtx to generate pseudo register after reload is
completed.


-- 


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

[Bug target/36174] New: [4.4 Regression]: Failed to boostrap

[hjl dot tools at gmail dot com]

Gcc 4.4 revision 135043 failed to bootstrap on Linux/ia32 when
configured with

-enable-clocale=gnu --with-system-zlib --enable-checking=assert
--with-demangler-in-ld --enable-shared --enable-threads=posix --enable-haifa
--prefix=/usr/gcc-4.4 --with-local-prefix=/usr/local

I got
libtool: compile:  /export/build/gnu/gcc/build-x86_64-linux/gcc/gcj
-B/export/build/gnu/gcc/build-x86_64-linux/x86_64-unknown-linux-gnu/libjava/
-B/export/build/gnu/gcc/build-x86_64-linux/gcc/ -fomit-frame-pointer
-fclasspath=
-fbootclasspath=/net/gnu-13/export/gnu/src/gcc/gcc/libjava/classpath/lib
--encoding=UTF-8 -Wno-deprecated -fbootstrap-classes -g -O2
-fsource-filename=/export/build/gnu/gcc/build-x86_64-linux/x86_64-unknown-linux-gnu/libjava/classpath/lib/classes
-fjni -findirect-dispatch -fno-indirect-classes -c
@gnu-java-awt-peer-swing.list  -fPIC -o .libs/gnu-java-awt-peer-swing.o
gnu/java/awt/peer/gtk/FreetypeGlyphVector.java: In class
'gnu.java.awt.peer.gtk.FreetypeGlyphVector':
gnu/java/awt/peer/gtk/FreetypeGlyphVector.java: In method
'gnu.java.awt.peer.gtk.FreetypeGlyphVector.setupGlyphMetrics()':
In file included from gnu/java/awt/peer/gtk/GtkClipboardNotifier.java:88,
 from gnu/java/awt/peer/gtk/GtkTextAreaPeer.java:221,
 from gnu/java/awt/peer/gtk/GtkChoicePeer.java:141,
 from gnu/java/awt/peer/gtk/GtkVolatileImage.java:203,
 from
/net/gnu-13/export/gnu/src/gcc/gcc/libjava/classpath/gnu/java/awt/peer/gtk/GdkPixbufDecoder.java:429,
 from :63:
gnu/java/awt/peer/gtk/FreetypeGlyphVector.java:440: internal compiler error: in
gen_reg_rtx, at emit-rtl.c:868
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[5]: *** [gnu-java-awt-peer-gtk.lo] Error 1
make[5]: *** Waiting for unfinished jobs

Revision 135037 is OK. Linux/ia32 and Linux/ia64 are fine. I think revision
135041

http://gcc.gnu.org/ml/gcc-patches/2008-05/msg00410.html

may be the cause.


-- 
   Summary: [4.4 Regression]: Failed to boostrap
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: critical
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com
GCC target triplet: x86_64-unknown-linux-gnu


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

[Bug c++/36170] enum variable operation behaviour and -O2

[john dot spelis at 3dlabs dot com]

--- Comment #2 from john dot spelis at 3dlabs dot com  2008-05-07 18:38 
---
Subject: Re:  enum variable operation behaviour and -O2


Thanks for ending that issue.
Best Regards


On 7 May 2008, pinskia at gcc dot gnu dot org wrote:

> 
> 
> --- Comment #1 from pinskia at gcc dot gnu dot org  2008-05-07 17:23 
> ---
> And C++ standard says if the value is out of range of the enum, the behavior 
> is
> undefined so this is not a bug.
> 
> 
> -- 
> 
> 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=36170
> 
> --- You are receiving this mail because: ---
> You reported the bug, or are watching the reporter.
> 


-- 


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

[Bug bootstrap/36169] [4.4 Regression] gcc/fortran/simplify.c:3956: internal compiler error: in gen_reg_rtx, at emit-rtl.c:868

[ubizjak at gmail dot com]

--- Comment #4 from ubizjak at gmail dot com  2008-05-07 18:32 ---
I see the problem:

define_insn_and_split "*fixuns_trunc_1" is a post-reload splitter that
calls  ix86_split_convert_uns_si_sse after reload. There we have:

 gen_sse2_loadlpd (value, CONST0_RTX (V2DFmode), input)

and this calls sse2_loadlpd expander that wants to fixup its operands by
forcing something in a register.

Posted patch will fix the failure.


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |ubizjak at gmail dot com
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-05-07 18:32:07
   date||


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

[Bug libstdc++/36173] New: abi breakage, stdio_filebuf routines missing

[mrs at apple dot com]

A few routines seem to have disappeared from 4.0.0 to 4.2.1:

_ZN9__gnu_cxx13stdio_filebufIcSt11char_traitsIcEE2fdEv;
_ZN9__gnu_cxx13stdio_filebufIcSt11char_traitsIcEE4fileEv;
   
_ZN9__gnu_cxx13stdio_filebufIcSt11char_traitsIcEEC1EP7__sFILESt13_Ios_Openmodem;
_ZN9__gnu_cxx13stdio_filebufIcSt11char_traitsIcEEC1EiSt13_Ios_Openmodem;
_ZN9__gnu_cxx13stdio_filebufIcSt11char_traitsIcEEC1Ev;
   
_ZN9__gnu_cxx13stdio_filebufIcSt11char_traitsIcEEC2EP7__sFILESt13_Ios_Openmodem;
_ZN9__gnu_cxx13stdio_filebufIcSt11char_traitsIcEEC2EiSt13_Ios_Openmodem;
_ZN9__gnu_cxx13stdio_filebufIcSt11char_traitsIcEEC2Ev;
_ZN9__gnu_cxx13stdio_filebufIcSt11char_traitsIcEED0Ev;
_ZN9__gnu_cxx13stdio_filebufIcSt11char_traitsIcEED1Ev;
_ZN9__gnu_cxx13stdio_filebufIcSt11char_traitsIcEED2Ev;
_ZN9__gnu_cxx13stdio_filebufIwSt11char_traitsIwEE2fdEv;
_ZN9__gnu_cxx13stdio_filebufIwSt11char_traitsIwEE4fileEv;
   
_ZN9__gnu_cxx13stdio_filebufIwSt11char_traitsIwEEC1EP7__sFILESt13_Ios_Openmodem;
_ZN9__gnu_cxx13stdio_filebufIwSt11char_traitsIwEEC1EiSt13_Ios_Openmodem;
_ZN9__gnu_cxx13stdio_filebufIwSt11char_traitsIwEEC1Ev;
   
_ZN9__gnu_cxx13stdio_filebufIwSt11char_traitsIwEEC2EP7__sFILESt13_Ios_Openmodem;
_ZN9__gnu_cxx13stdio_filebufIwSt11char_traitsIwEEC2EiSt13_Ios_Openmodem;
_ZN9__gnu_cxx13stdio_filebufIwSt11char_traitsIwEEC2Ev;
_ZN9__gnu_cxx13stdio_filebufIwSt11char_traitsIwEED0Ev;
_ZN9__gnu_cxx13stdio_filebufIwSt11char_traitsIwEED1Ev;
_ZN9__gnu_cxx13stdio_filebufIwSt11char_traitsIwEED2Ev;
_ZTVN9__gnu_cxx13stdio_filebufIcSt11char_traitsIcEEE;
_ZTVN9__gnu_cxx13stdio_filebufIwSt11char_traitsIwEEE;

Adding these back to libstdc++-v3/config/abi/pre/gnu.ver seems to make it
better.


-- 
   Summary: abi breakage, stdio_filebuf routines missing
   Product: gcc
   Version: 4.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mrs at apple dot com
GCC target triplet: powerpc-apple-darwin9


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

[Bug classpath/21869] We should to use StringBuilder instead of StringBuffer where appropriate.

[gnu_andrew at member dot fsf dot org]

--- Comment #39 from gnu_andrew at member dot fsf dot org  2008-05-07 18:10 
---
All appropriate changes made.  Closing this bug.


-- 

gnu_andrew at member dot fsf dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug ada/35576] Ada HW Interrupt Task Enhancement

[joel at gcc dot gnu dot org]

--- Comment #7 from joel at gcc dot gnu dot org  2008-05-07 18:08 ---
Created an attachment (id=15612)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15612&action=view)
hwint patch for gcc 4.3 branch

This has been tested against sparc-rtems4.9 for interrupt functionality.  ACATS
results reported for mips, i386, powerpc, and sparc.


-- 


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

[Bug classpath/21869] We should to use StringBuilder instead of StringBuffer where appropriate.

[gnu_andrew at member dot fsf dot org]

--- Comment #38 from gnu_andrew at member dot fsf dot org  2008-05-07 18:08 
---
Created an attachment (id=15611)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15611&action=view)
Change tools to use StringBuilder


-- 


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

[Bug bootstrap/36169] [4.4 Regression] gcc/fortran/simplify.c:3956: internal compiler error: in gen_reg_rtx, at emit-rtl.c:868

[ubizjak at gmail dot com]

--- Comment #3 from ubizjak at gmail dot com  2008-05-07 18:08 ---
Created an attachment (id=15610)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15610&action=view)
P

Can you try attached patch that fixes some patterns only at expand time? 


-- 


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

[Bug classpath/21869] We should to use StringBuilder instead of StringBuffer where appropriate.

[gnu_andrew at member dot fsf dot org]

--- Comment #37 from gnu_andrew at member dot fsf dot org  2008-05-07 18:08 
---
Created an attachment (id=15609)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15609&action=view)
Move towards a CPStringBuilder-using code base


-- 


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

[Bug classpath/21869] We should to use StringBuilder instead of StringBuffer where appropriate.

[gnu_andrew at member dot fsf dot org]

--- Comment #36 from gnu_andrew at member dot fsf dot org  2008-05-07 18:07 
---
Created an attachment (id=15608)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15608&action=view)
Move towards a CPStringBuilder-using code base


-- 


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

[Bug classpath/21869] We should to use StringBuilder instead of StringBuffer where appropriate.

[gnu_andrew at member dot fsf dot org]

--- Comment #35 from gnu_andrew at member dot fsf dot org  2008-05-07 18:07 
---
Created an attachment (id=15607)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15607&action=view)
Move towards a CPStringBuilder-using code base


-- 


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

[Bug classpath/21869] We should to use StringBuilder instead of StringBuffer where appropriate.

[gnu_andrew at member dot fsf dot org]

--- Comment #34 from gnu_andrew at member dot fsf dot org  2008-05-07 18:04 
---
Created an attachment (id=15606)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15606&action=view)
Move towards a CPStringBuilder-using code base


-- 


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

[Bug classpath/21869] We should to use StringBuilder instead of StringBuffer where appropriate.

[gnu_andrew at member dot fsf dot org]

--- Comment #33 from gnu_andrew at member dot fsf dot org  2008-05-07 18:04 
---
Created an attachment (id=15605)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15605&action=view)
Move towards a CPStringBuilder-using code base


-- 


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

[Bug ada/35576] Ada HW Interrupt Task Enhancement

[joel at gcc dot gnu dot org]

--- Comment #6 from joel at gcc dot gnu dot org  2008-05-07 18:03 ---
Tested against this GCC using gcc-ada-hwint-20080421.diff and patch in 
http://gcc.gnu.org/ml/gcc-patches/2008-04/msg01581.html 

sparc-rtems4.9-gcc (GCC) 4.4.0 20080502 (experimental) [trunk revision 134885]


-- 


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

[Bug classpath/21869] We should to use StringBuilder instead of StringBuffer where appropriate.

[gnu_andrew at member dot fsf dot org]

--- Comment #32 from gnu_andrew at member dot fsf dot org  2008-05-07 18:03 
---
Created an attachment (id=15604)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15604&action=view)
Move towards a CPStringBuilder-using code base


-- 


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

[Bug classpath/21869] We should to use StringBuilder instead of StringBuffer where appropriate.

[gnu_andrew at member dot fsf dot org]

--- Comment #31 from gnu_andrew at member dot fsf dot org  2008-05-07 18:02 
---
Created an attachment (id=15603)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15603&action=view)
Move towards a CPStringBuilder-using code base


-- 


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

[Bug classpath/21869] We should to use StringBuilder instead of StringBuffer where appropriate.

[gnu_andrew at member dot fsf dot org]

--- Comment #30 from gnu_andrew at member dot fsf dot org  2008-05-07 18:02 
---
Created an attachment (id=15602)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15602&action=view)
Move towards a CPStringBuilder-using code base


-- 


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

[Bug classpath/21869] We should to use StringBuilder instead of StringBuffer where appropriate.

[gnu_andrew at member dot fsf dot org]

--- Comment #29 from gnu_andrew at member dot fsf dot org  2008-05-07 18:01 
---
Created an attachment (id=15601)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15601&action=view)
Move towards a CPStringBuilder-using code base


-- 


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

[Bug classpath/21869] We should to use StringBuilder instead of StringBuffer where appropriate.

[ddaney at avtrex dot com]

--- Comment #28 from ddaney at avtrex dot com  2008-05-07 17:59 ---
Subject: Re:  We should to use StringBuilder instead
 of StringBuffer where appropriate.

gnu_andrew at member dot fsf dot org wrote:
> --- Comment #25 from gnu_andrew at member dot fsf dot org  2008-05-07 
> 17:57 ---
> Created an attachment (id=15598)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15598&action=view)
>  --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15598&action=view)
> Move towards a CPStringBuilder-using code base
> 
> 
I don't think it is strictly speaking necessary to attach all of these 
patches.

David Daney


-- 


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

[Bug classpath/21869] We should to use StringBuilder instead of StringBuffer where appropriate.

[gnu_andrew at member dot fsf dot org]

--- Comment #27 from gnu_andrew at member dot fsf dot org  2008-05-07 17:58 
---
Created an attachment (id=15600)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15600&action=view)
Move towards a CPStringBuilder-using code base


-- 


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

[Bug classpath/21869] We should to use StringBuilder instead of StringBuffer where appropriate.

[gnu_andrew at member dot fsf dot org]

--- Comment #26 from gnu_andrew at member dot fsf dot org  2008-05-07 17:58 
---
Created an attachment (id=15599)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15599&action=view)
Move towards a CPStringBuilder-using code base


-- 


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

[Bug classpath/21869] We should to use StringBuilder instead of StringBuffer where appropriate.

[gnu_andrew at member dot fsf dot org]

--- Comment #25 from gnu_andrew at member dot fsf dot org  2008-05-07 17:57 
---
Created an attachment (id=15598)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15598&action=view)
Move towards a CPStringBuilder-using code base


-- 


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

[Bug classpath/21869] We should to use StringBuilder instead of StringBuffer where appropriate.

[gnu_andrew at member dot fsf dot org]

--- Comment #24 from gnu_andrew at member dot fsf dot org  2008-05-07 17:57 
---
Created an attachment (id=15597)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15597&action=view)
Move towards a CPStringBuilder-using code base


-- 


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

[Bug classpath/21869] We should to use StringBuilder instead of StringBuffer where appropriate.

[gnu_andrew at member dot fsf dot org]

--- Comment #23 from gnu_andrew at member dot fsf dot org  2008-05-07 17:56 
---
Created an attachment (id=15596)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15596&action=view)
Move towards a CPStringBuilder-using code base


-- 


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

[Bug classpath/21869] We should to use StringBuilder instead of StringBuffer where appropriate.

[gnu_andrew at member dot fsf dot org]

--- Comment #22 from gnu_andrew at member dot fsf dot org  2008-05-07 17:56 
---
Created an attachment (id=15595)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15595&action=view)
Move towards a CPStringBuilder-using code base


-- 


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

[Bug classpath/21869] We should to use StringBuilder instead of StringBuffer where appropriate.

[gnu_andrew at member dot fsf dot org]

--- Comment #21 from gnu_andrew at member dot fsf dot org  2008-05-07 17:55 
---
Created an attachment (id=15594)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15594&action=view)
Move towards a CPStringBuilder-using code base


-- 


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

[Bug classpath/21869] We should to use StringBuilder instead of StringBuffer where appropriate.

[gnu_andrew at member dot fsf dot org]

--- Comment #20 from gnu_andrew at member dot fsf dot org  2008-05-07 17:54 
---
Created an attachment (id=15593)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15593&action=view)
Move towards a CPStringBuilder-using code base


-- 


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

[Bug tree-optimization/36127] bad choice of loop IVs above -Os on x86

[astrange at ithinksw dot com]

--- Comment #4 from astrange at ithinksw dot com  2008-05-07 17:36 ---
Created an attachment (id=15592)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15592&action=view)
minimal source


-- 


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

[Bug c++/36170] enum variable operation behaviour and -O2

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2008-05-07 17:23 ---
And C++ standard says if the value is out of range of the enum, the behavior is
undefined so this is not a bug.


-- 

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=36170

[Bug middle-end/36143] [4.4 Regression]: FAIL: g++.dg/tree-ssa/pr19637.C

[pinskia at gcc dot gnu dot org]

--- Comment #8 from pinskia at gcc dot gnu dot org  2008-05-07 17:21 ---
Fix it:
[andrew-pinskis-computer:local/gcc/gcc] apinski% svn diff
Index: tree-ssa-forwprop.c
===
--- tree-ssa-forwprop.c (revision 135021)
+++ tree-ssa-forwprop.c (working copy)
@@ -132,6 +132,16 @@ along with GCC; see the file COPYING3.  
  res = VIEW_CONVERT_EXPR(type2var)

Or
+ ptr = (type1*)&type2var;
+ *ptr = res
+
+   Will get turned into (if type1 and type2 are the same size
+   and neither have volatile on them and is not a scalar):
+VIEW_CONVERT_EXPR(type2var) = res
+  FIXME: The last constraint is not needed if DECL_GIMPLE_REG_P is expended
+  to all types
+
+   Or

  ptr = &x[0];
  ptr2 = ptr + ;
@@ -573,6 +583,7 @@ forward_propagate_addr_expr_1 (tree name
 {
   tree lhs, rhs, array_ref;
   tree *rhsp, *lhsp;
+  bool in_reference_lhs = false;

   gcc_assert (TREE_CODE (def_rhs) == ADDR_EXPR);

@@ -602,7 +613,10 @@ forward_propagate_addr_expr_1 (tree name
  ADDR_EXPR will not appear on the LHS.  */
   lhsp = &GIMPLE_STMT_OPERAND (use_stmt, 0);
   while (handled_component_p (*lhsp))
-lhsp = &TREE_OPERAND (*lhsp, 0);
+{
+  lhsp = &TREE_OPERAND (*lhsp, 0);
+  in_reference_lhs = true;
+}
   lhs = *lhsp;

   /* Now see if the LHS node is an INDIRECT_REF using NAME.  If so, 
@@ -617,6 +631,43 @@ forward_propagate_addr_expr_1 (tree name
TREE_TYPE (TREE_OPERAND (def_rhs, 0
 {
   *lhsp = unshare_expr (TREE_OPERAND (def_rhs, 0));
+  lhs = *lhsp;
+  fold_stmt_inplace (use_stmt);
+  tidy_after_forward_propagate_addr (use_stmt);
+
+  /* Continue propagating into the RHS if this was not the only use.  */
+  if (single_use_p)
+   return true;
+}
+
+  /* Now see if the LHS node is an INDIRECT_REF using NAME.  If so, 
+ propagate the ADDR_EXPR into the use of NAME and try to
+ create a VCE for the result.  */
+  if (TREE_CODE (lhs) == INDIRECT_REF
+  && TREE_OPERAND (lhs, 0) == name
+  && TYPE_SIZE (TREE_TYPE (lhs))
+  && TYPE_SIZE (TREE_TYPE (TREE_OPERAND (def_rhs, 0)))
+  /* Function decls should not be used for VCE either as it could be
+ a function descriptor that we want and not the actual function code. 
*/
+  && TREE_CODE (TREE_OPERAND (def_rhs, 0)) != FUNCTION_DECL
+  /* We should not convert volatile loads to non volatile loads. */
+  && !TYPE_VOLATILE (TREE_TYPE (lhs))
+  && !TYPE_VOLATILE (TREE_TYPE (TREE_OPERAND (def_rhs, 0))) 
+  && operand_equal_p (TYPE_SIZE (TREE_TYPE (lhs)),
+ TYPE_SIZE (TREE_TYPE (TREE_OPERAND (def_rhs, 0))), 0)
+  /* Check for aggregate types so we don't end up with a SSA_NAME inside
+ a VIEW_CONVERT_EXPR on the lhs. 
+FIXME: this can go away when DECL_GIMPLE_REG_P is extended for all
+scalar types.  */
+  && (AGGREGATE_TYPE_P (TREE_TYPE (TREE_OPERAND (def_rhs, 0)))
+ || TREE_CODE (TREE_TYPE (TREE_OPERAND (def_rhs, 0))) == VECTOR_TYPE
+ || TREE_CODE (TREE_TYPE (TREE_OPERAND (def_rhs, 0))) ==
COMPLEX_TYPE))
+{
+  tree new_lhs = unshare_expr (TREE_OPERAND (def_rhs, 0));
+  /* Use build1 here as we not produce a right hand side so we need to
keep
+ around the VCE.  */
+  new_lhs = build1 (VIEW_CONVERT_EXPR, TREE_TYPE (lhs), new_lhs);
+  *lhsp = new_lhs;
   fold_stmt_inplace (use_stmt);
   tidy_after_forward_propagate_addr (use_stmt);

@@ -673,9 +724,10 @@ forward_propagate_addr_expr_1 (tree name
   if (TREE_CODE (new_rhs) != VIEW_CONVERT_EXPR)
{
  block_stmt_iterator bsi = bsi_for_stmt (use_stmt);
- new_rhs = force_gimple_operand_bsi (&bsi, new_rhs, true, NULL, true,
BSI_SAME_STMT);
- /* As we change the deference to a SSA_NAME, we need to return false
to make sure that
-the statement does not get removed.  */
+ new_rhs = force_gimple_operand_bsi (&bsi, new_rhs, true, NULL, true,
+ BSI_SAME_STMT);
+ /* As we change the deference to a SSA_NAME, we need to return false
+to make sure that the statement does not get removed.  */
  res = false;
}
   *rhsp = new_rhs;


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug c/36172] ice for legal code with -O3

[dcb314 at hotmail dot com]

--- Comment #1 from dcb314 at hotmail dot com  2008-05-07 17:10 ---
Created an attachment (id=15591)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15591&action=view)
C source code


-- 


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

[Bug c/36172] New: ice for legal code with -O3

[dcb314 at hotmail dot com]

I just tried to compile the Suse Linux package
fontconfig-2.4.2-83 with the GNU C compiler  
version 4.4 snapshot 20080502

The compiler said

fccharset.c:1174: internal compiler error: in compare_values_warnv, at
tree-vrp.c:892
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Preprocessed source code attached. Flag -O3 required.


-- 
   Summary: ice for legal code with -O3
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dcb314 at hotmail dot com
  GCC host triplet: x86_64-suse-linux


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

[Bug middle-end/36143] [4.4 Regression]: FAIL: g++.dg/tree-ssa/pr19637.C

[hp at gcc dot gnu dot org]

--- Comment #7 from hp at gcc dot gnu dot org  2008-05-07 17:08 ---
Also seen on cris-elf with the revision as mentioned and still there as late as
r135041.  Pinskia, are you going to revert it, fix it or should we xfail the
test?


-- 


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

[Bug bootstrap/36169] [4.4 Regression] gcc/fortran/simplify.c:3956: internal compiler error: in gen_reg_rtx, at emit-rtl.c:868

[dominiq at lps dot ens dot fr]

--- Comment #2 from dominiq at lps dot ens dot fr  2008-05-07 17:06 ---
> Can you do a backtrace of the failure?

I tried, but my knowledge of gdb is too limited. I get the error, but backtrace
gives "no stack".


-- 


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

[Bug tree-optimization/36100] [4.4 Regression] always_inline attribute is broken at -O0

[hp at gcc dot gnu dot org]

--- Comment #12 from hp at gcc dot gnu dot org  2008-05-07 17:02 ---
(In reply to comment #11)
> This is not resolved.  I still see
> FAIL: g++.dg/tree-ssa/pr19637.C scan-tree-dump-times dom1 "return 1;" 3

Oops, different PR, sorry for the noise.


-- 

hp at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||FIXED


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

[Bug tree-optimization/36100] [4.4 Regression] always_inline attribute is broken at -O0

[hp at gcc dot gnu dot org]

--- Comment #11 from hp at gcc dot gnu dot org  2008-05-07 16:55 ---
This is not resolved.  I still see
FAIL: g++.dg/tree-ssa/pr19637.C scan-tree-dump-times dom1 "return 1;" 3
for cris-elf and it's been a few days.
I'm reopening this PR to properly track progress.


-- 

hp at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |


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

[Bug bootstrap/36169] [4.4 Regression] gcc/fortran/simplify.c:3956: internal compiler error: in gen_reg_rtx, at emit-rtl.c:868

[ubizjak at gmail dot com]

--- Comment #1 from ubizjak at gmail dot com  2008-05-07 16:39 ---
Hm... strange, because my patch changed x86 target specific MMX and SSE vector
builtins only. I don't see any __builtin_X usage in gfc_simplify_set_exponent
that would trigger codepaths that were changed.

Can you do a backtrace of the failure?


-- 


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

[Bug ada/36171] Missing documentation for Relative_Deadline pragma

[sam at gcc dot gnu dot org]

--- Comment #2 from sam at gcc dot gnu dot org  2008-05-07 15:10 ---
Oh, right, I've never used it before and missed it in the RM :)


-- 


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

[Bug ada/36171] Missing documentation for Relative_Deadline pragma

[charlet at gcc dot gnu dot org]

--- Comment #1 from charlet at gcc dot gnu dot org  2008-05-07 15:07 ---
Sorry, but this is a standard Ada 2005 pragma, documented in the Ada RM.

Arno


-- 

charlet at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug ada/36171] New: Missing documentation for Relative_Deadline pragma

[sam at gcc dot gnu dot org]

A new "Relative_Deadline" pragma has been introduced in commit 134010 and is
lacking documentation.

Assigning to the committer.


-- 
   Summary: Missing documentation for Relative_Deadline pragma
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
AssignedTo: charlet at gcc dot gnu dot org
ReportedBy: sam at gcc dot gnu dot org


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

[Bug c++/36170] New: enum variable operation behaviour and -O2

[john dot spelis at 3dlabs dot com]

The following program shows a case where
the 4.3.0 C++ compiler omits a check on an ENUM
variable when compiled with -O2 but keeps it when
-O is used ?

Targets where this occurs; at least x86, arm-*-linux-*


 optEnum = (Options::Id::Type) getopt_long( ... ) ;

 if( optEnum == -1 )/* This test skipped with -O2 but not -O */
  break;

 switch( optEnum ) {
:
 }

 The workaround for this "bug" is explicitly set
 an enum value of -1

  i.e.

  enum Type {
eHelp = 'h',
::
Dummy = -1  /* fixes issue */
}

 Some people say this is an interpretation of the C++ Spec
 but why does the program behaviour change so radically
 with/without the optimiser and without any warnings ?


 This behviour is reproducible with the attached program on
 an x86 build of 4.3.0

 E.g.

./configure --enable-languages=c,c++ --prefix=/tmp/gcc


g++ -O -o m m.cxx
./m   -> program runs and exit's

g++ -O2 -o m m.cxx
./m   -> program prints -1 forever


=
m.cxx
=

#include 
#include 
#include 
#include 

typedef unsigned long uint32_t ;
typedef unsigned char uint8_t ;

#define ANSI_BOLD ""
#define ANSI_RED ""
#define ANSI_RESET ""
#define HAVE_GETOPT 1


class Background {
public:
enum Type {
eMandel = 0,
eGrid,
eFlat,
eGouraud,
};
};

class Options {
public:
Options( void ) {
memset( this, 0x00, sizeof(*this) );

bailOut= 4;
maxIteration   = 240;
size[0]= 64;
size[1]= 32;
surfSize[0]= size[0];
surfSize[1]= size[1];
offset[0]  = 0;
offset[1]  = 0;
coordX[0]  = -2;
coordX[1]  =  2;
coordY[0]  = -2;
coordY[1]  =  2;
bRandomColours = true;

background = Background::eMandel;

#if USE_HARDWARE
bUseTCSET  = true;
#endif
}

boolbAnimate;
boolbUseGUI;
boolbSetMode;
boolbListModes;
boolbDumpImage;
boolbUseTCSET;
boolbWantClears;
boolbRandomColours;
boolbFixedAspect;
boolbFullScreen;
boolbSingleBuffer;
uint32_tmodeX, modeY;
uint32_tvidDevice;
uint32_tvidRotate;
uint32_tbailOut;
uint32_tmaxIteration;
uint32_tloopCount;
uint32_tsize[2];
uint32_tsurfSize[2];
uint32_toffset[2];
float   coordX[2];
float   coordY[2];
Background::Typebackground;
boolbStall;
uint32_tbenchmarkMode;
};

boolgVerbose= false;
boolgVeryVerbose= false;
boolgAbortNow   = false;


bool processArgs( int argc, char *const argv[], Options &opts )
{
#if HAVE_GETOPT
class Options {
public:
class Id {
public:
enum Type {
eHelp = 'h',
eHelpL = 1,
eSize,
eCoords,
eCoordSet,
eClearFirst,
eBail,
eMaxIt,
eColourMap,
eAnimate,
eSetMode,
eLoop,
eFullScreen,
eListModes,
eOffset,
eAspect,
eDemo,
eNoSync,
eVidDevice,
eNoTCSET,
eGUI,
eDumpImage,
eBackground,
eRotate,
eVerbose,
eStall,
eBench,
#if 0   /* set to '1' as workaround */
eDummy = -1
#endif
};
};

class Args {
public:
enum Type {
eNone,
eReq,
eOpt,
};
};

const char  *name;
Options::Args::Type  args;
Id::Typeid;
const char  *help;
};
Options::Id::Type optEnum;
int optIndex;
uint32_ti;
boolbSuccess = true;

static Options options[] = {
{ "help",Options::Args::eNone, Options::Id::eHelp, 
 "Show this help message" },
{ "size",Options::Args::eReq,  Options::Id::eSize, 
 "Size of rendered image" },
{ "coords", 

[Bug bootstrap/36169] New: [4.4 Regression] gcc/fortran/simplify.c:3956: internal compiler error: in gen_reg_rtx, at emit-rtl.c:868

[dominiq at lps dot ens dot fr]

Gcc revision 135041 failed to bootstrap at:

...
/opt/gcc/i686-darwin/./prev-gcc/xgcc -B/opt/gcc/i686-darwin/./prev-gcc/
-B/opt/gcc/gcc4.4w/i686-apple-darwin9/bin/ -c  -g -O2 -fomit-frame-pointer
-DIN_GCC   -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition -Wmissing-format-attribute -pedantic -Wno-long-long
-Wno-variadic-macros 
-Wno-overlength-strings -Werror -fno-common  -DHAVE_CONFIG_H -I. -Ifortran
-I../../gcc-4.4-work/gcc -I../../gcc-4.4-work/gcc/fortran
-I../../gcc-4.4-work/gcc/../include -I./../intl
-I../../gcc-4.4-work/gcc/../libcpp/include -I/sw/include 
-I../../gcc-4.4-work/gcc/../libdecnumber
-I../../gcc-4.4-work/gcc/../libdecnumber/dpd -I../libdecnumber 
../../gcc-4.4-work/gcc/fortran/simplify.c -o fortran/simplify.o
../../gcc-4.4-work/gcc/fortran/simplify.c: In function
'gfc_simplify_set_exponent':
../../gcc-4.4-work/gcc/fortran/simplify.c:3956: internal compiler error: in
gen_reg_rtx, at emit-rtl.c:868
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[3]: *** [fortran/simplify.o] Error 1
make[3]: *** Waiting for unfinished jobs
rm gcj-dbtool.pod fsf-funding.pod jcf-dump.pod jv-convert.pod grmic.pod
gcov.pod gcj.pod gc-analyze.pod gfdl.pod cpp.pod gij.pod gfortran.pod gcc.pod
make[2]: *** [all-stage2-gcc] Error 2
make[1]: *** [stage2-bubble] Error 2
make: *** [all] Error 2

Last successful bootstrap at rev. 135023, last successful update rev. 135039.


-- 
   Summary: [4.4 Regression] gcc/fortran/simplify.c:3956: internal
compiler error: in gen_reg_rtx, at emit-rtl.c:868
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dominiq at lps dot ens dot fr
 GCC build triplet: i686-apple-darwin9
  GCC host triplet: i686-apple-darwin9
GCC target triplet: i686-apple-darwin9


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

[Bug ada/34354] Bug box in save_gnu_tree, at ada/utils.c:176, in legal Ada 2005 program

[sam at gcc dot gnu dot org]

--- Comment #2 from sam at gcc dot gnu dot org  2008-05-07 14:07 ---
This appears to be fixed in GCC 4.3.2 and in SVN trunk.


-- 

sam at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug fortran/36167] ICE in gfc_conv_descriptor_dimension, at fortran/trans-array.c:242

[burnus at gcc dot gnu dot org]

-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||ice-on-valid-code
  Known to fail||4.1.2 4.2.1 4.3.0 4.4.0
   Last reconfirmed|-00-00 00:00:00 |2008-05-07 14:07:21
   date||
Summary|internal compiler error: in |ICE in
   |gfc_conv_descriptor_dimensio|gfc_conv_descriptor_dimensio
   |n, at fortran/trans-|n, at fortran/trans-
   |array.c:242 |array.c:242


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

[Bug ada/16087] Legal program rejected, RM 7.3(13)

[sam at gcc dot gnu dot org]

-- 

sam at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |sam at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2005-06-14 21:03:20 |2008-05-07 14:03:04
   date||


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

[Bug target/35714] x86 poor code with pmaddwd

[ubizjak at gmail dot com]

--- Comment #5 from ubizjak at gmail dot com  2008-05-07 13:33 ---
The problem with memory operands has been fixed by the patch, so we generate
optimal one insn sequence for both functions in:

--cut here--
#include 

extern __m128i a;

__m128i madd (__m128i b)
{
  return _mm_madd_epi16(a, b);
}

__m128i madd_swapped (__m128i b)
{
return _mm_madd_epi16(b, a);
}
--cut here--

Original testcase passes immediate operand to expanders. Since immediates don't
satisfy insn operand constraints, we move them to the register. Since there is
no direct imm->reg load insn for V4SF, they are first pushed to memory and then
loaded to register.

To solve this problem, we should push immediates to the memory in case insn
supports memory operands. Alternatively, we can perhaps find original memory
location (if available) and pass this location to the expander.


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |ubizjak at gmail dot com
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-05-07 13:33:55
   date||


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

[Bug target/35714] x86 poor code with pmaddwd

[uros at gcc dot gnu dot org]

--- Comment #4 from uros at gcc dot gnu dot org  2008-05-07 13:12 ---
Subject: Bug 35714

Author: uros
Date: Wed May  7 13:12:02 2008
New Revision: 135041

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=135041
Log:
PR target/35714
* config/i386/mmx.md (mmx_subv2sf3): New expander.
(*mmx_subv2sf3): Rename from mmx_subv2sf3 insn pattern.
(*mmx_eqv2sf3): Rename from mmx_eqv2sf3 insn pattern.
(mmx_eqv2sf3): New expander.  Use ix86_fixup_binary_operands_no_copy
to handle nonimmediate operands.
(*mmx_paddwd): Rename from mmx_paddwd insn pattern.
(mmx_paddwd): New expander.  Use ix86_fixup_binary_operands_no_copy
to handle nonimmediate operands.
(*mmx_pmulhrwv4hi3): Rename from mmx_pmulhrwv4hi3 insn pattern.
(mmx_pmulhrwv4hi3): New expander.  Use
ix86_fixup_binary_operands_no_copy to handle nonimmediate operands.
(*sse2_umulv1siv1di3): Rename from sse2_umulv1siv1di3 insn pattern.
(sse2_umulv1siv1di3): New expander.  Use
ix86_fixup_binary_operands_no_copy to handle nonimmediate operands.
(*mmx_eq3): Rename from mmx_eq3 insn pattern.
(mmx_eq3): New expander.  Use
ix86_fixup_binary_operands_no_copy to handle nonimmediate operands.
(*mmx_uavgv8qi3): Rename from mmx_uavgv8qi3 insn pattern.
(mmx_uavgv8qi3): New expander.  Use
ix86_fixup_binary_operands_no_copy to handle nonimmediate operands.
(*mmx_uavgv4hi3): Rename from mmx_uavgv4hi3 insn pattern.
(mmx_uavgv4hi3): New expander.  Use
ix86_fixup_binary_operands_no_copy to handle nonimmediate operands.

* config/i386/sse.md
(*sse_movhlps): Rename from sse_movhlps insn pattern.
(sse_movhlps): New expander.  Use ix86_fixup_binary_operands
to handle nonimmediate operands.
(*sse_movlhps): Rename from sse_movlhps insn pattern.
(sse_movlhps): New expander.  Use ix86_fixup_binary_operands
to handle nonimmediate operands.
(*sse_loadhps): Rename from sse_loadhps insn pattern.
(sse_loadhps): New expander.  Use ix86_fixup_binary_operands
to handle nonimmediate operands.
(*sse_loadlps): Rename from sse_loadlps insn pattern.
(sse_loadlps): New expander.  Use ix86_fixup_binary_operands
to handle nonimmediate operands.
(*sse2_unpckhpd): Rename from sse2_unpckhpd insn pattern.
(sse2_unpckhpd): New expander.  Use
ix86_fixup_binary_operands_no_copy to handle nonimmediate operands.
(*sse2_unpcklpd): Rename from sse2_unpcklpd insn pattern.
(sse2_unpcklpd): New expander.  Use
ix86_fixup_binary_operands_no_copy to handle nonimmediate operands.
(*sse_loadhpd): Rename from sse_loadhpd insn pattern.
(sse_loadhpd): New expander.  Use ix86_fixup_binary_operands
to handle nonimmediate operands.
(*sse_loadlpd): Rename from sse_loadlpd insn pattern.
(sse_loadlpd): New expander.  Use ix86_fixup_binary_operands
to handle nonimmediate operands.
(*sse2_3): Rename from
sse2_3 insn pattern.
(sse2_3): New expander.  Use
ix86_fixup_binary_operands_no_copy to handle nonimmediate operands.
(*sse2_umulv2siv2di3): Rename from sse2_umulv2siv2di3 insn pattern.
(sse2_umulv2siv2di3): New expander.  Use
ix86_fixup_binary_operands_no_copy to handle nonimmediate operands.
(*sse4_1_mulv2siv2di3): Rename from sse4_1_mulv2siv2di3 insn pattern.
(sse4_1_mulv2siv2di3): New expander.  Use
ix86_fixup_binary_operands_no_copy to handle nonimmediate operands.
(*sse2_pmaddwd): Rename from sse2_pmaddwd insn pattern.
(sse2_pmaddwd): New expander.  Use
ix86_fixup_binary_operands_no_copy to handle nonimmediate operands.
(*sse2_eq3): Rename from sse2_eq3 insn pattern.
(sse2_eq3): New expander.  Use
ix86_fixup_binary_operands_no_copy to handle nonimmediate operands.
(*sse4_1_eqv2di3): Rename from sse4_1_eqv2di3 insn pattern.
(sse4_1_eqv2di3): New expander.  Use
ix86_fixup_binary_operands_no_copy to handle nonimmediate operands.
(*sse2_uavgv16qi3): Rename from sse2_uavgv16qi3 insn pattern.
(sse2_uavgv16qi3): New expander.  Use
ix86_fixup_binary_operands_no_copy to handle nonimmediate operands.
(*sse2_uavgv16qi3): Rename from sse2_uavgv16qi3 insn pattern.
(sse2_uavgv16qi3): New expander.  Use
ix86_fixup_binary_operands_no_copy to handle nonimmediate operands.
(*sse2_uavgv8hi3): Rename from sse2_uavgv8hi3 insn pattern.
(sse2_uavgv8hi3): New expander.  Use
ix86_fixup_binary_operands_no_copy to handle nonimmediate operands.
(*ssse3_pmulhrswv8hi3): Rename from ssse3_pmulhrswv8hi3 insn pattern.
(ssse3_pmulhrswv8hi3): New expander.  Use
ix86_fixup_binary_operands_no_copy to handle nonimmediate opera

[Bug c/31983] Add option to gcc to display specific language manual section reference for error/warning encountered.

[esigra at gmail dot com]

--- Comment #8 from esigra at gmail dot com  2008-05-07 13:08 ---
(In reply to comment #7)
> Adding color output (ala ls --color) or the proposal in this bug (gcc as a
> lecturer in programming) show a critical misunderstanding: Assuming that GCC
> developers are bored and have nothing to do. There are many many features that
> GCC developers themselves would like to see implemented and they are not
> because of lack of time. Therefore, people coming up with random half-backed
> ideas, which they do not intend to fully specify, much less implement, is
> hopeless.

Sorry, you got it totally wrong! When someone suggests a feature that he thinks
would be useful, he does definitely not imply that the current developers are
bored and have nothing to do.

The critical misunderstanding here is that some GCC developers think that a
feature request is something that they are obliged to implement within a
certain time and the only way to get rid of that obligation is to dismiss any
idea, that they do not have time to implement right now, as invalid.

We are developers too for various projects and we get feature requests all the
time. Many of the ideas that we get are useful but there is no way that we can
implement them all within the foreseeable future. Still we do not rush to
dismiss ideas as invalid. And we certainly do not misconceieve it as
implications that we are bored or do not have any ideas of our own.

I think the criterion for closing feature requests as invalid should be
modified from "we do not have time to implement this feature any time soon" to
"there is no way that this feature would be useful". This is how most projects
handle it and what reporters interpret it as.


-- 


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

[Bug c++/36159] C++ compiler should issue a warning with missing new operator

[joseph at codesourcery dot com]

--- Comment #6 from joseph at codesourcery dot com  2008-05-07 11:25 ---
Subject: Re:  C++ compiler should issue a warning with  missing
 new operator

On Wed, 7 May 2008, pinskia at gcc dot gnu dot org wrote:

> aligned memory.  PPC LV2 returns 16byte aligned memory.  PPC Linux should be
> returning 16byte aligned memory for the 128bit long double but from what I
> remember or last heard does not.

There is a patch for that glibc bug 
, but the glibc 
maintainers have not reviewed it.


-- 


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

[Bug c++/36122] Arm EABI C++ optimiser handles bit fields incorrectly

[john dot spelis at 3dlabs dot com]

--- Comment #2 from john dot spelis at 3dlabs dot com  2008-05-07 11:14 
---
Subject: Re:  Arm EABI C++ optimiser handles bit fields
 incorrectly


Thanks pinskia. I ported the 4.3.0 compilers and that's a 
confirmed fix to the issue.

Best Regards


On 5 May 2008, pinskia at gcc dot gnu dot org wrote:

> 
> 
> --- Comment #1 from pinskia at gcc dot gnu dot org  2008-05-05 04:50 
> ---
> This is most likely a dup of bug 33887 and has been fixed for GCC 4.3.0.
> 
> 
> -- 
> 
> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36122
> 
> --- You are receiving this mail because: ---
> You reported the bug, or are watching the reporter.
> 


-- 


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