On Thu, 1 Oct 2009, Joe Buck wrote:
On Thu, Oct 01, 2009 at 05:00:10PM -0700, Andi Kleen wrote:
Richard Guenther rguent...@suse.de writes:
The wish for more granular and thus smaller debug information (things like
-gfunction-arguments which would properly show parameter values
for
2009/9/30 Richard Henderson r...@redhat.com:
On 09/29/2009 09:46 PM, Mohamed Shafi wrote:
bool strict = reload_completed ? true : false;
What happens if you set strict = false here?
That's what ARM does.
That particular case works, and yes arm does it that way but there
are other
2009/9/28 Richard Henderson r...@redhat.com:
On 09/28/2009 07:25 AM, Mohamed Shafi wrote:
Hope someone suggests me a solution.
The solution is almost certainly something involving the
TARGET_SECONDARY_RELOAD hook. You need to inform reload that it's going to
need some scratch registers in
I tried again but I'm not making much progress.
Maybe I need to go further than Canada, let's say Alaska.
1. First I need to use my current build machine, Linux,
to first of all convert the i370.md into insn*.c files, then
generate an xgcc. The xgcc would be capable of producing
i370 code so
To make the above work first the external tools have to add the
capabilities, just implementing it in GCC doesn't work for us.
Ok, but there's more to building software, than just building rpms.
For example I can definitely see a common use case where a program
is built with line number and
On 10/02/2009 05:03 AM, Mohamed Shafi wrote:
That particular case works, and yes arm does it that way but there
are other targets that uses (reload_completed || reload_in_progress)
like s390. So thats why i had to ask if my definition of strict is
proper or not. I am not sure which one to
Diego Novillo dnovi...@google.com writes:
If anyone has free cycles I would appreciate results from other
ELF-capable targets.
In addition to the issues already reported for Solaris 11/SPARC, here are
the findings for Solaris 10/x86:
Paul Edwards mutazi...@gmail.com writes:
1. First I need to use my current build machine, Linux,
to first of all convert the i370.md into insn*.c files, then
generate an xgcc. The xgcc would be capable of producing
i370 code so long as I use the -S option. It doesn't really
matter how this
Paul == Paul Brook p...@codesourcery.com writes:
Paul IMHO building lots of multilibs by default significantly increases
Paul toolchain size and build time for little actual benefit. ARM CPUs
Paul are generally backwards compatible and we only have one important
Paul ABI variant, so very few
On Fri, 2 Oct 2009, Diego Novillo wrote:
I have committed today's round of feedback to the branch. It incorporates
richi's fixes for C++ and enables LTO testing on builtins.exp (which is
interesting for LTO as it includes multiple files)
I am still not sure whether I will do the final
Hi Ian, thanks for your reply.
1. First I need to use my current build machine, Linux,
to first of all convert the i370.md into insn*.c files, then
generate an xgcc. The xgcc would be capable of producing
i370 code so long as I use the -S option. It doesn't really
matter how this xgcc was
Is there a documentation of the various magic letters that you can
apply to an operand in inline assembly? What I mean is this:
asm volatile (
some_insn %X[operand] \n
: [operand] =r (expr)
);
What I look for is documentation of 'X'. In particular, when (expr) is
a multi-register object,
On Fri, Oct 2, 2009 at 18:16, Richard Guenther rguent...@suse.de wrote:
Done. If all goes well I think we should merge - waiting even more
doesn't really add to the quality and it just takes extra ressources
to work on the branch.
I agree. I'd like to get started with the stage3 fixes next
--- Comment #8 from kirill at shutemov dot name 2009-10-02 07:34 ---
(In reply to comment #6)
(In reply to comment #5)
Ok. If .eh_frame should not be generated on ARM, we should to modify
dwarf2out_do_cfi_asm() to always return false on ARM. Right?
Look at this patch
--- Comment #59 from developer at sandoe-acoustics dot co dot uk
2009-10-02 08:17 ---
Created an attachment (id=18691)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18691action=view)
libext patch with ext on as default, debug flag removed and white space changes
removed.
This
, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
mov r0, #0
bx lr
.LFE0:
.cantunwind
.fnend
.size main, .-main
.ident GCC: (GNU) 4.4.2 20091002 (prerelease) [trunk revision
--- Comment #10 from 4ernov at gmail dot com 2009-10-02 08:41 ---
Yeah, I see..
But anyway, thank you for discussing it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41448
--- Comment #1 from burnus at gcc dot gnu dot org 2009-10-02 08:42 ---
I think the problem occurs in decl.c's
static gfc_try
encapsulate_class_symbol (gfc_typespec *ts, symbol_attribute *attr,
gfc_array_spec **as)
{
[...]
if (fclass == NULL)
{
--- Comment #10 from kirill at shutemov dot name 2009-10-02 09:06 ---
(In reply to comment #9)
(In reply to comment #8)
Are you testing the correct compiler ?
Yes.
After building my 4.4 tree (though a
cross compiler ) I see the code generated as below.
The only reason why
--- Comment #8 from ros at rzg dot mpg dot de 2009-10-02 09:43 ---
Subject: Re: [4.3/4.4/4.5 Regression] PARAMETER statement
in module subroutines
Thanks for fixing the bug 41515. Where can I find a Linux binary
of gfortran revision 152379, and how can I find out the revision
number
With -fpreprocessed, expand_location (BUILTINS_LOCATION) yields the
preprocessed source file name (e.g. bar.ii), line 1, column 1, instead of
built-in filename, line 0. So e.g. ./cc1 -g -dA -fpreprocessed bar.ii
where bar.ii is:
# 1 foo.C
# 1 built-in
# 1 command-line
# 1 foo.C
int
foo
--- Comment #8 from burnus at gcc dot gnu dot org 2009-10-02 09:54 ---
(In reply to comment #7)
Checking the 4.2 branch and trans-expr.c in trunk, it appears that
this chunk of code in gfc_conv_function_call() has gone missing.
It was removed with the following patch:
Date: Tue Jul
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Component|middle-end |testsuite
Summary|gcc.dg/tree-ssa/ipa-cp-1.c |[4.5
--- Comment #9 from mikael at gcc dot gnu dot org 2009-10-02 10:17 ---
(In reply to comment #8)
Where can I find a Linux binary
of gfortran revision 152379, and how can I find out the revision
number without downloading and installing a gfortran binary?
See the gfortran wiki
--- Comment #10 from ros at rzg dot mpg dot de 2009-10-02 10:25 ---
Subject: Re: [4.3/4.4/4.5 Regression] PARAMETER statement
in module subroutines
On Fri, 2 Oct 2009, mikael at gcc dot gnu dot org wrote:
--- Comment #9 from mikael at gcc dot gnu dot org 2009-10-02 10:17
--- Comment #60 from developer at sandoe-acoustics dot co dot uk
2009-10-02 10:39 ---
Reg test results:
powerpc-apple darwin8 :
http://gcc.gnu.org/ml/gcc-testresults/2009-10/msg00141.html
i686-apple-darwin9: http://gcc.gnu.org/ml/gcc-testresults/2009-10/msg00142.html
compare without
This is related to bug #35167 in:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35167
The attached test case compiles if the preprocessor symbol MAKE_IT_WORK is
defined. Otherwise fails with:
main.cpp: In static member function 'static const X AQ::getIt2() [with Q =
X]':
main.cpp:34:
--- Comment #1 from skandalfo at gmail dot com 2009-10-02 10:52 ---
Created an attachment (id=18692)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18692action=view)
Test case
Compiles with -DMAKE_IT_WORK.
Doesn't compile otherwise.
--
--- Comment #2 from skandalfo at gmail dot com 2009-10-02 10:53 ---
Excuse me, the confirmation of the issue WAS NOT DONE ON 3.3.1 on
x86_64-linux-gnum but in 4.3.3 on x86_64-linux-gnu.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41544
--- Comment #6 from jamborm at gcc dot gnu dot org 2009-10-02 11:39 ---
Fixed
--
jamborm at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #11 from burnus at gcc dot gnu dot org 2009-10-02 11:58 ---
(In reply to comment #8)
Thanks for fixing the bug 41515. Where can I find a Linux binary
of gfortran revision 152379, and how can I find out the revision
number without downloading and installing a gfortran
On *-apple-darwin* several tests in the g++ suite fail (see
http://gcc.gnu.org/ml/gcc-testresults/2009-10/msg00143.html) with:
/opt/gcc/_gcc_clean/gcc/testsuite/g++.dg/template/memfriend7.C:20:26: internal
compiler error: tree check: expected var_decl or function_decl, have
template_decl in
--- Comment #12 from ros at rzg dot mpg dot de 2009-10-02 12:35 ---
Subject: Re: [4.3/4.4/4.5 Regression] PARAMETER statement
in module subroutines
On Fri, 2 Oct 2009, burnus at gcc dot gnu dot org wrote:
Depends where you download the binary from. For my x86-64 builds, one can
Revision 152389:
http://gcc.gnu.org/ml/gcc-cvs/2009-10/msg00038.html
breaks gcc.target/i386/ifcvt-onecmpl-abs-1.c on x86-64
since -mtune=i586 is invalid for x86-64. I think we
should use -mtune=generic.
--
Summary: Revision 152389 breaks gcc.target/i386/ifcvt-onecmpl-
--- Comment #1 from hjl at gcc dot gnu dot org 2009-10-02 13:28 ---
Subject: Bug 41546
Author: hjl
Date: Fri Oct 2 13:28:17 2009
New Revision: 152400
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=152400
Log:
2009-10-02 H.J. Lu hongjiu...@intel.com
PR testsuite/41546
--- Comment #2 from hjl dot tools at gmail dot com 2009-10-02 13:30 ---
Fixed.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
On 10/02/2009 05:35 AM, ros at rzg dot mpg dot de wrote:
--- Comment #12 from ros at rzg dot mpg dot de 2009-10-02 12:35 ---
Subject: Re: [4.3/4.4/4.5 Regression] PARAMETER statement
in module subroutines
On Fri, 2 Oct 2009, burnus at gcc dot gnu dot org wrote:
Depends where you
--- Comment #13 from jvdelisle at verizon dot net 2009-10-02 13:57 ---
Subject: Re: [4.3/4.4/4.5 Regression] PARAMETER statement
in module subroutines
On 10/02/2009 05:35 AM, ros at rzg dot mpg dot de wrote:
--- Comment #12 from ros at rzg dot mpg dot de 2009-10-02 12:35
--- Comment #28 from howarth at nitro dot med dot uc dot edu 2009-10-02
14:08 ---
On reflection, I think the change Mike proposed for darwin.c in Comment 13
fails because it flag_reorder_blocks never gets set to 1 by that patch. I don't
know how I could implement the three variations
template class T
class DataArray {
int max() const { }
};
class Name { };
class DataHashTable {
template class ElemHashItem class Element { };
DataArray Element Name m_elem;
};
DataHashTable p;
./g++ -B. -nostdlib -fPIC -shared spxgeneralsm.3.ii -flto
lto1: internal compiler
class DataArray {
int max() const{ }
};
template class HashItem
class DataHashTable {
template class ElemHashItem
class Element{ };
typedef Element HashItem Elem;
DataArray m_elem;
};
class Name{ };
class NameSet {
DataHashTable Name hashtab;
};
--- Comment #24 from jakub at gcc dot gnu dot org 2009-10-02 15:01 ---
Subject: Bug 41404
Author: jakub
Date: Fri Oct 2 15:01:22 2009
New Revision: 152403
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=152403
Log:
PR debug/41404
PR debug/41353
*
--- Comment #13 from jakub at gcc dot gnu dot org 2009-10-02 15:01 ---
Subject: Bug 41353
Author: jakub
Date: Fri Oct 2 15:01:22 2009
New Revision: 152403
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=152403
Log:
PR debug/41404
PR debug/41353
*
--- Comment #25 from jakub at gcc dot gnu dot org 2009-10-02 15:03 ---
Should be fixed now.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from lanceb at ksu dot edu 2009-10-02 15:29 ---
Subject: Re: Segmentation fault calling DGETRF from gfortran
I have not figured out what is going on. I've been using G95 because it
works correctly with G95. When I have more time (things are very busy
right now) I will
--- Comment #26 from davek at gcc dot gnu dot org 2009-10-02 15:35 ---
Thanks Jakub, I'll try and verify that in the next ~24hrs.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41404
See mailing list:
http://gcc.gnu.org/ml/java/2009-09/msg00030.html
I have a problem with jni code callbacks.
I have attached some code that shows the problem.
The result of this code is:
# results on fedora 11
# gcc/gcj 4.4.1
# kernel 2.6.30.5-43.fc11.x86_64
# openjdk
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-10-02 16:21 ---
__FILE__ is dependent on # markers and #line markers in the preprocessed source
so this is invalid. __LINE__ is also dependent too.
If you look at the preprocessed source you will notice still some # in there.
--- Comment #6 from kargl at gcc dot gnu dot org 2009-10-02 16:25 ---
Works for me.
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from burnus at gcc dot gnu dot org 2009-10-02 16:26 ---
Subject: Bug 41479
Author: burnus
Date: Fri Oct 2 16:25:50 2009
New Revision: 152407
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=152407
Log:
2009-10-02 Tobias Burnus bur...@net-b.de
PR
--- Comment #13 from domob at gcc dot gnu dot org 2009-10-02 16:26 ---
I'll work on this.
--
domob at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from jakub at gcc dot gnu dot org 2009-10-02 16:35 ---
Created an attachment (id=18693)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18693action=view)
gcc45-pr41511.patch
Agreed. Patch I'm going to bootstrap/regtested on x86_64-linux and i686-linux
now, fixes this
--- Comment #2 from msebor at gmail dot com 2009-10-02 16:39 ---
I don't have a strong objection to not including __FILE__ and the rest of
standard predefined macros (e.g., __LINE__, __DATE__ and __TIME__) in the
output if that's by design but I would expect the documentation to mention
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-10-02 16:57 ---
Hmm, considering the C99 standard has a footnote about __FILE__ (149)
149) The presumed source file name and line number can be changed by the #line
directive.
So of course it is hard to define these in the
--- Comment #11 from armin76 at gentoo dot org 2009-10-02 17:08 ---
Created an attachment (id=18694)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18694action=view)
backtrace.log
and the backtrace using gdb with the following command:
gdb --args /root/build/./gcc/cc1 conftest.c
--- Comment #12 from bergner at gcc dot gnu dot org 2009-10-02 17:12
---
Subject: Bug 41081
Author: bergner
Date: Fri Oct 2 17:12:31 2009
New Revision: 152411
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=152411
Log:
Backport from mainline:
2009-08-23 Alan
--- Comment #8 from bergner at gcc dot gnu dot org 2009-10-02 17:12 ---
Subject: Bug 40473
Author: bergner
Date: Fri Oct 2 17:12:31 2009
New Revision: 152411
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=152411
Log:
Backport from mainline:
2009-08-23 Alan
From http://gcc.gnu.org/ml/gcc-patches/2009-09/msg02151.html
+static void
+write_resolution (void)
+{
+ unsigned int i;
+ FILE *f;
+ /* FIXME: Disabled for now since we are not using the resolution file. */
+ return;
+
+
+ /* FIXME: This should be a temporary file. */
+ f = fopen
--- Comment #2 from ro at gcc dot gnu dot org 2009-10-02 17:45 ---
Initial patch to get it to compile here:
http://gcc.gnu.org/ml/libstdc++/2009-10/msg8.html
--
ro at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from ro at gcc dot gnu dot org 2009-10-02 17:47 ---
Created an attachment (id=18695)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18695action=view)
libstdc++ testsuite log (both 32 and 64 bit) on Solaris 10/x86 with initial
patch
--
--- Comment #4 from msebor at gmail dot com 2009-10-02 18:00 ---
I understand that the values of __FILE__ and __LINE__ change within the same
translation unit and thus may not be meaningful in the output of -dM -E. But
the values of __DATE__ and __TIME__ do not change within a
--- Comment #6 from jakub at gcc dot gnu dot org 2009-10-02 18:52 ---
Subject: Bug 40521
Author: jakub
Date: Fri Oct 2 18:52:15 2009
New Revision: 152414
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=152414
Log:
PR debug/40521
* configure.ac
ICE on ia64 at -O1 and higher, seen with gcc 4.3 and 4.4 but not 4.2.
% gcc -O -c t.c
t.c: In function 'main':
t.c:5:1: error: unrecognizable insn:
(insn 5 4 6 3 t.c:3 (set (reg:DF 344)
(unsigned_float:DF (reg/f:DI 328 sfp))) -1 (nil))
t.c:5:1: internal compiler error: in
--- Comment #9 from burnus at gcc dot gnu dot org 2009-10-02 19:33 ---
Can this be closed as FIXED?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40996
--- Comment #1 from manu at gcc dot gnu dot org 2009-10-02 20:36 ---
Shouldn't location 0, location 1 and location 2 be reserved and allocated as
soon as the line_table is created? I think this was already in my patch moving
all location stuff to its own library.
--
manu at gcc dot
--
sam at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |sam at gcc dot gnu dot org
|dot org
--- Comment #2 from sam at gcc dot gnu dot org 2009-10-02 21:04 ---
Indeed. Closing as invalid, thanks Pierre-Nicolas.
--
sam at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from jakub at gcc dot gnu dot org 2009-10-02 21:04 ---
Perhaps better don't do something as non-sensical as this.
Anyway, we shouldn't ICE on it.
--- function.c.jj2009-09-29 15:10:43.0 +0200
+++ function.c2009-10-02 23:01:49.0 +0200
@@
--- Comment #7 from sam at gcc dot gnu dot org 2009-10-02 21:16 ---
The problem is still present in the trunk: datagram based streams are
meaningless in most cases.
The more I think about it, the more I think they should be removed from
GNAT.Sockets completely instead of half-fixed.
--- Comment #5 from sam at gcc dot gnu dot org 2009-10-02 21:19 ---
Reconfirmed on SVN trunk
+===GNAT BUG DETECTED==+
| 4.5.0 20090930 (experimental) (x86_64-unknown-linux-gnu) Assert_Failure
exp_disp.adb:1363|
| Error detected at
--
sam at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|sam at gcc dot gnu dot org |unassigned at gcc dot gnu
|
--- Comment #1 from sam at gcc dot gnu dot org 2009-10-02 21:25 ---
Reconfirmed on SVN trunk:
GNAT 4.5.0 20090930 (experimental)
Copyright 1992-2009, Free Software Foundation, Inc.
Compiling: p1.ads (source file time stamp: 2009-10-02 21:23:50)
2.type T1 is tagged null
--- Comment #1 from sam at gcc dot gnu dot org 2009-10-02 21:26 ---
Reconfirmed on SVN trunk.
+===GNAT BUG DETECTED==+
| 4.5.0 20090930 (experimental) (x86_64-unknown-linux-gnu) Program_Error
exp_disp.adb:7340 explicit raise|
| Error
--
sam at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
* tree.h (is_lang_specific): Include LANG_TYPE.
* tree.c (find_decls_types_r): Manually add interesting parts
of TYPE_FIELDS. Walk BINFO_VIRTUALS. Do not walk TYPE_METHODS.
testsuite/ChangeLog.lto
* g++.dg/lto/20091002-1_0.C: New testcase.
* g++.dg/lto/20091002-2_0.C
* tree.h (is_lang_specific): Include LANG_TYPE.
* tree.c (find_decls_types_r): Manually add interesting parts
of TYPE_FIELDS. Walk BINFO_VIRTUALS. Do not walk TYPE_METHODS.
testsuite/ChangeLog.lto
* g++.dg/lto/20091002-1_0.C: New testcase.
* g++.dg/lto/20091002-2_0.C
--- Comment #1 from sam at gcc dot gnu dot org 2009-10-02 21:36 ---
Still present in GCC trunk (4.5.0 20090930)
--
sam at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from sam at gcc dot gnu dot org 2009-10-02 21:38 ---
Reconfirmed on SVN trunk: gcc (GCC) 4.5.0 20090930 (experimental)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37775
--- Comment #29 from howarth at nitro dot med dot uc dot edu 2009-10-02
22:09 ---
Jakub,
Is there any reason why we can't have...
Index: opts.c
===
--- opts.c (revision 152346)
+++ opts.c (working copy)
@@
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-10-02 22:18 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-10-02 22:19 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from janus at gcc dot gnu dot org 2009-10-02 22:24 ---
(In reply to comment #9)
Can this be closed as FIXED?
I think so.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #13 from bergner at gcc dot gnu dot org 2009-10-03 01:39
---
Subject: Bug 41081
Author: bergner
Date: Sat Oct 3 01:39:14 2009
New Revision: 152430
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=152430
Log:
Backport from mainline.
2009-08-30 Alan
--- Comment #111 from bergner at gcc dot gnu dot org 2009-10-03 01:39
---
Subject: Bug 26854
Author: bergner
Date: Sat Oct 3 01:39:14 2009
New Revision: 152430
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=152430
Log:
Backport from mainline.
2009-08-30 Alan
--- Comment #112 from bergner at gcc dot gnu dot org 2009-10-03 01:39
---
Subject: Bug 33928
Author: bergner
Date: Sat Oct 3 01:39:14 2009
New Revision: 152430
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=152430
Log:
Backport from mainline.
2009-08-30 Alan
--- Comment #4 from kkojima at gcc dot gnu dot org 2009-10-03 04:00 ---
With the patch, native sh4-linux stage2 compiler generates the same
codes with and without -g for cfgexpand.c/omp-low.c. I believe that
it restores the bootstrap on sh. Thanks for taking a look at this
problem.
86 matches
Mail list logo
