--- Comment #2 from burnus at gcc dot gnu dot org 2007-11-08 10:32 ---
Two dummy arguments are distinguishable if neither is a subroutine and
neither is TKR compatible (5.1.1.2) with the other.
Does this mean, though, that a subroutine is or is not distinguishable from a
variable?
Attempt to compile pgplot (graphics library, ) with gfortran results in a
compiler error for one routine grfa.f.
Computer: Mac Book Pro (intel hardware) (I could not reproduce the error under
Linux and older
gfortran version)
Operating system: Mac OS 10.4
Compiler version:
When compiling any fortran program on Intel Darwin with -m64 -ffast-math, I get
the following warning:
ld64 warning: in
/opt/gcc/gcc4.3w/lib/gcc/i686-apple-darwin8/4.3.0/x86_64/crtfastmath.o, file is
not of required architecture
This yields the failure of gfortran.dg/pr32533.f90 and
--- Comment #11 from uros at gcc dot gnu dot org 2007-11-08 10:07 ---
Subject: Bug 32787
Author: uros
Date: Thu Nov 8 10:07:06 2007
New Revision: 129993
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=129993
Log:
PR target/32787
Backport from mainline:
--- Comment #1 from schwab at suse dot de 2007-11-08 09:38 ---
A variable that is supposed to survive longjmp must be declared volatile.
--
schwab at suse dot de changed:
What|Removed |Added
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org
|dot org
--- Comment #1 from manu at gcc dot gnu dot org 2007-11-08 10:56 ---
We cannot assume that people encountering the warning will have web access.
The warning can certainly be improved.
A list of valid replacements is as follows: Use: Instead of:
This doesn't actually explain what
--- Comment #2 from pcarlini at suse dot de 2007-11-08 11:05 ---
Let's add Benjamin in CC...
--
pcarlini at suse dot de changed:
What|Removed |Added
CC|
manu at gcc dot gnu dot org [EMAIL PROTECTED] writes:
| We cannot assume that people encountering the warning will have web access.
That is true. But, the majority of for those who do have a web
access, we should provide additional pointers.
Of course, the real solution is to leave these
--- Comment #3 from gdr at cs dot tamu dot edu 2007-11-08 11:23 ---
Subject: Re: warning in backward_warning.h is illegible
manu at gcc dot gnu dot org [EMAIL PROTECTED] writes:
| We cannot assume that people encountering the warning will have web access.
That is true. But, the
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-11-08 12:36
---
Can you get the same warning with a C program? And can you please post the
output of running gfortran with -v, so that we know what subprocesses are
invoked and what arguments they get passed?
--
fxcoudert at
--- Comment #12 from ubizjak at gmail dot com 2007-11-08 10:23 ---
(In reply to comment #8)
Thanks for the suggestion. I think it should use the assembler when
compiling with Sun Studio 12.
Please note that this part of gcc driver is only activated when -march=native
is added to
--- Comment #12 from richard dot guenther at gmail dot com 2007-11-08
09:08 ---
Subject: Re: [4.1/4.2/4.3 Regression] GCC generates wrong code for infinitely
recursive functions
On 11/7/07, Kenneth Zadeck [EMAIL PROTECTED] wrote:
This patch keeps recursive functions from being
PR32044 makes it for months impossible to compile the Linux kernel with gcc
4.3, but I'll leave the discussions who's technically at fault (and whether gcc
4.3 will ever be able to compile the Linux kernel) to the people who know more
about such things.
But the fact that the code emitted with -Os
--- Comment #15 from hubicka at gcc dot gnu dot org 2007-11-08 12:42
---
The problem here is that code assumes that variable without DEFAULT_DEF is not
in SSA. Arguments that are unused also do have DEFAULT_DEF=NULL, this patch
should fix it. I am testing it now.
Honza
Index:
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-11-08 12:45
---
(In reply to comment #0)
Since I did not find any way to attach the input files (grfa.f and
grpckg1.inc) to the present report
Once you write the report, there is a Create a New Attachment link on the
bugzilla
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-11-08 12:49
---
Does the same thing happen with C?
void foo(float *lhs, float*rhs) {
#pragma omp atomic
*lhs = *rhs + *lhs;
}
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from Christian dot Carli at cern dot ch 2007-11-08 12:51
---
Created an attachment (id=14506)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14506action=view)
Fortran source file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34026
--- Comment #3 from Christian dot Carli at cern dot ch 2007-11-08 12:53
---
Created an attachment (id=14507)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14507action=view)
Include File
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34026
--- Comment #16 from jakub at gcc dot gnu dot org 2007-11-08 12:54 ---
Continuing after the #c11 .. #c15 unrelated PR32540 comments with the original
bug:
I've built -r127926 and -r127927 cc1 and it seems this wasn't fixed just by
a side-effect.
Although p can be either retval of foo
--- Comment #4 from Christian dot Carli at cern dot ch 2007-11-08 13:05
---
Subject: Re: Internal compiler error: in gfc_add_modify, at
fortran/trans.c:159
Hello,
The two files needed to (re)produce the error message have been
uploaded
via the bugzilla interface.
I have
/execute/20071108-1.c: New test.
Added:
trunk/gcc/testsuite/gcc.c-torture/execute/20071108-1.c
Modified:
trunk/gcc/testsuite/ChangeLog
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32575
--- Comment #18 from jakub at gcc dot gnu dot org 2007-11-08 13:11 ---
I have also retested with the http://www.sqlite.org/gccbug32575.tar.gz
tarball and on the trunk it passes just fine with -O2.
--
jakub at gcc dot gnu dot org changed:
What|Removed
--- Comment #4 from manu at gcc dot gnu dot org 2007-11-08 13:13 ---
This is my proposal.
This header is deprecated and may be removed in the future. Please, consider
using an equivalent, non-deprecated interface for the requested functionality.
To disable this warning use
-languages=c,c++,fortran,objc,obj-c++
--with-gmp=/sw --with-libiconv-prefix=/sw --with-system-zlib
--x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib
Thread model: posix
gcc version 4.3.0 20071108 (experimental) (GCC)
COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.4' '-v' '-m64' '-ffast-math
Happens on x86-linux, with both -m32 and -m64. Spotted by running the testsuite
with -fdefault-integer-8.
$ cat intrinsic_bitops.f90
implicit none
integer(kind=4) :: k, o
o = 0
k = 12
if (ishft (k, o+2_8) .ne. 48_8) call abort
end
$ gfortran -O2 intrinsic_bitops.f90
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot
|dot org
--- Comment #15 from nickc at gcc dot gnu dot org 2007-11-08 13:44 ---
Subject: Bug 16350
Author: nickc
Date: Thu Nov 8 13:44:09 2007
New Revision: 12
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=12
Log:
PR target/16350
* config.gcc: For arm*b-* define
--- Comment #19 from manu at gcc dot gnu dot org 2007-11-08 14:22 ---
(In reply to comment #16)
One possible solution would be to annotate the division by the expected value
of the result. Division expanders then may decide whether to expand to
machine
instruction/libcall or to
--- Comment #30 from fxcoudert at gcc dot gnu dot org 2007-11-08 14:08
---
(In reply to comment #29)
gfortran.fortran-torture/execute/intrinsic_bitops.f90
This one is now PR34028, for which I have a patch. The others one aren't ICEs,
but matches my regexp because they have internal
--- Comment #1 from holger dot hopp at sap dot com 2007-11-08 13:41 ---
Created an attachment (id=14508)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14508action=view)
reproducer
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34029
I discovered following internal compiler error in gcc 4.3.0 (trunk).
The cause is the svn change 125925.
The title sounds to be similar to bug 34018, but the removal of change
125925 does not help for bug 34018. So this bug must be something
different.
gcc version: gcc 4.3.0 svn revision 125925
--- Comment #16 from nickc at redhat dot com 2007-11-08 13:47 ---
Hi Bernhard,
I have applied your patch. I made one small change: I adjusted the new
comments in the header files to:
/* TARGET_BIG_ENDIAN_DEFAULT is set in
config.gcc for big endian configurations. */
This
--- Comment #18 from manu at gcc dot gnu dot org 2007-11-08 13:47 ---
(In reply to comment #4)
(probably the condition check is too conservative
so this isn't fully cooked yet):
Way too conservative because even if you don't have the opcode, sometimes code
can be produced
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-11-08 14:04
---
Testcase that doesn't require -fdefault-integer-8:
$ cat a.f90
program test
integer(kind=8) nvec(10), ivec(10), nclass
integer i
nvec(:)= 1
ivec(:) = 0
call zbase(nvec,ivec,10)
write(*,'(10I3)') ivec
--- Comment #17 from buytenh at wantstofly dot org 2007-11-08 14:26 ---
Subject: Re: gcc only understands little endian ARM systems
When I (not Bernhard) wrote the original patch, Richard Earnshaw
didn't like the approach. See:
--- Comment #20 from rakdver at kam dot mff dot cuni dot cz 2007-11-08
14:46 ---
Subject: Re: [4.3 regression] udivdi3 counterproductive, unwarranted use
--- Comment #19 from manu at gcc dot gnu dot org 2007-11-08 14:22 ---
(In reply to comment #16)
One possible solution
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-11-08 15:35
---
Fixed.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from benoit dot hudson at gmail dot com 2007-11-08 15:35
---
The fact that the error appears in backward_warning.h is another annoyance,
which is probably why the overly long descriptive message is there. Better
would be that #include ext/hash_set would only report
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-11-08 15:33
---
Subject: Bug 34028
Author: fxcoudert
Date: Thu Nov 8 15:33:23 2007
New Revision: 130003
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=130003
Log:
PR fortran/34028
* trans-intrinsic.c
--- Comment #12 from rsandifo at gcc dot gnu dot org 2007-11-08 16:10
---
Interesting. Something platform-specific must be going wrong here.
The original build failure shouldn't have happened even without
the attached patch because ggc-none.o should provide a definition
of ggc_free.
--- Comment #7 from burnus at gcc dot gnu dot org 2007-11-08 15:28 ---
Subject: Bug 33917
Author: burnus
Date: Thu Nov 8 15:28:30 2007
New Revision: 130002
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=130002
Log:
2007-11-08 Tobias Burnus [EMAIL PROTECTED]
PR
--- Comment #4 from burnus at gcc dot gnu dot org 2007-11-08 15:29 ---
Both problems fixed on the trunk (4.3.0). Other branches are not affected as
PROCEDURE is new.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from burnus at gcc dot gnu dot org 2007-11-08 15:36 ---
Sorry, the check in was for PR 33917.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33917
--- Comment #5 from burnus at gcc dot gnu dot org 2007-11-08 15:39 ---
The check-in was the following (note the wrong bug number).
Author: burnus
Date: Thu Nov 8 15:28:30 2007
New Revision: 130002
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=130002
Log:
2007-11-08 Tobias
--- Comment #1 from hjl at lucon dot org 2007-11-08 17:12 ---
I verified that it isn't fixed in gcc 4.3.0.
--
hjl at lucon dot org changed:
What|Removed |Added
When compiling this sample code
int myvar;
int foo(int mynum)
{
if void *)0) ==
(
myvar ((1U0) mynum)
)
)
(mynum 0)
)
{
return 1;
}
return 0;
}
with GCC-4.1.1, 4.1.2, 4.2.2, I get:
internal compiler error:
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-11-08 17:59
---
I'm not sure about the wording, but the following patch does what you want:
Index: interface.c
===
--- interface.c (revision 129869)
+++
--- Comment #15 from zadeck at naturalbridge dot com 2007-11-08 16:49
---
fixed
--
zadeck at naturalbridge dot com changed:
What|Removed |Added
Status|NEW
--- Comment #14 from zadeck at naturalbridge dot com 2007-11-08 16:48
---
Subject: Re: [4.1/4.2/4.3 Regression] GCC generates
wrong code for infinitely recursive functions
Richard Guenther wrote:
On 11/7/07, Kenneth Zadeck [EMAIL PROTECTED] wrote:
This patch keeps recursive
--- Comment #10 from paolo dot bonzini at lu dot unisi dot ch 2007-11-08
16:32 ---
Subject: Re: [4.3 Regression] can't find a register
in class 'GENERAL_REGS' while reloading 'asm'
ubizjak at gmail dot com wrote:
--- Comment #9 from ubizjak at gmail dot com 2007-11-07 18:56
The C++ Standard, in section 22.2.6.1.1, says that if money_get::do_get
recognizes a valid sequence then it does not modify the ios_base::iostate
variable passed to it. That variable should be set to eofbit only if do_get
has not recognized a valid sequence and no more characters are available.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org
|dot org
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #13 from zadeck at gcc dot gnu dot org 2007-11-08 16:46 ---
Subject: Bug 33826
Author: zadeck
Date: Thu Nov 8 16:45:53 2007
New Revision: 130006
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=130006
Log:
2007-11-07 Kenneth Zadeck [EMAIL PROTECTED]
PR
--- Comment #9 from jakub at gcc dot gnu dot org 2007-11-08 17:05 ---
Bootstrapped/regtested on x86_64-linux, ppc64-linux (-m64 default) and
ia64-linux. No regressions. Could you please send it to gcc-patches?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34012
Building with -std=c++0x causes __STRICT_ANSI__ to be defined. The new C++
headers expect the system C headers (ctype.h, stdio.h, etc.,) to declare
certain functions (isblank(), snprintf(), etc.) that are part of C++0x. The
system C headers that are part of cygwin aren't privy to this. The result
--- Comment #1 from john dot xia at esstech dot com 2007-11-08 18:38
---
Created an attachment (id=14509)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14509action=view)
preprocessed file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32886
--- Comment #2 from john dot xia at esstech dot com 2007-11-08 18:39
---
../../gcc-4.2.2/gcc/libgcc2.c: In function '__neghi2':
../../gcc-4.2.2/gcc/libgcc2.c:80: error: unrecognizable insn:
(insn 40 39 41 3 ../../gcc-4.2.2/gcc/libgcc2.c:77 (set (reg:QI 57)
(const_int 0 [0x0]))
--- Comment #4 from dominiq at lps dot ens dot fr 2007-11-08 18:43 ---
Subject: Re: Warning when compiling with -m64 -ffast-math
on Intel Darwin
Hmmm, this should have been compiled with -m64. Can you attach your build log
for building GCC?
The full log or only the part
The code in c-lex.c that handles string concatenation allows weird,
and from what I can tell invalid, ObjC string concatentations.
In particular it allows any number of @s, and trailing @s.
E.g., it treats these as valid strings:
foo @ bar
@foo @
--
Summary: compiler
Test perlbmk from SPEC CPU2000 hangs on powerpc-linux and i686-linux when
compiled with -O2 -fno-tree-dce -fno-tree-dominator-opts. I didn't manage to
get a minimized testcase that fails on both targets, but do have two slightly
different tests. Both of them hang in the loop that begins for
--- Comment #1 from janis at gcc dot gnu dot org 2007-11-08 18:49 ---
Created an attachment (id=14510)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14510action=view)
test for x86-linux
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34034
--- Comment #2 from janis at gcc dot gnu dot org 2007-11-08 18:49 ---
Created an attachment (id=14511)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14511action=view)
test for powerpc-linux
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34034
--- Comment #5 from dominiq at lps dot ens dot fr 2007-11-08 18:50 ---
Subject: Re: Warning when compiling with -m64 -ffast-math
on Intel Darwin
this should have been compiled with -m64.
Apparently it has not been with -m64:
/opt/gcc/i686-darwin/./gcc/xgcc
--- Comment #2 from sebor at roguewave dot com 2007-11-08 18:52 ---
Yes, I can confirm that, Paolo. The Apache C++ Standard Library behaves the
same (i.e., the facet sets eofbit).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34031
--- Comment #1 from pcarlini at suse dot de 2007-11-08 18:56 ---
Note that the library has autoconf tests for those C99 functions, which,
however, are run with the default C++98 compiler. Now I'm confused by this
__STRICT_ANSI__ thing on cygwin, does it mean that with -std=gnu++0x
--- Comment #3 from pcarlini at suse dot de 2007-11-08 18:59 ---
Thanks Martin. Therefore, let's confirm this bug to suspend it immediately
until our DR get resolved.
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-11-08 18:59
---
Created an attachment (id=14512)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14512action=view)
Patch to add this feature
This patch does the job. I'll wait until next stage 1 to submit it.
--
--
pcarlini at suse dot de changed:
What|Removed |Added
CC|sebor at roguewave dot com |
Status|NEW |SUSPENDED
--- Comment #9 from ralf dot guetlein at web dot de 2007-11-08 21:42
---
(In reply to comment #8)
also fails on 4.2.1
is this bug still present in 4.2.2?
Acc. to my obervations the error only shows up when not all auto variables can
be mapped to registers, and additional variables
Test 176.gcc from SPEC CPU2000 fails at execution time on powerpc-linux when
compiled with -O2 -ftree-vectorize -maltivec. The stack frame is corrupted
but the last few entries are several recursive calls of reload which calls
spill_failure which calls asm_noperands. This is odd, but when
--- Comment #2 from brian dot e dot bliss at intel dot com 2007-11-09
00:06 ---
Subject: RE: Bogus codegen for openmp atomics w/ indirects operands on IPF
The C example looks correct (but you have to use the += operator to get
a legal example, which might have affected things):
%
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2007-11-08 23:56
---
Hi Christian,
I've tried on i686-darwin, and it works fine with GNU Fortran (GCC) 4.3.0
20071017. I will thus close this report as fixed, and I suggest you download
more recent binaries (either from macresearch,
--- Comment #1 from dje at google dot com 2007-11-09 00:57 ---
I looked into what's going on here.
This is a problem in the i386.md lshr+zext combiner patterns (or a problem in
the combine pass, depending on one's point of view). There are patterns in
i386.md that are supposed to
--- Comment #3 from sergey dot gcc at comrades dot id dot au 2007-11-09
01:14 ---
// Workaround:
class a
{
public:
templateclass T
operator T () const
throw(typename ::boost::disable_if
::boost::is_sameT, ref_t const ::type *)
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
Test eon from SPEC CPU2000 fails to build on powerpc64-linux with both -m32 and
-m64 and -fnon-call-exceptions -ffast-math -fno-gcse with an ICE in
calc_dfs_tree at dominance.c:393
Minimized test case:
class One {
public:
One () { e[0] = e[1] = 0.0; }
double e[2];
};
template class T
--- Comment #2 from burnus at gcc dot gnu dot org 2007-11-08 20:46 ---
I think we already emit the error you'd like (and probably have done so for
quite some time):
Error: Function 'fn' at (1) must be PURE
Ok. Seemingly it has been fixed by collateral damage of a pure patch during
--- Comment #3 from dannysmith at gcc dot gnu dot org 2007-11-08 20:20
---
Subject: Bug 33774
Author: dannysmith
Date: Thu Nov 8 20:20:02 2007
New Revision: 130024
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=130024
Log:
PR target/33774
* config/i386/cygming.h
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2007-11-09 01:25
---
The patch below should do it.
Index: expr.c
===
--- expr.c (revision 129869)
+++ expr.c (working copy)
@@ -1981,11 +1981,7 @@
--- Comment #3 from dannysmith at users dot sourceforge dot net 2007-11-08
19:18 ---
The newlib stdio.h puts [v]snprintf declarations within a #ifndef
__STRICT_ANSI__ block.
Likewise for cygwin's ctype.h and isblank
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34032
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-11-08 19:16
---
I think we already emit the error you'd like (and probably have done so for
quite some time):
$ cat k.f90
function f2 (fn, i)
integer :: i, fn
character (len = fn (i)) :: f2
end function f2
$
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-11-08 18:40 ---
/opt/gcc/gcc4.3w/lib/gcc/i686-apple-darwin8/4.3.0/x86_64/crtfastmath.o, file is
not of required architecture
Hmmm, this should have been compiled with -m64. Can you attach your build log
for building GCC?
--
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-11-08 18:37 ---
This might have been already fixed in 4.2.3.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from fxcoudert at gcc dot gnu dot org 2007-11-08 23:51
---
(In reply to comment #7)
However, most run time
libraries do the simple thing when they see io-redirection - they close the
stream file and re-open it as a ordinary file. Is there any reason GFORTRAN
could
Test eon from SPEC CPU2000 fails to build with -O2 -fnon-call-exceptions
-ffast-math -fsignaling-nans due to an ICE for control flow in the middle of a
basic block. Two minimized tests show different warnings on both powerpc-linux
and i686-linux:
elm3b145% /opt/gcc-nightly/trunk/bin/g++ -O2
--- Comment #4 from dannysmith at users dot sourceforge dot net 2007-11-08
20:21 ---
Fixed on trunk.
Danny
--
dannysmith at users dot sourceforge dot net changed:
What|Removed |Added
--- Comment #7 from dir at lanl dot gov 2007-11-08 19:56 ---
When I changed it to directly open the file, it was happy. You are right, of
course, backspacing a stream file is not permitted. However, most run time
libraries do the simple thing when they see io-redirection - they close
--- Comment #8 from tromey at gcc dot gnu dot org 2007-11-08 19:51 ---
Fixed on trunk.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
Known to work|
--- Comment #4 from pcarlini at suse dot de 2007-11-08 19:33 ---
Ok, at least we have a work around, then. About Cygwin, probably the reason is
that those features are made available as extensions not at C99 facilities (I'm
sure that this was the case at some point for many snprintf
--- Comment #11 from fxcoudert at gcc dot gnu dot org 2007-11-08 19:20
---
Subject: Bug 33739
Author: fxcoudert
Date: Thu Nov 8 19:19:50 2007
New Revision: 130016
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=130016
Log:
PR fortran/33739
* scanner.c
--- Comment #1 from pcarlini at suse dot de 2007-11-08 18:37 ---
Hi Martin. I think this inconsistency between num_get and money_get is just a
special case of our DR 585:
http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#585
and that setting eofbit when end of file after
--- Comment #2 from eric dot niebler at gmail dot com 2007-11-08 19:16
---
I didn't know about -std=gnu++0x. That seems to work. -std=c++0x doesn't.
FWIW, the stock gcc that comes with cygwin is 3.4:
$ g++ --version
g++ (GCC) 3.4.4 (cygming special, gdc 0.12, using dmd 0.125)
--- Comment #12 from fxcoudert at gcc dot gnu dot org 2007-11-08 19:20
---
Fixed.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2007-11-08 19:26
---
Interestingly, I can't reproduce your problem on x86_64-linux. I'll try tonight
with my own i686-darwin.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34026
--- Comment #4 from andreast at gcc dot gnu dot org 2007-11-08 19:34
---
The mentioned patch does not work properly, it only handles soft-float when
no-long-double-128 is used.
Working on a better one which should support both, 'double == long double' and
long double == 128.
--
--- Comment #7 from tromey at gcc dot gnu dot org 2007-11-08 19:50 ---
Subject: Bug 30297
Author: tromey
Date: Thu Nov 8 19:50:38 2007
New Revision: 130018
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=130018
Log:
gcc/cp
2007-11-08 Andrew Pinski [EMAIL PROTECTED]
PR
--- Comment #11 from bonzini at gnu dot org 2007-11-08 19:56 ---
-fforce-addr for SPECfp is neutral, with big improvements in equake (and a
little on swim+lucas, but the latter has huge fluctuations).
SPECint drops from 1156 to 1130, with clear changes for the worse as
highlighted by
--- Comment #12 from bonzini at gnu dot org 2007-11-08 19:58 ---
Who prepares the patch? :-)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33713
1 - 100 of 110 matches
Mail list logo
