--- Comment #24 from ubizjak at gmail dot com 2010-05-19 06:47 ---
Can you try this patch:
Index: configure.ac
===
--- configure.ac(revision 159481)
+++ configure.ac(working copy)
@@ -3254,9 +3254,10 @@
On Linux/ia64,gcc.dg/lto/20100518 c_lto_20100518_0.o failed
with
Executing on host: /export/gnu/import/svn/gcc-test/bld/gcc/xgcc
-B/export/gnu/import/svn/gcc-test/bld/gcc/ -O0 -fwhopr -c -o
c_lto_20100518_0.o
/export/gnu/import/svn/gcc-test/src-4.5/gcc/testsuite/gcc.dg/lto/20100518_0.c
--- 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
--- 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
Test case:
--
#include
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
testbad.o:
--- 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
--- 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
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Last reco
Starting with version 4.0 G++ fails to accept this testcase:
bool f(int i) { return i != 5; }
template
struct Traits
{
typedef P type;
};
template ::type>
struct S
{
const P& p_;
S( const P& p ) : p_(p) {} // const reference
};
template
S make_s(const typename Traits::type & p) // const re
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]
../../src-trunk/gcc/fortran/trans-expr
--- 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
Statu
--- 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=gcc&view=rev&rev=159549
Log:
2010-05-18 Eelis van der Weegen
PR libstdc++/44190
--- 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"
--
http://gcc.gnu.
--- 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 #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 #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 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,
--- 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
> +++ gcc
--- 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 #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?
--
http://gcc.gnu.org/bugzilla/sh
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 ""
# 1 ""
# 1 "test
--- 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
---
--- 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 #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 #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 #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 #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 #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
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last re
--- 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 g
--- 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=gcc&view=rev&rev=159545
Log:
2010-05-18 Vladimir Makarov
PR rtl-optimizatio
--- 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 signific
--- 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=20696&action=view)
Fifth draft patch - with test case
New approach. The attached patch now also works with twisted modules (cf. te
--
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 #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=20695&action=view)
Trivial patch that fixes the problem.
The problem was just a missing call to _M_update_guaranteed_
The assertion in the following testcase should /not/ fail, but does:
#define _GLIBCXX_DEBUG
#define _GLIBCXX_DEBUG_PEDANTIC
#include
#include
int main()
{
std::vector v;
v.resize(10);
assert(v.size() <= v.capacity());
}
--
Summary: Debug vector resize do
--- 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 f
--- 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 !=
E
--- 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 ha
--- 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=4416
--- 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
http://gcc.gnu.org/ml/gcc-patche
--- 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 the
--- 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 #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 heuris
--- 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 #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 #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.
--
--
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 #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
--- 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 #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=20693&action=view) [edit]
> latest version
>
> a few more tweaks.
> with this emutls is working for lto
--- 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 expect
--- 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 #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
Status|ASS
--- 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=gcc&view=rev&rev=159536
Log:
2010-05-18 Richard Guenther
PR lto/44143
--- 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 #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, wher
--
dje at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed
--- 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 bas
--- 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 #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- func
--- 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, b
--- 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 #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=gcc&view=rev&rev=159532
Log:
gcc/
PR lto/44184
* lto-streamer-out.c (output_
--- 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=gcc&view=rev&rev=159531
Log:
gcc/
PR lto/44184
* lto-streamer-out.c (output_
--- 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 #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 #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 #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 Tobia
--- 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=20694&action=view)
preprocessed source code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44101
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 --enabl
--- 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
--- 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 #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.
--
http://gcc.gnu.org/bugzilla/sh
--- 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 #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 #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?
--
http://gcc.gnu.org/bugzilla/sho
--- 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
--
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
--
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 triplet|
--- 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
--
--
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 #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
inv
--- 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=gcc&view=rev&rev=159528
Log:
PR debug/41371
* var-tracking.c (find_loc_in_1pd
typedef struct
{
int i;
} AAA;
typedef struct BBB
{
int i;
} BBB;
int main(void) {
BBB bb;
AAA aa;
return 0;
}
produces
<3>: Abbrev Number: 9 (DW_TAG_variable)
DW_AT_name: bb
DW_AT_decl_file : 1
DW_AT_decl_li
--- 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
--- 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=20693&action=view)
latest version
a few more tweaks.
with this emutls is working for lto/whopr
OMP is still broken and so will be t
--- 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
--
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 #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
--
--- 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 it's
--- 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 r
92 matches
Mail list logo
