--- 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=gccview=revrev=150615
Log:
2009-08-10 Dodji Seketeli do...@redhat.com
gcc/ChangeLog:
--- 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
--- 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 al...@redhat.com
Manuel López-Ibáñez m...@gcc.gnu.org
PR 40435
... builtins.c ... Add location argument
--- 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=gccview=revrev=150617
Log:
2009-08-10 Vincent Celier cel...@adacore.com
PR
--- 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
--- 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.
--
--- 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
--- 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=gccview=revrev=150620
Log:
2009-08-10 Janus Weil ja...@gcc.gnu.org
PR
--- 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=gccview=revrev=150621
Log:
2009-08-10 Richard Guenther rguent...@suse.de
PR
--- 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=revrevision=142628 to 4.3
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
--- 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=18335action=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
--- 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=gccview=revrev=150622
Log:
2009-08-10 Daniel Kraft d...@domob.eu
PR fortran/37425
--- 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
--- 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
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
--- 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 statements
--- 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
$ 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
--- 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
--- Comment #2 from janus at gcc dot gnu dot org 2009-08-10 12:46 ---
Confirmed. -fdump-tree-original shows:
assign_proc_ptr (void (*T63) (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
--- 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
--- 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
--- 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
--- 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
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;
--- 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 errors
--- 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
--- 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_ofstreamchar::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=18336action=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:
--- 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
--- 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=gccview=revrev=150626
Log:
PR target/37053
* reload1.c
--- 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
--- 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
--- 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
--- 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=gccview=revrev=129764
Log:
PR tree-optimization/32893
* tree-vectorize.c (vect_can_force_dr_alignment_p): Check
STACK_BOUNDARY
--- 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=gccview=revrev=150631
Log:
2009-08-10 Andreas Tobler a.tob...@schweiz.org
--- 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=gccview=revrev=150632
Log:
2009-08-10 Andreas Tobler a.tob...@schweiz.org
--- 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
--- 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
--- 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.am
--- 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
--- 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
--- 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 fails
--- 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=18337action=view)
patch fixing hpux differences
This patch squashes in the following too. It is a stupid used-uninitialized
bug that was
--- 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]
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: RTL check
--- 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=gccview=revrev=150635
Log:
PR target/41015
* longlong.h [__sh__]
--
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,
--- 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.
--
#!/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
--- 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=18338action=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)
+++
--- 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
+++
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
--- 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=18339action=view)
Preprocessed ecvtbuf.c from months-old newlib
Compile with -O2 to reproduce ICE.
--
--- 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
--- 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).
80 matches
Mail list logo
