On Mon, Sep 6, 2010 at 10:51 PM, Kai Ruottu kai.ruo...@wippies.com wrote:
This seems to be defined in a header generated during the build
into the $BUILD/gcc :
[r...@localhost gcc]# grep ggc_alloc_cleared_lang_type *.h
gtype-desc.h:#define ggc_alloc_cleared_lang_type_u() ((union lang_type_u
On 09/10/2010 03:12 PM, Manuel López-Ibáñez wrote:
On 10 September 2010 15:00, Steven Bosscherstevenb@gmail.com wrote:
On Fri, Sep 10, 2010 at 2:40 PM, Richard Kenner
ken...@vlsi1.ultra.nyu.edu wrote:
Some strong way of addressing the concern that this could be used to make
proprietary
On 13 September 2010 12:30, Paolo Bonzini bonz...@gnu.org wrote:
On 09/10/2010 03:12 PM, Manuel López-Ibáńez wrote:
On 10 September 2010 15:00, Steven Bosscherstevenb@gmail.com wrote:
On Fri, Sep 10, 2010 at 2:40 PM, Richard Kenner
ken...@vlsi1.ultra.nyu.edu wrote:
Some strong way of
13.9.2010 10:39, Dennis, CHENG Renquan kirjoitti:
So maybe the Gentoo distro has some problem...
No, I've tried compiling gcc-4.6-20100911 on ubuntu 10.04, the same
problem also happened;
and I also found that macro was defined in a generated header file, in
the gcc build directory;
renq...@flyer-1-1:~/src/gcc-4.6-build$ grep -RsInw
ggc_alloc_cleared_lang_type gcc/
gcc/gtype-desc.h:2451:#define ggc_alloc_cleared_lang_type() ((struct
lang_type *)(ggc_internal_cleared_alloc_stat (sizeof (struct
lang_type) MEM_STAT_INFO)))
this definition just doesn't accept any
From: Basile Starynkevitch bas...@starynkevitch.net
Subject: Re: How to parse a code snippet at front-end plugin
Date: Sun, 12 Sep 2010 08:35:48 +0200
On Sat, 11 Sep 2010 22:19:06 +0800 (CST)
Thinker K.F. Li thin...@codemud.net wrote:
Hi,
I am try to make a plugin to analyze GIMPLE before
On Mon, Sep 13, 2010 at 8:16 PM, Laurynas Biveinis
laurynas.bivei...@gmail.com wrote:
I am the author of how these macros are generated, but somehow I have
missed this thread initially. Could you send me off-list that
gtype-desc.h file?
The problematic gtype-desc.h has been sent to Laurynas
2010/9/13 Dennis, CHENG Renquan crq...@fedoraproject.org:
On Mon, Sep 13, 2010 at 8:16 PM, Laurynas Biveinis
laurynas.bivei...@gmail.com wrote:
I am the author of how these macros are generated, but somehow I have
missed this thread initially. Could you send me off-list that
gtype-desc.h
On Mon, Sep 13, 2010 at 9:32 PM, Laurynas Biveinis
laurynas.bivei...@gmail.com wrote:
Thanks. I assume that you pass --enable-languages=c to configure?
No, just a very simple configure and make command:
../path/to/gcc-4.6-build$ time { ../gcc-4.6-20100911/configure
--prefix=/usr --disable-nls
On Mon, Sep 13, 2010 at 01:44:57PM +0200, Manuel López-Ibáñez wrote:
On 13 September 2010 12:30, Paolo Bonzini bonz...@gnu.org wrote:
Hmm, my impression was that GCC can mostly gain from clang-gcc, and only
lose from llvm-gcc...
What will be gained and what will be lost in your opinion?
On 13 September 2010 16:55, Jack Howarth howa...@bromo.med.uc.edu wrote:
On Mon, Sep 13, 2010 at 01:44:57PM +0200, Manuel López-Ibáñez wrote:
On 13 September 2010 12:30, Paolo Bonzini bonz...@gnu.org wrote:
Hmm, my impression was that GCC can mostly gain from clang-gcc, and only
lose from
Hello,
I am experimenting some cond_exec patterns to better support
predicate in our target. I came across the following optimization
done in cse1, and not sure if it is correct behaviour or my fault.
Basically, cse1 performs copy propagation for insn 12 and 16 based
on assignment in insn 10.
Manuel López-Ibáñez lopeziba...@gmail.com writes:
From a user-perspective, there are benefits on both clang-gcc and
gcc-llvm. However, from what I know about the GCC project, I don't
see yet how GCC developers can consider either more beneficial than
the other.
It seems to me that at the
Bingfeng Mei b...@broadcom.com writes:
I am experimenting some cond_exec patterns to better support
predicate in our target. I came across the following optimization
done in cse1, and not sure if it is correct behaviour or my fault.
Basically, cse1 performs copy propagation for insn 12 and 16
On 9/13/10 2:04 PM, Ian Lance Taylor wrote:
Therefore, I see a clear benefit to clang-gcc, but I
do not see a clear benefit to gcc-llvm.
Suppose you have large Fortran applications, and want to accelerate
parts of them on graphics processors.
Several of the OpenCL implementations use LLVM for
On Mon, Sep 13, 2010 at 10:15 PM, Ian Lance Taylor i...@google.com wrote:
Bingfeng Mei b...@broadcom.com writes:
I am experimenting some cond_exec patterns to better support
predicate in our target. I came across the following optimization
done in cse1, and not sure if it is correct behaviour
On 13 September 2010 22:04, Ian Lance Taylor i...@google.com wrote:
Manuel López-Ibáñez lopeziba...@gmail.com writes:
From a user-perspective, there are benefits on both clang-gcc and
gcc-llvm. However, from what I know about the GCC project, I don't
see yet how GCC developers can consider
Manuel López-Ibáñez lopeziba...@gmail.com writes:
On 13 September 2010 22:04, Ian Lance Taylor i...@google.com wrote:
Manuel López-Ibáñez lopeziba...@gmail.com writes:
From a user-perspective, there are benefits on both clang-gcc and
gcc-llvm. However, from what I know about the GCC project,
On Mon, Sep 13, 2010 at 11:32 PM, Manuel López-Ibáñez
lopeziba...@gmail.com wrote:
I think you are again talking about user benefits. You don't see a
(user) benefit in gcc-llvm because you perhaps do not use the
features that LLVM has and GCC doesn't. But users of gcc-llvm surely
see a large
On 13 September 2010 23:41, Ian Lance Taylor i...@google.com wrote:
Manuel López-Ibáñez lopeziba...@gmail.com writes:
On 13 September 2010 22:04, Ian Lance Taylor i...@google.com wrote:
Manuel López-Ibáñez lopeziba...@gmail.com writes:
From a user-perspective, there are benefits on both
On Tue, Sep 14, 2010 at 12:05 AM, Manuel López-Ibáñez
lopeziba...@gmail.com wrote:
I understand the benefit that existed before clang. And my general
understanding is that clang C++ support is not yet complete, so there is
a benefit there, but only a temporary one. I don't see a real benefit
Manuel López-Ibáñez lopeziba...@gmail.com writes:
By that rule, it is clearly beneficial for some gcc users to compile
Fortran using dragon-egg to take advantage of OpenCL. Ergo, dragon-egg
is beneficial to GCC.
That's pretty special purpose, though. Not something I would personally
On 14 September 2010 00:16, Steven Bosscher stevenb@gmail.com wrote:
On Tue, Sep 14, 2010 at 12:05 AM, Manuel López-Ibáñez
lopeziba...@gmail.com wrote:
I understand the benefit that existed before clang. And my general
understanding is that clang C++ support is not yet complete, so there
Manuel López-Ibáñez lopeziba...@gmail.com writes:
In the same sense that adding clang-gcc means that there is less
motivation for developers to improve the current C/C++ FEs.
From the perspective of gcc, I think the goal of clang-gcc would be to
replace the current frontends entirely.
Ian
On Tue, Sep 14, 2010 at 12:30 AM, Manuel López-Ibáñez
lopeziba...@gmail.com wrote:
On 14 September 2010 00:16, Steven Bosscher stevenb@gmail.com wrote:
On Tue, Sep 14, 2010 at 12:05 AM, Manuel López-Ibáñez
lopeziba...@gmail.com wrote:
I understand the benefit that existed before clang.
--- Comment #14 from ubizjak at gmail dot com 2010-09-13 07:08 ---
(In reply to comment #13)
The patch in comment #3 broke the (previously passing) test for all ix86
targets. It seems strange to try and remedy that by disabling the test for
nonpic targets (as the change at r163685
--- Comment #29 from dominiq at lps dot ens dot fr 2010-09-13 09:09 ---
But it can still be updated and committed before the end of stage 1. :-)
I hope so!-) I also think this pr is related to pr43829.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43829
--- Comment #4 from jakub at gcc dot gnu dot org 2010-09-13 09:17 ---
Created an attachment (id=21783)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21783action=view)
gcc46-pr45567.patch
Untested fix.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45567
--- Comment #8 from rguenth at gcc dot gnu dot org 2010-09-13 09:35 ---
I have a patch.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from jakub at gcc dot gnu dot org 2010-09-13 10:18 ---
I believe just gfc_conv_intrinsic_arith needs to be adjusted so that it also
handles se-ss case, at least for optimize !optimize_size. Currently it
just handles the case where those intrinsics return a scalar.
--
--- Comment #9 from rguenth at gcc dot gnu dot org 2010-09-13 10:47 ---
Subject: Bug 45611
Author: rguenth
Date: Mon Sep 13 10:47:28 2010
New Revision: 164244
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=164244
Log:
2010-09-13 Richard Guenther rguent...@suse.de
PR
--- Comment #10 from rguenth at gcc dot gnu dot org 2010-09-13 10:48
---
Should be fixed now.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from ebotcazou at gcc dot gnu dot org 2010-09-13 10:55
---
Presumably re-fixed by Richard now. :-) Reopen if not.
*** This bug has been marked as a duplicate of 45611 ***
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed
--- Comment #11 from ebotcazou at gcc dot gnu dot org 2010-09-13 10:55
---
*** Bug 45421 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45611
--- Comment #5 from ibolton at gcc dot gnu dot org 2010-09-13 11:04 ---
Reporter needs to try again with different configure options. (We may still
want a more user-friendly way of catching the original problem though.)
--
ibolton at gcc dot gnu dot org changed:
What
--- Comment #6 from abnikant dot singh at atmel dot com 2010-09-13 11:38
---
we get better code in the head. Both the cases [test1 and test2] produce the
same piece of code:
i.e for the following test case:
void foo(char *p);
void test1(char * p)
{
foo(p++);
foo(p++);
--- Comment #12 from abnikant dot singh at atmel dot com 2010-09-13 12:09
---
I have verified the attached test case and test case with other comments and
found the code generated is correct i.e. the variable is not promoted to
integer in gcc-4.3.3, gcc-4.4.3, gcc-4.5.0 and also the
Sorry if this is a dup.
Is there any reason why with -fwhole-file we don't warn about:
subroutine foo(ptr, ptr2, f)
integer, pointer :: ptr(:), ptr2(:)
logical :: f
if (f) then
allocate (ptr(6))
else
nullify(ptr)
end if
end subroutine
subroutine bar()
real, pointer :: ptr(:),
The GCC Wiki does not have the text colorizing macro installed (or else it
doesn't seem to work as it's supposed to). See
http://moinmo.in/MacroMarket/Color2 for more details on it.
--
Summary: GCC WIki Needs Text Colorizing Capability
Product: gcc
Version:
With revision r163997 this test passed.
From revision r163998 and on, including at least r164242 this test has failed
as follows:
Running /tmp/reg_a4_998/gcc/gcc/testsuite/gfortran.dg/dg.exp ...
... (non-regressions elided)
FAIL: gfortran.dg/forall_4.f90 -O3 -g execution test
With the message
--- Comment #1 from hp at gcc dot gnu dot org 2010-09-13 14:00 ---
Created an attachment (id=21784)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21784action=view)
shortened gfortran.dg/forall_4.f90
-O3 -g
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45656
--- Comment #2 from matz at gcc dot gnu dot org 2010-09-13 14:21 ---
Uh, I just disabled tree-sinking in some cases. This can't be directly
the reason for the problem, rather it must have uncovered a latent problem.
Will try to investigate.
--
--- Comment #3 from hp at gcc dot gnu dot org 2010-09-13 14:37 ---
(In reply to comment #1)
-O3 -g
I forgot to mention, also: -fno-delayed-branch (reorg is always the usual
suspect when latent bugs are exposed, but not so this time.)
I guess it's fair to include Alexandre what with
--- Comment #15 from davek at gcc dot gnu dot org 2010-09-13 14:41 ---
(In reply to comment #14)
Well, scans definitely pass on x86_64 AND i686 linux without -fpic.
Why it fails for the -fpic targets should be clear from the assembly dumps.
The fix you are referring to added
--- Comment #3 from jason at gcc dot gnu dot org 2010-09-13 14:57 ---
This isn't a bug. We produce a cast here because no field is generated for an
empty base class. From class.c:
/* We do not create a FIELD_DECL for empty base classes because it might
overlap some other field. We
--- Comment #9 from paolo dot carlini at oracle dot com 2010-09-13 15:22
---
What's going on with this? Is there something I can do to help resolving it for
good?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42033
This code is invalid, but is accepted by GCC:
// snip
struct Viral {
struct Dose { };
protected:
~Viral() throw (Dose) { }
};
struct Base : virtual Viral {
virtual ~Base() throw() { }
};
struct Derived : Base { };
// snap
~Derived calls ~Viral, which adds Dose to its exception spec. This
--- Comment #9 from jakub at gcc dot gnu dot org 2010-09-13 15:36 ---
Created an attachment (id=21785)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21785action=view)
gcc46-pr45596.patch
Updated patch. This one should handle the case where pointer assigment just
points into some
Even with PR bootstrap/45611 fixed, I get a comparison failure on
sparc-sun-solaris2.10:
Comparing stages 2 and 3
Bootstrap comparison failure!
gcc/ada/ali.o differs
make[2]: *** [compare] Error 1
Comparing the stage 2 and 3 assembler output, I find:
--- prev-gcc/ali.s 2010-09-13
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45658
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45354
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45363
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45566
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-09-13 15:53 ---
Looks kindof obvious.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45569
Not quite sure if this CP2K derived testcase is really a bug, but for the
testcase below, I get the following warning and later an error (this might be
different issues?) :
gfortran -flto test_c.c test.f90
test_c.c:3:8: warning: type of build_eri does not match original declaration
[enabled by
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45593
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45606
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45650
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45651
--- Comment #2 from paolo dot carlini at oracle dot com 2010-09-13 16:01
---
Seems a rather annoying regression, let's ask H.J. a binary search...
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-09-13 16:12 ---
It works for me. I suppose you have older gold with known bugs? I have
GNU gold (GNU Binutils; SUSE:openSUSE 11.1 2.20.51.20091013-0.1) 1.9
Copyright 2008 Free Software Foundation, Inc.
This program is free
--- Comment #2 from ro at gcc dot gnu dot org 2010-09-13 16:43 ---
Same on *-*-solaris2* (probably on all non-Linux targets).
--
ro at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from amonakov at gcc dot gnu dot org 2010-09-13 16:53
---
Confirmed. Not related to PR43949 since selective scheduling does not use
cselib. The miscompilation seems to come from RTL aliasing: sel-sched lifts a
load that references stack via a general-purpose register
--- Comment #1 from redi at gcc dot gnu dot org 2010-09-13 16:55 ---
Not a regression, and G++ 4.6 correctly rejects it:
pr.cc:12:8: error: looser throw specifier for 'virtual Derived::~Derived()
throw (Viral::Dose)'
pr.cc:9:11: error: overriding 'virtual Base::~Base() throw ()'
EDG
--- Comment #2 from schaub-johannes at web dot de 2010-09-13 17:02 ---
Great(In reply to comment #1)
Not a regression, and G++ 4.6 correctly rejects it:
pr.cc:12:8: error: looser throw specifier for 'virtual Derived::~Derived()
throw (Viral::Dose)'
pr.cc:9:11: error: overriding
--- Comment #3 from redi at gcc dot gnu dot org 2010-09-13 17:04 ---
the test already includes cassert so presumably the fix is simply to replace
line 77 with
T const* operator-() const { assert(this-is_initialized()) ; return
this-get_ptr_impl() ; }
--
--- Comment #3 from redi at gcc dot gnu dot org 2010-09-13 17:06 ---
Jason, do you know if this was fixed as part of your noexcept work, or is it
still latent in trunk?
--
redi at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #30 from mikael at gcc dot gnu dot org 2010-09-13 17:09 ---
(In reply to comment #29)
I also think this pr is related to pr43829.
It couldn't be more ;-)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43829
--- Comment #4 from paolo dot carlini at oracle dot com 2010-09-13 17:12
---
I agree with Jon: the expansion of assert to __assert_fail, etc, isn't
portable, the testcase should simply use assert.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45645
--- Comment #2 from Joost dot VandeVondele at pci dot uzh dot ch
2010-09-13 17:13 ---
(In reply to comment #1)
It works for me. I suppose you have older gold with known bugs? I have
GNU gold (GNU Binutils; SUSE:openSUSE 11.1 2.20.51.20091013-0.1) 1.9
my date is more recent
--- Comment #7 from mikael at gcc dot gnu dot org 2010-09-13 17:14 ---
(In reply to comment #4)
(see pr43829)
I think it is a duplicate of (or close to) pr43829.
Marked as depending on it so that I don't forget it.
--
mikael at gcc dot gnu dot org changed:
What
--- Comment #22 from belyshev at depni dot sinp dot msu dot ru 2010-09-13
17:54 ---
Fixed everywhere but on 4.3 branch.
Maybe commit the patch there too?
--
belyshev at depni dot sinp dot msu dot ru changed:
What|Removed |Added
// { dg-do compile }
// { dg-options -g -fno-inline }
void
test ()
{
struct S
{
typedef void (**T) (void);
static T i (void) { return 0; }
};
S s;
if (s.i ())
*s.i () = 0;
}
ICEs with
rh632847.C:15:1: internal compiler error: in dwarf2out_finish, at
dwarf2out.c:22387
Please
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-09-13 17:58 ---
void (*build_eri)();
In C means something different from:
void (*build_eri)(void);
Please try with the void.
--- CUT --
void (*build_eri)();
In C means that the build_eri takes a variable arguments.
--
--- Comment #1 from jakub at gcc dot gnu dot org 2010-09-13 18:28 ---
Created an attachment (id=21786)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21786action=view)
gcc46-pr45660.patch
Untested fix.
--
jakub at gcc dot gnu dot org changed:
What|Removed
--- Comment #4 from jason at gcc dot gnu dot org 2010-09-13 18:35 ---
I'm sure this was fixed by my work on implicitly deleted functions, which
involved rewriting the calculation of exception specifications for implicitly
declared functions.
--
jason at gcc dot gnu dot org changed:
i...@linux-fd1f:/tmp cat tst.f90
subroutine foo(a,c,d,n)
real, dimension(n),intent(in) :: a
real, dimension(n),intent(out) :: c,d
c = sin(a)
d = cos(a)
end subroutine foo
i...@linux-fd1f:/tmp gfortran -O3 -S tst.f90
i...@linux-fd1f:/tmp grep sin tst.s
callsinf
--- Comment #8 from jakub at gcc dot gnu dot org 2010-09-13 18:50 ---
So, are you goint to take care of this?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36841
--- Comment #3 from hjl dot tools at gmail dot com 2010-09-13 18:53 ---
It is caused by revision 115086:
http://gcc.gnu.org/ml/gcc-cvs/2006-06/msg00805.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45651
--- Comment #6 from tkoenig at gcc dot gnu dot org 2010-09-13 18:53 ---
Sounds like something for front end optimization.
Should we maybe generate the BLAS calls directly, instead of jumping
through the library functions?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29550
--- Comment #2 from tkoenig at gcc dot gnu dot org 2010-09-13 18:59 ---
This doesn't seem to happen any more.
Can we close this?
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from jakub at gcc dot gnu dot org 2010-09-13 19:04 ---
Perhaps a testcase should be added (either with -Warray-temporaries or scanning
dumps) to make sure we don't regress here?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42831
--- Comment #5 from howarth at nitro dot med dot uc dot edu 2010-09-13
19:13 ---
I can confirm that the change...
Index: gcc/testsuite/g++.dg/torture/pr44972.C
===
--- gcc/testsuite/g++.dg/torture/pr44972.C (revision
On Linux/x86, revision 164250:
http://gcc.gnu.org/ml/gcc-cvs/2010-09/msg00544.html
caused
FAIL: gcc.target/i386/funcspec-1.c scan-assembler addps[ \t]
FAIL: gcc.target/i386/funcspec-1.c scan-assembler fsubs[ \t]
FAIL: gfortran.dg/vect/fast-math-pr38968.f90 scan-tree-dump vect vectorized 1
loops
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Target Milestone|--- |4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45662
On Linux/x86, revision 164252:
http://gcc.gnu.org/ml/gcc-cvs/2010-09/msg00546.html
caused:
FAIL: gcc.dg/guality/sra-1.c -O2 line 42 a.j == 14
FAIL: gcc.dg/guality/sra-1.c -O2 -flto line 42 a.j == 14
FAIL: gcc.dg/guality/sra-1.c -O2 -fwhopr line 42 a.j == 14
FAIL: gcc.dg/guality/sra-1.c
--
Summary: All ifunc tests fail on Solaris 2
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: testsuite
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy:
--- Comment #1 from ro at gcc dot gnu dot org 2010-09-13 20:18 ---
All the new ifunc tests fail on Solaris 2 (at least Solaris 10/x86):
FAIL: g++.dg/ext/attr-ifunc-1.C execution test
FAIL: g++.dg/ext/attr-ifunc-2.C execution test
FAIL: g++.dg/ext/attr-ifunc-3.C execution test
FAIL:
--- Comment #2 from jakub at gcc dot gnu dot org 2010-09-13 21:00 ---
Subject: Bug 45617
Author: jakub
Date: Mon Sep 13 21:00:03 2010
New Revision: 164257
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=164257
Log:
PR rtl-optimization/45617
* combine.c
--- Comment #6 from paolo dot carlini at oracle dot com 2010-09-13 21:01
---
Please properly post the patch to the mailing list and let's resolve this
rather straightforward issue. Thanks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45645
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2010-09-13 21:08
---
Subject: Bug 43937
Author: ebotcazou
Date: Mon Sep 13 21:08:13 2010
New Revision: 164258
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=164258
Log:
PR debug/43937
* varasm.c
--- Comment #4 from ebotcazou at gcc dot gnu dot org 2010-09-13 21:10
---
At long last.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from jakub at gcc dot gnu dot org 2010-09-13 21:10 ---
Committed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from mikael at gcc dot gnu dot org 2010-09-13 21:35 ---
(In reply to comment #8)
So, are you goint to take care of this?
Sure.
--
mikael at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from jsm28 at gcc dot gnu dot org 2010-09-13 22:25 ---
Subject: Bug 44749
Author: jsm28
Date: Mon Sep 13 22:25:09 2010
New Revision: 164260
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=164260
Log:
PR target/44749
* config/mep/t-mep (GTM_H): Add
--- Comment #2 from jsm28 at gcc dot gnu dot org 2010-09-13 22:27 ---
Note that while my commit fixes two causes of build failure for this target,
a third cause of failure is still present. As I noted in my patch submission
http://gcc.gnu.org/ml/gcc-patches/2010-09/msg00664.html
*
--- Comment #7 from howarth at nitro dot med dot uc dot edu 2010-09-13
22:33 ---
Patch posted at http://gcc.gnu.org/ml/gcc-patches/2010-09/msg01144.html.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45645
Compiler output:
$ gcc testcase.C
testcase.C:2:11: error: type/value mismatch at argument 1 in template parameter
list for 'templateclass struct S'
testcase.C:2:11: error: expected a type, got '0'
testcase.C:2:21: internal compiler error: tree check: expected class 'type',
have 'exceptional'
../../gcc/xgcc -B../../gcc/ -isystem /mingw/include -c -I.
-I../../../gcc-trunk/include -DHAVE_CONFIG_H -g -O1 -Wwrite-strings
-Wc++-compat ../../../gcc-trunk/libiberty/make-temp-file.c -o make-temp-file.o
In file included from /mingw/include/windef.h:137:0,
from
1 - 100 of 105 matches
Mail list logo
