--- Comment #3 from jakub at gcc dot gnu dot org 2009-01-27 10:09 ---
Subject: Bug 38872
Author: jakub
Date: Tue Jan 27 10:09:23 2009
New Revision: 143698
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143698
Log:
PR libgcj/38872
* gcj/javaprims.h
--- Comment #4 from jakub at gcc dot gnu dot org 2009-01-27 10:18 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #5 from uros at gcc dot gnu dot org 2009-01-27 10:19 ---
Subject: Bug 38969
Author: uros
Date: Tue Jan 27 10:18:54 2009
New Revision: 143699
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143699
Log:
PR middle-end/38969
* calls.c
--- Comment #9 from jakub at gcc dot gnu dot org 2009-01-27 10:25 ---
So, what should we do for 4.4 then?
--- tree-vrp.c.jj2009-01-02 09:32:55.0 +0100
+++ tree-vrp.c2009-01-27 11:16:57.0 +0100
@@ -1620,7 +1620,8 @@ extract_range_from_assert (value_range_t
--- Comment #6 from ubizjak at gmail dot com 2009-01-27 10:27 ---
Fixed in the trunk.
--
ubizjak at gmail dot com changed:
What|Removed |Added
URL|
--- Comment #10 from rguenther at suse dot de 2009-01-27 10:29 ---
Subject: Re: [4.3/4.4 Regression] ICE in set_value_range,
at tree-vrp.c:398
On Tue, 27 Jan 2009, jakub at gcc dot gnu dot org wrote:
--- Comment #9 from jakub at gcc dot gnu dot org 2009-01-27 10:25 ---
--- Comment #16 from rguenth at gcc dot gnu dot org 2009-01-27 10:43
---
Subject: Bug 38503
Author: rguenth
Date: Tue Jan 27 10:42:59 2009
New Revision: 143700
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143700
Log:
2009-01-27 Richard Guenther rguent...@suse.de
PR
--- Comment #17 from rguenth at gcc dot gnu dot org 2009-01-27 10:43
---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from bonzini at gnu dot org 2009-01-27 10:33 ---
integer overflow in expression
is emitted only for 32-bit HWI gcc, for x86_64 -m32 as well as -m64 only the
first warning is emitted.
If the warning should be there in 64-bit HWI gcc too, that's a separate bug.
But if
This testcase fails:
/* { dg-do compile } */
/* { dg-options -O2 -fno-delete-null-pointer-checks -fdump-tree-optimized }
*/
int f(int *p)
{
int a = *p;
int *null = 0;
*null = 5;
return *p == a;
}
/* { dg-final { scan-tree-dump-times = \\\*p 2 optimized } } */
/* { dg-final {
--- Comment #1 from bonzini at gnu dot org 2009-01-27 11:02 ---
This simple patch is not enough:
Index: tree-ssa-structalias.c
===
--- tree-ssa-structalias.c (revision 142960)
+++ tree-ssa-structalias.c (working
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-01-27 11:06 ---
Can you fill in a known-to-work version?
ANYTHING = ANYTHING
ESCAPED = *ESCAPED
NONLOCAL = ESCAPED
INTEGER = ANYTHING
derefaddrtmp.8 = NONLOCAL
*ESCAPED = derefaddrtmp.8
p = NONLOCAL
misses a constraint for null.
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-01-27 11:06 ---
hm, or rather, we CCP into null ... which makes this an operand scanner issue.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38984
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-01-27 11:07 ---
Smaller testcase:
unsigned foo (int _si1, unsigned _si2)
{
return _si1 0 _si1 2147483647 - _si2;
}
unsigned bar (unsigned _left, int _right)
{
return (unsigned) _right = 8 ? 1 : _left _right;
}
unsigned
Sent from my iPhone
On Jan 27, 2009, at 3:02 AM, bonzini at gnu dot org gcc-bugzi...@gcc.gnu.org
wrote:
--- Comment #1 from bonzini at gnu dot org 2009-01-27 11:02
---
This simple patch is not enough:
Index: tree-ssa-structalias.c
--- Comment #4 from pinskia at gmail dot com 2009-01-27 11:08 ---
Subject: Re: [4.2/4.3/4.4 Regression] NULL pointers always considered distinct
by PTA, even with -fno-delete-null-pointer-checks
Sent from my iPhone
On Jan 27, 2009, at 3:02 AM, bonzini at gnu dot org
--- Comment #5 from bonzini at gnu dot org 2009-01-27 11:09 ---
I don't think CCPing of the null variable is a problem. Writing it as *(int
*)0 = 5 would not make the testcase invalid.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38984
This testcase fails:
/* { dg-do compile } */
/* { dg-options -O2 -fdump-tree-optimized } */
int f(int *p)
{
int a = *p;
int *q = (int *)0xDEADBEE0;
*q = 5;
return *p == a;
}
/* { dg-final { scan-tree-dump-times = \\\*p 2 optimized } } */
/* { dg-final { scan-tree-dump-not return 1
--- Comment #6 from bonzini at gnu dot org 2009-01-27 11:15 ---
The issue with the operand scanner is now PR38985
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38984
Sent from my iPhone
On Jan 27, 2009, at 3:15 AM, bonzini at gnu dot org gcc-bugzi...@gcc.gnu.org
wrote:
This testcase fails:
/* { dg-do compile } */
/* { dg-options -O2 -fdump-tree-optimized } */
int f(int *p)
{
int a = *p;
int *q = (int *)0xDEADBEE0;
*q = 5;
return *p == a;
}
/* {
--- Comment #1 from pinskia at gmail dot com 2009-01-27 11:27 ---
Subject: Re: New: [4.2/4.3/4.4 Regression] missing constraints for pointers
accessed directly via their address
Sent from my iPhone
On Jan 27, 2009, at 3:15 AM, bonzini at gnu dot org gcc-bugzi...@gcc.gnu.org
--- Comment #12 from jakub at gcc dot gnu dot org 2009-01-27 11:29 ---
The difference is in interpret_integer:
579 if (itk == itk_none)
580/* cpplib has already issued a warning for overflow. */
581type = ((flags CPP_N_UNSIGNED)
582? widest_unsigned_literal_type_node
583
--- Comment #13 from uros at gcc dot gnu dot org 2009-01-27 11:39 ---
Subject: Bug 38706
Author: uros
Date: Tue Jan 27 11:39:42 2009
New Revision: 143701
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143701
Log:
gcc/ChangeLog:
Backport from mainline:
2009-01-13
--- Comment #13 from jakub at gcc dot gnu dot org 2009-01-27 11:59 ---
I wonder if the libcpp warning is correct in this case for -std=c99/-std=gnu99,
saying that the constant is too large that it is unsigned doesn't match the C99
wording, which says that the constant may have a signed
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-01-27 12:04 ---
Works on the alias-improvements branch. Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-01-27 12:06 ---
In the operand scanner we try to be clever ...
else if (TREE_CODE (ptr) == INTEGER_CST)
{
/* If a constant is used as a pointer, we can't generate a real
operand for it but we mark the
Suppose that someone wants to see if a string is shorter than another and
writes:
#include string.h
bool f(char const * const a, char const * const b) {return strlen(a) =
strlen(b);}
Then g++ generates this:
pushl %ebp
movl%esp, %ebp
pushl %ebx
subl
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-01-27 12:09 ---
The bad thing is that this is really bad. We would need to add the SMT for
the type here, but we have no way of looking that up. So the only way to fix
this in a reasonable way is to simply not CCP constant
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-01-27 12:13 ---
Note that for *(int *)0 = 5 the gimplifier inserts a temporary.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38984
--- Comment #8 from pault at gcc dot gnu dot org 2009-01-27 12:16 ---
I have done most of the work on the corner cases and the fix below looks good.
I am marking it as pending for temporary book-keeping purposes.
Paul
--
pault at gcc dot gnu dot org changed:
What
--- Comment #6 from bonzini at gnu dot org 2009-01-27 12:21 ---
These passes are able to propagate the address to the load: CCP, VRP, DOM. If
we decide that it's an invalid transformation, fixing them would fix this bug.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38985
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-01-27 12:04 ---
Mine.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from bonzini at gnu dot org 2009-01-27 12:27 ---
From PR38985:
These passes are able to propagate the address to the load: CCP, VRP, DOM.
If
we decide that it's an invalid transformation, fixing them would fix this bug.
The interesting part is that after you
--- Comment #7 from bonzini at gnu dot org 2009-01-27 12:29 ---
simply not CCP constant addresses into dereferences.
Apart from the fact that it's not only CCP, it seems mostly sensible.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38985
--- Comment #9 from rguenther at suse dot de 2009-01-27 12:29 ---
Subject: Re: [4.2/4.3/4.4 Regression] NULL
pointers always considered distinct by PTA, even with
-fno-delete-null-pointer-checks
On Tue, 27 Jan 2009, bonzini at gnu dot org wrote:
--- Comment #8 from bonzini at
--- Comment #8 from rguenth at gcc dot gnu dot org 2009-01-27 12:31 ---
Created an attachment (id=17190)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17190action=view)
incomplete patch
I tried this quick hack to add proper operands for the dereference, but it
shows
that (of
--- Comment #14 from bonzini at gnu dot org 2009-01-27 12:32 ---
Yes, for the record those were my thoughts too when I prepared the --std=c99
testcase.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38934
--- Comment #9 from rguenth at gcc dot gnu dot org 2009-01-27 12:33 ---
As this bug exists basically forever (since tree-ssa merge) I am inclined to
only fix it for 4.5 with the alias-improvements branch merge.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38985
--- Comment #9 from dorit at gcc dot gnu dot org 2009-01-27 12:40 ---
(In reply to comment #4)
The testcase should be
subroutine to_product_of(self,a,b,a1,a2)
complex(kind=8) :: self (:)
complex(kind=8), intent(in) :: a(:,:)
complex(kind=8), intent(in) :: b(:)
integer
--- Comment #7 from dorit at gcc dot gnu dot org 2009-01-27 12:46 ---
related testcase/PR: PR37021
and related discussion: http://gcc.gnu.org/ml/gcc-patches/2009-01/msg01322.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33113
--- Comment #4 from eric dot weddington at atmel dot com 2009-01-27 12:52
---
Closing bug. No feedback from the OP for almost a year.
--
eric dot weddington at atmel dot com changed:
What|Removed |Added
--- Comment #10 from bonzini at gnu dot org 2009-01-27 12:58 ---
Created an attachment (id=17191)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17191action=view)
tentative patch
Do you want to pursue something as in the attached patch instead? You can then
revert it in the
--- Comment #11 from rguenth at gcc dot gnu dot org 2009-01-27 13:05
---
The patch is not enough. Consider replacements in loads and in loads of
call arguments to const/pure calls.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38985
--- Comment #12 from bonzini at gnu dot org 2009-01-27 13:18 ---
Ok, I'm not working on it anyway. I'll just leave the patch in case someone
else would pick it up.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38985
--- Comment #15 from joseph at codesourcery dot com 2009-01-27 13:33
---
Subject: Re: [4.3/4.4 Regression] ICE in set_value_range,
at tree-vrp.c:398
On Tue, 27 Jan 2009, jakub at gcc dot gnu dot org wrote:
I wonder if the libcpp warning is correct in this case for
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-01-27 13:36 ---
static inline int foo (unsigned _si1)
{
if (_si1 != 0)
if (_si1 2147483647)
return 1;
return 0;
}
static inline unsigned bar (unsigned _left, int _right)
{
return (unsigned) _right = 8 ? 1 : _left
--- Comment #4 from jkp at kirkconsulting dot co dot uk 2009-01-27 13:44
---
Hi there
I reported this bug too long ago to even remember the details. All I can say
is that now PPC OS X is probably completely irrelevant to most people. I
certainly won't be wasting any more time on it.
--- Comment #16 from bonzini at gnu dot org 2009-01-27 13:44 ---
It's very clear to me by now that HOST_WIDE_INT should only depend on the
target (probably only on the target architecture), not the host; that's
the only way to ensure consistency between hosts for the same target.
--- Comment #8 from kamaraju at gmail dot com 2009-01-27 13:51 ---
I would like to confirm that, even after recompiling gcc with bison, I am still
getting the internal compiler error. There is no yacc, no /usr/ccs/bin in $PATH
when gcc was compiled.
--
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-01-27 14:34 ---
We try to insert {nop_expr,g_2.7_58} in bb 41
bb 18:
# g_67_22 = PHI g_67_63(39), g_67_44(D)(24)
# g_2.7_58 = PHI g_2.11_10(39), g_2.7_1(24)
# g_2_59 = PHI g_2_48(39), g_2_43(D)(24)
# VUSE g_162_45(D)
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-01-27 14:38 ---
Happens here:
/* If the PHI node is already available, use it. */
if ((res = vn_phi_lookup (phi)) != NULL_TREE)
{
gimple_stmt_iterator gsi = gsi_for_stmt (phi);
remove_phi_node (gsi, true);
--- Comment #17 from joseph at codesourcery dot com 2009-01-27 14:55
---
Subject: Re: [4.3/4.4 Regression] ICE in set_value_range,
at tree-vrp.c:398
On Tue, 27 Jan 2009, bonzini at gnu dot org wrote:
It's very clear to me by now that HOST_WIDE_INT should only depend on the
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-01-27 15:08 ---
So we are about to insert a duplicate PHI node but for a different value
number.
I can trivially avoid the ICE, but I wonder if that (missed optimization?) is
bad or not ...
Patch in testing.
--
--- Comment #2 from rob1weld at aol dot com 2009-01-27 15:13 ---
Same issue on Fedora 10
# ../gcc_build/gcc/xgcc -v
Using built-in specs.
Target: i386-redhat-linux
Configured with: ../gcc_trunk/configure
--enable-languages=c,c++,fortran,java,objc,obj-c++ --enable-shared
--- Comment #18 from jakub at gcc dot gnu dot org 2009-01-27 15:14 ---
The problem on ix86 is I believe that on such a register starved host, using
long long in many places will mean very noticeable performance degradation.
In any case, I'd prefer to change tree-vrp.c at this point (am
--- Comment #1 from rob1weld at aol dot com 2009-01-27 15:18 ---
Running trunk revision 143680 on Fedora 10 I get:
# ../gcc_build/gcc/xgcc -v
Using built-in specs.
Target: i386-redhat-linux
Configured with: ../gcc_trunk/configure
--enable-languages=c,c++,fortran,java,objc,obj-c++
--- Comment #19 from bonzini at gnu dot org 2009-01-27 15:21 ---
The problem on ix86 is I believe that on such a register starved host, using
long long in many places will mean very noticeable performance degradation.
Probably noticeable; however, Debian and Apple are already
--- Comment #3 from rob1weld at aol dot com 2009-01-27 15:38 ---
(In reply to comment #2)
It's not a bug that GCC EXEC_PREFIX is defined when the testsuite is run, as
explained in these patches:
http://gcc.gnu.org/ml/gcc-patches/2006-10/msg00708.html
--- Comment #4 from hjl dot tools at gmail dot com 2009-01-27 15:47 ---
Reopen ...
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #5 from hjl dot tools at gmail dot com 2009-01-27 15:48 ---
*** This bug has been marked as a duplicate of 36443 ***
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #32 from hjl dot tools at gmail dot com 2009-01-27 15:48
---
*** Bug 38820 has been marked as a duplicate of this bug. ***
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #6 from rob1weld at aol dot com 2009-01-27 15:50 ---
Here is a newer result on Fedora 10:
=== gfortran tests ===
Running target unix
=== gfortran Summary ===
# of expected passes29107
# of expected failures 14
# of
--- Comment #33 from hjl dot tools at gmail dot com 2009-01-27 15:54
---
I think it is a very bad idea to set GCC_EXEC_PREFIX for make check.
If some people want binary tools, which aren't the part of installed gcc,
in the GCC_EXEC_PREFIX directory when running make check, they
should
--- Comment #7 from rob1weld at aol dot com 2009-01-27 16:00 ---
(In reply to comment #5)
! Test XFAILed on these platforms because the system's printf() lacks
! proper support for denormalized long doubles. See PR24685
Looks like this testcase should be xfailed on solaris also.
--- Comment #5 from bangerth at gmail dot com 2009-01-27 16:00 ---
Richard,
this isn't a duplicate of PR 38851: while the testcase there indeed now
passes, the one in the current PR still fails.
Best
Wolfgang
--
bangerth at gmail dot com changed:
What|Removed
--
bangerth at gmail dot com changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38908
--- Comment #34 from hjl dot tools at gmail dot com 2009-01-27 16:06
---
If I have an old gcc 4.4 installed on my machine, will setting
GCC_EXEC_PREFIX use the old installed gcc 4.4 for make check?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36443
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-01-27 16:11 ---
Well, it is a duplicate really, just this testcase involves one more case:
# VUSE D.2044_1(D)
# retval_3 = VDEF retval_2(D)
__comp_ctor (retval, D.2044);
where the uninitialized aggregate use appears as a
--- Comment #8 from rob1weld at aol dot com 2009-01-27 16:18 ---
(In reply to comment #4)
(In reply to comment #3)
This is not so much an error in Fortran than it is an error in the
scripting and it's ability to add it's own LD_LIBRARY_PATH components.
No. The current linking
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38984
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-01-27 16:25 ---
Mine.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from rob1weld at aol dot com 2009-01-27 16:26 ---
(In reply to comment #1)
With that dropped in gcc seems to build and test correctly. It _might_ be
that gcc builds Faster and uses Less memory during the two peaks in libjava
after this patch, more testing required.
When a header(A) is precompiled and included from another header(B), compiling
a source file using B results in invalid assembly. The message from the
assembler is file number X already allocated.
--
Summary: Including a precompiled header from another header
--- Comment #1 from frank dot richter at gmail dot com 2009-01-27 16:28
---
Created an attachment (id=17192)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17192action=view)
Test case for precompiled header inclusion
This test case is a simple scenario where a precompiled header
--- Comment #1 from rob1weld at aol dot com 2009-01-27 16:30 ---
On Fedora 10 (i386-redhat-linux) trunk revision 143680 using:
# iconv --version
iconv (GNU libc) 2.9
# iconv -l | grep IBM1047
IBM1047//
Rob
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38910
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-01-27 16:33 ---
Created an attachment (id=17193)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17193action=view)
example patch
I just found this, I tried to fix this in fold but in the end agreed with
Andrew
that the C++ FE
--- Comment #4 from hjl dot tools at gmail dot com 2009-01-27 16:50 ---
(In reply to comment #0)
This is split off from PR38474 for clarity. Compiling the testcase of that PR
(http://gcc.gnu.org/bugzilla/attachment.cgi?id=16873)
as
gfortran -ffree-line-length-512 -g
--- Comment #1 from rob1weld at aol dot com 2009-01-27 17:00 ---
Trunk revision 143680 works on Fedora 10:
# gcc/xgcc -v
Using built-in specs.
Target: i386-redhat-linux
Configured with: ../gcc_trunk/configure
--enable-languages=c,c++,fortran,java,objc,obj-c++ --enable-shared
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-01-27 17:01 ---
Hm, unfortunately simply disabling that error doesn't fix my bash build.
Instead we now error on
jobs.c:4121: error: corrupted profile info: number of executions for edge 10-11
thought to be -1726
jobs.c:4121:
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-01-27 17:14 ---
CXX=g++-4.3 ./cause-error.sh
In file included from built-in:0:
built-in:0: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See
If you compile the following code (cut down from crtstuff.c) with
-mcmodel=large -fPIC -O2 on a 64 bit x86 target GCC will ICE. There are at
least two problems, one in cselib_hash_rtx, and if that is fixed then I get a
shared rtx abort.
The test case is
typedef long unsigned int
--- Comment #3 from frank dot richter at gmail dot com 2009-01-27 17:18
---
No ICE here (gcc version 4.2.4 (Gentoo 4.2.4 p1.0)), but the underlying cause
might be the same.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38987
--- Comment #13 from bkoz at gcc dot gnu dot org 2009-01-27 17:26 ---
*** Bug 25956 has been marked as a duplicate of this bug. ***
--
bkoz at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from bkoz at gcc dot gnu dot org 2009-01-27 17:26 ---
Duplicate
*** This bug has been marked as a duplicate of 28017 ***
--
bkoz at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from hjl dot tools at gmail dot com 2009-01-27 17:46 ---
Do you have a testcase to show that -mcmodel=large doesn't work for
you?
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #2 from hjl dot tools at gmail dot com 2009-01-27 17:48 ---
By testcase, I meant a user application, not crtstuff.c, like
# gcc -mcmodel=large foo.c
# ./a.out
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38988
--- Comment #3 from sje at cup dot hp dot com 2009-01-27 17:54 ---
No, I don't have a user application. I believe the problem was that the user
was compiling a program with something like
-Wl,--section-start,.text=0x11000 and because the crt files weren't
compiled with
--- Comment #4 from paolo dot carlini at oracle dot com 2009-01-27 17:56
---
On it.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #4 from hjl dot tools at gmail dot com 2009-01-27 18:07 ---
Assuming you have solved crtstuff.c issue, will /usr/lib64/crt1.o
work with -Wl,--section-start,.text=0x11000? Can you try
the latest binutils from CVS with
[...@gnu-6 pr38988]$ cat f.c
#include stdio.h
int
--- Comment #7 from domob at gcc dot gnu dot org 2009-01-27 18:08 ---
Subject: Bug 38883
Author: domob
Date: Tue Jan 27 18:07:54 2009
New Revision: 143707
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143707
Log:
2009-01-27 Daniel Kraft d...@domob.eu
PR fortran/38883
--- Comment #8 from domob at gcc dot gnu dot org 2009-01-27 18:10 ---
Fixed on trunk.
--
domob at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from ethouris at gmail dot com 2009-01-27 18:33 ---
Created an attachment (id=17194)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17194action=view)
Preprocessed source that caused the problem
The problem is reported for line 40 in msigslot.h, where a 'friend'
--- Comment #8 from ethouris at gmail dot com 2009-01-27 18:35 ---
I added as attachment the code that causes the same error message.
Please note that this code was compiling and working correctly with the old
Doug Gregor's patch, which was the first version of 'variadic template'
--- Comment #3 from hjl dot tools at gmail dot com 2009-01-27 18:39 ---
Fixed as of revision 139039.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #35 from janis at gcc dot gnu dot org 2009-01-27 18:45 ---
In response to comment #34, the -B option overrides GCC_EXEC_PREFIX and the
compiler being tested in the build directory is invoked with -B.
GCC_EXEC_PREFIX will only be used to find files that are not in the build
--- Comment #4 from sje at gcc dot gnu dot org 2009-01-27 18:46 ---
Subject: Bug 38615
Author: sje
Date: Tue Jan 27 18:45:49 2009
New Revision: 143708
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143708
Log:
PR middle-end/38615
* gimplify.c
--- Comment #5 from sje at cup dot hp dot com 2009-01-27 18:48 ---
Fixed on trunk for 4.4.0 and on 4.3 branch for 4.3.4.
--
sje at cup dot hp dot com changed:
What|Removed |Added
--- Comment #1 from bkoz at gcc dot gnu dot org 2009-01-27 18:55 ---
http://gcc.gnu.org/ml/gcc/2009-01/msg00417.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38983
--- Comment #4 from joel at gcc dot gnu dot org 2009-01-27 19:04 ---
(In reply to comment #3)
Fixed as of revision 139039.
Disagree. http://gcc.gnu.org/ml/gcc-testresults/2009-01/msg02352.html is ACATS
for powerpc-rtems on psim. Test C974013 fails with exactly the same backtrace
as
RTEMS has fixed size task stacks. This test is blowing a stack that is ~100K
large. How large does it need to be? Is is a bug to use this much stack?
,.,. C380004 ACATS 2.5 88-01-01 00:00:00
C380004 Check evaluation of discriminant expressions when the
constraint depends
1 - 100 of 155 matches
Mail list logo
