--- Comment #4 from pinskia at gcc dot gnu dot org 2010-04-18 06:49 ---
How do we know if this is valid code or not?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43775
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-04-18 06:48 ---
Yes your experience is with 4.5.0 but there is no reason to file a new bug
about a known issue. I don't know if the C++ defect report 743 have been voted
on yet or not (if not then PR 6709 is suspended because we do
--- Comment #14 from pinskia at gcc dot gnu dot org 2010-04-18 06:48
---
*** Bug 43780 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-04-18 06:45 ---
Oh I forgot to mention, sqrt will use sqrtsd and will be inlined so you don't
need to use inline-asm yourself.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43782
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-04-18 06:44 ---
You have the wrong inline-asm:
sqrtsd %0, %1
That is wrong because with AT&T style x86 asm, the src is first and the dest is
second.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
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 i
[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 ful
gcc 4.5 in c++0x mode rejects the following valid code:
std::vector 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.
--
S
--- 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=gcc&view=rev&rev=158476
Log:
2010-04-17 Steven G. Kargl
PR fortran/31538
* gfortran
--- 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 #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=gcc&view=rev&rev=158474
Log:
2010-04-17 Steven G. Kargl
PR fortran/31538
* gfortran
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 #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 warni
--- 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).
--
http://gcc.gnu.org/bu
--- 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=gcc&view=rev&rev=158378
Carrot , can you confirm you are happy with the code generated on trunk now ?
cheers
Ramana
--
ramana at gcc dot gn
--- 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 ix86_decomp
--- 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 #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 #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 #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 res
--- 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 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 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 wa
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 no
--- 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
--
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||rejects-valid
Target Milestone|--- |4.5.1
--- 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 b$r
--- 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 #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
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 signature
--- 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:).
--
http:
--- 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=20407&action=view)
alter deprecation tests to eliminate duplicate warnings.
There are actually several constructs that have duplica
--- 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 #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 it,
--- 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=20406&action=view)
testcase.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43776
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 #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_c<0>'
0.ii:121749:9: error: no type named 'p
--- 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=20405&action=view)
testcase.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43775
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 #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
--- 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 t
--- 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
> X<-0x0
42 matches
Mail list logo
