--- Comment #1 from burnus at gcc dot gnu dot org 2007-10-19 06:40 ---
> Whenever I invoke this compiler without specifying a cource file I get the
> expected error message:
> gfortran: no input files
[...]
> Whenever I invoke the compiler with a valid fortran source file I get the
> er
--- Comment #14 from skaller at users dot sourceforge dot net 2007-10-19
06:33 ---
Confirm this also with SVN as at around 15 Oct 2007,
version 4.3, a bit before revision 129472.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26165
--- Comment #10 from jvdelisle at gcc dot gnu dot org 2007-10-19 04:58
---
This does the trick. I am checking the testsuite for any side effects.
Index: simplify.c
===
--- simplify.c (revision 129465)
+++ simplify.c (w
Consider:
#include
#include
#include
#include
void test ( unsigned int num_buckets, unsigned int seed = 3141592 ) {
std::cout << "using " << num_buckets << " buckets:\n";
std::tr1::mt19937 eng(seed);
const unsigned long range = eng.max() / 5.5;
std::tr1::uniform_int rnd( 0, range );
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2007-10-19 04:22
---
Fixed, closing
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
Sta
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2007-10-19 04:16
---
Subject: Bug 33795
Author: jvdelisle
Date: Fri Oct 19 04:16:14 2007
New Revision: 129471
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129471
Log:
2007-10-18 Jerry DeLisle <[EMAIL PROTECTED]>
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2007-10-19 04:11
---
Subject: Bug 33795
Author: jvdelisle
Date: Fri Oct 19 04:10:58 2007
New Revision: 129470
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129470
Log:
2007-10-18 Francois-Xavier Coudert <[EMAIL PROTECTED]>
I am using gfortran on a Mac Mini, and have got the compiler by untaring the
gfortran-intel-bin.tar package. The compilers are located in /usr/local/bin.
I am running Mac OS X Version 10.4.10
Whenever I invoke this compiler without specifying a cource file I get the
expected error message:
gfort
--- Comment #22 from bkoz at gcc dot gnu dot org 2007-10-19 02:00 ---
> I believe there are other functions in libstdc++ that depend on initialization
> order. I do not have specifics.
Perhaps:
FAIL: 27_io/objects/char/6.cc execution test
FAIL: 27_io/objects/wchar_t/6.cc execution test
--- Comment #21 from ajd at gentrack dot com 2007-10-19 01:44 ---
Created an attachment (id=14372)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14372&action=view)
support -blazy, add option to disable
I suggest exportinitfini_flag is enabled by default or atleast for the build of
--- Comment #1 from dave at hiauly1 dot hia dot nrc dot ca 2007-10-18
23:55 ---
Subject: Re: New: collect2 doesn't strip .sl version
On Sun, 14 Oct 2007, danglin at gcc dot gnu dot org wrote:
> After recently updating libgmp, I find that shared libraries that
> were linked against t
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-10-18 21:25
---
Subject: Bug 32021
Author: fxcoudert
Date: Thu Oct 18 21:25:21 2007
New Revision: 129463
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129463
Log:
PR libfortran/32021
* runtime/backtrace.
--- Comment #2 from dannysmith at users dot sourceforge dot net 2007-10-18
21:04 ---
The native compiler MSVC++ does not limit field alignment to 64 bits, but as
documented here
Windows Data Alignment on IPF, x86, and x64
http://msdn2.microsoft.com/en-us/library/Aa290049(VS.71).aspx
s
--- Comment #17 from hjl at lucon dot org 2007-10-18 20:55 ---
This patch:
http://gcc.gnu.org/ml/gcc-patches/2007-10/msg01047.html
makes 437.leslie3d 10% faster on Intel Core 2 Duo 64bit. But it is still 23%
slower than gcc 4.1 Red Hat.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?
--- Comment #4 from falk at debian dot org 2007-10-18 19:26 ---
Created an attachment (id=14370)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14370&action=view)
Vectorization dump file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33804
--- Comment #12 from bangerth at dealii dot org 2007-10-18 18:46 ---
Yes, sorry. I meant to report of course that I believe that it works now.
Thanks for your work!
W.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33489
--- Comment #7 from gdr at cs dot tamu dot edu 2007-10-18 18:46 ---
Subject: Re: configuration failure during native build
"bkoz at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
| Yo Gaby. Has this been worked out? Can we close this?
As long as we document that that build on MinGW
--- Comment #26 from burnus at gcc dot gnu dot org 2007-10-18 18:22 ---
If I understand it correctly, there is a difference between
IEEE 754-1989 and the current draft of IEEE 754 (duped IEEE 754r), see also
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/33055faef5
--- Comment #7 from pcarlini at suse dot de 2007-10-18 17:58 ---
Fixed for 4.2.3.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #6 from paolo at gcc dot gnu dot org 2007-10-18 17:58 ---
Subject: Bug 33807
Author: paolo
Date: Thu Oct 18 17:58:13 2007
New Revision: 129454
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129454
Log:
2007-10-18 Paolo Carlini <[EMAIL PROTECTED]>
PR libstd
--- Comment #5 from pcarlini at suse dot de 2007-10-18 17:48 ---
No, this is ADL at work. Browse the comments in stl_iterator.h for some
additional hints, or delve into the nuisances of ADL ;) Anyway, for mainline, I
will also add another fix, which avoid completely the comparison for st
--- Comment #6 from dcb314 at hotmail dot com 2007-10-18 17:33 ---
(In reply to comment #2)
> Although valgrind is correct that we are doing an uninitialized read, the code
> is actually working as designed and is correct.
I wish I had a pound for every time I've heard that ;->
> So ye
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-10-18 16:56 ---
Looks like they also appear on ppc-darwin too:
http://gcc.gnu.org/ml/gcc-testresults/2007-10/msg00818.html
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #4 from dominiq at lps dot ens dot fr 2007-10-18 16:40 ---
May I guess revision 129400?
--- trunk/gcc/ChangeLog 2007/10/17 00:46:27 129399
+++ trunk/gcc/ChangeLog 2007/10/17 01:05:50 129400
@@ -1,3 +1,10 @@
+2007-10-17 Alan Modra <[EMAIL PROTECTED]>
+
+ * con
--- Comment #4 from bldantes at comcast dot net 2007-10-18 16:40 ---
Why does adding the new libstdc++ template function:
template
inline bool operator!=(const allocator<_Tp>&, const allocator<_Tp>&);
fix the conflict between my template function:
template
bool operator != (const T&
--- Comment #6 from bkoz at gcc dot gnu dot org 2007-10-18 16:31 ---
Yo Gaby. Has this been worked out? Can we close this?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33603
--- Comment #3 from bkoz at gcc dot gnu dot org 2007-10-18 16:29 ---
Thanks for fixing this Paolo.
-benjamin
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33807
--- Comment #2 from bkoz at gcc dot gnu dot org 2007-10-18 16:27 ---
Parallel mode added bits/algorithmfwd.h.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31464
--- Comment #4 from manu at gcc dot gnu dot org 2007-10-18 16:27 ---
(In reply to comment #3)
> Your code is undefined. You have multiple assignments to pow_tmp without
> intervening sequence points.
>
Do you think it could be interesting to collect these kind of reports as
potential
--- Comment #3 from bkoz at gcc dot gnu dot org 2007-10-18 16:18 ---
Current mainline in parallel mode still has this fail, for the record.
Looking at the concepts code
From:
http://www.generic-programming.org/software/ConceptGCC/
include/bits/stl_numeric.h:
template<_GLIBCXX
--- Comment #7 from cabanasg at metro dot net 2007-10-18 16:13 ---
Subject: RE: Compile failing for xpdf 3.02
My problem occurs during the 'make' step, after the './configure' step.
How can I use 'g++' for linking during the 'make' step?
Thanks.
-Original Message-
From: pins
--- Comment #11 from bkoz at gcc dot gnu dot org 2007-10-18 16:06 ---
Wolfgang, I'm going to close this as fixed, ok? We are now checking
systematically for this issue as part of the 25_algo conformance testing. If
you find any more of these, please re-open.
best,
benjamin
--
bkoz
--- Comment #5 from bkoz at gcc dot gnu dot org 2007-10-18 16:04 ---
Done.
--
bkoz at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #6 from neil at gcc dot gnu dot org 2007-10-18 15:24 ---
(In reply to comment #5)
> I believe more than 160 bits are required to get even single-precision numbers
> right with DECIMAL_DIG digits precision and an exponent. I'm going to try and
> prove this by finding an exam
--- Comment #4 from bkoz at gcc dot gnu dot org 2007-10-18 15:23 ---
Subject: Bug 30085
Author: bkoz
Date: Thu Oct 18 15:22:58 2007
New Revision: 129442
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129442
Log:
2007-10-18 Benjamin Kosnik <[EMAIL PROTECTED]>
* include
--- Comment #4 from dominiq at lps dot ens dot fr 2007-10-18 15:23 ---
> while we expand a constant integral power to an optimal (as of the count of
> multiplications / additions) series of multiplications and additions.
It seems the difference is coming from something else. I'll bet th
--- Comment #1 from pault at gcc dot gnu dot org 2007-10-18 14:50 ---
(In reply to comment #0)
> A fix for both will be posted tonight, as long as the regtesting completes OK.
> Cheers
> Paul
This fix has been posted: http://gcc.gnu.org/ml/fortran/2007-10/msg00264.html
Paul
--
ht
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-10-18 14:46 ---
Your code is undefined. You have multiple assignments to pow_tmp without
intervening sequence points.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #3 from dominiq at lps dot ens dot fr 2007-10-18 14:37 ---
The PR started between revisions 129388 (works) and 129401 (does not).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33812
--- Comment #2 from dominiq at lps dot ens dot fr 2007-10-18 14:32 ---
The same occurs in 32 bit mode, see for instance
http://gcc.gnu.org/ml/gcc-testresults/2007-10/msg00804.html
[karma] dominiq/Desktop% gfc -O2 -ftree-vectorize -maltivec
/opt/gcc/_gcc-clean/gcc/testsuite/gcc.dg/vect/
--- Comment #2 from satyaakam at yahoo dot co dot in 2007-10-18 14:00
---
$gcc -ffloat-store round.c
$ ./a.out
-0.724062
$gcc -O3 -ffloat-store round.c
$ ./a.out
-0.541341
$gcc -O0 -ffloat-store round.c
./a.out
-0.724062
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33809
--- Comment #6 from pault at gcc dot gnu dot org 2007-10-18 13:54 ---
Fixed on trunk.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
Statu
--- Comment #13 from pault at gcc dot gnu dot org 2007-10-18 13:53 ---
Fixed on trunk
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
Statu
--- Comment #12 from hjl at lucon dot org 2007-10-18 13:44 ---
(In reply to comment #8)
> (In reply to comment #7)
> > Icc generates:
> >0: 66 0f 6e cf movd %edi,%xmm1
> >4: 66 0f f2 c1 pslld %xmm1,%xmm0
>
> Right, that's what icc's documentation w
--- Comment #1 from dominiq at lps dot ens dot fr 2007-10-18 13:40 ---
This seems to be a duplicate of PR33806, at least the ICE occurs at the same
point.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33812
--- Comment #10 from fxcoudert at gcc dot gnu dot org 2007-10-18 13:39
---
I think it's best to close this one. I only wanted to keep it open because I
thought I'd add the rest of the F2003 specifiers quickly, which didn't happen.
--
fxcoudert at gcc dot gnu dot org changed:
With current trunk (r129433) vectorizer testcases fail on powerpc64:
FAIL: gcc.dg/vect/vect-64.c (internal compiler error)
FAIL: gcc.dg/vect/vect-64.c (test for excess errors)
WARNING: gcc.dg/vect/vect-64.c compilation failed to produce executable
FAIL: gcc.dg/vect/vect-68.c (internal compiler err
--- Comment #14 from fxcoudert at gcc dot gnu dot org 2007-10-18 13:22
---
(In reply to comment #13)
> ../../../libgfortran/runtime/environ.c:312: warning: 'init_choice' defined but
> not used
> ../../../libgfortran/runtime/environ.c:339: warning: 'show_choice' defined but
> not used
T
--- Comment #1 from dominiq at lps dot ens dot fr 2007-10-18 12:55 ---
This regression affects also
gfortran.fortran-torture/execute/stack_varsize.f90.
A reduced test case is:
! Program to test the stack variable size limit.
program stack
call sub1
contains
! Local variables larg
--- Comment #5 from pault at gcc dot gnu dot org 2007-10-18 12:48 ---
Subject: Bug 33233
Author: pault
Date: Thu Oct 18 12:48:37 2007
New Revision: 129437
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129437
Log:
2007-10-18 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--- Comment #12 from pault at gcc dot gnu dot org 2007-10-18 12:45 ---
Subject: Bug 33733
Author: pault
Date: Thu Oct 18 12:44:57 2007
New Revision: 129436
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129436
Log:
2007-10-18 Paul Thomas <[EMAIL PROTECTED]>
Dominiq
--- Comment #11 from pault at gcc dot gnu dot org 2007-10-18 12:44 ---
Subject: Bug 33733
Author: pault
Date: Thu Oct 18 12:44:03 2007
New Revision: 129435
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129435
Log:
2007-10-18 Paul Thomas <[EMAIL PROTECTED]>
Dominiq
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Ke
--- Comment #1 from ubizjak at gmail dot com 2007-10-18 12:18 ---
What about -ffloat-store?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33809
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org
|dot org
This
$ cat assign_bug_3.f90
character(1) :: a(3) = ['1','2','3']
integer :: i = 1
a(2:3)(i:i) = a(1:2)(i:i)
print *, a
end
$ /irun/bin/gfortran assign_bug_3.f90; ./a
111
is the wrong result (should be 112)
The problem lies in gfc_check_dependency, where the assumption about substrings
i
--- Comment #16 from rguenth at gcc dot gnu dot org 2007-10-18 11:45
---
I have a patch.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedT
Run the test case on a x86_64 bit machine to see how gcc 4.1.2 mangles results
in under Linux
We have tested the test case using 3.2.3 Compiler on RHEL 3 on both 32 as well
as 64 bit OS it works well.
Compile the test case provided with the following steps
$gcc -g -I. -Wall -m64 -c bar.c
$g++ -g
Based on our investigation and the gcc documentation , we think there is a Bug
in GCC 4.1.2
Firstly, according to the doc and our understanding, the error caused by
rounding should be small, for instance, some systems may treat 5.000 as 4.998.
However, in our case, the difference is quit big, abou
--- Comment #2 from paolo at gcc dot gnu dot org 2007-10-18 10:00 ---
Subject: Bug 33807
Author: paolo
Date: Thu Oct 18 10:00:18 2007
New Revision: 129434
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129434
Log:
2007-10-18 Paolo Carlini <[EMAIL PROTECTED]>
PR libstd
--- Comment #1 from pcarlini at suse dot de 2007-10-18 09:55 ---
Note, the problem - trivial, the same we had in stl_iterator.h - is latent in
the older branches, dates back to the configurable allocator.h. The fix is safe
and will go in 4_2-branch too.
--
http://gcc.gnu.org/bugzill
--
pcarlini at suse dot de changed:
What|Removed |Added
Target Milestone|--- |4.2.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33807
--- Comment #5 from nathan at codesourcery dot com 2007-10-18 09:43 ---
Subject: Re: gcc warns that pure virtual class not explicitly
initialized
manu at gcc dot gnu dot org wrote:
> --- Comment #4 from manu at gcc dot gnu dot org 2007-10-17 11:26 ---
> Does this patch makes
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de
|dot org |
--- Comment #11 from ubizjak at gmail dot com 2007-10-18 09:14 ---
Fixed for 4.2.3 and 4.3.0.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status|
--- Comment #10 from uros at gcc dot gnu dot org 2007-10-18 09:12 ---
Subject: Bug 32961
Author: uros
Date: Thu Oct 18 09:12:30 2007
New Revision: 129433
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129433
Log:
PR target/32961
* config/i386/i386.c (ix86_expand_
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-10-18 08:49 ---
As far as I understand there is no way to encode currently typeof for
templates.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from irar at il dot ibm dot com 2007-10-18 08:33 ---
It works fine for me (and the loop gets SLPed) on powerpc-64 and x86_64.
Could you please run it with -fdump-tree-vect-details and attach the dump file?
Ira
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33804
--- Comment #3 from brakiozor at caramail dot com 2007-10-18 08:06 ---
I found this bug on a more complex program and I did an epurated code.
--
brakiozor at caramail dot com changed:
What|Removed |Added
--- Comment #2 from brakiozor at caramail dot com 2007-10-18 07:56 ---
Created an attachment (id=14369)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14369&action=view)
.ii file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33808
--- Comment #1 from brakiozor at caramail dot com 2007-10-18 07:55 ---
Created an attachment (id=14368)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14368&action=view)
source code
I was playing a little with template
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33808
Hello,
I'm working on Dev-cpp this is the output :
Compiler: Default compiler
Building Makefile: "C:\cygwin\tmp\Makefile.win"
Executing make...
make.exe -f "C:\cygwin\tmp\Makefile.win" all
g++.exe -c toto.cc -o toto
--- Comment #25 from fxcoudert at gcc dot gnu dot org 2007-10-18 07:38
---
(In reply to comment #24)
> So maybe approach the question differently. Which element in an array of NaNs
> is the smallest one and what is its value? If I pick any one element, its
> "value" is NaN. It does n
73 matches
Mail list logo
