--- Comment #1 from highegg at gmail dot com 2007-06-26 06:36 ---
Created an attachment (id=13790)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13790&action=view)
speedtester of TRANSPOSE, RESHAPE and SPREAD
this testcase tests speed of constructing an array via TRANSPOSE, RESHAP
gfortran currently implements the TRANSPOSE intrinsic by simply rearranging the
array descriptor, which can save considerable time when passed to an
assumed-shape argument. Two more intrinsics can be implemented in this way:
RESHAPE can check for contiguity of its argument and if so, only construc
--- Comment #5 from jakub at gcc dot gnu dot org 2007-06-26 05:47 ---
The exact wording that forbids this is in 2.8.3.6:
"A list item that appears in a reduction clause of a work-sharing construct
must be shared in the parallel regions to which any of the work-sharing regions
arising fro
GCC generally doesn't inline weak functions, because their body may be
redefined by the linker: if the compiler inlined the call, the linker changing
the behavior of the function wouldn't change the inlined copy. For example,
GCC does not inline this:
void bar () __attribute__((weak));
void bar (
--- Comment #9 from davids at webmaster dot com 2007-06-26 03:42 ---
This should be marked as a 4.2.0 regression.
--
davids at webmaster dot com changed:
What|Removed |Added
--
--- Comment #6 from acahalan at gmail dot com 2007-06-26 03:37 ---
(In reply to comment #5)
> This is related to or really a dup of bug 4417.
It's only related, not a dup, though bug 4417 is sort of a subset.
There appears to be no possible set of gcc options that will allow compiling
--- Comment #4 from acahalan at gmail dot com 2007-06-26 03:10 ---
(In reply to comment #3)
> Subject: Re: Missed optimizations with -fwhole-program -combine
>
> I would not expect this to be fixed anytime soon. I have yet to find
> any real people who use either combine or -fwhole-pr
The masseges below are the errors when i compile with command recodif, it never
happen before. Could you help me to fix this problem ?
recodif -cv -D CC=gcc -g testfee.des testfee.rec
Tri des variables...
Ecriture de "testfee.c"...
Ecriture du dessin...
Compilation :
gcc -I/app/std/include -o tes
--- Comment #4 from zadeck at naturalbridge dot com 2007-06-26 02:19
---
so kazu,
is there anything that i need to do with this bug?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32423
--- Comment #15 from geoffk at gcc dot gnu dot org 2007-06-26 01:18 ---
Subject: Bug 20216
Author: geoffk
Date: Tue Jun 26 01:18:08 2007
New Revision: 126014
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126014
Log:
PR 20216
* gcc.dg/pr20216.c: New.
Added:
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-06-26 00:22 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-06-26 00:19 ---
Subject: Bug 32421
Author: pinskia
Date: Tue Jun 26 00:19:44 2007
New Revision: 126012
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126012
Log:
2007-06-25 Andrew Pinski <[EMAIL PROTECTED]>
PR tr
--- Comment #10 from pcarlini at suse dot de 2007-06-25 23:50 ---
Probably, the answer is yes. In this area, when writing portable code, always
remember that C++03 says *nothing* about threads, and concurrent programming,
and so on. Different implementations, historically, made different
--- Comment #9 from appfault at hotmail dot com 2007-06-25 23:41 ---
So does this being marked dupe of bug 21334 mean that as long as (not
ext/vstring.h) is in use, that std::string is subject to other possible race
conditions, even if the original test case succeeds in gcc 3.4.x?
--
--- Comment #2 from gd at spherenet dot de 2007-06-25 23:38 ---
Here is the reduced testcase which shows the bug:
=
namespace std __attribute__((__visibility__("default"))) {
template
class basic_streambuf
{
friend void getline();
};
extern template class basic_
--- Comment #8 from zadeck at naturalbridge dot com 2007-06-25 23:27
---
Subject: Re: ICE in df_refs_verify, at df-scan.c:4058
spark at gcc dot gnu dot org wrote:
> --- Comment #6 from spark at gcc dot gnu dot org 2007-06-25 23:13 ---
> This patch:
>
> diff -r 36792eca786a gc
--- Comment #3 from pcarlini at suse dot de 2007-06-25 23:27 ---
Sorry, disregard my remark between parentheses about 4.1 headers vs 4.2
library, I didn't follow your way of explaining your setup: yes, actaully, a
4.1 object *can* be linked to a 4.2 *.so. In any case, certainly the curre
--- Comment #7 from spark at gcc dot gnu dot org 2007-06-25 23:25 ---
As David suggested, this might be a slightly better fix:
diff -r 36792eca786a gcc/combine.c
--- a/gcc/combine.c Sat Jun 23 16:21:43 2007 +
+++ b/gcc/combine.c Mon Jun 25 23:23:23 2007 +
@@ -2057,6 +205
--- Comment #6 from spark at gcc dot gnu dot org 2007-06-25 23:13 ---
This patch:
diff -r 36792eca786a gcc/combine.c
--- a/gcc/combine.c Sat Jun 23 16:21:43 2007 +
+++ b/gcc/combine.c Mon Jun 25 23:10:32 2007 +
@@ -2849,6 +2849,7 @@ try_combine (rtx i3, rtx i2, rtx i1, i
--- Comment #2 from pcarlini at suse dot de 2007-06-25 23:13 ---
And of course a normally installed and configured recent 4_1-branch gcc
(20070619) compiles the provided snippet just fine. The symbol is exported as
expected:
000ad570 T std::numpunct::_M_initialize_numpunct(__locale_struc
--- Comment #1 from pcarlini at suse dot de 2007-06-25 23:03 ---
Whatever it is, it isn't a libstdc++ proper issue: the 4_1-branch is in deep
regressions-only mode, only very few commits to the breanch during the last 6+
months, nothing related to that issue (just have a look to the Chan
--- Comment #5 from pluto at agmk dot net 2007-06-25 22:57 ---
Created an attachment (id=13789)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13789&action=view)
preprocessed testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32395
--- Comment #4 from pluto at agmk dot net 2007-06-25 22:56 ---
(In reply to comment #2)
> This is caused by two things, jump threading and inlining. If we jump thread
> more, we no longer get the warning which is what you are seeing in 4.2.1.
>
the latest gcc 4.2 also produces this wa
--- Comment #3 from simartin at gcc dot gnu dot org 2007-06-25 22:54
---
This should be fixed in 4.3.
--
simartin at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from simartin at gcc dot gnu dot org 2007-06-25 22:51
---
Subject: Bug 32111
Author: simartin
Date: Mon Jun 25 22:51:12 2007
New Revision: 126006
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126006
Log:
gcc/cp/
2007-06-26 Simon Martin <[EMAIL PROTECTED]>
--- Comment #6 from pluto at agmk dot net 2007-06-25 22:33 ---
this is a duplicate of PR23399.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32109
--- Comment #5 from pluto at agmk dot net 2007-06-25 22:32 ---
fixed by patch for PR32190.
--
pluto at agmk dot net changed:
What|Removed |Added
Status|NEW
--- Comment #1 from pluto at agmk dot net 2007-06-25 22:23 ---
4.2-20070609 works, but 4.2-20070625 fails similar to 4.1.
$ readelf -sW concepts-42.so|c++filt|grep Concept
10: 1010 5 FUNCWEAK DEFAULT 10
__gnu_cxx::_BidirectionalIteratorConcept::__constraints
--- Comment #4 from spam dot brian dot taylor at gmail dot com 2007-06-25
22:20 ---
Looks like you are correct. I believe the relevant section of the OpenMP API
standard is 2.8.1.2 ("Sharing Attribute Rules for Variables Referenced in a
Region, but not in a Construct"), lines 25-35 on
[forwarded from http://bugs.debian.org/428926]
current 4.1 branch fails to link when the following code (extracted from the
gmp source) is built with -O1 (the libstdc++.so.6 on the system is the one
built by the current 4.2 branch).
$ g++ -O1 t-locale.cc
/tmp/ccXHCSZ6.o: In function `main':
t-lo
according to documentation of libstdc++:
"--enable-concept-checks
This turns on additional compile-time checks for instantiated library
templates, in the form of specialized templates, described here.
They can help users discover when they break the rules of the STL,
before their programs run.
--- Comment #1 from magnetudinbuda at yahoo dot com 2007-06-25 21:41
---
Created an attachment (id=13788)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13788&action=view)
the file that caused 'internal compiler error'
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32507
g++ -g source_c++_iostream_test01.cpp
-->
source_c++_iostream_test01.cpp:80 internal compiler error: in dwarf2out_finish,
at dwarf2out.c:14292
source_c++_iostream_test01.cpp :
#include
#include
#include
#include
using namespace std;
static
void
PerformTest01 () {
stringstream objSt
--- Comment #1 from jdi at l4x dot org 2007-06-25 21:35 ---
Created an attachment (id=13787)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13787&action=view)
preprocessed file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32506
Related to #21220?
Still happens with 4.0.4, Host 4.1.2,
$ /usr/cc/sh64/bin/sh64-superh-linux-gnu-ld -v
GNU ld version 2.15.94.0.2.2 20041220
$ /usr/src/cc/gcc-4.0.4/gcc-4.0.4/sh64/gcc/xgcc
-B/usr/src/cc/gcc-4.0.4/gcc-4.0.4/sh64/gcc/
-B/usr/cc/sh64/sh64-superh-linux-gnu/bin/
-B/usr/cc/sh64/sh64-s
--- Comment #3 from dfranke at gcc dot gnu dot org 2007-06-25 21:30 ---
OpenMP v2.5, section 2.5.1, "Loop contruct":
Summary
The loop construct specifies that the iterations of the associated loop will be
executed in parallel. The iterations of the loop are distributed across threads
th
--- Comment #1 from dascandy at gmail dot com 2007-06-25 20:51 ---
The problem doesn't produce a warning when compiled with -Wall -Wextra
-pedantic. One of these (I expect -Wall is the best fit) should produce a
warning.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32505
The following code produces predictable but odd output. The compiler should
either generate a warning for this case or throw away the instantiation of the
type upon encountering the better-matching partial specialization, somehow
keeping it for code above the given line.
template
struct A {
--- Comment #9 from burnus at gcc dot gnu dot org 2007-06-25 20:49 ---
Besides local allocated variables, one can think of local pointers as well:
integer, pointer :: a
a = 4 ! wrong
if(associated(a)) ! wrong
nullify(a)
if(associated(a)) ! ok
a = 4 ! wrong
For allocation, one could als
--- Comment #2 from jojelino at gmail dot com 2007-06-25 20:44 ---
craches if -Olevel given level>1
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32504
--- Comment #1 from jojelino at gmail dot com 2007-06-25 20:42 ---
Created an attachment (id=13786)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13786&action=view)
preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32504
i used to think this is duplicate bug of 32372 because it is invoked by similar
source.
but that testcase works fine.
--
Summary: [4.3 Regression] internal compiler error: in
df_refs_verify, at df-scan.c:4058
Product: gcc
Version: 4.3.0
--- Comment #8 from dfranke at gcc dot gnu dot org 2007-06-25 20:37 ---
Cross-reference: the other way round, warn if allocatable is already allocated:
PR30676.
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from dfranke at gcc dot gnu dot org 2007-06-25 20:35 ---
Currently, there is no means to warn about the usage of (un-)allocated
allocatables. See also: PR20520.
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2007-06-25 20:26
---
(In reply to comment #2)
> there probably is a case for allowing certain such typedefs to be treated
> like keywords with regard to adding _Complex, signed or unsigned.
I second that. Can a decision be reached o
--- Comment #2 from burnus at gcc dot gnu dot org 2007-06-25 20:13 ---
Besides with gfortran, it is also rejected by three further compilers. It still
might be an oversight, but one has to check the OpenMP 2.5 standard; by
compiler voting gfortran wins ;-)
Intel's ifort rejects it with
--- Comment #1 from dfranke at gcc dot gnu dot org 2007-06-25 20:09 ---
I think gfortran is correct ...
$> ifort -warn all -openmp pr32502.f
fortcom: Error: pr32502.f, line 6: Variables that appear on the FIRSTPRIVATE,
LASTPRIVATE, and REDUCTION clauses on a work-sharing directive must
--- Comment #5 from zadeck at naturalbridge dot com 2007-06-25 20:04
---
sorry, pilot error on my part, i am too embarrassed to actually tell you what i
did.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32481
--- Comment #4 from marcus at jet dot franken dot de 2007-06-25 19:57
---
I am using 10.2-x86_64 with the compiler built with
./configure --enable-languages=c
and at r126002
gdb
(gdb) bt
#0 fancy_abort (file=0xab29a0 "/home/marcus/projects/gcc/gcc/df-scan.c",
line=4058, function=0xab3
--- Comment #1 from burnus at gcc dot gnu dot org 2007-06-25 19:56 ---
> Additionally: It would be great if there would be a variant for long integers
> (8 byte integers) and long long (16 byte integers) as PR32239 could only use
> __builtin_powi for int4 and not for int8 or int16.
Actu
--- Comment #4 from burnus at gcc dot gnu dot org 2007-06-25 19:52 ---
"At the moment the vectorizer only vectorizes builtin_pow if the exponent is
either 2 or 0.5. whereas if we expand constant exponents in the gfortran
frontend (gfc_conv_cst_int_power) it vectorizes for other constant
http://gcc.gnu.org/ml/gcc-patches/2007-06/msg01172.html (PR 32239):
"At the moment the vectorizer only vectorizes builtin_pow if the exponent is
either 2 or 0.5. whereas if we expand constant exponents in the gfortran
frontend (gfc_conv_cst_int_power) it vectorizes for other constant integer
power
The following subroutine has an orphaned OpenMP "do" directive (i.e. no
enclosing "parallel" region in the program unit) containing a reduction clause.
gfortran reports an error involving the scope of the reduction variable and
fails to compile the code. I believe this code is valid. For referen
--- Comment #3 from zadeck at naturalbridge dot com 2007-06-25 19:29
---
I cannot recreate this bug.
I have tried building both 32 and 64 bit compilers with both revision 125972
and the current 126001.
All of my machines are suse, so if this requires someone elses abi, I am out of
--- Comment #4 from patchapp at dberlin dot org 2007-06-25 19:03 ---
Subject: Bug number PR32359
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-06/msg01222.html
--
http://gcc.gnu.org/bugzilla/sh
--- Comment #6 from dfranke at gcc dot gnu dot org 2007-06-25 18:51 ---
Updated patch:
http://gcc.gnu.org/ml/gcc-patches/2007-06/msg01858.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32467
--- Comment #2 from patchapp at dberlin dot org 2007-06-25 18:50 ---
Subject: Bug number PR 32130
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-06/msg01856.html
--
http://gcc.gnu.org/bugzilla/s
--- Comment #11 from pault at gcc dot gnu dot org 2007-06-25 18:30 ---
Fixed on trunk.
Thanks for the report, Harald.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #6 from pault at gcc dot gnu dot org 2007-06-25 18:28 ---
Fixed on trunk.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
Statu
--- Comment #10 from pault at gcc dot gnu dot org 2007-06-25 18:28 ---
Subject: Bug 32464
Author: pault
Date: Mon Jun 25 18:27:59 2007
New Revision: 126000
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126000
Log:
2007-06-25 Paul Thomas <[EMAIL PROTECTED]>
PR fortran
--- Comment #5 from pault at gcc dot gnu dot org 2007-06-25 18:28 ---
Subject: Bug 31494
Author: pault
Date: Mon Jun 25 18:27:59 2007
New Revision: 126000
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126000
Log:
2007-06-25 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--- Comment #1 from ro at gcc dot gnu dot org 2007-06-25 18:16 ---
I forgot to mention: this is a regression from the 4.2 branch.
Besides, the same error happens with gas 2.17 and the native assembler.
With both gas and gld 2.17, the problem does not occur, but all java programs
tail t
--- Comment #30 from spark at gcc dot gnu dot org 2007-06-25 18:13 ---
The following patch will essentially disable the warning
for template instantiations in the anonymous namespace.
Index: gcc/cp/decl2.c
===
--- gcc/cp/de
--
spark at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |zadeck at gcc dot gnu dot
|dot org
--
spark at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|spark at gcc dot gnu dot org|unassigned at gcc dot gnu
|
--- Comment #3 from ro at techfak dot uni-bielefeld dot de 2007-06-25
17:38 ---
Subject: Re: Linking 64-bit libgcj.so fails on Solaris 10/x86: non-PIC code
despite -fPIC
hjl at lucon dot org writes:
> --- Comment #2 from hjl at lucon dot org 2007-06-22 18:26 ---
> On Linux,
--- Comment #8 from simon_baldwin at yahoo dot com 2007-06-25 17:26 ---
Resolved by revision 122434.
--
simon_baldwin at yahoo dot com changed:
What|Removed |Added
--- Comment #5 from simon_baldwin at yahoo dot com 2007-06-25 17:24 ---
Indeed it can -- thanks for the reminder. Marking as FIXED.
--
simon_baldwin at yahoo dot com changed:
What|Removed |Added
--- Comment #3 from nemet at gcc dot gnu dot org 2007-06-25 17:22 ---
Fixed.
--
nemet at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #2 from nemet at gcc dot gnu dot org 2007-06-25 17:21 ---
Subject: Bug 32495
Author: nemet
Date: Mon Jun 25 17:21:46 2007
New Revision: 125998
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125998
Log:
PR libfortran/32495
* runtime/backtrace.c (local_
--- Comment #11 from pinskia at gcc dot gnu dot org 2007-06-25 17:12
---
The standard is clear that long long is fully supported by freestanding
programs which means that the implementation needs to support it. GCC supports
it by providing libgcc.a support library.
4/6:
The two forms o
--- Comment #10 from pinskia at gcc dot gnu dot org 2007-06-25 17:08
---
You missed:
> Any library facilities available to a freestanding
> program, other than the minimal set required by clause 4, are
> implementation-> defined.
This is from C99/5.1.2.1.
And C99/4/6 says:
The two fo
--- Comment #9 from malitzke at metronets dot com 2007-06-25 17:02 ---
Read the standard
--
malitzke at metronets dot com changed:
What|Removed |Added
Status|
--- Comment #10 from malitzke at metronets dot com 2007-06-25 17:01 ---
ping
--
malitzke at metronets dot com changed:
What|Removed |Added
CC|rguenth at g
--- Comment #8 from pinskia at gcc dot gnu dot org 2007-06-25 16:54 ---
Who are you pinging? Because if you read the bug report I pointed to, you will
see that this was already decided this is not a bug a long long time ago.
Please read all of my comments instead of just reopening the
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-06-25 16:54 ---
*** Bug 32501 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16470
--- Comment #7 from malitzke at metronets dot com 2007-06-25 16:52 ---
ping
--
malitzke at metronets dot com changed:
What|Removed |Added
Status|RESOLVED
--- Comment #8 from ed at fxq dot nl 2007-06-25 16:52 ---
(In reply to comment #0)
> When the size of the loop is increased (in the attached example, to 6 or
> higher) the problem disappears.
This should read:
> When the size of the array is increased (in the attached example, to 6 or
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Known to fail||4.3.0
Known to work||4.1.2 4.2.0
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-06-25 16:45 ---
This was reported a long time ago as PR 16470, if you think otherwise you need
to go back and talk to the C standards committee. What the issue here is you
are using long long and there is no hardware support for it
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-06-25 16:45 ---
*** Bug 32501 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-06-25 16:44 ---
This is related to or really a dup of bug 4417.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29171
--- Comment #5 from rguenth at gcc dot gnu dot org 2007-06-25 16:41 ---
Pong.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC|rguenth at
--- Comment #4 from malitzke at metronets dot com 2007-06-25 16:39 ---
ping
--
malitzke at metronets dot com changed:
What|Removed |Added
Status|RESOLVED
--- Comment #3 from malitzke at metronets dot com 2007-06-25 16:39 ---
ping
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32501
--- Comment #2 from malitzke at metronets dot com 2007-06-25 16:38 ---
I want to reiterate that I am as little a linux-kernel maintainer as I am a GCC
maintainer. The linux-kernel is in excellent hands and does not need me. Out of
sheer laziness and/or intellectual poverty the example gi
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-06-25 16:31 ---
There is no builtin udivdi3. This is a runtime library function that get's
called
if the processor does not support this instruction (Unsigned DIVide for DImode
with 3 arguments) natively.
--
rguenth at gcc dot
I recognize that because of limits.h and float.h the C compiler has to
implement
functions or in-line code to make available ways to offer something to provide
operations for types referenced via freestanding headers. However, the C
specification says nothing about ___ramming down my throat___ ope
--- Comment #7 from ache at nagual dot pp dot ru 2007-06-25 16:08 ---
Still not works with
gcc version 4.2.1 20070614 prerelease [FreeBSD]
try
cc -O2 foo.c; ./a.out
and
cc -O foo.c; ./a.out
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32500
--- Comment #1 from hjl at lucon dot org 2007-06-25 16:07 ---
Revision 125997 also fails at -O2 on Linux/x86-64 and the 4.2 patch
for PR 30252 fixes this bug for 4.3.
--
hjl at lucon dot org changed:
What|Removed |Added
--
spark at gcc dot gnu dot org changed:
What|Removed |Added
CC||zadeck at gcc dot gnu dot
|
--- Comment #6 from ed at fxq dot nl 2007-06-25 15:50 ---
Thanks for confirming this. Will the fix in question be part of 4.2.1 as well?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32500
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-06-25 15:46 ---
This works on the trunk.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Known
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|blocker |normal
Component|c |tree-optimizat
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-06-25 15:45 ---
i.10_10: [5, 12]
D.2123_11 = i.10_10 - 7;
D.2123_11: [0fffa, +INF]
I think this might have been already fixed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32500
--- Comment #3 from ed at fxq dot nl 2007-06-25 15:36 ---
Created an attachment (id=13785)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13785&action=view)
Generated assembly code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32500
--- Comment #2 from ed at fxq dot nl 2007-06-25 15:36 ---
Created an attachment (id=13784)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13784&action=view)
GCC intermediate code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32500
--- Comment #1 from ed at fxq dot nl 2007-06-25 15:35 ---
Created an attachment (id=13783)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13783&action=view)
C source code which triggers the bug
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32500
Hello,
On the FreeBSD -CURRENT mailing lists a user of the upcoming FreeBSD release
discovered a bug in the GCC that is shipped with the base system (4.2.0
20070514). This bug causes the amount of iterations in a loop to be limited to
the range of an array used in a single part of the loop. When t
I noticed that the libstdc++ testsuite fails to run on mips-sgi-irix6.5 and
mips-sgi-irix5.3::
ERROR: tcl error sourcing
/vol/gcc/src/gcc-dist/libstdc++-v3/testsuite/libstdc++-abi/abi.exp.
ERROR: could not link libtestc++.a
while executing
"error "could not link libtestc++.a""
(procedure
1 - 100 of 149 matches
Mail list logo
