[Bug fortran/34234] New: Incorrect code generated by gfortran (missing code)
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. $ gfortran --version GNU Fortran (GCC) 4.2.1 (Ubuntu 4.2.1-5ubuntu4) Copyright (C) 2007 Free Software Foundation, Inc. If I compile the following (using only -Wall), all appears to be o.k.: Subroutine fn(f, b, y, m) dimension f(m,m) y = b / f(1,1) return end However, change it to this: Subroutine fn(f, b, y, m) dimension f(m,m), b(m), y(m) y(l) = b(1) / f(1,1) return end and the generated code is wrong. The key point is the treatment of the index of y(1). It appears that it is intended to be copied to the local stack frame and used later. In the (second) version above, the copying to the local stack frame is skipped in the generated code. The following assembler code is generated from the second version by $ gfortran -S subs2.f The instruction which references an uninitialised part of the stack is indicated by "***". It appears that the code would be correct if $1 (i.e. the index of y(1)) had been previously stored in -4(%ebp). .file "subs2.f" .text .globl fn_ .type fn_, @function fn_: pushl %ebp movl%esp, %ebp subl$24, %esp movl20(%ebp), %eax movl(%eax), %eax testl %eax, %eax js .L2 jmp .L4 .L2: .L4: movl20(%ebp), %eax movl(%eax), %eax testl %eax, %eax js .L5 jmp .L7 .L5: .L7: movl20(%ebp), %eax movl(%eax), %eax movl%eax, -20(%ebp) cmpl$0, -20(%ebp) js .L8 movl-20(%ebp), %eax movl%eax, -24(%ebp) jmp .L10 .L8: movl$0, -24(%ebp) .L10: movl-24(%ebp), %eax movl%eax, -20(%ebp) movl20(%ebp), %eax movl(%eax), %eax imull -20(%ebp), %eax testl %eax, %eax js .L11 jmp .L13 .L11: .L13: movl-20(%ebp), %edx notl%edx movl-4(%ebp), %ecx *** subl$1, %ecx movl12(%ebp), %eax flds(%eax) movl-20(%ebp), %eax addl$1, %eax leal(%eax,%edx), %edx movl8(%ebp), %eax flds(%eax,%edx,4) fdivrp %st, %st(1) movl16(%ebp), %eax fstps (%eax,%ecx,4) leave ret .size fn_, .-fn_ .ident "GCC: (GNU) 4.2.1 (Ubuntu 4.2.1-5ubuntu4)" .section.note.GNU-stack,"",@progbits -- Summary: Incorrect code generated by gfortran (missing code) Product: gcc Version: 4.2.1 Status: UNCONFIRMED Severity: major Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: billm at melbpc dot org dot au GCC build triplet: 4.2.1-5ubuntu4 GCC host triplet: Linux Ubuntu GCC target triplet: ix86 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34234
[Bug fortran/34231] Scalar actual not distinguished from assumed size formal argument
--- 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(out) :: nfam CHARACTER(*),INTENT(out) :: cnames(:) <= Assumed size not working here nfam=0 cnames(1:nfam)=' ' write(*,*) 'odfamilycnames' END SUBROUTINE This is a double bug because gfortran is failing to recognise the error in the call: CALL odfamilycnames(base,i,cname) Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-11-26 09:03:54 date|| Summary|wrong selection of a routine|Scalar actual not |belonging to an interface |distinguished from assumed ||size formal argument http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34231
[Bug tree-optimization/31849] [4.3 Regression] Code size regression caused by fix to PR 31360
--- 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 to do with code size, so let't make it block bug 16996. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31849
[Bug fortran/34234] Incorrect code generated by gfortran (missing code)
--- 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 difference between the two characters. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34234
[Bug fortran/34234] Incorrect code generated by gfortran (missing code)
--- 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
[Bug fortran/34231] Scalar actual not distinguished from assumed size formal argument
--- 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: gcc/fortran/interface.c
===
*** gcc/fortran/interface.c (révision 130286)
--- gcc/fortran/interface.c (copie de travail)
*** compare_actual_formal (gfc_actual_arglis
*** 1782,1788
|| f->sym->as->type == AS_DEFERRED);
if (f->sym->ts.type == BT_CHARACTER && a->expr->ts.type == BT_CHARACTER
! && a->expr->rank == 0
&& f->sym->as && f->sym->as->type != AS_ASSUMED_SHAPE)
{
if (where && (gfc_option.allow_std & GFC_STD_F2003) == 0)
--- 1782,1788
|| f->sym->as->type == AS_DEFERRED);
if (f->sym->ts.type == BT_CHARACTER && a->expr->ts.type == BT_CHARACTER
! && a->expr->rank == 0 && !ranks_must_agree
&& f->sym->as && f->sym->as->type != AS_ASSUMED_SHAPE)
{
if (where && (gfc_option.allow_std & GFC_STD_F2003) == 0)
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
CC||burnus at gcc dot gnu dot
||org
AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org
|dot org |
Status|NEW |ASSIGNED
Last reconfirmed|2007-11-26 09:03:54 |2007-11-26 09:47:12
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34231
[Bug preprocessor/33907] Empty macro definitions not considered equal
--- 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 #8) > > > > Tom can probably do this. But I belive the patch will not work, > > as CPP_PEDANTIC is set to true by the C++ frontend now. > > BTW, the patch works for the revision I diffed against. The testcases included > in the patch pass. 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. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33907
[Bug fortran/34234] Incorrect code generated by gfortran (missing code)
--- 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 Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34234
[Bug middle-end/34233] ICE: get_callee_fndecl, at tree.c:6592
--- 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 (call) 0.0 #3 0x00724430 in expand_builtin_pow (exp=0x2b29eb100120, target=0x2b29eb1052c0, subtarget=0x0) at /space/rguenther/src/svn/trunk/gcc/builtins.c:2941 2941 op = expand_builtin (call_expr, NULL_RTX, subtarget, mode, 0); (gdb) call debug_generic_expr (exp) __builtin_pow (0.0, -1.5e+0) tree call_expr = build_call_expr (fn, 1, narg0); op = expand_builtin (call_expr, NULL_RTX, subtarget, mode, 0); so yet-another-case where we fold the builtin (call_expr) to a constant. I have a patch. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-11-26 10:33:36 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34233
[Bug fortran/34234] Incorrect code generated by gfortran (missing code)
--- 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 it. I was misled because the full program produced correct results (or appeared to be correct) when compiled with the Intel ifort compiler. Thanks for resolving this so quickly. -- billm at melbpc dot org dot au changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34234
[Bug middle-end/34233] ICE: get_callee_fndecl, at tree.c:6592
--- 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.gnu.org/bugzilla/show_bug.cgi?id=34233
[Bug ada/34173] [4.3 regression] FAIL: gnat.dg/release_unc_maxalign.adb execution test
--- 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 me more than two years ago :) I'm obviously not very used to doing these operations and will give my @gcc.gnu.org a try. Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34173
[Bug rtl-optimization/34085] ICE with -freorder-blocks-and-partition
--- 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/testsuite/gcc.dg/tree-prof/bb-reorg.c Modified: trunk/gcc/ChangeLog trunk/gcc/bb-reorder.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34085
[Bug middle-end/34233] ICE: get_callee_fndecl, at tree.c:6592
--- 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 middle-end/34233 * builtins.c (expand_builtin_pow): Use expand_expr to expand the result of build_call_expr. * gcc.dg/pr34233.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/pr34233.c Modified: trunk/gcc/ChangeLog trunk/gcc/builtins.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34233
[Bug middle-end/34233] [4.3 Regresion] ICE: get_callee_fndecl, at tree.c:6592
--- 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|RESOLVED Keywords||ice-on-valid-code Known to fail||4.3.0 Known to work||4.2.3 Resolution||FIXED Summary|ICE: get_callee_fndecl, at |[4.3 Regresion] ICE: |tree.c:6592 |get_callee_fndecl, at ||tree.c:6592 Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34233
[Bug preprocessor/33907] Empty macro definitions not considered equal
--- 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 warnings (with 4.2) are now errors (with 4.3), such > as this one or the macro re-definition. That would have been the fix for bug 24924. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33907
[Bug c++/34213] [4.2/4.3 Regression] static member function in anonymous namespace can't be used as template argument
--- 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|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2007-11-25 03:05:54 |2007-11-26 12:45:41 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34213
[Bug target/34215] [4.2 Regression] ICE in assign_386_stack_local, at config/i386/i386.c:13481
-- 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 |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Known to work|4.1.2 |4.1.2 4.3.0 Last reconfirmed|-00-00 00:00:00 |2007-11-26 12:51:08 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34215
[Bug preprocessor/33907] Empty macro definitions not considered equal
--- 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. > (My english must be getting pretty bad lately, please let me know what part is not clear. Perhaps we should put up some Developers FAQ in the wiki.) * C++ front-end did not and does not enable -pedantic-errors by default. * C++ front-end makes pedwarns to be emitted as errors. * -pedantic-errors sets the variable pedantic to true and makes pedwarns to be emitted as errors. * C++ front-end in 4.3 now makes CPP's pedwarns to be emitted as errors. * C++ front-end in 4.3 did not and does not set CPP's pedantic flag to true, you still need -pedantic or -pedantic-errors for that. * So, a CPP's pedwarn that is guarded by the pedantic flag still requires an explicit -pedantic or -pedantic-errors in the command-line to be generated (as error by default, as a warning with -fpermissive). Please, I am banging my head against the wall since comment #7 of why this is not clear. So, please, let me know which part I am explaining wrong. -- manu at gcc dot gnu dot org changed: What|Removed |Added Last reconfirmed|2007-11-25 22:23:50 |2007-11-26 13:03:29 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33907
[Bug c/34235] New: short variable cast to unsigned int fails to right shift as unsigned
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("a:%x b:%x c:%x",a,b,c);
produces
a:7fff b:7fff c:
while I'd expect the result for c to be the same as the other two.
Similar behavior appears to occur with other types, as long as the source type
is shorter than the target type and the target type is int or longer.
--
Summary: short variable cast to unsigned int fails to right shift
as unsigned
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: fgccbz1 at greynode dot net
GCC host triplet: x86_64-redhat-linux
GCC target triplet: x86_64-redhat-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34235
[Bug preprocessor/33907] Empty macro definitions not considered equal
--- 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 #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.
> >
>
> (My english must be getting pretty bad lately, please let me know what part is
> not clear. Perhaps we should put up some Developers FAQ in the wiki.)
>
> * C++ front-end did not and does not enable -pedantic-errors by default.
>
> * C++ front-end makes pedwarns to be emitted as errors.
>
> * -pedantic-errors sets the variable pedantic to true and makes pedwarns to be
> emitted as errors.
>
> * C++ front-end in 4.3 now makes CPP's pedwarns to be emitted as errors.
>
> * C++ front-end in 4.3 did not and does not set CPP's pedantic flag to true,
> you still need -pedantic or -pedantic-errors for that.
>
> * So, a CPP's pedwarn that is guarded by the pedantic flag still requires an
> explicit -pedantic or -pedantic-errors in the command-line to be generated (as
> error by default, as a warning with -fpermissive).
>
> Please, I am banging my head against the wall since comment #7 of why this is
> not clear. So, please, let me know which part I am explaining wrong.
I guess you are not explaining it wrong, but the situation is
extremely confusing:
/* Adjust various flags for C++ based on command-line settings. */
if (c_dialect_cxx ())
{
if (!flag_permissive)
{
flag_pedantic_errors = 1;
cpp_opts->pedantic_errors = 1;
}
...
}
which means by default pedantic is false but pedantic-errors is true
(though -fpedantic-errors also sets pedantic to true). So all
pedwarns() that are not guarded by an extra if (pedantic) are errors
for C++ (and for libcpp now). So, to get regular -pedantic behavior
you need -fpermissive -pedantic (?) (because obviously the C++ default
is not what you get from enabling any of the -pedantic -pedantic-errors
or -fpermissive flags) And of course there's no -no-pedantic-errors
either.
I find this situation confusing (especially with the defintion of
pedwarn, which reads
/* A "pedantic" warning: issues a warning unless -pedantic-errors was
given on the command line, in which case it issues an error. Use
this for diagnostics required by the relevant language standard,
if you have chosen not to make them errors.
Note that these diagnostics are issued independent of the setting
of the -pedantic command-line switch. To get a warning enabled
only with that switch, write "if (pedantic) pedwarn (...);" */
void
pedwarn (const char *gmsgid, ...)
so it suggests -pedantic-errors, but in reality it only checks for
flag_pedantic_errors:
diagnostic.h:#define pedantic_error_kind() (flag_pedantic_errors ?
DK_ERROR : DK_WARNING)
So, for C++ you either get no warning by default for
if (pedantic)
pedwarn (...);
or you get an error by default for
pedwarn (...);
But you cannot get a warning for pedwarn as its name suggests.
(-fpermissive -pedantic should work, but maybe doesn't)
Richard.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33907
[Bug target/34174] gcc produces erroneous asm for movdi
--- 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_double): Sanitize mem->reg case. Copy the address before it is clobbered. testsuite/ * gcc.dg/torture/pr34174-1.c: New. Added: trunk/gcc/testsuite/gcc.dg/torture/pr34174-1.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/fr30/fr30.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34174
[Bug target/34226] [4.3 Regression][frv] ICE in default_secondary_reload, at targhooks.c:612
--- 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.cgi?id=34226
[Bug c/34235] short variable cast to unsigned int fails to right shift as unsigned
--- 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 Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34235
[Bug tree-optimization/1046] gcc less efficient than jdk for recursion with -finline-functions
--- 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 Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1046
[Bug other/1634] Request for gcc-cvs-patches list
--- 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? -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1634
[Bug libstdc++/34236] New: nth_element failure: infinite loop or segmentation fault
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}
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu
--enable-libstdcxx-debug --enable-mpfr --enable-checking=release i486-linux-gnu
Thread model: posix
gcc version 4.1.2 (Ubuntu 4.1.2-0ubuntu4)
command line: g++ bug_nth_element.cpp && a.out
content of bug_nth_element follows:
<
#include
#include
int main() {
using namespace std;
vector a;
// fill_n (back_inserter(a), 4, 1.0); // infinite loop
fill_n (back_inserter(a), 4, 0.0); // segmentation fault
nth_element (a.begin(), a.begin(), a.end(), not2(less()));
copy (a.begin(), a.end(), ostream_iterator(cout, "\n"));
}
EOF
--
Summary: nth_element failure: infinite loop or segmentation fault
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: florent dot balestrieri at ofidea dot fr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34236
[Bug web/2036] More broken gcc-cvs links
--- 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: What|Removed |Added Status|ASSIGNED|WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2036
[Bug bootstrap/34205] iwmmxt type/size error
--- 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=34205
[Bug libstdc++/34236] nth_element failure: infinite loop or segmentation fault
--- 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 Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34236
[Bug libstdc++/18640] sorting std::vector filled with same values causes segmentation fault
--- 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 CC||florent dot balestrieri at ||ofidea dot fr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18640
[Bug target/4516] [SH] sh-unknown-linux-gnu: big jump table
--- 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 CC||kkojima at gcc dot gnu dot ||org Status|NEW |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4516
[Bug fortran/34231] Scalar actual not distinguished from assumed size formal argument
--- 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 following works as expected and prints: two: character(*) scalar! finds right generic interface one: character(*), dimension(*) ! F2003 storage equivalence: ok for specific ! function. two: character(*) scalar! obviously ok. And if one comments out "two" in "interface gen", one gets the expected compile-time error. MODULE test implicit none INTERFACE gen MODULE PROCEDURE one,two END INTERFACE CONTAINS SUBROUTINE one(cnames) CHARACTER(*) :: cnames(*) write(*,*) 'one: character(*), dimension(*)' END SUBROUTINE one SUBROUTINE two(cname) CHARACTER(*) :: cname write(*,*) 'two: character(*) scalar' END SUBROUTINE two END MODULE PROGRAM main USE test CHARACTER(11) :: cname = 'Hello World' CALL gen(cname) CALL one(cname) CALL two(cname) END PROGRAM -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34231
[Bug middle-end/32820] optimizer malfunction when mixed with asm statements
--- 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, the bug exists since GCC 3.0, so the bug is not a regression. GCC 4.2 and earlier are in "regression fixes only" mode. This means, I'm sorry to say, that your bug will not be fixed for these already released GCC versions. Could you please test this bug with a recent GCC 4.3 snapshot? If the bug persists, we can still fix the problem before GCC 4.3 is released. -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32820
[Bug middle-end/24221] ICE in first_insn_after_basic_block_note on HPPA
--- 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 |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24221
[Bug target/30131] ICE in propagate_one_insn, at flow.c:1583
--- 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 at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30131
[Bug middle-end/20408] Unnecessary code generated for empty structs
--- 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 dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org Status|NEW |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20408
[Bug target/34215] [4.2 Regression] ICE in assign_386_stack_local, at config/i386/i386.c:13481
--- 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): Select SLOT_TEMP stack slot if virtual registers are instantiated. (truncxfsf2): Ditto. (truncxfdf2): Ditto. testsuite/ChangeLog: PR target/34215 * gcc.target/i386/pr34215.c: New test. Added: branches/gcc-4_2-branch/gcc/testsuite/gcc.target/i386/pr34215.c Modified: branches/gcc-4_2-branch/gcc/ChangeLog branches/gcc-4_2-branch/gcc/config/i386/i386.md branches/gcc-4_2-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34215
[Bug debug/9565] [g77] outputs incorrect DWARF3 for multidimensional arrays
--- 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 |Added CC||jakub at gcc dot gnu dot org Status|NEW |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9565
[Bug target/34215] [4.2 Regression] ICE in assign_386_stack_local, at config/i386/i386.c:13481
--- 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
[Bug other/1634] Request for gcc-cvs-patches list
--- 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 having them lapse and be forgotten through the passage of time; old but still-relevant issues are not pollution. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1634
[Bug other/13573] Manual changes from GCC book need to be merged
--- 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 |Added Status|NEW |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13573
[Bug tree-optimization/18594] PHI insertion is slow
--- 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 Status|NEW |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18594
[Bug c++/34237] New: Weird error with getpass and crypt
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 password: ");
passwordnew = getpass("Enter new password: ");
string *strold = new string(crypt(passwordold,salt));
*strold = strold->substr(12,22);
string *strnew = new string(crypt(passwordnew,salt));
*strnew = strnew->substr(12,22);
cout << "cryptold: " << *strold << endl;
cout << "cryptnew: " << *strnew << endl;
return 1;
}
for input of passwords blah and blah2 it outputs
cryptold: oj.L0Tu9xXqtV9lyKLmdv0
cryptnew: oj.L0Tu9xXqtV9lyKLmdv0
which is the encrpytion of blah2 whatever I put into both the second one is
encryped. If I change it to cin >> instead of getpass it works.
if out cout << passwordold << passwordnew it still knows the correct passwords
entered.
The only fix I can find is reordering putting the request for the new
password after its calculated the old crypt, but that doesn't solve the fact
that somethign very wrong is going on here.
--
Summary: Weird error with getpass and crypt
Product: gcc
Version: 3.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jlarsen at fsu dot edu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34237
[Bug other/1634] Request for gcc-cvs-patches list
--- 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 request on gcc@ or on overseers. If no-one but you wants to persue this actively, I'd say there is no reason to keep this report open. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1634
[Bug c++/34237] Weird error with getpass and crypt
--- 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 Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34237
[Bug other/1634] Request for gcc-cvs-patches list
--- 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 keeping bug reports open for tracking issues where nothing > happens is a Bad Thing. No, it's a Good Thing; issues where something happens quickly have people actively remembering them and so less need to track them in a tracker, issues with less activity over time have more use for being tracked. We might decide in some cases that a page in projects/ or on the wiki is a better way to track some sorts of feature ideas than the bug database, but simply closing without moving elsewhere would be wrong. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1634
[Bug target/34225] [4.3 Regression] ICE (segfault) in adjacent_mem_locations at rs6000.c:18191
--- 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
[Bug target/34215] [4.2 Regression] ICE in assign_386_stack_local, at config/i386/i386.c:13481
--- 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): Select SLOT_TEMP stack slot if virtual registers are instantiated. (truncxf2): Ditto. (floatsi2): Ditto. (floatdisf2): Ditto. (floatdidf2): Ditto. testsuite/ChangeLog: PR target/34215 * gcc.target/i386/pr34215.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr34215.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.md trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34215
[Bug target/34215] [4.2 Regression] ICE in assign_386_stack_local, at config/i386/i386.c:13481
--- 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|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34215
[Bug libstdc++/25913] Client's isnormal function is broken by cmath
-- pcarlini at suse dot de changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25913
[Bug c/27898] Compile failure with --combine and anonymous structures
--- 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|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27898
[Bug bootstrap/34188] xgcc: Internal error: Segmentation fault (program cc1plus)
--- 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 revision? I tried the SVN version from last night. And now it compiles. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34188
[Bug bootstrap/34205] iwmmxt type/size error
--- 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/staging_dir/usr/include -I/there/build_armeb/staging_dir/include --sysroot=/there/build_armeb/staging_dir/ -isysroot /there/build_armeb/staging_dir -mtune=iwmmxt -march=iwmmxt -mabi=iwmmxt -msoft-float -mfloat-abi=soft" \ /there/toolchain_build_armeb_nofpu/gcc-4.3.0/configure \ --prefix=/usr \ --build=i386-pc-linux-gnu \ --host=armeb-linux-uclibcgnueabi \ --target=armeb-linux-uclibcgnueabi \ --enable-languages=c,fortran \ --with-gxx-include-dir=/usr/include/c++ \ --disable-__cxa_atexit \ --with-gnu-ld \ --enable-shared \ --with-gmp="/there/build_armeb/gmp-4.2.2" \ --with-mpfr="/there/build_armeb/mpfr-2.3.0" \ --disable-nls \ --enable-threads \ --disable-multilib \ --with-float=soft -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34205
[Bug bootstrap/34205] iwmmxt type/size error
--- 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
[Bug c++/34238] New: "static data member used, but not defined" error on member definition
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 'WTF::GenericHashTraitsBase::CommandImp*>::needsDestruction' used, but not defined ../../../JavaScriptCore/wtf/HashTraits.h:114: error: static data member 'WTF::HashTraits::CommandImp*>::emptyValueIsZero' used, but not defined ../../../JavaScriptCore/wtf/HashTraits.h:115: error: static data member 'WTF::HashTraits::CommandImp*>::needsDestruction' used, but not defined ../../../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 'WTF::GenericHashTraitsBase::CommandImp*> >::needsDestruction' used, but not defined ../../../JavaScriptCore/wtf/HashTraits.h:67: error: static data member 'WTF::GenericHashTraits::CommandImp*> >::needsRef' used, but not defined ../../../JavaScriptCore/wtf/HashTraits.h:165: error: static data member 'WTF::PairBaseHashTraits, WTF::HashTraits::CommandImp*> >::emptyValueIsZero' used, but not defined The lines where gcc complains about "static data member used, but not defined" are actually the places where the members are defined. -- Summary: "static data member used, but not defined" error on member definition Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bero at arklinux dot org GCC build triplet: i586-pc-linux-gnu GCC host triplet: i586-pc-linux-gnu GCC target triplet: i586-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34238
[Bug libfortran/33583] FAIL: gfortran.dg/gamma_1.f90
--- 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
[Bug c++/34238] "static data member used, but not defined" error on member definition
--- 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
[Bug middle-end/34226] [4.3 Regression][frv] ICE in default_secondary_reload, at targhooks.c:612
--- 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/config/frv/frv.c:6347
#1 0x0073430a in default_secondary_reload (in_p=0 '\0',
x=0x2b0f0ec48d80, reload_class=GPR_REGS, reload_mode=BImode,
sri=0x7fff9c430880)
at /n/12/rask/src/all/gcc/targhooks.c:595
#2 0x006bca5c in secondary_reload_class (in_p=1 '\001',
class=GPR_REGS, mode=VOIDmode, x=0x7) at /n/12/rask/src/all/gcc/reload.c:525
#3 0x006aa82f in init_regs () at
/n/12/rask/src/all/gcc/regclass.c:1285
#4 0x00737032 in backend_init_target () at
/n/12/rask/src/all/gcc/toplev.c:2040
#5 0x0073751a in toplev_main (argc=, argv=) at /n/12/rask/src/all/gcc/toplev.c:2086
#6 0x2b0f0ea1d4ca in __libc_start_main () from /lib/libc.so.6
#7 0x00403c2a in _start () at ../sysdeps/x86_64/elf/start.S:113
(gdb) fin
Run till exit from #0 frv_secondary_reload_class (class=ICC_REGS, mode=BImode,
x=0x2b0f0ec48d80, in_p=0) at /n/12/rask/src/all/gcc/config/frv/frv.c:6347
default_secondary_reload (in_p=0 '\0', x=0x2b0f0ec48d80, reload_class=GPR_REGS,
reload_mode=BImode, sri=0x7fff9c430880)
at /n/12/rask/src/all/gcc/targhooks.c:597
Value returned is $16 = GPR_REGS
The next few lines of code read:
if (class != NO_REGS)
{
enum insn_code icode = (in_p ? reload_in_optab[(int) reload_mode]
: reload_out_optab[(int) reload_mode]);
(gdb) print icode
$19 = 0
(gdb) print insn_data[0]->name
$20 = 0xb8e5ba "*movqi_load"
(gdb) print insn_data[0]->n_operands
$21 = 2 '\002'
I.e. we get the wrong icode.
(gdb) print reload_in_optab
$22 = {0 }
(gdb) print reload_out
$23 = {0 }
I would have expected a default of CODE_FOR_nothing, not 0. I think this is
a problem with the new lazy optab initialization. We now call
backend_init_target() and init_regs() before calling init_optabs().
--
rask at gcc dot gnu dot org changed:
What|Removed |Added
Component|target |middle-end
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34226
[Bug middle-end/34226] [4.3 Regression][frv] ICE in default_secondary_reload, at targhooks.c:612
-- steven at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-11-26 17:31:08 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34226
[Bug target/34081] [4.3 Regression] ICE in s390_function_value, at config/s390/s390.c:7880
--- 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]> PR 34081/C++ * c-decl.c (store_parm_decls): Pass 'false' for the new allocate_struct_function parameter. * cgraphunit.c (cgraph_build_static_cdtor): Likewise. * tree-parloops.c (create_loop_fn): Likewise. * function.c (push_function_context_to, push_struct_function, init_function_start): Likewise. (allocate_struct_function): Add boolean parameter. * tree.h (allocate_struct_function): Add boolean parameter. * function.h (struct function): Move returns_struct and returns_pcc_struct to the end of the structure definiton. 2007-11-26 Andreas Krebbel <[EMAIL PROTECTED]> PR 34081/C++ * trans.c (Subprogram_Body_to_gnu, Compilation_Unit_to_gnu): Pass 'false' for the new allocate_struct_function parameter. * utils.c (build_function_stub): Likewise. 2007-11-26 Andreas Krebbel <[EMAIL PROTECTED]> PR 34081/C++ * decl.c (finish_method): Pass 'false' for the new allocate_struct_function parameter. 2007-11-26 Andreas Krebbel <[EMAIL PROTECTED]> PR 34081/C++ * treetree.c (tree_code_create_function_wrapup): Pass 'false' for the new allocate_struct_function parameter. 2007-11-26 Andreas Krebbel <[EMAIL PROTECTED]> PR 34081/C++ * decl.c (start_preparsed_function): Pass processing_template_decl for the new allocate_struct_function parameter. 2007-11-26 Andreas Krebbel <[EMAIL PROTECTED]> PR 34081/C++ * g++.dg/template/dependent-expr6.C: New testcase. Added: trunk/gcc/testsuite/g++.dg/template/dependent-expr6.C Modified: trunk/gcc/ChangeLog trunk/gcc/ada/ChangeLog trunk/gcc/ada/trans.c trunk/gcc/ada/utils.c trunk/gcc/c-decl.c trunk/gcc/cgraphunit.c trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/function.c trunk/gcc/function.h trunk/gcc/java/ChangeLog trunk/gcc/java/decl.c trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-parloops.c trunk/gcc/tree.h trunk/gcc/treelang/ChangeLog trunk/gcc/treelang/treetree.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34081
[Bug libfortran/33583] FAIL: gfortran.dg/gamma_1.f90
--- 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" and for gamma it should use the one provided by libgfortran. Do you get linker errors? Or what exactly is the error message/problem? -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||burnus at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33583
[Bug preprocessor/33907] Empty macro definitions not considered equal
--- 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++ front-end. It is just that now CPP and C++ front-end defaults are consistent. > So, to get regular -pedantic behavior > you need -fpermissive -pedantic (?) (because obviously the C++ default > is not what you get from enabling any of the -pedantic -pedantic-errors > or -fpermissive flags) And of course there's no -no-pedantic-errors > either. That is a good point. But it is not new. It seems to have been like this for the C++ front-end forever. > But you cannot get a warning for pedwarn as its name suggests. > (-fpermissive -pedantic should work, but maybe doesn't) -fpermissive gets a warning for pedwarn(). -fpermissive -pedantic gets you a warning for "if (pedantic) pedwarn()". Think about it like this: pedwarns are diagnostics required by the standard. Some of them are nice, others are a pain in the ass. So we "hide" away the latter under "if (pedantic)" or more precisely under "-pedantic". Now, why the C++ front-end has pedwarns as errors by default, I don't know. But if you have that, then you need -fpermissive. In the C front-end there is no flag to get pedwarns as warnings back: once you issue -pedantic-errors in the command-line, then you cannot take it back. Of course, finding all this took me to read the code and do some tests. You wasn't able to guess it from invoke.texi. So for this bug, I am proposing that we only give the pointless diagnostic if the flag "pedantic" is set to 1 (either by using -pedantic or -pedantic-errors). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33907
[Bug libfortran/33583] FAIL: gfortran.dg/gamma_1.f90
--- 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 function, and not your internal gamma function: this one is, unfortunately, is a voluntary change in the behaviour of gfortran to conform to other compilers and the Fortran 2008 standard (or whatever its final name will be). You can get rid of that behaviour by adding "EXTERNAL GAMMA" to your main program, as I stated in my comment to PR33942. That first part is, as far as we are concerned, not a bug. It is noted in the 4.3 release notes (http://gcc.gnu.org/gcc-4.3/changes.html), along with the fact that adding "EXTERNAL GAMMA" is the way to go. The second half of the issue is that, on FreeBSD, there is no gammaf() in libm. This is what this PR tracks, and this is why PR33942 was closed as a duplicate. Sorry if that wasn't clear enough. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33583
[Bug c++/34237] Weird error with getpass and crypt
--- 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.cgi?id=34237
[Bug middle-end/34226] [4.3 Regression][frv] ICE in default_secondary_reload, at targhooks.c:612
--- 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
[Bug target/34081] [4.3 Regression] ICE in s390_function_value, at config/s390/s390.c:7880
--- 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|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34081
[Bug libfortran/33583] FAIL: gfortran.dg/gamma_1.f90
--- 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 function `MAIN__': : undefined reference to `tgammaf' collect2: ld returned 1 exit status Is this the intended behavior? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33583
[Bug libstdc++/25913] Client's isnormal function is broken by cmath
--- 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 libstdc++/25913 * include/c_std/cmath (std::fpclassify, isfinite, isinf, isnan, isnormal, signbit, isgreater, isgreaterequal, isless, islessequal, islessgreater, isunordered): Guard with __enable_if and forward with __promote. * include/c_global/cmath: Likewise. * testsuite/26_numerics/headers/cmath/25913.cc: New. * include/c_std/cmath (__gnu_cxx::__capture_isfinite, __capture_isinf, __capture_isnan, __capture_isnormal, __capture_signbit, __capture_isgreater, __capture_isgreaterequal, __capture_isless, __capture_islessequal, __capture_islessgreater, __capture_isunordered): Remove. (std::isfinite, isinf, isnan, isnormal, signbit, isgreater, isgreaterequal, isless, islessequal, islessgreater, isunordered): Forward to the corresponding builtin. * include/c_global/cmath: Likewise. * include/c_global/cmath (std::atan2, pow): Guard with __enable_if. Added: trunk/libstdc++-v3/testsuite/26_numerics/headers/cmath/25913.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/c_global/cmath trunk/libstdc++-v3/include/c_std/cmath -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25913
[Bug libstdc++/25913] Client's isnormal function is broken by cmath
--- 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|RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25913
[Bug java/34239] New: soalris 8 /bin/sh does not support -ef in gen-classlist.sh
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 use bash instead? Or do the test a different way on solaris? -- Summary: soalris 8 /bin/sh does not support -ef in gen- classlist.sh Product: gcc Version: 4.2.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: warren dot l dot dodge at tektronix dot com GCC build triplet: sparc-sun-solaris2.8 GCC host triplet: sparc-sun-solaris2.8 GCC target triplet: sparc-sun-solaris2.8 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34239
[Bug java/34239] solaris 8 /bin/sh does not support -ef in gen-classlist.sh
--- 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 CC||tromey at gcc dot gnu dot ||org Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34239
[Bug c/23722] bad error recovery with if blocks and else
--- 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/23722 * c-parser.c (struct c_parser): New bit in_if_block. (c_parser_compound_statement_nostart): Handle unexpected 'else' keyword. (c_parser_statement_after_labels): Set in_if_block to false while parsing. (c_parser_if_body): Don't call c_parser_statement_after_labels if a semicolon is found, just consume it. Don't call c_parser_statement_after_labels if an open brace is found, call c_parser_compound_statement instead. (c_parser_else_body): New. (c_parser_if_statement): Set in_if_block to true when parsing the body of the 'if' statement. Use c_parser_else_body. testsuite/ * gcc.dg/cpp/19990413-1.c: Update. * gcc.dg/parse-else-error.c: New. * gcc.dg/parse-else-error-2.c: New. * gcc.dg/parse-else-error-3.c: New. * gcc.dg/parse-else-error-4.c: New. Added: trunk/gcc/testsuite/gcc.dg/parse-else-error-2.c trunk/gcc/testsuite/gcc.dg/parse-else-error-3.c trunk/gcc/testsuite/gcc.dg/parse-else-error-4.c trunk/gcc/testsuite/gcc.dg/parse-else-error.c Modified: trunk/gcc/ChangeLog trunk/gcc/c-parser.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/cpp/19990413-1.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23722
[Bug c/23722] bad error recovery with if blocks and else
--- 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 |RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23722
[Bug c++/34059] [4.1/4.2/4.3 regression] ICE with invalid base type for class member
--- 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 CC||simartin at gcc dot gnu dot ||org AssignedTo|unassigned at gcc dot gnu |simartin at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2007-11-19 04:11:30 |2007-11-26 19:38:27 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34059
[Bug middle-end/24221] ICE in first_insn_after_basic_block_note on HPPA
--- 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, Shaun On 26 Nov 2007 14:12:20 -, steven at gcc dot gnu dot org <[EMAIL PROTECTED]> wrote: > --- 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. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24221
[Bug c++/34240] New: ICE with __builtin_isnormal
#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: ICE with __builtin_isnormal
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pcarlini at suse dot de
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34240
[Bug middle-end/24221] ICE in first_insn_after_basic_block_note on HPPA
--- 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 |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24221
[Bug c++/34238] "static data member used, but not defined" error on member definition
--- 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:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org
|dot org |
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2007-11-26 20:18:10
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34238
[Bug c++/34238] [4.3 regression] "static data member used, but not defined" error on member definition
--- 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 Known to fail||4.2.0 4.2.1 4.2.2 Known to work||4.3.0 Summary|"static data member used, |[4.3 regression] "static |but not defined" error on |data member used, but not |member definition |defined" error on member ||definition http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34238
[Bug c++/34238] [4.3 regression] "static data member used, but not defined" error on member definition
--- 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 invalid code. There is no definition of A::a, though
there is no use of A::a.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
||org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34238
[Bug libgcj/34239] solaris 8 /bin/sh does not support -ef in gen-classlist.sh
--- 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|Removed |Added Component|java|libgcj http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34239
[Bug bootstrap/34188] [4.3 Regression] xgcc: Internal error: Segmentation fault (program cc1plus)
--- 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 Status|WAITING |RESOLVED Resolution||FIXED Summary|xgcc: Internal error: |[4.3 Regression] xgcc: |Segmentation fault (program |Internal error: Segmentation |cc1plus)|fault (program cc1plus) Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34188
[Bug ada/15611] Invalid program not detected, RM 3.7(11)
--- 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: -- Tagged types cannot have defaulted discriminants, but a -- non-tagged private type with defaulted discriminants -- can have a tagged completion. -- sam at gcc dot gnu dot org changed: What|Removed |Added CC||sam at gcc dot gnu dot org Status|NEW |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15611
[Bug ada/15616] Compiler error on legal program using generic package
--- 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 at gcc dot gnu dot org changed: What|Removed |Added CC||sam at gcc dot gnu dot org Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15616
[Bug fortran/34136] [regression against g77] Add entry point and symbol for linker
--- 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 to generate the reference to bdtest on those platforms that need it. Darwin would be one such system. I've filed radr://5613343 need to search for definitions for common symbols so we won't need such help at some point. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34136
[Bug ada/15799] Legal program rejected, using 'Base
--- 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 changed: What|Removed |Added CC||sam at gcc dot gnu dot org Status|NEW |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15799
[Bug target/34225] [4.3 Regression] ICE (segfault) in adjacent_mem_locations at rs6000.c:18191
-- 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 | Status|NEW |ASSIGNED Last reconfirmed|2007-11-25 18:50:20 |2007-11-26 21:15:44 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34225
[Bug ada/15803] Illegal program not detected, RM 8.3(19)
-- 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 | Status|NEW |ASSIGNED Last reconfirmed|2005-06-14 04:55:13 |2007-11-26 21:36:27 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15803
[Bug fortran/34203] Treat \ as normal character (at least on Windows); diagnose unrecognized escape characters
--- 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]> * options.c: Change default behavior of backslash processing. * invoke.texi: Update documentation. 2007-11-26 Tobias Burnus <[EMAIL PROTECTED]> PR fortran/34203 * gfortran.dg/backslash_3.f: Add -fbackslash option. * gfortran.dg/init_flag_1.f90: Add -fbackslash option. * gfortran.dg/backslash_1.f90: Remove no longer needed -fno-backslash option. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/invoke.texi trunk/gcc/fortran/options.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/backslash_1.f90 trunk/gcc/testsuite/gfortran.dg/backslash_3.f trunk/gcc/testsuite/gfortran.dg/init_flag_1.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34203
[Bug target/34077] GCC -O1 -minline-all-stringops -minline-stringops-dynamically fails for spec 2006 bzip2, gobmk, and h264ref benchmarks
--- 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/i386/pr34077.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34077
[Bug ada/15804] Illegal program not detected, RM 3.8.1(2)
-- 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 | Status|NEW |ASSIGNED Last reconfirmed|2005-06-14 20:15:50 |2007-11-26 22:49:54 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15804
[Bug fortran/34203] Treat \ as normal character (at least on Windows); diagnose unrecognized escape characters
--- 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' gfortran should do likewise in match.c's gfc_match_special_char. Actually, we do not fully support all C escape sequences (see "5.2.2 Character display semantics", "6.4.4.4 Character constants" and "6.4.3 Universal character names"); missing are: - trigraphs (I don't think anyone misses them) - \" and \' (use "" or '' instead) - \? (use ?) - \o, \oo \ooo (o = octal digit) - except of \0 - \xh, \xhh (h = hexadecimal digit) - \u, \U (h = hexadecimal digit) I don't know whether we really need to implement them, but at least we should document what we have. A proper documentation would be something like Intel's http://www.intel.com/software/products/compilers/docs/flin/main_for/index.htm -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34203
[Bug libfortran/33583] FAIL: gfortran.dg/gamma_1.f90
--- 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 question is only why does it happen. Did you compile GCC yourself? If yes, what do libgfortran/config.h and libgfortran/config.log contain for lgammaf? Are you sure that the linker finds the right version of libgfortran.so? (This feature was added 2007-11-16.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33583
[Bug target/34001] Incorrect x86 fastcall behavior
--- 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;
inttest_y;
double test_d1;
void caller( void ){
f_dii( test_d1, test_x, test_y );
}
---
Gcc 3.4 doesn't pass the first 2 integral parameters in ecx/edx and gcc
4.1 does.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34001
[Bug fortran/34203] Treat \ as normal character (at least on Windows); diagnose unrecognized escape characters
--- 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: warning: unknown escape sequence '\w'
>
Tobias,
I think that gfortran should not bother with a warning.
A better solution would be to simply list the escape
sequences that -fbackslash trigger, and state the
all other combinations are not expanded.
I think gfortran definitely wants to avoid the pandora's box
of trigraph, octal, and hexidecimal escaped character sequences.
The following was tested with a "make pdf"
Index: invoke.texi
===
--- invoke.texi (revision 130454)
+++ invoke.texi (working copy)
@@ -239,6 +239,11 @@ Allow @samp{$} as a valid character in a
@cindex escape characters
Change the interpretation of backslashes in string literals
from a single backslash character to ``C-style'' escape characters.
+The following combinations are expanded \a, \b, \f, \n, \r, \t,
+\v, \\, and \0 to the ASCII characters alert, backspace, form feed,
+newline, carriage return, horizontal tab, vertical tab, backslash,
+and NUL, respectively. All other combinations of a character preceded
+by \ are unexpanded.
@item -fmodule-private
@opindex @code{fmodule-private}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34203
[Bug libfortran/33583] FAIL: gfortran.dg/gamma_1.f90
--- Comment #15 from kargl at gcc dot gnu dot org 2007-11-26 23:29 --- (In reply to comment #13) > 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 function `MAIN__': > : undefined reference to `tgammaf' > collect2: ld returned 1 exit status > > Is this the intended behavior? Works for me. troutmask:sgk[223] gc4x -o z a.f90 troutmask:sgk[224] nm z | grep 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) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33583
[Bug ada/15805] Illegal program not detected, allows writing through access to constant
-- 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 | Status|NEW |ASSIGNED Last reconfirmed|2005-07-04 10:20:33 |2007-11-26 23:51:26 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15805
[Bug target/4516] [SH] sh-unknown-linux-gnu: big jump table
--- 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 dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4516
[Bug middle-end/34241] New: ICE in forward_propagate_into_cond
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, single_use_only=0 '\0',
single_use_p=0xbfdc018b "")
at ../../gcc/tree-ssa-forwprop.c:221
#1 0x08328d58 in forward_propagate_into_cond (cond_expr=0xb7bca7d0,
stmt=0xb7bca7d0)
at ../../gcc/tree-ssa-forwprop.c:378
#2 0x0832b5be in tree_ssa_forward_propagate_single_use_vars ()
at ../../gcc/tree-ssa-forwprop.c:1021
#3 0x0824a963 in execute_one_pass (pass=0x8727e80) at ../../gcc/passes.c:1118
#4 0x0824aaff in execute_pass_list (pass=0x8727e80) at ../../gcc/passes.c:1171
#5 0x0824ab12 in execute_pass_list (pass=0x8727840) at ../../gcc/passes.c:1172
#6 0x0824aeec in execute_ipa_pass_list (pass=0x8727800) at
../../gcc/passes.c:856
#7 0x083e6d25 in cgraph_optimize () at ../../gcc/cgraphunit.c:1339
#8 0x0809198d in cp_write_global_declarations () at ../../gcc/cp/decl2.c:3442
#9 0x082bf163 in toplev_main (argc=4, argv=0xbfdc0424) at
../../gcc/toplev.c:1055
#10 0x08121b7f in main (argc=Cannot access memory at address 0x7
) at ../../gcc/main.c:35
the stmt where the def is NULL is:
version 3 in-free-list>
--
Summary: ICE in forward_propagate_into_cond
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: critical
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mueller at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34241
