Problem supporting char and short int

[Prashant Purohit]

Hi,
  I am trying to port gcc-4.3.0 to a custom architecture. The high level
language selected is C.
The processor is a RISC processor and all the registers are of 32-bits wide.
The integer data type (SImode) is set as 32-bits.

I have already completed implementation to support integer data type and it
works fine. Now I am trying to support other data types such as char
(8-bits), short int (16-bits).
I have defined the following things:
1. macros in the .h file:
#define LOAD_EXTEND_OP(MODE) SIGN_EXTEND

#define PROMOTE_MODE(MODE, UNSIGNEDP, TYPE) \
  if (GET_MODE_CLASS (MODE) == MODE_INT \
   GET_MODE_SIZE (MODE)  4)  \
{   \
  (MODE) = SImode;  \
}

#define PROMOTE_FUNCTION_MODE(MODE, UNSIGNEDP, TYPE)\
  if ((GET_MODE_CLASS (MODE) == MODE_INT\
   || GET_MODE_CLASS (MODE) == MODE_COMPLEX_INT)\
   GET_MODE_SIZE (MODE)  4)  \
(MODE) = SImode;   

2. md patterns for zero_extend and extend patterns, movqi and movhi.

The gcc builds successfully and also cc1 compiles the following C code. But
you can see that the generated assembly has bugs.

C code:
   void main()
{
   short int c;
   int b;

   b = c;

}

generated .s looks something like :

...function prologue..
loadHI Reg1, (frame_pointer, #-18)
storeHI Reg1,[frame_pointer, #-28] 
loadSI  Reg2, [frame_pointer, #-28]
ashiftleft   Reg1,Reg2,#16
ashiftright Reg1,Reg1,#16
storeSI Reg1,[frame_pointer, #-16]
...function epilogue


expected .s is:
...function prologue..
loadHI Reg1, (frame_pointer, #-18)
storeSI Reg1,[frame_pointer, #-16]
...function epilogue

I am not able to find out why extra load, store and shift instructions are
generated.

- Prashant.
-- 
View this message in context: 
http://old.nabble.com/Problem-supporting-char-and-short-int-tp27024900p27024900.html
Sent from the gcc - bugs mailing list archive at Nabble.com.

[Bug tree-optimization/42508] [4.5 Regression] wrong code with -O1 -fipa-sra

[jakub at gcc dot gnu dot org]

--- Comment #5 from jakub at gcc dot gnu dot org  2010-01-05 08:41 ---
Subject: Bug 42508

Author: jakub
Date: Tue Jan  5 08:40:50 2010
New Revision: 155640

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155640
Log:
PR tree-optimization/42508
* tree-sra.c (convert_callers): Check for recursive call
by comparing cgraph nodes instead of decls.
(modify_function): Call ipa_modify_formal_parameters also
on all same_body aliases.

* g++.dg/opt/pr42508.C: New test.

* cgraphunit.c (cgraph_materialize_all_clones): Compare
cgraph nodes when checking for same_body aliases.

Added:
trunk/gcc/testsuite/g++.dg/opt/pr42508.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/cgraphunit.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-sra.c


-- 


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

[Bug other/42611] ICE in tree_low_cst, at tree.c:5014

[jakub at gcc dot gnu dot org]

--- Comment #8 from jakub at gcc dot gnu dot org  2010-01-05 08:43 ---
Subject: Bug 42611

Author: jakub
Date: Tue Jan  5 08:42:53 2010
New Revision: 155641

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155641
Log:
PR other/42611
* cfgexpand.c (expand_one_var): Diagnose too large variables.

* gcc.dg/pr42611.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr42611.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/cfgexpand.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug other/42611] ICE in tree_low_cst, at tree.c:5014

[jakub at gcc dot gnu dot org]

--- Comment #9 from jakub at gcc dot gnu dot org  2010-01-05 08:56 ---
Subject: Bug 42611

Author: jakub
Date: Tue Jan  5 08:56:30 2010
New Revision: 155642

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155642
Log:
PR other/42611
* cfgexpand.c (expand_one_var): Diagnose too large variables.

* gcc.dg/pr42611.c: New test.

Added:
branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/pr42611.c
Modified:
branches/gcc-4_4-branch/gcc/ChangeLog
branches/gcc-4_4-branch/gcc/cfgexpand.c
branches/gcc-4_4-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug other/42611] ICE in tree_low_cst, at tree.c:5014

[jakub at gcc dot gnu dot org]

--- Comment #10 from jakub at gcc dot gnu dot org  2010-01-05 08:57 ---
Fixed.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug tree-optimization/42508] [4.5 Regression] wrong code with -O1 -fipa-sra

[jakub at gcc dot gnu dot org]

--- Comment #6 from jakub at gcc dot gnu dot org  2010-01-05 08:58 ---
Fixed.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug middle-end/41082] [4.5 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3 -g with -m64

[irar at il dot ibm dot com]

--- Comment #42 from irar at il dot ibm dot com  2010-01-05 09:09 ---
So, it's enough to force alignment of reduce only (and to vectorize its loop)
to get wrong code. On the other hand, the result of the vectorized loop is
correct, and the problem is in choosing the correct index of temp.

The assembly looks fine to me. So, for me the only way to proceed is to debug.
Dominique, is it possible to access your machine?

Ira


-- 


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

[Bug fortran/42481] generic interface not recognized

[burnus at gcc dot gnu dot org]

--- Comment #3 from burnus at gcc dot gnu dot org  2010-01-05 09:20 ---
See also
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/b128e5ed244a2516

Richard Maine thinks it is valid - and I also do not see (ad hoc) any reason
why it should be invalid.


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

OtherBugsDependingO||32834
  nThis||
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||rejects-valid
   Last reconfirmed|-00-00 00:00:00 |2010-01-05 09:20:12
   date||


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

[Bug c/42596] Integer/Floating point vector casts generate XMM register moves from and to the same register

[rguenth at gcc dot gnu dot org]

--- Comment #5 from rguenth at gcc dot gnu dot org  2010-01-05 10:47 ---
Uh, of course.

_Don't use global register variables_

They are not supposed to be used for this kind of things and nobody spends
a single second to optimizing code generation for them - instead the most
difficult thing is to prevent the compiler from miscompiling things.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||WONTFIX


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

[Bug bootstrap/42619] New: [4.5 regression] ICE building stage3 libiberty/regex.o on Tru64 UNIX: verify_ssa failed

[ro at gcc dot gnu dot org]

As of 20100104 (rev. 155613), mainline failsto bootstrap on alpha-dec-osf4.0f
while compiling the stage3 libiberty/regex.o:

% /vol/gcc/obj/gcc-4.5.0-20100104/4.0f-gcc/./prev-gcc/xgcc
-B/vol/gcc/obj/gcc-4.5.0-20100104/4.0f-gcc/./prev-gcc/
-B/vol/gcc/alpha-dec-osf4.0f/bin/ -B/vol/gcc/alpha-dec-osf4.0f/bin/
-B/vol/gcc/alpha-dec-osf4.0f/lib/ -isystem /vol/gcc/alpha-dec-osf4.0f/include
-isystem /vol/gcc/alpha-dec-osf4.0f/sys-include-c -DHAVE_CONFIG_H -g -O2 
-I. -I/vol/gcc/src/gcc-dist/libiberty/../include  -W -Wall -Wwrite-strings
-Wc++-compat -Wstrict-prototypes -pedantic 
/vol/gcc/src/gcc-dist/libiberty/regex.c -o regex.o -save-temps -v
Reading specs from /vol/gcc/obj/gcc-4.5.0-20100104/4.0f-gcc/./prev-gcc/specs
COLLECT_GCC=/vol/gcc/obj/gcc-4.5.0-20100104/4.0f-gcc/./prev-gcc/xgcc
COLLECT_LTO_WRAPPER=/vol/gcc/obj/gcc-4.5.0-20100104/4.0f-gcc/./prev-gcc/lto-wrapper
Target: alpha-dec-osf4.0f
Configured with: /vol/gcc/src/gcc-dist/configure --prefix=/vol/gcc
--with-local-prefix=/vol/gcc --disable-nls --with-gmp=/vol/gcc
--with-mpfr=/vol/gcc --with-mpc=/vol/gcc --with-libelf=/vol/gcc --host
alpha-dec-osf4.0f --build alpha-dec-osf4.0f --target alpha-dec-osf4.0f
--enable-languages=c,c++,fortran,java,objc
Thread model: posix
gcc version 4.5.0 20100104 (experimental) [trunk revision 155613] (GCC) 
COLLECT_GCC_OPTIONS='-B/vol/gcc/obj/gcc-4.5.0-20100104/4.0f-gcc/./prev-gcc/'
'-B/vol/gcc/alpha-dec-osf4.0f/bin/' '-B/vol/gcc/alpha-dec-osf4.0f/bin/'
'-B/vol/gcc/alpha-dec-osf4.0f/lib/' '-isystem'
'/vol/gcc/alpha-dec-osf4.0f/include' '-isystem'
'/vol/gcc/alpha-dec-osf4.0f/sys-include' '-c' '-DHAVE_CONFIG_H' '-g' '-O2'
'-I.' '-I/vol/gcc/src/gcc-dist/libiberty/../include' '-W' '-Wall'
'-Wwrite-strings' '-Wc++-compat' '-Wstrict-prototypes' '-pedantic' '-o'
'regex.o' '-save-temps' '-v'
 /vol/gcc/obj/gcc-4.5.0-20100104/4.0f-gcc/./prev-gcc/cc1 -E -quiet -v -I.
-I/vol/gcc/src/gcc-dist/libiberty/../include -iprefix
/tmp_mnt/vol/gcc/obj/gcc-4.5.0-20100104/4.0f-gcc/prev-gcc/../lib/gcc/alpha-dec-osf4.0f/4.5.0/
-isystem /vol/gcc/obj/gcc-4.5.0-20100104/4.0f-gcc/./prev-gcc/include -isystem
/vol/gcc/obj/gcc-4.5.0-20100104/4.0f-gcc/./prev-gcc/include-fixed
-DHAVE_CONFIG_H -isystem /vol/gcc/alpha-dec-osf4.0f/include -isystem
/vol/gcc/alpha-dec-osf4.0f/sys-include /vol/gcc/src/gcc-dist/libiberty/regex.c
-W -Wall -Wwrite-strings -Wc++-compat -Wstrict-prototypes -pedantic -g
-fworking-directory -O2 -fpch-preprocess -o regex.i
[...]
 /vol/gcc/obj/gcc-4.5.0-20100104/4.0f-gcc/./prev-gcc/cc1 -fpreprocessed regex.i
-quiet -dumpbase regex.c -auxbase-strip regex.o -g -O2 -W -Wall -Wwrite-strings
-Wc++-compat -Wstrict-prototypes -pedantic -version -o regex.s
GNU C (GCC) version 4.5.0 20100104 (experimental) [trunk revision 155613]
(alpha-dec-osf4.0f)
compiled by GNU C version 4.5.0 20100104 (experimental) [trunk revision
155613], GMP version 4.2.1, MPFR version 2.3.2, MPC version 0.8
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU C (GCC) version 4.5.0 20100104 (experimental) [trunk revision 155613]
(alpha-dec-osf4.0f)
compiled by GNU C version 4.5.0 20100104 (experimental) [trunk revision
155613], GMP version 4.2.1, MPFR version 2.3.2, MPC version 0.8
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: 8f3075b99b6a6af3bebe7ab0e925e5fb
In file included from /vol/gcc/src/gcc-dist/libiberty/regex.c:638:0:
/vol/gcc/src/gcc-dist/libiberty/regex.c: In function 'byte_re_compile_fastmap':
/vol/gcc/src/gcc-dist/libiberty/regex.c:4660:20: warning: '({anonymous})' may
be used uninitialized in this function
/vol/gcc/src/gcc-dist/libiberty/regex.c:4653:22: note: '({anonymous})' was
declared here
In file included from /vol/gcc/src/gcc-dist/libiberty/regex.c:638:0:
/vol/gcc/src/gcc-dist/libiberty/regex.c: In function
'byte_re_match_2_internal':
/vol/gcc/src/gcc-dist/libiberty/regex.c:5543:1: error: definition in block 8
does not dominate use in block 7
for SSA_NAME: D.6360_246 in statement:
D.6361_247 = regstart_61 + D.6360_246;
/vol/gcc/src/gcc-dist/libiberty/regex.c:5543:1: internal compiler error:
verify_ssa failed

The problem doesn't happen at -O0, only with -O and above:

% cc1 -fpreprocessed regex.i -quiet -g -O
In file included from /vol/gcc/src/gcc-dist/libiberty/regex.c:638:0:
/vol/gcc/src/gcc-dist/libiberty/regex.c: In function
'byte_re_match_2_internal':
/vol/gcc/src/gcc-dist/libiberty/regex.c:5543:1: error: definition in block 13
does not dominate use in block 12
for SSA_NAME: D.6360_246 in statement:
D.6361_247 = regstart_61 + D.6360_246;
/vol/gcc/src/gcc-dist/libiberty/regex.c:5543:1: internal compiler error:
verify_ssa failed


-- 
   Summary: [4.5 regression] ICE building stage3 libiberty/regex.o
on Tru64 UNIX: verify_ssa failed
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassigned at gcc 

[Bug bootstrap/42619] [4.5 regression] ICE building stage3 libiberty/regex.o on Tru64 UNIX: verify_ssa failed

[ro at gcc dot gnu dot org]

--- Comment #1 from ro at gcc dot gnu dot org  2010-01-05 11:00 ---
Created an attachment (id=19470)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19470action=view)
preprocessed input file


-- 


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

[Bug tree-optimization/42614] FRE optimizes away valid code after IPA inlining

[stubbs at icerasemi dot com]

--- Comment #2 from stubbs at icerasemi dot com  2010-01-05 11:14 ---
This code should do it:

---
extern void *malloc(int);
extern void abort(void);
extern void free(void *);

typedef struct SEntry
{
  unsigned char num;
} TEntry;

typedef struct STable
{
  TEntry data[2];
} TTable;

TTable *init ()
{
  return malloc(sizeof(TTable));
}

void
expect_func (int a, unsigned char *b) __attribute__ ((noinline));

static inline void
inlined_wrong (TEntry *entry_p, int flag);

void
inlined_wrong (TEntry *entry_p, int flag)
{
  unsigned char index;
  entry_p-num = 0;

  if (flag == 0)
abort();

  for (index = 0; index  1; index++)
entry_p-num++;

  if (!entry_p-num)
{
  abort();
}
}

void
expect_func (int a, unsigned char *b)
{
  if (abs ((a == 0)))
abort ();
  if (abs ((b == 0)))
abort ();
}

int
main ()
{
  unsigned char index = 0;
  TTable *table_p = init();
  TEntry work;

  inlined_wrong ((table_p-data[1]), 1);
  expect_func (1, index);
  inlined_wrong (work, 1);

  free (table_p);

  return 1;
}
---

Built with the command line:

---
gcc -O2 -finline-functions-called-once fail.c
---

When built with GCC 4.4.1 the resultant executable incorrectly calls abort.
When built with GCC 3.4.6 the resultant executable doesn't abort.


-- 


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

[Bug rtl-optimization/42489] Opt bug -foptimize-sibling-calls function call stalled! dead-lock, cpu max

[t66667 at gmail dot com]

--- Comment #11 from t7 at gmail dot com  2010-01-05 11:14 ---
nothing to do with gcc


-- 

t7 at gmail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug bootstrap/42619] [4.5 regression] ICE building stage3 libiberty/regex.o on Tru64 UNIX: verify_ssa failed

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2010-01-05 11:16 ---
The testcase works on i?86.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
   Target Milestone|--- |4.5.0


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

[Bug c/39959] [4.5 Regression] IMA is broken

[joseph at codesourcery dot com]

--- Comment #17 from joseph at codesourcery dot com  2010-01-05 11:25 
---
Subject: Re:  [4.5 Regression] IMA is broken

See what I said in http://gcc.gnu.org/ml/gcc/2009-09/msg00519.html 
suggesting deprecating the implementation of -combine and keeping the 
interface.


-- 


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

[Bug tree-optimization/42620] New: FRE optimizes away valid code after IPA inlining

[rahul at icerasemi dot com]

On the following test case compiled with GCC 4.4.1 release version and the
following command line

gcc -S -O2 -finline-functions-called-once -fdump-tree-all-details
-fdump-ipa-all fail.c

typedef struct SEntry
{
  unsigned char num;
} TEntry;

typedef struct STable
{
  TEntry data[2];
} TTable;


TTable *init ();
int fake_expect (int, int);
void fake_assert (int);

void
expect_func (int a, unsigned char *b) __attribute__ ((noinline));

static inline void
inlined_wrong (TEntry *entry_p, int flag);

void
inlined_wrong (TEntry *entry_p, int flag)
{
  unsigned char index;
  entry_p-num = 0;

  if (!flag)
  fake_assert (0);

  for (index = 0; index  1; index++)
entry_p-num++;

  asm (before);

  if (entry_p-num)
{
  fake_assert(0);
  asm (#here);
}
}

void
expect_func (int a, unsigned char *b)
{
  if (fake_expect ((a == 0), 0))
fake_assert (0);
  if (fake_expect ((b == 0), 0))
fake_assert (0);
}

void
broken ()
{
  unsigned char index = 0;
  TTable *table_p = init();

  inlined_wrong ((table_p-data[1]), 1);
  expect_func (0, index);
  inlined_wrong ((TEntry *)0xf00f, 1);

  LocalFreeMemory (table_p);
}


we get after FRE:

broken ()
{
  unsigned char index;
  unsigned char D.1321;
  unsigned char D.1320;
  unsigned char index;
  unsigned char D.1316;
  unsigned char D.1315;
  struct TTable * table_p;
  unsigned char index;
  struct TEntry * D.1281;
  struct TTable * table_p.1;
  struct TTable * table_p.0;

bb 2:
  index = 0;
  table_p.0_1 = init ();
  table_p = table_p.0_1;
  table_p.1_2 = table_p.0_1;
  D.1281_3 = table_p.1_2-data[1];
  table_p.1_2-data[1].num = 0;
  goto bb 4;

bb 3:
  D.1315_4 = D.1281_3-num;
  D.1316_5 = D.1315_4 + 1;
  D.1281_3-num = D.1316_5;
  index_7 = index_6 + 1;

bb 4:
  # index_6 = PHI 0(2), index_7(3)
  if (index_6 == 0)
goto bb 3;
  else
goto bb 5;

bb 5:
  __asm__ __volatile__(before);
  D.1315_8 = 0;
  expect_func (0, index);
  61455B-num ={v} 0;
  goto bb 7;

bb 6:
  D.1320_10 ={v} 61455B-num;
  D.1321_11 = D.1320_10 + 1;
  61455B-num ={v} D.1321_11;
  index_13 = index_12 + 1;

bb 7:
  # index_12 = PHI 0(5), index_13(6)
  if (index_12 == 0)
goto bb 6;
  else
goto bb 8;

bb 8:
  __asm__ __volatile__(before);
  D.1320_14 ={v} 61455B-num;
  if (D.1320_14 != 0)
goto bb 9;
  else
goto bb 10;

bb 9:
  fake_assert (0);
  __asm__ __volatile__(#here);

bb 10:
  LocalFreeMemory (table_p);
  return;

}


Note the check if (entry_p-num) and associated block is completely
eliminated. The dumps indicate:

Replaced table_p with table_p.0_1 in table_p.1_2 = table_p;
Replaced table_p.1_2-data[1].num with 0 in D.1315_8 =
table_p.1_2-data[1].num;
Removing basic block 6
;; basic block 6, loop depth 0, count 0
;; prev block 5, next block 7
;; pred:   5 [39.0%]  (true,exec)
;; succ:   7 [100.0%]  (fallthru,exec)
bb 6:
fake_assert (0);
__asm__ __volatile__(#here);


If the same code is compiled with the function inlined_wrong declared as

static inline void
inlined_wrong (TEntry *entry_p, int flag) __attribute__ ((always_inline));

The generated code is correct with the check in place, suggesting ipa-inline is
troublesome while early inlining works okay?


-- 
   Summary: FRE optimizes away valid code after IPA inlining
   Product: gcc
   Version: 4.4.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rahul at icerasemi dot com
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


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

[Bug bootstrap/42619] [4.5 regression] ICE building stage3 libiberty/regex.o on Tru64 UNIX: verify_ssa failed

[ro at CeBiTec dot Uni-Bielefeld dot DE]

--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld dot DE  2010-01-05 
11:30 ---
Subject: Re:  [4.5 regression] ICE building stage3 libiberty/regex.o on Tru64
UNIX: verify_ssa failed

 --- Comment #2 from rguenth at gcc dot gnu dot org  2010-01-05 11:16 
 ---
 The testcase works on i?86.

Same for a i386-pc-solaris2.10 - alpha-dec-osf4.0f cross compiler.
This will make reghunting much slower.  I've last successfully
bootstrapped mainline on that platform on 20091217 (rev 155315).

 Rainer


-- 


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

[Bug tree-optimization/42614] FRE optimizes away valid code after IPA inlining

[rahul at icerasemi dot com]

--- Comment #3 from rahul at icerasemi dot com  2010-01-05 11:30 ---
*** Bug 42620 has been marked as a duplicate of this bug. ***


-- 


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

[Bug tree-optimization/42620] FRE optimizes away valid code after IPA inlining

[rahul at icerasemi dot com]

--- Comment #1 from rahul at icerasemi dot com  2010-01-05 11:30 ---
Accidentally added due to browser refresh. Bug is duplicate of PR42614.

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


-- 

rahul at icerasemi dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug tree-optimization/42614] [4.4 Regression] FRE optimizes away valid code after IPA inlining

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2010-01-05 11:31 ---
Somehow patched openSUSE GCC 4.3 is also affected.

bb 2:
  # index_18 = VDEF index_17(D)
  index = 0;
  # index_21 = VDEF index_18
  # SMT.57_22 = VDEF SMT.57_19(D)
  # SMT.58_23 = VDEF SMT.58_20(D)
  table_p_1 = init ();
  D.1295_3 = table_p_1-data[1];
  # SMT.57_24 = VDEF SMT.57_22
  table_p_1-data[1].num = 0;
  goto bb 4;

bb 3:
  # VUSE SMT.58_10
  D.1355_5 = D.1295_3-num;
  D.1356_6 = D.1355_5 + 1;
  # SMT.58_25 = VDEF SMT.58_10
  D.1295_3-num = D.1356_6;
  index_8 = index_7 + 1;

bb 4:
  # index_7 = PHI 0(2), index_8(3)
  # SMT.58_10 = PHI SMT.58_23(2), SMT.58_25(3)
  if (index_7 == 0)
goto bb 3;
  else
goto bb 5;

bb 5:
  # VUSE SMT.57_24
  D.1355_9 = table_p_1-data[1].num;

FRE CSEs the load from table_p_1-data[1].num with the store in BB2 not
seeing the must-alias in BB3.  And it's obvious why when you look at the
vops.

SMT.58 needs to have SMT.57 in its may-aliases but doesn't have it
for some reason.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||alias, wrong-code
  Known to fail||4.4.0 4.4.2
  Known to work||4.2.4 4.3.4 4.5.0
   Last reconfirmed|-00-00 00:00:00 |2010-01-05 11:31:37
   date||
Summary|FRE optimizes away valid|[4.4 Regression] FRE
   |code after IPA inlining |optimizes away valid code
   ||after IPA inlining
   Target Milestone|--- |4.4.3


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

[Bug tree-optimization/42614] [4.4 Regression] FRE optimizes away valid code after IPA inlining

[rguenth at gcc dot gnu dot org]

--- Comment #5 from rguenth at gcc dot gnu dot org  2010-01-05 11:39 ---
Hm, I guess I'm the only one that is likely going to fix it.


-- 

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|2010-01-05 11:31:37 |2010-01-05 11:39:47
   date||


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

[Bug middle-end/42479] Wrong code with -floop-block

[fxcoudert at gcc dot gnu dot org]

--- Comment #1 from fxcoudert at gcc dot gnu dot org  2010-01-05 11:40 
---
Also happens at rev. 155544 on x86_64-unknown-linux-gnu, with both -m32 and
-m64. -O3 -floop-block gives different results than -O3 alone (and is much
faster). Profiling should indicate what part of code is different (I tried
diff'ing the optimized tree dumps, but it's too hard with the variable name
changes).


-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
  GCC build triplet|x86_64-apple-darwin10   |
   GCC host triplet|x86_64-apple-darwin10   |
 GCC target triplet|x86_64-apple-darwin10   |i386, x86_64
   Last reconfirmed|-00-00 00:00:00 |2010-01-05 11:40:52
   date||
Summary|Wrong-code  for induct.f90  |Wrong code with -floop-block
   |with  -O3 -floop-block|


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

[Bug tree-optimization/42614] [4.4 Regression] FRE optimizes away valid code after IPA inlining

[stubbs at icerasemi dot com]

--- Comment #6 from stubbs at icerasemi dot com  2010-01-05 11:41 ---
I can try and look into it if you give me some pointers. I can guarantee I
won't be able to fix it anywhere near as quickly as you though :)


-- 


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

[Bug middle-end/42479] Wrong code with -floop-block

[fxcoudert at gcc dot gnu dot org]

--- Comment #2 from fxcoudert at gcc dot gnu dot org  2010-01-05 11:42 
---
Created an attachment (id=19471)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19471action=view)
Source file and input file

Compile induct.f90 and run with induct.in in the same directory.


-- 


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

[Bug rtl-optimization/42612] post-increment addressing not used

[bonzini at gnu dot org]

--- Comment #2 from bonzini at gnu dot org  2010-01-05 11:43 ---
Combine is doing what it knows best (forming complicated instructions,
addressing modes in this case); to do this it is already damaging the nice
shape of the code after the tree optimizers, and synthesizing things like x+2.

I wonder more about what the RTL looks like before auto-inc-dec, and whether it
is missing something because it must be taught some trick...

Is this a regression from pre-DF (that would be 4.2)?


-- 


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

[Bug c++/40155] [c++0x] variadic template pack problem

[dodji at gcc dot gnu dot org]

--- Comment #2 from dodji at gcc dot gnu dot org  2010-01-05 11:43 ---
FWIW, I think this code is valid.

The A template parameter in typename identityA::type... is in a non-deduced
context, so it's argument should not be deduced from there. The argument of A
should be re-used from the deduction done using RT (*) (A...).

And I think that's where the problem is. Once the compiler figured the second
argument of forward_call is a non-deduced context, it fails to re-use the
argument of A that was deduced in the context of the first argument of
forward_call.

I believe this should be flagged P1, even if it doesn't seem to be a
regression.


-- 

dodji at gcc dot gnu dot org changed:

   What|Removed |Added

   Keywords||rejects-valid


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

[Bug c/42621] New: 4.4/4.5 Regression, Computed gotos on AMD 800% slower

[fredrik dot svahn at gmail dot com]

When compiling a program with computed goto:s with gcc 4.4.2 it runs
significantly slower (up to a factor 10) than when it is compiled with e.g. gcc
4.1/4.3 with the same optimization flags (-O2 or -O3). A small dummy test
program without header file dependencies is attached.

I am compiling with a commandline like gcc -O3 test.c -o testp.4.4.2, and run
the generated executable without arguments, like ./testp.4.4.2. Generating
cpu specific instructions, e.g. -march=athlon64 seems to make no difference.
I have also tried with -fno-gcse (as recommended in the docs) to no avail.
Same results with targets x86_64 and i686 on Novell SLES 10 and Arch Linux.

Interestingly enough I do not see this problem on any Intel processor I have
tried, but I have seen the slowdown on all AMD processors I have tried (e.g.
Dual-Core AMD Opteron Processor 2216 and AMD Turion 64 X2 Mobile Technology
TL-60). In fact, the exact same two binaries resulting from compilation with
gcc 4.4.2 and gcc 4.3 for i686 which show a significant performance difference
on an AMD will not show any significant difference on an Intel Core 2 Duo
T7500.

Some observations:

1. On AMD there is a huge difference in the number of mispredicted branches
between the program compiled with gcc-4.4.2 and the program compiled with
earlier compilers. See for instance the following output from oprofile:

---
Counted RETIRED_INDIRECT_BRANCHES_MISPREDICTED events (Retired Indirect
Branches Mispredicted) with a unit mask of 0x00 (No unit mask) count 500
Counted RETIRED_MISPREDICTED_BRANCH_INSTRUCTIONS events (Retired Mispredicted
Branch Instructions) with a unit mask of 0x00 (No unit mask) count 500
Counted RETIRED_TAKEN_BRANCH_INSTRUCTIONS events (Retired taken branch
instructions) with a unit mask of 0x00 (No unit mask) count 500
RETIRED_INDIRE...|RETIRED_MISPRE...|RETIRED_TAKEN_...|
  samples|  %|  samples|  %|  samples|  %|
--
   185416 88.7799186587 82.8723381826 48.1913 testp.4.4.2
 5605  2.6838  6275  2.7870157401 19.8660 testp.4.3


2. Gcc 4.3 generates the following assembler around the eq: label in
the attached program:

  4004c0:   48 81 fb 00 e1 f5 05cmp$0x5f5e100,%rbx
  4004c7:   74 21   je 4004ea main+0x6a
  4004c9:   0f 1f 80 00 00 00 00nopl   0x0(%rax)
  4004d0:   48 63 c5movslq %ebp,%rax
  4004d3:   48 8b 44 c4 b0  mov-0x50(%rsp,%rax,8),%rax
  4004d8:   ff e0   jmpq   *%rax

While gcc 4.4.2 will generate an additional jump instruction:

  4004c0:   ff e0   jmpq   *%rax
...
  4004d8:   48 81 fb 00 e1 f5 05cmp$0x5f5e100,%rbx
  4004df:   74 21   je 400502 main+0x82
  4004e1:   0f 1f 80 00 00 00 00nopl   0x0(%rax)
  4004e8:   48 63 c5movslq %ebp,%rax
  4004eb:   48 8b 44 c4 88  mov-0x78(%rsp,%rax,8),%rax
  4004f0:   eb ce   jmp4004c0 main+0x40

3. I see the same behaviour with a month-old snapshot of gcc 4.5.

Examples of compilers used (have tried with a number of differrent builds on
different targets):

Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --prefix=/usr --enable-shared
--enable-languages=c,c++,fortran,objc,obj-c++,ada
--enable-threads=posix --mandir=/usr/share/man
--infodir=/usr/share/info --enable-__cxa_atexit --disable-multilib
--libdir=/usr/lib --libexecdir=/usr/lib --enable-clocale=gnu
--disable-libstdcxx-pch --with-tune=generic
Thread model: posix
gcc version 4.4.2 (GCC)

Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --prefix=/usr --enable-shared
--enable-languages=c,c++ --enable-threads=posix
--mandir=/usr/share/man --infodir=/usr/share/info
--enable-__cxa_atexit --disable-multilib --libdir=/usr/lib
--libexecdir=/usr/lib --enable-clocale=gnu --disable-libstdcxx-pch
--with-tune=generic --disable-werror --enable-checking=release
--program-suffix=-4.3 --enable-version-specific-runtime-libs
Thread model: posix
gcc version 4.3.3 (GCC)

Test program:
=

#define VALUE 1

int main(int argc, char *argv[]) {
  void *ops[] = { inc, eq, gt, lt, gte, lte, zero,
not_implemented, exit };

  long i = 0;
  int next_op = argc; //unknown at compile time...
  int fail_op = 0; //inc
  goto *ops[0];   

  inc: 
i++;
goto *ops[next_op]; 

  eq: 
if (!(i == VALUE)) goto handle_fail;
return 0; 

  gt: 
if (!(i  VALUE)) goto handle_fail;
return 0; 

  lt: 
if (!(i  VALUE)) goto handle_fail;
return 0; 

  gte: 
if (!(i = VALUE)) goto handle_fail;
return 0; 

  lte: 
if (!(i = VALUE)) goto handle_fail;
return 0; 

  zero:
if (!(i == 0)) goto handle_fail;
return 0; 

  not_implemented: 
fail_op = 8; //exit
goto handle_fail;

  exit:
return -1;


  handle_fail: 
goto 

[Bug tree-optimization/42614] [4.4 Regression] FRE optimizes away valid code after IPA inlining

[rguenth at gcc dot gnu dot org]

--- Comment #7 from rguenth at gcc dot gnu dot org  2010-01-05 11:57 ---
Shorter testcase, fails at -O2 -fno-early-inlining:

extern void abort(void);

typedef struct SEntry
{
  int num;
} TEntry;

typedef struct STable
{
  TEntry data[2];
} TTable;

TTable * __attribute__((noinline))
init ()
{
  static TTable t;
  return t;
}

static inline void
inlined_wrong (TEntry *entry_p)
{
  unsigned char index;
  entry_p-num = 0;

  for (index = 0; index  1; index++)
entry_p-num++;

  if (!entry_p-num)
abort();
}

void __attribute__((noinline))
expect_func (unsigned char *b)
{
  if (!b)
abort ();
}

int
main ()
{
  unsigned char index = 0;
  TTable *table_p;

  expect_func (index);

  table_p = init();
  inlined_wrong ((table_p-data[1]));

  return 0;
}


-- 


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

[Bug tree-optimization/42614] [4.4 Regression] FRE optimizes away valid code after IPA inlining

[rguenth at gcc dot gnu dot org]

--- Comment #8 from rguenth at gcc dot gnu dot org  2010-01-05 11:58 ---
Well, I'm sure it goes wrong in compute_flow_insensitive_aliasing - let me
have a quick look there.


-- 


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

[Bug libstdc++/42622] New: [C++0x] Improve std::ratio_less to not overflow

[paolo dot carlini at oracle dot com]

This is just an internal reminder: we should implement the following suggestion
from Howard on the library reflector. Maybe Chris is interested...

/

I just recently became aware that it is possible to do this comparison without
any chance of overflow. This is accomplished by converting each ratio to a
continued fraction, term by term so that the memory used is O(1): stack based -
not O(N): heap based.  And then you compare the terms of the continued
fractions, as they are created, and then forget them.  This process does not
involve multiplication, only / and %, thus no overflow.

Boost rational uses this technique, and I have implemented it in a ratio
example implementation.  The complexity of it is approximately the same amount
of code I used in my previous implementation which did go to great lengths to
avoid overflow as much as I knew how at the time.  Both my previous
implementation and my current implementation are much more involved than simply
evaluating R1::num * R2::den  R2::num * R1::den (on the order of 60 lines of
code instead of 3 lines of code).  All cost is incurred at compile time, not
run time.  For my money, the compile-time cost is worth it.  Other
implementations (or clients of those implementations) may or may not feel that
way.

Here is an algorithm for comparing continued fractions:

http://perl.plover.com/yak/cftalk/TALK/slide045.html

Algorithms for converting rationals to continued fractions are common and found
elsewhere/everywhere.


-- 
   Summary: [C++0x] Improve std::ratio_less to not overflow
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: paolo dot carlini at oracle dot com


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

[Bug rtl-optimization/42612] post-increment addressing not used

[jon at beniston dot com]

--- Comment #3 from jon at beniston dot com  2010-01-05 12:13 ---
GCC 4.1.2 seems to produce the same code.

   mov r2, #0
   mov r3, r0
   strbr2, [r3], #1
   strbr2, [r0, #1]
   add r0, r3, #2
   @ lr needed for prologue
   strbr2, [r3, #1]
   bx  lr
   .size   func, .-func
   .ident  GCC: (GNU) 4.1.2


-- 


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

[Bug tree-optimization/42614] [4.4 Regression] FRE optimizes away valid code after IPA inlining

[rguenth at gcc dot gnu dot org]

--- Comment #9 from rguenth at gcc dot gnu dot org  2010-01-05 12:16 ---
Ok, it's simple.  We add false aliases to index to both SMTs of SEntry and
STable because may_alias_p (SEntry, char) returns true as every alias-set
is a subset of alias-set zero.

But then when coming along to adding SMT aliases we do not add STable as
an alias of SEntry because they already have (false) aliases in common.
These false aliases are pruned by access_can_touch_variable later and
boom - there we go.

I have a fix.


-- 


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

[Bug tree-optimization/42614] [4.4 Regression] FRE optimizes away valid code after IPA inlining

[rguenth at gcc dot gnu dot org]

--- Comment #10 from rguenth at gcc dot gnu dot org  2010-01-05 12:20 
---
Created an attachment (id=19472)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19472action=view)
patch

Testing on the application that originally failed appreciated.


-- 


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

[Bug tree-optimization/42614] [4.4 Regression] FRE optimizes away valid code after IPA inlining

[stubbs at icerasemi dot com]

--- Comment #11 from stubbs at icerasemi dot com  2010-01-05 12:23 ---
Thanks for your time and the extra quick fix! I'll do some testing with that
patch now.


-- 


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

[Bug bootstrap/42511] bootstrap error in stage3 on alpha-linux-gnu

[ubizjak at gmail dot com]

--- Comment #4 from ubizjak at gmail dot com  2010-01-05 12:29 ---
I got different error in the same place when configured with:

Target: alpha-linux-gnu
Configured with: ../gcc-svn/trunk/configure --host=alpha-linux-gnu
--build=alpha-linux-gnu --target=alpha-linux-gnu --enable-languages=c

~/gcc-build-test/gcc/cc1 -O2 -quiet regex.i
In file included from ../../src/libiberty/regex.c:638:0:
../../src/libiberty/regex.c: In function ‘byte_re_match_2_internal’:
../../src/libiberty/regex.c:5543:1: error: definition in block 8 does not
dominate use in block 7
for SSA_NAME: D.7346_246 in statement:
D.7347_247 = regstart_61 + D.7346_246;
../../src/libiberty/regex.c:5543:1: internal compiler error: verify_ssa failed
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.

This happens with stage2 compiler.


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-01-05 12:29:58
   date||


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

[Bug tree-optimization/42614] [4.4 Regression] FRE optimizes away valid code after IPA inlining

[stubbs at icerasemi dot com]

--- Comment #12 from stubbs at icerasemi dot com  2010-01-05 12:32 ---
Your patch fixes our original application. Thanks again for your help.


-- 


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

[Bug rtl-optimization/42621] [4.4/4.5 Regression] Computed gotos on AMD 800% slower

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

  Component|c   |rtl-optimization
   Keywords||missed-optimization
Summary|4.4/4.5 Regression, Computed|[4.4/4.5 Regression]
   |gotos on AMD 800% slower|Computed gotos on AMD 800%
   ||slower
   Target Milestone|--- |4.4.3


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

[Bug rtl-optimization/42621] [4.4/4.5 Regression] Computed gotos on AMD 800% slower

[steven at gcc dot gnu dot org]

--- Comment #1 from steven at gcc dot gnu dot org  2010-01-05 12:50 ---
There is a pass duplicate_computed_gotos that should take care of this. Why
does it not work in this case?


-- 

steven at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-01-05 12:50:01
   date||


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

[Bug middle-end/42479] Wrong code with -floop-block

[dominiq at lps dot ens dot fr]

--- Comment #3 from dominiq at lps dot ens dot fr  2010-01-05 12:56 ---
Profiling without -floop-block

+ 99.8%, start, a.out
| + 99.8%, main, a.out
| | + 99.8%, induct_, a.out
| | | + 77.5%, __mqc_m_MOD_mutual_ind_quad_cir_coil, a.out
| | | |   2.8%, cosisin, libSystem.B.dylib
| | | | - 1.0%, cexp$fenv_access_off, libSystem.B.dylib
| | | | - 0.2%, asin, libSystem.B.dylib
| | | |   0.1%, cos$fenv_access_off, libSystem.B.dylib
| | | |   0.1%, _gfortran_transpose_r8, libgfortran.3.dylib
| | | |   0.0%, dyld_stub_cexp, a.out
| | | |   0.0%, dyld_stub_asin, a.out
| | | |   0.0%, dyld_stub__gfortran_transpose_r8, a.out
| | | - 21.9%, __mqr_m_MOD_mutual_ind_quad_rec_coil, a.out
| | | - 0.1%, __s_rect_m_MOD_rect_self_inductance, a.out
| | | - 0.1%, __rect_r_m_MOD_rect_resistance, a.out
| | |   0.0%, log, libSystem.B.dylib
| | | - 0.0%, __gen_resq_mesh_m_MOD_gen_resq_mesh, a.out
| | | - 0.0%, __mcr_m_MOD_mutual_ind_cir_rec_coils, a.out
| | | - 0.0%, free_large, libSystem.B.dylib
| | |   0.0%, cos$fenv_access_off, libSystem.B.dylib
| | | - 0.0%, __mcc_m_MOD_mutual_ind_cir_cir_coils, a.out
| | | - 0.0%, __define_wand_coils_m_MOD_define_wand_coils, a.out
| | | - 0.0%, __computer_time_m_MOD_computer_time, a.out

with -floop-block

+ 99.6%, start, a.out
| + 99.6%, main, a.out
| | + 99.6%, induct_, a.out
| | | + 59.1%, __mqr_m_MOD_mutual_ind_quad_rec_coil, a.out
| | | | + 0.1%, asin, libSystem.B.dylib
| | | | |   0.0%, sqrtl, libSystem.B.dylib
| | | |   0.1%, _gfortran_transpose_r8, libgfortran.3.dylib
| | | |   0.1%, cos$fenv_access_off, libSystem.B.dylib
| | | |   0.0%, dyld_stub_cos, a.out
| | | - 39.4%, __mqc_m_MOD_mutual_ind_quad_cir_coil, a.out
| | | - 0.4%, __s_rect_m_MOD_rect_self_inductance, a.out
| | | - 0.3%, __rect_r_m_MOD_rect_resistance, a.out
| | |   0.1%, log, libSystem.B.dylib
| | | - 0.1%, __gen_resq_mesh_m_MOD_gen_resq_mesh, a.out
| | |   0.0%, __mcr_m_MOD_mutual_ind_cir_rec_coils, a.out
| | | - 0.0%, free_large, libSystem.B.dylib
| | |   0.0%, asin, libSystem.B.dylib
| | |   0.0%, __mcc_m_MOD_mutual_ind_cir_cir_coils, a.out
| | | - 0.0%, __gen_resq_mesh_m_MOD_gen_resq_mesh_size, a.out
| | | - 0.0%, __define_wand_coils_m_MOD_define_wand_coils, a.out
| |   0.0%, __mqc_m_MOD_mutual_ind_quad_cir_coil, a.out

The miscompiled subroutine being mutual_ind_quad_rec_coil.


-- 


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

[Bug c++/40155] [c++0x] variadic template pack problem

[bangerth at gmail dot com]

--- Comment #3 from bangerth at gmail dot com  2010-01-05 13:20 ---
(In reply to comment #2)
 I believe this should be flagged P1, even if it doesn't seem to be a
 regression.

I'm obviously not impartial, but this is the sort of code that template
packs are supposed to support, and forwarding calls is one of its main
objectives. So I would definitely support getting this to work in 4.5...

W.


-- 


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

[Bug c++/42603] [C++0x] decltype not supported for parent class specifier

[jason at gcc dot gnu dot org]

--- Comment #2 from jason at gcc dot gnu dot org  2010-01-05 13:29 ---
This is

http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#950

we decided in Santa Cruz that this usage should be allowed.


-- 


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

[Bug c++/40155] [c++0x] variadic template pack problem

[dodji at gcc dot gnu dot org]

--- Comment #4 from dodji at gcc dot gnu dot org  2010-01-05 13:31 ---
Patch submitted to http://gcc.gnu.org/ml/gcc-patches/2010-01/msg00205.html


-- 


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

[Bug tree-optimization/42462] [4.5 Regression] wrong-code with computed-goto

[jamborm at gcc dot gnu dot org]

--- Comment #4 from jamborm at gcc dot gnu dot org  2010-01-05 13:39 ---
This weird side-effect of IPA-SRA is caused by a bug in
compute_inline_parameters which should pass node-decl instead of
current_function_decl to its helper functions.  I am about to test the
following patch which fixes this problem:

Index: mine/gcc/ipa-inline.c
===
--- mine.orig/gcc/ipa-inline.c
+++ mine/gcc/ipa-inline.c
@@ -1859,10 +1859,10 @@ compute_inline_parameters (struct cgraph
   node-global.stack_frame_offset = 0;

   /* Can this function be inlined at all?  */
-  node-local.inlinable = tree_inlinable_function_p (current_function_decl);
+  node-local.inlinable = tree_inlinable_function_p (node-decl);
   if (node-local.inlinable  !node-local.disregard_inline_limits)
 node-local.disregard_inline_limits
-  = DECL_DISREGARD_INLINE_LIMITS (current_function_decl);
+  = DECL_DISREGARD_INLINE_LIMITS (node-decl);
   estimate_function_body_sizes (node);
   /* Inlining characteristics are maintained by the cgraph_mark_inline.  */
   node-global.time = inline_summary (node)-self_time;


-- 

jamborm at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jamborm at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2009-12-31 15:57:11 |2010-01-05 13:39:11
   date||


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

[Bug tree-optimization/42614] [4.4 Regression] FRE optimizes away valid code after IPA inlining

[rguenth at gcc dot gnu dot org]

--- Comment #13 from rguenth at gcc dot gnu dot org  2010-01-05 13:41 
---
Subject: Bug 42614

Author: rguenth
Date: Tue Jan  5 13:41:41 2010
New Revision: 155646

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155646
Log:
2010-01-05  Richard Guenther  rguent...@suse.de

PR tree-optimization/42614
* tree-ssa-alias.c (compute_flow_insensitive_aliasing):
Compute SMT aliases before symbol aliases.

* gcc.c-torture/execute/pr42614.c: New testcase.

Added:
branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/execute/pr42614.c
Modified:
branches/gcc-4_4-branch/gcc/ChangeLog
branches/gcc-4_4-branch/gcc/testsuite/ChangeLog
branches/gcc-4_4-branch/gcc/tree-ssa-alias.c


-- 


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

[Bug tree-optimization/42614] [4.4 Regression] FRE optimizes away valid code after IPA inlining

[rguenth at gcc dot gnu dot org]

--- Comment #14 from rguenth at gcc dot gnu dot org  2010-01-05 13:42 
---
Subject: Bug 42614

Author: rguenth
Date: Tue Jan  5 13:42:40 2010
New Revision: 155647

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155647
Log:
2010-01-05  Richard Guenther  rguent...@suse.de

PR tree-optimization/42614
* gcc.c-torture/execute/pr42614.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.c-torture/execute/pr42614.c
Modified:
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug tree-optimization/42614] [4.4 Regression] FRE optimizes away valid code after IPA inlining

[rguenth at gcc dot gnu dot org]

--- Comment #15 from rguenth at gcc dot gnu dot org  2010-01-05 13:42 
---
Fixed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug bootstrap/42511] bootstrap error in stage3 on alpha-linux-gnu

[ubizjak at gmail dot com]

--- Comment #5 from ubizjak at gmail dot com  2010-01-05 13:52 ---
Minimized testcase (from other bootstrap failure):

--cut here--
typedef struct
{
  struct
  {
int how;
  } reg[64 + 1];
}
_Unwind_FrameState;

alpha_fallback_frame_state (_Unwind_FrameState * fs)
{
  long i;

  for (i = 0; i  31; ++i)
fs-reg[i + 32].how = 0;
}
--cut here--

~/gcc-build-test/gcc/cc1 -O2 -quiet t1.c
t1.c: In function ‘alpha_fallback_frame_state’:
t1.c:10:1: error: definition in block 3 does not dominate use in block 2
for SSA_NAME: i_11 in statement:
D.2028_3 = i_11 + 32;
t1.c:10:1: internal compiler error: verify_ssa failed
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.


-- 


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

[Bug bootstrap/42511] bootstrap error in stage3 on alpha-linux-gnu

[rguenth at gcc dot gnu dot org]

--- Comment #6 from rguenth at gcc dot gnu dot org  2010-01-05 13:53 ---
So, which stages do ICE on the testcase?


-- 


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

[Bug fortran/42517] -fcheck=recursion does not work with -fopenmp

[burnus at gcc dot gnu dot org]

--- Comment #10 from burnus at gcc dot gnu dot org  2010-01-05 14:15 ---
Subject: Bug 42517

Author: burnus
Date: Tue Jan  5 14:15:37 2010
New Revision: 155649

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155649
Log:
2010-01-05  Tobias Burnus  bur...@net-b.de

PR fortran/42517
* options.c (gfc_post_options): Set -frecursion
when -fopenmp is used.


Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/options.c


-- 


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

[Bug bootstrap/42511] bootstrap error in stage3 on alpha-linux-gnu

[debian-gcc at lists dot debian dot org]

--- Comment #7 from debian-gcc at lists dot debian dot org  2010-01-05 
14:16 ---
setting BOOT_CFLAGS to -g -O1 lets the build succeed. the testcase from comment
#5 doesn't ice. test results for this build at
http://gcc.gnu.org/ml/gcc-testresults/2010-01/msg00501.html


-- 


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

[Bug bootstrap/42511] bootstrap error in stage3 on alpha-linux-gnu

[ubizjak at gmail dot com]

--- Comment #8 from ubizjak at gmail dot com  2010-01-05 14:21 ---
It looks that tree loop IM FUBARs the compilation.

All testcases compile OK with -O2 -fno-tree-loop-im.

The dump for _.c.099t.lim1 looks quite strange (it resembles _.c.024t.ssa):

--cut here--
;; Function alpha_fallback_frame_state (alpha_fallback_frame_state)



Symbols to be put in SSA form

{ .MEM fs___regfs__I_I__howfs___regfs__I_I_I.3 }


Incremental SSA update started at block: 0

Number of blocks in CFG: 6
Number of blocks to update: 5 ( 83%)




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

fs___regfs__I_I__howfs___regfs__I_I_I.3_10 - {
fs___regfs__I_I__howfs___regfs__I_I_I.3_9 }

Number of virtual NEW - OLD mappings:   0
Number of real NEW - OLD mappings:  1
Number of total NEW - OLD mappings: 1

Number of virtual symbols: 0


Incremental SSA update started at block: 3

Number of blocks in CFG: 6
Number of blocks to update: 2 ( 33%)



alpha_fallback_frame_state (struct _Unwind_FrameState * fs)
{
  int fs___regfs__I_I__howfs___regfs__I_I_I.3;
  long int pretmp.2;
  long int i;
  long int D.2028;

bb 2:
  D.2028_3 = i_11 + 32;
  fs___regfs__I_I__howfs___regfs__I_I_I.3_8 = fs_4(D)-reg[D.2028_3].how;

bb 3:
  # i_11 = PHI i_5(4), 0(2)
  fs___regfs__I_I__howfs___regfs__I_I_I.3_9 = 0;
  i_5 = i_11 + 1;
  if (i_5 = 30)
goto bb 4;
  else
goto bb 5;

bb 4:
  goto bb 3;

bb 5:
  # fs___regfs__I_I__howfs___regfs__I_I_I.3_10 = PHI
fs___regfs__I_I__howfs___regfs__I_I_I.3_9(3)
  fs_4(D)-reg[D.2028_3].how = fs___regfs__I_I__howfs___regfs__I_I_I.3_10;
  return;

}
--cut here--


-- 


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

[Bug bootstrap/42511] bootstrap error in stage3 on alpha-linux-gnu

[ubizjak at gmail dot com]

--- Comment #9 from ubizjak at gmail dot com  2010-01-05 14:27 ---
(In reply to comment #7)
 setting BOOT_CFLAGS to -g -O1 lets the build succeed. the testcase from 
 comment
 #5 doesn't ice. 

It will ICE with default build, with checkings enabled.


-- 


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

[Bug middle-end/42479] Wrong code with -floop-block

[dominiq at lps dot ens dot fr]

--- Comment #4 from dominiq at lps dot ens dot fr  2010-01-05 14:35 ---
Note that the inner loops in subroutine mutual_ind_quad_rec_coil are not
vectorized at -O3, unless -ffast-math is used. Timing the code with and without
-ffast-math gives

[macbook] lin/test% gfc -O3 induct.f90
[macbook] lin/test% time a.out  /dev/null
23.048u 0.037s 0:23.09 99.9%0+0k 0+0io 0pf+0w
[macbook] lin/test% gfc -O3 -ffast-math induct.f90
[macbook] lin/test% time a.out  /dev/null
13.747u 0.033s 0:13.78 99.9%0+0k 0+0io 0pf+0w
[macbook] lin/test% gfc -O3 -floop-block induct.f90
[macbook] lin/test% time a.out  /dev/null
8.452u 0.028s 0:08.48 99.8% 0+0k 0+0io 0pf+0w
[macbook] lin/test% gfc -O3 -ffast-math -floop-block induct.f90
[macbook] lin/test% time a.out  /dev/null
8.154u 0.030s 0:08.18 100.0%0+0k 0+0io 0pf+0w


-- 


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

[Bug fortran/42568] [Cygwin] BLOCKDATA referenced in EXTERNAL not loading from library

[burnus at gcc dot gnu dot org]

--- Comment #21 from burnus at gcc dot gnu dot org  2010-01-05 14:46 ---
(In reply to comment #20)
 Dave, do you know how to emit the forceload and just exactly what is this?

g77 does it as shown in
http://gcc.gnu.org/viewcvs/branches/gcc-3_4-branch/gcc/f/com.c?view=markup


-- 


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

[Bug c++/42623] New: Function template default arguments: Invalid expressions are allowed

[adam at jessamine dot co dot uk]

Ref: Function template default arguments: C++ defect report 226
(http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#226)

GCC 4.5.0 (tr...@155642) compiles the following code despite the
result of sizeof being undefined.  The use of sizeof(incomplete-type)
as the value of a default template argument results in the argument
being given the value zero rather than causing a compile error.

I was originally trying an SFINAE technique with a parameter pack and
as such tried applications of sizeof to variations of templates (as
included below).  However the bug is exposed by the following reduced
case:

  struct undef;

  template typename U, int N = sizeof(U)
  int f()
  {
 return N;
  }

  int main()
  {
 // compiles and returns zero
 return fundef();

 // the above should fail to compile in the same way as this
 // explicitly specified version does.
 //   return fundef, sizeof(undef)();
  }


A more elaborate source yielding the same result is:

  struct undef;
  template typename struct undef_single;
  template typename,typename,typename struct undef_three;
  template typename... struct undef_pack;

  template typename U, int N = sizeof(U)
  int f()
  {
 return N;
  }

  template typename U, int N = sizeof(undef_singleU)
  int f1()
  {
 return N;
  }

  template typename U1, typename U2, typename U3, int N =
sizeof(undef_threeU1,U2,U3)
  int f3()
  {
 return N;
  }

  template typename... U, int N = sizeof(undef_packU...)
  int fp()
  {
 return N;
  }

  int main()
  {
  // all alternatives compile and return zero
  //
  // return fpint,float,short();
  // return f3int,float,short();
  // return f1int();
 return fundef();


  // yields the result I would expect from the above (i.e. fail to
  // compile)
  //
  // return fpint,float,short, sizeof(undef_packint,float,short)();
  // return f3int,float,short, sizeof(undef_threeint,float,short)();
  // return f1int,float,short, sizeof(undef_singleint)();
  // return fundef, sizeof(undef)();
  }


-- 
   Summary: Function template default arguments: Invalid expressions
are allowed
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: adam at jessamine dot co dot uk
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


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

[Bug target/42503] [4.4 Regression] gcc-4.4-20091215 broke libjava on ARM

[rguenth at gcc dot gnu dot org]

--- Comment #16 from rguenth at gcc dot gnu dot org  2010-01-05 15:17 
---
Is this fixed now?


-- 


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

[Bug bootstrap/42511] bootstrap error in stage3 on alpha-linux-gnu

[rguenth at gcc dot gnu dot org]

--- Comment #10 from rguenth at gcc dot gnu dot org  2010-01-05 15:36 
---
Well, I can't see how this wouldn't be a problem on other targets thus I
re-iterate: which stages do show this behavior?  Does the stage1 cc1
reproduce it?


-- 


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

[Bug target/42503] [4.4 Regression] gcc-4.4-20091215 broke libjava on ARM

[mikpe at it dot uu dot se]

--- Comment #17 from mikpe at it dot uu dot se  2010-01-05 15:41 ---
Fixed now, closing.


-- 

mikpe at it dot uu dot se changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug tree-optimization/42286] October 23rd change to tree-ssa-pre.c breaks calculix on powerpc with -ffast-math

[dje at gcc dot gnu dot org]

--- Comment #5 from dje at gcc dot gnu dot org  2010-01-05 15:47 ---
sqrt(-0) = -0  and 0 is a discontinuity for atan2

Either sqrt should return +0 or atan2 should force +0 if games with signed
zeros are allowed.


-- 

dje at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-01-05 15:47:15
   date||


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

[Bug tree-optimization/42286] October 23rd change to tree-ssa-pre.c breaks calculix on powerpc with -ffast-math

[rguenth at gcc dot gnu dot org]

--- Comment #6 from rguenth at gcc dot gnu dot org  2010-01-05 15:50 ---
IIRC the problem is that using fma causes the -0 argument for fsqrt (which
behaves 100% correct).  Thus a more sensible fix would be to do the 0+ on
the fma result.


-- 


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

[Bug tree-optimization/42286] October 23rd change to tree-ssa-pre.c breaks calculix on powerpc with -ffast-math

[segher at kernel dot crashing dot org]

--- Comment #7 from segher at kernel dot crashing dot org  2010-01-05 15:57 
---
With -fno-signed-zeroes, a-b*c is transformed to -(b*c-a), which is a machine
instruction.  If the result would have been +0 before, it now is -0.
The code then takes the sqrt() of that; sqrt(-0) is -0.  This then is
passed to atan2(), which has a discontinuity at 0, and we get wildly
diverging results.

The compiler does nothing wrong here; the transformation is perfectly
valid.

A solution might be to transform e.g. atan2(x,y) into atan2(+0.+x,+0.+y)
when -fno-signed-zeroes is in effect (and of course somehow make sure
those additions aren't optimised away).  Similar for other math library
functions with discontinuities at +/- 0.


-- 


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

[Bug tree-optimization/42286] October 23rd change to tree-ssa-pre.c breaks calculix on powerpc with -ffast-math

[segher at kernel dot crashing dot org]

--- Comment #8 from segher at kernel dot crashing dot org  2010-01-05 16:00 
---
(In reply to comment #6)
 IIRC the problem is that using fma causes the -0 argument for fsqrt (which
 behaves 100% correct).  Thus a more sensible fix would be to do the 0+ on
 the fma result.

But a -0 result from fsqrt() is no problem /an sich/; problems
only show up when you pass a +/- 0 to a function with a discontinuity
there.  Also, doing an extra addition on every fma is hugely expensive.


-- 


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

[Bug tree-optimization/42462] [4.5 Regression] wrong-code with computed-goto

[jamborm at gcc dot gnu dot org]

--- Comment #5 from jamborm at gcc dot gnu dot org  2010-01-05 16:03 ---
Patch posted to the mailing list:
http://gcc.gnu.org/ml/gcc-patches/2010-01/msg00215.html


-- 


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

[Bug tree-optimization/42286] October 23rd change to tree-ssa-pre.c breaks calculix on powerpc with -ffast-math

[rguenther at suse dot de]

--- Comment #9 from rguenther at suse dot de  2010-01-05 16:03 ---
Subject: Re:  October 23rd change to tree-ssa-pre.c
 breaks calculix on powerpc with -ffast-math

On Tue, 5 Jan 2010, segher at kernel dot crashing dot org wrote:

 --- Comment #7 from segher at kernel dot crashing dot org  2010-01-05 
 15:57 ---
 With -fno-signed-zeroes, a-b*c is transformed to -(b*c-a), which is a machine
 instruction.  If the result would have been +0 before, it now is -0.
 The code then takes the sqrt() of that; sqrt(-0) is -0.  This then is
 passed to atan2(), which has a discontinuity at 0, and we get wildly
 diverging results.
 
 The compiler does nothing wrong here; the transformation is perfectly
 valid.
 
 A solution might be to transform e.g. atan2(x,y) into atan2(+0.+x,+0.+y)
 when -fno-signed-zeroes is in effect (and of course somehow make sure
 those additions aren't optimised away).  Similar for other math library
 functions with discontinuities at +/- 0.

Right.  Just it might be simpler with -fno-signed-zeros to
transform a-b*c to 0 + -(b*c-a).  Of course if the result was -0
before then it will be +0 after either variant (and the atan2 
discontinuity would still happen even with your fix).

Thus whatever fix the underlying problem is surely that calculix
is not really -fno-signed-zeros safe.  Can't we get lucky again
as before by trying to recover the PRE code change?

Richard.


-- 


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

[Bug fortran/42568] [Cygwin] BLOCKDATA referenced in EXTERNAL not loading from library

[ian at airs dot com]

--- Comment #22 from ian at airs dot com  2010-01-05 16:09 ---
For ELF, when the GNU linker has seen a common symbol, and then sees that
symbol in the archive map, it will look in the object to see whether the object
defines the symbol (rather than simply providing another common definition). 
If the object does define the symbol, then it is pulled into the link.  See
http://sourceware.org/ml/binutils/1999-12/msg00015.html .  This was done for
compatibility with the SunOS and HP/UX linkers, but in retrospect I think it
may have been a mistake.

For the PE target used on cygwin, the GNU linker does not do this.  It follows
the simpler rule.  For that matter, the gold linker also does not do this.

So, yes, the linkers behave differently.  If you need to provide a common
definition, and you also need to force that common definition to pull in a
definition from an archive, then the compiler should arrange for that to
happen.  The easy way is: whenever you have a definition, also define some
other symbol.  Whenever you have a common symbol, also include an undefined
reference to that definition.


-- 

ian at airs dot com changed:

   What|Removed |Added

 CC||ian at airs dot com


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

[Bug bootstrap/42511] bootstrap error in stage3 on alpha-linux-gnu

[ubizjak at gmail dot com]

--- Comment #11 from ubizjak at gmail dot com  2010-01-05 16:24 ---
(In reply to comment #10)
 Well, I can't see how this wouldn't be a problem on other targets thus I
 re-iterate: which stages do show this behavior?  Does the stage1 cc1
 reproduce it?

No.


-- 


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

[Bug c++/17920] add __attribute__((reimpl)) as a replacement for the (optional) virtual keyword for reimplementations of virtual functions

[shcherbakov at daad-alumni dot de]

--- Comment #12 from shcherbakov at daad-alumni dot de  2010-01-05 16:27 
---
I would also appreciate if an attribute like this is supported by gcc due to
several reasons:
  1. Developers that want to ensure that a virtual method actually overrides
another virtual method of a base class will have means of doing it
automatically (via this __attribute__). Basically, instead of checking every
method signature manually when an updated version of some C++ framework was
released, all checks can be done automatically.
  2. Provided that if this attribute is not used, the compiler behavior will
remain unchanged, nobody will get hurt. Those who don't use the attribute
(and/or don't know about it) won't have any difference, while those who do -
will have better user experience (e.g. if a noreturn function is not marked as
a noreturn, it is maybe a missed optimization chance, but not a problem to
those who don't know about noreturn).
  3. Not supporting an extension until C++ committee states it is a strange
argument, as already GCC supports many time-saving functionality with backward
compatibility (e.g. printf() argument checking or __attribute__((noreturn)))
and nobody complains that they are not approved by C++ committee. As soon as
such extensions are not incompatible with pure C++, they do not mean any
problems. 
  4. -Woverloaded-virtual won't help if a class is designed to contain several
overloads for a virtual method.
  5. Implementing support such attribute should not be a big problem (as the
VTABLE generation code that checks whether the method overrides another method
should just check one attribute and produce one error if it is defined).

To Andrew Pinski: If the proposed feature is still found to be unreasonable, I
am ready to discuss it and provide additional arguments.


-- 

shcherbakov at daad-alumni dot de changed:

   What|Removed |Added

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


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

[Bug tree-optimization/42286] October 23rd change to tree-ssa-pre.c breaks calculix on powerpc with -ffast-math

[segher at kernel dot crashing dot org]

--- Comment #10 from segher at kernel dot crashing dot org  2010-01-05 
16:42 ---
(In reply to comment #9)
 Right.  Just it might be simpler with -fno-signed-zeros to
 transform a-b*c to 0 + -(b*c-a).

a-b*c is two machine instructions; -(b*c-a) is one.  Adding
zero again makes it two, no good :-(

 Of course if the result was -0
 before then it will be +0 after either variant (and the atan2 
 discontinuity would still happen even with your fix).

Sure, it's not a fix, more a band-aid: it will produce more
intuitive results when -fno-signed-zeroes is in effect, since
atan2() does care about the sign of zero, and that compiler
flag says we do not want that.

 Thus whatever fix the underlying problem is surely that calculix
 is not really -fno-signed-zeros safe.

Yes, certainly.  It seems to me this will happen with more sloppy
code though, not just calculix.

 Can't we get lucky again
 as before by trying to recover the PRE code change?

Well, the code change actually improved the generated code
here, do we want to undo that?


-- 


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

[Bug middle-end/42450] [4.5 Regression] another GCC 4.5 ICE on C++ templated code

[rth at gcc dot gnu dot org]

-- 

rth at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |rth at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2009-12-21 22:04:10 |2010-01-05 17:14:21
   date||


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

[Bug bootstrap/41771] Bootstrap with Sun Studio 12.1 fails

[ro at gcc dot gnu dot org]

--- Comment #15 from ro at gcc dot gnu dot org  2010-01-05 17:14 ---
Subject: Bug 41771

Author: ro
Date: Tue Jan  5 17:14:30 2010
New Revision: 155654

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155654
Log:
gcc:
PR bootstrap/41771
* flags.h: Don't include real.h.
(HONOR_NANS, HONOR_SNANS, HONOR_INFINITIES, HONOR_SIGNED_ZEROS,
HONOR_SIGN_DEPENDENT_ROUNDING): Move ...
* real.h (HONOR_NANS, HONOR_SNANS, HONOR_INFINITIES,
HONOR_SIGNED_ZEROS, HONOR_SIGN_DEPENDENT_ROUNDING): ... here.
* dominance.c: Update copyright.
* gimple.c (walk_gimple_op): Remove inline.
* tree-ssa-reassoc.c: Include real.h.
* Makefile.in (FLAGS_H): Remove $(REAL_H).
(tree-ssa-reassoc.o): Depend on $(REAL_H).

include:
PR bootstrap/41771
* ansidecl.h: Fix inline test for C99 and Sun Studio cc.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/Makefile.in
trunk/gcc/dominance.c
trunk/gcc/flags.h
trunk/gcc/gimple.c
trunk/gcc/real.h
trunk/gcc/tree-ssa-reassoc.c
trunk/include/ChangeLog
trunk/include/ansidecl.h


-- 


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

[Bug debug/42396] [4.5 Regression] ICE: in dwarf2out_frame_debug_adjust_cfa, at dwarf2out.c:1859

[rth at gcc dot gnu dot org]

-- 

rth at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |rth at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2009-12-17 16:38:20 |2010-01-05 17:36:59
   date||


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

[Bug libstdc++/42624] New: libstdc++ parallel mode deadlocks in barrier

[edwintorok at gmail dot com]

When building ClamAV with -D_GLIBCXX_PARALLEL -fopenmp, clamd hangs, attaching
gdb to the hanged process reveals 2 threads, one is waiting in poll (normal),
the other one is hanged in gomp_team_barrier_wait_end.
Since there are no other threads that could grant it the barrier, that thread
will wait there indefinetely:

  2 Thread 0x7fedad8d1910 (LWP 6147)  0x0031798c0783 in *__GI___poll
(fds=value optimized out, nfds=value optimized out,
timeout=value optimized out) at ../sysdeps/unix/sysv/linux/poll.c:87
* 1 Thread 0x7fedbdc84770 (LWP 6146)  futex_wait (bar=value optimized out,
state=value optimized out)
at ../../../src/libgomp/config/linux/x86/futex.h:44

Steps to reproduce:
1. Download ClamAV snapshot:
http://git.clamav.net/gitweb?p=clamav-devel.git;a=snapshot;h=fc382bd68b9e2e14198ca05efc72fba15f1a32da;sf=tgz
2. Unpack snapshot
3. Build it with libstdc++ parallel mode:
$ ./configure CXXFLAGS=-fopenmp -D_GLIBCXX_PARALLEL LDFLAGS=-fopenmp
--disable-clamav --enable-llvm=yes
$ make -j4
4. Edit etc/clamd.conf, remove Example line
5. Start clamd:
$ clamd/clamd -c etc/clamd.conf
6. Reload database twice:
$ clamdscan/clamdscan --reload -c etc/clamd.conf
$ clamdscan/clamdscan --reload -c etc/clamd.conf
^C(deadlocks here)
7. $ ps -ef | grep clamd
edwin 7226 1  0 19:55 ?00:00:00
/home/edwin/clam/git/publicgitgit/clamd/.libs/lt-clamd -c etc/clamd.conf
8. Attach gdb
$ gdb 
(gdb) attach 7226
(gdb) thread apply all bt
Thread 2 (Thread 0x7f5180e31910 (LWP 7294)):
#0  0x0031798c0783 in *__GI___poll (fds=value optimized out, nfds=value
optimized out, timeout=value optimized out)
at ../sysdeps/unix/sysv/linux/poll.c:87
#1  0x0040ee6d in fds_poll_recv (data=0x7fff884c1e40, timeout=value
optimized out, check_signals=0) at others.c:487
#2  0x0040d31f in acceptloop_th (arg=value optimized out) at
server-th.c:320
#3  0x00317a40673a in start_thread (arg=value optimized out) at
pthread_create.c:300
#4  0x0031798cb6fd in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#5  0x in ?? ()

Thread 1 (Thread 0x7f51911e4770 (LWP 7293)):
#0  futex_wait (bar=value optimized out, state=value optimized out) at
../../../src/libgomp/config/linux/x86/futex.h:44
#1  do_wait (bar=value optimized out, state=value optimized out) at
../../../src/libgomp/config/linux/wait.h:58
#2  gomp_team_barrier_wait_end (bar=value optimized out, state=value
optimized out)
at ../../../src/libgomp/config/linux/bar.c:109
#3  0x7f51913d43d8 in
__gnu_parallel::find_template__gnu_cxx::__normal_iteratorllvm::PassInfo
const* const*, std::__cxx1998::vectorllvm::PassInfo const*,
std::allocatorllvm::PassInfo const*  ,
__gnu_cxx::__normal_iteratorllvm::PassInfo const* const*,
std::__cxx1998::vectorllvm::PassInfo const*, std::allocatorllvm::PassInfo
const*  , std::binder2nd__gnu_parallel::equal_tollvm::PassInfo const*,
llvm::PassInfo const* const , __gnu_parallel::find_if_selector ()
   from /home/edwin/clam/git/publicgitgit/libclamav/.libs/libclamav.so.6
#4  0x7f51913defea in std::pair__gnu_cxx::__normal_iteratorllvm::PassInfo
const* const*, std::__cxx1998::vectorllvm::PassInfo const*,
std::allocatorllvm::PassInfo const*  ,
__gnu_cxx::__normal_iteratorllvm::PassInfo const* const*,
std::__cxx1998::vectorllvm::PassInfo const*, std::allocatorllvm::PassInfo
const*   
__gnu_parallel::find_template__gnu_cxx::__normal_iteratorllvm::PassInfo
const* const*, std::__cxx1998::vectorllvm::PassInfo const*,
std::allocatorllvm::PassInfo const*  ,
__gnu_cxx::__normal_iteratorllvm::PassInfo const* const*,
std::__cxx1998::vectorllvm::PassInfo const*, std::allocatorllvm::PassInfo
const*  , std::binder2nd__gnu_parallel::equal_tollvm::PassInfo const*,
llvm::PassInfo const* const ,
__gnu_parallel::find_if_selector(__gnu_cxx::__normal_iteratorllvm::PassInfo
const* const*, std::__cxx1998::vectorllvm::PassInfo const*,
std::allocatorllvm::PassInfo const*  ,
__gnu_cxx::__normal_iteratorllvm::PassInfo const* const*,
std::__cxx1998::vectorllvm::PassInfo const*, std::allocatorllvm::PassInfo
const*  , __gnu_cxx::__normal_iteratorllvm::PassInfo const* const*,
std::__cxx1998::vectorllvm::PassInfo const*, std::allocatorllvm::PassInfo
const*  , std::binder2nd__gnu_parallel::equal_tollvm::PassInfo const*,
llvm::PassInfo const* const , __gnu_parallel::find_if_selector,
__gnu_parallel::constant_size_blocks_tag) ()
   from /home/edwin/clam/git/publicgitgit/libclamav/.libs/libclamav.so.6
#5  0x7f51913dc9b1 in std::pair__gnu_cxx::__normal_iteratorllvm::PassInfo
const* const*, std::__cxx1998::vectorllvm::PassInfo const*,
std::allocatorllvm::PassInfo const*  ,
__gnu_cxx::__normal_iteratorllvm::PassInfo const* const*,
std::__cxx1998::vectorllvm::PassInfo const*, std::allocatorllvm::PassInfo
const*   
__gnu_parallel::find_template__gnu_cxx::__normal_iteratorllvm::PassInfo
const* const*, std::__cxx1998::vectorllvm::PassInfo const*,
std::allocatorllvm::PassInfo const*  ,
__gnu_cxx::__normal_iteratorllvm::PassInfo const* 

[Bug libstdc++/42624] libstdc++ parallel mode deadlocks in barrier

[edwintorok at gmail dot com]

--- Comment #1 from edwintorok at gmail dot com  2010-01-05 18:09 ---
(In reply to comment #0)
 $ make -j4

This should have been: make CCLD=g++ -j4


-- 


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

[Bug fortran/42568] [Cygwin] BLOCKDATA referenced in EXTERNAL not loading from library

[dominiq at lps dot ens dot fr]

--- Comment #23 from dominiq at lps dot ens dot fr  2010-01-05 18:12 ---
This looks like a duplicate of pr34136.


-- 


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

[Bug fortran/34136] Add entry point and symbol for linker

[dominiq at lps dot ens dot fr]

--- Comment #19 from dominiq at lps dot ens dot fr  2010-01-05 18:15 ---
pr42568 looks like a duplicate of this one.

Note that the issue seems fixed on darwin10.


-- 


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

[Bug target/42601] Simplify code to address function static variables with option -fpic

[ramana at gcc dot gnu dot org]

--- Comment #1 from ramana at gcc dot gnu dot org  2010-01-05 18:20 ---
Confirmed but definitely an enhancement. 


-- 

ramana at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-01-05 18:20:29
   date||


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

[Bug fortran/34136] Add entry point and symbol for linker

[howarth at nitro dot med dot uc dot edu]

--- Comment #20 from howarth at nitro dot med dot uc dot edu  2010-01-05 
18:27 ---
(In reply to comment #19)
 pr42568 looks like a duplicate of this one.
 
 Note that the issue seems fixed on darwin10.
 

This issue was radr://5613343 and has been fixed for darwin10 and later.


-- 


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

[Bug rtl-optimization/42499] Bad register allocation in multiplication code by constant

[ramana at gcc dot gnu dot org]

--- Comment #2 from ramana at gcc dot gnu dot org  2010-01-05 18:28 ---
Why is there no load of tv.tv_usec in the code generated that you've pasted?
Are you sure you've pasted this right ? 

With 4.4 arm-eabi - 17/12/2009 snapshot I see the following code ?

for -march=armv5te -mthumb -Os . Are you sure you have given the right options
here ? 



.arch armv5te
.fpu softvfp
.eabi_attribute 20, 1
.eabi_attribute 21, 1
.eabi_attribute 23, 3
.eabi_attribute 24, 1
.eabi_attribute 25, 1
.eabi_attribute 26, 1
.eabi_attribute 30, 4
.eabi_attribute 18, 4
.code   16
.file   t.c
.global __aeabi_idiv
.text
.align  2
.global test
.code   16
.thumb_func
.type   test, %function
test:
push{r4, r5, r6, r7, lr}
sub sp, sp, #28
add r4, sp, #16
str r0, [sp, #12]
mov r0, r4
bl  get_time
mov r1, #250
ldr r0, [r4, #4]
lsl r1, r1, #2
bl  __aeabi_idiv
ldr r7, [sp, #16]
mov r3, r7
asr r7, r7, #31
mov r4, r7
lsl r7, r7, #5
lsr r1, r3, #27
mov r2, r7
orr r2, r2, r1
str r2, [sp, #4]
mov r5, r0
asr r6, r0, #31
lsl r0, r3, #5
str r0, [sp]
ldr r0, [sp]
ldr r1, [sp, #4]
sub r0, r0, r3
sbc r1, r1, r4
str r0, [sp]
str r1, [sp, #4]
ldr r1, [sp]
ldr r7, [sp, #4]
lsr r0, r1, #30
lsl r2, r7, #2
orr r2, r2, r0
ldr r0, [sp]
lsl r1, r0, #2
mov r0, r1
mov r1, r2
add r0, r0, r3
adc r1, r1, r4
lsr r4, r0, #29
lsl r3, r1, #3
orr r3, r3, r4
ldr r1, [sp, #12]
lsl r2, r0, #3
add r5, r5, r2
adc r6, r6, r3
add sp, sp, #28
str r5, [r1]
str r6, [r1, #4]
@ sp needed for prologue
pop {r4, r5, r6, r7, pc}
.size   test, .-test
.ident  GCC: (GNU) 4.4.3 20091217 (prerelease)


-- 

ramana at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING


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

[Bug tree-optimization/42286] October 23rd change to tree-ssa-pre.c breaks calculix on powerpc with -ffast-math

[meissner at linux dot vnet dot ibm dot com]

--- Comment #11 from meissner at linux dot vnet dot ibm dot com  2010-01-05 
18:40 ---
Subject: Re:  October 23rd change to tree-ssa-pre.c breaks calculix on powerpc
with -ffast-math

On Tue, Jan 05, 2010 at 04:03:17PM -, rguenther at suse dot de wrote:
 
 
 --- Comment #9 from rguenther at suse dot de  2010-01-05 16:03 ---
 Subject: Re:  October 23rd change to tree-ssa-pre.c
  breaks calculix on powerpc with -ffast-math
 
 On Tue, 5 Jan 2010, segher at kernel dot crashing dot org wrote:
 
  --- Comment #7 from segher at kernel dot crashing dot org  2010-01-05 
  15:57 ---
  With -fno-signed-zeroes, a-b*c is transformed to -(b*c-a), which is a 
  machine
  instruction.  If the result would have been +0 before, it now is -0.
  The code then takes the sqrt() of that; sqrt(-0) is -0.  This then is
  passed to atan2(), which has a discontinuity at 0, and we get wildly
  diverging results.
  
  The compiler does nothing wrong here; the transformation is perfectly
  valid.
  
  A solution might be to transform e.g. atan2(x,y) into atan2(+0.+x,+0.+y)
  when -fno-signed-zeroes is in effect (and of course somehow make sure
  those additions aren't optimised away).  Similar for other math library
  functions with discontinuities at +/- 0.
 
 Right.  Just it might be simpler with -fno-signed-zeros to
 transform a-b*c to 0 + -(b*c-a).  Of course if the result was -0
 before then it will be +0 after either variant (and the atan2 
 discontinuity would still happen even with your fix).
 
 Thus whatever fix the underlying problem is surely that calculix
 is not really -fno-signed-zeros safe.  Can't we get lucky again
 as before by trying to recover the PRE code change?

I've come to the conclusion that the compiler is doing the correct action in
terms fo the FMA, and that we should not remove the current optimizations.

I suspect the AMD/Intel folks will see this also when the AVX/FMA4 hardware
shows up since they also have FMA instructions that generate -0.0 in this
case.  I don't recall when I was doing the old SSE5 support whether we had run
the tests through the simulator with -ffast-math or not.

However, I dunno whether there should be a -fno-signed-zeroes version of atan2
that does not give a different result for the function atan2 (-0.0, 1.0) than
for atan2 (0.0, 1.0).  I know in the past, we've floated ideas about having a
fast math library that doesn't worry about Nans/negative 0/etc.  Or whether
Fortran needs such a wrapper since I don't believe signed zeroes are a Fortran
concept.

For my SPEC runs, I now use the GNU ld --wrap function for atan2, and 'fix' the
negative zeroes by adding 0.0:

static double zero = 0.0;

extern double __real_atan2 (double, double);

double
__wrap_atan2 (double x, double y)
{
  return __real_atan2 (x + zero, y + zero);
}


-- 


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

[Bug tree-optimization/42157] [4.5 regression] ICE building stage 1 libgcc: SEGV in compare_access_positions

[jamborm at gcc dot gnu dot org]

--- Comment #12 from jamborm at gcc dot gnu dot org  2010-01-05 18:46 
---
I posted a slightly simpler patch to the mailing list:
http://gcc.gnu.org/ml/gcc-patches/2010-01/msg00229.html


-- 


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

[Bug libfortran/42420] libgfortran fails to open large files on MINGW32

[jb at gcc dot gnu dot org]

--- Comment #9 from jb at gcc dot gnu dot org  2010-01-05 19:14 ---
Closing as fixed.


-- 

jb at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug libstdc++/42624] libstdc++ parallel mode deadlocks in barrier

[paolo dot carlini at oracle dot com]

--- Comment #2 from paolo dot carlini at oracle dot com  2010-01-05 19:22 
---
The best we can do is asking the attention of Johannes...


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 CC||singler at ira dot uka dot
   ||de


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

[Bug tree-optimization/42462] [4.5 Regression] wrong-code with computed-goto

[jamborm at gcc dot gnu dot org]

--- Comment #6 from jamborm at gcc dot gnu dot org  2010-01-05 19:42 ---
Subject: Bug 42462

Author: jamborm
Date: Tue Jan  5 19:42:32 2010
New Revision: 155658

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155658
Log:
2010-01-05  Martin Jambor  mjam...@suse.cz

PR tree-optimization/42462
* ipa-inline.c (compute_inline_parameters): Pass node-decl instead of
current_function_decl to helper functions and macros.

* gcc/testsuite/g++.dg/torture/pr42462.C: New test.


Added:
trunk/gcc/testsuite/g++.dg/torture/pr42462.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/ipa-inline.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug tree-optimization/42462] [4.5 Regression] wrong-code with computed-goto

[jamborm at gcc dot gnu dot org]

--- Comment #7 from jamborm at gcc dot gnu dot org  2010-01-05 19:44 ---
Fixed.


-- 

jamborm at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug c++/42346] darwin instantiation vs. optimization oddity

[howarth at nitro dot med dot uc dot edu]

--- Comment #9 from howarth at nitro dot med dot uc dot edu  2010-01-05 
19:52 ---
Might this bug be related to PR40459? Does the PR42346 test case work on gcc
pre-r148492?


-- 


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

[Bug libstdc++/38081] time_get::do_get_weekday does not always recognize full names of weekdays

[paolo at gcc dot gnu dot org]

--- Comment #4 from paolo at gcc dot gnu dot org  2010-01-05 20:05 ---
Subject: Bug 38081

Author: paolo
Date: Tue Jan  5 20:05:20 2010
New Revision: 155659

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155659
Log:
2010-01-05  Paolo Carlini  paolo.carl...@oracle.com

PR libstdc++/38081
* include/bits/locale_facets_nonio.h (time_get::
_M_extract_wday_or_month): New, declare.
* include/bits/locale_facets_nonio.tcc (time_get::
_M_extract_wday_or_month): Define.
(time_get::do_get_weekday, time_get::do_get_monthname): Use it.
* config/abi/pre/gnu.ver: Export new symbols.
* doc/xml/manual/prerequisites.xml: Add ru_RU.UTF-8 and
ru_RU.ISO-8859-5.
* testsuite/lib/libstdc++.exp: Adjust.
* testsuite/22_locale/time_get/get_weekday/char/38081-1.cc: New.
* testsuite/22_locale/time_get/get_weekday/char/38081-2.cc: Likewise.



Added:
trunk/libstdc++-v3/testsuite/22_locale/time_get/get_weekday/char/38081-1.cc
trunk/libstdc++-v3/testsuite/22_locale/time_get/get_weekday/char/38081-2.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/config/abi/pre/gnu.ver
trunk/libstdc++-v3/doc/xml/manual/prerequisites.xml
trunk/libstdc++-v3/include/bits/locale_facets_nonio.h
trunk/libstdc++-v3/include/bits/locale_facets_nonio.tcc
trunk/libstdc++-v3/testsuite/lib/libstdc++.exp


-- 


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

[Bug libstdc++/38081] time_get::do_get_weekday does not always recognize full names of weekdays

[paolo dot carlini at oracle dot com]

--- Comment #5 from paolo dot carlini at oracle dot com  2010-01-05 20:10 
---
Fixed.


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

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


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

[Bug c++/42623] [C++0x] Function template default arguments: Invalid expressions are allowed

[jason at gcc dot gnu dot org]

-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jason at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-01-05 20:18:23
   date||


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

[Bug c++/42623] [C++0x] Function template default arguments: Invalid expressions are allowed

[jason at gcc dot gnu dot org]

--- Comment #1 from jason at gcc dot gnu dot org  2010-01-05 20:22 ---
Created an attachment (id=19473)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19473action=view)
fix

Here's a fix.  Since this touches language-independent code and the bug isn't a
regression, I'm not going to apply it to 4.5 at this time.


-- 


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

[Bug tree-optimization/42625] New: -fipa-sra can generate different destructors in different object files, binary breaks after linking

[zsojka at seznam dot cz]

Tested revisions:
r155643 - broken
r155256 - broken
r154886 - broken
r154830 - OK

Command line:
in original testcases, all files are compiled with the same compiler parameters
for this reduced testcase, one file is compiled with -O1 -fipa-sra, second
with just -O1
if -fipa-sra is expected to generate the same code independently on where the
function (destructor) is called from, I will open separate bugreport for that

Output:
g++ file1.cpp -O1 -fipa-sra -c  g++ file2.cpp -O1 -c  g++ file1.o file2.o
 ./a.out
a.out: header.h:8: Object::~Object(): Assertion `i == 1' failed.

 header.h ===
#include assert.h

struct Object {
int a, i;
Object() : i(1) {};
__attribute__((noinline)) ~Object()
{
assert(i == 1);
}
void del();
};
 file1.cpp ==
#include header.h

int main()
{
delete new Object();
(new Object())-del();
return 0;
}
 file1.cpp ==
#include header.h

void Object::del()
{
delete this;
}
=


-- 
   Summary: -fipa-sra can generate different destructors in
different object files, binary breaks after linking
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: zsojka at seznam dot cz
  GCC host triplet: x86_64-pc-linux-gnu


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

[Bug tree-optimization/42625] -fipa-sra can generate different destructors in different object files, binary breaks after linking

[zsojka at seznam dot cz]

--- Comment #1 from zsojka at seznam dot cz  2010-01-05 20:35 ---
Created an attachment (id=19474)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19474action=view)
packed files (testcase)


-- 


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

[Bug ada/42626] New: gcc/ada/Makefile.in has missing quote

[simon at pushface dot org]

A missing quote prevents building the RTS.


-- 
   Summary: gcc/ada/Makefile.in has missing quote
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: simon at pushface dot org
  GCC host triplet: x86_64-apple-darwin10


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

[Bug ada/42626] gcc/ada/Makefile.in has missing quote

[simon at pushface dot org]

--- Comment #1 from simon at pushface dot org  2010-01-05 20:40 ---
Created an attachment (id=19475)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19475action=view)
Patch to gcc/ada/Makefile.in


-- 


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

[Bug target/42542] Vectorizer produces incorrect results on max/min of unsigned intergers

[hjl at gcc dot gnu dot org]

--- Comment #13 from hjl at gcc dot gnu dot org  2010-01-05 20:44 ---
Subject: Bug 42542

Author: hjl
Date: Tue Jan  5 20:44:14 2010
New Revision: 155660

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155660
Log:
Properly convert GTU to GT for V4SI and V2DI

gcc/

2010-01-05  Paolo Bonzini  bonz...@gnu.rg
H.J. Lu  hongjiu...@intel.com

PR target/42542
* config/i386/i386.c (ix86_expand_int_vcond): Convert GTU to GT
for V4SI and V2DI by subtracting (-(INT MAX) - 1) from both
operands to make them signed.

* config/i386/sse.md (umaxv4si3): Revert the last change.
(uminmode3): Likewise.
(uminv8hi3): Removed.
(uminv4si3): Likewise.

gcc/testsuite/

2010-01-05  H.J. Lu  hongjiu...@intel.com

* gcc.target/i386/pr42542-1.c (res): Make it 8 elements.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/config/i386/sse.md
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/i386/pr42542-1.c


-- 


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

[Bug bootstrap/42511] bootstrap error in stage3 on alpha-linux-gnu

[ubizjak at gmail dot com]

--- Comment #12 from ubizjak at gmail dot com  2010-01-05 20:47 ---
Got the problem. stage1 compiler miscompiles determine_max_movement() from
tree-ssa-loop-im.c.

Following patch fixes the testcase from comment #5:

Index: tree-ssa-loop-im.c
===
--- tree-ssa-loop-im.c  (revision 155643)
+++ tree-ssa-loop-im.c  (working copy)
@@ -677,6 +677,7 @@
 level = superloop_at_depth (loop, 1);
   lim_data-max_loop = level;

+  debug_gimple_stmt (stmt);
   FOR_EACH_SSA_TREE_OPERAND (val, stmt, iter, SSA_OP_USE)
 if (!add_dependency (val, lim_data, loop, true))
   return false;

I will restart bootstrap now.


-- 


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

[Bug tree-optimization/42625] -fipa-sra can generate different destructors in different object files, binary breaks after linking

[jakub at gcc dot gnu dot org]

--- Comment #2 from jakub at gcc dot gnu dot org  2010-01-05 21:10 ---
I guess cgraph_make_node_local needs to update all same_body aliases (in
particular clear DECL_WEAK which etc. which made the alias externally visible).


-- 


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

[Bug bootstrap/42511] bootstrap error in stage3 on alpha-linux-gnu

[ubizjak at gmail dot com]

--- Comment #13 from ubizjak at gmail dot com  2010-01-05 21:15 ---
(In reply to comment #12)

 I will restart bootstrap now.

Bootstraps OK for --enable-languages=c.


-- 


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

[Bug tree-optimization/42625] -fipa-sra can generate different destructors in different object files, binary breaks after linking

[jakub at gcc dot gnu dot org]

--- Comment #3 from jakub at gcc dot gnu dot org  2010-01-05 21:26 ---
Created an attachment (id=19476)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19476action=view)
gcc45-pr42625.patch

Untested fix.  No idea how to create a testcase though, dg-additional-sources
are compiled using the same command and this needs the sources compiled with
different options.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jakub at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED


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

[Bug rtl-optimization/42621] [4.4/4.5 Regression] Computed gotos on AMD 800% slower

[steven at gcc dot gnu dot org]

--- Comment #2 from steven at gcc dot gnu dot org  2010-01-05 21:51 ---
Caused by revision 139760.
http://gcc.gnu.org/viewcvs?view=revisionrevision=139760


-- 


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

[Bug rtl-optimization/42621] [4.4/4.5 Regression] Computed gotos on AMD 800% slower

[pinskia at gcc dot gnu dot org]

--- Comment #3 from pinskia at gcc dot gnu dot org  2010-01-05 21:56 ---
So the profiling information (which is not always accurate without real
profiling) says the code is not executed that often.  I guess someone needs to
tune them better for computed gotos unless people really want to do profiling
runs first to get better performance ...


-- 


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