--- Comment #5 from hp at gcc dot gnu dot org 2008-03-15 04:03 ---
fixed
--
hp at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #4 from hp at gcc dot gnu dot org 2008-03-15 03:56 ---
Subject: Bug 35595
Author: hp
Date: Sat Mar 15 03:55:22 2008
New Revision: 133238
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133238
Log:
PR middle-end/35595
* gcc.c-torture/compile/pr35595.c:
--- Comment #3 from hp at gcc dot gnu dot org 2008-03-15 03:54 ---
Subject: Bug 35595
Author: hp
Date: Sat Mar 15 03:53:12 2008
New Revision: 133237
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133237
Log:
PR middle-end/35595
* tree-ssa-pre.c (bitmap_find_leade
--- Comment #16 from jvdelisle at gcc dot gnu dot org 2008-03-15 03:23
---
Closing, test case committed to avoid regression.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #15 from jvdelisle at gcc dot gnu dot org 2008-03-15 03:21
---
Subject: Bug 33296
Author: jvdelisle
Date: Sat Mar 15 03:20:57 2008
New Revision: 133236
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133236
Log:
2008-03-14 Jerry DeLisle <[EMAIL PROTECTED]>
--
dje at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Known to fail
"-g" was added to CXXFLAGS in the GLIBCXX_CHECK_COMPILER_FEATURES configure
test in libstdc++. This option causes G++ to warn: "-ffunction-sections may
affect debugging on some targets". CXXFLAGS also includes "-Werror" causing
the warning to become an error. This results in -ffunction-sections
--- Comment #2 from kevin at kelphead dot org 2008-03-15 02:49 ---
Created an attachment (id=15327)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15327&action=view)
Output of compiler when virtual memory is exhausted
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35596
--- Comment #1 from kevin at kelphead dot org 2008-03-15 02:48 ---
Created an attachment (id=15326)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15326&action=view)
.ii produced during compilation
This is the code produced during the failed run of the compiler.
Similar code crash
The attached code runs out of virtual memory with the attached code.
--
Summary: Runs out of virtual memory, with for_each
Product: gcc
Version: 4.1.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
--- Comment #6 from merkert at comcast dot net 2008-03-15 01:45 ---
It seems to do better (still compiling), now that I've adjusted the
LD_LIBRARY_PATH to point to mpfr (there's another bug that seems to be a
duplicate). It should really produce a better warning or something. It really
d
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Priori
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Priori
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Priori
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Priori
--- Comment #1 from jsm28 at gcc dot gnu dot org 2008-03-15 01:33 ---
I don't think this code is valid; the tls_model attribute only makes sense on
an __thread variable.
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
-
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Priori
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Priori
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Priori
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Priori
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Priori
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Priori
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Priori
--- Comment #4 from nicos at maunakeatech dot com 2008-03-15 01:07 ---
I think I need some help here, I looked to bug 323 and I can't see how it is
related to this issue.
The assertion at the end of the test case compares integers, and the iFloor
function is only applied to 0 in the test
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.3.1 |4.2.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33088
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.3.1 |4.2.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19636
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.4.0 |4.3.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35322
--- Comment #1 from jsm28 at gcc dot gnu dot org 2008-03-15 00:43 ---
Update milestone after 4.3.0 release.
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from jsm28 at gcc dot gnu dot org 2008-03-15 00:43 ---
Update milestone after 4.3.0 release.
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from jsm28 at gcc dot gnu dot org 2008-03-15 00:43 ---
Update milestone after 4.3.0 release.
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from jsm28 at gcc dot gnu dot org 2008-03-15 00:43 ---
Update milestone after 4.3.0 release.
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from jsm28 at gcc dot gnu dot org 2008-03-15 00:43 ---
Update milestone after 4.3.0 release.
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from jsm28 at gcc dot gnu dot org 2008-03-15 00:43 ---
Update milestone after 4.3.0 release.
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from jsm28 at gcc dot gnu dot org 2008-03-15 00:42 ---
Update milestone after 4.3.0 release.
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from jsm28 at gcc dot gnu dot org 2008-03-15 00:42 ---
Update milestone after 4.3.0 release.
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from jsm28 at gcc dot gnu dot org 2008-03-15 00:42 ---
Update milestone after 4.3.0 release.
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from jsm28 at gcc dot gnu dot org 2008-03-15 00:42 ---
Update milestone after 4.3.0 release.
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from jsm28 at gcc dot gnu dot org 2008-03-15 00:42 ---
Update milestone after 4.3.0 release.
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from jsm28 at gcc dot gnu dot org 2008-03-15 00:42 ---
Update milestone after 4.3.0 release.
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from jsm28 at gcc dot gnu dot org 2008-03-15 00:42 ---
Update milestone after 4.3.0 release.
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from jsm28 at gcc dot gnu dot org 2008-03-15 00:42 ---
Update milestone after 4.3.0 release.
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from jsm28 at gcc dot gnu dot org 2008-03-15 00:42 ---
Update milestone after 4.3.0 release.
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from jsm28 at gcc dot gnu dot org 2008-03-15 00:41 ---
Update milestone after 4.3.0 release.
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #16 from jsm28 at gcc dot gnu dot org 2008-03-15 00:41 ---
Update milestone after 4.3.0 release.
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #13 from jsm28 at gcc dot gnu dot org 2008-03-15 00:41 ---
Update milestone after 4.3.0 release.
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #18 from jsm28 at gcc dot gnu dot org 2008-03-15 00:41 ---
Update milestone after 4.3.0 release.
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from jsm28 at gcc dot gnu dot org 2008-03-15 00:41 ---
Update milestone after 4.3.0 release.
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from jsm28 at gcc dot gnu dot org 2008-03-15 00:41 ---
Update milestone after 4.3.0 release.
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from jsm28 at gcc dot gnu dot org 2008-03-15 00:40 ---
Update milestone after 4.3.0 release.
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #24 from jsm28 at gcc dot gnu dot org 2008-03-15 00:40 ---
Update milestone after 4.3.0 release.
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #43 from jsm28 at gcc dot gnu dot org 2008-03-15 00:40 ---
Update milestone after 4.3.0 release.
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #28 from jsm28 at gcc dot gnu dot org 2008-03-15 00:39 ---
Update milestone after 4.3.0 release.
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from jsm28 at gcc dot gnu dot org 2008-03-15 00:40 ---
Update milestone after 4.3.0 release.
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from jsm28 at gcc dot gnu dot org 2008-03-15 00:40 ---
Update milestone after 4.3.0 release.
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from jsm28 at gcc dot gnu dot org 2008-03-15 00:40 ---
Update milestone after 4.3.0 release.
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #20 from jsm28 at gcc dot gnu dot org 2008-03-15 00:39 ---
Update milestone after 4.3.0 release.
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from dfranke at gcc dot gnu dot org 2008-03-15 00:33 ---
A less pessimistic warning would do ...
Index: resolve.c
===
--- resolve.c (revision 133233)
+++ resolve.c (working copy)
@@ -5596,7 +5596,7 @@ res
--- Comment #8 from dann at godzilla dot ics dot uci dot edu 2008-03-15
00:28 ---
(In reply to comment #7)
> The testcase is fixed by the SCCVN alias-oracle patch.
Are you sure? I still see the problem (.final_cleanup dump):
void bar(first*, multi*) (s1, s3)
{
:
s1->f1 = 0;
s3->f3
--- Comment #2 from dfranke at gcc dot gnu dot org 2008-03-15 00:28 ---
Here an example were the warning is appropriate:
$> cat infloop.f90
character(3) :: x = "xxx"
1 read(x,FMT="(I1)",err=1) i
write(*,*) i
end
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-03-14 23:56 ---
Created an attachment (id=15325)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15325&action=view)
patch
Pre-approved if you are faster with testing than me ;)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?i
--- Comment #1 from hp at gcc dot gnu dot org 2008-03-14 23:48 ---
Created an attachment (id=15324)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15324&action=view)
gzipped preprocessed code.
Compile with -O2
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35595
With a change in the svn range 133216:133223, build broke in a unified tree for
cris-elf, with the error message:
/tmp/hpautotest-gcc1/gcc/newlib/libm/math/erf_lgamma.c: In function
'__ieee754_lgammaf_r':
/tmp/hpautotest-gcc1/gcc/newlib/libm/math/erf_lgamma.c:153: internal compiler
error: Segmentat
--- Comment #1 from pcarlini at suse dot de 2008-03-14 22:54 ---
Hi Johannes, can you have a look? Many thanks.
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-03-14 22:44 ---
I'll have a look.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedT
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-03-14 22:44 ---
Because we fold the pointer addition to &a->d[-8] ;)
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #21 from laurent at guerby dot net 2008-03-14 22:29 ---
Best think would be to trace rtems calls on a platform where it works vs on the
simulator. On a platform where it works, look at the backtrace of the task
creation call and try to find out why it doesn't get called on i3
--- Comment #20 from joel at gcc dot gnu dot org 2008-03-14 21:46 ---
I don't want this bug to die from inattention. Returning to my analysis of
Laurent's program, the task does not get to run at all before the system is
finalized. I suspect this indicates the initialization of the task
--- Comment #3 from eda-qa at disemia dot com 2008-03-14 21:34 ---
Agreed. That was the obvious bit I was missing.
Sorry about that, just didn't recognize it at first.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35594
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-03-14 21:29 ---
Zdeneks lim/store-motion rewrite should help as well.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #12 from jcea at hispasec dot com 2008-03-14 21:27 ---
Bug hit trying to compile GCC 4.3.0 using SUN ld. If I use the gnu ld (2.18),
compiler builds fine, but then I have problems with tools like gdb and such,
specially with shared libraries. So, no luck.
Post a link to this
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-03-14 21:27 ---
Zdeneks lim/store-motion rewrite should fix this.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-03-14 21:26 ---
out.at(at++) = append( count-1, out );
I think the issue here is the order of evaluation of the lhs and the rhs is
unspecified so we are evaluating out.at(at++) first and then append( count -1,
out) w
--- Comment #9 from tromey at gcc dot gnu dot org 2008-03-14 21:25 ---
I'm testing this patch.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
Assig
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-03-14 21:24 ---
This is most likely a dup of PR 16306.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28030
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-03-14 21:21 ---
Related to PR34172, but not fixed. MEM_REF will get this right as we
effectively
have array refs on pointers there.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Ad
--- Comment #1 from eda-qa at disemia dot com 2008-03-14 21:19 ---
Created an attachment (id=15323)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15323&action=view)
g++ --save-temp fail.cc
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35594
The below code fragment (.ii attached) causes a segmentation fault. I can't
see anything logically wrong with the code, but I am guessing an optimization
of the pointers within "out" are causing the problem: a reallocation occurs in
a deeper stack level, and the outer stack still maintains an old
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-03-14 21:16 ---
This issue boils down to restrict not working or getting lost.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #5 from al dot danial at gmail dot com 2008-03-14 21:15 ---
Indeed, adding the MPFR and GPM lib directories to LD_LIBRARY_PATH solves the
problem. For some reason I thought configure would handle this for me since I
gave it --with-gmp and --with-mpfr settings. Would have be
--- Comment #11 from gopi dot reddy at motorola dot com 2008-03-14 21:14
---
(In reply to comment #3)
> ecj1 is not part of GCC.
Well, it should be. I just downloaded gcc4.3.0, compiled it, and tried to
compile a simple test program.
$ gcj --version
gcj (GCC) 4.3.0
Copyright (C) 2008
--- Comment #9 from rguenth at gcc dot gnu dot org 2008-03-14 21:10 ---
We could simply prune locals from points-to solutions for default defs.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
-
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.3.0 |4.3.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35428
--- Comment #6 from reichelt at gcc dot gnu dot org 2008-03-14 20:45
---
No, it's not a duplicate.
The bug is still present on mainline and 4.3 branch from 2008-03-12
(at least on i686-pc-linux-gnu).
--
reichelt at gcc dot gnu dot org changed:
What|Removed
--- Comment #7 from rguenth at gcc dot gnu dot org 2008-03-14 20:30 ---
The testcase is fixed by the SCCVN alias-oracle patch. I don't see how
BINFOs should be needed here - if the MEM_REFs are still there the
disambiguation can happen based on the member offsets, no?
--
rguenth at
When compiling the following tiny example .cxx source with "-Wall -O2", I get
spurious warnings:
- cut example test.cxx here --
extern void function(void * x);
struct A {
long x;
char d[0];
};
void test(A * a) {
function((char *)a - 4); // gcc emi
--- Comment #10 from rguenth at gcc dot gnu dot org 2008-03-14 20:06
---
This is related to PR27799. It is also fixed with -fstrict-aliasing on the
tree level:
bar ()
{
struct example * ex1.0;
:
ex1.0 = ex1;
ex1.0->a = 1;
ex1.0->b = 2;
ex1.0->c = 3;
return;
}
Without -f
--- Comment #18 from bonzini at gnu dot org 2008-03-14 20:05 ---
The NSS testcase has been fixed, but we found that the committed fix just made
the bug latent. We don't have a failing testcase.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35160
--- Comment #2 from felix-gcc at fefe dot de 2008-03-14 19:58 ---
I am aware of -Wconversion, but I am not interested in ALL conversion
truncations. Truncation happens to be a security issue in a few cases, in many
other cases it would just be a regular bug. My suggestions aims to isol
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-03-14 19:42 ---
Honza implemented this.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from rguenth at gcc dot gnu dot org 2008-03-14 19:37 ---
Can we fix this at expansion time? Thus, move the VIEW_CONVERT_EXPR from the
rhs to the lhs? This might be a target dependent optimization.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33989
--- Comment #9 from rguenth at gcc dot gnu dot org 2008-03-14 19:34 ---
I have a patch. But maybe trying to optimize this is a little bit expensive?
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #3 from dfranke at gcc dot gnu dot org 2008-03-14 19:20 ---
4.2.4 (20080314) gives an ICE as well.
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-03-14 19:20 ---
You should try -Wconversion .
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35592
gcc has a warning if one assigns a pointer to an integer of lower width.
I would like to have a way to be warned if someone calls malloc(long long) on
32-bit platforms. A general warning about integer truncation would generate
lots of spam, so I suggest adding a way to say "if an integer given to
--- Comment #8 from pinskia at gcc dot gnu dot org 2008-03-14 19:14 ---
We do get:
*b = VIEW_CONVERT_EXPR(*a + e);
Now, if produced:
VIEW_CONVERT_EXPR(*b) = *a + e;
We might produce better code as SImode is not able to held in FPRs.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?
--- Comment #7 from pinskia at gcc dot gnu dot org 2008-03-14 19:12 ---
PPC still gets bad code:
_f:
lfs f0,0(r3)
fadds f0,f1,f0
stfs f0,-8(r1)
lwz r0,-8(r1)
stw r0,0(r4)
blr
--
pinskia at gcc dot gnu dot org changed:
What
// David
For value profiling transformation to kick in, gcc requires value histogram to
have a value with dominating count. However, another heuristic that can be used
is to check if the total number of values is small, for instance 2.
The following progrma shows the problem:
//
#include
vo
--- Comment #17 from nelson at bolyard dot com 2008-03-14 18:59 ---
Would an attached copy of the relevant NSS source file suffice for a test case?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35160
--- Comment #5 from merkert at comcast dot net 2008-03-14 18:57 ---
I've been getting the same thing with the 4.3 release build. I had no problem
building this version: gcc (GCC) 4.3.0 20071228 (experimental)
Here's the tail of my output (I'll try to build again)
m -f include-fixed/R
--- Comment #1 from xinliangli at gmail dot com 2008-03-14 18:55 ---
(In reply to comment #0)
> value profiling transformation does not kick in for the following simple
> program. Looks like it requires power of 2 values to dominate. It is probably
> not due to design but simply lack of
1 - 100 of 215 matches
Mail list logo
