--- 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
-
--- 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 #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 #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
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 #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
--- 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 #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 #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 #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 #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
--
--
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 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
#!/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 #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://
--- 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 #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
--
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
CC||rguenth at gcc dot gnu dot
|
--- 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
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 #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
--- 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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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
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 #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
--- 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 #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
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 #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
--- 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 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 #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
--
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 #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
--- 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
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 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
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||rejects-valid
Summary|Can't declare an extern "C" |[4.5 Re
-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
--- 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
$ 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 #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
--- 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 #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
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 #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
--- 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 #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 #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 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
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 #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
--- 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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 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 #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|
81 matches
Mail list logo
