--- Comment #9 from dodji at gcc dot gnu dot org 2009-01-22 07:15 ---
Subject: Bug 26693
Author: dodji
Date: Thu Jan 22 07:15:41 2009
New Revision: 143562
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143562
Log:
Reverted commit 143546 related to PR c++/26693
Removed:
tru
--- Comment #9 from hjl dot tools at gmail dot com 2009-01-22 06:03 ---
One fix is to add a proper intrinsic for vmrun.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38925
--- Comment #11 from hjl dot tools at gmail dot com 2009-01-22 05:56
---
(In reply to comment #5)
> Created an attachment (id=17159)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17159&action=view) [edit]
> Fix candidate
>
> I think this patch should fix the problem.
>
> I am te
--- Comment #25 from regehr at cs dot utah dot edu 2009-01-22 05:06 ---
I get this using r143561 on Ubuntu Hardy on x86:
reg...@john-home:~/volatile/tmp126$ current-gcc -O3 -c small.c
small.c: In function bar:
small.c:22: internal compiler error: in set_value_range, at tree-vrp.c:398
--- Comment #8 from pinskia at gcc dot gnu dot org 2009-01-22 04:01 ---
Also I think this is the same as bug 35160.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38925
--- Comment #7 from pinskia at gcc dot gnu dot org 2009-01-22 03:51 ---
The problem here is that you are using unitialized local register variables so
the register allocator does not know any better. Anyways it works correctly on
the trunk and I don't have any other compiler to test wit
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2009-01-22 03:05
---
Further information: PD is not the problem here at all. The problem is that
when using the D edit descriptor, one is not allowed to also specify the
exponent digits.
Thus: '(1pD24.15)' is valid
While: '(1pD2
--- Comment #1 from rob1weld at aol dot com 2009-01-22 02:24 ---
One we get to gcc version 4.4.0 20090121 (experimental) [trunk revision 143538]
this no longer occurs. Closing FIXED.
Rob
--
rob1weld at aol dot com changed:
What|Removed |Added
/testsuite/gcc.dg/pch/counter-1.c:7: internal
compiler error: in ggc_record_overhead, at ggc-common.c:873
More info:
Results for 4.4.0 20090121 (experimental) [trunk revision 143538] (GCC)
testsuite on i386-pc-solaris2.11
http://gcc.gnu.org/ml/gcc-testresults/2009-01/msg02197.html
Rob
--
http
--- Comment #1 from rob1weld at aol dot com 2009-01-22 01:47 ---
With that dropped in gcc seems to build and test correctly. It _might_ be
that gcc builds Faster and uses Less memory during the two peaks in libjava
after this patch, more testing required.
Rob
--
http://gcc.gnu.org
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-01-22 01:41 ---
3.3 ICEd on the testcase.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Know
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-01-22 01:41 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-01-22 01:30 ---
Confirmed, more reduced testcase:
typedef int __m64 __attribute__ ((__vector_size__ (8)));
__inline __m64 _m_pshufw (){}
typedef unsigned char uint8;
void dummy (
const int input_bpl,
const un
--- Comment #10 from sje at cup dot hp dot com 2009-01-22 00:08 ---
Pointer to http://gcc.gnu.org/ml/gcc-patches/2008-07/msg00371.html where Martin
Jambor says he has looked at this bug and says he thinks it is a libmudflap bug
and not actually related to the patch that caused it to star
--- Comment #10 from hjl dot tools at gmail dot com 2009-01-22 00:01
---
(In reply to comment #5)
> Created an attachment (id=17159)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17159&action=view) [edit]
> Fix candidate
>
> I think this patch should fix the problem.
>
> I am te
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #18 from pinskia at gcc dot gnu dot org 2009-01-21 23:30
---
*** Bug 38929 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #7 from pinskia at gcc dot gnu dot org 2009-01-21 23:30 ---
Yes it is a dup, replacing ++ with +=1 allows this to work correctly.
*** This bug has been marked as a duplicate of 35634 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #6 from pinskia at gcc dot gnu dot org 2009-01-21 23:28 ---
Reopening to ...
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #5 from joseph at codesourcery dot com 2009-01-21 23:27 ---
Subject: Re: Optimisation with inline function causes invalid
behaviour
On Wed, 21 Jan 2009, rguenth at gcc dot gnu dot org wrote:
> You overflow x and y in main() which invokes undefined behavior.
Actually, I d
--- Comment #6 from pinskia at gcc dot gnu dot org 2009-01-21 22:59 ---
(In reply to comment #5)
> I think it is the frontends business to omit the stores.
Or the gimplifier like what happens for GNU C code:
/* For zero sized types only gimplify the left hand side and right hand
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38908
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-01-21 22:49 ---
I think it is the frontends business to omit the stores.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from hjl dot tools at gmail dot com 2009-01-21 22:43 ---
(In reply to comment #8)
> Subject: Re: [4.4 Regression] Revision 143546 failed to bootstrap
>
> hjl dot tools at gmail dot com a écrit :
> > --- Comment #6 from hjl dot tools at gmail dot com 2009-01-21 22:3
--- Comment #4 from bkoz at gcc dot gnu dot org 2009-01-21 22:41 ---
fixed summary
--
bkoz at gcc dot gnu dot org changed:
What|Removed |Added
Known to work|
--- Comment #2 from bkoz at gcc dot gnu dot org 2009-01-21 22:41 ---
fix summary
--
bkoz at gcc dot gnu dot org changed:
What|Removed |Added
Summary|[4.3 regre
--- Comment #8 from dodji at gcc dot gnu dot org 2009-01-21 22:37 ---
Subject: Re: [4.4 Regression] Revision 143546 failed to bootstrap
hjl dot tools at gmail dot com a écrit :
> --- Comment #6 from hjl dot tools at gmail dot com 2009-01-21 22:34
> ---
> A small testcase:
>
--- Comment #7 from hjl dot tools at gmail dot com 2009-01-21 22:37 ---
(In reply to comment #5)
> Created an attachment (id=17159)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17159&action=view) [edit]
> Fix candidate
>
> I think this patch should fix the problem.
>
> I am test
--- Comment #6 from hjl dot tools at gmail dot com 2009-01-21 22:34 ---
A small testcase:
[...@gnu-6 pr38930]$ cat x.cc
class _Jv_Linker
{
private:
typedef unsigned int uaddr __attribute__ ((mode (pointer)));
};
[...@gnu-6 pr38930]$ /export/build/gnu/gcc-work/build-x86_64-linux/gcc/x
--- Comment #5 from dodji at gcc dot gnu dot org 2009-01-21 22:27 ---
Created an attachment (id=17159)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17159&action=view)
Fix candidate
I think this patch should fix the problem.
I am testing it right now. It'll take a little while as
--- Comment #4 from dodji at gcc dot gnu dot org 2009-01-21 22:25 ---
I think I have an idea of what's going on.
g++ is actually failing on the line:
typedef unsigned int uaddr __attribute__ ((mode (pointer)));
(in libjava/include/jvm.h:262, while compiling libjava/jni-libjvm.cc).
That
--- Comment #1 from bkoz at gcc dot gnu dot org 2009-01-21 22:24 ---
I see this as well. See 38851 for more spurious uninitialized warnings.
This is a regression from 4.3, and IMHO is not minor.
--
bkoz at gcc dot gnu dot org changed:
What|Removed
--- Comment #3 from bkoz at gcc dot gnu dot org 2009-01-21 22:19 ---
Confirmed for s390x.
This is causing the following s390x libstdc++ testsuite failures, and is thus a
regression from 4.3. As far as I can tell these warnings are spurious.
http://gcc.gnu.org/ml/gcc-testresults/2009-
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Severity|critical|normal
Status|UNCONFIRMED |NEW
Ever
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-01-21 22:15 ---
Fixed for GCC 4.4, not worth fixing on the branches.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38666
--- Comment #7 from hp at gcc dot gnu dot org 2009-01-21 22:00 ---
(In reply to comment #6)
> However, I suspect that all the places that use may_trap_after_code_motion_p
> in
> fact expect it to have MTP_AFTER_MOVE | MTP_UNALIGNED_MEMS semantics as well.
Me too.
> So I would propose
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P2 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38926
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||build
Priority|P3 |P1
http://gcc
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38926
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38880
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38878
--- Comment #42 from rguenth at gcc dot gnu dot org 2009-01-21 21:56
---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-01-21 20:50 ---
I was able to work around the issue sofar, but more analysis is still required.
I will see if I can find some time for that.
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-01-21 20:26 ---
You overflow x and y in main() which invokes undefined behavior.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pault at gcc dot gnu dot org 2009-01-21 20:22 ---
(In reply to comment #1)
> http://gcc.gnu.org/ml/gcc-patches/2009-01/msg00937.html
>
Richard,
I am not sure that any of the gfortran developers have the skills to deal with
this. I read the words about canonical ty
--- Comment #41 from vmakarov at gcc dot gnu dot org 2009-01-21 20:18
---
Subject: Bug 38587
Author: vmakarov
Date: Wed Jan 21 20:18:03 2009
New Revision: 143554
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143554
Log:
2009-01-21 Vladimir Makarov
PR middle-end/385
--- Comment #16 from hjl dot tools at gmail dot com 2009-01-21 20:03
---
I am closing it as dup of PR 38587, which will be fixed by
http://gcc.gnu.org/ml/gcc-patches/2009-01/msg01067.html
Please re-open it if the patch above doesn't fix this bug.
*** This bug has been marked as a dup
--- Comment #40 from hjl dot tools at gmail dot com 2009-01-21 20:03
---
*** Bug 38660 has been marked as a duplicate of this bug. ***
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
-
--- Comment #3 from dominiq at lps dot ens dot fr 2009-01-21 19:58 ---
It failed to bootstrap on i686-apple-darwin9 too.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38930
--- Comment #2 from hjl dot tools at gmail dot com 2009-01-21 19:46 ---
It failed to bootstrap on Linux/ia32 and Linux/Intel64.
Linux/ia64 is OK.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
---
--
dodji at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dodji at gcc dot gnu dot org
|dot org
--- Comment #12 from davek at gcc dot gnu dot org 2009-01-21 19:20 ---
Subject: Bug 37660
Author: davek
Date: Wed Jan 21 19:20:08 2009
New Revision: 143552
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143552
Log:
PR bootstrap/37660
* config/i386/cygwin.h (SHARE
--- Comment #1 from nvachhar at google dot com 2009-01-21 19:02 ---
Created an attachment (id=17158)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17158&action=view)
Test case to trigger the segfault.
To generate the segfault, use the following command line:
g++ -mtune=generic -O
Calling insn_default_latency on the following RTL causes the compiler to
segfault.
(insn 75 73 77 2 y.ii:19 (set (reg:SI 30 mm1)
(const_int 0 [0x0])) 41 {*movsi_1} (nil))
The root cause of the problem seems to be in i386.md. Pasted below is a
snippet of the file describing the alternativ
--- Comment #6 from ubizjak at gmail dot com 2009-01-21 18:50 ---
Fixed.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #5 from uros at gcc dot gnu dot org 2009-01-21 18:47 ---
Subject: Bug 38879
Author: uros
Date: Wed Jan 21 18:47:19 2009
New Revision: 143549
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143549
Log:
PR rtl-optimization/38879
* alias.c (base_alias_che
--- Comment #1 from hjl dot tools at gmail dot com 2009-01-21 18:31 ---
It also happened on Linux/ia32.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
T
Revision 143546:
http://gcc.gnu.org/ml/gcc-patches/2009-01/msg00940.html
causes
In file included from ../../../../src-trunk/libjava/gij.cc:11:
../../../../src-trunk/libjava/include/jvm.h:260: internal compiler error: in
gen_typedef_die, at dwarf2out.c:14665
Please submit a full bug report,
with
--- Comment #5 from bkoz at gcc dot gnu dot org 2009-01-21 18:02 ---
fixed.
--
bkoz at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #4 from bkoz at gcc dot gnu dot org 2009-01-21 18:02 ---
Mine.
--
bkoz at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gc
--- Comment #3 from gcc at twistedsquare dot com 2009-01-21 17:36 ---
The main optimisation that seems to affect this example, is, -fstrict-overflow.
So to reiterate:
Works: gcc gccbug.c -std=gnu99 -O1
Doesn't work: gcc gccbug.c -std=gnu99 -O2
Doesn't work: gcc gccbug.c -std=gnu99 -O2
--- Comment #2 from gcc at twistedsquare dot com 2009-01-21 17:13 ---
The -fno-tree-vrp flag does stop the problem on the testcase I submitted.
However, on the full program I drew the testcase from, it only modifies the
behaviour to a different invalid problem, so it is perhaps an inter
--- Comment #1 from gcc at twistedsquare dot com 2009-01-21 17:03 ---
I tried fiddling with various optimisations. With -O1 the code works fine.
With -O2 the code breaks. With -O2 -fno-tree-vrp it works fine again, so that
may help in finding the bug.
--
http://gcc.gnu.org/bugzil
I have a program with an addition function for int8_t that is intended to check
for overflow. Regardless of whether the test works, I get different results
from the program if I compile it with -O1 vs compiling with -O2. It appears
that GCC is performing optimisations it shouldn't across the proc
--- Comment #6 from rakdver at gcc dot gnu dot org 2009-01-21 16:41 ---
(In reply to comment #4)
> Zdenek, could you please comment on comment #3?
>
Adding MTP_AFTER_MOVE seems like the right thing to do; after all, even the
comments for may_trap_or_fault_p specify that it should behav
--- Comment #8 from dodji at gcc dot gnu dot org 2009-01-21 16:15 ---
Subject: Bug 26693
Author: dodji
Date: Wed Jan 21 16:14:49 2009
New Revision: 143546
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143546
Log:
gcc/ChangeLog:
2009-01-21 Dodji Seketeli
PR c++/26693
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-01-21 15:43 ---
Mine. I am working on adding versioning for non-constant strides.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #39 from vmakarov at redhat dot com 2009-01-21 15:39 ---
Yes, right. I should have read the standard itself (not gcc manual which
states "ISO C says that automatic variables that are not declared `volatile'
have undefined values after a `longjmp'"). That is good that Andrew
--- Comment #18 from bruprz1 at lhsystems dot pl 2009-01-21 14:39 ---
(In reply to comment #13)
> symbols. The assembly files generated by GCC for AIX always have included
> multiple symbol definitions for certain global variable and function
If I understand correctly, that statement me
--- Comment #2 from dberlin at gcc dot gnu dot org 2009-01-21 14:09 ---
Subject: Re: [4.4 Regression] ice in
find_or_generate_expression, at tree-ssa-pre.c:2769
names should be self-leaders.
Sounds like a set bitmap messup somewhere or an equality function gone
bad or somethin
--- Comment #5 from domob at gcc dot gnu dot org 2009-01-21 13:37 ---
Fixed on trunk by converting the abort() call in internal_unpack to a return
(this is also what the "real" unpack library call does).
--
domob at gcc dot gnu dot org changed:
What|Removed
--- Comment #4 from domob at gcc dot gnu dot org 2009-01-21 13:35 ---
Subject: Bug 38887
Author: domob
Date: Wed Jan 21 13:34:55 2009
New Revision: 143541
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143541
Log:
2009-01-21 Daniel Kraft
* trans-stmt.c (gfc_conv_elem
--- Comment #6 from thutt at vmware dot com 2009-01-21 13:08 ---
(In reply to comment #3)
> Also I think the inline-asm could be improved so that the inline-asm just
> marks
> the registers that are clobbered instead of doing the mess you are doing.
>
Can you provide an example of h
--- Comment #5 from thutt at vmware dot com 2009-01-21 13:06 ---
(In reply to comment #2)
> I think this code is undefined as you are using uninitialized variables for
> input of the inline-asm.
>
I disagree.
The registers are intended to have their *current*
values saved across the
--- Comment #8 from jwakely dot gcc at gmail dot com 2009-01-21 12:21
---
Not sure what happened yesterday, but I get the same result for both libgomp
and libstdc++ today: both interpret the GNU ld version as 1800
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38923
etie...@pc300:~$ gcc -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.2-1'
--with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared
--with-system-zlib --libex
--- Comment #4 from hpreg at vmware dot com 2009-01-21 10:19 ---
Andrew,
With respect to your comment #2: initializing all the variables to 0 does not
solve the problem, which is that gcc does not understand that %rbp is
clobbered.
With respect to your comment #3: as explained in the b
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-01-21 10:13 ---
Confirmed. PRE doesn't find a leader for a NAME (!?) when inserting
{nop_expr,g_2.7_47}.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #38 from schwab at suse dot de 2009-01-21 09:16 ---
(In reply to comment #35)
> "system", which is a function argument, is trashed here.
But it's not modified between setjmp and longjmp, so its value must be
preserved.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3858
81 matches
Mail list logo
