--- Comment #2 from steven at gcc dot gnu dot org 2009-08-10 07:16 ---
SRA expert -> CC
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #5 from dodji at gcc dot gnu dot org 2009-08-10 07:16 ---
Subject: Bug 40866
Author: dodji
Date: Mon Aug 10 07:16:08 2009
New Revision: 150615
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150615
Log:
2009-08-10 Dodji Seketeli
gcc/ChangeLog:
PR c++/40866
--- Comment #6 from dodji at gcc dot gnu dot org 2009-08-10 07:17 ---
Fixed in 4.5
--
dodji at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNE
--- Comment #5 from laurent at guerby dot net 2009-08-10 08:01 ---
The search is not finished but it's likely the following patch:
2009-07-17 Aldy Hernandez
Manuel López-Ibáñez
PR 40435
... builtins.c ... Add location argument to ...
The ICE happens here:
b
--- Comment #5 from ubizjak at gmail dot com 2009-08-10 08:05 ---
(In reply to comment #4)
> If you want to change it to be consistent with the documentation (not with
> existing implementation) and pass structures always on stack, I wouldn't
> object
> against it. Just don't change it
--- Comment #6 from ubizjak at gmail dot com 2009-08-10 08:06 ---
Adding H.J. to CC.
--
ubizjak at gmail dot com changed:
What|Removed |Added
CC|
--- Comment #2 from charlet at gcc dot gnu dot org 2009-08-10 08:25 ---
Subject: Bug 17566
Author: charlet
Date: Mon Aug 10 08:25:05 2009
New Revision: 150617
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150617
Log:
2009-08-10 Vincent Celier
PR ada/17566
*
--- Comment #3 from charlet at gcc dot gnu dot org 2009-08-10 08:27 ---
Should now be fixed
--
charlet at gcc dot gnu dot org changed:
What|Removed |Added
Sta
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-08-10 09:07 ---
There is only one struct copy, so it isn't SRAs business to optimize anything
here. Instead the burden is put on expand and the backend to figure out the
most efficient way to do this block copy.
--
http://gcc.
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-08-10 09:10 ---
*expr_p = targetm.gimplify_va_arg_expr (valist, type, pre_p, post_p);
SET_EXPR_LOCATION (*expr_p, loc);
is simply bogus. You can't expect *expr_p being still an expression tree
when you throw the gimpli
--- Comment #1 from janus at gcc dot gnu dot org 2009-08-10 09:19 ---
Subject: Bug 40940
Author: janus
Date: Mon Aug 10 09:19:24 2009
New Revision: 150620
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150620
Log:
2009-08-10 Janus Weil
PR fortran/40940
* decl
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-08-10 09:23 ---
Subject: Bug 41006
Author: rguenth
Date: Mon Aug 10 09:22:47 2009
New Revision: 150621
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150621
Log:
2009-08-10 Richard Guenther
PR middle-end/41006
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-08-10 09:23 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #9 from dodji at gcc dot gnu dot org 2009-08-10 10:09 ---
Okay,I have adjusted the regression markers.
I won't apply the patch to 4.3 for now though.
To apply this patch to 4.3, one would need to backport the patch
http://gcc.gnu.org/viewcvs?view=rev&revision=142628 to 4.3 f
It seems that not a pointer is transferred but a value in the following case.
Here is the tracking info:
gfortran -g fptr_transfer.f90 -o fptr_transfer && ./fptr_transfer
Segmentation fault (core dumped)gdb fptr_transfer core
[...]
Program terminated with signal 11, Segmentation fault.
#0 0x0
--- Comment #1 from reuter at physik dot uni-freiburg dot de 2009-08-10
10:12 ---
Created an attachment (id=18335)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18335&action=view)
Example file which shows the PP problem
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41022
--- Comment #2 from jwakely dot gcc at gmail dot com 2009-08-10 10:40
---
Apart from the semi-colon after the extern "C" block the code is valid and this
is a recent regression on trunk.
--
jwakely dot gcc at gmail dot com changed:
What|Removed |A
--- Comment #1 from domob at gcc dot gnu dot org 2009-08-10 10:52 ---
Subject: Bug 37425
Author: domob
Date: Mon Aug 10 10:51:46 2009
New Revision: 150622
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150622
Log:
2009-08-10 Daniel Kraft
PR fortran/37425
* gf
--- Comment #1 from domob at gcc dot gnu dot org 2009-08-10 10:57 ---
After Janus' recent check-in of CLASS parsing, this behaviour is fixed (though
CLASS is not really polymorphic).
I'm not sure if we should close this or keep open until CLASS is fully
implemented. Janus, feel free to
--- Comment #2 from domob at gcc dot gnu dot org 2009-08-10 11:08 ---
After the check-in now, type-bound operators are parsed/checked correctly, but
can not be called for now. I'll work on that as a follow-up patch.
This means that the test-case given in the report works, but of course
When defining an OPERATOR(...) for intrinsic operators or ASSIGNMENT(=), the
interface of the provided procedure must match certain characteristics (like
one or two dummy arguments, being a FUNCTION/SUBROUTINE, respectively, and so
on).
For a wrong interface, gfortran correctly prints an error mes
--- Comment #1 from domob at gcc dot gnu dot org 2009-08-10 11:18 ---
The same holds for type-bound operators, see for instance
gcc/testsuite/gfortran.dg/typebound_operator_2.f03 for the current
"inconsistent" locations.
But as the checking code is mainly shared, a fix will probably do
--- Comment #2 from jwakely dot gcc at gmail dot com 2009-08-10 11:34
---
(In reply to comment #0)
> To my mind statement
> test.cpp: In constructor 'testclass::testclass()':
> test.cpp:4: error: class 'testclass' does not have any field named 'number'
> is redundant because stateme
--- Comment #3 from jwakely dot gcc at gmail dot com 2009-08-10 11:35
---
(In reply to comment #2)
> Note that if you put the declaration of 'int number;' first then Comeau has a
> very similar error to GCC's when the member function is first - it complains
> about the invalid member in
$ gcc -v -o test.exe test.c
Es werden eingebaute Spezifikationen verwendet.
Ziel: x86_64-w64-mingw32
Konfiguriert mit: ../../../../src/gcc-4.5.0/configure
--prefix=/mingw/gcc/gcc-4.5.0/x86_64-w64-mingw32/mingw
--with-sysroot=/mingw/gcc/gcc-4.5.0/x86_64-w64-mingw32/mingw
--with-gmp=/mingw/gcc/gcc-4.
--- Comment #1 from jwakely dot gcc at gmail dot com 2009-08-10 12:26
---
Does libstdc++-v3/src/fstream-inst.cc get compiled in C++0x mode? If not, then
the C++0x-only symbols would not be instantiated in the library
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41005
-ftracer on various gcc versions sometimes gives "is already defined" error on
build. Was on glibc (x86_*) & linux kernel (x86_64), but now git-kernel build
good and I not going deep. Only glibc 2.10.1 log tail:
===
[...]
i686-pc-linux-gnu-gcc ../sysdeps/unix/sysv/linux/dl-execstack.c -c -std=gnu99
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||rejects-valid
Summary|Can't declare an extern "C" |[4.5 Re
--- Comment #2 from janus at gcc dot gnu dot org 2009-08-10 12:46 ---
Confirmed. -fdump-tree-original shows:
assign_proc_ptr (void (*) (void) * ptr, struct container_t & obj1)
{
*ptr = obj1->proc;
}
--
janus at gcc dot gnu dot org changed:
What|Removed
gcc --version
gcc (GCC) 4.4.1 20090507 (prerelease)
The following test compiled with
gcc -S -Os
struct struct_t {
int* data;
};
void testAddr (struct struct_t* sp, int len)
{
int i;
for (i = 0; i < len; i++)
{
sp->data[i] = 0;
}
}
generates the following code for x
--- Comment #2 from jwakely dot gcc at gmail dot com 2009-08-10 13:17
---
Since the C++0x changes to fstream are only additions, the simplest solution is
probably to compile src/fstream-inst.cc in c++0x mode, which just means adding
new targets to src/Makefile.am so that -std=gnu++0x is
--- Comment #6 from anitha dot boyapati at atmel dot com 2009-08-10 13:27
---
Confirmed with gcc 4.4.0. Using switch -O0 with avr-gcc 4.4.0 (-mmcu=atmega128)
gave the result 0 while -O1 gave 0xFF
--
anitha dot boyapati at atmel dot com changed:
What|Removed
--
eric dot weddington at atmel dot com changed:
What|Removed |Added
Status|WAITING |NEW
Last reconfirmed|2009-03-18 17:47:31 |2009-08-10
--- Comment #3 from janus at gcc dot gnu dot org 2009-08-10 13:41 ---
Actually the part of the dump shown in comment #2 is ok. The problematic piece
is this:
transfer_proc_ptr (struct container_t & obj2, struct container_t & obj1)
{
[...]
assign_proc_ptr (obj2->proc, (struct contain
--- Comment #4 from janus at gcc dot gnu dot org 2009-08-10 13:49 ---
This problems seems to be similar to PR 40450.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41022
--- Comment #5 from janus at gcc dot gnu dot org 2009-08-10 14:14 ---
This patchlet should fix it:
Index: gcc/fortran/trans-expr.c
===
--- gcc/fortran/trans-expr.c(revision 150621)
+++ gcc/fortran/trans-expr.c(worki
--- Comment #4 from b0ntrict0r at yandex dot ru 2009-08-10 14:16 ---
Thank you for your explanation.
(In reply to comment #2)
> The errors for lines 9 and 15 relate to the duplicate declaration of a member
> with the name 'number', whereas the error on line 4 refers to the invalid
> me
trying to build gcc for arm-eabi with --enable-build-with-cxx fails with
'structure 'key' with uninitialized const members'. However, a normal C-based
bootstrap does not report this as a warning when -Wc++-compat is used.
struct f
{
const int a;
};
void g(struct f*);
void h ()
{
struct f h;
g
--- Comment #5 from jwakely dot gcc at gmail dot com 2009-08-10 14:44
---
(In reply to comment #4)
> Those are seperate errors of course. I've meant that when compiler already
> discovered that there is a conflict between number and number() it looks like
> it's keeping on emitting erro
--- Comment #6 from b0ntrict0r at yandex dot ru 2009-08-10 15:02 ---
I've got your point, thank you. So if
(In reply to comment #5)
> in general it would be
> very difficult for the compiler to determine if individual errors are caused
> by
> an earlier error and suppress them condition
--- Comment #3 from redi at gcc dot gnu dot org 2009-08-10 15:09 ---
For now, the workaround is to provide some or all of these explicit
instantiations in your program:
namespace std
{
template
basic_ofstream::basic_ofstream(string const&, ios_base::openmode);
template
I do a partial specialisation of a class. I havec a compilation error if I
specialize on a typedef which is defined in a template class
--
Summary: Compilation error when a class specialization use a
typedef define in a template class
Product: gcc
--- Comment #1 from maxime dot fiandino at gmail dot com 2009-08-10 15:20
---
Created an attachment (id=18336)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18336&action=view)
simple source with the bug
just use:
g++ main.cc
on 3.46/4.1.1 no error
on 4.4.0/4.4.1
main.cc:30: erro
--- Comment #18 from sje at cup dot hp dot com 2009-08-10 15:33 ---
I tried the pa.c change, it didn't help. I will do a non-bootstrap build with
tests. All my HP-UX machines are behind the HP firewall unfortunately. I see
we have a PA box in the compile farm but I think it is running
--- Comment #19 from uweigand at gcc dot gnu dot org 2009-08-10 15:34
---
Subject: Bug 37053
Author: uweigand
Date: Mon Aug 10 15:34:09 2009
New Revision: 150626
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150626
Log:
PR target/37053
* reload1.c (reload_as_ne
--- Comment #2 from redi at gcc dot gnu dot org 2009-08-10 15:36 ---
The code is invalid: The template parameters T and U cannot be deduced in your
partial specialization, because they occur in a non-deduced context.
According to 14.5.4.1 [temp.class.spec.match] paragraph 2 the templat
--- Comment #3 from davek at gcc dot gnu dot org 2009-08-10 16:17 ---
(In reply to comment #2)
> Apart from the semi-colon after the extern "C" block the code is valid and
> this
> is a recent regression on trunk.
I am fairly sure that a semi-colon after a block statement like that is
--- Comment #4 from jwakely dot gcc at gmail dot com 2009-08-10 17:05
---
It's irrelevant to this bug and is just me being more pedantic than -pedantic,
however ... even with -pedantic GCC has always accepted stray semi-colons at
namespace scope, but it's not valid.
At function scope a
--- Comment #5 from davek at gcc dot gnu dot org 2009-08-10 17:16 ---
(In reply to comment #4)
> It's irrelevant to this bug and is just me being more pedantic than -pedantic,
> however ... even with -pedantic GCC has always accepted stray semi-colons at
> namespace scope, but it's not v
--- Comment #23 from mahatma at eu dot by 2009-08-10 17:48 ---
(In reply to comment #17)
> URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129764
> Log:
> PR tree-optimization/32893
> * tree-vectorize.c (vect_can_force_dr_alignment_p): Check
> STACK_BOUNDAR
--- Comment #1 from andreast at gcc dot gnu dot org 2009-08-10 18:22
---
Subject: Bug 41018
Author: andreast
Date: Mon Aug 10 18:22:22 2009
New Revision: 150631
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150631
Log:
2009-08-10 Andreas Tobler
PR bootstrap/41018
--- Comment #2 from andreast at gcc dot gnu dot org 2009-08-10 18:24
---
Subject: Bug 41018
Author: andreast
Date: Mon Aug 10 18:23:57 2009
New Revision: 150632
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150632
Log:
2009-08-10 Andreas Tobler
PR bootstrap/41018
--- Comment #3 from andreast at gcc dot gnu dot org 2009-08-10 18:25
---
Committed.
--
andreast at gcc dot gnu dot org changed:
What|Removed |Added
Status|AS
--- Comment #19 from sje at cup dot hp dot com 2009-08-10 19:32 ---
Here are the unexpected failures I see when running the testsuite using a
non-bootstrap PA compiler. The compiler I built includes the patch from
comment #17.
FAIL: 22_locale/ctype/narrow/char/2.cc execution test
FAIL:
--- Comment #4 from 3dw4rd at verizon dot net 2009-08-10 19:35 ---
(In reply to comment #2)
> Since the C++0x changes to fstream are only additions, the simplest solution
> is
> probably to compile src/fstream-inst.cc in c++0x mode, which just means adding
> new targets to src/Makefile.
--- Comment #7 from mikulas at artax dot karlin dot mff dot cuni dot cz
2009-08-10 19:36 ---
Worse, try to return these structures with -freg-struct-return and it also
follows this inconsistent pattern, some are returned in EAX:EDX, some are
returned in ST(0).
It is even inconsistent b
--- Comment #5 from jwakely dot gcc at gmail dot com 2009-08-10 19:39
---
The definitions are in that header, but the 'extern template' extension is used
to prevent the compiler from instantiating the code in your program, see
http://gcc.gnu.org/onlinedocs/gcc/Template-Instantiation.htm
--- Comment #6 from jwakely dot gcc at gmail dot com 2009-08-10 20:05
---
(In reply to comment #5)
> Instead of instantiating that code in every object a single explicit
> instantiation is provided in libstdc++.so, that's the purpose of
> src/fstream-inst.cc
... but in this case it fai
--- Comment #20 from bonzini at gnu dot org 2009-08-10 20:09 ---
Created an attachment (id=18337)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18337&action=view)
patch fixing hpux differences
This patch squashes in the following too. It is a stupid used-uninitialized
bug that wa
--- Comment #21 from sje at cup dot hp dot com 2009-08-10 20:18 ---
That seems to have fixed pr39240.c in the testsuite. I will try a complete
bootstrap again.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40952
--- Comment #2 from dominiq at lps dot ens dot fr 2009-08-10 20:54 ---
I think the ifort messages are more helpful:
[ibook-dhum] f90/bug% ifc pr41023.f90
pr41023.f90(14): error #6711: The number of function arguments is inconsistent
with the intrinsic use of the OPERATOR. [MYPLUS]
I
Building sh4-unknown-linux-gnu target with --enable-checking=rtl yields.
gcc version 4.5.0 20090810 (experimental) [trunk revision 150633] (GCC)
../../../libiberty/floatformat.c: In function 'floatformat_from_double':
../../../libiberty/floatformat.c:683:1: internal compiler error:
--- Comment #5 from kkojima at gcc dot gnu dot org 2009-08-10 20:57 ---
Subject: Bug 41015
Author: kkojima
Date: Mon Aug 10 20:57:35 2009
New Revision: 150635
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150635
Log:
PR target/41015
* longlong.h [__sh__] (udiv_q
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
CC||rguenth at gcc dot gnu dot
|
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-08-10 21:15 ---
This is not an aliasing issue rather PRE not running at -Os which is expected.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #2 from steven at gcc dot gnu dot org 2009-08-10 21:29 ---
Hmm, this isn't my day. Of course you're right, Andrew.
So the issue is that a loop invariant load is not hoisted at -Os, because it
does not improve size.
FWIW several patches have been proposed to change this, se
--- Comment #22 from sje at cup dot hp dot com 2009-08-10 21:30 ---
A hppa2.0w-hp-hpux11.11 bootstrap was successful with the v3 patch and running
the broken tests also looks OK now. I will let my normal nightly process do a
full test run tonight on PA but it looks good.
--
http://
#!/bin/bash
cat << EOF > test.cpp
enum class foo : char
{
A,
B
};
int main()
{
foo a = foo::A;
return (a == foo::A) ? 1 : 0;
}
EOF
$ g++-4.4 -std=c++0x test.cpp
test.cpp: In function int main():
test.cpp:11: error: invalid operands of types foo and foo to b
--- Comment #1 from steven at gcc dot gnu dot org 2009-08-10 21:33 ---
Can you attach the preprocessed source, so that we can try to reproduce this
without building a complete cross-toolchain?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41029
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38064
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-08-10 21:37 ---
*** This bug has been marked as a duplicate of 38064 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #10 from pinskia at gcc dot gnu dot org 2009-08-10 21:37
---
*** Bug 41030 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #2 from rmansfield at qnx dot com 2009-08-10 21:40 ---
Created an attachment (id=18338)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18338&action=view)
preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41029
--- Comment #3 from rmansfield at qnx dot com 2009-08-10 22:12 ---
It doesn't appear on gcc 4.3 and 4.4 branches. I'll narrow down when it was
introduced.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41029
--- Comment #7 from laurent at guerby dot net 2009-08-10 22:25 ---
I tested the following patch and it restores --with-cpu=v8 c,ada bootstrap
Index: gcc/builtins.c
===
--- gcc/builtins.c (revision 150589)
+++ gcc/built
--- Comment #4 from kkojima at gcc dot gnu dot org 2009-08-10 23:15 ---
GDB backtrace shows a target problem. I'm testing the patch below.
* config/sh/sh.md (reload_outdf__RnFRm+4): Fix thinko.
--- ORIG/trunk/gcc/config/sh/sh.md 2009-07-06 23:27:44.0 +0900
+++ tru
With revision 150591, cris-elf built.
>From revision 150593 and on, build is broken as follows, compiling newlib:
...
/tmp/hpautotest-gcc1/cris-elf/gccobj/./gcc/xgcc
-B/tmp/hpautotest-gcc1/cris-elf/gccobj/./gcc/ -nostdinc
-B/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/v10/newlib/ -isystem
/tmp/hp
--- Comment #1 from hp at gcc dot gnu dot org 2009-08-11 00:18 ---
Created an attachment (id=18339)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18339&action=view)
Preprocessed ecvtbuf.c from months-old newlib
Compile with -O2 to reproduce ICE.
--
http://gcc.gnu.org/bugzilla
--- Comment #2 from hp at gcc dot gnu dot org 2009-08-11 01:02 ---
I had a brief look. Seems like the new code assumes that promote_mode always
promotes the input mode (ahem! :) when mismatching, which it only does if the
target defines PROMOTE_MODE (which CRIS does not; it just has a
T
--- Comment #6 from mattst88 at gmail dot com 2009-08-11 02:38 ---
To show how worthwhile this trivial patch is -- the following table shows the
number of times s{4,8}{add,sub}l are used in building the Linux kernel
(2.6.31-rc5) with unpatched and patched gcc (4.3.4).
un
--- Comment #7 from ubizjak at gmail dot com 2009-08-11 06:46 ---
(In reply to comment #6)
> Please add to gcc-4.3.x and gcc-4.4.x.
OK, I will post the patch, thanks for the analysis.
--
ubizjak at gmail dot com changed:
What|Removed |Added
-
81 matches
Mail list logo
