[Bug libstdc++/30280] SIGSEGV on operator==(valarray, bool)
--- Comment #7 from ebotcazou at gcc dot gnu dot org 2006-12-23 08:05 --- > Here's the output of g++ -v if it helps: Thanks, but we still need the preprocessed sources... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30280
[Bug c/30282] New: Optimization flag -O2 generate error stack operating code
Stack operating code that generated by gcc have an error. In some operating
system that saved the thread's context in stack when schedule, it will be have
critical problem.
Enabling the compiler optimalisation (-O2 option) the error will be occuring,
and don't occur when using option -O1 or -O0.
--- sample ---
array.c:
int find_num(int i)
{
const int arr[5] = {0, 1, 2, 3, 4};
return arr[i];
}
using command:
ppc-eabi-gcc -c -O2 array.c -o array.o
ppc-eabi-objdump -S array.o
the disassemble code is:
:
0: 3d 60 00 00 lis r11,0
4: 94 21 ff d0 stwur1,-48(r1)
8: 39 2b 00 00 addir9,r11,0
c: 81 0b 00 00 lwz r8,0(r11)
10: 80 e9 00 10 lwz r7,16(r9)
14: 54 63 10 3a rlwinm r3,r3,2,0,29
18: 80 09 00 04 lwz r0,4(r9)
1c: 81 69 00 08 lwz r11,8(r9)
20: 81 49 00 0c lwz r10,12(r9)
24: 7d 21 1a 14 add r9,r1,r3
28: 91 01 00 10 stw r8,16(r1)
2c: 90 01 00 14 stw r0,20(r1)
30: 91 61 00 18 stw r11,24(r1)
34: 91 41 00 1c stw r10,28(r1)
38: 90 e1 00 20 stw r7,32(r1)
3c: 38 21 00 30 addir1,r1,48
40: 80 69 00 10 lwz r3,16(r9)
44: 4e 80 00 20 blr
The instruction 3c let stack pointer back, and instruction 40 load data from
the stack, this is error. The true code must be:
lwz r3,16(r9)
addir1,r1,48
And when you using option -O1, the code generated is true.
Release:
GCC v3.4.6 ppc-eabi cross compiler in cygwin
Environment:
Reading specs from
/cygdrive/d/Compiler/gcc3.4.6-ppc-eabi/bin/../lib/gcc/ppc-eab
i/3.4.6/specs
Configured with: ../configure --target=ppc-eabi
--prefix=/usr/local/gcc3.4.6-ppc
-eabi --enable-languages=c
Thread model: single
gcc version 3.4.6
How-To-Repeat:
Using my sample.
--
Summary: Optimization flag -O2 generate error stack operating
code
Product: gcc
Version: 3.4.6
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: chenkb at ruijie dot com dot cn
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30282
[Bug target/30282] Optimization flag -O2 generate error stack operating code
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|major |normal Component|c |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30282
[Bug target/30282] Optimization flag -O1 -fschedule-insns2 cause red zone to be used when there is none
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-12-23 10:31 ---
For 4.0 and above your sample code works but that is a different issue.
Here is a testcase which fails for 4.0 and above:
int find_num(int i)
{
int arr[5] = {0, 1, 2, 3, 4};
return arr[i];
}
The problem is the scheduler is moving the load past the update of r1 which is
invalid for the SYSV ABI to do as there is no red zone.
This has almost always been an issue since the rs6000 target was added and/or
the scheduler was added.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
GCC target triplet||powerpc-linux-gnu powerpc-
||eabi
Keywords||wrong-code
Last reconfirmed|-00-00 00:00:00 |2006-12-23 10:31:55
date||
Summary|Optimization flag -O2 |Optimization flag -O1 -
|generate error stack|fschedule-insns2 cause red
|operating code |zone to be used when there
||is none
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30282
[Bug libstdc++/30280] SIGSEGV on operator==(valarray, bool)
--- Comment #8 from gdr at integrable-solutions dot net 2006-12-23 11:17 --- Subject: Re: SIGSEGV on operator==(valarray, bool) "pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes: | What target is this one, all I get is: | t.cc:8: error: cannot convert 'std::_Expr > >, | bool>' to 'long int' for argument '1' to 'long int __builtin_expect(long int, | long int)' I don't remember I ever used this funky __builtin_expect. valarray is improving everyday :-( -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30280
[Bug c++/30281] [reject valid?] type deduction fails.
--- Comment #1 from pluto at agmk dot net 2006-12-23 11:21 --- wrapper< my_error >().add_method< char const* >( &my_error::what ); such call compiles, so it looks like type deduction failure. -- pluto at agmk dot net changed: What|Removed |Added Summary|[reject valid?] mismatch|[reject valid?] type |type of virtual method. |deduction fails. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30281
[Bug fortran/30278] Inconsistencies with backslash handling
-- steven at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-12-23 12:12:23 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30278
[Bug fortran/30278] Inconsistencies with backslash handling
--- Comment #1 from steven at gcc dot gnu dot org 2006-12-23 12:19 --- This is what g77 outputs for this test case: results in:ackslash results in: \backslash ackslash now results inackslash \backslash now results in \backslash -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30278
[Bug fortran/30278] Inconsistencies with backslash handling
--- Comment #2 from steven at gcc dot gnu dot org 2006-12-23 12:42 --- I suspect that the problem is some difference between the front end and library FORMAT parsers. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30278
[Bug fortran/30278] Inconsistencies with backslash handling
--- Comment #3 from steven at gcc dot gnu dot org 2006-12-23 12:52 ---
This not-for-including patch shows that we should match "\\" in io.c and treat
it as a single '\\' character. This is what g77 appears to do, too.
Index: io.c
===
--- io.c(revision 120167)
+++ io.c(working copy)
@@ -905,6 +905,24 @@ gfc_match_format (void)
check_format (); /* Guaranteed to succeed */
gfc_match_eos ();/* Guaranteed to succeed */
+ {
+char c1, c2;
+int i, j;
+int len = e->value.character.length;
+for (i = 0; i < len - 1; ++i)
+ {
+ c1 = e->value.character.string[i];
+ c2 = e->value.character.string[i + 1];
+ if (c1 == '\\' && c2 == '\\')
+ {
+ for (j = i; j < len; ++j)
+ e->value.character.string[j] = e->value.character.string[j+1];
+ len--;
+ }
+ }
+e->value.character.length = len;
+ }
+
return MATCH_YES;
}
My understanding of io.c is not quite good, so perhaps someone who understands
that code well can have a look at a proper fix.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30278
[Bug fortran/30278] Inconsistencies with backslash handling
--- Comment #4 from tobi at gcc dot gnu dot org 2006-12-23 13:12 --- NB The whole of \-ed symbols would have to be interpreted, conditionalized on -fbackslash. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30278
[Bug fortran/30278] Inconsistencies with backslash handling
--- Comment #5 from steven at gcc dot gnu dot org 2006-12-23 13:17 --- Created an attachment (id=12838) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12838&action=view) Handle escaped characters if flag_backslash Slightly less horrible patch... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30278
[Bug tree-optimization/30089] Compiling FreeFem3d uses unreasonable amount of time and memory
--- Comment #13 from hubicka at gcc dot gnu dot org 2006-12-23 14:26 --- Note that we've got another noticeable jump in memory consumption today (well at least it would be very important jump if we used just 28MB of memory for aliasing :). Is that also aliasing or shall be analyzed? Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30089
[Bug tree-optimization/30089] Compiling FreeFem3d uses unreasonable amount of time and memory
--- Comment #14 from hubicka at gcc dot gnu dot org 2006-12-23 14:27 --- Well, actually the testcase now runs out of memory and ICE... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30089
[Bug fortran/30276] gfortran include problem
--- Comment #2 from steven at gcc dot gnu dot org 2006-12-23 14:48 --- I think the proper fix is to add "." to the search list of directories where include files may live. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30276
[Bug fortran/29975] [meta-bugs] ICEs with CP2K
--- Comment #43 from steven at gcc dot gnu dot org 2006-12-23 14:51 --- Fixed in GCC 4.3.0 -- steven 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=29975
[Bug tree-optimization/30089] Compiling FreeFem3d uses unreasonable amount of time and memory
--- Comment #15 from dberlin at gcc dot gnu dot org 2006-12-23 16:21 --- Subject: Re: Compiling FreeFem3d uses unreasonable amount of time and memory On 23 Dec 2006 14:26:00 -, hubicka at gcc dot gnu dot org <[EMAIL PROTECTED]> wrote: > > > --- Comment #13 from hubicka at gcc dot gnu dot org 2006-12-23 14:26 > --- > Note that we've got another noticeable jump in memory consumption today (well > at least it would be very important jump if we used just 28MB of memory for > aliasing :). Is that also aliasing or shall be analyzed? It's possible it was my aliasing fix, but it's hard to say. I had only seen cases where it increased mem usage ~3-5% (this was on large testcases too). It certainly shouldn't run out of memory. In any case, i'm working on testing bitmaps for may-aliases right now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30089
[Bug middle-end/7651] Define -Wextra strictly in terms of other warning flags
--- Comment #11 from manu at gcc dot gnu dot org 2006-12-23 17:45 --- Subject: Bug 7651 Author: manu Date: Sat Dec 23 17:45:33 2006 New Revision: 120173 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120173 Log: 2006-12-23 Manuel Lopez-Ibanez <[EMAIL PROTECTED]> PR middle-end/7651 * c.opt (Wmissing-parameter-type): New. * doc/invoke.texi (Wmissing-parameter-type): Document it. (Wextra): Enabled by -Wextra. * c-opts.c (c_common_post_options): Enabled by -Wextra. * c-decl.c (store_parm_decls_oldstyle): Replace Wextra with Wmissing-parameter-type. testsuite/ * gcc.dg/Wmissing-parameter-type.c: New. * gcc.dg/Wmissing-parameter-type-Wextra.c: New. * gcc.dg/Wmissing-parameter-type-no.c: New. Added: trunk/gcc/testsuite/gcc.dg/Wmissing-parameter-type-Wextra.c trunk/gcc/testsuite/gcc.dg/Wmissing-parameter-type-no.c trunk/gcc/testsuite/gcc.dg/Wmissing-parameter-type.c Modified: trunk/gcc/ChangeLog trunk/gcc/c-decl.c trunk/gcc/c-opts.c trunk/gcc/c.opt trunk/gcc/doc/invoke.texi trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7651
[Bug target/29867] [4.3 Regression] building libgfortran fails because of multiple definitions gcc-4.3-20061111
--- Comment #17 from dfranke at gcc dot gnu dot org 2006-12-23 17:53 --- Created an attachment (id=12839) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12839&action=view) fixincludes: find headers in distro-specfic paths * fixincl.c(fix_applies): Use fnmatch instead of strstr to allow shell-like wildcard pattern matching. * inclhack.def(glibc_c99_inline_[1234]): Add search patterns to file list. * fixincl.x: Regenerated. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29867
Re: [Bug libstdc++/30280] SIGSEGV on operator==(valarray, bool)
On Sat, 2006-12-23 at 11:17 +, gdr at integrable-solutions dot net wrote: > > I don't remember I ever used this funky __builtin_expect. > valarray is improving everyday :-( You most likely did not but assert did :). -- Pinski
[Bug libstdc++/30280] SIGSEGV on operator==(valarray, bool)
--- Comment #9 from pinskia at gmail dot com 2006-12-23 18:50 --- Subject: Re: SIGSEGV on operator==(valarray, bool) On Sat, 2006-12-23 at 11:17 +, gdr at integrable-solutions dot net wrote: > > I don't remember I ever used this funky __builtin_expect. > valarray is improving everyday :-( You most likely did not but assert did :). -- Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30280
[Bug fortran/30283] New: Specification expression not properly recognized in type declaration
Hi, the following legal code fails to compile with gfortran: % cat gfcbug50.f90 module gfcbug50 implicit none contains subroutine foo (n, y) integer, intent(in) :: n integer, dimension(bar (n)) :: y ! Array bound is specification expression, which is allowed (F2003, sect. 7. 1.6) end subroutine foo pure function bar (n) result (l) integer, intent(in) :: n integer :: l l = n end function bar end module gfcbug50 % gfc -c gfcbug50.f90 gfcbug50.f90:7.23: integer, dimension(bar (n)) :: y 1 Error: Expression at (1) must be of INTEGER type This is wrong. bar(n) is a specification expression. See e.g. the F2003 standard, sect. 7.1.6 Cheers, -ha -- Summary: Specification expression not properly recognized in type declaration Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: anlauf at gmx dot de GCC host triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30283
[Bug libstdc++/30280] SIGSEGV on operator==(valarray, bool)
--- Comment #10 from sebor at roguewave dot com 2006-12-23 20:46 --- Created an attachment (id=12840) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12840&action=view) preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30280
[Bug fortran/30284] New: ICE in gfc_add_modify, at fortran/trans.c:159
Hi, here's another one: % cat gfcbug51.f90 program gfcbug51 implicit none type date_t character(len=12) :: date = '200612231200' ! mmddhhmm end type date_t type year_t integer :: year = 0 end type year_t type(date_t) :: file(1) type(year_t) :: time(1) read (file% date(1:4),'(i4)') time% year print *, time% year end program gfcbug51 % gfc gfcbug51.f90 gfcbug51.f90: In function 'MAIN__': gfcbug51.f90:1: internal compiler error: in gfc_add_modify, at fortran/trans.c:1 59 Cheers, -ha -- Summary: ICE in gfc_add_modify, at fortran/trans.c:159 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: anlauf at gmx dot de GCC host triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30284
[Bug target/28764] [4.2 Regression] libjava build failure on sh4
--- Comment #18 from ubizjak at gmail dot com 2006-12-23 21:24 ---
(In reply to comment #12)
> As far as I can see, the i387 mode switching is already completely broken,
> because it treats the different modes of a single mode-switchable entity
> as separate entities.
NO, it is _NOT_ broken by any stretch of imagination!
Perhaps something could be writtenn in a more fancy way, but there is a reason,
why we have separate entities for x87. Please note, that at mode switch point,
we insert code that calculates mode word and stores the result in memory. This
value is then used at the point, where mode is briefly switched for the insn to
operate in desired mode.
So, consider this testcase:
--cut here--
double test(double *a, int x)
{
int i;
double z = 0.0;
for (i = 0; i < x; i++)
z += floor(a[i]) + ceil(a[i]);
return z;
}
--cut here--
This gets compiled by current approach (-O2 -ffast-math) into:
fnstcw -6(%ebp)
xorl%edx, %edx
fldz
movzwl -6(%ebp), %eax
movb$4, %ah
movw%ax, -10(%ebp)
movzwl -6(%ebp), %eax
movb$8, %ah
movw%ax, -8(%ebp)
.p2align 4,,7
.L5:
fldl(%ebx,%edx,8)
addl$1, %edx
fld %st(0)
cmpl%ecx, %edx
fldcw -8(%ebp)
frndint
fldcw -6(%ebp)
fxch%st(1)
fldcw -10(%ebp)
frndint
fldcw -6(%ebp)
faddp %st, %st(1)
faddp %st, %st(1)
jne .L5
Note that mode word calculation is pushed out of the loop.
I actualy considered an idea that implemented proposed
"several-modes-for-one-entity" approach for x87. However, modes are switched
_inside_ the loop, so by this approach mode calculation code also stays inside:
.L5:
fldl(%ebx,%edx,8)
addl$1, %edx
fnstcw -6(%ebp)
fld %st(0)
cmpl%ecx, %edx
movzwl -6(%ebp), %eax
movb$8, %ah
movw%ax, -8(%ebp)
movzwl -6(%ebp), %eax
fldcw -8(%ebp)
frndint
fldcw -6(%ebp)
fxch%st(1)
movb$4, %ah
movw%ax, -10(%ebp)
fldcw -10(%ebp)
frndint
fldcw -6(%ebp)
faddp %st, %st(1)
faddp %st, %st(1)
jne .L5
Now, which code is preferred?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28764
[Bug fortran/30285] New: gfortran huge (excessive?) memory usage with large modules
Hi, gfortran seems to use much more memory at compile time when I "use" larger modules that contain many symbols, even if I "use, only" selected one. In the described situation it needs significantly more memory than "competitors". The attached archive contains the following main program and three (3) large modules to demonstrate this. The variant with the commented lines uncommented goes beyond 500 MB virtual memory in a Linux/x86 machine. program main use mo_psas, only: setup_psas use mo_3dvar, only: obs, bg ! use mo_t_enkf,only: enkf_driver ! Uncomment to go beyond 500 MB virt ual mem. implicit none call setup_psas (obs% o, bg% grid% a, bg) ! call enkf_driver end program main Compiling this program with: % gfortran -S -fmem-report -ftime-report Memory still allocated at the end of the compilation process Size AllocatedUsedOverhead 8 40962816 96 1616k 13k256 64 40961088 40 128 4096 768 36 256 40962304 32 512 64k 61k512 2048 36k 36k288 4096 16k 16k128 819281928192 32 32768416k416k416 8388608 8192k 8192k 32 56 4096 280 40 104 20k 17k180 92 106M105M958k 80 4096 80 36 8873M 72M661k 2424k 15k312 72 4096 288 36 28 9208k 9189k107k 112 44k 37k396 36 4096 288 44 12 10164k 10146k178k 4033M 33M364k Total240M238M 2274k String pool entries 336041 identifiers 336041 (100.00%) slots 524288 bytes 4934k (350k overhead) table size 2048k coll/search 0.6655 ins/search 0.2790 avg. entry 15.04 bytes (+/- 0.99) longest entry 34 ??? tree nodes created (No per-node statistics) Type hash: size 1021, 175 elements, 0.084121 collisions DECL_DEBUG_EXPR hash: size 1021, 0 elements, 0.00 collisions DECL_VALUE_EXPR hash: size 2097143, 865473 elements, 1.209451 collisions Execution times (seconds) garbage collection: 1.56 (19%) usr 0.00 ( 0%) sys 1.54 (17%) wall 0 kB ( 0%) ggc parser: 6.29 (78%) usr 0.78 (99%) sys 7.08 (79%) wall 25 1744 kB (100%) ggc symout: 0.00 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall 0 kB ( 0%) ggc TOTAL : 8.11 0.79 8.91 25 2445 kB Extra diagnostic checks enabled; compiler may run slowly. Configure with --disable-checking to disable checks. The modules are extracted from a larger project and should be sufficient to just compile the example. The project uses MPI (mpich) which is why these symbols occur quite frequently in the module files. Gfortran seems to handle the present case quite inefficiently. Maybe there is a solution that handles used modules more economically... Cheers, -ha -- Summary: gfortran huge (excessive?) memory usage with large modules Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: anlauf at gmx dot de GCC host triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30285
[Bug fortran/30285] gfortran huge (excessive?) memory usage with large modules
--- Comment #1 from anlauf at gmx dot de 2006-12-24 00:28 --- Created an attachment (id=12841) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12841&action=view) main.f90 + 3 modules included my main -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30285
[Bug fortran/30278] Inconsistencies with backslash handling
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2006-12-24 03:14 --- With th patch in comment #5, NIST tests go OK. It matches g77 behavior. I am thinking though that the default behavior should be -fno-backslash. With -fno-backslash, gfortran matches intel behavior. My impression is that escaping with backslashes is non-standard behavior, so we should require a parameter to invoke it. It could also be tied in with -std=legacy. If not this, then we should at least do -fno-backslash with -std=f95 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30278
[Bug middle-end/30250] Evaluate lgamma/gamma at compile-time
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-12-24 03:33 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-12-24 03:33:42 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30250
[Bug middle-end/30251] Evaluate bessel functions at compile-time
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-12-24 03:34 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-12-24 03:34:02 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30251
[Bug target/30266] [4.1 Regression] Segfault with -O2 -ftrapv
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Keywords||ice-on-valid-code Known to fail||4.1.2 Known to work||4.0.2 4.2.0 4.3.0 Summary|Segfault in cc1 |[4.1 Regression] Segfault ||with -O2 -ftrapv Target Milestone|--- |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30266
[Bug middle-end/30286] New: [4.1 Regression] Segfault with -O2 -ftrapv
Testcase:
struct free_block {
struct free_block *next;
};
struct mm {
struct free_block *free_arr[25];
};
void get_exact(int i, struct mm *mm, struct free_block *p)
{
int j;
for (j=14; j>i; j--)
mm->free_arr[j] = p->next;
}
--
Summary: [4.1 Regression] Segfault with -O2 -ftrapv
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30286
[Bug target/30266] [4.1 Regression] Segfault with -O2 -ftrapv
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-12-24 04:40 --- *** This bug has been marked as a duplicate of 30286 *** -- 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=30266
[Bug middle-end/30286] [4.1 Regression] Segfault with -O2 -ftrapv
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-12-24 04:40 --- *** Bug 30266 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||perm at sics dot se http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30286
[Bug middle-end/30286] [4.1 Regression] Segfault with -O2 -ftrapv
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-12-24 04:41 --- Confirmed, I created a new bug because the other one was a mess since the preprocessed source was not attached but just pasted. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Known to fail||4.1.2 Known to work||4.0.2 4.2.0 4.3.0 Last reconfirmed|-00-00 00:00:00 |2006-12-24 04:41:47 date|| Target Milestone|--- |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30286
[Bug target/30153] -fPIC failure
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-12-24 04:49 --- As far as I can tell this is really a binutils issue. the difference between static inline and just static is where foo is emitted. In the static inline case, it is emitted after bar. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30153
[Bug c/30171] non-portable va_list abuse should be diagnostic
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-12-24 04:50 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||diagnostic Last reconfirmed|-00-00 00:00:00 |2006-12-24 04:50:11 date|| Summary|non-portable va_list abuse |non-portable va_list abuse |is permitted on i386|should be diagnostic http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30171
[Bug libstdc++/30280] SIGSEGV on operator==(valarray, bool)
--- Comment #11 from pinskia at gcc dot gnu dot org 2006-12-24 04:56 --- So on solaris assert is defined as (void)((operand) || (__assert (),0) ); -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30280
[Bug target/30280] SIGSEGV on operator==(valarray, bool)
--- Comment #12 from pinskia at gcc dot gnu dot org 2006-12-24 05:02 --- I am starting to think Solaris's definition of assert is incorrect because you can actually overload "operator ||" and force evulation of both operands in C++ which is what is happening here. All other asserts I know of use ?: which cannot be overloaded. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|libstdc++ |target GCC target triplet||sparc-sun-solaris2.9 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30280
[Bug fortran/30207] [4.2 Regression] ICE in gfc_dep_resolver with where (a < 0) a(:) = 1
--- Comment #11 from pinskia at gcc dot gnu dot org 2006-12-24 05:03 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30207
[Bug driver/17621] Add option to have GCC not search $(prefix)
--- Comment #19 from pinskia at gcc dot gnu dot org 2006-12-24 05:04 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17621
[Bug target/24036] [4.1/4.2 Regression] [e500] ICE in subreg_offset_representable_p, at rtlanal.c:3143
--- Comment #11 from pinskia at gcc dot gnu dot org 2006-12-24 05:08 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24036
[Bug fortran/30145] Fortran 90: write statement fails to ignore zero-sized array...
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-12-24 05:09 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30145
[Bug middle-end/30229] Out of memory error during make of gcc 4.1.1 using 3.3.5
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-12-24 05:11 --- Try first compiling 4.0.0 and then 4.1.1 since it is the compiler which installed already which is running out of memory. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30229
[Bug target/30280] SIGSEGV on operator==(valarray, bool)
--- Comment #13 from gdr at integrable-solutions dot net 2006-12-24 05:23 --- Subject: Re: SIGSEGV on operator==(valarray, bool) "pinskia at gmail dot com" <[EMAIL PROTECTED]> writes: | --- Comment #9 from pinskia at gmail dot com 2006-12-23 18:50 --- | Subject: Re: SIGSEGV on operator==(valarray, | bool) | | On Sat, 2006-12-23 at 11:17 +, gdr at integrable-solutions dot net | wrote: | > | > I don't remember I ever used this funky __builtin_expect. | > valarray is improving everyday :-( | | | You most likely did not but assert did :). Doh. You're right; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30280
[Bug fortran/30284] ICE in gfc_add_modify with internal reads
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-12-24 05:25 --- Reduced testcase: program gfcbug51 type date_t character(len=12) :: date end type date_t type(date_t) :: file(1) read (file%date(1:4),'(i4)') a end program gfcbug51 -- Here is a patch which fixes the issue too: Index: trans-io.c === --- trans-io.c (revision 120165) +++ trans-io.c (working copy) @@ -635,7 +635,7 @@ set_internal_unit (stmtblock_t * block, /* The cast is needed for character substrings and the descriptor data. */ gfc_add_modify_expr (&se.pre, io, fold_convert (TREE_TYPE (io), tmp)); - gfc_add_modify_expr (&se.pre, len, se.string_length); + gfc_add_modify_expr (&se.pre, len, fold_convert (TREE_TYPE (len), se.string_length)); gfc_add_modify_expr (&se.pre, desc, se.expr); gfc_add_block_to_block (block, &se.pre); -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||ice-on-valid-code Last reconfirmed|-00-00 00:00:00 |2006-12-24 05:25:13 date|| Summary|ICE in gfc_add_modify, at |ICE in gfc_add_modify with |fortran/trans.c:159 |internal reads http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30284
[Bug fortran/30249] Pointers not given target type in GFORTRAN
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-12-24 05:36 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added OtherBugsDependingO||24546 nThis|| Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||wrong-debug Last reconfirmed|-00-00 00:00:00 |2006-12-24 05:36:28 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30249
[Bug c++/30158] [4.0/4.1/4.2/4.3 regression] ICE with invalid statement-expressions
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-12-24 06:12 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |minor Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-12-24 06:12:27 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30158
[Bug tree-optimization/30177] [4.3 Regression] ICE in ssa_operand_alloc, at tree-ssa-operands.c:365
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-12-24 06:13 --- I think this has been fixed already. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30177
[Bug bootstrap/19176] [4.0/4.1/4.2/4.3 Regression] static gcc cannot be build (libgcc_eh.a required for static gcc)
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-12-24 06:21 --- *** This bug has been marked as a duplicate of 26510 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19176
[Bug target/26510] [4.1/4.2/4.3 Regression] --disable-shared broken for darwin platform
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-12-24 06:21 --- *** Bug 19176 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||hideishi at magisystem dot ||net Bug 26510 depends on bug 19176, which changed state. Bug 19176 Summary: [4.0/4.1/4.2/4.3 Regression] static gcc cannot be build (libgcc_eh.a required for static gcc) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19176 What|Old Value |New Value Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26510
