--- Comment #1 from jakub at gcc dot gnu dot org 2010-04-17 06:55 ---
You should make the struct packed, because otherwise you are accessing it
unaligned.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43774
--- Comment #19 from manu at gcc dot gnu dot org 2010-04-17 07:59 ---
(In reply to comment #18)
The output with my patch is
wa.C:2:38: error: template instantiation depth exceeds maximum of 1024 (use
-ftemplate-depth= to increase the maximum) instantiating �struct
--- Comment #6 from wang-xi05 at mails dot thu dot edu dot cn 2010-04-17
08:07 ---
(In reply to comment #5)
(In reply to comment #4)
Change the severity to normal.
It appears you have more than 1 version of mpfr install
and you're picking up the wrong library. I suspect that
--- Comment #2 from dirtysalt1987 at gmail dot com 2010-04-17 08:11 ---
(In reply to comment #1)
You should make the struct packed, because otherwise you are accessing it
unaligned.
I think the main problem coming from that GCC replace the 'strlen' function
with the following code.
hi,
recent 4.5/4.6 compilers reject code that works with 4.3/4.4.
this is probably some parser regression.
--
Summary: g++ parser rejects valid code.
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
--- Comment #1 from pluto at agmk dot net 2010-04-17 08:51 ---
Created an attachment (id=20405)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20405action=view)
testcase.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43775
--- Comment #2 from pluto at agmk dot net 2010-04-17 08:53 ---
just try to compile it with 'g++ -c'. it ends with:
(...)
0.ii:128606:39: instantiated from here
0.ii:121745:12: error: no type named 'proto_tag' in 'struct
boost::proto::_child_c0'
0.ii:121749:9: error: no type named
here's a small testcase that shows cpu hog in 4.5.
for bigger files, the hog is much bigger :(
$ time g++43 1.ii -c -O1 -g2
g++43 1.ii -c -O1 -g2 11,25s user 0,20s system 99% cpu 11,474 total
$ time g++44 1.ii -c -O1 -g2
g++44 1.ii -c -O1 -g2 8,53s user 0,25s system 99% cpu 8,795 total
$ time
--- Comment #1 from pluto at agmk dot net 2010-04-17 09:11 ---
Created an attachment (id=20406)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20406action=view)
testcase.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43776
--- Comment #3 from dirtysalt1987 at gmail dot com 2010-04-17 09:45 ---
(In reply to comment #1)
You should make the struct packed, because otherwise you are accessing it
unaligned.
If I recompile it with -O0, the assembly code call 'strlen' function.And I use
Valgrind to run
--- Comment #4 from schwab at linux-m68k dot org 2010-04-17 09:49 ---
The compiler can assume that *x is correctly aligned, so this is not a bug.
--
schwab at linux-m68k dot org changed:
What|Removed |Added
--- Comment #16 from iains at gcc dot gnu dot org 2010-04-17 10:17 ---
Created an attachment (id=20407)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20407action=view)
alter deprecation tests to eliminate duplicate warnings.
There are actually several constructs that have
--- Comment #5 from dirtysalt1987 at gmail dot com 2010-04-17 10:28 ---
(In reply to comment #1)
You should make the struct packed, because otherwise you are accessing it
unaligned.
3ku for your reply.Your reply is much more useful than Axxx's reply.3ku very
much:).
--
The files for GMP, MPFR and MPC in ftp://gcc.gnu.org/pub/gcc/infrastructure are
not gpg-signed. Since these files are required to build gcc, it would be
prudent to add them.
MPFR and GMP have signatures at their upstream sites which could be added.
MPC is not currently distributed with
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-04-17 11:03 ---
$ gcc-4.5 -Wlogical-op t.c -S -B.
t.c: In function 'main':
t.c:11:4: warning: logical 'and' of mutually exclusive tests is always false
confirmed. It should warn ... is always true.
--
rguenth at gcc dot gnu
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-04-17 11:07 ---
-Wcoverage-mismatch isn't designed to cover this kind of errors. Are there
source changes for the profile-use stage compared to the profile-generate
stage?
--
rguenth at gcc dot gnu dot org changed:
--- Comment #7 from rguenth at gcc dot gnu dot org 2010-04-17 11:11 ---
We now have basic-block vectorization but it still works on memory accesses
(visible on the gimple level) only. So it doesn't handle
add1 (ss1 a, ss1 b)
{
float D.3164;
float D.3163;
float b$imag;
float
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||rejects-valid
Target Milestone|--- |4.5.1
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-04-17 11:16 ---
That's the usual KDE var-tracking issue. Do we still have a PR open to mark
this as a dup of?
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
As I read the documentation for the attribute, warnings should be issued when a
deprecated entity is used and not when that deprecation is declared.
Thus, as I read it, the following lines should not result in a warning until
the entities they declare are used:
(Lines marked as bogus).
This is
--- Comment #1 from iains at gcc dot gnu dot org 2010-04-17 12:19 ---
It seems that
/* { dg-warning } */
Is eating all lines where occurs together with the line on which the
warning is declared.
Otherwise, we'd get an excess errors (which would be perfectly fine as a way
--- Comment #2 from manu at gcc dot gnu dot org 2010-04-17 12:56 ---
The reason is the regexp that dejagnu uses to match the output
/usr/share/dejagnu/dg.exp
# Remove all error messages for the line [lindex $i 0]
# in the source file. If we find any, success!
set line
--- Comment #1 from iains at gcc dot gnu dot org 2010-04-17 13:16 ---
similarly.
it would seem that:
typedef int INT1 __attribute__((deprecated));
struct __attribute__((deprecated)) s_rec {
int x;
INT1 y ; /* { dg-bogus 'INT1' is deprecated } */
} ;
or
struct s_rec {
int x;
--- Comment #2 from pluto at agmk dot net 2010-04-17 13:58 ---
ok, i've tested the boost-1.42.0 libs with the application and
different compiler configuration (4.3/4.4/4.5) and now i'm sure
that libboost-thread.a is broken by 4.4/4.5. i'll dump gcc trees
from that library and compare
--- Comment #67 from t dot artem at mailcity dot com 2010-04-17 14:28
---
Am I right assuming that GCC 4.5 is also affected by this bug? Is this bug
going to be resolved?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838
--- Comment #3 from hjl dot tools at gmail dot com 2010-04-17 14:30 ---
It is caused by revision 153958:
http://gcc.gnu.org/ml/gcc-cvs/2009-11/msg00176.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #9 from jvdelisle at gcc dot gnu dot org 2010-04-17 14:57
---
No longer ICE, closing. The warning is adequate for this situation.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from ubizjak at gmail dot com 2010-04-17 15:11 ---
(In reply to comment #3)
Works with x86-64.
Checking -m32, the same thing happens with or without the patch:
This happens because combine pulls memory references into the combined address
operand. Since
--- Comment #4 from ramana at gcc dot gnu dot org 2010-04-17 15:32 ---
I think this should now be fixed by
http://gcc.gnu.org/viewcvs?root=gccview=revrev=158378
Carrot , can you confirm you are happy with the code generated on trunk now ?
cheers
Ramana
--
ramana at gcc dot gnu
--- Comment #6 from rearnsha at gcc dot gnu dot org 2010-04-17 17:15
---
I can't see how it would hurt to allow combine to always merge insns that are
known to be consecutive (ie to ignore CLASS_LIKELY_SPILLED_P if
prev_nonenote_insn(consumer) == producer).
--
--- Comment #2 from P at draigBrady dot com 2010-04-17 17:40 ---
Well the warning should at least change.
However the logical operation itself is not an issue,
so I think a warning should not be issued at all.
I.E. if TOP and BOT are defined as a narrower range
then we don't get a
In gcc/cp/typecheck.c there is this construction:
error_at (input_location, too many arguments to %s %q#D,
called_thing, fndecl);
and an analogous message for too few arguments. Called_thing is a string like
function or constructor. But this string is not available for
--- Comment #11 from kargl at gcc dot gnu dot org 2010-04-17 21:06 ---
Subject: Bug 31538
Author: kargl
Date: Sat Apr 17 21:05:53 2010
New Revision: 158474
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158474
Log:
2010-04-17 Steven G. Kargl ka...@gcc.gnu.org
PR
--- Comment #12 from kargl at gcc dot gnu dot org 2010-04-17 22:12 ---
Fixed on 4.5 branch and trunk.
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #13 from kargl at gcc dot gnu dot org 2010-04-17 22:22 ---
Subject: Bug 31538
Author: kargl
Date: Sat Apr 17 22:22:02 2010
New Revision: 158476
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158476
Log:
2010-04-17 Steven G. Kargl ka...@gcc.gnu.org
PR
gcc 4.5 in c++0x mode rejects the following valid code:
std::vectorint vec;
decltype(vec)::value_type v = vec.first();
Per the DR above, decltype can be used with the :: operator.
This is similar to a bug report that someone posted for version 3.1, but my
experience is with 4.5.
--
[reg...@gamow tmp405]$ current-gcc -c -O2 small.c
small.c: In function 'int32func':
small.c:26:1: error: definition in block 8 follows the use
for SSA_NAME: g_313.0_6 in statement:
# VUSE .MEM_22
g_313.8_12 = *g_313.0_6;
small.c:26:1: internal compiler error: verify_ssa failed
Please submit a full
Between gcc-4.5-20090903 (correct) and gcc-4.5-20091008 (wrong), a
bug was introduced in the expansion of _asm__() directives on AMD64.
The bug has been reproduced also in gcc-4.5-20100107 and yesterday's
first release of gcc-4.6-20100416. Here is test program, with leading
comments that reflect
38 matches
Mail list logo
