On 25/06/10 06:39, Richard Guenther wrote:
There are btw. some bugs wrt accounting of functions called once
being inlined in 4.5 which were fixed on trunk which allow extra
inlining.
Are these changes likely to make it onto the 4.5 branch and into (say)
4.5.1?
j.
Minus whitespace changes it seems to be
! if (lhs_free (is_gimple_reg (rhs) ||
is_gimple_min_invariant (rhs)))
rhs_free = true;
vs.
! if (lhs_free
!(is_gimple_reg (rhs)
! || !is_gimple_reg_type (TREE_TYPE (rhs))
!
On Fri, Jun 25, 2010 at 8:34 AM, Eric Botcazou ebotca...@adacore.com wrote:
Minus whitespace changes it seems to be
! if (lhs_free (is_gimple_reg (rhs) ||
is_gimple_min_invariant (rhs)))
rhs_free = true;
vs.
! if (lhs_free
!
On Fri, Jun 25, 2010 at 8:15 AM, Jonathan Adamczewski
jadam...@utas.edu.au wrote:
On 25/06/10 06:39, Richard Guenther wrote:
There are btw. some bugs wrt accounting of functions called once
being inlined in 4.5 which were fixed on trunk which allow extra
inlining.
Are these changes likely
I do think so.
Huh? What do your version and mine return for the following assignment?
void foo (int i)
{
struct S s;
s.a = i;
}
Which in the following example makes i = *p not likely eliminated
but makes j = *q likely eliminated.
void foo (int *p, struct X *q)
{
int i;
struct
On Fri, Jun 25, 2010 at 12:45 PM, Eric Botcazou ebotca...@adacore.com wrote:
I do think so.
Huh? What do your version and mine return for the following assignment?
void foo (int i)
{
struct S s;
s.a = i;
}
Which in the following example makes i = *p not likely eliminated
but makes j
On Fri, Jun 25, 2010 at 8:15 AM, Jonathan Adamczewski
jadam...@utas.edu.au wrote:
On 25/06/10 06:39, Richard Guenther wrote:
There are btw. some bugs wrt accounting of functions called once
being inlined in 4.5 which were fixed on trunk which allow extra
inlining.
Are these changes
On Thu, Jun 24, 2010 at 11:50:52AM -0700, Taras Glek wrote:
Just wanted to give a heads up on what might be the biggest
compiler-upgrade-related performance difference we've seen at Mozilla.
We switched gcc4.3 for gcc4.5 and our automated benchmarking
infrastructure reported 4-19%
On Fri, Jun 25, 2010 at 1:02 PM, Richard Guenther
richard.guent...@gmail.com wrote:
On Fri, Jun 25, 2010 at 12:45 PM, Eric Botcazou ebotca...@adacore.com wrote:
I do think so.
Huh? What do your version and mine return for the following assignment?
void foo (int i)
{
struct S s;
s.a =
Hi,
On Fri, 25 Jun 2010, Jan Hubicka wrote:
I would be also very interested to know how profile feedback works in this
case
(and why it does not work in previous releases).
Profiling multi-threading programs needs -fprofile-correction that appeared
only in 4.4 (but I have no idea whether
Hi,
everything was fine until this morning, now upon make-check in the v3
dir, during the final link for testsuite_shared.so, ld spills:
relocation R_X86_64_PC32 against symbol
`__gnu_cxx::__common_pool__gnu_cxx::__pool, true::_S_get_pool()' can
not be used when making a shared object; recompile
On Fri, Jun 25, 2010 at 06:10:56AM -0700, Jan Hubicka wrote:
When you compile with -Os, the inlining happens only when code size reduces.
Thus we pretty much care about the code size metrics only. I suspect the
problem here might be that normal C++ code needs some inlining to make
abstraction
Hi,
On Fri, 25 Jun 2010, Jan Hubicka wrote:
I would be also very interested to know how profile feedback works in this
case
(and why it does not work in previous releases).
Profiling multi-threading programs needs -fprofile-correction that appeared
only in 4.4 (but I have no idea
On 06/03/2010 05:24 AM, Uros Bizjak wrote:
; Current assemblers are broken and do not allow @GOTOFF in
; ought but a memory context.
Code, following this comment disables or special-cases
pic_symbolic_operands.
I'm investigating, which current assemblers are
Richard Henderson r...@redhat.com writes:
Note that this *is* a memory context. The problematic cases were
addl $...@gotoff, %eax
which needed to be written as
lea x...@gotoff(%eax), %eax
to satisfy the memory context requirement of the broken assemblers.
The Solaris 8/x86
On Fri, Jun 25, 2010 at 7:50 AM, Paolo Carlini paolo.carl...@oracle.com wrote:
Hi,
everything was fine until this morning, now upon make-check in the v3
dir, during the final link for testsuite_shared.so, ld spills:
relocation R_X86_64_PC32 against symbol
On 06/25/2010 11:09 AM, Rainer Orth wrote:
The Solaris 8/x86 assembler handles the first form just fine, with
output identical to gas 2.20.1.
Excellent.
r~
On Fri, Jun 25, 2010 at 11:38 AM, H.J. Lu hjl.to...@gmail.com wrote:
On Fri, Jun 25, 2010 at 7:50 AM, Paolo Carlini paolo.carl...@oracle.com
wrote:
Hi,
everything was fine until this morning, now upon make-check in the v3
dir, during the final link for testsuite_shared.so, ld spills:
On 06/25/2010 08:48 PM, H.J. Lu wrote:
I opened a bug:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44671
Thanks HJ. Luckily it's friday, but we have quite a bit of ongoing
activity in the library, I really hope that over the weekend the
offending commit is properly tweaked or otherwise
Hello,
Can anybody explain how the register allocation is handled in GCC? Is it
done together with the general register allocation? or GCC has a separate phase
to handle them separately?
Any pointer to the source code that I can take a look? Thanks
Peng
BLUE 3TOO blue_3...@hotmail.com writes:
Can anybody explain how the register allocation is handled in GCC?
Is it done together with the general register allocation? or GCC
has a separate phase to handle them separately?
There is no separate vector register allocator. All classes
Ian, thanks a lot for the help. Is there any document
about IRA (e.g. how the SIMD registers of a
specific architecture is exposed to the allocation
process)? or the only option is the read the code?
what is the best information source for a beginner on gcc?
Thanks again.
BLUE 3TOO blue_3...@hotmail.com writes:
Ian, thanks a lot for the help. Is there any document
about IRA (e.g. how the SIMD registers of a
specific architecture is exposed to the allocation
process)? or the only option is the read the code?
Vlad described IRA in a paper published in the
Hi,
On Fri, Jun 25, 2010 at 11:38:39AM -0700, H.J. Lu wrote:
On Fri, Jun 25, 2010 at 7:50 AM, Paolo Carlini paolo.carl...@oracle.com
wrote:
Hi,
everything was fine until this morning, now upon make-check in the v3
dir, during the final link for testsuite_shared.so, ld spills:
These previous patches don't seem to solve the problem:
here is another reduced case that still fails in resolve_equivalence
at a different place than before.
$ cat bug.f
CALL TRFWTM(JKT,XX,NX,Y,NIX,NORB2,1,TOL)
IF(DBUG.AND.NX.GT.0) THEN
EQUIVALENCE (DBUGME, DBUGME_STR)
--- Comment #6 from sebpop at gmail dot com 2010-06-25 06:07 ---
Subject: Re: [regression 4.4/4.5/4.6] ICE in
resolve_equivalence()
These previous patches don't seem to solve the problem:
here is another reduced case that still fails in resolve_equivalence
at a different
--- Comment #7 from kargl at gcc dot gnu dot org 2010-06-25 06:14 ---
(In reply to comment #5)
Subject: Re: [regression 4.4/4.5/4.6] ICE in
resolve_equivalence()
On Thu, Jun 24, 2010 at 23:02, kargl at gcc dot gnu dot org
gcc-bugzi...@gcc.gnu.org wrote:
Comment #1
--- Comment #8 from burnus at gcc dot gnu dot org 2010-06-25 06:20 ---
Comment 6 prints correctly the error that EQUIVALENCE is unexpected, but then
segfaults. Valgrind shows:
==11477== Invalid read of size 8
==11477==at 0x52B7BB: resolve_types (resolve.c:12544)
==11477==by
--- Comment #9 from sebpop at gmail dot com 2010-06-25 06:24 ---
Subject: Re: [regression 4.4/4.5/4.6] ICE in
resolve_equivalence()
On Fri, Jun 25, 2010 at 01:14, kargl at gcc dot gnu dot org
gcc-bugzi...@gcc.gnu.org wrote:
... there is a 200 line difference in the location
--- Comment #10 from kargl at gcc dot gnu dot org 2010-06-25 06:29 ---
(In reply to comment #6)
Subject: Re: [regression 4.4/4.5/4.6] ICE in
resolve_equivalence()
These previous patches don't seem to solve the problem:
here is another reduced case that still fails in
--- Comment #2 from pzhao at gcc dot gnu dot org 2010-06-25 07:32 ---
Subject: Bug 44517
Author: pzhao
Date: Fri Jun 25 07:31:49 2010
New Revision: 161363
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161363
Log:
gcc/
2010-06-25 Shujing Zhao pearly.z...@oracle.com
PR
--- Comment #15 from jakub at gcc dot gnu dot org 2010-06-25 08:13 ---
Created an attachment (id=21000)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21000action=view)
gcc46-pr43866.patch
Here is a complete fix.
This includes what the earlier two patches did, plus for nested
--- Comment #13 from bernds at gcc dot gnu dot org 2010-06-25 08:56 ---
Subject: Bug 43902
Author: bernds
Date: Fri Jun 25 08:56:24 2010
New Revision: 161366
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161366
Log:
With large parts from Jim Wilson:
PR
--- Comment #3 from borntraeger at de dot ibm dot com 2010-06-25 09:02
---
Created an attachment (id=21001)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21001action=view)
Potential fix for compile time regression
Here is a potential fix. We just limit prefetching to loops with a
--- Comment #16 from rakdver at gcc dot gnu dot org 2010-06-25 09:04
---
Now, in the first loop if we decide to unswitch on cond3, it transforms this
into:
...
If cond3 tests some variable that is initialized only if cond1 is false, this
unswitching (besides not being very useful
--- Comment #17 from rakdver at gcc dot gnu dot org 2010-06-25 09:12
---
(In reply to comment #16)
Now, in the first loop if we decide to unswitch on cond3, it transforms this
into:
...
If cond3 tests some variable that is initialized only if cond1 is false,
this
--- Comment #18 from jakub at gcc dot gnu dot org 2010-06-25 09:14 ---
That part comes from the questionable testcase, which does
a_sp = matrix%local_data_sp
before the loop unconditionally, eventhough matrix%local_data_sp is
uninitialized unless use_sp is .true.
Without the unswitching
I think this was not reported yet, and both refer to the same problem.
--
Summary: unitialized memory on testcases abstract_type_6.f03 and
typebound_call_4.f03
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity:
--- Comment #11 from burnus at gcc dot gnu dot org 2010-06-25 09:17 ---
(In reply to comment #10)
What language is GAMESS written in?
Fortran, of course. See: http://www.spec.org/cpu2006/Docs/416.gamess.html
and http://www.msg.ameslab.gov/GAMESS/GAMESS.html
The above simply is not
--- Comment #19 from jakub at gcc dot gnu dot org 2010-06-25 09:19 ---
The compiler doesn't know that matrix%local_data_sp is uninitialized (at least
unless it would propagate that info in some IPA pass), matrix%local_data_sp is
a field in what an arguments points at (and the argument
--- Comment #12 from mikael at gcc dot gnu dot org 2010-06-25 09:27 ---
(In reply to comment #11)
However, regressions are now on transpose :
- alloc_comp_transformational_1.f90 : double free on function exit. I will
have to investigate.
Fixed
- char_length_8.f90 : reshape
--- Comment #20 from jv244 at cam dot ac dot uk 2010-06-25 09:28 ---
(In reply to comment #18)
That part comes from the questionable testcase, which does
a_sp = matrix%local_data_sp
before the loop unconditionally, eventhough matrix%local_data_sp is
uninitialized unless use_sp is
--- Comment #13 from mikael at gcc dot gnu dot org 2010-06-25 09:34 ---
Created an attachment (id=21002)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21002action=view)
Updated patch
As I was having memory corruption regressions, I started to run valgrind on
some testcases, whose
--- Comment #14 from mikael at gcc dot gnu dot org 2010-06-25 09:36 ---
TODO:
* testcases to check anything that might be impacted by the patch
* split the patch for review commit
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43829
--- Comment #21 from jakub at gcc dot gnu dot org 2010-06-25 09:38 ---
True. Most of the fields of the pointer are still uninitialized (NULLIFY only
clears the data field).
I'm afraid when NULLIFY doesn't clear the whole struct there will be always a
possibility valgrind might
--- Comment #15 from mikael at gcc dot gnu dot org 2010-06-25 09:42 ---
Isn't there a problem with the size of the patch ?
pr43829_3.diff 46.78 KB
I get here:
% du -h pr43829_3.diff
240Kpr43829_3.diff
%
At least it is not truncated (I have just checked).
--
--- Comment #1 from mikael at gcc dot gnu dot org 2010-06-25 09:45 ---
It is fixed by the patch at:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43829#c13
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44662
--- Comment #16 from rguenther at suse dot de 2010-06-25 09:45 ---
Subject: Re: Scalarization of reductions
On Fri, 25 Jun 2010, mikael at gcc dot gnu dot org wrote:
--- Comment #15 from mikael at gcc dot gnu dot org 2010-06-25 09:42
---
Isn't there a problem with the
--- Comment #12 from mikael at gcc dot gnu dot org 2010-06-25 10:32 ---
(In reply to comment #11)
Thus, seemingly, reject_statement leaves the symtree in a half-existing state.
It calls: gfc_undo_symbols () and undo_new_statement (). I think the former
one only does a partial
--- Comment #13 from mikael at gcc dot gnu dot org 2010-06-25 10:33 ---
Created an attachment (id=21003)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21003action=view)
patch against my (diry) tree
patch restoring the old equivalence list on reject_statement ()
--
--- Comment #10 from rguenth at gcc dot gnu dot org 2010-06-25 10:35
---
Subject: Bug 44555
Author: rguenth
Date: Fri Jun 25 10:35:40 2010
New Revision: 161370
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161370
Log:
2010-06-25 Richard Guenther rguent...@suse.de
hi,
the latest llvm/clang++ reports an error during parsing tr1/tuple
included from tr1/functional:
In file included from t00.cpp:1:
In file included from /usr/include/c++/4.5.0/tr1/functional:39:
/usr/include/c++/4.5.0/tr1/tuple:68:30: error: variadic templates are only
allowed in C++0x
--- Comment #1 from redi at gcc dot gnu dot org 2010-06-25 11:08 ---
(In reply to comment #0)
the latest llvm/clang++ reports an error during parsing tr1/tuple
included from tr1/functional:
In file included from t00.cpp:1:
In file included from
--- Comment #3 from jakub at gcc dot gnu dot org 2010-06-25 11:26 ---
This goes wrong with -O2 -funroll-loops already during tree opts. In vrp2 we
have:
b[2][1]{lb: 1 sz: 1} = D.1599_148;
b[3][1]{lb: 1 sz: 1} = D.1599_154;
D.1635_152 = 2;
D.1636_151 = b[2][1]{lb: 1 sz: 1};
--- Comment #2 from mikael at gcc dot gnu dot org 2010-06-25 11:29 ---
(In reply to comment #1)
It is fixed by the patch at:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43829#c13
relevant hunk:
diff --git a/decl.c b/decl.c
index aa7a266..840c32c 100644
--- a/decl.c
+++ b/decl.c
@@
--- Comment #3 from paolo dot carlini at oracle dot com 2010-06-25 11:49
---
Fixed.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #2 from redi at gcc dot gnu dot org 2010-06-25 11:55 ---
http://gcc.gnu.org/onlinedocs/libstdc++/faq.html#faq.other_compilers
If the guards were there as you suggest, tr1::tuple would only be usable in
C++0x mode, where it's redundant because you have std::tuple anyway.
--- Comment #3 from paolo dot carlini at oracle dot com 2010-06-25 11:59
---
Totally agree.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44663
--- Comment #6 from jakub at gcc dot gnu dot org 2010-06-25 12:07 ---
Subject: Bug 44539
Author: jakub
Date: Fri Jun 25 12:07:00 2010
New Revision: 161374
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161374
Log:
PR tree-optimization/44539
* tree-cfgcleanup.c
--- Comment #22 from jakub at gcc dot gnu dot org 2010-06-25 12:11 ---
Subject: Bug 43866
Author: jakub
Date: Fri Jun 25 12:10:42 2010
New Revision: 161375
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161375
Log:
PR middle-end/43866
* tree-ssa-loop-unswitch.c
Unaware of any current (GDB) problems from it.
echo 'class C { public: C () {} }; int main() { C c; }' | g++ -Wall -g -x c++ -
FAIL g++ (GCC) 4.4.5 20100625 (prerelease)
FAIL g++ (GCC) 4.5.1 20100625 (prerelease)
FAIL g++ (GCC) 4.6.0 20100625 (experimental) [under the test below]
Compilation
in gcc-4.5 and trunk:
gimplify.c:
/* Return true if T is a CALL_EXPR or an expression that can be
- assignmed to a temporary. Note that this predicate should only be
+ assigned to a temporary. Note that this predicate should only be
used during gimplification.
--- Comment #7 from jakub at gcc dot gnu dot org 2010-06-25 12:30 ---
Should be fixed now.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #23 from jakub at gcc dot gnu dot org 2010-06-25 12:30 ---
Fixed on the trunk so far.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Known
--- Comment #1 from manu at gcc dot gnu dot org 2010-06-25 13:09 ---
Subject: Bug 44665
Author: manu
Date: Fri Jun 25 13:09:28 2010
New Revision: 161380
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161380
Log:
2010-06-25 Manuel López-Ibáñez m...@gcc.gnu.org
PR
--- Comment #1 from jakub at gcc dot gnu dot org 2010-06-25 13:10 ---
For DW_AT_low_pc, we do this because of (DWARF4, 3.1.1:
A DW_AT_low_pc attribute may also be specified in combination with
DW_AT_ranges to specify the default base address for use in location lists (see
Section 2.6.2)
--- Comment #2 from manu at gcc dot gnu dot org 2010-06-25 13:14 ---
FIXED in trunk.
Such fixes are considered obvious, so feel free to commit patches to fix them.
Fixing changelogs and svn logs for typos falls also into the obvious category.
If you do not have write access, just send
--- Comment #1 from turutani at scphys dot kyoto-u dot ac dot jp
2010-06-25 13:54 ---
Created an attachment (id=21004)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21004action=view)
sample code
This is a test code to generate error.
gcc-4.2.5 20090325 generates no error.
--- Comment #18 from hjl dot tools at gmail dot com 2010-06-25 14:09
---
(In reply to comment #17)
Subject: Re: [4.4/4.5/4.6 Regression] Performance
degradation for simple fibonacci numbers calculation
This is not correct, when profile is guessed we should look into the
On Jun 25, 2010, at 3:49 AM, pluto at agmk dot net gcc-bugzi...@gcc.gnu.org
wrote:
hi,
the latest llvm/clang++ reports an error during parsing tr1/tuple
included from tr1/functional:
Both of these are c++0x only headers and really are only supported
when compiling in c++0x mode.
--- Comment #4 from pinskia at gmail dot com 2010-06-25 14:18 ---
Subject: Re: New: missed GXX_EXPERIMENTAL guards in tr1/tuple?
On Jun 25, 2010, at 3:49 AM, pluto at agmk dot net gcc-bugzi...@gcc.gnu.org
wrote:
hi,
the latest llvm/clang++ reports an error during parsing
--- Comment #5 from paolo dot carlini at oracle dot com 2010-06-25 14:23
---
Wrong Andrew.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44663
12.5.2.12 Argument presence and restrictions on arguments not present
A dummy argument or an entity that is host associated with a dummy argument is
not present if the dummy argument
[...]
* does not have the ALLOCATABLE or POINTER attribute, and corresponds to an
actual argument that
- has
Command line:
$ gfortran -O2 -fprofile-generate
or
$ gfortran -O1 -finline-small-functions -fprofile-generate
Compiler output:
$ gfortran -O1 -finline-small-functions -fprofile-generate
/mnt/svn/gcc-trunk/gcc/testsuite/gfortran.dg/char_pointer_assign_5.f90
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||ice-checking
Target Milestone|--- |4.5.1
--- Comment #22 from sfilippone at uniroma2 dot it 2010-06-25 15:31 ---
(In reply to comment #21)
Ok, I bit the bullet, and fooled around with the internals to see what was
happening. I did a very naive thing of adding warnings in
resolve.c:resolve_typebound_generic_call, and I think I
--- Comment #1 from hjl at gcc dot gnu dot org 2010-06-25 15:33 ---
Subject: Bug 44326
Author: hjl
Date: Fri Jun 25 15:33:21 2010
New Revision: 161389
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161389
Log:
Don't search DEBUG_INSNs for removable zero extends.
2010-06-25 H.J.
--- Comment #2 from hjl dot tools at gmail dot com 2010-06-25 15:34 ---
Fixed.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #4 from matz at gcc dot gnu dot org 2010-06-25 15:34 ---
Indeed. Mine.
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #23 from sfilippone at uniroma2 dot it 2010-06-25 15:34 ---
(In reply to comment #22)
generic_23.f03 obviously works becase the binding name DOIT and the procedure
name are one and the same
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43945
--- Comment #8 from sje at cup dot hp dot com 2010-06-25 16:10 ---
Resolved with code change to test case.
--
sje at cup dot hp dot com changed:
What|Removed |Added
: 0x33
45 DW_AT_data_member_location: 2 byte block: 23 0 (DW_OP_plus_uconst:
0)
48 DW_AT_accessibility: 2 (protected)
DIE 0x33 should have DW_AT_accessibility.
FAIL g++ (GCC) 4.6.0 20100625 (experimental)
FAIL g++ (GCC) 4.5.1 20100625 (prerelease)
SKIP g++ (GCC) 4.4.5
! { dg-options -O2 -funroll-loops }
function foo (b)
character (len=1) :: b(4)
logical :: foo
foo = any (b .ne. (/1,2,3,4/))
end
results in horrible code:
movzbl .LC0(%rip), %edx
movl$1, %eax
cmpb%dl, (%rdi)
jne .L2
movzbl .LC1(%rip),
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44669
--- Comment #1 from jan dot kratochvil at redhat dot com 2010-06-25 16:31
---
Dependent GDB Bug:
http://sourceware.org/bugzilla/show_bug.cgi?id=11757
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44668
--- Comment #3 from hjl dot tools at gmail dot com 2010-06-25 16:43 ---
Another testcase:
[...@gnu-6 44659]$ cat extract-3.c
typedef struct
{
unsigned char c1;
unsigned char c2;
unsigned char c3;
unsigned char c4;
} foo_t;
int
foo (foo_t x)
{
return x.c2 != 0;
}
[...@gnu-6
--- Comment #8 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-06-25
16:48 ---
Subject: Re: [4.4/4.5/4.6 regression] Preprocessor ICE with -m64 and
--traditional-cpp
It occured to me that this is only failing for me with 32-bit cc1,
i.e. i386-pc-solaris2.11, sparc-sun-solaris2.11,
--- Comment #10 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-06-25
16:49 ---
Subject: Re: 32-bit gfortran.dg/atan2_1.f90 fails on Solaris 1[01]/x86 at -O0
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2010-06-22 01:24
---
atan2_1.f90 has failed on other
--- Comment #2 from jakub at gcc dot gnu dot org 2010-06-25 16:53 ---
Created an attachment (id=21005)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21005action=view)
gcc46-pr44668.patch
Patch to fix this for typedefs. More work will be needed to handle it for
other DW_TAG_* type
--- Comment #4 from changpeng dot fang at amd dot com 2010-06-25 17:08
---
(In reply to comment #3)
Created an attachment (id=21001)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21001action=view) [edit]
Potential fix for compile time regression
Here is a potential fix. We
../../gcc/gcc/config/arm/arm.c: In function insn_code
locate_neon_builtin_icode(int, neon_itype*):
../../gcc/gcc/config/arm/arm.c:18244: error: structure key with uninitialized
const members
--
Summary: arm port fails to build with --enable-build-with-cxx
Product: gcc
--- Comment #14 from kargl at gcc dot gnu dot org 2010-06-25 17:14 ---
(In reply to comment #11)
Well, it is invalid code - based on a valid Fortran code. If you use Delta to
reduce a test case (cf.
http://gcc.gnu.org/wiki/A_guide_to_testcase_reduction),
it simply removes lines
--- Comment #1 from hjl dot tools at gmail dot com 2010-06-25 17:50 ---
It is caused by revision 150519:
http://gcc.gnu.org/ml/gcc-cvs/2009-08/msg00199.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #15 from jakub at gcc dot gnu dot org 2010-06-25 18:11 ---
Well, the compiler shouldn't ICE on invalid input.
And, delta is just a simple text tool, it depends on the user how he writes the
test script. Ideally when reducing a testcase to find an ICE the delta test
script
--- Comment #11 from jvdelisle at gcc dot gnu dot org 2010-06-25 18:22
---
Please go ahead and commit, OK by me.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8
--- Comment #3 from jakub at gcc dot gnu dot org 2010-06-25 18:23 ---
Created an attachment (id=21006)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21006action=view)
gcc46-pr44668.patch
Updated patch.
--
jakub at gcc dot gnu dot org changed:
What|Removed
--- Comment #12 from ro at gcc dot gnu dot org 2010-06-25 18:32 ---
Subject: Bug 8
Author: ro
Date: Fri Jun 25 18:31:33 2010
New Revision: 161392
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161392
Log:
2010-06-25 Jerry DeLisle jvdeli...@gcc.gnu.org
PR
--- Comment #13 from ro at gcc dot gnu dot org 2010-06-25 18:33 ---
Subject: Bug 8
Author: ro
Date: Fri Jun 25 18:33:01 2010
New Revision: 161393
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161393
Log:
2010-06-25 Jerry DeLisle jvdeli...@gcc.gnu.org
PR
--- Comment #14 from ro at gcc dot gnu dot org 2010-06-25 18:36 ---
Thanks, installed on mainline and 4.5 branch.
--
ro at gcc dot gnu dot org changed:
What|Removed |Added
include of insn-constants.h
* Makefile.in (insn-enums.o): Depend on insn-constants.h.
Modified:
branches/multi-target-20100625-branch/gcc/ChangeLog
branches/multi-target-20100625-branch/gcc/Makefile.in
branches/multi-target-20100625-branch/gcc/genenums.c
--
http
1 - 100 of 145 matches
Mail list logo
