--- Comment #10 from irar at gcc dot gnu dot org 2007-06-08 06:31 ---
Subject: Bug 31699
Author: irar
Date: Fri Jun 8 06:31:39 2007
New Revision: 125560
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125560
Log:
Backport from mainline:
2007-05-03 Dorit Nuzman
The following code compiles and run find using my system's
g++-4.1.3 but when compiled with g++-4.2.1 from SVN,
I get
terminate called after throwing an instance of 'std::runtime_error'
what(): locale::facet::_S_create_c_locale name not valid
Aborted
//-
#include clocale
--- Comment #2 from ubizjak at gmail dot com 2007-06-08 07:20 ---
Confirmed, fails also on i686 (-O3 -msse2 -ftree-vectorize).
Backtrace:
#1 0x08686e6e in vectorizable_type_promotion (stmt=0xb7d0624c, bsi=0x0,
vec_stmt=0x0) at ../../gcc-svn/trunk/gcc/tree-vect-transform.c:2891
#2
--- Comment #171 from ian at airs dot com 2007-06-08 07:49 ---
Created an attachment (id=13666)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13666action=view)
Patch
This variant of the previous patch does better on at least some of the tramp3d
functions. Here we eliminate the
--- Comment #12 from rakdver at gcc dot gnu dot org 2007-06-08 07:29
---
Subject: Bug 32209
Author: rakdver
Date: Fri Jun 8 07:28:50 2007
New Revision: 125563
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125563
Log:
PR middle-end/32209
* dominance.c
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-06-08 07:52 ---
(In reply to comment #1)
no, this is OK (whether it is a good design choice is another thing, I will
think about that).
I actually have a fix for this issue (the MEM with just index: and offset:) but
it is going
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2007-06-08 08:06
---
Patch reverted until Lee comes back, PR assigned to him.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-06-08 08:04
---
(In reply to comment #1)
r125316 | fxcoudert | 2007-06-04 22:59:49 +0200 (Mo, 04 Jun 2007) | 31 lines
2007-06-04 Lee Millward [EMAIL PROTECTED]
http://gcc.gnu.org/ml/gcc-cvs/2007-06/msg00072.html
Patch
--- Comment #7 from chrbr at gcc dot gnu dot org 2007-06-08 07:58 ---
Subject: Bug 29953
Author: chrbr
Date: Fri Jun 8 07:58:41 2007
New Revision: 125564
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125564
Log:
PR target/29953
* config/sh/sh.md (doloop_end): New pattern and
--- Comment #3 from ubizjak at gmail dot com 2007-06-08 08:02 ---
Patch in testing.
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-06-08 08:06
---
Patch reverted until Lee comes back, and bug assigned to him so that he takes
care of it in the next round.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from chrbr at gcc dot gnu dot org 2007-06-08 08:18 ---
doloop_optimize does the iv inversion with the doloop_end insn support in the
machine description.
--
chrbr at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pcarlini at suse dot de 2007-06-08 08:38 ---
The only possible explanation is that, at build time, the configury didn't find
the required localedata (at least de_DE) or other tests failed, and the
generic (instead of gnu) locale model has been selected. In that case
--- Comment #5 from dorit at gcc dot gnu dot org 2007-06-08 08:58 ---
Subject: Bug 32224
Author: dorit
Date: Fri Jun 8 08:57:54 2007
New Revision: 125566
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125566
Log:
PR tree-optimization/32224
* tree-vect-analyze.c
--- Comment #4 from uros at gcc dot gnu dot org 2007-06-08 09:06 ---
Subject: Bug 32243
Author: uros
Date: Fri Jun 8 09:06:46 2007
New Revision: 125567
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125567
Log:
PR tree-optimization/32243
* tree-vect-transform.c
--- Comment #5 from ubizjak at gmail dot com 2007-06-08 09:14 ---
Fixed.
--
ubizjak at gmail dot com changed:
What|Removed |Added
CC|ubizjak at gmail dot
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-06-08 10:11 ---
Confirmed. Instead of calls to _gfortran_pow_r4_i4, gfortran should use
__builtin_powi in this case. __builtin_powi is either expanded inline or
implemented by the libgcc powi function which looks like
TYPE
NAME
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-06-08 10:16 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-06-08 10:28 ---
Confirmed. We are wrongly expanding
;; D.2027 = D.2026 32
(insn 18 17 0 (parallel [
(set (reg:DI 59 [ D.2027 ])
(ashift:DI (reg:DI 60 [ D.2026 ])
(const_int 32
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-06-08 10:36 ---
Confirmed.
{
struct foo x = {.mem1=0, .mem2=-1};
cleanup_point struct foo x = {.mem1=0, .mem2=-1};;
cleanup_point Unknown tree: expr_stmt
bar (x.mem2 == (TARGET_EXPR D.2011, {}).mem2)
;
return retval
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-06-08 10:39 ---
works for me.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pault at gcc dot gnu dot org 2007-06-08 12:56 ---
(In reply to comment #2)
Also breaks 465.tonto in SPEC2006.
I'd say it's
2007-06-04 Lee Millward [EMAIL PROTECTED]
Gentlemen, you will see that this patch was reverted this morning because it
caused PRs3, 38
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-06-08 12:27 ---
Also breaks 465.tonto in SPEC2006.
I'd say it's
2007-06-04 Lee Millward [EMAIL PROTECTED]
* trans-intrinsic.c (gfc_conv_intrinsic_function_args): Adjust
to operate on a stack allocated array for
--- Comment #172 from rguenther at suse dot de 2007-06-08 13:47 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement
new does not change the dynamic type as it should
On Fri, 8 Jun 2007, ian at airs dot com wrote:
--- Comment #171 from ian at airs dot com 2007-06-08
--- Comment #4 from r dot f dot arduini at larc dot nasa dot gov
2007-06-08 14:15 ---
Subject: Re: internal compiler error: in gfc_assign_data_value, at
fortran/data.c:288
Can you please tell me why the compiler flags tauaero.f:1517 while
the problem seems to be associated with the
gcc version 4.3.0 20070608 (experimental)
--
Summary: warning can't open dynamic library
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned
--- Comment #1 from dir at lanl dot gov 2007-06-08 14:59 ---
I just noticed that programs work anyway -
[dranta:~/tests/gfortran-D] dir% rm testioBackspace
[dranta:~/tests/gfortran-D] dir% gfortran -o testioBackspace testioBackspace.f
/usr/bin/ld: warning can't open dynamic library:
--- Comment #2 from dominiq at lps dot ens dot fr 2007-06-08 15:13 ---
/usr/bin/ld: warning can't open dynamic library: /libgcc_s.1.dylib referenced
I have seen this problem while regetesting g++. I am not sure, but I think I
have reported the problem to the gcc list without answer
--- Comment #3 from dir at lanl dot gov 2007-06-08 15:32 ---
It is something new for me. My last build from 4 days ago did not have the
problem -
[dranta:~/tests/gfortran-D] dir% gfortran -o testioBackspace testioBackspace.f
[dranta:~/tests/gfortran-D] dir% gfortran --v
Using built-in
The following program exposes a problem with the scoping of the loop variable
in the IO statement:
program test
implicit none
character(len=100) :: value
integer, dimension(100) :: intvalues
integer i
i = 2
intvalues = 42
value = 2 5 69
write(*,*) len(trim(value))
--- Comment #5 from brolley at redhat dot com 2007-06-08 15:41 ---
OK, I've looked into this a bit more. For inspiration I looked into where the
error is generated when an incomplete struct is used instead of an unsized
array. I found it in:
cxx_incomplete_type_diagnostic called by
--- Comment #7 from brolley at redhat dot com 2007-06-08 15:46 ---
Small optimization. We need only call complete_type_or_else once we know it's
an array type.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31743
--- Comment #6 from brolley at redhat dot com 2007-06-08 15:42 ---
Created an attachment (id=13667)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13667action=view)
New proposed patch
--
brolley at redhat dot com changed:
What|Removed |Added
--- Comment #4 from dominiq at lps dot ens dot fr 2007-06-08 15:35 ---
You may also have a look to PR30572.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32255
Hi, this header (header.h):
#pragma GCC system_header
int noreturn() { }
included by (file.cc):
#include header.h
void ok() { }
Leads to:
paolo:~/Work g++ -Wall -c file.cc
header.h: In function 'int noreturn()':
header.h:2: warning: control reaches end of non-void function
Note, this problem
--- Comment #8 from brolley at redhat dot com 2007-06-08 15:47 ---
Created an attachment (id=13668)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13668action=view)
Improvement on previous patch
--
brolley at redhat dot com changed:
What|Removed
-testresults/2007-05/msg01083.html
Here are some other people's results - some used the --with-mpfr option:
Compiled using --with-mpfr=/remote/atg5/jbuck/mpfr-linux :
Results for 4.3.0 20070608 (experimental) testsuite on i686-pc-linux-gnu
http://gcc.gnu.org/ml/gcc-testresults/2007-06/msg00396.html
--- Comment #1 from pcarlini at suse dot de 2007-06-08 16:53 ---
In fact, the problem is of the same type of that in C++/30500: in C++ only when
execute_warn_function_return begins in_system_header is zero (in C is 1 and all
the warnings are suppressed because
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-06-08 16:51 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
Hi,
maybe someone of the gcc bugs group can help you, this bug is
unrelated to the video4linux/em28xx project.
Maybe retrying to compile the code might fix it, (I would try to run
memcheck and checking for faulty memory)
Markus
On 6/8/07, Romain Fluttaz [EMAIL PROTECTED] wrote:
Hi, i'm under
--- Comment #1 from kargl at gcc dot gnu dot org 2007-06-08 17:14 ---
(In reply to comment #0)
I installed http://www.mpfr.org/mpfr-current/mpfr-2.2.1.tar.bz2 and applied
the
most recent patches. My version is 2.2.1-p5.
What does p4 do?
--
kargl at gcc dot gnu dot org changed:
--- Comment #7 from rask at sygehus dot dk 2007-06-08 17:35 ---
Created an attachment (id=13669)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13669action=view)
Patch v3 to add -L and -B as necessary
This patch should fix the mep* case that I accidentally deleted.
--
rask at
I checked http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16104 which is for
gcc.c-torture/execute/20050316-1.c and this is not related.
In this test optimization levels -O0, -O1 and -O2 are broken, levels
-O3 and -Os are OK. I am using rtl and rtlflag checking.
# gcc/xgcc -v
Using built-in specs.
--- Comment #4 from ian at airs dot com 2007-06-08 17:57 ---
I'm testing this patch.
Index: tree-vrp.c
===
--- tree-vrp.c (revision 125521)
+++ tree-vrp.c (working copy)
@@ -2208,6 +2208,8 @@
--- Comment #1 from tromey at gcc dot gnu dot org 2007-06-08 18:35 ---
I'm closing this, because parse.y no longer exists on svn trunk.
If you find instances of this bug in the remaining parts of gcj,
please file a new PR. Thanks.
--
tromey at gcc dot gnu dot org changed:
--- Comment #1 from tromey at gcc dot gnu dot org 2007-06-08 18:36 ---
I'm closing this, because parse.y no longer exists on svn trunk.
If you find instances of this bug in the remaining parts of gcj,
please file a new PR. Thanks.
--
tromey at gcc dot gnu dot org changed:
--- Comment #11 from baldrick at gcc dot gnu dot org 2007-06-08 18:46
---
Thank you both for your explanation to a newbie having no experience with
valgrind tool. I have come up with a simpler version which similar to
Laurent's. Here it goes.
Thanks - but how is it supposed to
The following code, compiled with -O2 -Wall (g++ 4.3 as of 20070607),
produces the following unexpected/annoying warning:
test_typeinfo.cpp: In function 'int main()':
test_typeinfo.cpp:5: warning: dereferencing type-punned pointer will break
strict-aliasing rules
test_typeinfo.cpp:5: warning:
--- Comment #4 from simartin at gcc dot gnu dot org 2007-06-08 18:27
---
Fixed on the mainline.
--
simartin at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from anhvofrcaus at gmail dot com 2007-06-08 19:11 ---
You are right Constraint_Error is raised when checking for validity through
Item.all'Valid if Item is null. Therefore, using Laurent's to check Item for
null is the only way. Either one of these methods verifies that
--- Comment #2 from goeran at uddeborg dot se 2007-06-08 19:25 ---
Ok. I've found a few more in parse.y, but I won't bother to report them then.
So far nothing outside this time around, but I have a few hundred messages to
go ... :-)
--
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-06-08 19:50 ---
It is also fixed in 3.4.6.
Well then it is fixed as 3.3.x is no longer being maintained and has not been
for over a year (or two).
--
pinskia at gcc dot gnu dot org changed:
What|Removed
Compiling with:
g++ -g -O3 gccbug.cpp -pthread -o gccbug -s
Note that removing the -s eliminates the segfault, as does removing
optimizations with -O0.
This occurs with gcc 3.3 and 3.3.6 but does not occur with the gcc 3.2.3
delivered as part of RedHat ES3.0u5. It is also fixed in 3.4.6.
I have configure gcc like this:
/n/08/rask/src/gcc/configure --target=m68hc11-none --disable-multilib
--disable-nls --with-newlib --enable-sim
Building libgfortran fails with this message:
libtool: compile: /home/rask/build/gcc-m68hc11-none/./gcc/gfortran
Document the required versions of glibc and binutils.
Typically only a couple versions of glibc and binutils are compatible with each
version of gcc, and finding out which ones are compatible is often quite
time-consuming. While gcc/doc/gccinstall.info does document some minimum
versions, it
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-06-08 20:16 ---
HUH? I had never had any problems with older versions of GCC with newer
versions of binutils. If you do then either it is a bug in the older version
of GCC (which is likely) or a bug in the newer binutils (which is
When Linux vanilla kernel 2.4.34.5 is compiled with -march=c3 (VIA C3)
- kernel crashes after boot on a VIA C3
.config: CONFIG_MCYRIXIII=y
Environment:
System: Linux bongo 2.4.34.5-ARXc3 COHERENT #9-ARX (Build 3359) Fri Jun 8
16:41:33 CEST 2007 i686 i686 i386 GNU/Linux
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-06-08 20:18 ---
I think we need more information from you about what issues you are running
into.
I also use glibc 2.3.2 with many different versions of GCC too. I still don't
see what regressions you are talking about anyways.
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-06-08 20:19 ---
Testcase?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32264
--- Comment #3 from axel at freakout dot de 2007-06-08 20:25 ---
Subject: Re: 03.5: gcc 4.2.0 compiled vanilla
kernel 2.4.34.5 crashes when VIA C3 optimized -march=c3
According to pinskia at gcc dot gnu dot org:
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-06-08
--- Comment #9 from mueller at gcc dot gnu dot org 2007-06-08 21:48 ---
Subject: Bug 31806
Author: mueller
Date: Fri Jun 8 21:48:34 2007
New Revision: 125580
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125580
Log:
2007-06-08 Dirk Mueller [EMAIL PROTECTED]
PR
--- Comment #10 from mueller at gcc dot gnu dot org 2007-06-08 21:48
---
Subject: Bug 31809
Author: mueller
Date: Fri Jun 8 21:48:34 2007
New Revision: 125580
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125580
Log:
2007-06-08 Dirk Mueller [EMAIL PROTECTED]
PR
No matter how high the optimzation level,
--never_inline prevents all inlining, even when called for in source code
--no_automatic_inline prevents automatic inlining, i.e. inlining by the
compiler when not specifically called for in the source code
--
Summary: --never_inline and
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-06-08 22:14 ---
--never_inline prevents all inlining, even when called for in source code
-fno-inline
(Or do you mean even with attribute always_inline?)
--no_automatic_inline prevents automatic inlining, i.e. inlining by the
--- Comment #7 from rob1weld at aol dot com 2007-06-08 23:34 ---
I tried this on i686-pc-linux-gnu using gcc-3.4 (from Debian), gcc-4.1 (from
Debian), gcc version 4.2.0 20070501 (prerelease) (from SVN), and gcc version
4.3.0 20070607 (experimental) (from SVN):
I modified as follows:
I will attach the example in a subsequent comment. If I execute:
gcc -O1 -c xf86ScanPci.c
it sucks up 805M of virtual memory. No optimization, no problem.
gcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.2.0/configure --prefix=/opt/gcc-4.2.0
--enable-threads
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-06-08 23:38 ---
*** This bug has been marked as a duplicate of 30052 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #32 from pinskia at gcc dot gnu dot org 2007-06-08 23:38
---
*** Bug 32266 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from jsberg04+computing dot bugs dot gcc at ftml dot net
2007-06-08 23:38 ---
Created an attachment (id=13670)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13670action=view)
Preprocessed, bzip2 compressed example.
From Xorg 7.2.0, if anyone cares...
--
--- Comment #2 from thanate at asu dot edu 2007-06-08 23:40 ---
umm... I don't know how to check for that.
But I ran configure with --enable-clocale=gnu.
I posted my build log at
http://mathpost.asu.edu/~thanate/build.log
I'll keep the build dir for a while in case
you need some more
--- Comment #3 from pcarlini at suse dot de 2007-06-09 00:11 ---
See this line in the Log:
checking for C locale to use... generic
That means the configure-time tests for the gnu locale model are not ok and the
generic locale model is selected instead, as a fallback. Can you
--- Comment #4 from thanate at asu dot edu 2007-06-09 00:22 ---
localedef --list-archive gave me only one line:
en_US.utf8
I think that's how I set up my system, with only one locale.
Now I'm not sure why should I have to have de_DE installed
for locale() to work. But if you want, I
--- Comment #5 from pcarlini at suse dot de 2007-06-09 00:26 ---
Ok, that is it. That locale must be installed because old glibcs had a bug
which showed up clearly with de_DE and we must check against it. The docs
explain that, anyway:
--- Comment #1 from rob1weld at aol dot com 2007-06-09 00:57 ---
Here is a related failure this time for gcc.c-torture/execute/20050604-1.c :
# grep --color=always -B16 -A6 20050604-1.c gcc/testsuite/gcc/gcc.log | tail -n
26
Executing on host: /opt/gcc-4_3-build-2/gcc/xgcc
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-06-09 02:10 ---
This is related to (or a dup of) bug 19590.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
+++ This bug was initially created as a clone of Bug #21291 +++
works with -O0, fails with -O[123].
gcc-4.0.0 + patches for pr20973,21173.
I could not reopen http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21291 so I
thought I'd try clicking on clone this bug since it has re-emerged in 4.2.0 and
--- Comment #2 from rob1weld at aol dot com 2007-06-09 03:17 ---
From [EMAIL PROTECTED]
I installed http://www.mpfr.org/mpfr-current/mpfr-2.2.1.tar.bz2 and applied
the most recent patches. My version is 2.2.1-p5.
What does p4 do?
They only offer the patches mixed together,
--- Comment #4 from rob1weld at aol dot com 2007-06-09 03:27 ---
One enhancement I did try was adding this to the end of contrib/test_summary.
It does nothing for _me_ since I have the new assembler but for others it would
catch the failures and report them.
print ;
print ---;
--- Comment #2 from rob1weld at aol dot com 2007-06-09 03:45 ---
Tried running make -i check on a just-built version of gcc while compiling a
newer revision of gcc in a different X-Window. The load was enough to give a
number of timeouts in various places.
It is inconvenient to be
--- Comment #6 from rob1weld at aol dot com 2007-06-09 03:52 ---
Changing From / To:
Known to work: (Blank) and Known to fail: 4.2.0 4.2.1 4.3.0
Known to work: 4.3.0 and Known to fail: 4.2.0 4.2.1
Since 4.3.0 works on i686-pc-linux-gnu perfectly - No reason to believe 4.3.0
works on
--- Comment #38 from bergner at gcc dot gnu dot org 2007-06-09 04:08
---
Created an attachment (id=13671)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13671action=view)
Updated patch to address x86_64 performance issues.
This updated patch reverts the
81 matches
Mail list logo
