[Bug tree-optimization/37879] [4.3/4.4 Regression] ICE with "wrong" use of noreturn attribute and optimization

[cnstar9988 at gmail dot com]

--- Comment #5 from cnstar9988 at gmail dot com  2008-10-30 06:57 ---
fixed in gcc 4.3 branch?


-- 


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

[Bug c/37955] internal compiler error: in vectorizable_store, at tree-vect-transform.c:5447

[alon dot barlev at gmail dot com]

--- Comment #3 from alon dot barlev at gmail dot com  2008-10-30 06:45 
---
Created an attachment (id=16587)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16587&action=view)
sample2.c

Maybe the complete source will be better...

$ x86_64-pc-mingw32-gcc -O3 -c sample2.c
e_aep.c: In function ‘aep_get_connection’:
e_aep.c:862: internal compiler error: in vectorizable_store, at
tree-vect-transform.c:5447
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


-- 


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

[Bug middle-end/37928] [graphite] ICE :Segmentation fault

[grosser at gcc dot gnu dot org]

--- Comment #3 from grosser at gcc dot gnu dot org  2008-10-30 04:28 ---
(From update of attachment 16586)
This patch was thought for another bug.


-- 

grosser at gcc dot gnu dot org changed:

   What|Removed |Added

  Attachment #16586|0   |1
is obsolete||


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

[Bug middle-end/37928] [graphite] ICE :Segmentation fault

[grosser at gcc dot gnu dot org]

-- 

grosser at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||grosser at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-10-30 04:16:30
   date||


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

[Bug middle-end/37928] [graphite] ICE :Segmentation fault

[grosser at gcc dot gnu dot org]

--- Comment #2 from grosser at gcc dot gnu dot org  2008-10-30 04:15 ---
Created an attachment (id=16586)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16586&action=view)
Add POINTER_PLUS_EXPR - Improvement?

It seems we miss the POINTER_PLUS_EXPR. In most cases in tree-scalar-evol.c and
tree-chrec.c it is handled like a PLUS_EXPR. If I add it, the test case passes
the front end, but fails again in gloog() with:
#0  0x089d919f in link_imm_use (linknode=0x29072c4c, def=0x20017) at
tree-flow-inline.h:323
#1  0x089d914e in set_ssa_use_from_ptr (use=0x29072c4c, val=0x20017) at
tree-flow-inline.h:342
#2  0x089d9097 in graphite_rename_variables_in_stmt (stmt=0x29060528,
map=0x8d8b040)
at ../../../git/gcc/graphite.c:3512
#3  0x089d9b89 in graphite_rename_variables (bb=0x29060618, map=0x8d8b040)
at ../../../git/gcc/graphite.c:3685
#4  0x089da177 in translate_clast (scop=0x8d321c0, context_loop=0x29100948,
stmt=0x8d8a350, 
next_e=0x290c2988, ivstack=0xbfbfe880) at ../../../git/gcc/graphite.c:3816
#5  0x089d9fbd in translate_clast (scop=0x8d321c0, context_loop=0x29100948,
stmt=0x8d8a110, 
next_e=0x290c25c8, ivstack=0xbfbfe880) at ../../../git/gcc/graphite.c:3781


I will have to think about the patch. Opinions?


-- 


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

[Bug middle-end/37883] [graphite] ICE : in scan_tree_for_params, at graphite.c:2274

[grosser at gcc dot gnu dot org]

-- 

grosser 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-10-30 04:10:22
   date||


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

[Bug target/37437] [4.4 regression] speed regression

[hjl dot tools at gmail dot com]

--- Comment #4 from hjl dot tools at gmail dot com  2008-10-30 02:04 ---
Change Core 2 cost with

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37948#c1

doesn't help. Re-enable regmove with

http://gcc.gnu.org/bugzilla/attachment.cgi?id=16571

fixes the performance regression.


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-10-30 02:04:28
   date||


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

[Bug middle-end/37929] [graphite] ICE :in single_succ_edge, at basic-block.h:642

[grosser at gcc dot gnu dot org]

--- Comment #2 from grosser at gcc dot gnu dot org  2008-10-30 01:47 ---
Under FreeBSD x68 this works in trunk and branch.


-- 

grosser at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||grosser at gcc dot gnu dot
   ||org


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

[Bug debug/36668] [4.4 Regression] FAIL: g++.dg/other/PR23205.C scan-assembler .stabs.*foobar:c=i

[jakub at gcc dot gnu dot org]

--- Comment #7 from jakub at gcc dot gnu dot org  2008-10-30 00:49 ---
Fixed.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug bootstrap/37639] Bootstrap fails with "may be used uninitialized" warning in c-parser.c

[lucier at math dot purdue dot edu]

--- Comment #3 from lucier at math dot purdue dot edu  2008-10-30 00:19 
---
You're right, it was fixed by 

Revision 141193 - (view) (download) - [select for diffs]
Modified Fri Oct 17 14:50:07 2008 UTC (12 days, 9 hours ago) by krebbel
File length: 238566 byte(s)
Diff to previous 140914 (colored)

2008-10-17  Andreas Krebbel  <[EMAIL PROTECTED]>

* c-parser.c (c_parser_binary_expression): Silence the
uninitialized variable warning emitted for binary_loc.


I hadn't noticed because I started adding --disable-werror to my configuration
files.

Closing as fixed.


-- 

lucier at math dot purdue dot edu changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||FIXED


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

[Bug debug/36668] [4.4 Regression] FAIL: g++.dg/other/PR23205.C scan-assembler .stabs.*foobar:c=i

[jakub at gcc dot gnu dot org]

--- Comment #6 from jakub at gcc dot gnu dot org  2008-10-30 00:11 ---
Subject: Bug 36668

Author: jakub
Date: Thu Oct 30 00:11:23 2008
New Revision: 141453

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141453
Log:
PR debug/36668
* g++.dg/other/PR23205.C: Allow foobar to be defined as variable.
* g++.dg/other/pr23205-2.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/other/pr23205-2.C
Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/other/PR23205.C


-- 


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

[Bug bootstrap/37639] Bootstrap fails with "may be used uninitialized" warning in c-parser.c

[manu at gcc dot gnu dot org]

--- Comment #2 from manu at gcc dot gnu dot org  2008-10-30 00:09 ---
What revision is this? Seems fixed in mainline.


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug target/37878] [4.4 regression] PPC64 ldu command generated with invalid offset

[lucier at math dot purdue dot edu]

--- Comment #14 from lucier at math dot purdue dot edu  2008-10-30 00:02 
---
Thank you, this fixes the original bug.

I took the liberty of closing this bug report.

Thanks again.

Brad


-- 

lucier at math dot purdue dot edu changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug target/37909] internal compiler error: in fixup_mova, at config/sh/sh.c:3756

[kkojima at gcc dot gnu dot org]

--- Comment #5 from kkojima at gcc dot gnu dot org  2008-10-29 23:54 ---
Subject: Bug 37909

Author: kkojima
Date: Wed Oct 29 23:54:35 2008
New Revision: 141452

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141452
Log:
PR target/37909
* config/sh/sh.c (untangle_mova): Return -1 when NEW_MOVA has
no address.


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


-- 


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

[Bug rtl-optimization/33642] unrecognizable insn for -frtl-abstract-sequences

[jakub at gcc dot gnu dot org]

--- Comment #31 from jakub at gcc dot gnu dot org  2008-10-29 23:33 ---
Any progress on this patch?  IMHO an option that doesn't work on most of the
primary and secondary arches deserves to be disabled.


-- 


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

[Bug target/37878] [4.4 regression] PPC64 ldu command generated with invalid offset

[dje at gcc dot gnu dot org]

--- Comment #13 from dje at gcc dot gnu dot org  2008-10-29 23:33 ---
Subject: Bug 37878

Author: dje
Date: Wed Oct 29 23:33:02 2008
New Revision: 141450

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141450
Log:
PR target/37878
* config/rs6000/predicates.md (word_offset_memref_operand):
Restructure code and look inside auto-inc/dec addresses.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/predicates.md


-- 


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

[Bug middle-end/37951] -ftree-parallelize-loops=2 fails for MA57

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2008-10-29 22:46 ---
The cfg manipulation code on the branch has the same "bug" as on the trunk.


-- 


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

[Bug middle-end/37951] -ftree-parallelize-loops=2 fails for MA57

[pinskia at gcc dot gnu dot org]

--- Comment #3 from pinskia at gcc dot gnu dot org  2008-10-29 22:42 ---
(In reply to comment #1)
> May be related to PR37485.

I highly doubt it is related to that PR as this is reported against 4.3.2 and
graphite was not in 4.3.x.


-- 


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

[Bug ada/37956] New: ACATS ac3207a sometimes hangs in system.tasking.stages.vulnerable_complete_master

[laurent at guerby dot net]

On my continuous tester I noticed that with trunk ac3207a sometimes hangs.
Using a slightly modified testcase and a shell loop I managed to reproduce it
after one hour of looping (140k loop exec), please find below the gdb
backtrace.

$ gcc -v
gcc version 4.4.0 20081029 (experimental) [trunk revision 141434] (GCC) 
$ gnatmake -O2 ac3207a
$ while true; do date;./ac3207a; done >& log.txt

$ gdb -p PID
(gdb) info thread
  1 Thread 46912500751824 (LWP 25669)  0x2abcbb3a in
pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0
(gdb) bt
#0  0x2abcbb3a in pthread_cond_wait@@GLIBC_2.3.2 () from
/lib/libpthread.so.0
#1  0x0040a953 in system.tasking.stages.vulnerable_complete_master ()
at s-tassta.adb:1620
#2  0x004031f0 in ac3207a___clean.3268 ()
#3  0x0040356c in _ada_ac3207a ()

$ cat ac3207a.adb
-- BEGIN SOURCE
with Ada.Text_Io;use Ada.Text_Io;

PROCEDURE AC3207A IS

 GENERIC
  TYPE PRIV IS LIMITED PRIVATE;
 PACKAGE GEN_P IS
  TASK T1 IS
   ENTRY E;
  END T1;
 END GEN_P;

 TASK TYPE TASK_T IS
 END TASK_T;

 TYPE REC IS
  RECORD
   OBJ : TASK_T;
  END RECORD;

 PACKAGE BODY GEN_P IS
  TASK BODY T1 IS
  BEGIN
   DECLARE
OBJ : PRIV;
   BEGIN
SELECT
 ACCEPT E;
OR
 TERMINATE;
END SELECT;
   END;
  END T1;
 END GEN_P;

 TASK BODY TASK_T IS
 BEGIN
  NULL;
 END;

 PACKAGE P IS NEW GEN_P(TASK_T);
 PACKAGE NEW_P IS NEW GEN_P(REC);

BEGIN

 P.T1.E;

 NEW_P.T1.E;

 Put_Line("ok");
END AC3207A;
-- END SOURCE


-- 
   Summary: ACATS ac3207a sometimes hangs in
system.tasking.stages.vulnerable_complete_master
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: laurent at guerby dot net
  GCC host triplet: x86_64-linux


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

[Bug c++/26693] [4.2/4.3/4.4 regression] Access checks not performed for types in templates

[dodji at gcc dot gnu dot org]

--- Comment #6 from dodji at gcc dot gnu dot org  2008-10-29 21:56 ---
I think the problem is due to the fact that in general, grokdeclarator() in
gcc/cp/decl.c does not properly set the type variant node for typedef
statements.

To understand this way of representing the relationship between a type and its
typedef names, please read the comment of function clone_underlying_type, in
gcc/c-decl.c.

So grokdeclarator() does not properly create the typedef type variant for the
typedef statement. Later, build_functional_cast in gcc/cp/typeck2.c looses the
information about the typedef. It just takes in account the initial type.

So later at templater instanciation time, there is no chance left to check the
access of the typedef name, as we only know about the initial type.

So in grokdeclarator() I think we should properly create the typedef type
variant for the typedef statement encountered during the parsing of a class
member.

Then later at template instanciation time we can have a chance to check for the
access of the typedef name as its information is still present via the typedef
type variant associated to the initial type.


-- 


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

[Bug c/37955] internal compiler error: in vectorizable_store, at tree-vect-transform.c:5447

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2008-10-29 21:12 ---
works for me on x86_64-linux.


-- 

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

[Bug fortran/37749] ICE on array section with vector subscript

[mikael dot morin at tele2 dot fr]

--- Comment #2 from mikael dot morin at tele2 dot fr  2008-10-29 21:06 
---
Created an attachment (id=16585)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16585&action=view)
proposed patch, regression tested

This patch solves the problem by going through all the loop dimensions in
gfc_trans_create_temp_array to look for a NULL loop->to before the actual loop
execution and set size to NULL if one is found (it solves conditions (4) and
(5)).


-- 


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

[Bug fortran/37749] ICE on array section with vector subscript

[mikael dot morin at tele2 dot fr]

--- Comment #1 from mikael dot morin at tele2 dot fr  2008-10-29 20:59 
---
Reduced case:

subroutine subr (m, n, a, b, c, d, p)
  implicit none
  integer m, n
  real a(m,n), b(m,n), c(n,n), d(m,n)
  integer p(n)
  d = a(:,p) - matmul(b, c)
end subroutine


The problem is with a(:,p) - matmul(b,c)

It arises because:
(1) gfc_conv_loop_setup chooses matmul's ss to setup the loop bounds. 
This explains why -matmul(b,c) + a(:,p) works.
(2) The loop->to are asserted to be NULL in gfc_conv_loop_setup
(GFC_SS_FUNCTION case)
(3) gfc_add_ss_loop_code for the second dimension of a(:,p) calls
gfc_set_loop_bounds_from_array_spec which sets the second dimension of
the loop.to
(4) in the loop setting the descriptor in gfc_trans_create_temp_array, 
in the first iteration, (n = 0), loop.to is NULL, and the size is set to
NULL. 
(5) In the next iteration, (n = 1), loop.to != NULL, and the loop follows
the normal path. The size however was set to NULL (condition (4)).


(4) and (5) explain why it works with a(q,:) - matmul(b,c)


-- 


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

[Bug c/37955] internal compiler error: in vectorizable_store, at tree-vect-transform.c:5447

[alon dot barlev at gmail dot com]

--- Comment #1 from alon dot barlev at gmail dot com  2008-10-29 20:28 
---
Created an attachment (id=16584)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16584&action=view)
sample1.c

sample1.c: In function ‘aep_rsa_mod_exp’:
sample1.c:619: internal compiler error: in vectorizable_store, at
tree-vect-transform.c:5447
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


-- 


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

[Bug middle-end/37943] [graphite] ICE : in build_graphite_scops, at graphite.c:1823

[grosser at gcc dot gnu dot org]

--- Comment #2 from grosser at gcc dot gnu dot org  2008-10-29 20:28 ---
Created an attachment (id=16583)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16583&action=view)
Bugfix


-- 


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

[Bug c/37955] New: internal compiler error: in vectorizable_store, at tree-vect-transform.c:5447

[alon dot barlev at gmail dot com]

Attached is a sample from OpenSSL.
When compiled with -O3 the error comes up.

I tried to remove as much code as I could, but it looks like every line I
remove also avoid the error.

I use rev141361


-- 
   Summary: internal compiler error: in vectorizable_store, at tree-
vect-transform.c:5447
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: alon dot barlev at gmail dot com
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: x86_64-pc-mingw32


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

[Bug c/37954] odd sized packed structures, under ARM, cause lockup of application

[damon dot michaels at navico dot com]

--- Comment #5 from damon dot michaels at navico dot com  2008-10-29 19:53 
---
Created an attachment (id=16582)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16582&action=view)
requested options


-- 


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

[Bug c/37954] odd sized packed structures, under ARM, cause lockup of application

[damon dot michaels at navico dot com]

--- Comment #4 from damon dot michaels at navico dot com  2008-10-29 19:52 
---
Created an attachment (id=16581)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16581&action=view)
requested .ii file


-- 


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

[Bug c/37954] odd sized packed structures, under ARM, cause lockup of application

[damon dot michaels at navico dot com]

--- Comment #3 from damon dot michaels at navico dot com  2008-10-29 19:52 
---
Created an attachment (id=16580)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16580&action=view)
.c source file


-- 


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

[Bug target/32277] indir-call-prof fails on ia64-linux-gnu

[sje at cup dot hp dot com]

--- Comment #4 from sje at cup dot hp dot com  2008-10-29 19:49 ---
Fixed with patch to libgcov.c


-- 

sje at cup dot hp dot com changed:

   What|Removed |Added

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


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

[Bug c/37954] odd sized packed structures, under ARM, cause lockup of application

[damon dot michaels at navico dot com]

--- Comment #2 from damon dot michaels at navico dot com  2008-10-29 19:49 
---
Subject: RE:  odd sized packed structures, under ARM, cause lockup of
application

Yes, I'm figuring out how to move it from VMWare to my Windows system.

It is unexpected to me.  X86 doesn't do it under 3 different compilers
(one of which is GCC).  I understand why under ARM it does it at the
assembly level.

I'm completely new to Linux, and this bug reporting mechanism.  Although
I'm an old Unix hand from 1983... it's all coming back to me now. 
So please bear with me!


Thx,

-D
-Original Message-
From: pinskia at gcc dot gnu dot org [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, October 29, 2008 3:44 PM
To: Damon Michaels
Subject: [Bug c/37954] odd sized packed structures, under ARM, cause
lockup of application



--- Comment #1 from pinskia at gcc dot gnu dot org  2008-10-29 19:44
---
Do you have an example code that shows this?  I almost want to say this
is
expected behavior.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added


   Severity|blocker |normal


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

--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.
You reported the bug, or are watching the reporter.


-- 


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

[Bug target/32277] indir-call-prof fails on ia64-linux-gnu

[sje at gcc dot gnu dot org]

--- Comment #3 from sje at gcc dot gnu dot org  2008-10-29 19:46 ---
Subject: Bug 32277

Author: sje
Date: Wed Oct 29 19:46:16 2008
New Revision: 141442

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141442
Log:
PR target/32277
* libgcov.c ( __gcov_indirect_call_profiler): Check
TARGET_VTABLE_USES_DESCRIPTORS.

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


-- 


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

[Bug c/37954] odd sized packed structures, under ARM, cause lockup of application

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2008-10-29 19:44 ---
Do you have an example code that shows this?  I almost want to say this is
expected behavior.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|blocker |normal


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

[Bug middle-end/37339] [4.4 Regression] gcc.dg/pr33645-3.c scan-assembler-not var1_t

[sje at cup dot hp dot com]

--- Comment #7 from sje at cup dot hp dot com  2008-10-29 19:43 ---
Deleted test as it is no longer valid since we don't support
non-unit-at-a-time.


-- 

sje at cup dot hp dot com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug c/37954] New: odd sized packed structures, under ARM, cause lockup of application

[damon dot michaels at navico dot com]

It appears that although an array of packed structures is done correctly, when
a routine is called that references an element of said packed structures the
compiler believes it to be word aligned.


-- 
   Summary: odd sized packed structures, under ARM, cause lockup of
application
   Product: gcc
   Version: 4.3.1
Status: UNCONFIRMED
  Severity: blocker
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: damon dot michaels at navico dot com


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

[Bug middle-end/37339] [4.4 Regression] gcc.dg/pr33645-3.c scan-assembler-not var1_t

[sje at gcc dot gnu dot org]

--- Comment #6 from sje at gcc dot gnu dot org  2008-10-29 19:41 ---
Subject: Bug 37339

Author: sje
Date: Wed Oct 29 19:41:26 2008
New Revision: 141440

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141440
Log:
PR middle-end/37339
* gcc.dg/pr33545-3.c: Remove.

Removed:
trunk/gcc/testsuite/gcc.dg/pr33645-3.c
Modified:
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug debug/36668] [4.4 Regression] FAIL: g++.dg/other/PR23205.C scan-assembler .stabs.*foobar:c=i

[jakub at gcc dot gnu dot org]

--- Comment #5 from jakub at gcc dot gnu dot org  2008-10-29 19:14 ---
Actually, the behaviour of -fno-toplevel-reorder is documented this way:
`-funit-at-a-time'
 This option is left for compatibility reasons. `-funit-at-a-time'
 has no effect, while `-fno-unit-at-a-time' implies
 `-fno-toplevel-reorder' and `-fno-section-anchors'.

 Enabled by default.

`-fno-toplevel-reorder'
 Do not reorder top-level functions, variables, and `asm'
 statements.  Output them in the same order that they appear in the
 input file.  When this option is used, unreferenced static
 variables will not be removed.  This option is intended to support
 existing code which relies on a particular ordering.  For new
 code, it is better to use attributes.

 Enabled at level `-O0'.  When disabled explicitly, it also imply
 `-fno-section-anchors' that is otherwise enabled at `-O0' on some
 targets.

So I guess we want to change the testcase.


-- 


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

[Bug tree-optimization/37573] [4.4 Regression] gcc-4.4 regression: incorrect code generation with -O1 -ftree-vectorize

[edwintorok at gmail dot com]

--- Comment #13 from edwintorok at gmail dot com  2008-10-29 18:48 ---
I just noticed that this testcase also fails with -O3 on gcc version 4.1.2
20070626 (Red Hat 4.1.2-14), but works on gcc version 4.1.3 20080623
(prerelease) (Debian 4.1.2-23)


-- 

edwintorok at gmail dot com changed:

   What|Removed |Added

  Known to fail||4.1.2
  Known to work||4.1.3 4.3.2


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

[Bug middle-end/11492] Bogus warning with -Wsign-compare

[manu at gcc dot gnu dot org]

--- Comment #8 from manu at gcc dot gnu dot org  2008-10-29 17:24 ---
FIXED in GCC 4.4. Thanks for the report and sorry for the time this took!


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug middle-end/11492] Bogus warning with -Wsign-compare

[manu at gcc dot gnu dot org]

--- Comment #7 from manu at gcc dot gnu dot org  2008-10-29 17:17 ---
Subject: Bug 11492

Author: manu
Date: Wed Oct 29 17:16:46 2008
New Revision: 141434

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141434
Log:
2008-10-29  Manuel Lopez-Ibanez  <[EMAIL PROTECTED]>

PR 11492
* c-common.c (min_precision): Move to...
* tree.c (tree_int_cst_min_precision): ... to here. Renamed.
* tree.h (tree_int_cst_min_precision): Declare.
* c-common.h (min_precision): Delete declaration.
* fold-const.c (tree_binary_nonnegative_warnv_p): Handle
multiplication of non-negative integer constants.
* c-decl.c (check_bitfield_type_and_width): Rename min_precision to
tree_int_cst_min_precision.
(finish_enum): Likewise.
cp/
* class.c (check_bitfield_decl): Rename min_precision to
tree_int_cst_min_precision.
* decl.c (finish_enum): Likewise.
testsuite/
* gcc.dg/pr11492.c: New.
* g++.dg/warn/pr11492.C: New.

Added:
trunk/gcc/testsuite/g++.dg/warn/pr11492.C
trunk/gcc/testsuite/gcc.dg/pr11492.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/c-common.c
trunk/gcc/c-common.h
trunk/gcc/c-decl.c
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/class.c
trunk/gcc/cp/decl.c
trunk/gcc/fold-const.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree.c
trunk/gcc/tree.h


-- 


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

[Bug middle-end/36578] cast to long double not taken into account when result stored to a double

[jsm28 at gcc dot gnu dot org]

--- Comment #5 from jsm28 at gcc dot gnu dot org  2008-10-29 17:12 ---
Fixed for 4.4.


-- 

jsm28 at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug middle-end/36578] cast to long double not taken into account when result stored to a double

[jsm28 at gcc dot gnu dot org]

--- Comment #4 from jsm28 at gcc dot gnu dot org  2008-10-29 17:06 ---
Subject: Bug 36578

Author: jsm28
Date: Wed Oct 29 17:05:42 2008
New Revision: 141432

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141432
Log:
PR middle-end/36578
* convert.c (convert_to_real): Do not optimize conversions of
binary arithmetic operations between binary and decimal
floating-point types.  Consider mode of target type in determining
decimal type for arithmetic.  Unless
flag_unsafe_math_optimizations, do not optimize binary conversions
where this may change rounding behavior.
* real.c (real_can_shorten_arithmetic): New.
* real.h (real_can_shorten_arithmetic): Declare.

testsuite:
* gcc.dg/dfp/convert-bfp-13.c, gcc.dg/dfp/convert-bfp-14.c,
gcc.dg/dfp/convert-dfp-fold-2.c, gcc.target/i386/pr36578-1.c,
gcc.target/i386/pr36578-2.c: New tests.

Added:
trunk/gcc/testsuite/gcc.dg/dfp/convert-bfp-13.c
trunk/gcc/testsuite/gcc.dg/dfp/convert-bfp-14.c
trunk/gcc/testsuite/gcc.dg/dfp/convert-dfp-fold-2.c
trunk/gcc/testsuite/gcc.target/i386/pr36578-1.c
trunk/gcc/testsuite/gcc.target/i386/pr36578-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/convert.c
trunk/gcc/real.c
trunk/gcc/real.h
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug middle-end/29256] [4.2/4.3/4.4 regression] loop performance regression

[janis at gcc dot gnu dot org]

--- Comment #29 from janis at gcc dot gnu dot org  2008-10-29 17:05 ---
On powerpc-linux the submitter's testcase gets better code with the patch from
comment #17, but the same testcase with the loop starting with 1 instead of
zero gets worse code.  From the 4.1 branch with -O2:

.L2:
lfd 0,0(9)
addi 9,9,8
stfd 0,0(11)
addi 11,11,8
bdnz .L2

>From the 4.2 branch:

.L2:
add 9,10,0
add 11,10,8
addi 10,10,8
lfd 0,8(9)
stfd 0,8(11)
bdnz .L2

Code from current mainline is the same except for the order of the addi and lfd
instructions.


-- 

janis at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||janis at gcc dot gnu dot org


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

[Bug fortran/37953] undefined reference to '_gfortran_*'

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2008-10-29 17:00 ---
You should link using gfortran, that is

gfortran -c optnhp3ma.f middle3.f optnhp3.f
gfortran -o xxx optnhp3ma.o middle3.o optnhp3.o


-- 

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

[Bug fortran/37953] New: undefined reference to '_gfortran_*'

[successful dot jiang at gmail dot com]

hi there,
I am testing a package with three source files.
I saw lots of information about solving 'undefined reference to ###', but it
stucks me.

compile the object file with
   'gfortran -c optnhp3ma.f middle3.f optnhp3.f'

when I run these objects, coupled with a problem input. Things happen...

optnhp3ma.f:(.text+0x2c): undefined reference to `_gfortran_set_std'
optnhp3ma.f:(.text+0xe0): undefined reference to `_gfortran_st_write'
optnhp3ma.f:(.text+0xfe): undefined reference to `_gfortran_transfer_character'
optnhp3ma.f:(.text+0x163): undefined reference to `_gfortran_transfer_array'
optnhp3ma.f:(.text+0x171): undefined reference to `_gfortran_st_write_done'
optnhp3ma.f:(.text+0x1e3): undefined reference to `_gfortran_st_write'
optnhp3ma.f:(.text+0x201): undefined reference to
`_gfortran_transfer_character'
optnhp3ma.f:(.text+0x221): undefined reference to `_gfortran_transfer_real'
optnhp3ma.f:(.text+0x22f): undefined reference to `_gfortran_st_write_done'


How can solve this out? it is a little urgent...

if I add the -lgfortran, like that 'gfortran -c optnhp3ma.f middle3.f optnhp3.f
-L/usr/lib -lgfortran'

errro message:
'gfortran: -lgfortran: linker input file unused because linking not done'


Please give me a hand


-- 
   Summary: undefined reference to '_gfortran_*'
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: successful dot jiang at gmail dot com


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

[Bug other/37625] 32-bit bootstrap failure on darwin9

[sylvain dot pion at sophia dot inria dot fr]

--- Comment #2 from sylvain dot pion at sophia dot inria dot fr  2008-10-29 
16:36 ---
I have also seen this, and it seems that --with-libiconv-prefix=/sw/
does not do the trick anymore with the trunk (unless some other
difference in my setup is responsible for this).

Googleing a bit showed that the problem comes from the system iconv.h
under /usr/include, which conflicts with Fink's under /sw/.

A solution is to replace /usr/include/iconv.h by a symlink to
/sw/include/iconv.h.

Maybe there is a better solution, though.


-- 

sylvain dot pion at sophia dot inria dot fr changed:

   What|Removed |Added

 CC||sylvain dot pion at sophia
   ||dot inria dot fr


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

[Bug rtl-optimization/37782] [4.4 regression] Stage2 ada compiler miscompiled

[joel at gcc dot gnu dot org]

--- Comment #9 from joel at gcc dot gnu dot org  2008-10-29 16:30 ---
ACATS results for powerpc-rtems4.10 with the "maybefix"

http://gcc.gnu.org/ml/gcc-testresults/2008-10/msg02107.html

They look very good with 6 failure cases. 


-- 


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

[Bug middle-end/37870] [4.3 Regression] ICE in extract_bit_field_1

[jakub at gcc dot gnu dot org]

--- Comment #6 from jakub at gcc dot gnu dot org  2008-10-29 16:08 ---
Fixed on the trunk so far.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

  Known to fail|4.3.2 4.4.0 |4.3.2
  Known to work|4.2.4   |4.2.4 4.4.0
Summary|[4.3/4.4 Regression] ICE in |[4.3 Regression] ICE in
   |extract_bit_field_1 |extract_bit_field_1


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

[Bug middle-end/37870] [4.3/4.4 Regression] ICE in extract_bit_field_1

[jakub at gcc dot gnu dot org]

--- Comment #5 from jakub at gcc dot gnu dot org  2008-10-29 16:07 ---
Subject: Bug 37870

Author: jakub
Date: Wed Oct 29 16:07:39 2008
New Revision: 141430

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141430
Log:
PR middle-end/37870
* expmed.c (extract_bit_field_1): If int_mode_for_mode returns
BLKmode for non-memory, convert using a wider MODE_INT mode
or through memory.

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

Added:
trunk/gcc/testsuite/gcc.target/i386/pr37870.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/expmed.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug c++/26997] g++ reports misleading error message when the identifier with error occurs earlier on the same line

[manu at gcc dot gnu dot org]

--- Comment #7 from manu at gcc dot gnu dot org  2008-10-29 16:06 ---
FIXED in GCC 4.4


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug c++/26997] g++ reports misleading error message when the identifier with error occurs earlier on the same line

[manu at gcc dot gnu dot org]

--- Comment #6 from manu at gcc dot gnu dot org  2008-10-29 16:05 ---
Subject: Bug 26997

Author: manu
Date: Wed Oct 29 16:05:27 2008
New Revision: 141429

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141429
Log:
2008-10-29  Manuel López-Ibáñez  <[EMAIL PROTECTED]>

PR c++/26997
cp/
* parser.c (cp_parser_token_starts_cast_expression): New.
(cp_parser_cast_expression): Peek the next token to decide whether
this could be a parenthesized constructor or is definitely an
actual cast.
testsuite/
* g++.dg/parse/pr26997.C: New.

Added:
trunk/gcc/testsuite/g++.dg/parse/pr26997.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/parser.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug c/37947] missing sequence point warning for 'count += inc(&count);'

[manu at gcc dot gnu dot org]

--- Comment #7 from manu at gcc dot gnu dot org  2008-10-29 15:46 ---
(In reply to comment #6)
> Warning is (reliably) only possible if we can tell if the function call
> modifies
> the passed storage.  This requires some IPA analysis and thus moving the
> warning to the middle-end.

I don't want that at all. I wonder how much correct code is written like this
against how much incorrect code. However, now I realize that any function call 

counter += inc();

can trigger this if counter is a global variable. So this is impossible to get 
right 100% and it is not probably practical to move to the middle-end, since it
is very front-end specific.


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WONTFIX


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

[Bug middle-end/37339] [4.4 Regression] gcc.dg/pr33645-3.c scan-assembler-not var1_t

[jakub at gcc dot gnu dot org]

--- Comment #5 from jakub at gcc dot gnu dot org  2008-10-29 15:31 ---
The problem is that -fno-toplevel-reorder is often more restrictive than
-fno-unit-at-a-time used to be.  I guess instead of removing the testcase we
should just remove -fno-unit-at-a-time, or add -ftoplevel-reorder.


-- 


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

[Bug middle-end/37951] -ftree-parallelize-loops=2 fails for MA57

[dennis dot wassel at googlemail dot com]

--- Comment #2 from dennis dot wassel at googlemail dot com  2008-10-29 
15:27 ---
(In reply to comment #1)
> Waiting for a testcase.  May be related to PR37485.

Much as I would like to help, but I will not be able to distill a testcase out
of ma57 due to license and time constraints. Sorry!


-- 


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

[Bug middle-end/37913] [4.4 Regression] ICE: Segmentation fault in link_block, cfg.c:153

[jakub at gcc dot gnu dot org]

--- Comment #5 from jakub at gcc dot gnu dot org  2008-10-29 15:21 ---
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=37913

[Bug middle-end/37913] [4.4 Regression] ICE: Segmentation fault in link_block, cfg.c:153

[jakub at gcc dot gnu dot org]

--- Comment #4 from jakub at gcc dot gnu dot org  2008-10-29 15:19 ---
Subject: Bug 37913

Author: jakub
Date: Wed Oct 29 15:19:24 2008
New Revision: 141426

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141426
Log:
PR middle-end/37913
* tree-cfgcleanup.c (split_bbs_on_noreturn_calls): Only split bbs
that haven't been removed yet.

* gcc.c-torture/compile/pr37913.c: New test.

Added:
trunk/gcc/testsuite/gcc.c-torture/compile/pr37913.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-cfgcleanup.c


-- 


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

[Bug tree-optimization/35518] [4.4 Regression] FAIL: gcc.c-torture/execute/20040709-1.c execution at -O2 and above

[dave at hiauly1 dot hia dot nrc dot ca]

--- Comment #34 from dave at hiauly1 dot hia dot nrc dot ca  2008-10-29 
15:00 ---
Subject: Re:  [4.4 Regression] FAIL: gcc.c-torture/execute/20040709-1.c
execution at -O2 and above

> In this case they should be fixed with your backend change too.

No, my change was only for the 64-bit targets.  32-bit targets
including hppa2.0w-hp-hpux11.11 pad downward.

The reason this PR is still open is comment #22.

Dave


-- 


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

[Bug middle-end/37870] [4.3/4.4 Regression] ICE in extract_bit_field_1

[jakub at gcc dot gnu dot org]

-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jakub at gcc dot gnu dot org
   |dot org |
URL||http://gcc.gnu.org/ml/gcc-
   ||patches/2008-
   ||10/msg01236.html
 Status|NEW |ASSIGNED
   Last reconfirmed|2008-10-19 12:50:28 |2008-10-29 15:01:05
   date||


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

[Bug rtl-optimization/37948] [4.4 Regression] IRA generates slower code for -mtune=core2

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.4.0


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

gcc-bugs@gcc.gnu.org

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

  Known to work|4.3.2 4.4.0 |4.3.0 4.3.2 4.4.0
   Target Milestone|--- |4.3.0


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

[Bug c/37947] missing sequence point warning for 'count += inc(&count);'

[rguenth at gcc dot gnu dot org]

--- Comment #6 from rguenth at gcc dot gnu dot org  2008-10-29 14:34 ---
Warning is (reliably) only possible if we can tell if the function call
modifies
the passed storage.  This requires some IPA analysis and thus moving the
warning to the middle-end.


-- 


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

[Bug middle-end/37951] -ftree-parallelize-loops=2 fails for MA57

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2008-10-29 14:38 ---
Waiting for a testcase.  May be related to PR37485.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING


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

[Bug tree-optimization/37952] failure in polyhedron benchmark when ftree-parallelize-loops is enabled

[paolo dot carlini at oracle dot com]

--- Comment #1 from paolo dot carlini at oracle dot com  2008-10-29 13:18 
---


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


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug tree-optimization/37950] failure in polyhedron benchmark when ftree-parallelize-loops is enabled

[paolo dot carlini at oracle dot com]

--- Comment #1 from paolo dot carlini at oracle dot com  2008-10-29 13:18 
---
*** Bug 37952 has been marked as a duplicate of this bug. ***


-- 


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

[Bug rtl-optimization/37948] [4.4 Regression] IRA generates slower code for -mtune=core2

[hjl dot tools at gmail dot com]

--- Comment #4 from hjl dot tools at gmail dot com  2008-10-29 13:08 ---
(In reply to comment #2)
> Subject: Re:  [4.4 Regression] IRA generates slower
>  code for -mtune=core2
> 
> hjl dot tools at gmail dot com wrote:
> > --- Comment #1 from hjl dot tools at gmail dot com  2008-10-29 05:44 
> > ---
> > It looks like the cost of loading/storing FP values aren't appropriate for
> > Core 2. With this patch:
> 
> Good.  Is regmove still helping (which would be the wrong thing to do,
> but gives a data point)?
> 
> Paolo
> 

For this bug, regmove has mixed impacts with updated core2_cost:

[EMAIL PROTECTED] regmove]$ ../xgcc -B../ -m32 -O2 /tmp/foo.c -o core2.sse
-mtune=core2  -msse3 -mfpmath=sse
[EMAIL PROTECTED] regmove]$ ../xgcc -B../ -m32 -O2 /tmp/foo.c -o o2.sse   -msse3
-mfpmath=sse
[EMAIL PROTECTED] regmove]$ ../xgcc -B../ -m32 -O2 /tmp/foo.c -o core2 
-mtune=core2   
[EMAIL PROTECTED] regmove]$ ../xgcc -B../ -m32 -O2 /tmp/foo.c -o o2
[EMAIL PROTECTED] regmove]$ time ./o2

real0m7.995s
user0m7.956s
sys 0m0.003s
[EMAIL PROTECTED] regmove]$ time ./core2

real0m7.951s
user0m7.950s
sys 0m0.000s
[EMAIL PROTECTED] regmove]$ time ./core2.sse

real0m7.358s
user0m7.357s
sys 0m0.000s
[EMAIL PROTECTED] regmove]$ time ./o2.sse

real0m7.177s
user0m7.176s
sys 0m0.000s
[EMAIL PROTECTED] regmove]$


-- 


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

[Bug tree-optimization/37952] New: failure in polyhedron benchmark when ftree-parallelize-loops is enabled

[razya at il dot ibm dot com]

gas_dyn fails when autopar is enabled.
The failure is durig alias computation for one of the new parallel functions
created by autopar.

gas_dyn.f90: In function âcortesa._loopfn.0â:
gas_dyn.f90:1791: internal compiler error: in referenced_var_lookup, at
tree-dfa.c:565
Please submit a full bug report


#0  referenced_var_lookup (uid=3942) at ../../gcc/gcc/tree-dfa.c:564
#1  0x105700e4 in update_alias_info_1 (stmt=0xf7e51080, ai=0x11132a08)
at ../../gcc/gcc/tree-ssa-alias.c:2713
#2  0x10570d70 in update_alias_info (ai=0x11132a08)
at ../../gcc/gcc/tree-ssa-alias.c:2742
#3  0x1056dd0c in compute_may_aliases () at ../../gcc/gcc/tree-ssa-alias.c:1764


-- 
   Summary: failure in polyhedron benchmark when ftree-parallelize-
loops is enabled
   Product: gcc
   Version: tree-ssa
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: razya at il dot ibm dot com
 GCC build triplet: powerpc64-suse-linux
  GCC host triplet: powerpc64-suse-linux
GCC target triplet: powerpc64-suse-linux


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

[Bug c/37947] missing sequence point warning for 'count += inc(&count);'

[manu at gcc dot gnu dot org]

--- Comment #5 from manu at gcc dot gnu dot org  2008-10-29 12:40 ---
(In reply to comment #3)
> Thanks for the quick answer. Is it possible to get a warning if I write
> undefined code like this? -Wall didn't tell me anything.

-Wsequence-point should but it doesn't right now. The sooner this could be
implemented would be GCC 4.5. Sorry about that.


-- 

manu 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-10-29 12:40:46
   date||


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

[Bug c/37947] missing sequence point warning for 'count += inc(&count);'

[manu at gcc dot gnu dot org]

--- Comment #4 from manu at gcc dot gnu dot org  2008-10-29 12:39 ---
(In reply to comment #2)
> counter += inc(&counter);
> 
> That is undefined code as you access counter without a sequence point where 
> you
> assign it.

Is it only undefined because inc modifies counter? We do not warn about this
and my improved patch for 4.5 neither catches this case. We could warn if the
argument to the function is a pointer to the written variable. However, I have
no idea how to do this within the current code of verify_tree. Suggestions
welcome.

I'll reopen this as an enhancement.


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||manu at gcc dot gnu dot org
   Severity|normal  |enhancement
 Status|RESOLVED|UNCONFIRMED
   Keywords||diagnostic
 Resolution|INVALID |
Summary|p->count += inc(p);  // |missing sequence point
   |value of p->count is wrong, |warning for 'count +=
   |if inc(p) not only returns  |inc(&count);'
   |an int but also increases p-|
   |>counter|


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

[Bug fortran/37951] New: parallelization fails for MA57

[dennis dot wassel at googlemail dot com]

Compiling ma57 with 
"gfortran -O -ftree-parallelize-loops=2 -c ma57.f -o ma57.o"
produces the following error messages:

 = 1,2
--
ma57.f: In function 'ma57od':
ma57.f:2724: error: edge from 676 to 686 should be marked irreducible
ma57.f:2724: error: basic block 686 should be marked irreducible
ma57.f:2724: error: edge from 686 to 679 should be marked irreducible
ma57.f:2724: error: basic block 679 should be marked irreducible
ma57.f:2724: error: edge from 679 to 124 should be marked irreducible
ma57.f:2724: confused by earlier errors, bailing out

 = 3

ma57.f: In function 'ma57od':
ma57.f:2724: error: edge from 840 to 850 should be marked irreducible
ma57.f:2724: error: basic block 850 should be marked irreducible
ma57.f:2724: error: edge from 850 to 843 should be marked irreducible
ma57.f:2724: error: basic block 843 should be marked irreducible
ma57.f:2724: error: edge from 843 to 160 should be marked irreducible
ma57.f:2724: confused by earlier errors, bailing out

Since the HSL codes are subject to restricted licenses, I am pretty sure that I
am not supposed to include its source-code here. You can have a look at
http://www.cse.scitech.ac.uk/nag/hsl/ though, if you are eligible to obtain a
copy of ma57!

My gcc version:

Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: /localdata/install/gcc/gcc-4.3.2/configure
--prefix=/home/dwassel --program-suffix=-4.3.2 --enable-languages=c,c++,fortran
--with-gmp=/home/dwassel --with-mpfr=/home/dwassel --with-arch=athlon64
--with-tune=athlon64 --enable-version-specific-runtime-libs
Thread model: posix
gcc version 4.3.2 (GCC)


-- 
   Summary: parallelization fails for MA57
   Product: gcc
   Version: 4.3.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dennis dot wassel at googlemail dot com
  GCC host triplet: i686-pc-linux-gnu


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

[Bug tree-optimization/37950] New: failure in polyhedron benchmark when ftree-parallelize-loops is enabled

[razya at il dot ibm dot com]

gas_dyn fails when autopar is enabled.
The failure is durig alias computation for one of the new parallel functions
created by autopar.

gas_dyn.f90: In function âcortesa._loopfn.0â:
gas_dyn.f90:1791: internal compiler error: in referenced_var_lookup, at
tree-dfa.c:565
Please submit a full bug report


#0  referenced_var_lookup (uid=3942) at ../../gcc/gcc/tree-dfa.c:564
#1  0x105700e4 in update_alias_info_1 (stmt=0xf7e51080, ai=0x11132a08)
at ../../gcc/gcc/tree-ssa-alias.c:2713
#2  0x10570d70 in update_alias_info (ai=0x11132a08)
at ../../gcc/gcc/tree-ssa-alias.c:2742
#3  0x1056dd0c in compute_may_aliases () at ../../gcc/gcc/tree-ssa-alias.c:1764


-- 
   Summary: failure in polyhedron benchmark when ftree-parallelize-
loops is enabled
   Product: gcc
   Version: tree-ssa
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: razya at il dot ibm dot com
 GCC build triplet: powerpc64-suse-linux
  GCC host triplet: powerpc64-suse-linux
GCC target triplet: powerpc64-suse-linux


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

[Bug middle-end/37908] [4.2/4.3/4.4 regression] atomic NAND op generate wrong code; __sync_nand_and_fetch, __sync_fetch_and_nand

[ubizjak at gmail dot com]

--- Comment #8 from ubizjak at gmail dot com  2008-10-29 10:55 ---
Patch at http://gcc.gnu.org/ml/gcc-patches/2008-10/msg01224.html


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

URL||http://gcc.gnu.org/ml/gcc-
   ||patches/2008-
   ||10/msg01224.html
 Status|REOPENED|ASSIGNED
   Last reconfirmed|2008-10-24 07:44:56 |2008-10-29 10:55:33
   date||


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

[Bug c++/37949] New: static initialisation through pointer deferred until run time

[ajrobb at bigfoot dot com]

Given various methods for determining byte order on different platforms, the
following can be used in C++ to find the byte order across platforms.

  static const uint32_t bytes = 0x03020100ul;
  static const unsigned lo = *(const unsigned char*)&bytes;

Unfortunately, the value of 'lo' is determined at pre-run rather than at
compile time.

It would be useful if the compiler could determine the value of 'lo' so as to
eliminate constant logical tests and jumps.


-- 
   Summary: static initialisation through pointer deferred until run
time
   Product: gcc
   Version: 4.2.4
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ajrobb at bigfoot dot com
 GCC build triplet: i486-linux-gnu
  GCC host triplet: i486-linux-gnu
GCC target triplet: i486-linux-gnu


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

[Bug middle-end/37908] [4.2/4.3/4.4 regression] atomic NAND op generate wrong code; __sync_nand_and_fetch, __sync_fetch_and_nand

[kokseng at ieee dot org]

--- Comment #7 from kokseng at ieee dot org  2008-10-29 09:37 ---
The only problem is whether there are codes out there that depend on
"NEGATE-and-AND"? Frankly speaking,  when I was reminded about the 'nand'
comment on gcc manual, only then I remembered many moons ago, I read that line,
and also remembered saying to myself "W-T-F".  However, many moons later, when
I work on porting to other processor and test-the-unit-test, I relied on
text-book and historical definition of the term 'NAND'.  So, I think it is not
an issue of what Intel ICC did, it is matter of getting the semantic of NAND
the way any programmer was taught and practiced.

Propagating a misnomer will only guarantee that this issue of " NAND is not
NAND but 'N'AND" will come back to haunt every now-and-then.  IMHO, it is
better to bite the bullet now then swallow a canon later.

 :-)


-- 


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

[Bug target/37878] [4.4 regression] PPC64 ldu command generated with invalid offset

[jakub at gcc dot gnu dot org]

-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |dje at gcc dot gnu dot org
   |dot org |
URL||http://gcc.gnu.org/ml/gcc-
   ||patches/2008-
   ||10/msg01220.html
 Status|NEW |ASSIGNED


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

[Bug tree-optimization/35518] [4.4 Regression] FAIL: gcc.c-torture/execute/20040709-1.c execution at -O2 and above

[jakub at gcc dot gnu dot org]

--- Comment #33 from jakub at gcc dot gnu dot org  2008-10-29 08:29 ---
In this case they should be fixed with your backend change too.


-- 


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

[Bug middle-end/37914] [4.4 Regression] internal compiler error: vector VEC(basic_block,base) index domain error

[jakub at gcc dot gnu dot org]

--- Comment #1 from jakub at gcc dot gnu dot org  2008-10-29 08:28 ---
I've bootstrapped/regtested the trunk last night on s390-linux just fine.
Can you reproduce this with current trunk (there has been e.g. an IRA fix
for s390* compiler miscompilation)?
If yes, can you say which stage cc1 ICEs (stage1 or later stage), how you have
configured the compiler (e.g. which CPU variant it targets and/or tunes for)
and
if it is stage1 that ICEs, what bootstrap compiler was used, attach the
preprocessed source that triggers it and mention all options that were passed
to it.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING


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

[Bug rtl-optimization/37948] [4.4 Regression] IRA generates slower code for -mtune=core2

[pinskia at gmail dot com]

--- Comment #3 from pinskia at gmail dot com  2008-10-29 07:25 ---
Subject: Re:  [4.4 Regression] IRA generates slower code for -mtune=core2



Sent from my iPhone

On Oct 29, 2008, at 12:17 AM, "bonzini at gnu dot org"
<[EMAIL PROTECTED] 
 > wrote:

>
>
> --- Comment #2 from bonzini at gnu dot org  2008-10-29 07:17  
> ---
> Subject: Re:  [4.4 Regression] IRA generates slower
> code for -mtune=core2
>
> hjl dot tools at gmail dot com wrote:
>> --- Comment #1 from hjl dot tools at gmail dot com  2008-10-29  
>> 05:44 ---
>> It looks like the cost of loading/storing FP values aren't  
>> appropriate for
>> Core 2. With this patch:
>
> Good.  Is regmove still helping (which would be the wrong thing to do,
> but gives a data point)?

I noticed that ira ignores ! part of constraint do you know if the  
register class would change if ! was not ignored?

Thanks,
Andrew Pinsky

>
>
> Paolo
>
>
> -- 
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37948
>


-- 


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

Re: [Bug rtl-optimization/37948] [4.4 Regression] IRA generates slower code for -mtune=core2

[Andrew Thomas Pinski]

Sent from my iPhone

On Oct 29, 2008, at 12:17 AM, "bonzini at gnu dot org" <[EMAIL PROTECTED] 
> wrote:





--- Comment #2 from bonzini at gnu dot org  2008-10-29 07:17  
---

Subject: Re:  [4.4 Regression] IRA generates slower
code for -mtune=core2

hjl dot tools at gmail dot com wrote:
--- Comment #1 from hjl dot tools at gmail dot com  2008-10-29  
05:44 ---
It looks like the cost of loading/storing FP values aren't  
appropriate for

Core 2. With this patch:


Good.  Is regmove still helping (which would be the wrong thing to do,
but gives a data point)?


I noticed that ira ignores ! part of constraint do you know if the  
register class would change if ! was not ignored?


Thanks,
Andrew Pinsky




Paolo


--


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

[Bug rtl-optimization/37948] [4.4 Regression] IRA generates slower code for -mtune=core2

[bonzini at gnu dot org]

--- Comment #2 from bonzini at gnu dot org  2008-10-29 07:17 ---
Subject: Re:  [4.4 Regression] IRA generates slower
 code for -mtune=core2

hjl dot tools at gmail dot com wrote:
> --- Comment #1 from hjl dot tools at gmail dot com  2008-10-29 05:44 
> ---
> It looks like the cost of loading/storing FP values aren't appropriate for
> Core 2. With this patch:

Good.  Is regmove still helping (which would be the wrong thing to do,
but gives a data point)?

Paolo


-- 


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

[Bug middle-end/37908] [4.2/4.3/4.4 regression] atomic NAND op generate wrong code; __sync_nand_and_fetch, __sync_fetch_and_nand

[ubizjak at gmail dot com]

--- Comment #6 from ubizjak at gmail dot com  2008-10-29 07:10 ---
According to Intel [1]:

According to Dan, __sync_fetch_and_nand intrinsic should be implemented as
~(target & val). Uros's patch is correct.

[1] http://gcc.gnu.org/ml/gcc-patches/2008-10/msg01214.html


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

   Severity|major   |critical
 Status|RESOLVED|REOPENED
   Keywords||wrong-code
   Priority|P3  |P1
 Resolution|INVALID |


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