--- Comment #1 from ramana at gcc dot gnu dot org 2009-09-16 06:48 ---
This is a forum to report bugs on existing releases of GCC or the current
development version. Queries regarding porting GCC should be taken on
g...@gcc.gnu.org.
In this case you might find it useful to look at
--- Comment #1 from ramana at gcc dot gnu dot org 2009-09-16 07:08 ---
The problem occurs with 4.4.x branch r 151319. The problem is evident if you
have -march=armv5te or earlier, but not with -march=armv6 or later.
This is the code I get with armv6
foo:
@ args = 0, pretend
(Motivated but independent from
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/817234ccd2b3ae1b#)
The following program is rejected in gfortran until one adds a component. I
agree that it is not particularly useful but I think it is standard conform.
In any case the error
In the same c.l.f thread as PR 41369: The following program, based on a post by
Jim Xia does not compile with gfortran (nor with NAG f95, ifort, openf95); I
think it is standard conform (CHECK before fixing!) - and it works with g95.
character(len=mt%i) function foo(mt)
1
Error:
--- Comment #1 from burnus at gcc dot gnu dot org 2009-09-16 07:41 ---
Hmm, I think it might be invalid. The follwing program is rejected as well and
avoids one potential problem. Xia had some other examples which should also be
checked after PR 41369 and - if valid - this PR is fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Summary|gcc.dg/vect/vect-cond- |[4.5 Regression]
|[123].c abort due to bad
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-09-16 08:02 ---
The compiler warns for the store in
D.1845_1 = (struct F *) eee.[0];
D.1854_8 ={v} 0B-D.1740.[0];
D.1845_1-ppp1 = D.1854_8;
because that stores to eee. (type char) via a pointer to type F
--- Comment #1 from dominiq at lps dot ens dot fr 2009-09-16 08:45 ---
The test is also rejected by g95 and ifort, the latter gives:
error #7128: A derived-type-def must have at least one component-def-stmt.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41369
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-09-16 08:50 ---
Subject: Bug 34011
Author: rguenth
Date: Wed Sep 16 08:50:46 2009
New Revision: 151740
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=151740
Log:
2009-09-16 Richard Guenther rguent...@suse.de
PR
I just tried to compile the Suse Linux package krename-3.9.3-1.33
with the gcc 4.5 mainline snapshot 20090910
and the compiler appeared to hang for over half an hour on
an otherwise idle machine.
Preprocessed C++ source attached. Flags -O2 -g -m64 required.
--
Summary: compiler hang
--- Comment #1 from dcb314 at hotmail dot com 2009-09-16 09:19 ---
Created an attachment (id=18594)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18594action=view)
C++ source code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41371
When I compile jar into shared library all symbols become local when
-findirect-dispatch is specified. Local symbols can't be found by dlsym.
-findirect-dispatch options shouldn't change symbols from global to local since
external callers may choose to import them regardless of this option.
--
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-09-16 09:54 ---
it's var-tracking again. Slowly eating memory and time. Working very hard
here:
Run till exit from #0 vt_find_locations ()
at /space/rguenther/src/svn/trunk/gcc/var-tracking.c:5467
--
rguenth at gcc dot
--- Comment #4 from yuri at rawbw dot com 2009-09-16 09:55 ---
Subject: Re: Erroneous aliasing rules violation messages are
issued
rguenth at gcc dot gnu dot org wrote:
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-09-16 08:02
---
The compiler warns for the
--- Comment #23 from davek at gcc dot gnu dot org 2009-09-16 10:19 ---
Created an attachment (id=18595)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18595action=view)
simplified fix
After discussion on the -patches list, it seemed sensible to try preserving the
precise value of
--- Comment #2 from burnus at gcc dot gnu dot org 2009-09-16 10:33 ---
(In reply to comment #1)
The test is also rejected by g95 and ifort, the latter gives:
error #7128: A derived-type-def must have at least one component-def-stmt.
I did not claim that I have a valid Fortran 95
--- Comment #24 from jakub at gcc dot gnu dot org 2009-09-16 10:37 ---
As the __emul* decls are using TLS_MODEL_EMULATED, this patch might make even
their SYMBOL_REFs start using that TLS model. But, unlike the user vars, these
occur normally in the instruction stream, so I wonder if
--- Comment #25 from davek at gcc dot gnu dot org 2009-09-16 10:51 ---
(In reply to comment #24)
As the __emul* decls are using TLS_MODEL_EMULATED, this patch might make even
their SYMBOL_REFs start using that TLS model. But, unlike the user vars,
these
occur normally in the
--- Comment #26 from davek at gcc dot gnu dot org 2009-09-16 10:54 ---
Created an attachment (id=18596)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18596action=view)
YA respin
don't copy tls model into rtl flags for TLS_MODEL_EMULATED, only other values.
--
davek at gcc dot
Using functions with attribute error/warning from templates doesn't
output the instantiation stack. With attribute deprecated this works.
Consider this program:
/
void func() __attribute__ ((error(error)));
//void func()
I noticed the C99 standard (ISO/IEC 9899:1999) doesn't include the dollar sign
($), the at sign (@) and the grave accent (`) in the basic character set (see
section 5.2.1). gcc, anyway, doesn't complain if I have something such as:
char c = '$';
instead of
char c = '\u0024';
I looked at the
--- Comment #5 from jakub at gcc dot gnu dot org 2009-09-16 11:48 ---
Looking at the
int
foo (int i)
{
asm volatile ( : +r (i));
int i1 = 2 * i;
int i2 = 2 * i;
int i3 = 2 * i;
return i;
}
testcase now, here the problem is that cse1 pass sees:
(insn 7 6 8 2 d6.c:4 (set
--- Comment #6 from jakub at gcc dot gnu dot org 2009-09-16 11:53 ---
With:
--- var-tracking.c.xx 2009-09-16 09:17:52.0 +0200
+++ var-tracking.c 2009-09-16 13:48:08.0 +0200
@@ -4416,14 +4416,14 @@ use_type (rtx *loc, struct count_use_inf
expr = REG_EXPR (*loc);
--- Comment #26 from rguenth at gcc dot gnu dot org 2009-09-16 11:56
---
Subject: Bug 41101
Author: rguenth
Date: Wed Sep 16 11:56:31 2009
New Revision: 151744
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=151744
Log:
2009-09-16 Richard Guenther rguent...@suse.de
--- Comment #27 from rguenth at gcc dot gnu dot org 2009-09-16 11:57
---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from joseph at codesourcery dot com 2009-09-16 12:00 ---
Subject: Re: New: C99 basic character set
String and character literals may contain characters from the source
character set that are not members of the basic source character set.
See the syntax for c-char
I have a simple Java class that doesn't directly depend on anything except for
java.lang.String, java.lang.reflect.Class and java.lang.reflect.Method.
It loads other classes (from jars in my case) by name and invoked them through
Class.forName()/Method.invoke() mechanism.
But it only works when
--- Comment #1 from yuri at tsoft dot com 2009-09-16 12:12 ---
I should also add that one of the classes has native methods, and crash occurs
shortly after the first such method is invoked.
This may or may not be a factor in the issue.
Testcase is quite large and I can't submit it
--- Comment #2 from pi00100100 at gmail dot com 2009-09-16 12:27 ---
The fact is that the characters belonging to the source character set but not
belonging the basic source character set are left to the implementation (as far
as I understood). So it would be better (for portability
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-09-16 12:55 ---
it's the inliner that exposes this. I didn't yet investigate further.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41347
collect2 does not handle static libraries to maybe_run_lto_and_relink so it
doesn't get a chance to optimize using its content. This for example means
that when bootstrapping with BOOT_CFLAGS=-flto libbackend.a does not benefit
from lto.
--
Summary: collect2 (and maybe lto1) do not
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-09-16 13:17 ---
It looks like this:
/* Read in lto_in_decl_state objects. */
data_ptr = (const uint32_t *) ((const char*) data + decl_offset);
data_end =
(const uint32_t *) ((const char*) data_ptr +
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-09-16 13:20 ---
Does replacing the #include with
#ifdef HAVE_STDINT_H
#include stdint.h
#endif
#ifdef HAVE_INTTYPES_H
#include inttypes.h
#endif
work for you?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40790
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-09-16 13:27 ---
Works for me with the current branch.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-09-16 13:29 ---
Object files are not useful anymore. Please provide sources.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-09-16 13:32 ---
The patch is not yet in but I think it's the wrong approach. Instead
uncompression should deal with tail padding.
Maybe the issue is no longer present though - can you possibly re-check?
--
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-09-16 13:28 ---
Object files are not useful as a testcase as the object format is not
transferable
between versions. Please provide sources.
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--- Comment #8 from rguenth at gcc dot gnu dot org 2009-09-16 13:38 ---
For the ease of debugging lto_execute_ltrans should get a mode that just
serially executes things without a script. I'm trying to get that running.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39276
--- Comment #5 from rmansfield at qnx dot com 2009-09-16 13:55 ---
I will have to reduce the source testcase before I can provide it. I tried to
reproduce this PR with gcc version 4.5.0 20090910 (experimental) [lto revision
151644] (lto merged with rev 150842) and I now hit the ICE
--- Comment #6 from rmansfield at qnx dot com 2009-09-16 13:59 ---
I now hit PR41173 when I try to reproduce this problem.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40409
--- Comment #7 from rmansfield at qnx dot com 2009-09-16 14:02 ---
I can reproduce the x86 ICE with gcc version 4.5.0 20090902 (experimental) [lto
revision 151401] (lto merged with rev 150842). I will try again with the
latest and reduce a source testcase.
--
--
rth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org
|dot org
--- Comment #3 from ro at techfak dot uni-bielefeld dot de 2009-09-16
14:37 ---
Subject: Re: plugin-api.h unconditionally includes stdint.h
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-09-16 13:20
---
Does replacing the #include with
#ifdef HAVE_STDINT_H
The following testcase triggers an ICE on the trunk when compiled with -O3:
===
struct A
{
bool foo(int*) const;
} a;
struct B {};
struct B1 : B
{
bool (A::*pmf)(int*) const;
const A* pa;
B1() : pmf(A::foo), pa(a) {}
bool
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41377
--- Comment #4 from rth at gcc dot gnu dot org 2009-09-16 15:04 ---
Subject: Bug 41360
Author: rth
Date: Wed Sep 16 15:04:06 2009
New Revision: 151759
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=151759
Log:
PR middle-end/41360
* cfgbuild.c (find_bb_boundaries):
--- Comment #5 from rth at gcc dot gnu dot org 2009-09-16 15:05 ---
Fixed.
--
rth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #5 from rmansfield at qnx dot com 2009-09-16 15:27 ---
Problem still happens with gcc version 4.5.0 20090914 (experimental) [lto
revision 151753] (lto merged with rev 150842)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40392
--- Comment #1 from linuxl4 at sohu dot com 2009-09-16 15:28 ---
Created an attachment (id=18597)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18597action=view)
the source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41378
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-09-16 15:53 ---
Mine.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
After running make check-gcc RUNTESTFLAGS=lto.exp we have
ls testsuite/gcc/
ccnMRJwL-c_lto_20090116_0.o.lto.o gcc-dg-lto-20090206-1-01
c_lto_20090116_0.s gcc-dg-lto-20090206-2-01
gcc-dg-lto-20081120-1-01 gcc-dg-lto-20090219-01
gcc-dg-lto-20081120-2-01
--- Comment #5 from ixt at nm dot ru 2009-09-16 15:58 ---
Denis, nobody wants to open this thread. First, we must do it.
PS You say in Russian?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35294
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-09-16 16:02 ---
FYI, -fipa-pta does nothing (and is known to be broken).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41378
--- Comment #18 from matz at gcc dot gnu dot org 2009-09-16 16:12 ---
Subject: Bug 41212
Author: matz
Date: Wed Sep 16 16:12:18 2009
New Revision: 151761
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=151761
Log:
PR fortran/41212
* tree.h (struct
--- Comment #19 from matz at gcc dot gnu dot org 2009-09-16 16:13 ---
Fixed.
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #18 from rth at gcc dot gnu dot org 2009-09-16 16:27 ---
Subject: Bug 41246
Author: rth
Date: Wed Sep 16 16:26:55 2009
New Revision: 151762
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=151762
Log:
PR target/41246
* tree-cfg.c (verify_gimple_call): Validate
--- Comment #7 from jakub at gcc dot gnu dot org 2009-09-16 16:42 ---
Created an attachment (id=18598)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18598action=view)
expand-asm-stmt.patch
Alternatively to cure this expand_asm_operands could ensure the temporaries
have correct
--- Comment #8 from jakub at gcc dot gnu dot org 2009-09-16 16:43 ---
The http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41353#c4 patch has been
obsoleted by http://gcc.gnu.org/ml/gcc-patches/2009-09/msg01017.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41353
--- Comment #6 from matz at gcc dot gnu dot org 2009-09-16 17:03 ---
Mine. The inliner remaps types (when they are variably modified)
without caring for qualifiers or attributes, resulting in these mismatches.
I have a patch.
--
matz at gcc dot gnu dot org changed:
What
--- Comment #9 from jakub at gcc dot gnu dot org 2009-09-16 17:17 ---
Another interesting testcase:
int
foo (int i)
{
asm volatile ( : +r (i));
int i1 = 2 * i;
int i2 = 2 * i;
int i3 = 3 * i;
asm volatile ( : +r (i) : : memory);
return i;
}
Here things go wrong during
--- Comment #10 from jakub at gcc dot gnu dot org 2009-09-16 17:19 ---
And yet another testcase:
int
foo (int i, int j)
{
j += i;
int i1 = 2 * i;
int i2 = 3 * i;
asm volatile ( : +r (j) : : memory);
return j;
}
Here the debug_insn arguments are lost during cprop1 pass, no
--- Comment #6 from den at openvz dot org 2009-09-16 17:22 ---
for russian - yes.
Should we open new issue? :)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35294
--
rwild at gcc dot gnu dot org changed:
What|Removed |Added
CC||rwild at gcc dot gnu dot org
AssignedTo|unassigned at gcc dot
g++4.3.0 is wrongly eliding the copy constructor and the assignment of a
struct. Look at the following code:
#include iostream
#include complex
struct Complex {
std::complexdouble value;
};
const Complex one = { 1 };
int main() {
Complex z = one, w;
w = one;
--- Comment #1 from paolo dot carlini at oracle dot com 2009-09-16 18:20
---
Works for me with current compilers built out any active release branch.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #7 from ixt at nm dot ru 2009-09-16 18:26 ---
ß êîãäà-òî ïî ïîâîäó ýòîé îøèáêè îáèëüíî ãóãëèë è íàõîäèë íåñêîëüêî òðåäîâ â
ýòîé áàãçèëëå. Èõ çàêðûâàëè ïîä ïðåäëîãîì duplicate. ß äóìàþ, åñëè òû
çàõî÷åøü, òû èõ òîæå íàéä¸øü. Òàê ÷òî - ýòî ãëàâíûé òðåä.
À òàê íàâåðíîå íàäî
--- Comment #9 from rth at gcc dot gnu dot org 2009-09-16 18:55 ---
Fixed here:
http://gcc.gnu.org/ml/gcc-patches/2009-09/msg01069.html
--
rth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from yuri at tsoft dot com 2009-09-16 20:01 ---
Created an attachment (id=18599)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18599action=view)
Java proxy example that crashes without -findirect-dispatch
Try making an executable with -findirect-dispatch and run
--- Comment #6 from rth at gcc dot gnu dot org 2009-09-16 20:12 ---
Subject: Bug 41360
Author: rth
Date: Wed Sep 16 20:12:35 2009
New Revision: 151771
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=151771
Log:
PR middle-end/41360
* cfgbuild.c (find_bb_boundaries):
My source file contains some manipulation on struct arrays. After the
initialization of some local data, there is a call to a dummy function which
has its actual argument being the value of a field of one element of such an
array.
In running the executable compiled with -O, memory corruption can
--- Comment #27 from davek at gcc dot gnu dot org 2009-09-16 21:10 ---
This is not really specific to debug info after all, and since tls doesn't have
its own category, I think middle-end is the best description of this bug.
Just about to post test results from final respin, only
ARM D.15 about Ada.Real_Time.Timing_Events states:
9/2 An object of type Timing_Event is said to be set if it is associated
with a non-null value of type Timing_Event_Handler and cleared
otherwise. All Timing_Event objects are initially cleared.
17/2 The procedure Cancel_Handler clears the event
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-09-16 21:19 ---
Works on all active release branches.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-09-16 21:20 ---
Confirmed with 4.2.4 btw.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #28 from davek at gcc dot gnu dot org 2009-09-16 21:29 ---
Subject: Bug 41357
Author: davek
Date: Wed Sep 16 21:29:17 2009
New Revision: 151773
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=151773
Log:
PR middle-end/41357
* varasm.c
--- Comment #8 from rmansfield at qnx dot com 2009-09-17 02:01 ---
I hit the PR41173 using an updated powerpc-unknown-linux-gnu configuration.
The x86 ICE is still reproducible using a reduced testcase and a mismatch of
optimizations levels.
$ ./xgcc -v
Using built-in specs.
I wrote the following code.
-- begin file haha.cc ---
struct C {
int i;
};
template typename T
struct A {
A() : p(C::i) {}
int C::*p;
};
const Aint r;
int main()
{
return 0;
}
end file haha.cc -
And I compiled it
On Linux/ia32, revision 151771 gave
FAIL: gcc.dg/tls/alias-1.c (test for excess errors)
FAIL: gcc.dg/tls/diag-1.c (test for excess errors)
FAIL: gcc.dg/tls/diag-2.c (test for excess errors)
FAIL: gcc.dg/tls/diag-3.c (test for excess errors)
FAIL: gcc.dg/tls/diag-4.c (test for excess errors)
FAIL:
--- Comment #1 from hjl dot tools at gmail dot com 2009-09-17 03:31 ---
On Linux/x86-64, revision 151771 gave
FAIL: gcc.dg/2111-1.c (test for excess errors)
FAIL: gcc.dg/2906-1.c (test for excess errors)
FAIL: gcc.dg/20010405-1.c (test for excess errors)
FAIL:
79 matches
Mail list logo
