--- Comment #2 from pinskia at gcc dot gnu dot org 2010-05-18 06:31 ---
*** Bug 44187 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44186
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-05-18 06:31 ---
*** This bug has been marked as a duplicate of 44186 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from ethouris at gmail dot com 2010-05-18 07:14 ---
No matter which entity is actually affected in the example above, 'foo' is a
type of field used inside the entity. In all these cases, deprecation warning
should not be reported for the field of type 'foo'. It should be
--- Comment #1 from hjl dot tools at gmail dot com 2010-05-18 07:29 ---
In general, with inlining, not a huge deal, although it can still
occur when functons are short-circuited. For certain applicatons
that are built with PIC, the IP-thunk, at the very least, should
be padded since
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2010-05-18 07:41
---
I need the preprocessed file. Thanks in advance.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |steven at gcc dot gnu dot
|dot org
--- Comment #4 from segher at gcc dot gnu dot org 2010-05-18 08:26 ---
Confirmed with current 4.4 branch and mainline.
-mabi=nospe -mno=spe doesn't make the problem go away; only
changing -mcpu does.
--
segher at gcc dot gnu dot org changed:
What|Removed
--- Comment #17 from iains at gcc dot gnu dot org 2010-05-18 09:09 ---
Created an attachment (id=20693)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20693action=view)
latest version
a few more tweaks.
with this emutls is working for lto/whopr
OMP is still broken and so will be
--- Comment #3 from paolo dot carlini at oracle dot com 2010-05-18 09:25
---
Note however, that both the warning and the miscompilation do not happen with
current 4_5-branch and mainline...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44186
typedef struct
{
int i;
} AAA;
typedef struct BBB
{
int i;
} BBB;
int main(void) {
BBB bb;
AAA aa;
return 0;
}
produces
3a2: Abbrev Number: 9 (DW_TAG_variable)
a3 DW_AT_name: bb
a6 DW_AT_decl_file : 1
a7
--- Comment #27 from jakub at gcc dot gnu dot org 2010-05-18 09:36 ---
Subject: Bug 41371
Author: jakub
Date: Tue May 18 09:35:52 2010
New Revision: 159528
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159528
Log:
PR debug/41371
* var-tracking.c
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-05-18 09:53 ---
(In reply to comment #3)
Note however, that both the warning and the miscompilation do not happen with
current 4_5-branch and mainline...
Which is because we see the must-alias and punt. After all this just
--
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=44185
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-05-18 10:04 ---
Confirmed. Assembly with 4.4 is equal -g vs. -g0 and different starting with
4.5.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
GCC build triplet|x86_64-pc-linux-gnu |
GCC host triplet|x86_64-pc-linux-gnu |
GCC target
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44174
--- Comment #5 from paolo dot carlini at oracle dot com 2010-05-18 10:08
---
Ok ;)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44186
--- Comment #28 from siarhei dot siamashka at gmail dot com 2010-05-18
10:09 ---
Thanks, this patch fixes bootstrap for powerpc/powerpc64. But still fails for
arm on all the same gcc_assert() in another place. Should a new bug be filed
about this?
--
--- Comment #16 from fxcoudert at gcc dot gnu dot org 2010-05-18 10:28
---
Confirmed on gcc version 4.5.1 20100506 (prerelease).
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2010-05-18 10:35
---
Doesn't happen for me with the 4.5 branch. (I don't have a current trunk
compiler to compare with.)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43821
--- Comment #9 from sfilippone at uniroma2 dot it 2010-05-18 10:41 ---
(In reply to comment #8)
(In reply to comment #7)
Btw, after the recent patch for PR43969, this might well be fixed already ...
Unfortunately, no, I still get the ICE.
--
--- Comment #29 from jakub at gcc dot gnu dot org 2010-05-18 10:58 ---
Please file a new PR for that, with preprocessed source and all other relevant
info for reproduction.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42347
--- Comment #3 from jakub at gcc dot gnu dot org 2010-05-18 11:26 ---
The differences start during inlining.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44182
SVN revision: 159525
Configure line: ../gcc-svn/configure --prefix=/tmp/gcc-cross/gcc-svn-bin/
--target=arm-linux-gnueabi
--with-headers=/tmp/gcc-cross/gcc-svn-bin/arm-linux-gnueabi/include
--with-libs=/tmp/gcc-cross/gcc-svn-bin/arm-linux-gnueabi/lib/
--enable-threads=posix --enable-shared
--- Comment #3 from ro at gcc dot gnu dot org 2010-05-18 11:55 ---
Created an attachment (id=20694)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20694action=view)
preprocessed source code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44101
--- Comment #10 from janus at gcc dot gnu dot org 2010-05-18 12:19 ---
(In reply to comment #9)
Btw, after the recent patch for PR43969, this might well be fixed already
...
Unfortunately, no, I still get the ICE.
Sure. Actually my comment was only targeted towards Tobias'
--- Comment #11 from burnus at gcc dot gnu dot org 2010-05-18 12:24 ---
(In reply to comment #8)
If one adds b = ALLOCATED(x) one finds:
Where do you add this?
Add in bug14 of attachment 20491 before 'end subroutine':
logical b
b = allocated(a%a)
However, this is now fixed.
*
--- Comment #3 from iains at gcc dot gnu dot org 2010-05-18 12:30 ---
it still fails for me on ppc and i686 4.6.0 r159518 and 159528 resp.
gcc version 4.5.1 20100518 (prerelease) [gcc-4_5-branch revision 159528] (GCC)
apollo:gcc-4-5-branch-build $ ./gcc/xgcc -B gcc -g -feliminate
--- Comment #4 from jakub at gcc dot gnu dot org 2010-05-18 13:04 ---
I guess this is related to the EH rewrite in 4.5.
In particular, when building cfg for f2 in make_blocks on
(gdb) p debug_gimple_stmt (stmt)
S::f3 (this, D.2140);
(gdb) p stmt_can_throw_internal (stmt)
$47 = 0 '\000'
--- Comment #1 from steven at gcc dot gnu dot org 2010-05-18 13:52 ---
Subject: Bug 44184
Author: steven
Date: Tue May 18 13:51:50 2010
New Revision: 159531
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159531
Log:
gcc/
PR lto/44184
* lto-streamer-out.c
--- Comment #2 from steven at gcc dot gnu dot org 2010-05-18 14:07 ---
Subject: Bug 44184
Author: steven
Date: Tue May 18 14:06:31 2010
New Revision: 159532
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159532
Log:
gcc/
PR lto/44184
* lto-streamer-out.c
--- Comment #3 from steven at gcc dot gnu dot org 2010-05-18 14:08 ---
Fixed for GCC 4.5.1 and later.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from ktietz at gcc dot gnu dot org 2010-05-18 14:22 ---
(In reply to comment #10)
Re-opening. It turns out that GCC fails to actually apply the dllexport
attribute to TLS control vars. So solving the binutils problem allows
auto-export of a TLS variable to work, but
--- Comment #12 from davek at gcc dot gnu dot org 2010-05-18 14:29 ---
(In reply to comment #11)
I have doubts about the approach in winnt.c, but well maybe I am wrong here. I
investigated for this issue and see the real issue in declaration cloning in
varasm.c's emutls_decl-
--- Comment #13 from davek at gcc dot gnu dot org 2010-05-18 14:33 ---
(In reply to comment #12)
TARGET_EMUTLS_VAR_INIT
Nah, scratch that, it's not really sensible.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44139
--- Comment #10 from rguenth at gcc dot gnu dot org 2010-05-18 14:58
---
(In reply to comment #9)
But the standard says in [basic.types] that For any trivially copyable type
T,
if two pointers to T point to distinct T objects obj1 and obj2, where neither
obj1 nor obj2 is a
--
dje at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #11 from rguenth at gcc dot gnu dot org 2010-05-18 15:00
---
(In reply to comment #10)
(In reply to comment #9)
But the standard says in [basic.types] that For any trivially copyable
type T,
if two pointers to T point to distinct T objects obj1 and obj2, where
--- Comment #12 from rguenth at gcc dot gnu dot org 2010-05-18 15:02
---
Making this a C++ frontend bug. The only way to avoid expanding the copy
to a loop is by using memcpy which will then run into PR42834.
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--- Comment #7 from rguenth at gcc dot gnu dot org 2010-05-18 15:11 ---
Subject: Bug 44143
Author: rguenth
Date: Tue May 18 15:11:01 2010
New Revision: 159536
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159536
Log:
2010-05-18 Richard Guenther rguent...@suse.de
PR
--- Comment #8 from rguenth at gcc dot gnu dot org 2010-05-18 15:11 ---
Fixed again.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #14 from ktietz at gcc dot gnu dot org 2010-05-18 15:18 ---
Hi Dave,
following patch solves the issue for me pretty well.
ChangeLog
* varasm.c (emutls_decl): Clone attributes for new decl.
Index: gcc/gcc/varasm.c
--- Comment #15 from davek at gcc dot gnu dot org 2010-05-18 15:26 ---
(In reply to comment #14)
Hi Dave,
following patch solves the issue for me pretty well.
That looks good to me to, although doing it in the middle-end makes me worry
that some other target might /not/ be
--- Comment #18 from iains at gcc dot gnu dot org 2010-05-18 15:55 ---
(In reply to comment #17)
Created an attachment (id=20693)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20693action=view) [edit]
latest version
a few more tweaks.
with this emutls is working for lto/whopr
--- Comment #16 from dominiq at lps dot ens dot fr 2010-05-18 16:28 ---
You may be interested by pr 44132.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44139
--- Comment #19 from dominiq at lps dot ens dot fr 2010-05-18 16:55 ---
This PR may have an overlap with pr44139.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44132
--
ccoutant at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |ccoutant at gcc dot gnu dot
|dot org
--- Comment #1 from vmakarov at redhat dot com 2010-05-18 19:06 ---
It will be fixed by IRA without cover classes which I am working on. The code
is planned to be included in gcc4.6.
For older versions, it should be fixed in reload because I believe it is a
hidden reload bug.
--
--- Comment #1 from gergely+gccbug at risko dot hu 2010-05-18 19:17 ---
Added wrong-debug as a keyword.
--
gergely+gccbug at risko dot hu changed:
What|Removed |Added
--- Comment #2 from ro at gcc dot gnu dot org 2010-05-18 19:39 ---
This happens on i386-pc-solaris2.11, too, but only with -flto and -fwhopr.
--
ro at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from changpeng dot fang at amd dot com 2010-05-18 19:39
---
I have a patch to fix the test cases:
http://gcc.gnu.org/ml/gcc-patches/2010-05/msg01359.html
For prefetch-6.c, patch http://gcc.gnu.org/ml/gcc-cvs/2010-05/msg00567.html
applies the insn to prefetch ratio
--- Comment #3 from ro at gcc dot gnu dot org 2010-05-18 19:42 ---
Ian, you've introduced this testcase; could you have a look?
--
ro at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #15 from chris dot litchfield at gmail dot com 2010-05-18
19:48 ---
This is still a huge issue. We would wish to inhibit use of the CURRENT
Working directory to find include files. Basically FORCE every time a new
include file is found with #include to start AGAIN from
--- Comment #4 from iains at gcc dot gnu dot org 2010-05-18 20:04 ---
(In reply to comment #3)
Ian, you've introduced this testcase; could you have a look?
Yes.. working my way through ..
I'm sure that it is problem with ObjC
(and ObjC++, if you apply
--- Comment #13 from pluto at agmk dot net 2010-05-18 20:57 ---
btw. the boost::optional uses char-based storage and cast storage
- void* - some_type* via address() and get_object() methods.
it looks like aliasing violation too.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44164
--- Comment #2 from dfranke at gcc dot gnu dot org 2010-05-18 21:17 ---
If
print *, (foo())
is changed to
print *, foo()
one gets:
$ gfortran-svn pr41859.f90
pr41859.f90:17.19:
print *, foo() ! -- ICE here!
1
Error: Data transfer element at (1) cannot
--- Comment #3 from dfranke at gcc dot gnu dot org 2010-05-18 21:30 ---
Breakpoint 9, resolve_transfer (code=0x8bfed90) at
/home/daniel/svn/gcc-svn/gcc/fortran/resolve.c:7369
(gdb) list
7367 exp = code-expr1;
7368
7369 if (exp-expr_type != EXPR_VARIABLE exp-expr_type !=
--- Comment #4 from vmakarov at redhat dot com 2010-05-18 21:40 ---
Thanks for reporting the problem. The problem has no effect on generated
code whatever initialization is used. The code in question tries to get basic
block for BARRIER which is wrong. Whatever it gets basic block
The assertion in the following testcase should /not/ fail, but does:
#define _GLIBCXX_DEBUG
#define _GLIBCXX_DEBUG_PEDANTIC
#include vector
#include cassert
int main()
{
std::vectorint v;
v.resize(10);
assert(v.size() = v.capacity());
}
--
Summary: Debug
--- Comment #1 from gcc-bugzilla at contacts dot eelis dot net 2010-05-18
21:45 ---
Created an attachment (id=20695)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20695action=view)
Trivial patch that fixes the problem.
The problem was just a missing call to
--
dodji at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dodji at gcc dot gnu dot org
|dot org
--- Comment #13 from burnus at gcc dot gnu dot org 2010-05-18 21:51 ---
Created an attachment (id=20696)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20696action=view)
Fifth draft patch - with test case
New approach. The attached patch now also works with twisted modules (cf.
--- Comment #4 from dfranke at gcc dot gnu dot org 2010-05-18 21:54 ---
Comment #3 is somewhat hard to parse. Once more with this reduced testcase:
TYPE :: ptype
character, pointer, dimension(:) :: x = null()
END TYPE
TYPE(ptype) :: p
print *, (p)! '()' are
--- Comment #5 from vmakarov at gcc dot gnu dot org 2010-05-18 22:09
---
Subject: Bug 43332
Author: vmakarov
Date: Tue May 18 22:09:19 2010
New Revision: 159545
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159545
Log:
2010-05-18 Vladimir Makarov vmaka...@redhat.com
--- Comment #2 from dfranke at gcc dot gnu dot org 2010-05-18 22:09 ---
Reduced testcase:
type t
real :: a(3)
end type t
contains
function func(x)
type(t), target :: x(:)
real, dimension(:), pointer :: func
func = x%a(1)
end function func
end
--
dfranke at
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #3 from dfranke at gcc dot gnu dot org 2010-05-18 22:22 ---
Roughly the same testcase, same backtrace.
*** This bug has been marked as a duplicate of 34640 ***
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #14 from dfranke at gcc dot gnu dot org 2010-05-18 22:22
---
*** Bug 42851 has been marked as a duplicate of this bug. ***
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from zsojka at seznam dot cz 2010-05-18 22:22 ---
Thank you for fixing this. I hope to rebuild gcc with valgrind checking in few
days again.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43332
--- Comment #11 from dfranke at gcc dot gnu dot org 2010-05-18 22:26
---
As commented multiple times in PR34640, given the similarity of the testcase,
the identical backtrace and the same assignee ...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38471
--- Comment #12 from dfranke at gcc dot gnu dot org 2010-05-18 22:28
---
(In reply to comment #11)
As commented multiple times in PR34640, given the similarity of the testcase,
the identical backtrace and the same assignee ...
*** This bug has been marked as a duplicate of 34640
--- Comment #15 from dfranke at gcc dot gnu dot org 2010-05-18 22:28
---
*** Bug 38471 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34640
--- Comment #16 from dfranke at gcc dot gnu dot org 2010-05-18 22:30
---
The dupes PR38471 and PR42851 have more testcases, the former an equally
lengthy discussion as this PR.
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
Hey,
while working on a low-prio PR24024, I recognized that the -E output of
gcc-4.5.0 is somehow broken for certain constructs, for example:
test.c
int main ()
{
int ret, a;
ret = a + \
b;
}
END test.c
(gcc-4.5.0) # gcc -E test.c
# 1 test.c
# 1 built-in
# 1
--- Comment #18 from dfranke at gcc dot gnu dot org 2010-05-18 22:36
---
(In reply to comment #17)
Fixed on the trunk (4.6). Planned to be committed also to GCC 4.5.1.
Patch was applied to trunk about 6 weeks ago - how are the backporting plans?
--
--- Comment #7 from dfranke at gcc dot gnu dot org 2010-05-18 22:38 ---
Paul, is there anything left to do here or can this PR be closed?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43266
--- Comment #17 from dannysmith at users dot sourceforge dot net
2010-05-18 22:43 ---
(In reply to comment #14)
Index: gcc/gcc/varasm.c
===
--- gcc.orig/gcc/varasm.c 2010-05-18 13:19:20.0 +0200
+++
--- Comment #4 from dfranke at gcc dot gnu dot org 2010-05-18 22:44 ---
(In reply to comment #2)
OK for trunk with the usual embellishments of ChangeLogs and testcase?
Yes, if you have an example for EXPR_FUNCTION - otherwise I would claim that
EXPR_VARIABLE is enough.
Paul, any
--- Comment #1 from jakub at gcc dot gnu dot org 2010-05-18 22:44 ---
That's just incorrect assumption.
The reason why the first alternative is now preferred is to provide proper
locus for the b token.
--
jakub at gcc dot gnu dot org changed:
What|Removed
--- Comment #4 from pinskia at gcc dot gnu dot org 2010-05-18 22:46 ---
Well I don't think we should cause an infinite loop on any input. Note Comeau
C++ also causes an infinite loop.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from paolo dot carlini at oracle dot com 2010-05-18 23:36
---
I'm going to apply the patch: could you please provide name and family name for
the ChangeLog entry? Thanks!
--
paolo dot carlini at oracle dot com changed:
What|Removed
--- Comment #3 from gcc-bugzilla at contacts dot eelis dot net 2010-05-18
23:38 ---
(In reply to comment #2)
I'm going to apply the patch
Great, thanks! :)
could you please provide name and family name for
the ChangeLog entry?
It's Eelis van der Weegen
--
--- Comment #4 from paolo at gcc dot gnu dot org 2010-05-18 23:59 ---
Subject: Bug 44190
Author: paolo
Date: Tue May 18 23:58:50 2010
New Revision: 159549
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159549
Log:
2010-05-18 Eelis van der Weegen gcc-bugzi...@contacts.eelis.net
--- Comment #5 from paolo dot carlini at oracle dot com 2010-05-19 00:00
---
Fixed.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
On Linux, revision gave 159549:
../../src-trunk/gcc/fortran/trans-expr.c: In function
'gfc_conv_procedure_call':
../../src-trunk/gcc/fortran/trans-expr.c:3344:3: error: implicit declaration of
function 'build_call_list' [-Werror=implicit-function-declaration]
Starting with version 4.0 G++ fails to accept this testcase:
bool f(int i) { return i != 5; }
template class X, class P = bool(X)
struct Traits
{
typedef P type;
};
template class X, class P = typename TraitsX::type
struct S
{
const P p_;
S( const P p ) : p_(p) {} // const reference
};
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Last
--- Comment #9 from pault at gcc dot gnu dot org 2010-05-19 04:28 ---
Fixed. Thanks, Joost!
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from pault at gcc dot gnu dot org 2010-05-19 04:32 ---
Fixed. Thanks, Tobias.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
Test case:
--
#include stdint.h
struct twoints { uint64_t a, b; } foo();
void bar(uint64_t a, uint64_t b);
void func() {
struct twoints s = foo();
bar(s.a, s.b);
}
--
$ gcc -save-temps -Wall -c -o testbad.o -msse2 -O3 -fomit-frame-pointer
testbad.c
$ objdump -d -r -M intel testbad.o
--- Comment #1 from hjl dot tools at gmail dot com 2010-05-19 05:42 ---
Fixed as of revision 159555.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2010-05-19 05:47
---
I have a patch testing.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
92 matches
Mail list logo
