Hi,
As I understand, the DWARF tag DW_AT_external is meant to indicate whether a
variable/function is accessible from outside the compilation unit(object file)
containing the given DWARF DIE - Debugging Information Entry.
But it looks like DW_AT_external is also set for variables/functions de
--- Comment #3 from kkojima at gcc dot gnu dot org 2010-07-31 04:46 ---
Fixed.
--
kkojima at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #6 from kkojima at gcc dot gnu dot org 2010-07-31 04:45 ---
Fixed.
--
kkojima at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRM
--- Comment #17 from damian at rouson dot net 2010-07-31 02:30 ---
Tobias,
Thanks for your continued efforts on this. It will ultimately have a huge
impact on the usability of gfortran for my purposes. I look forward to
hearing more when you get back to it or when others do.
Since
--- Comment #2 from bkoz at gcc dot gnu dot org 2010-07-31 01:46 ---
That dr-934-1 ICE is the only thing I see. On g++ testing, I see:
FAIL: c-c++-common/uninit-17.c (test for warnings, line 14)
FAIL: c-c++-common/uninit-17.c (test for excess errors)
=== g++ Summary =
--- Comment #1 from bkoz at gcc dot gnu dot org 2010-07-31 01:41 ---
As of 2010-07-30, x86_64/linux see:
FAIL: abi_check
Running
/mnt/share/src/gcc.git-constexpr/libstdc++-v3/testsuite/libstdc++-dg/conformance.exp
...
FAIL: 20_util/duration/arithmetic/dr934-1.cc (test for excess errors)
--- Comment #1 from bkoz at gcc dot gnu dot org 2010-07-31 01:36 ---
Created an attachment (id=21362)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21362&action=view)
FAIL 01: 20_util/duration/arithmetic/dr934-1.cc
Pre-processed source
--
http://gcc.gnu.org/bugzilla/show_bug
--
bkoz at gcc dot gnu dot org changed:
What|Removed |Added
CC||jason at redhat dot com, gdr
|
This is a meta-tracker for libstdc++ issues with constexpr. It tracks the git
branch
of http://gcc.gnu.org/wiki/Constexpr";>contexpr. There is another
bug for the g++ component (http://gcc.gnu.org/PR45148)
Right now some of the static members of random have been made non-static.
atomic is missing
This is a meta-tracker for g++ issues with constexpr. It tracks the git branch
of http://gcc.gnu.org/wiki/Constexpr";>contexpr. There is another
bug for the libstdc++ component.
As of 2010-07-30, x86_64/linux see:
FAIL: abi_check
Running
/mnt/share/src/gcc.git-constexpr/libstdc++-v3/testsuite/lib
Standard installation of FreeBSD 8.1 on 64 but AMD processor, building package
net-mgmt/net-snmp from /usr/ports, command line is "make install" with the
options MFD_REWRITES, PERL, PERL_EMBEDDED, and DUMMY selected.
cc (GCC) 4.2.1 20070719 [FreeBSD]
libtool: compile: cc -I../include -I. -I../s
--- Comment #17 from pinskia at gcc dot gnu dot org 2010-07-30 23:13
---
Someone might want to try this again after the fix for PR 38582.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31850
--- Comment #8 from dominiq at lps dot ens dot fr 2010-07-30 22:49 ---
Closing.
--
dominiq at lps dot ens dot fr changed:
What|Removed |Added
Status|NEW
--- Comment #18 from ramana at gcc dot gnu dot org 2010-07-30 22:38 ---
And hence fixed. Thanks for allowing the backport.
Ramana
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #17 from ramana at gcc dot gnu dot org 2010-07-30 22:36 ---
Subject: Bug 43698
Author: ramana
Date: Fri Jul 30 22:35:40 2010
New Revision: 162725
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162725
Log:
Backport fix for PR target/43698.
2010-07-30 Ramana Radhakri
--- Comment #8 from janus at gcc dot gnu dot org 2010-07-30 20:56 ---
(In reply to comment #7)
> The test case still fails when adding an 'only' clause in the use statement:
>
>use polynomial, only: polynom
>
This case can be fixed by the following patchlet:
Index: module.c
=
tr...@162541 does not bootstrap with BOOT_CFLAGS="-g -O3".
Comparing stages 2 and 3
warning: gcc/cc1plus-checksum.o differs
warning: gcc/cc1-checksum.o differs
Bootstrap comparison failure!
gcc/dbxout.o differs
--
Summary: Bootstrap broken at -O3
Product: gcc
Ve
--- Comment #17 from dave at hiauly1 dot hia dot nrc dot ca 2010-07-30
19:20 ---
Subject: Re: [4.6 Regression] ICE: Segmentation fault (cc1) compiling
matmul_i1.c
> I just tried the patch in comment #15 and successfully bootstrapped GCC on my
> 32 bit PA system (including building mat
--- Comment #6 from binocs38149 at mypacks dot net 2010-07-30 19:01 ---
(In reply to comment #5)
Apple seems to have fixed it a different way:
http://www.opensource.apple.com/source/gcc/gcc-5659/gcc/cp/decl2.c
{
tree underlying_type = TREE_TYPE (DECL_NAME (decl));
int
--- Comment #6 from hjl dot tools at gmail dot com 2010-07-30 18:54 ---
Fixed by revision 162720.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #7 from janus at gcc dot gnu dot org 2010-07-30 18:54 ---
(In reply to comment #6)
> Good point. Actually the test case is fixed by making the vtab public:
Of course this does not fix the actual problem, but it limits the set of
affected cases (and I guess it's a good idea i
--- Comment #6 from janus at gcc dot gnu dot org 2010-07-30 18:46 ---
(In reply to comment #4)
> One observation: In case one does not have PRIVATE, one initializes seemingly
> the global variable
>__polynomial_MOD_vtab
> while with PRIVATE and failing, one uses the variables vtab$po
--- Comment #5 from janus at gcc dot gnu dot org 2010-07-30 18:39 ---
(In reply to comment #4)
> admittedly, I do not fully understand the code which sets
> the TBP to the vtable - shouldn't this be done when the vtable for a type is
> created rather than every time before it is used?
W
--- Comment #16 from sje at cup dot hp dot com 2010-07-30 18:33 ---
I just tried the patch in comment #15 and successfully bootstrapped GCC on my
32 bit PA system (including building matmul_i1.c). This was on ToT (r162716).
--
sje at cup dot hp dot com changed:
What|
--- Comment #1 from jakub at gcc dot gnu dot org 2010-07-30 17:09 ---
The solution IMNSHO is to detect adjacent bitfield operations that can be
handled together and lower bitfield ops still at the tree level, though soon
before expansion, rather than disabling SRA for bitfields.
--
--- Comment #1 from allcock at math dot utexas dot edu 2010-07-30 17:33
---
Created an attachment (id=21361)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21361&action=view)
preprocessed version of 20-line c++ file exhibiting bug
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
This should print 100 numbers separated by tabs, then 100 x's separated by
spaces, then 100 x's separated by tabs, then 100 0's (int not char) separated
by tabs. But the last two print fewer than 100--only one line of them.
g++ -v -O0 -Wall --save-temps bug.cc
Using built-in specs.
Target: i686-ap
--- Comment #19 from janus at gcc dot gnu dot org 2010-07-30 17:55 ---
Fixed with r162724. I am planning to backport this to 4.5 in about a week,
provided it does not introduce any more regressions.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44929
--- Comment #2 from redi at gcc dot gnu dot org 2010-07-30 17:54 ---
4.2.1 is no logner supported, and bugs for Apple builds should be reported to
Apple.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45145
--- Comment #1 from davidxl at gcc dot gnu dot org 2010-07-30 17:23 ---
Seems -Os specific -- also reproducible on x86. With -O2, the result is
expected.
David
--
davidxl at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #18 from janus at gcc dot gnu dot org 2010-07-30 17:50 ---
Subject: Bug 44929
Author: janus
Date: Fri Jul 30 17:50:28 2010
New Revision: 162724
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162724
Log:
2010-07-30 Janus Weil
Steven G. Kargl
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |janus at gcc dot gnu dot org
|dot org
--- Comment #3 from uweigand at gcc dot gnu dot org 2010-07-30 16:19
---
Fixed in mainline. Will check in to 4.5 after 4.5.1 release.
--
uweigand at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from jakub at gcc dot gnu dot org 2010-07-30 15:57 ---
Fixed on the trunk, will backport to 4.5.2 once 4.5.1 is released.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #2 from uweigand at gcc dot gnu dot org 2010-07-30 15:50
---
Subject: Bug 45112
Author: uweigand
Date: Fri Jul 30 15:49:34 2010
New Revision: 162716
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162716
Log:
gcc/
PR c++/45112
* cp/decl.c (duplicate_d
--- Comment #4 from burnus at gcc dot gnu dot org 2010-07-30 15:29 ---
One observation: In case one does not have PRIVATE, one initializes seemingly
the global variable
__polynomial_MOD_vtab
while with PRIVATE and failing, one uses the variables vtab$polynomD which is
local in "test_p
--- Comment #54 from bernds at gcc dot gnu dot org 2010-07-30 15:12 ---
Yeah, that's what I did. I if (0)ed the newly added code block to produce
comparisons, but I haven't found anything yet that looks wrong in the dumps
(and I can't read PA assembly very well). So it would be useful
For the following code:
void baz (unsigned);
extern unsigned buf[];
struct A
{
unsigned a1:10;
unsigned a2:3;
unsigned:19;
};
union TMP
{
struct A a;
unsigned int b;
};
static unsigned
foo (struct A *p)
{
union TMP t;
struct A x;
x = *p;
t.a = x;
return t.b;
}
void
bar (u
--- Comment #9 from burnus at gcc dot gnu dot org 2010-07-30 15:11 ---
I can also reproduce it with -m32 and x86-64. The dump looks OK; if one uses a
debugger, one sees that in inquire_via_unit:
u->last_record == 0 - instead of the expect "5".
but u->flags.access == ACCESS_DIRECT as e
--- Comment #53 from dave at hiauly1 dot hia dot nrc dot ca 2010-07-30
15:09 ---
Subject: Re: [4.6 regression] Revision 162270 failed
to bootstrap
On Thu, 29 Jul 2010, bernds at gcc dot gnu dot org wrote:
> --- Comment #51 from bernds at gcc dot gnu dot org 2010-07-29 19
--- Comment #5 from hjl dot tools at gmail dot com 2010-07-30 14:48 ---
In fact, revision 162688 gave:
FAIL: c-c++-common/uninit-17.c (test for warnings, line 12)
FAIL: c-c++-common/uninit-17.c (test for warnings, line 14)
FAIL: c-c++-common/uninit-17.c (test for excess errors)
FAIL:
--- Comment #3 from redi at gcc dot gnu dot org 2010-07-30 14:39 ---
On second thoughts, concurrent calls to future::get are also undefined, so
simply asserting valid() would be better. I'll do that asap.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45133
--- Comment #5 from jakub at gcc dot gnu dot org 2010-07-30 14:37 ---
Subject: Bug 45137
Author: jakub
Date: Fri Jul 30 14:36:56 2010
New Revision: 162714
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162714
Log:
PR debug/45055
PR rtl-optimization/45137
--- Comment #3 from jakub at gcc dot gnu dot org 2010-07-30 14:37 ---
Subject: Bug 45055
Author: jakub
Date: Fri Jul 30 14:36:56 2010
New Revision: 162714
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162714
Log:
PR debug/45055
PR rtl-optimization/45137
--- Comment #2 from redi at gcc dot gnu dot org 2010-07-30 14:30 ---
(In reply to comment #0)
>
> I would assume the result of doing a get() when !valid() is undefined,
No need to assume, it's stated explicitly in the FCD.
> so
> throwing an exception when someone does this would be c
--- Comment #7 from bergner at gcc dot gnu dot org 2010-07-30 14:24 ---
Trunk is fixed for powerpc64-linux too.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45134
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-07-30 14:24 ---
Created an attachment (id=21360)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21360&action=view)
required patch
Together with attached patch (from the vector-enhancement GSoC project).
#define vector(elcount
--- Comment #1 from rth at gcc dot gnu dot org 2010-07-30 14:17 ---
Test case?
--
rth at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2010-07-30 14:10
---
Mine
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassi
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2010-07-30 14:06
---
#7 confirms my suspicions. I will try to have a look into this in the next few
days. If anyone else has time, please do.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45131
--- Comment #15 from johnfb at mail dot utexas dot edu 2010-07-30 14:00
---
We have also had some trouble with this issue. We found that in general if we
where running on a machine with hardware threads (i.e., Intel's
Hyper-Threading) then performance was poor. Most of our runs where on
--- Comment #7 from aleksazr at gmail dot com 2010-07-30 14:00 ---
Poor listings = listings without debug info.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45127
--- Comment #6 from aleksazr at gmail dot com 2010-07-30 13:56 ---
Anyway, the files can be used to generate poor listings,
and that is also a bug. See method2.lss
--
aleksazr at gmail dot com changed:
What|Removed |Added
--
The following is valid according to the F2008 FDIS, but it does not make sense
and is invalid according the the first rounds of interpretation for F08/0030.
gfortran currently ends in an endless loop for the example:
print 20
20 format ( *('a') )
end
As it is a constraint, one needs to diag
--- Comment #4 from kkojima at gcc dot gnu dot org 2010-07-30 12:54 ---
I've confirmed that gcc46-pr45055.patch solves this PR too.
Thanks!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45137
--- Comment #15 from mikael at gcc dot gnu dot org 2010-07-30 12:05 ---
The symtree allocated at decl.c:7811
/* Insert it and set attributes. */
if (!stree)
{
stree = gfc_new_symtree (&ns->tb_sym_root, name);
gcc_assert (stree);
}
has t
--- Comment #3 from jakub at gcc dot gnu dot org 2010-07-30 11:59 ---
I agree, and after all, we had one of those two functions already, just private
to combine.c.
See the patch in PR45055.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45137
--- Comment #2 from jakub at gcc dot gnu dot org 2010-07-30 11:57 ---
Created an attachment (id=21359)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21359&action=view)
gcc46-pr45055.patch
So far untested fix.
--
jakub at gcc dot gnu dot org changed:
What|Remove
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-07-30 11:01 ---
Subject: Bug 45141
Author: rguenth
Date: Fri Jul 30 11:01:22 2010
New Revision: 162709
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162709
Log:
2010-07-30 Richard Guenther
PR middle-end/45141
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-07-30 11:01 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRM
--- Comment #14 from mikael at gcc dot gnu dot org 2010-07-30 11:00 ---
(In reply to comment #13)
> I have a patch.
>
No, I don't.
--
mikael at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #2 from howarth at nitro dot med dot uc dot edu 2010-07-30
10:47 ---
The ICE in lto1 backtraces as...
gdb /sw/lib/gcc4.6/libexec/gcc/x86_64-apple-darwin10.4.0/4.6.0/lto1
(gdb) r -fPIC -feliminate-unused-debug-symbols -quiet -dumpdir ./ -dumpbase
cns_solve-1007222053.exe.
t.c:24:1: error: could not split insn
(insn:TI 20 47 43 (set (mem/c:V4SI (reg/f:DI 7 sp) [3 %sfp+-64 S16 A128])
(vec_merge:V4SI (vec_duplicate:V4SI (reg:SI 0 ax))
(mem/c:V4SI (reg/f:DI 7 sp) [3 %sfp+-64 S16 A128])
(const_int 1 [0x1]))) t.c:16 1424 {*vec_setv4si_0_sse
--- Comment #1 from howarth at nitro dot med dot uc dot edu 2010-07-30
10:43 ---
Created an attachment (id=21358)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21358&action=view)
reduced testcase of lto1 crash when linking cns_solve.
--
http://gcc.gnu.org/bugzilla/show_bug.cg
Current gcc trunk (but not gcc 4.5.1) ICEs when linking cns_solve using -O2
-fwhopr -fwholeprogram. The reduced test case is attached and crashes as...
[MacPro:~/badlinkdir2] howarth% more README
[MacPro:~/badlinkdir2] howarth% gfortran -c -fdefault-integer-8 -w -O2 -fwhopr
-fwhole-program --save-
--- Comment #13 from mikael at gcc dot gnu dot org 2010-07-30 10:23 ---
I have a patch.
--
mikael at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|j
--- Comment #6 from dominiq at lps dot ens dot fr 2010-07-30 09:58 ---
Revision 162697 fixes this pr on powerpc-apple-darwin9. If there is no
objection in the coming 12 hours from other ppc platforms, I'll close the pr as
fixed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45134
--- Comment #2 from jakub at gcc dot gnu dot org 2010-07-30 09:48 ---
This is likely dup of PR45136. Again, NOTE_INSN_DELETED moved just with -g and
kept where it was with -g0.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
-
--
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=45134
--
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=45137
--- Comment #5 from jakub at gcc dot gnu dot org 2010-07-30 09:40 ---
Confirmed, this seems to be sched1 fault.
In bb5 we have 2 normal insns, followed by (-g only) a debug_insn, followed by
two NOTE_INSN_DELETED created by combine (do we ever remove these from the
IL?),
followed again (
--- Comment #1 from janus at gcc dot gnu dot org 2010-07-30 09:38 ---
*** This bug has been marked as a duplicate of 44584 ***
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #12 from janus at gcc dot gnu dot org 2010-07-30 09:38 ---
*** Bug 45140 has been marked as a duplicate of this bug. ***
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #7 from ramana at gcc dot gnu dot org 2010-07-30 09:37 ---
*** Bug 45138 has been marked as a duplicate of this bug. ***
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #1 from ramana at gcc dot gnu dot org 2010-07-30 09:37 ---
*** This bug has been marked as a duplicate of 45067 ***
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from rguenth at gcc dot gnu dot org 2010-07-30 09:32 ---
I see the same with -m32 on x86_64. Interestingly I see it with -O0
and libgfortran from 4.5 as well, so it looks like a frontend problem, not
a library problem to me.
--
rguenth at gcc dot gnu dot org changed:
--- Comment #1 from paolo dot carlini at oracle dot com 2010-07-30 09:32
---
It is, and it's well known.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--
--- Comment #7 from rguenth at gcc dot gnu dot org 2010-07-30 09:22 ---
It can't be the same bug, please open a new one. Thx.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
$ valgrind ~/gcc-build/gcc/f951 -O -std=f2003 typebound_proc_15.f03
==22333== Memcheck, a memory error detector
==22333== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==22333== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info
==22333== Command: /home/uros/gcc-bu
--- Comment #16 from burnus at gcc dot gnu dot org 2010-07-30 09:03 ---
Remove assignment. I think I won't work on this in the next weeks and "New" is
better in allowing others to pick it up. If not, I will look at it again later.
The patch of attachment 20714 plus the fix in comment 1
--- Comment #6 from jakub at gcc dot gnu dot org 2010-07-30 08:55 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #5 from rguenther at suse dot de 2010-07-30 08:41 ---
Subject: Re: No prefetch for the vectorized
loop
On Thu, 29 Jul 2010, changpeng dot fang at amd dot com wrote:
> --- Comment #4 from changpeng dot fang at amd dot com 2010-07-29 19:14
> ---
> (In reply to com
Hopefully this isn't standard defined behavior, because it doesn't make much
sense.
// trying to have some overloaded functions to share some private data:
class A {
private:
// some static stuff
// ...
public:
A(int a, int b = 0) {}
// more versions of A(...)
// ...
};
int
r162396 OK
r162497 KO
/home/guerby/build/./prev-gcc/xgcc -B/home/guerby/build/./prev-gcc/
-B/n/57/guerby/install-trunk-162696/armv5tel-unknown-linux-gnueabi/bin/
-B/n/57/guerby/install-trunk-162696/armv5tel-unknown-linux-gnueabi/bin/
-B/n/57/guerby/install-t\
runk-162696/armv5tel-unknown-linux-gnu
--- Comment #3 from burnus at gcc dot gnu dot org 2010-07-30 07:02 ---
(In reply to comment #2)
> > it prints the following output:
> > ifc: ( 1.000, 0.000) ( 2.000, 0.000) (
> > 3.000, 0.000)
> > ap
> > Segmentation fault
If one c
85 matches
Mail list logo
