[Bug ada/34290] Problem with procedure visibility at the prefixed view call
--- Comment #4 from sam at gcc dot gnu dot org 2007-11-30 09:54 --- Of course, you should read "reference" instead of "dereference" in the previous comment. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34290
[Bug ada/15803] Illegal program not detected, RM 8.3(19)
--- Comment #4 from ludovic at ludovic-brenta dot org 2007-11-30 21:28 --- Samuel, this PR is not about variant parts. I think you closed the wrong bug. -- ludovic at ludovic-brenta dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15803
[Bug ada/15799] Legal program rejected, using 'Base
--- Comment #3 from ludovic at ludovic-brenta dot org 2007-11-30 21:22 --- But Boolean'Base is not an expression, since it does not define "the computation or retrieval of a value" (4.4(1)) but instead "denotes an unconstrained subtype" (3.5(15)). So, it really is a subtype_name. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15799
[Bug libfortran/34291] [4.3 Regression] Segfault in io/list_read.c handling of end conditions
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2007-11-30 23:19 --- Subject: Bug 34291 Author: jvdelisle Date: Fri Nov 30 23:19:34 2007 New Revision: 130548 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130548 Log: 2007-11-30 Jerry DeLisle <[EMAIL PROTECTED]> PR libfortran/34291 * io/list_read.c (read_character): When reading an unquoted string, return if special characters that could signify the end of the namelist read are encountered. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/io/list_read.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34291
[Bug fortran/29648] Inlining only done for contained procedures
--- Comment #3 from bdavis at gcc dot gnu dot org 2007-12-01 02:24 --- in case someone does not know what a contained procedure is (i sure didn't without getting out the Metcalf and Reid book), below is an example: program fred integer j j = 0 call a(j) print*,j contains subroutine a(i) integer i i = i +2 end subroutine a end program fred compile it with no optimization and look at the assembler code, then compile it with -O2, the subroutine is inlined by gfortran. not really relevant to this PR, but something I learned and verified, which might be of use. --bud -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29648
[Bug libfortran/33985] access="stream",form="unformatted" doesn't buffer
--- Comment #16 from jvdelisle at gcc dot gnu dot org 2007-12-01 04:34 --- OK, found some other regressions as well. I think we are still on the right trail. We can think about back porting after we get it really fixed. :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33985
[Bug c++/34307] New: when data member name is same as parameter name, possible to omit parameter name in constructor without warning
under Linux 2.6.20, KUbuntu Gutsy with gcc 4.1.3
compiling for use on linux
#if 0
//first here:
//g++ accepts to compile no parameter name is given anytime (not in the class
definition neither in the constructor implementation)
//the program runs ok though
#include
using namespace std;
class Hop
{
public:
Hop(string);
void fct(string);
};
Hop::Hop(string)
{}
void Hop::fct(string)
{}
int main()
{
Hop a("txt");
return 0;
}
#endif
#if 1
//second: when using an option parameter for constructor
//if we use this parameter name again for member initialisation and it's the
same as a data member name
//this gives no compile pb
//+a crash when running
#include
using namespace std;
class Hop
{
public:
Hop(string msg="no_msg");
void sayMsg();
string msg;
};
Hop::Hop(string):msg(msg)
{}
void Hop::sayMsg()
{
cout << "msg is:"
[Bug libfortran/33985] access="stream",form="unformatted" doesn't buffer
--- Comment #14 from jvdelisle at gcc dot gnu dot org 2007-12-01 04:22
---
This is embarrassing and good at the same time:
Index: unix.c
===
--- unix.c (revision 130547)
+++ unix.c (working copy)
@@ -669,11 +669,8 @@ fd_seek (unix_stream * s, gfc_offset off
if (s->file_length == -1)
return SUCCESS;
- if (s->physical_offset == offset) /* Are we lucky and avoid syscall? */
-{
- s->logical_offset = offset;
- return SUCCESS;
-}
+ if (s->logical_offset == offset) /* Are we lucky and avoid syscall? */
+return SUCCESS;
if (lseek (s->fd, offset, SEEK_SET) >= 0)
{
According to the comment we have been unlucky for a long time. :) With this
simple change alone, my sequential read benchmark goes from 23 seconds to .5
seconds. There is a regression in backspace_6.f90 which implies we need to fix
back space and leave the above fix in place if possible. The read test I am
using is reading a 36 megabyte unformatted file with ACCESS="stream". This is
impressive!
My write test with same file goes from about 6 seconds to about .5 seconds as
well.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33985
[Bug ada/34287] Simple Ada bug [Barnes' Silly]
-- sam at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34287
[Bug ada/34287] Simple Ada bug [Barnes' Silly]
-- sam at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |sam at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-12-01 01:00:33 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34287
[Bug fortran/34306] misprinting of derived types
--- Comment #1 from dominiq at lps dot ens dot fr 2007-11-30 23:59 ---
If this may help, I have extracted the following piece from the
-fdump-tree-original:
{
struct __st_parameter_dt dt_parm.11;
dt_parm.11.common.filename = &"pr18022_red.f90"[1]{lb: 1 sz: 1};
dt_parm.11.common.line = 21;
dt_parm.11.internal_unit = &buf1[1]{lb: 1 sz: 1};
dt_parm.11.internal_unit_len = 30;
dt_parm.11.internal_unit_desc = 0B;
dt_parm.11.common.unit = 0;
dt_parm.11.common.flags = 16512;
_gfortran_st_write (&dt_parm.11);
{
integer(kind=4) S.12;
S.12 = 1;
while (1)
{
if (S.12 > 4) goto L.9;
{
struct point * D.853;
D.853 = &pts[S.12 + -1];
_gfortran_transfer_character (&dt_parm.11, &D.853->x, 2);
_gfortran_transfer_character (&dt_parm.11, &D.853->y, 2);
}
S.12 = S.12 + 1;
}
L.9:;
}
_gfortran_st_write_done (&dt_parm.11);
}
{
struct __st_parameter_dt dt_parm.13;
dt_parm.13.common.filename = &"pr18022_red.f90"[1]{lb: 1 sz: 1};
dt_parm.13.common.line = 22;
dt_parm.13.internal_unit = &buf2[1]{lb: 1 sz: 1};
dt_parm.13.internal_unit_len = 30;
dt_parm.13.internal_unit_desc = 0B;
dt_parm.13.common.unit = 0;
dt_parm.13.common.flags = 16512;
_gfortran_st_write (&dt_parm.13);
{
struct array2_unknown parm.14;
parm.14.dtype = 178;
parm.14.dim[0].lbound = 1;
parm.14.dim[0].ubound = 4;
parm.14.dim[0].stride = 1;
parm.14.dim[1].lbound = 1;
parm.14.dim[1].ubound = 2;
parm.14.dim[1].stride = 4;
parm.14.data = (void *) (character(kind=1)[0:][1:2] *) &tab_c[0];
parm.14.offset = -5;
_gfortran_transfer_array (&dt_parm.13, &parm.14, 1, 2);
}
_gfortran_st_write_done (&dt_parm.13);
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34306
[Bug libfortran/33985] access="stream",form="unformatted" doesn't buffer
--- Comment #15 from howarth at nitro dot med dot uc dot edu 2007-12-01 04:28 --- Hopefully this performance improvement can be backported for gcc 4.2.3 as well. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33985
[Bug libfortran/34291] [4.3 Regression] Segfault in io/list_read.c handling of end conditions
--- Comment #9 from jvdelisle at gcc dot gnu dot org 2007-11-30 23:22 --- Subject: Bug 34291 Author: jvdelisle Date: Fri Nov 30 23:21:48 2007 New Revision: 130549 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130549 Log: 2007-11-30 Jerry DeLisle <[EMAIL PROTECTED]> PR libfortran/34291 * gfortran.dg/namelist_41.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/namelist_41.f90 Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34291
[Bug fortran/34306] New: misprinting of derived types
While looking at PR18022, I stumbled over the following problem illustrated by the reduced code from the original one: program test_bug implicit none character(len=2), dimension(4,2) :: tab_c character(len=30) :: buf1, buf2 type :: point character(len=2) :: x,y end type point type(point), dimension(4) :: pts tab_c(:,1)(:) = (/'1','2','3','4'/) tab_c(:,2)(:) = (/'2','3','4','5'/) pts%x = tab_c(:,1) pts%y = tab_c(:,2) if (any(pts%x /= tab_c(:,1)) .or. any(pts%y /= tab_c(:,2))) call abort() write (buf1, *) pts write (buf2, *) tab_c print *, buf1 print *, buf2 if (buf1 /= buf2) call abort() end program test_bug which gives 1 2 2 3 3 4 4 5 1 2 3 4 2 3 4 5 Abort -- Summary: misprinting of derived types Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dominiq at lps dot ens dot fr GCC build triplet: i686-apple-darwin9 GCC host triplet: i686-apple-darwin9 GCC target triplet: i686-apple-darwin9 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34306
[Bug c++/34298] [3.4] ICE on templated class with statically sized array computed from static const member
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-11-30 23:11 --- 3.4.x is no longer supported. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34298
[Bug libfortran/33985] access="stream",form="unformatted" doesn't buffer
--- Comment #12 from tkoenig at gcc dot gnu dot org 2007-11-30 22:57 --- (In reply to comment #11) > Thanks, > > I will look this over. I was saving this for when I really had some time. We > need to test it with everything we can find. I am glad you are as sensitive > to > the potential regression issue as I am. :) Actually, I just found that this doesn't really help a lot (too many reads...). I'll need to tweak this a bit. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33985
[Bug target/34261] Directed rounding doesn't work on MacOS X
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-11-30 22:20 --- (In reply to comment #2) > In a strict sense maybe not. fprintf() in GCC works fine on other > Unix-based systems. The trouble would be that GCC's communication > with the OS kernel somehow screwed up on this particular system. So > you can blame the kernel, not GCC. This is way beyond my capability > as a user to fix or even understand, so I have to rely on you experts > to fix it. Lets put it this way. If fprintf failed, it does not mean it is a GCC bug as GCC does not provide the fprintf library function. Yes GCC could have an ABI bug but that would mean everything else would be broken but since just fprintf is broken, it is most likely a bug in fprintf. > Interval arithmetic IA is in a unique position. It *also* relies on a > basic and simple communication with the OS, namely the ability to > switch rounding mode. If you can do this, your IA software works. If > you can't, it doesn't. Well since fesetround is not provided by GCC, it is provided by the system. Also are you using Apple's provided GCC, if so please file a bug with them. We cannot support their modified version anyways. > This violates the IEEE754 standard, which of course mandates rounding to > nearest as the default. Of course x87 violates it anyways. When I ran the test on a x86 machine, I get: [EMAIL PROTECTED]:~$ ./a.out 1 3 fesetround(0) returned 0 Then fegetround() returned 0 fesetround(1) returned 1 Then fegetround() returned 0 fesetround(2) returned 1 Then fegetround() returned 0 fesetround(3) returned 1 Then fegetround() returned 0 z0=0.15, z1=0.15, z2-z1=0, z1-z3=0 But when I run it on a PowerPC machine (which does not violate the IEEE standard): fesetround(0) returned 0 Then fegetround() returned 0 fesetround(1) returned 0 Then fegetround() returned 1 fesetround(2) returned 0 Then fegetround() returned 2 fesetround(3) returned 0 Then fegetround() returned 3 z0=0.15, z1=0.15, z2-z1=5.55112e-17, z1-z3=0 So I think this is just an x87 issue of execusive precission. Please read bug 323. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34261
[Bug ada/15804] Illegal program not detected, RM 3.8.1(2)
--- Comment #2 from sam at gcc dot gnu dot org 2007-11-30 22:11 --- Fixed in SVN trunk -- sam at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15804
[Bug ada/15803] Illegal program not detected, RM 8.3(19)
--- Comment #5 from sam at gcc dot gnu dot org 2007-11-30 21:47 --- Thanks for reopening it Ludovic. Yes, I mixed up the PR#, I'll fix the ChangeLog and close the right one. It's been two times this week, I guess it's bad for my health to go through so many Ada PR at a time :) -- sam at gcc dot gnu dot org changed: What|Removed |Added CC||sam at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15803
[Bug preprocessor/33907] Empty macro definitions not considered equal
--- Comment #18 from gdr at gcc dot gnu dot org 2007-11-30 21:10 --- The program is invalid, there is no point in getting into special cased corner cases. If you happen to have those macros in the same program from real world applications, you probably should be watching for bigger issues. -- gdr at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33907
[Bug target/34304] OpenJDK7 b23 is miscompiled with -O3 on amd64
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-11-30 20:15 --- Does -O2 -fno-strict-aliasing work? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34304
[Bug target/34304] New: OpenJDK7 b23 is miscompiled with -O3 on amd64
This report is incomplete When building with GCC 4.2 from the 4.2 branch, all the demos in demos/jfc and the gcjwebplugin crash. Lowering the optimization for the jdk to -O2 results in working demos and plugin. The build with GCC 4.1 does fail for me on amd64, GCC 4.3 from trunk works fine with -O2 and -O3. thread on OpenJDK: http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2007-November/000685.html -- Summary: OpenJDK7 b23 is miscompiled with -O3 on amd64 Product: gcc Version: 4.2.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: doko at ubuntu dot com GCC target triplet: x86_64-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34304
[Bug c++/34303] New: C++ class variable gets compiler error "declared 'threadprivate' after first use"
+++ This bug was initially created as a clone of Bug #27557 +++
This bug presented here is likely the same as Bug #27557, but this test case
does not involve a non-POD type.
Following program gets a compile time error with g++, but is able to compile
and execute using PGI and PathScale compilers.
$ cat bug2907.cpp
/* derived from OpenMP API Ver 2.5 p. 159 Example A.22.3c */
#include
#include
#define NT 4
class T {
public:
int val;
T (int);
T (const T&);
};
T :: T (int v){
val = v;
}
T :: T (const T& t) {
val = t.val;
}
int x = 1;
const T b_aux(x);
T b(b_aux);
#pragma omp threadprivate(b)
int main()
{
int save_val;
omp_set_num_threads(NT);
x++;
#pragma omp parallel default(none) shared(save_val)
{
if (omp_get_thread_num()==0) save_val = b.val;
}
printf("save_val=%d\n",save_val);
return 0;
}
$ g++ -fopenmp bug2907.cpp
bug2907.cpp:23: error: 'b' declared 'threadprivate' after first use
bug2907.cpp: In function 'int main()':
bug2907.cpp:33: error: 'b' not specified in enclosing parallel
bug2907.cpp:31: error: enclosing parallel
$ pathCC -mp bug2907.cpp; ./a.out
save_val=1
$ pgCC -mp=nonuma bug2907.cpp; ./a.out
Warning: omp_set_num_threads (4) greater than available cpus (1)
save_val=1
$
--
Summary: C++ class variable gets compiler error "declared
'threadprivate' after first use"
Product: gcc
Version: 4.2.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: geir at cray dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34303
[Bug preprocessor/34288] ssize_t used in libcpp/files.c without autoconf detection
--- Comment #3 from tromey at gcc dot gnu dot org 2007-11-30 18:35 --- Created an attachment (id=14674) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14674&action=view) patch to check for ssize_t Please try this patch. It applies to svn trunk. It includes the changes to configure and config.in as well. If this works for you, I will check it in. -- tromey at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |tromey at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34288
[Bug preprocessor/32868] Don't warn about redefinitions of __STDC_FORMAT_MACROS
--- Comment #4 from tromey at gcc dot gnu dot org 2007-11-30 18:24 --- Subject: Bug 32868 Author: tromey Date: Fri Nov 30 18:24:01 2007 New Revision: 130544 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130544 Log: libcpp PR preprocessor/32868: * macro.c (_cpp_create_definition): Special case __STDC_FORMAT_MACROS. gcc/testsuite PR preprocessor/32868: * gcc.dg/cpp/pr32868.c: New file. Added: trunk/gcc/testsuite/gcc.dg/cpp/pr32868.c Modified: trunk/gcc/testsuite/ChangeLog trunk/libcpp/ChangeLog trunk/libcpp/macro.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32868
[Bug rtl-optimization/34171] [4.3 Regression] Segfault in df_chain_remove_problem with -O3 on alpha
--- Comment #18 from spark at gcc dot gnu dot org 2007-11-30 17:02 --- Subject: Bug 34171 Author: spark Date: Fri Nov 30 17:02:43 2007 New Revision: 130539 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130539 Log: gcc/testsuite/ChangeLog: 2007-11-30 Martin Michlmayr <[EMAIL PROTECTED]> PR rtl-optimization/34171 * gcc.dg/pr34171.c: New testcase. gcc/ChangeLog: 2007-11-30 Seongbae Park <[EMAIL PROTECTED]> PR rtl-optimization/34171 * cfgrtl.c (update_bb_for_insn_chain): New function, refactored from update_bb_for_insn. (update_bb_for_insn): Call update_bb_for_insn. (rtl_merge_blocks, try_redirect_by_replacing_jump): Replace a loop with update_bb_for_insn_chain call. (cfg_layout_merge_blocks): Add a call to update_bb_for_insn_chain. Replace the for loop with a call to update_bb_for_insn_chain. Added: trunk/gcc/testsuite/gcc.dg/pr34171.c Modified: trunk/gcc/ChangeLog trunk/gcc/cfgrtl.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34171
[Bug ada/34301] GNAT Bug detected: visibility
--- Comment #3 from sam at gcc dot gnu dot org 2007-11-30 16:57 --- As I said, there were a real problem, but it has already been fixed in GCC 4.3.0 which has not yet been released. For what you are trying to achieve, you should rather declare X as X : T_Type; for X'Address use System.Storage_Elements.To_Address (50); but this question should have been brought onto the comp.lang.ada newsgroup instead of here :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34301
[Bug libfortran/33985] access="stream",form="unformatted" doesn't buffer
--- Comment #11 from jvdelisle at gcc dot gnu dot org 2007-11-30 22:45 --- Thanks, I will look this over. I was saving this for when I really had some time. We need to test it with everything we can find. I am glad you are as sensitive to the potential regression issue as I am. :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33985
[Bug libfortran/33985] access="stream",form="unformatted" doesn't buffer
--- Comment #10 from tkoenig at gcc dot gnu dot org 2007-11-30 22:27 --- Created an attachment (id=14675) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14675&action=view) proposed patch Hi Jerry, could you look at this? This also fixes excessive seeking when writing, but this is deep regression country (backspace_5.f, backspace_6.f and streamio_12.f90 are candidates for failure here :-) and the more people look at this, the better. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33985
[Bug c++/34303] C++ class variable gets compiler error "declared 'threadprivate' after first use"
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-11-30 21:56 --- >This bug presented here is likely the same as Bug #27557, but this test case >does not involve a non-POD type. T is a non POD type. It has a non trivial copy constructor and/or constructor. *** This bug has been marked as a duplicate of 27557 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34303
[Bug c++/27557] OpenMP threadprivate directive does not work with non-POD types
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-11-30 21:56 --- *** Bug 34303 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||geir at cray dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27557
[Bug ada/15803] Illegal program not detected, RM 8.3(19)
-- sam at gcc dot gnu dot org changed: What|Removed |Added Status|REOPENED|ASSIGNED Last reconfirmed|2007-11-26 21:36:27 |2007-11-30 21:51:58 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15803
[Bug tree-optimization/34265] Missed optimizations
--- Comment #25 from ubizjak at gmail dot com 2007-11-30 21:38 --- (In reply to comment #24) > Then the loop is vectorized again. IMO, SLP should vectorize the sequence. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34265
[Bug fortran/34246] gfortran.dg/bind_c_usage_16.f03 doesn't work
--- Comment #8 from burnus at gcc dot gnu dot org 2007-11-30 16:07 --- > powerpc64-unknown-linux-gnu shows the same pattern as powerpc-apple-darwin9: > anything linked to endianness? Well, x86-32 and x86-64 should have the same endianness. -- burnus at gcc dot gnu dot org changed: What|Removed |Added OtherBugsDependingO||32630 nThis|| Keywords||wrong-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34246
[Bug ada/22559] Bug box, Program_Error at sinput.adb:404, derived fixed-point type
--- Comment #5 from anhvofrcaus at gmail dot com 2007-11-30 18:58 --- Oops! I did not realize that. By the way, I will verify it with gcc-20071130. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22559
[Bug rtl-optimization/34302] [4.3 regression] Invalid code reordering
--- Comment #3 from zadeck at naturalbridge dot com 2007-11-30 15:33 --- 32 or 64 bit? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34302
[Bug tree-optimization/29415] [4.2 Regression] bad code reordering around inline asm block
--- Comment #14 from rguenth at gcc dot gnu dot org 2007-11-30 15:27 --- As you can see from the target milestone it should be fixed in all released versions (it was only broken during 4.2.0 development). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29415
[Bug tree-optimization/29415] [4.2 Regression] bad code reordering around inline asm block
--- Comment #13 from cfriedt at visible-assets dot com 2007-11-30 15:25 --- Is there a release of gcc where is this problem fixed, or is it only in the repository? I've been running into this problem for the last 2 days and was working around the clock, assuming that something was wrong with my code. (In reply to comment #12) > Fixed. > -- cfriedt at visible-assets dot com changed: What|Removed |Added CC||cfriedt at visible-assets ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29415
[Bug preprocessor/32868] Don't warn about redefinitions of __STDC_FORMAT_MACROS
--- Comment #5 from tromey at gcc dot gnu dot org 2007-11-30 18:24 --- Fix checked in. -- tromey at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32868
[Bug target/32086] [4.3 Regression] 10% to 20% Performance Regression Between 4.1.3 and 4.3
--- Comment #9 from dominiq at lps dot ens dot fr 2007-11-30 15:23 --- > I think we should turn on cost model by default, at least for i386. Although the information on cost model are very scarce in the gcc manual, if its goal is to avoid too costly vectorization, it should certainly turned on by default. And probably if this increases the execution time, the cost model would need some tuning. Concerning the induct code it is not a good test case on PPC since it uses double FP. On a 2.16Ghz Core2Duo I get for induct: -O3 -ffast-math -funroll-loops induct.f90 93.192u 0.066s 1:33.28 99.9%0+0k 0+1io 0pf+0w -O3 -ffast-math -funroll-loops -fvect-cost-model induct.f90 73.453u 0.107s 1:13.57 99.9%0+0k 0+1io 0pf+0w -O3 -ffast-math -funroll-loops -mfpmath=387 induct.f90 105.564u 0.128s 1:45.69 99.9% 0+0k 0+1io 0pf+0w -O3 -ffast-math -funroll-loops -mfpmath=387 -fvect-cost-model induct.f90 79.162u 0.088s 1:19.25 99.9%0+0k 0+0io 0pf+0w With the patch in comment #5 of PR34265, the timings are: without -mfpmath=387 and with or without -fvect-cost-model 37.014u 0.065s 0:37.08 99.9%0+0k 0+0io 0pf+0w with -mfpmath=387 and with or without -fvect-cost-model 39.820u 0.071s 0:39.89 100.0% 0+0k 0+0io 0pf+0w -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32086
[Bug testsuite/34253] Lots of failures in gcc.dg/vect
--- Comment #8 from andreasmeier80 at gmx dot de 2007-11-30 15:07 --- So some new informations. In revision 128088 it is fine, but it fails in revision 128109. I have no information for the revisions between, because of the commit in 128089 I have about 15000 failures in the C testsuite. 128089 and 128101 have been reverted in 128109, so because of the language C and my system i686-pc-linux-gnu only 128091,128092, 128105, 128107, 128108 are possible reasons for the failures -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34253
[Bug target/29524] [4.2/4.3 Regression] Too much RAM used: __clz_tab[] linked
--- Comment #14 from wvangulik at xs4all dot nl 2007-11-30 14:59 --- Note that the use of clz for the avr is avoided by using avr-libc's math library. See http://lists.gnu.org/archive/html/avr-libc-dev/2007-11/msg00048.html for more details. -- wvangulik at xs4all dot nl changed: What|Removed |Added CC||wvangulik at xs4all dot nl http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29524
[Bug regression/33928] [4.3 Regression] 22% performance slowdown from 4.2.2 to 4.3.0 in floating-point code
--- Comment #18 from bonzini at gnu dot org 2007-11-30 14:58 --- It would be -fno-forward-propagate, but what I meant is that the changes *connected to* fwprop could be the culprit. One has to look at dumps to understand if this is the case. It would be possible, maybe, to put an asm around the problematic basic block, so that one could plot the number of instructions in that basic block over time? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33928
[Bug fortran/33998] ICE in make_decl_rtl, at varasm.c:1263
--- Comment #4 from pault at gcc dot gnu dot org 2007-11-30 17:06 --- I think that I have a fix Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2007-11-05 23:46:09 |2007-11-30 17:06:19 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33998
[Bug regression/33928] [4.3 Regression] 22% performance slowdown from 4.2.2 to 4.3.0 in floating-point code
--- Comment #17 from lucier at math dot purdue dot edu 2007-11-30 14:47 --- Subject: Re: [4.3 Regression] 22% performance slowdown from 4.2.2 to 4.3.0 in floating-point code On Nov 30, 2007, at 12:39 AM, bonzini at gnu dot org wrote: > One suspect is fwprop. Anyone can confirm? How does one turn off fwprop? It doesn't seem to like "-fno-fwprop". -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33928
[Bug middle-end/31529] ICE in cgraph_expand_function with IMA
--- Comment #4 from aldot at gcc dot gnu dot org 2007-11-30 16:59 --- Breakpoint 2, cgraph_expand_function (node=0xb7c7a280) at ../../../src/gcc-4.3/gcc/cgraphunit.c:1138 1138 tree decl = node->decl; 1141 gcc_assert (!node->global.inlined_to); 1143 if (flag_unit_at_a_time) 1144announce_function (decl); 1146 gcc_assert (node->lowered); trips the node->lowered assert. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31529
[Bug ada/34301] GNAT Bug detected: visibility
--- Comment #2 from tomas at cernaj dot de 2007-11-30 16:53 --- Subject: Re: GNAT Bug detected: visibility > 29. X : constant access T_Type := TA.To_Pointer (50); [...] > You have to use "System.Storage_Elements.To_Address (50)" here. Hmm, thank you for the quick response, but the problem persists anyway... As I mentioned it compiles alright when moving the declaration into the public part of the spec (i.e. not deferred). Am I missing a point or is this indeed a valid construct? (I want the compiler to optimize an access to a fixed memory location.) Tomas -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34301
[Bug tree-optimization/29415] [4.2 Regression] bad code reordering around inline asm block
--- Comment #15 from cfriedt at visible-assets dot com 2007-11-30 15:48 --- Right - I guess I should make the Gentoo folks aware of this, because in their current tree anything >= 4.2.0 is marked as unstable. Thanks for the reply. (In reply to comment #14) > As you can see from the target milestone it should be fixed in all released > versions (it was only broken during 4.2.0 development). > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29415
[Bug rtl-optimization/34302] [4.3 regression] Invalid code reordering
--- Comment #2 from schwab at suse dot de 2007-11-30 14:16 --- The bug is introduced during auto-inc-dec. -- schwab at suse dot de changed: What|Removed |Added Component|target |rtl-optimization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34302
[Bug target/32086] [4.3 Regression] 10% to 20% Performance Regression Between 4.1.3 and 4.3
--- Comment #8 from bonzini at gnu dot org 2007-11-30 13:30 --- Testing a one-liner. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32086
[Bug target/34302] New: [4.3 regression] Invalid code reordering
((c_addr)=(Char *)(sp[2]));
((u1)=(UCell)(sp[1]));
((wfileid)=(Cell)((sp[0])));
sp += -1;
{
struct Cellquad r = read_line(c_addr, u1, wfileid);
lwz 6,0(19) #* sp, wfileid ((wfileid)=(Cell)((sp[0])));
addi 19,19,-4# sp, sp, sp += -1;
mr 29,19 # temp.1416, sp
mr 28,19 # temp.1418, sp
addi 3,1,72 #,,
lwzu 4,8(29) #, ((c_addr)=(Char *)(sp[2]));
lwzu 5,4(28) #, ((u1)=(UCell)(sp[1]));
bl read_line #
--
Summary: [4.3 regression] Invalid code reordering
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: schwab at suse dot de
GCC target triplet: powerpc*-suse-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34302
[Bug target/34302] [4.3 regression] Invalid code reordering
--- Comment #1 from schwab at suse dot de 2007-11-30 13:21 --- Created an attachment (id=14672) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14672&action=view) Preprocessed source Compile with -O or higher. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34302
[Bug target/32086] [4.3 Regression] 10% to 20% Performance Regression Between 4.1.3 and 4.3
--- Comment #7 from ubizjak at gmail dot com 2007-11-30 13:20 --- This is with latest SVN: Benchmark Name 387 387c sse ssec - --- --- --- --- ac 16.57 16.57 22.66 22.65 aermod 55.85 54.72 50.23 51.08 air 14.95 15.02 15.92 15.94 capacita 78.60 78.55 81.89 81.95 channel 9.90 9.78 9.90 9.65 doduc 59.82 59.65 67.81 68.97 fatigue 20.06 18.27 21.65 21.27 gas_dyn 11.47 11.35 10.62 10.68 induct 60.60 50.92 73.82 58.74 linpk 27.26 27.20 28.24 28.17 mdbx 30.41 30.36 33.33 33.23 nf 33.63 33.69 31.97 32.03 protein 73.16 72.87 72.67 72.76 rnflow 57.18 57.18 42.19 42.46 test_fpu 20.71 20.86 21.61 21.54 tfft 4.86 5.10 4.92 5.11 27.48 27.03 28.26 27.93 gcc version 4.3.0 20071130 (experimental) [trunk revision 130533] (GCC) Family: 15 Model: 4 Stepping: 10 Type: 0 Brand: 0 CPU Model: Pentium 4 D (Foster) Original OEM Processor name string: Intel(R) Xeon(TM) CPU 3.60GHz Compile Command : -march=opteron -ffast-math -funroll-loops -ftree-loop-linear -msse3 -O3 387 : -mfpmath=387 387c: -mfpmath=387 -fvec-cost-model sse : -mfpmath=sse ssec: -mfpmath=sse -fvec-cost-model -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32086
[Bug ada/34301] GNAT Bug detected: visibility
--- Comment #1 from sam at gcc dot gnu dot org 2007-11-30 12:52 --- GCC 4.3.0 will give a proper error message: 29. X : constant access T_Type := TA.To_Pointer (50); | >>> expected private type "System.Address" >>> found type universal integer You have to use "System.Storage_Elements.To_Address (50)" here. -- sam at gcc dot gnu dot org changed: What|Removed |Added CC||sam at gcc dot gnu dot org Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34301
[Bug middle-end/34300] gcc 4.2.2 miscompiles code that uses global register variables
--- Comment #4 from ismail at pardus dot org dot tr 2007-11-30 11:56 --- Are we sure it works with trunk? Because this is initially found as a clisp crash bug and it still crashes with gcc 4.3 trunk but only when compiled with -O2. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34300
[Bug middle-end/34300] gcc 4.2.2 miscompiles code that uses global register variables
--- Comment #5 from ismail at pardus dot org dot tr 2007-11-30 11:59 --- Indeed testcase doesn't abort with gcc 4.3 20071130 , so there must be another gcc bug hiding there :( -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34300
[Bug ada/34301] New: GNAT Bug detected: visibility
I got the following message with GNAT on Ubuntu 7.10 using following command: $ gcc-4.2 -O -S testpkg.adb +===GNAT BUG DETECTED==+ | 4.2.1 (Ubuntu 4.2.1-5ubuntu6) (x86_64-pc-linux-gnu) GCC error: | | in gnat_to_gnu_entity, bei ada/decl.c:230| | Error detected at testpkg.adb:24:9 | | Please submit a bug report; see http://gcc.gnu.org/bugs.html.| | Use a subject line meaningful to you and us to track the bug.| | Include the entire contents of this bug box in the report. | | Include the exact gcc-4.2 or gnatmake command that you entered. | | Also include sources listed below in gnatchop format | | (concatenated together with no headers between files). | +==+ Please include these source files with error report Note that list may not be accurate in some cases, so please double check that the problem can still be reproduced with the set of files listed. testpkg.adb testpkg.ads compilation abandoned It doesn't matter if the -O switch is given or not. The files compiled are: testpkg.ads: with System; with System.Address_To_Access_Conversions; package TestPkg is type T_Type is record Bit0: Boolean; Bit1: Boolean; Bit2: Boolean; Bit3: Boolean; Bit4: Boolean; Bit5: Boolean; Bit6: Boolean; Bit7: Boolean; end record; pragma Pack (T_Type); for T_Type'Size use 8; X : constant access T_Type; Y : T_Type; procedure TestIt; private package TA is new System.Address_To_Access_Conversions (T_Type); X : constant access T_Type := TA.To_Pointer (50); end TestPkg; testpkg.adb: with System.Address_To_Access_Conversions; package body TestPkg is type U_Type is record Bit0: Boolean; Bit1: Boolean; Bit2: Boolean; Bit3: Boolean; Bit4: Boolean; Bit5: Boolean; Bit6: Boolean; Bit7: Boolean; end record; pragma Pack (U_Type); for U_Type'Size use 8; package UA is new System.Address_To_Access_Conversions (U_Type); Z : UA.Object_Pointer := UA.To_Pointer (49); procedure TestIt is begin X.Bit4 := True; Y.Bit5 := True; Z.Bit6 := True; end TestIt; end TestPkg; The error does only occur when using a deferred constant declaration for X. If it's not deferred it compiles OK. -- Summary: GNAT Bug detected: visibility Product: gcc Version: 4.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tomas at cernaj dot de GCC host triplet: x86_64-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34301
[Bug middle-end/34300] gcc 4.2.2 miscompiles code that uses global register variables
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-11-30 11:09 --- Works with trunk as well. (Aliasing should be not the issue here, strict-aliasing is off) -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Known to fail||4.2.2 Known to work||4.1.2 4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34300
[Bug target/32086] [4.3 Regression] 10% to 20% Performance Regression Between 4.1.3 and 4.3
--- Comment #6 from bonzini at gnu dot org 2007-11-30 10:59 --- Looking at http://physik.fu-berlin.de/~tburnus/gcc-trunk/benchmark/gfortran-run.dat and http://physik.fu-berlin.de/~tburnus/gcc-trunk/benchmark/gfortranVecCost-run.dat I think we should turn on cost model by default, at least for i386. Uros? -- bonzini at gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-11-30 10:59:33 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32086
[Bug middle-end/34300] gcc 4.2.2 miscompiles code that uses global register variables
--- Comment #1 from bruno at clisp dot org 2007-11-30 10:46 --- Created an attachment (id=14671) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14671&action=view) source code exhibiting the bug -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34300
[Bug middle-end/34300] New: gcc 4.2.2 miscompiles code that uses global register variables
$ gcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.2.2/configure --prefix=/packages/gnu-inst-gcc/4.2.2
--enable-shared --enable-version-specific-runtime-libs --enable-nls
--enable-threads=posix --enable-__cxa_atexit --with-as=/packages/gnu/bin/as
--with-ld=/packages/gnu/bin/ld --with-gmp=/packages/gnu-inst-gcc/4.2.2
--with-mpfr=/packages/gnu-inst-gcc/4.2.2
--with-ecj-jar=/gfs/ibook/Volumes/ExtData/source/gnu/gcc/sourceware.org-ecj/ecj-latest.jar
Thread model: posix
gcc version 4.2.2
$ gcc bug.c
$ ./a.out ; echo $?
0
$ gcc -O bug.c
$ ./a.out ; echo $?
Aborted
134
= bug.c
typedef unsigned char UBYTE;
typedef long SLONG;
typedef unsigned long ULONG;
typedef ULONG uint32;
typedef SLONG sint32;
typedef sint32 sintL;
typedef uint32 uintL;
typedef sint32 sintP;
typedef uint32 uintP;
typedef void * gcv_object_t;
typedef uintP oint;
typedef uint32 tint;
typedef uint32 aint;
typedef uint32 uintV;
typedef gcv_object_t object;
typedef struct {
gcv_object_t cdr ;
gcv_object_t car ;
} cons_;
typedef cons_ * Cons;
typedef struct {
gcv_object_t GCself;
} symbol_;
typedef symbol_ * Symbol;
typedef struct {
gcv_object_t GCself;
gcv_object_t data[2] ;
} svector_;
typedef svector_ * Svector;
register gcv_object_t* STACK __asm__("%ebx");
extern object allocate_vector (uintL len);
struct symbol_tab_ {
symbol_ S_nil;
} symbol_tab_data = { { (UBYTE*)&symbol_tab_data.S_nil+2 } };
extern void newinsert (object sym, uintL size);
extern void abort (void);
static gcv_object_t stackspace[100];
object rehash_symtab (object symtab)
{
STACK[0] = symtab, STACK += 1;
{
uintL oldsize =
((uintV)(((oint)Svector)((oint)(symtab)-2))->data[0]))&((oint)0x2000UL-1))>>5));
{
uintL newsize;
{
object size;
STACK[0] = ((Svector)((oint)(symtab)-2))->data[1], STACK += 1;
STACK[0] = (object)((UBYTE*)(&symbol_tab_data.S_nil)+2), STACK += 1;
{
uint32 prod = oldsize * 205UL;
newsize = (prod < (1UL<<31) ? prod>>7 : 0xffUL);
}
newsize = (newsize - 1) | 1 ;
size = ((gcv_object_t)((oint)(tint)0xC000 + ((oint)(aint)(newsize)
<< 5)));
{
object newtable = allocate_vector(newsize);
STACK[0] = newtable, STACK += 1;
}
{
gcv_object_t* offset = 0;
uintL count;
count = oldsize;
do
{
object oldentry =
*(gcv_object_t*)(((UBYTE*)(&((Svector)((oint)(((STACK[-3])))-2))->data[0])+((aint)offset)));
if (((oint)(oldentry) & 3) == 2)
do
{
STACK[0] = ((Cons)((oint)(oldentry)-2))->cdr, STACK += 1;
((Cons)((oint)(oldentry)-2))->cdr = STACK[-3];
STACK[-3] = oldentry;
newinsert(((Cons)((oint)(oldentry)-2))->car,newsize);
oldentry = (STACK -= 1, STACK[0]);
}
while (((oint)(oldentry) & 3) == 2);
offset++;
}
while(!(--count==0));
}
if (STACK != &stackspace[54])
abort();
{
object newtable = (STACK -= 1, STACK[0]);
STACK -= 2;
symtab = (STACK -= 1, STACK[0]);
((Svector)((oint)(symtab)-2))->data[0] = size;
((Svector)((oint)(symtab)-2))->data[1] = newtable;
}
return symtab;
}
}
}
}
object allocate_vector (uintL len)
{
return 0;
}
void newinsert (object sym, uintL size)
{
if (STACK != &stackspace[55])
abort();
}
static cons_ cons2 = { (void*)0, (void*)'2' };
static cons_ cons1 = { (UBYTE*)&cons2+2, (void*)'1' };
static svector_ vector1 = { (UBYTE*)&vector1+2, { (UBYTE*)&cons1+2, 0 } };
static svector_ symtab1 = { (UBYTE*)&symtab1+2, { (void*)0x2020,
(UBYTE*)&vector1+2 } };
int main ()
{
STACK = &stackspace[50];
rehash_symtab((UBYTE*)&symtab1+2);
return 0;
}
This is a regression, because gcc 3.4.4, gcc 4.0.4, and gcc 4.1.2 all compile
this program fine, even with higher optimization levels (-O2).
What happens is that gcc 4.2.2 keeps a "cache" of the STACK = %ebx variable
in another register, %edi, in the inner loop, around the function call of
newinsert(). Two things are wrong here:
1) It is wrong to assume that newinsert() will leave STACK unmodified.
newinsert() could also always decrement STACK by 2, for example. You can
see that the code is unchanged if the newinsert() function is put into a
different compilation unit.
2) The value cached in %edi and used for this statement
oldentry = (STACK -= 1, STACK[0]);
is the value of STACK at the beginning of the loop MINUS 1.
If assuming that newinsert() does not change the STACK, the value cached
in %edi should be the value of STACK at the beginning of the loop
(since th
[Bug c++/32245] [4.1 Regression] wrong POD type initialization with pointer to member
--- Comment #5 from aaw at gcc dot gnu dot org 2007-11-30 10:43 --- Should this bug be marked as resolved, then? -- aaw at gcc dot gnu dot org changed: What|Removed |Added CC||aaw at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32245
[Bug middle-end/34300] gcc 4.2.2 miscompiles code that uses global register variables
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-11-30 10:50 --- hmm, i see some alias issues. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34300
[Bug c++/32245] [4.1 Regression] wrong POD type initialization with pointer to member
--- Comment #6 from rguenth at gcc dot gnu dot org 2007-11-30 10:49 --- It's still broken in 4.1, so we want to keep it open (generally we don't close wrong-code bugs as fixed only in later releases - unless the branch is closed). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32245
[Bug target/32086] [4.3 Regression] 10% to 20% Performance Regression Between 4.1.3 and 4.3
--- Comment #5 from ubizjak at gmail dot com 2007-11-30 10:27 --- gfortran -march=opteron -ffast-math -funroll-loops -ftree-loop-linear -msse3 -O3 -mfpmath=sse induct.f90: user1m32.226s gfortran -march=opteron -ffast-math -funroll-loops -ftree-loop-linear -msse3 -O3 -mfpmath=sse -fno-tree-vectorize induct.f90 user0m58.492s fortran -march=opteron -ffast-math -funroll-loops -ftree-loop-linear -msse3 -O3 -mfpmath=387 induct.f90 user1m40.906s gfortran -march=opteron -ffast-math -funroll-loops -ftree-loop-linear -msse3 -O3 -mfpmath=387 -fno-tree-vectorize induct.f90 user0m46.439s gfortran -march=opteron -ffast-math -funroll-loops -ftree-loop-linear -msse3 -O3 -mfpmath=sse -fvect-cost-model induct.f90 user0m58.168s gfortran -march=opteron -ffast-math -funroll-loops -ftree-loop-linear -msse3 -O3 -mfpmath=387 -fvect-cost-model induct.f90 user0m46.415s All on: Family: 15 Model: 4 Stepping: 10 Type: 0 Brand: 0 CPU Model: Pentium 4 D (Foster) Original OEM Processor name string: Intel(R) Xeon(TM) CPU 3.60GHz (so -march=opteron is a bit misleading) I'd say that vectorizer cost model is doing its job pretty well. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32086
[Bug ada/34289] Systematic recompilation of up-to-date object files when using the "-s" gnatmake option GNAT 4.3.0 on x86-*-Darwin8
--- Comment #5 from sam at gcc dot gnu dot org 2007-11-30 09:36 --- I sent a mail to the author of this change to ask if and why it was necessary. Note that it may have been perfectly valid in 2004 as this target was not covered yet. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34289
[Bug fortran/34186] dump-parse-tree: ICE for ts->cl->length, if ts->cl == NULL
--- Comment #2 from burnus at gcc dot gnu dot org 2007-11-30 09:32 --- Subject: Bug 34186 Author: burnus Date: Fri Nov 30 09:31:56 2007 New Revision: 130534 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130534 Log: 2007-11-30 Tobias Burnus <[EMAIL PROTECTED]> PR fortran/34186 * symbol.c (generate_isocbinding_symbol): Set string length. * dump-parse-tree.c (gfc_show_attr): Show BIND(C) attribute. * misc.c (gfc_basic_typename): Handle BT_VOID. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/dump-parse-tree.c trunk/gcc/fortran/misc.c trunk/gcc/fortran/symbol.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34186
[Bug fortran/34186] dump-parse-tree: ICE for ts->cl->length, if ts->cl == NULL
--- Comment #1 from burnus at gcc dot gnu dot org 2007-11-30 09:32 --- FIXED on the trunk (4.3.0); 4.2.x and 4.1.x should be unaffected as the crash seems to be due to C Binding changes. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34186
[Bug ada/34289] Systematic recompilation of up-to-date object files when using the "-s" gnatmake option GNAT 4.3.0 on x86-*-Darwin8
--- Comment #4 from bechir dot zalila at gmail dot com 2007-11-30 09:30 --- Created an attachment (id=14670) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14670&action=view) Patchfile that solves the poblem This patchfile is valid only if the order among -g* and -m* switches is not important. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34289
[Bug libfortran/33583] FAIL: gfortran.dg/gamma_1.f90
--- Comment #23 from fxcoudert at gcc dot gnu dot org 2007-11-30 09:27 --- This time it can probably be marked as fixed. Please reopen it if the problem persists. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33583
[Bug ada/15611] Invalid program not detected, RM 3.7(11)
--- Comment #3 from ludovic at ludovic-brenta dot org 2007-11-30 21:51 --- 7.3(15) says that a private type has a partial view and a full view, and the properties of the partial view apply in some places, and the properties of the full view apply in other places. So in places where the full view applies, the type is considered tagged, and cannot have default expressions in the known_discriminant part. You seem to imply that the full view does not apply in the completion of the type, as the full view does not even exist yet. Taking the RM literally, you may be right but the annotated AARM 3.7(11.b/2) provides guidance: Defaults for discriminants of tagged types are disallowed so that every object of a tagged type is constrained, either by an explicit constraint, or by its initial discriminant values. This substantially simplifies the semantic rules and the implementation of inherited dispatching operations. For generic formal types, the restriction simplifies the type matching rules. If one simply wants a "default" value for the discriminants, a constrained subtype can be declared for future use. I think this rule would be violated for objects of the type declared in the private part where the full view applies, i.e. you could declare unconstrained objects of the tagged type. So, I confirm this to be a bug. -- ludovic at ludovic-brenta dot org changed: What|Removed |Added Status|WAITING |NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15611
[Bug ada/15799] Legal program rejected, using 'Base
--- Comment #4 from sam at gcc dot gnu dot org 2007-11-30 21:32 --- I checked in the RM. "subtype_mark" is defined as a "/subtype/_name" which is equivalent to a "name" which is not specifically defined. And "subtype_mark" is used in "relation" which accepts T'Base after the "in" keyword, so I guess you are right here. -- sam at gcc dot gnu dot org changed: What|Removed |Added Last reconfirmed|2005-06-14 04:55:55 |2007-11-30 21:32:34 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15799
[Bug c++/10179] alignment attributes are not inherited correctly with empty classes
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10179
[Bug ada/22559] Bug box, Program_Error at sinput.adb:404, derived fixed-point type
--- Comment #4 from sam at gcc dot gnu dot org 2007-11-30 17:25 --- Well, given that you tried the test with a version from November 23 and given that I fixed it on November 28, it is quite normal that you see the bug :) -- sam at gcc dot gnu dot org changed: What|Removed |Added CC|sam at rfc1149 dot net |sam at gcc dot gnu dot org, ||anhvofrcaus at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22559
[Bug ada/22559] Bug box, Program_Error at sinput.adb:404, derived fixed-point type
--- Comment #3 from anhvofrcaus at gmail dot com 2007-11-30 17:21 --- The problem still exists as shown below. bash-2.05b$ gcc -c test_deltas.adb +===GNAT BUG DETECTED==+ | 4.3.0 20071123 (experimental) (i686-pc-linux-gnu) Program_Error sinput.adb:403 explicit raise| | Error detected at test_deltas.adb:1:1| | Please submit a bug report; see http://gcc.gnu.org/bugs.html.| | Use a subject line meaningful to you and us to track the bug.| | Include the entire contents of this bug box in the report. | | Include the exact gcc or gnatmake command that you entered. | | Also include sources listed below in gnatchop format | | (concatenated together with no headers between files). | +==+ Please include these source files with error report Note that list may not be accurate in some cases, so please double check that the problem can still be reproduced with the set of files listed. list may be incomplete compilation abandoned -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22559
[Bug tree-optimization/34195] missed optimization with store motion (vectorizer)
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-11-30 13:41 --- Created an attachment (id=14673) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14673&action=view) updated patch I have updated Zdeneks patch for using an alias oracle for store motion and loop invariant motion to mainline. Of the store-motion cases in the testcase there fail two, test4 and test5. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34195
[Bug fortran/34133] Bind(c,name="") should be rejected for dummies; F2008: allow bind(c) for internal procs
--- Comment #9 from burnus at gcc dot gnu dot org 2007-11-30 12:16 --- Subject: Bug 34133 Author: burnus Date: Fri Nov 30 12:16:35 2007 New Revision: 130535 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130535 Log: 2007-11-20 Tobias Burnus <[EMAIL PROTECTED]> PR fortran/34133 * match.h: Add bool allow_binding_name to gfc_match_bind_c. * decl.c * (match_attr_spec,gfc_match_bind_c_stmt,gfc_match_entry): Adjust accordingly. (gfc_match_bind_c): Add allow_binding_name argument, reject binding name for dummy arguments. (gfc_match_suffix,gfc_match_subroutine): Make use of allow_binding_name. 2007-11-20 Tobias Burnus <[EMAIL PROTECTED]> PR fortran/34133 * gfortran.dg/bind_c_usage_9.f03: Fixes; add -std=f2003. * gfortran.dg/bind_c_usage_11.f03: New. * gfortran.dg/bind_c_usage_12.f03: New. Added: trunk/gcc/testsuite/gfortran.dg/bind_c_usage_11.f03 trunk/gcc/testsuite/gfortran.dg/bind_c_usage_12.f03 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/fortran/match.h trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/bind_c_usage_9.f03 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34133
[Bug ada/34289] Systematic recompilation of up-to-date object files when using the "-s" gnatmake option GNAT 4.3.0 on x86-*-Darwin8
--- Comment #3 from bechir dot zalila at gmail dot com 2007-11-30 09:19
---
In gcc/config/i386/darwin.h, we can see:
#define CC1_SPEC "%(cc1_cpu) \
%{!mkernel:%{!static:%{!mdynamic-no-pic:-fPIC}}} \
%{!mmacosx-version-min=*:-mmacosx-version-min=%(darwin_minversion)} \
%{g: %{!fno-eliminate-unused-debug-symbols: -feliminate-unused-debug-symbols
}}"
which cintains the addition of -mmacosx-version-min=... if it is not given,
In gcc/ada/lang-spec.h we can see the following:
%{O*} %{W*} %{w} %{p} %{pg:-p} %{a} %{f*} %{d*} %{g*&m*} "
#if defined(TARGET_VXWORKS_RTP)
"%{fRTS=rtp:-mrtp} "
#endif
#if CONFIG_DUAL_EXCEPTIONS
"%{fRTS=sjlj:-fsjlj} "
#endif
"%1 %{!S:%{o*:%w%*-gnatO}} \
The %1 (processing of CC1_SPEC) comes after the %{g*&m*} which should result in
adding the -mmacosx-version-min=... after all options that begins with -g* and
especially -gnatez, and it should not be added in the .ali file. For some
reason, the -mmacosx-version-min=... is added before all options that begins
with -g...
I replaced %{g*&m*} by %{g*} %{m*} in lang-specs.h and this solved the problem.
However, I don't know whether its is very important to conserve the order among
-g* and -m* switches when passing them to gnat1. The change 83658 did not say
why:
* lang-specs.h: Keep -g and -m switches in the same order, and as the
last switches.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34289
[Bug tree-optimization/34244] [4.3 Regression] VRP/SCEV miscompiles Firefox
--- Comment #12 from hjl at lucon dot org 2007-11-30 08:56 --- gcc.dg/tree-ssa/pr34244.c in http://gcc.gnu.org/viewcvs?view=rev&revision=130527 has duplicated content. -- hjl at lucon dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34244
[Bug target/34299] New: [avr] ICE on function attribute syntax for main()
+++ This bug was initially created as a clone of Bug #31331 +++ On a Mac(Tiger) compilation of a TinyOS standard example application "Blink" does not compile. Please mail me if important information is missing. As I cannot access the MAC I cannot provide the C file created by the Nesc Compiler. make micaz sh: line 1: sha1sum: command not found sh: line 1: sha1sum: command not found mkdir -p build/micaz compiling BlinkAppC to a micaz binary ncc -o build/micaz/main.exe -Os -fnesc-separator=\never1096WritE -Wall -Wshadow -Wnesc-all -target=micaz -fnesc-cfile=build/micaz/app.c -board=micasb --param max-inline-insns-single=10 -I/sw/include/python2.5/ -DIDENT_PROGRAM_NAME=\"BlinkAppC\" -DIDENT_USER_ID=\"admin\" -DIDENT_HOSTNAME=\"macbook-zina.in\" -DIDENT_USER_HASH=0L -DIDENT_UNIX_TIME=0x474aa64cL -DIDENT_UID_HASH=0L -fnesc-dump=wiring -fnesc-dump='interfaces(!abstract())' -fnesc-dump='referenced(interfacedefs, components)' -fnesc-dumpfile=build/micaz/wiring-check.xml BlinkAppC.nc -lm /sw/tinyos-2.x/tinyos-2.x/tos/chips/atm128/timer/HplAtm128Timer0AsyncP.nc:178: internal compiler error: in start_function, at c-decl.c:6177 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. make: *** [exe0] Error 1 The NesC Compiler involved is: nescc: 1.2.9 gcc -_fnesc-gcc=gcc -specs=/opt/tinyostools//lib/ncc/tdspecs -_fnesc-include=nesc_nx -I/opt/tinyostools//lib/ncc -v -DNESC=129 Using built-in specs. Reading specs from /opt/tinyostools//lib/ncc/tdspecs Target: i386-apple-darwin8.10.1 Configured with: ../gcc-4.2.2/configure --prefix=/opt/local --enable-languages=c,c++,java,objc,obj-c++,fortran --libdir=/opt/local/lib/gcc42 --includedir=/opt/local/include/gcc42 --infodir=/opt/local/share/info --mandir=/opt/local/share/man --with-local-prefix=/opt/local --with-system-zlib --disable-nls --disable-multilib --program-suffix=-mp-4.2 --with-gxx-include-dir=/opt/local/include/gcc42/c++/ --with-gmp=/opt/local --with-mpfr=/opt/local Thread model: posix gcc version 4.2.2 avr-gcc -v produces: Using built-in specs. Target: avr Configured with: ../configure --target=avr --prefix=/opt/tinyostools/ --disable-nls --enable-languages=c --disable-libsp : (reconfigured) ../configure --target=avr --prefix=/opt/tinyostools/ --disable-nls --enable-languages=c --disable-libssp Thread model: single gcc version 4.2.2 -- Summary: [avr] ICE on function attribute syntax for main() Product: gcc Version: 4.2.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: marek dot jawurek at gmx dot net GCC target triplet: avr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34299
[Bug ada/34290] Problem with procedure visibility at the prefixed view call
--- Comment #3 from sam at gcc dot gnu dot org 2007-11-30 09:51 --- As a workaround, it looks like you can use an explicit dereference instead of an implicit one for the Set_Central_Widget call: Main_Windows.Impl.Main_Window_Impl (Result.all)'Access.Set_Central_Widget (Main_Windows.Impl.Main_Window_Impl (Result.all).Text_Edit); -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34290
[Bug tree-optimization/34172] Missed store ccp optimization
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-11-30 10:25 --- Mine. I have a patch. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2007-11-21 12:04:28 |2007-11-30 10:25:34 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34172
[Bug target/34261] Directed rounding doesn't work on MacOS X
--- Comment #2 from j dot d dot pryce at ntlworld dot com 2007-11-30 12:40 --- Subject: Re: Directed rounding doesn't work on MacOS X Dear Pinskia On 28 Nov 2007, at 17:08, pinskia at gcc dot gnu dot org wrote: > --- Comment #1 from pinskia at gcc dot gnu dot org 2007-11-28 > 17:08 --- > I doubt that this is a gcc bug. Consider this. Suppose I just downloaded the vanilla GCC system on to the shiny new Mac from which I am writing. And I find everything works fine except that whenever I use fprintf(), it crashes the system. I report this as a bug, and I get back the comment "I doubt that this is a gcc bug." In a strict sense maybe not. fprintf() in GCC works fine on other Unix-based systems. The trouble would be that GCC's communication with the OS kernel somehow screwed up on this particular system. So you can blame the kernel, not GCC. This is way beyond my capability as a user to fix or even understand, so I have to rely on you experts to fix it. Of course as it's fprintf() that's crashing, you wouldn't say, in effect, "It's none of my business, guvnor". You would aim to fix it ASAP, because a C++ system without fprintf() is simply not credible. Interval arithmetic IA is in a unique position. It *also* relies on a basic and simple communication with the OS, namely the ability to switch rounding mode. If you can do this, your IA software works. If you can't, it doesn't. When it works, it can *provably* get correct answers to problems that are hard or even impractical by other means, e.g. see chapter 4 by Stan Wagon in the "100 dollar, 100 digit challenge" book. The hardware hooks to switch rounding mode are there on any IEEE754- compliant CPU, as this one is. Languages support it: e.g. C has fegetround/fegetround. The trouble seems to be that the detail of how rounding mode is handled at machine instruction level varies widely between machines. E.g. is the mode a global flag in the floating-point unit or is it encoded within each FP instruction? So perhaps it is tricky to make it work on each new architecture. While making fprintf() work is routine. Tricky though it may be, the buck stops at you compiler writers. Interval computation is an increasingly important mainstream scientific computing activity. We interval folk haven't the skills to make it work on a new machine. If you don't help us, who will? John Pryce [EMAIL PROTECTED] -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34261
[Bug tree-optimization/34244] [4.3 Regression] VRP/SCEV miscompiles Firefox
--- Comment #13 from jakub at gcc dot gnu dot org 2007-11-30 13:24 --- Zdenek fixed that. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34244
[Bug tree-optimization/34195] missed optimization with store motion (vectorizer)
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-11-30 13:46 --- That moves the stores pS[i].x += (a[i]+b[i]); pS[i].y += (a[i]-b[i]); out of the inner loop, but still none of the loops are vectorized (on x86_64). -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||missed-optimization Last reconfirmed|-00-00 00:00:00 |2007-11-30 13:46:49 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34195
[Bug rtl-optimization/34302] [4.3 regression] Invalid code reordering
--- Comment #4 from schwab at suse dot de 2007-11-30 15:37 --- Both. The testcase is for 32 bit, but the equivalent source for 64 bit produces basically the same bad code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34302
[Bug fortran/34133] Bind(c,name="") should be rejected for dummies; F2008: allow bind(c) for internal procs
--- Comment #10 from burnus at gcc dot gnu dot org 2007-11-30 16:04 --- FIXED on the trunk (4.3.0). -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34133
[Bug preprocessor/34288] ssize_t used in libcpp/files.c without autoconf detection
--- Comment #2 from antoine64leca at hotmail dot com 2007-11-30 16:26 --- (In reply to comment #1) > The check in gcc/configure.ac defaults ssize_t to int if it isn't found. > But, we also need to do this in libcpp/configure.ac. Thanks to confirm my intuition. > If I send you a patch, can you test it? > I will send a patch for configure as well. I appreciate your help. With configure's diffs, sure I can (although it won't be until Monday). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34288
[Bug middle-end/31529] ICE in cgraph_expand_function with IMA
--- Comment #3 from aldot at gcc dot gnu dot org 2007-11-30 16:53 ---
Target independent. Reduced from toplev.c and i386.c:
$ cat one.i
getline ()
{
}
$ cat two.i
extern __inline
getline ()
{
}
$ /scratch/obj.i686/gcc-4.3/./prev-gcc/xgcc -v
-B/scratch/obj.i686/gcc-4.3/./prev-gcc/
-B/opt/i686/gcc-4.3//i686-linux-gnu/bin/ -c one.i two.i -o pr.o -combine
Reading specs from /scratch/obj.i686/gcc-4.3/./prev-gcc/specs
Target: i686-linux-gnu
Configured with: ../../src/gcc-4.3/configure -v
--enable-languages=c,c++,fortran,treelang --prefix=/opt/i686/gcc-4.3/
--enable-shared --with-system-zlib --libexecdir=/opt/i686/gcc-4.3/lib
--enable-nls --without-included-gettext --enable-threads=posix
--program-suffix=-4.3-HEAD --enable-__cxa_atexit
--enable-libstdcxx-allocator=mt --enable-clocale=gnu --enable-libstdcxx-debug
--enable-mpfr --disable-werror --enable-checking=yes --enable-debug
--with-gmp=/opt/i686/gmp-4.2.2/ --with-mpfr=/opt/i686/mpfr-2.3.0
--disable-multilib --enable-intermodule i686-linux-gnu
Thread model: posix
gcc version 4.3.0 20071128 (experimental) (GCC)
COLLECT_GCC_OPTIONS='-v' '-B/scratch/obj.i686/gcc-4.3/./prev-gcc/'
'-B/opt/i686/gcc-4.3//i686-linux-gnu/bin/' '-c' '-o' 'pr.o' '-combine'
'-mtune=generic'
/scratch/obj.i686/gcc-4.3/./prev-gcc/cc1 -fpreprocessed one.i two.i -quiet
-dumpbase one.i -mtune=generic -auxbase-strip pr.o -version -o /tmp/ccCpNIlO.s
GNU C (GCC) version 4.3.0 20071128 (experimental) (i686-linux-gnu)
compiled by GNU C version 4.1.2 20061115 (prerelease) (Debian
4.1.1-21), GMP version 4.2.1, MPFR version 2.3.0-p4.
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: 67dafa8bc8cc74b9ccacf5609573a661
two.i:4: internal compiler error: in cgraph_expand_function, at
cgraphunit.c:1146
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31529
[Bug fortran/33888] ICE - CHARACTER expression using an ELEMENTAL FUNCTION as actual arg
--- Comment #3 from pault at gcc dot gnu dot org 2007-11-30 17:05 --- I can see what to do - watch this spot. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2007-10-25 06:30:06 |2007-11-30 17:05:04 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33888
[Bug rtl-optimization/34171] [4.3 Regression] Segfault in df_chain_remove_problem with -O3 on alpha
--- Comment #19 from jakub at gcc dot gnu dot org 2007-11-30 17:07 --- 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=34171
[Bug tree-optimization/34195] missed optimization with store motion (vectorizer)
--- Comment #5 from eres at il dot ibm dot com 2007-11-30 17:24 --- (In reply to comment #4) > That moves the stores > pS[i].x += (a[i]+b[i]); > pS[i].y += (a[i]-b[i]); > out of the inner loop, but still none of the loops are vectorized (on x86_64). Also on ppc64. It seems to be the same problem as PR32824. Nevertheless lim can improved performance regardless of vectorization, as was mentioned before. Taken from the vectorizer dump: u.c:17: note: vect_is_simple_use: operand pS_I__ypS_I_I_lsm.16_15 u.c:17: note: def_stmt: pS_I__ypS_I_I_lsm.16_15 = PHI u.c:17: note: Unsupported pattern. u.c:17: note: not vectorized: unsupported use in stmt. u.c:17: note: unexpected pattern.(get_loop_exit_condition -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34195
[Bug fortran/34248] ICE on assumed length character function
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2007-11-30 17:56 --- Subject: Bug 34248 Author: jvdelisle Date: Fri Nov 30 17:55:55 2007 New Revision: 130542 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130542 Log: 2007-11-30 Jerry DeLisle <[EMAIL PROTECTED]> PR fortran/34248 * gfortran.dg/result_in_spec_3.f90: Add dg-option -std=gnu. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/result_in_spec_3.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34248
[Bug fortran/34305] New: ICE with array(real) declaration
$ cat foo.f program test parameter (datasize = 1000) dimension idata(datasize) idata(1) = -1 end $ gfortran foo.f foo.f:3.22: dimension idata(datasize) 1 Error: Expression at (1) must be of INTEGER type foo.f:3.21: dimension idata(datasize) 1 Error: The module or main program array 'idata' at (1) must have constant shape foo.f:5.72: end 1 Internal Error at (1): compare_bound(): Bad expression -- Summary: ICE with array(real) declaration Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: ice-on-invalid-code, error-recovery Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tkoenig at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34305
[Bug libfortran/34291] [4.3 Regression] Segfault in io/list_read.c handling of end conditions
--- Comment #10 from jvdelisle at gcc dot gnu dot org 2007-11-30 23:22 --- Fixed on trunk. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34291
[Bug libfortran/33985] access="stream",form="unformatted" doesn't buffer
--- Comment #13 from jvdelisle at gcc dot gnu dot org 2007-11-30 23:55 --- Created an attachment (id=14676) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14676&action=view) Another idea borrowing from Thomas Thomas, This patch regression tests OK and passes streamio_12.f90, the original that regressed on my first patch. Just tinkering here a bit. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33985
[Bug libfortran/33985] access="stream",form="unformatted" doesn't buffer
--- Comment #17 from kargl at gcc dot gnu dot org 2007-12-01 07:34 --- (In reply to comment #15) > Hopefully this performance improvement can be backported for gcc 4.2.3 as > well. > This is not a regression fix. It therefore can't be backported. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33985
