It is many years since I last tried to use FORTRAN. I am now trying to use
gfortran to work through some examples from a book. Unfortunately I am being
hampered by a bug in gfortran. It usually causes SIGSEGV.
I couldn't spot this bug in a search, but this is probably due to my
inexperience.
$
--- Comment #1 from pault at gcc dot gnu dot org 2007-11-26 09:03 ---
Francois,
Many thanks for the report.
gfortran works correctly if you change cnames to assumed shape:
SUBROUTINE odfamilycnames(base,nfam,cnames)
TYPE(odbase),INTENT(in) :: base
INTEGER ,INTENT(o
--- Comment #31 from steven at gcc dot gnu dot org 2007-11-26 09:05 ---
I experimented with autoinc/-dec addressing modes for ARM earlier this year and
also saw smaller code size reductions (just over 2% overall on CSiBE). Looks
like an area worth working on :-)
Apparently this bug has
--- Comment #1 from dominiq at lps dot ens dot fr 2007-11-26 09:43 ---
Are you sure that you want 'y(l)' and not 'y(1)', i.e., the letter 'l' and not
the integer '1'? In the former case 'l' is not defined and the code is invalid.
The font used in my browser does allow to see the differen
--- Comment #2 from dominiq at lps dot ens dot fr 2007-11-26 09:45 ---
s/does allow/does not allow/
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34234
--- Comment #2 from pault at gcc dot gnu dot org 2007-11-26 09:47 ---
The patch below does the job but has yet to be regtested. I think that the
required F2003 survives correctly but I am having difficulty to find in the
ChangeLog where this was added. Tobias, what do you think?
Index:
--- Comment #11 from rguenther at suse dot de 2007-11-26 09:56 ---
Subject: Re: Empty macro definitions not considered
equal
On Sun, 25 Nov 2007, manu at gcc dot gnu dot org wrote:
> --- Comment #10 from manu at gcc dot gnu dot org 2007-11-25 22:59 ---
> (In reply to comment
--- Comment #3 from steven at gcc dot gnu dot org 2007-11-26 10:07 ---
Looks like a '1' vs. 'l' typo. Please close as INVALID if "y(1)" works.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-11-26 10:33 ---
Confirmed.
#1 0x00d3925d in get_callee_fndecl (call=0x2b29eaf32240)
at /space/rguenther/src/svn/trunk/gcc/tree.c:6592
6592 gcc_assert (TREE_CODE (call) == CALL_EXPR);
(gdb) call debug_generic_expr
--- Comment #4 from billm at melbpc dot org dot au 2007-11-26 10:38 ---
Thanks, this was indeed my typo (actually, it was a missed OCR error). It is
difficult to see the difference between '1' and 'l' in the font used on my
machine and despite my looking for this type of error, I missed
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-11-26 11:09 ---
Reduced testcase:
-funsafe-math-optimizations
double foo(void)
{
return __builtin_pow (0.0, -1.5);
}
which we (try to) expand as 1.0 / (sqrt (0.0) * 0.0) where sqrt (0.0) is
simplified to 0.0.
--
http://gcc
--- Comment #6 from hainque at adacore dot com 2007-11-26 12:02 ---
Subject: Re: [4.3 regression] FAIL: gnat.dg/release_unc_maxalign.adb execution
test
pinskia at gmail dot com wrote:
> Have you tried your @gcc.gnu.org account?
Humm, no. I tried the login/password combination sent to
--- Comment #19 from revitale at gcc dot gnu dot org 2007-11-26 12:15
---
Subject: Bug 34085
Author: revitale
Date: Mon Nov 26 12:15:02 2007
New Revision: 130435
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130435
Log:
Fix PR rtl-optimization/34085
Added:
trunk/gcc/tests
--- Comment #5 from rguenth at gcc dot gnu dot org 2007-11-26 12:30 ---
Subject: Bug 34233
Author: rguenth
Date: Mon Nov 26 12:30:40 2007
New Revision: 130436
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130436
Log:
2007-11-26 Richard Guenther <[EMAIL PROTECTED]>
PR
--- Comment #6 from rguenth at gcc dot gnu dot org 2007-11-26 12:35 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #12 from joseph at codesourcery dot com 2007-11-26 12:44
---
Subject: Re: Empty macro definitions not considered
equal
On Mon, 26 Nov 2007, rguenther at suse dot de wrote:
> I see. But sth changed in the cpp defaults for C++ in 4.3 as things
> that were previously warni
--- Comment #3 from jakub at gcc dot gnu dot org 2007-11-26 12:45 ---
Testing a patch.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|una
--
ubizjak at gmail dot com changed:
What|Removed |Added
CC|uros at gcc dot gnu dot org |
AssignedTo|unassigned at gcc dot gnu |ubizjak at gmail dot com
--- Comment #13 from manu at gcc dot gnu dot org 2007-11-26 13:03 ---
(In reply to comment #11)
> I see. But sth changed in the cpp defaults for C++ in 4.3 as things
> that were previously warnings (with 4.2) are now errors (with 4.3), such
> as this one or the macro re-definition.
>
Shifting the result of a cast does not produce the same results as when using
an intermediate variable.
short x = -1;
unsigned a = ((unsigned)(short)-1) >> 1;
unsigned tmp = (unsigned)x;
unsigned b = tmp >> 1;
unsigned c = ((unsigned)x) >> 1;
printf(
--- Comment #14 from rguenther at suse dot de 2007-11-26 13:15 ---
Subject: Re: Empty macro definitions not considered
equal
On Mon, 26 Nov 2007, manu at gcc dot gnu dot org wrote:
> --- Comment #13 from manu at gcc dot gnu dot org 2007-11-26 13:03 ---
> (In reply to comment
--- Comment #13 from rask at gcc dot gnu dot org 2007-11-26 13:20 ---
Subject: Bug 34174
Author: rask
Date: Mon Nov 26 13:20:19 2007
New Revision: 130438
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130438
Log:
PR target/34174
* config/fr30/fr30.c (fr30_move_do
--- Comment #2 from steven at gcc dot gnu dot org 2007-11-26 13:31 ---
Note, it is only a regression if it worked in a previous _released_ version of
GCC. You have not filled out the "known-to-..."-fields. Did this work in
earlier releases?
--
http://gcc.gnu.org/bugzilla/show_bug.
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-11-26 13:43 ---
Works for me. Please be more specific wrt the version of your compiler and the
used optimization flags.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #18 from steven at gcc dot gnu dot org 2007-11-26 13:43 ---
This is indeed fixed AFAICT.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from steven at gcc dot gnu dot org 2007-11-26 13:47 ---
So almost 7 years later we still have this bug report and nothing has happened
-- and the reporter isn't exactly persuing the issue either. Can we just
please close this one to avoid bug database polution?
--
ste
When given certain input and certain comparator, nth_element
enters in a loop or crash the program. The problem didn't
appear when using less. With the comparator:
not2 >
it failed with an array of {1,1,1,1,2,3,4}
worked with an array of {1,1,1,1,2,3,4,5}
failed again with {1,1,1,1,2,2,2,3}
U
--- Comment #6 from steven at gcc dot gnu dot org 2007-11-26 13:49 ---
The entire repo has been converted to SVN. This obviously doesn't fix the
almost 7 year old broken links, but is it enough reason to close this bug
report at least?
--
steven at gcc dot gnu dot org changed:
--- Comment #2 from drow at gcc dot gnu dot org 2007-11-26 13:50 ---
I don't know how you configured to get this. It looks like you've got
-fshort-enums by default; GCC can not be built with that option (although it
should be fixable).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- Comment #1 from pcarlini at suse dot de 2007-11-26 13:53 ---
*** This bug has been marked as a duplicate of 18640 ***
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #3 from pcarlini at suse dot de 2007-11-26 13:53 ---
*** Bug 34236 has been marked as a duplicate of this bug. ***
--
pcarlini at suse dot de changed:
What|Removed |Added
-
--- Comment #10 from steven at gcc dot gnu dot org 2007-11-26 13:53 ---
Again 1.5 years and zero progress. Kaz?
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #3 from burnus at gcc dot gnu dot org 2007-11-26 13:58 ---
> I think that the required F2003 survives correctly but
> I am having difficulty to find in the ChangeLog where this was added.
It was added for PR 30940.
> Tobias, what do you think?
Looks OK. At least the follow
--- Comment #5 from steven at gcc dot gnu dot org 2007-11-26 14:10 ---
Thanks for the effort you have put into this.
Your bug is probably fixed in GCC 4.3 (for which the entire dataflow module has
been rewritten from scratch) but it probably still exists in GCC 4.2.
As you have shown,
--- Comment #6 from steven at gcc dot gnu dot org 2007-11-26 14:12 ---
No test case, no progress. If this problem still exists, we need more than a
pointer to a build log to investigate the problem.
--
steven at gcc dot gnu dot org changed:
What|Removed
--- Comment #3 from steven at gcc dot gnu dot org 2007-11-26 14:14 ---
flow.c is gone, so if this bug is still around in GCC 4.3, it's somewhere else
now. For released versions of GCC this won't be fixed.
If you still see a problem, please file a new bug report about it.
--
steven
--- Comment #19 from steven at gcc dot gnu dot org 2007-11-26 14:17 ---
The recent improvements to the dataflow module and ra-conflicts may have fixed
this. Richi, you were the last to look at this bug report. Can you check if
there still is an issue to fix here?
--
steven at gcc d
--- Comment #3 from uros at gcc dot gnu dot org 2007-11-26 14:23 ---
Subject: Bug 34215
Author: uros
Date: Mon Nov 26 14:22:59 2007
New Revision: 130439
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130439
Log:
PR target/34215
* config/i386/i386.md (truncdfsf2):
--- Comment #2 from steven at gcc dot gnu dot org 2007-11-26 14:24 ---
g77 is dead, long live gfortran.
But does gfortran do the right thing here? Have Jakub's recent patches fixed
this perhaps?
--
steven at gcc dot gnu dot org changed:
What|Removed
--- Comment #4 from ubizjak at gmail dot com 2007-11-26 14:24 ---
Fixed for 4.2 branch, latent on mainline.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34215
--- Comment #10 from joseph at codesourcery dot com 2007-11-26 14:28
---
Subject: Re: Request for gcc-cvs-patches list
The feature request is just as relevant as it was. Part of the point of a
bug database is to track issues over time for as long as they are relevant
rather than ha
--- Comment #22 from steven at gcc dot gnu dot org 2007-11-26 14:28 ---
If even the FSF doesn't care to contribute its changes back properly, then why
should any one of the GCC developers?
--
steven at gcc dot gnu dot org changed:
What|Removed |Add
--- Comment #5 from steven at gcc dot gnu dot org 2007-11-26 14:34 ---
Andrew, still an issue here?
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
compile with g++ -lcrypt
#include
#include
#include
#include
using namespace std;
int main()
{
string username;
char salt[] = "$1$";
char * passwordold = new char [100];
char * passwordnew = new char [100];
cout << "Enter username: ";
cin >> username;
passwordold = getpass("Enter
--- Comment #11 from steven at gcc dot gnu dot org 2007-11-26 14:37 ---
The feature request is only worth a bug report if you actually intend to persue
the request. Just keeping bug reports open for tracking issues where nothing
happens is a Bad Thing.
I suggest you bring up your reque
--- Comment #1 from schwab at suse dot de 2007-11-26 14:42 ---
getpass returns a pointer to a static buffer that is overwritten by each call.
--
schwab at suse dot de changed:
What|Removed |Added
--- Comment #12 from joseph at codesourcery dot com 2007-11-26 14:43
---
Subject: Re: Request for gcc-cvs-patches list
On Mon, 26 Nov 2007, steven at gcc dot gnu dot org wrote:
> The feature request is only worth a bug report if you actually intend to
> persue
> the request. Just k
--- Comment #7 from jakub at gcc dot gnu dot org 2007-11-26 14:45 ---
Created an attachment (id=14641)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14641&action=view)
gcc43-pr34225-test.patch
Reduced testcase.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34225
--- Comment #5 from uros at gcc dot gnu dot org 2007-11-26 15:53 ---
Subject: Bug 34215
Author: uros
Date: Mon Nov 26 15:52:57 2007
New Revision: 130440
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130440
Log:
PR target/34215
* config/i386/i386.md (truncdfsf2):
--- Comment #6 from ubizjak at gmail dot com 2007-11-26 15:54 ---
Fixed.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status|ASSIGNED
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de
|dot org |
--- Comment #5 from aoliva at gcc dot gnu dot org 2007-11-26 16:24 ---
Fixed.
--
aoliva at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #5 from heinzl at iue dot tuwien dot ac dot at 2007-11-26
16:29 ---
Subject: Re: xgcc: Internal error: Segmentation fault (program cc1plus)
On Nov 25, 2007, at 3:49 AM, pinskia at gcc dot gnu dot org wrote:
> Can you show the full build log?
>
> Also can you try a newer
--- Comment #3 from aldot at gcc dot gnu dot org 2007-11-26 17:09 ---
I don't see an explicit -fshort-enums in my flags..
I'm using this:
CFLAGS_FOR_TARGET="-Os -pipe -fno-tree-loop-optimize -fno-tree-dominator-opts
-fno-strength-reduce -fno-branch-count-reg
-I/there/build_armeb/stagin
--- Comment #4 from aldot at gcc dot gnu dot org 2007-11-26 17:11 ---
While the configure explicitely lists armeb, the very same thing happens for
arm(el), fwiw.
Does perhaps one of -m{arch,abi}=iwmmxt imply -fshort-enums ?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34205
Trying to compile the attached preprocessed code (from WebKit) results in
../../../JavaScriptCore/wtf/HashTraits.h:61: error: static data member
'WTF::GenericHashTraitsBase::CommandImp*>::emptyValueIsZero' used, but not defined
../../../JavaScriptCore/wtf/HashTraits.h:62: error: static data member
--- Comment #10 from michael dot a dot richmond at nasa dot gov 2007-11-26
17:18 ---
Bug 33942 was marked as a duplicate of this one, but it is not fixed
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33583
--- Comment #1 from bero at arklinux dot org 2007-11-26 17:19 ---
Created an attachment (id=14642)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14642&action=view)
bzip2-ed preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34238
--- Comment #3 from rask at gcc dot gnu dot org 2007-11-26 17:27 ---
This seems to have started with revision 130333, but I don't think that change
is to blame:
(gdb) bt
#0 frv_secondary_reload_class (class=ICC_REGS, mode=BImode, x=0x2b0f0ec48d80,
in_p=0) at /n/12/rask/src/all/gcc/conf
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfir
--- Comment #10 from krebbel at gcc dot gnu dot org 2007-11-26 17:33
---
Subject: Bug 34081
Author: krebbel
Date: Mon Nov 26 17:33:23 2007
New Revision: 130441
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130441
Log:
2007-11-26 Andreas Krebbel <[EMAIL PROTECTED]>
P
--- Comment #11 from burnus at gcc dot gnu dot org 2007-11-26 17:42 ---
(In reply to comment #10)
> Bug 33942 was marked as a duplicate of this one, but it is not fixed
Can you enlighten us what is missing? As a configure test was added, it should
have found the lgamma function of "libm
--- Comment #15 from manu at gcc dot gnu dot org 2007-11-26 17:47 ---
(In reply to comment #14)
>
> I guess you are not explaining it wrong, but the situation is
> extremely confusing:
>
Oh, I fully agree on that. But it is exactly the same situation that was there
pre-4.3 for the C++
--- Comment #12 from fxcoudert at gcc dot gnu dot org 2007-11-26 17:58
---
(In reply to comment #10)
> Bug 33942 was marked as a duplicate of this one, but it is not fixed
PR33942 contains two different issues: first, that using GAMMA in your main
program is calling the system gamma fu
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-11-26 18:13 ---
(In reply to comment #1)
> getpass returns a pointer to a static buffer that is overwritten by each call.
Also getpass is not controlled by GCC so this is not a GCC bug.
--
http://gcc.gnu.org/bugzilla/show_bug.
--- Comment #4 from rask at gcc dot gnu dot org 2007-11-26 18:14 ---
Created an attachment (id=14643)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14643&action=view)
patch v1
This patch makes the ICE go away.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34226
--- Comment #11 from jakub at gcc dot gnu dot org 2007-11-26 18:16 ---
Fixed, thanks.
As a minor nit, the common formatting of ChangeLog entries mentioning PR is:
PR c++/34081
rather than
PR 34081/C++
--
jakub at gcc dot gnu dot org changed:
What|Remov
--- Comment #13 from michael dot a dot richmond at nasa dot gov 2007-11-26
18:16 ---
When I compile the following program under FreeBSD using the November 23
snapshot of gfortran:
PROGRAM pgamma
y = gamma(x)
END PROGRAM pgamma
I get the message:
/var/tmp//ccuAsOud.o(.text+0x1f): In f
--- Comment #7 from paolo at gcc dot gnu dot org 2007-11-26 18:25 ---
Subject: Bug 25913
Author: paolo
Date: Mon Nov 26 18:24:54 2007
New Revision: 130443
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130443
Log:
2007-11-26 Paolo Carlini <[EMAIL PROTECTED]>
PR libstd
--- Comment #8 from pcarlini at suse dot de 2007-11-26 18:26 ---
Fixed for 4.3.0.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|ASSIGNED
In building gcc with java on the solaris2.8 platform the build failed when this
was executed
./sparc-sun-solaris2.8/libjava/classpath/lib/gen-classlist.sh
The script used /bin/sh but sh on solaris does not support the -ef switch that
is used.
/bin/bash does support it. Perhaps the script should u
--- Comment #1 from tromey at gcc dot gnu dot org 2007-11-26 18:44 ---
I think this is fixed on svn trunk.
Also, the solaris build instructions already recommend using ksh
and not sh.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #5 from manu at gcc dot gnu dot org 2007-11-26 19:02 ---
Subject: Bug 23722
Author: manu
Date: Mon Nov 26 19:01:54 2007
New Revision: 130446
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130446
Log:
2007-11-26 Manuel Lopez-Ibanez <[EMAIL PROTECTED]>
PR c/
--- Comment #6 from manu at gcc dot gnu dot org 2007-11-26 19:06 ---
Fixed in GCC 4.3
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #3 from simartin at gcc dot gnu dot org 2007-11-26 19:38
---
Testing a patch.
--
simartin at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from sjackman at gmail dot com 2007-11-26 19:54 ---
Subject: Re: ICE in first_insn_after_basic_block_note on HPPA
This package (swingwt) no longer exists in Debian, so I don't have any
further information. If you would like to close the bug, that's fine
by me.
Cheers,
S
#include
template
int isnan(T t)
{
return __builtin_isnormal(t);
}
int f()
{
return isnan(std::string());
}
ice.cc: In function int isnan(T) [with T = std::basic_string, std::allocator >]:
ice.cc:6: internal compiler error: in expr_size, at explow.c:249
--
Summary:
--- Comment #8 from steven at gcc dot gnu dot org 2007-11-26 20:07 ---
.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|WAITING
--- Comment #2 from jakub at gcc dot gnu dot org 2007-11-26 20:18 ---
Small testcase:
// PR c++/34238
// { dg-do compile }
namespace
{
template struct A
{
static const bool a = true;
};
};
struct A<> a;
Investigating...
--
jakub at gcc dot gnu dot org changed:
--- Comment #3 from bero at arklinux dot org 2007-11-26 20:26 ---
Works in 4.2.x -- marking as regression
--
bero at arklinux dot org changed:
What|Removed |Added
Kn
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-11-26 20:32 ---
(In reply to comment #2)
> Small testcase:
> // PR c++/34238
> // { dg-do compile }
> namespace
> {
> template struct A
> {
> static const bool a = true;
> };
> };
> struct A<> a;
Hmm, I think this is inv
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-11-26 20:34 ---
(In reply to comment #1)
> Also, the solaris build instructions already recommend using ksh
> and not sh.
That is set CONFIG_SHELL to be ksh.
--
pinskia at gcc dot gnu dot org changed:
What|Remov
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-11-26 20:38 ---
So closing as such.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Sta
--- Comment #2 from sam at gcc dot gnu dot org 2007-11-26 20:46 ---
Ludovic,
are you sure that this applies when a tagged type is used as a completion of a
private type with discriminants having default expressions?
This case is handled specially in GNAT sources. sem_ch3.adb reads:
--- Comment #6 from sam at gcc dot gnu dot org 2007-11-26 20:52 ---
With mainline 4.1 20050619, invalid code is flagged:
test_246184.adb:9:17: not fully conformant with declaration at line 5
test_246184.adb:9:17: type of "x" does not match
Still fixed in GCC 4.3.0 SVN trunk.
--
sam
--- Comment #8 from mrs at apple dot com 2007-11-26 20:58 ---
Apparently there are two distinct ways to make this work, either, output a
reference to bdtest, or ensure that the linker tries to resolve commons from
libraries. Linux uses the later approach. To be portable, gfortran needs
--- Comment #2 from sam at gcc dot gnu dot org 2007-11-26 21:02 ---
Ludovic,
I don't think this is correct. You can use a subtype_mark here, but it is
defined as being a subtype_/name/, not any expression returning a type. See RM
3.2.2 and RM 3.5.
--
sam at gcc dot gnu dot org chang
--
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
--
sam at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |sam at gcc dot gnu dot org
|dot org
--- Comment #7 from burnus at gcc dot gnu dot org 2007-11-26 22:14 ---
Subject: Bug 34203
Author: burnus
Date: Mon Nov 26 22:14:20 2007
New Revision: 130451
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130451
Log:
2007-11-26 Steven G. Kargl <[EMAIL PROTECTED]>
* opt
--- Comment #5 from meissner at gcc dot gnu dot org 2007-11-26 22:33
---
Subject: Bug 34077
Author: meissner
Date: Mon Nov 26 22:33:30 2007
New Revision: 130453
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130453
Log:
Fix PR 34077
Added:
trunk/gcc/testsuite/gcc.target/i3
--
sam at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |sam at gcc dot gnu dot org
|dot org
--- Comment #8 from burnus at gcc dot gnu dot org 2007-11-26 22:54 ---
I just committed Steve's patch. Now gfortran uses -fno-backslash by default.
Now we only need to improve the warning:
For C gcc warns for:
char c[] = "\w";
a.c:3:14: warning: unknown escape sequence '\w'
gfortr
--- Comment #14 from burnus at gcc dot gnu dot org 2007-11-26 23:11 ---
(In reply to comment #13)
> When I compile the following program under FreeBSD using the November 23
> snapshot of gfortran:
> : undefined reference to `tgammaf'
> Is this the intended behavior?
Of cause not. The qu
--- Comment #6 from hjl at lucon dot org 2007-11-26 23:19 ---
We have changed fastcall behavior from gcc 3.4 to 4.1. For
---
#define FASTCALL __attribute((fastcall))
double FASTCALL f_dii( double p1d, int p2i, int p3i ){ return p1d +
(double)p2
i + (double)p3i; }
inttest_x;
int
--- Comment #9 from kargl at gcc dot gnu dot org 2007-11-26 23:21 ---
(In reply to comment #8)
> I just committed Steve's patch. Now gfortran uses -fno-backslash by default.
>
> Now we only need to improve the warning:
>
> For C gcc warns for:
>
> char c[] = "\w";
>
> a.c:3:14: war
p gamma
00416060 T tgamma
00403b10 T tgammaf
troutmask:sgk[225] gfc4x -v
Using built-in specs.
Target: x86_64-unknown-freebsd8.0
Configured with: ../gcc4x/configure --prefix=/home/sgk/work/4x
--enable-languages=c,fortran
Thread model: posix
gcc version 4.3.0 20071126 (experimental) (GCC)
--
sam at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |sam at gcc dot gnu dot org
|dot org
--- Comment #11 from kkojima at gcc dot gnu dot org 2007-11-27 00:22
---
I thought that the problem was fixed with the patches revision
61075 and 61803, though I missed the track of this PR. I'd like
to close this as fixed. Sorry for forgetting it for a long time.
--
kkojima at gcc
inline void *operator new (unsigned int, void *__p) throw ()
{
return __p;
}
struct A
{
A(int, double);
inline explicit A (int pattern, bool cs)
{
new (this) A (pattern, double(cs));
}
};
A test ()
{
const A a (42, true);
}
(gdb) bt
#0 get_prop_source_stmt (name=0xb7c5d478, singl
1 - 100 of 129 matches
Mail list logo
