--- Comment #17 from jakub at gcc dot gnu dot org 2010-06-14 06:59 ---
Created an attachment (id=20906)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20906&action=view)
gcc46-pr44509.patch
Untested patch.
--
jakub at gcc dot gnu dot org changed:
What|Removed
--- Comment #7 from ian at gcc dot gnu dot org 2010-06-14 06:57 ---
Subject: Bug 43365
Author: ian
Date: Mon Jun 14 06:57:36 2010
New Revision: 160704
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160704
Log:
Avoid crash when exception landing pad becomes unreachable.
Bring ov
When building a clean GCC 4.5.0 targeting sh-elf, the multilib configuration of
the compiler does not appear to work at all. For instance, building GCC 4.5.0
with the following set of configure flags:
../gcc-4.5.0/configure --target=sh-elf --prefix=/usr/local/dc2/sh-elf
--with-newlib --enable-lang
--- Comment #3 from Daniel dot Davies at xerox dot com 2010-06-14 02:49
---
Thank You! Adding the -fwrapv flag fixed the problem.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44530
--- Comment #4 from zsojka at seznam dot cz 2010-06-14 01:25 ---
I am not sure if that's related, but the testcase fails with -O
-funsafe-loop-optimizations in r160687/x86_64-linux:
$ /mnt/svn/gcc-trunk/binary-160687-lto-fortran-checking-yes-rtl/bin/gcc -O1
-funsafe-loop-optimizations p
--- Comment #2 from pinskia at gmail dot com 2010-06-13 21:58 ---
Subject: Re: New: wrong code due to branch optimization
Sent from my iPhone
On Jun 13, 2010, at 2:34 PM, "Daniel dot Davies at xerox dot com"
wrote:
> When compiled with -03, the attached file prints out an error
Sent from my iPhone
On Jun 13, 2010, at 2:34 PM, "Daniel dot Davies at xerox dot com" > wrote:
When compiled with -03, the attached file prints out an error
message due to
incorrectly comparing "xCount + 32 < 0x8000". When compiled
with the
default optimization, it prints out the co
--- Comment #1 from janus at gcc dot gnu dot org 2010-06-13 21:38 ---
(In reply to comment #0)
> First example:
>
>
> integer, allocatable :: a(:), b(:)
> allocate (a, source = b)
> end
>
>
> This is rejected with
>
> allocate (a, source = b)
> 1
> Error: Array specificati
--- Comment #1 from Daniel dot Davies at xerox dot com 2010-06-13 21:35
---
Created an attachment (id=20905)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20905&action=view)
Preprocessed source file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44530
When compiled with -03, the attached file prints out an error message due to
incorrectly comparing "xCount + 32 < 0x8000". When compiled with the
default optimization, it prints out the correct message.
$ gcc -v -save-temps -std=gnu99 -fno-strict-aliasing -funroll-loops
-march=core2 -mfpmath=
First example:
integer, allocatable :: a(:), b(:)
allocate (a, source = b)
end
This is rejected with
allocate (a, source = b)
1
Error: Array specification required in ALLOCATE statement at (1)
although it is valid (cf. F08:C633).
Second example:
integer, allocatable :: a(:)
int
--- Comment #4 from manu at gcc dot gnu dot org 2010-06-13 19:33 ---
Perhaps, but the location should be at the end of the expression, where most
programmers would put the ';'. Then, mentioning '}', which may be in a totally
different line with a lot comments in between, would be confusi
--- Comment #3 from joseph at codesourcery dot com 2010-06-13 18:25 ---
Subject: Re: improve message for missing ";"
Perhaps "between expression and '}' token" would be more precise.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44515
--- Comment #14 from paolo dot carlini at oracle dot com 2010-06-13 17:53
---
*** Bug 44528 has been marked as a duplicate of this bug. ***
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
---
--- Comment #1 from paolo dot carlini at oracle dot com 2010-06-13 17:53
---
*** This bug has been marked as a duplicate of 42101 ***
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
---
--- Comment #10 from mikpe at it dot uu dot se 2010-06-13 17:42 ---
Created an attachment (id=20904)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20904&action=view)
correction to encode-3.mm
The powerpc64 failure in encode-3.mm was also caused by a plain char mangling
difference.
when executing the command g++ bug_report.cc , i get the output:
/tmp/ccM7O0pr.o: In function `A::init()':
bug_report.cc:(.text._ZN1A4initEv[A::init()]+0x6): undefined reference to
`A::i'
collect2: ld returned 1 exit status
here is the output of the command ld -v
GNU ld (GNU Binutils for Debian
--- Comment #2 from manu at gcc dot gnu dot org 2010-06-13 17:33 ---
(In reply to comment #1)
> Actually before is more correct than saying after bar(). Because expressions
> don't need to end on the same line.
I wonder why people tend to write:
bar();
rather than
;}
Obviously the
--- Comment #6 from manu at gcc dot gnu dot org 2010-06-13 17:30 ---
This column information:
t.c:2:11: note: generated from here
__asm__ ("frob%0" : "+r" (X));
^
I am not going to get into a reopen war with you anyway. I am just trying to
make a list of the diagnostic i
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44524
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-06-13 17:25 ---
Actually before is more correct than saying after bar(). Because expressions
don't need to end on the same line.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from iains at gcc dot gnu dot org 2010-06-13 17:20 ---
(In reply to comment #8)
> On ARM encode-2.mm fails in part for the same "plain char mangles differently"
> reason as on powerpc64, but also due to a backend oddity. Here's how the
> string is output in the assembly f
--- Comment #5 from pinskia at gcc dot gnu dot org 2010-06-13 17:18 ---
>The column information is wrong.
What column information :).
>The diagnostic markers are inconsistent (Error versus error).
Report that to the binutils project.
>This depends on the gnu assembler, which is not t
--- Comment #8 from mikpe at it dot uu dot se 2010-06-13 17:15 ---
On ARM encode-2.mm fails in part for the same "plain char mangles differently"
reason as on powerpc64, but also due to a backend oddity. Here's how the
string is output in the assembly file on ARM:
.ascii "{?={
--- Comment #14 from redi at gcc dot gnu dot org 2010-06-13 17:14 ---
(In reply to comment #12)
> Why not make -Wconversion an error, at least this would
> be consistent ;-)
You can use -Werror=conversion
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44500
--- Comment #7 from iains at gcc dot gnu dot org 2010-06-13 17:07 ---
(In reply to comment #5)
> Created an attachment (id=20903)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20903&action=view) [edit]
> correction to encode-2.mm
>
> On powerpc64 encode-2.mm fails because the test
--- Comment #6 from iains at gcc dot gnu dot org 2010-06-13 17:04 ---
(In reply to comment #4)
> (In reply to comment #3)
> > powerpc*-darwin9 passes and, apparently, *86*-linux-gnu (I checked Lu's
> > output)
>
> I've scanned the gcc-testresults list archive for May and June quite
> c
--- Comment #4 from manu at gcc dot gnu dot org 2010-06-13 16:59 ---
The column information is wrong.
The diagnostic markers are inconsistent (Error versus error).
This depends on the gnu assembler, which is not the default in many places.
--
manu at gcc dot gnu dot org changed:
.c (main): Output include of insn-constants.h
* Makefile.in (insn-enums.o): Depend on insn-constants.h.
gcc/c-family:
PR bootstrap/44512
* c-cppbuiltin.c (builtin_define_with_hex_fp_value): Add cast
for C++ standard compliance.
Modified:
branches/multi-target-
--- Comment #5 from mikpe at it dot uu dot se 2010-06-13 16:49 ---
Created an attachment (id=20903)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20903&action=view)
correction to encode-2.mm
On powerpc64 encode-2.mm fails because the test case scans the assembly output
for the str
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-06-13 16:49 ---
Now with Apple's as we get the weird error message you pointed out but that is
because apple's as does not support the change in line info we output:
# 2 "t.c" 1
frob%eax
# 0 "" 2
--
pinskia at gcc do
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-06-13 16:47 ---
GNU assembler (GNU Binutils for Debian) 2.18.0.20080103
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44527
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-06-13 16:47 ---
Hmm, with a newer binutils we get a better error message:
t.c: Assembler messages:
t.c:2: Error: no such instruction: `frob %eax'
--
pinskia at gcc dot gnu dot org changed:
What|Removed
Testcase:
int foo(int X) {
__asm__ ("frob%0" : "+r" (X));
return X;
}
gcc-4.6:
/var/folders/51/51Qw875vFdGa9KojoIi7Zk+++TM/-Tmp-//ccyXfgfZ.s:11:no such
instruction: `frob %eax'
clang:
:1:2: error: unrecognized instruction
frob%eax
^
t.c:2:11: note: generated from here
--- Comment #4 from mikpe at it dot uu dot se 2010-06-13 16:42 ---
(In reply to comment #3)
> powerpc*-darwin9 passes and, apparently, *86*-linux-gnu (I checked Lu's
> output)
I've scanned the gcc-testresults list archive for May and June quite carefully,
and I don't think anyone is tes
--- Comment #8 from dfranke at gcc dot gnu dot org 2010-06-13 16:09 ---
Makefile dependency generation is now available in trunk (-cpp -MD).
See PR44526 for a follow-up request to libcpp.
Closing.
--
dfranke at gcc dot gnu dot org changed:
What|Removed
--- Comment #16 from dfranke at gcc dot gnu dot org 2010-06-13 16:07
---
Fixed in trunk. See PR44526 for a follow-up request for libcpp.
Closing.
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--
Since r160684 gfortran supports generation of Makefile dependencies via libcpp.
In the example below, foo.mod is a target as it is generated from the .f90
file, but also a dependency as it used in the same source file:
$ cat foo.f90
MODULE foo
END MODULE
USE foo
END
$ gfortran-svn -cpp -M foo.f9
--- Comment #7 from dfranke at gcc dot gnu dot org 2010-06-13 16:05 ---
Subject: Bug 43954
Author: dfranke
Date: Sun Jun 13 16:05:01 2010
New Revision: 160684
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160684
Log:
2010-06-13 Daniel Franke
PR fortran/31588
--- Comment #15 from dfranke at gcc dot gnu dot org 2010-06-13 16:05
---
Subject: Bug 31588
Author: dfranke
Date: Sun Jun 13 16:05:01 2010
New Revision: 160684
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160684
Log:
2010-06-13 Daniel Franke
PR fortran/31588
When executing the profiling tests (e.g. gcc.dg/matrix/matrix.exp) on a remote
machine, the test run assumes that the directory structure is the same on the
remote target machine as it is on the host machine.
The path structure assumption is made based on the working directory during the
build of
--- Comment #3 from iains at gcc dot gnu dot org 2010-06-13 15:31 ---
(In reply to comment #1)
> Ian - testsuite regressions are not acceptable on the branch (XPASSes are ok
> though).
Well, of course, the patch did not cause any regressions on targets I have
access to.
These now XPASS.
--- Comment #2 from iains at gcc dot gnu dot org 2010-06-13 15:26 ---
Subject: Bug 44518
Author: iains
Date: Sun Jun 13 15:26:22 2010
New Revision: 160682
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160682
Log:
partial reversion of r160541.
PR testsuite/44518
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-06-13 14:20 ---
Ian - testsuite regressions are not acceptable on the branch (XPASSes are ok
though).
Please restore the previous state by at least re-instantiating the XFAIL on the
branch.
Thanks.
--
rguenth at gcc dot gnu do
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-06-13 14:18 ---
(In reply to comment #2)
> (In reply to comment #1)
> >
> > instead. So the warning you see is really warning about no return
> > statement,
> > not about control reaching the end of a non-void function. And it d
Testcase:
#include
int bar(std::map *X) {
return X.empty();
}
gcc-4.6:
/home/manuel/test/src/gcc/testsuite/g++.dg/warn/clang-11.C: In function 'int
bar(std::map*)':^M
/home/manuel/test/src/gcc/testsuite/g++.dg/warn/clang-11.C:4:12: error: request
for member 'empty' in 'X', which is of non-cl
Testcase:
namespace x {
struct a { };
}
template
class foo {
};
foo a1;
foo a2;
x::a a3 = a2;
gcc-4.6:
clang-10.C:10:8: error: template argument 1 is invalid
clang-10.C:10:12: error: invalid type in declaration before ; token
clang-10.C:12:11: error: conversion from int to non-scalar t
Testcase:
namespace x {
struct a { };
}
x:a a2;
x::a a3 = a2;
gcc-4.6:
clang-9.C:5:1: error: x does not name a type
clang-9.C:6:11: error: a2 was not declared in this scope
clang:
t.cc:5:2: error: unexpected ':' in nested name specifier
x:a a2;
^
::
"In addition to getting the error
--- Comment #2 from manu at gcc dot gnu dot org 2010-06-13 13:49 ---
(In reply to comment #1)
>
> instead. So the warning you see is really warning about no return statement,
> not about control reaching the end of a non-void function. And it does so
> by design just for functions wit
Testcase:
struct B1 { void f(); };
struct B2 { void f(double); };
struct I1 : B1 { };
struct I2 : B1 { };
struct D: I1, I2, B2 {
void g() {
f();
}
};
gcc-4.6:
clang-8.C:9:5: error: reference to f is ambiguous
clang-8.C:2:18: error: candidates are: void B2::f(double)
clang-8.C:1:18:
Testcase:
struct B1 { void f(); };
struct B2 { void f(double); };
struct I1 : B1 { };
struct I2 : B1 { };
struct D: I1, I2, B2 {
using B1::f; using B2::f;
void g() {
f();
}
};
gcc-4.6:
clang-7.C:10:7: error: B1 is an ambiguous base of D
clang:
t.cc:10:5: error: ambiguous conv
Testcase:
struct foo { int x; }
typedef int bar;
gcc-4.6:
clang-6.c:3:9: error: two or more data types in declaration specifiers
Notice the line and the column are far away from the problem.
clang:
t.c:1:22: error: expected ';' after struct
struct foo { int x; }
^
On 4_5-branch, the objc++ encode-2.mm and encode-3.mm tests started to fail
recently on several platforms:
FAIL: obj-c++.dg/encode-2.mm scan-assembler
{?={Vec=ddi}{Vec=ffi}fd{Vec=cci}i}
FAIL: obj-c++.dg/encode-3.mm -fgnu-runtime execution test
Compare e.g.
http://gcc.gnu.org/ml/gcc-testresults/2
Testcase:
int foo(int x, pid_t y) {
return x+y;
}
gcc-4.6:
clang-5.c:1:16: error: expected declaration specifiers or ... before pid_t
foo
clang-5.c: In function foo:
clang-5.c:2:12: error: y undeclared (first use in this function)
clang-5.c:2:12: note: each undeclared identifier is re
Testcase:
namespace services {
struct WebService { };
}
namespace myapp {
namespace servers {
struct Server { };
}
}
using namespace myapp;
void addHTTPService(servers::Server const &server, ::services::WebService const
*http) {
server += http;
}
gcc-4.6:
clang-4.C:12:13: error: n
--- Comment #10 from manu at gcc dot gnu dot org 2010-06-13 12:46 ---
I don't care as long as there is a testcase that tests for this bug. Bugs
shouldn't be closed if a testcase has not been committed that prevents
regressing.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16630
Testcase:
void bar(void);
void foo(void)
{
bar()
}
gcc-4.6:
clang-3.c:7:1: error: expected ; before } token
clang:
t.c:4:8: error: expected ';' after expression
bar()
^
;
--
Summary: improve message for missing ";"
Product: gcc
V
Testcase:
template
class a {}
class temp {};
a b;
struct b {
}
gcc-4.6:
clang-2.C:3:15: error: multiple types in one declaration
clang-2.C:4:7: error: non-template type a used as a template
clang-2.C:4:10: error: invalid type in declaration before ; token
clang-2.C:6:1: error: expected unq
Testcase:
/* { dg-do compile } */
/* { dg-options "-std=iso9899:1990 -pedantic -Wformat" } */
#include "format.h"
void
foo (int i)
{
printf ("%d%d", i);
}
gcc-4.6:
/home/manuel/test/src/gcc/testsuite/gcc.dg/format/clang-1.c: In function 'foo':
/home/manuel/test/src/gcc/testsuite/gcc.dg/forma
--- Comment #3 from rsandifo at gcc dot gnu dot org 2010-06-13 12:29
---
Created an attachment (id=20902)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20902&action=view)
Patch for unspec{,v}_strings definition
One fix would be to make insn-enums.c include insn-constants.h,
but I
--- Comment #8 from rguenth at gcc dot gnu dot org 2010-06-13 12:25 ---
(In reply to comment #7)
> (In reply to comment #6)
> > (In reply to comment #5)
> > > The bug is in creation of a neutral value for BIT_AND_EXPR. What is the
> > > correct
> > > way to create it for all types? I fo
--- Comment #1 from paolo dot carlini at oracle dot com 2010-06-13 12:12
---
First, note that the *extractor*, ie, read, is slower, not the inserter. That
said, I think it's not at all obvious that read must be faster than the pointer
extractor, because in the latter case the parsing it
/libcpp.a
../libdecnumber/libdecnumber.a ../libcpp/libcpp.a ../libiberty/libiberty.a
../libdecnumber/libdecnumber.a -lcloog -lppl_c -lppl -lgmpxx -lmpc -lmpfr
-lgmp -rdynamic -ldl -L../zlib -lz -lelf
libbackend.a(print-rtl.o): In function `print_rtx':
/user/inria/fsf/bldxx-20100613-2/gcc/../../gc
--- Comment #7 from irar at il dot ibm dot com 2010-06-13 12:01 ---
(In reply to comment #6)
> (In reply to comment #5)
> > The bug is in creation of a neutral value for BIT_AND_EXPR. What is the
> > correct
> > way to create it for all types? I found
> > double-int.h:#define ALL_ONES
--- Comment #16 from dominiq at lps dot ens dot fr 2010-06-13 11:47 ---
See also pr44512.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44509
--- Comment #1 from dominiq at lps dot ens dot fr 2010-06-13 11:46 ---
Could it be a duplicate of pr44509?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44512
./move-if-change tmp-attrtab.c insn-attrtab.c
echo timestamp > s-attrtab
rm gcov.pod gfdl.pod cpp.pod fsf-funding.pod gcc.pod
make[3]: Leaving directory `/user/inria/fsf/bldxx-20100613/gcc'
make[2]: *** [all-stage1-gcc] Error 2
make[2]: Leaving directory `/user/inria/fsf/bldxx-20100613'
mak
--- Comment #15 from iains at gcc dot gnu dot org 2010-06-13 11:35 ---
powerpc64-darwin9;
failed in stage3:
In file included from /usr/include/math.h:26:0,
from /GCC/gcc-live-trunk/gcc/genautomata.c:117:
/usr/include/architecture/ppc/math.h: In function â__inline_isno
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-06-13 11:35 ---
(In reply to comment #5)
> The bug is in creation of a neutral value for BIT_AND_EXPR. What is the
> correct
> way to create it for all types? I found
> double-int.h:#define ALL_ONES (~((unsigned HOST_WIDE_INT) 0))
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-06-13 10:33 ---
It's because
/* Complain if there's just no return statement. */
if (warn_return_type
...
/* Normally, with -Wreturn-type, flow will complain, but we might
optimize out static functions. */
--- Comment #5 from irar at il dot ibm dot com 2010-06-13 10:29 ---
The bug is in creation of a neutral value for BIT_AND_EXPR. What is the correct
way to create it for all types? I found
double-int.h:#define ALL_ONES (~((unsigned HOST_WIDE_INT) 0))
but it won't work for signed.
Thanks
--- Comment #2 from dominiq at lps dot ens dot fr 2010-06-13 09:52 ---
Confirmed on x86_64-apple-darwin10.3.0.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44505
GCC 4.5 -Wall warns if your function has a non-void return type but
returns. It can also detect an infinite loop which means that
"falling off the end" doesn't actually imply a return, and therefore
suppress the warning in that case.
However, if the function is static, this infinite loop detectio
--- Comment #8 from ubizjak at gmail dot com 2010-06-13 08:54 ---
Fixed.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #7 from uros at gcc dot gnu dot org 2010-06-13 08:52 ---
Subject: Bug 44481
Author: uros
Date: Sun Jun 13 08:51:51 2010
New Revision: 160672
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160672
Log:
PR target/44481
* config/i386/i386.md (UNSPEC_PARIT
75 matches
Mail list logo
