[Bug ada/35953] New: Socket stream subprograms incorrectly handling null arrays
The code used to send and receive data from sockets through Ada streams (in GNAT.Sockets) may be bogus if an empty array is sent or expected to be received. An empty array will have its upper bound smaller than its lower bound, but the code in GNAT.Sockets assumes that the difference is always one. One could argue that the suspicious Read and Write subprograms with this flaw are not present in the spec, and that GNAT will not call them with empty arrays while writing data onto the stream using stream attributes; however, it is possible to obtain a Stream_Access which is an access to those private stream types. The Read and Write subprograms then become usable from outside the package through dispatching, as they are overloads of Ada.Streams.Root_Stream_Type primitive operations. Thanks to Laurent Guerby for pointing this out. -- Summary: Socket stream subprograms incorrectly handling null arrays Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sam at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35953
[Bug fortran/35944] [4.3, 4.4 regression] wrong result for MOD with kind=10 for some array argument values
--- Comment #3 from ubizjak at gmail dot com 2008-04-16 06:21 --- (In reply to comment #2) The tree dump for the kind=8 and kind=10 are exactly identical except for the call to __builtin_fmodl for kind=10 and __builtin_fmod for kind=8. It looks like fmodl is broken. Can somebody provide equivalent c testcase? I will look into this problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35944
[Bug libstdc++/35954] New: cannot build from read-only source tree
This change 2007-08-21 Benjamin Kosnik [EMAIL PROTECTED] * include/Makefile.am (install-data-local): Remove pch-install rules. (host_headers): Add stdc++.h, stdtr1c++.h, extc++.h. * include/Makefile.in: Regenerate. * config.h.in: Same. * scripts/check_compile: Remove space between outputs. * include/ext/throw_allocator.h: Correct doxygen markup. * include/bits/char_traits.h: Correct spacing. * include/bits/stl_function.h: Same, for 80 column. * include/std/valarray: Same. * testsuite/util/testsuite_iterators.h: Same. * testsuite/25_algorithms/headers/algorithm/synopsis.cc: Format. breaks the build when the source tree is not modifiable: Making all in include touch: cannot touch `./i686-pc-linux-gnu/bits/stdc++.h': Permission denied make[4]: *** [i686-pc-linux-gnu/bits/stdc++.h.gch/O2g.gch] Error 1 make[3]: *** [all-recursive] Error 1 make[2]: *** [all] Error 2 make[1]: *** [all-target-libstdc++-v3] Error 2 make: *** [all] Error 2 It is obviously wrong to touch a symlink to a file in the source tree - if the file (other than in 4.2.x) really needs to have full contents, then it needs to be copied (with ownership and permissions changed) rather than symlinked. -- Summary: cannot build from read-only source tree Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jbeulich at novell dot com GCC build triplet: *-*-* GCC host triplet: *-*-* GCC target triplet: *-*-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35954
[Bug c++/35955] New: -Wignored-qualifiers produce different output with/without typedef
g++ -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc_current/configure
--prefix=/usr/local/i686-pc-linux-gnu-current
--enable-version-specific-runtime-libs --enable-checking=yes
--enable-languages=c,c++
Thread model: posix
gcc version 4.4.0 20080416 (experimental) [trunk revision 134340] (GCC)
g++ -Wignored-qualifiers -c t.cpp
t.cpp:5: warning: type qualifiers ignored on function return type
typedef int* pint;
class C
{
operator const int*();
operator const pint();
};
--
Summary: -Wignored-qualifiers produce different output
with/without typedef
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dimhen at gmail dot com
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35955
[Bug driver/35956] New: gcc/g++ print different trunk revision #
$ gcc -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../gcc_current/configure --prefix=/usr/local/i686-pc-linux-gnu-current --enable-version-specific-runtime-libs --enable-checking=yes --enable-languages=c,c++ Thread model: posix gcc version 4.4.0 20080416 (experimental) [trunk revision 134340] (GCC) $ g++ -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../gcc_current/configure --prefix=/usr/local/i686-pc-linux-gnu-current --enable-version-specific-runtime-libs --enable-checking=yes --enable-languages=c,c++ Thread model: posix gcc version 4.4.0 20080416 (experimental) [trunk revision 134339] (GCC) -- Summary: gcc/g++ print different trunk revision # Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: driver AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dimhen at gmail dot com GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35956
Re: [Bug c++/35955] New: -Wignored-qualifiers produce different output with/without typedef
Sent from my iPhone
On Apr 16, 2008, at 0:07, dimhen at gmail dot com [EMAIL PROTECTED]
wrote:
g++ -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc_current/configure
--prefix=/usr/local/i686-pc-linux-gnu-current
--enable-version-specific-runtime-libs --enable-checking=yes
--enable-languages=c,c++
Thread model: posix
gcc version 4.4.0 20080416 (experimental) [trunk revision 134340]
(GCC)
g++ -Wignored-qualifiers -c t.cpp
t.cpp:5: warning: type qualifiers ignored on function return type
This warning is correct, with the typedef the const applies to the
pointer type and not the what the pointer points to.
typedef int* pint;
class C
{
operator const int*();
operator const pint();
};
--
Summary: -Wignored-qualifiers produce different output
with/without typedef
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dimhen at gmail dot com
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35955
[Bug c++/35955] -Wignored-qualifiers produce different output with/without typedef
--- Comment #1 from pinskia at gmail dot com 2008-04-16 07:48 ---
Subject: Re: New: -Wignored-qualifiers produce different output with/without
typedef
Sent from my iPhone
On Apr 16, 2008, at 0:07, dimhen at gmail dot com [EMAIL PROTECTED]
wrote:
g++ -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc_current/configure
--prefix=/usr/local/i686-pc-linux-gnu-current
--enable-version-specific-runtime-libs --enable-checking=yes
--enable-languages=c,c++
Thread model: posix
gcc version 4.4.0 20080416 (experimental) [trunk revision 134340]
(GCC)
g++ -Wignored-qualifiers -c t.cpp
t.cpp:5: warning: type qualifiers ignored on function return type
This warning is correct, with the typedef the const applies to the
pointer type and not the what the pointer points to.
typedef int* pint;
class C
{
operator const int*();
operator const pint();
};
--
Summary: -Wignored-qualifiers produce different output
with/without typedef
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dimhen at gmail dot com
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35955
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35955
[Bug c++/20624] [4.0 Regression] wrong control reaches end of non-void function warning
--- Comment #24 from pluto at agmk dot net 2008-04-16 08:03 ---
(In reply to comment #23)
Fixed in 4.0.2 and above.
i have one more testcase which still exposes this bug.
$ cat 0.cpp
struct X
{
X();
~X();
};
bool f( int k )
{
X x;
switch ( k )
{
default:
return false;
break;
}
}
$ g++ 0.cpp -Wall -fdump-tree-gimple -g0 -c -o /dev/null
0.cpp: In function #8216;bool f(int)#8217;:
0.cpp:16: warning: control reaches end of non-void function
$ cat 0.cpp.004t.gimple
bool f(int) (k)
{
bool D.2056;
struct X x;
__comp_ctor (x);
try
{
switch (k)
{
default : goto D.2054;
}
D.2054:;
D.2056 = 0;
return D.2056;
goto D.2055;
D.2055:;
}
finally
{
__comp_dtor (x);
}
}
--
pluto at agmk dot net changed:
What|Removed |Added
CC||pluto at agmk dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20624
[Bug c++/35955] -Wignored-qualifiers produce different output with/without typedef
--- Comment #2 from dimhen at gmail dot com 2008-04-16 08:19 --- Function according C/C++ specs -- dimhen at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35955
[Bug target/35860] [4.3 Regression] [avr] code bloat caused by -fsplit-wide-types
--- Comment #7 from steven at gcc dot gnu dot org 2008-04-16 08:59 --- I agree with Paolo in comment #6. One purpose of the lower-subreg path was to allow backends to *not* define insns that it doesn't have. The expanders will generate inline code for such patterns at expand time, with sets to subregs. Before GCC had lower-subreg, this would lead to awful code, but now that we split the subregs out to pseudos it ought to work just fine. Sadly, even i386 still hasn't been modified to benefit from this work... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35860
[Bug middle-end/35897] DSE doesn't support targets with wide registers
--- Comment #7 from steven at gcc dot gnu dot org 2008-04-16 09:07 --- Fixed, or what? -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35897
[Bug ada/9535] Datagram socket semantics are wrong
-- 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|2003-05-27 18:18:57 |2008-04-16 10:32:14 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9535
[Bug ada/35953] Socket stream subprograms incorrectly handling null arrays
-- 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|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-04-16 10:32:40 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35953
[Bug c/35957] New: static return value type checking, no warning issued
I hope this does not conflict with the C-standard, but why does the following
code not issue a warning about the return value of 'someFunction'?
#include stdio.h
unsigned int someFunction() { return 0xbadc0de; }
void someOtherFunction(unsigned char in) { printf(0x%x\n, in); }
int main(int argc, char **argv)
{
unsigned char x;
unsigned int y;
x = someFunction();
printf(0x%x\n, x);
y = 0xbadc0de;
someOtherFunction(y);
return 0;
}
The return value is correctly cast to a char, but shouldn't the compiler
complain?
--
Summary: static return value type checking, no warning issued
Product: gcc
Version: 4.2.2
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: clemens dot kol at gmx dot at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35957
[Bug c/35957] static return value type checking, no warning issued
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-04-16 11:27 --- Not unconditionally. With -Wconversion it does since gcc 4.3: t.c: In function 'main': t.c:11: warning: conversion to 'unsigned char' from 'unsigned int' may alter its value t.c:15: warning: conversion to 'unsigned char' from 'unsigned int' may alter its value -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35957
[Bug fortran/35944] [4.3, 4.4 regression] wrong result for MOD with kind=10 for some array argument values
--- Comment #4 from ubizjak at gmail dot com 2008-04-16 11:28 --- (In reply to comment #3) Can somebody provide equivalent c testcase? I will look into this problem. I have a patch in testing. -- ubizjak at gmail dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ubizjak at gmail dot com |dot org | Status|NEW |ASSIGNED Last reconfirmed|2008-04-15 21:02:35 |2008-04-16 11:28:36 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35944
[Bug fortran/35958] New: gfortran for Vista
Hi, after running into severe problems with gfortran 4.4.0 under Vista, I wanted to regress to 4.3.0. I installed gcc 4.3.0, but this still resulted in: gfortran: CreateProcess: No such file or directory The previous version I worked with was gfortran 4.3.0 (20071017), trunk 129419. This one worked fine, but I can't find the distribution anymore... Could you please tell me if this is still available, and where I can download it. I am now in the situation that gfortran is completely unoperable, and I need to make a binary delivery of a product real soon... I really need this resolved very urgently... Thank you in advance, and also many thanks for all the effort of maintaining gcc. -- Summary: gfortran for Vista Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: DHConsultancy at skynet dot be http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35958
[Bug ada/29015] Ada 2005 observer pattern with mutually dependent packages and containers produces compiler error
--- Comment #9 from sam at gcc dot gnu dot org 2008-04-16 12:38 --- Subject: Bug 29015 Author: sam Date: Wed Apr 16 12:37:38 2008 New Revision: 134345 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134345 Log: gcc/ada/ PR ada/29015 * sem_ch12.adb (Instantiate_Type): Check whether the full view of the type is known instead of the underlying type. gcc/testsuite/ PR ada/29015 * gnat.dg/incomplete1.ads, gnat.dg/incomplete2.ads, gnat.dg/incomplete2.adb: New. Added: trunk/gcc/testsuite/gnat.dg/incomplete1.ads trunk/gcc/testsuite/gnat.dg/incomplete2.adb trunk/gcc/testsuite/gnat.dg/incomplete2.ads Modified: trunk/gcc/ada/ChangeLog trunk/gcc/ada/sem_ch12.adb trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29015
[Bug ada/29015] Ada 2005 observer pattern with mutually dependent packages and containers produces compiler error
--- Comment #10 from sam at gcc dot gnu dot org 2008-04-16 12:44 --- This is fixed in the current GCC SVN. -- sam at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29015
[Bug middle-end/35897] DSE doesn't support targets with wide registers
--- Comment #8 from hjl dot tools at gmail dot com 2008-04-16 12:56 --- Fixed. -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35897
[Bug testsuite/35843] [4.4 Regression]: -fdump-rtl-expand does not exist anymore
--- Comment #7 from hjl dot tools at gmail dot com 2008-04-16 13:02 --- Joey has a point: http://gcc.gnu.org/ml/gcc-patches/2008-04/msg01280.html It does look wired for a *dump-tree* option to generate a RTL looking result. -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||Joey dot ye at intel dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35843
[Bug target/35860] [4.3 Regression] [avr] code bloat caused by -fsplit-wide-types
--- Comment #8 from hutchinsonandy at aim dot com 2008-04-16 13:10 --- Subject: Re: [4.3 Regression] [avr] code bloat caused by -fsplit-wide-types Yes, indeed, I have patches in progress for AVR that do split operation to take more advantage of lowering but the bug is still an issue then. For example, if the testcase was using PLUS instead or OR, I will not be able to split instruction. (anything with carried status is problematic with reload and - as yet - cannot be split) The problem will merely propagate backwards until it gets blocked by unsplit wide mode operation (PLUS, COMPARE, SUB, MULT and probabley calls). Simply put, it will occur where ever a wide mode value meets a set of subregs. Here it will determine there is a conflict - even if there is not one. -Original Message- From: steven at gcc dot gnu dot org [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wed, 16 Apr 2008 4:59 am Subject: [Bug target/35860] [4.3 Regression] [avr] code bloat caused by -fsplit-wide-types --- Comment #7 from steven at gcc dot gnu dot org 2008-04-16 08:59 --- I agree with Paolo in comment #6. One purpose of the lower-subreg path was to allow backends to *not* define insns that it doesn't have. The expanders will generate inline code for such patterns at expand time, with sets to subregs. Before GCC had lower-subreg, this would lead to awful code, but now that we split the subregs out to pseudos it ought to work just fine. Sadly, even i386 still hasn't been modified to benefit from this work... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35860 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35860
[Bug tree-optimization/3713] Pointers to functions or member functions are not folded or inlined
--- Comment #16 from jamborm at gcc dot gnu dot org 2008-04-16 13:27 --- I'm now working on inlining of indirect calls (PR 9079) and intend to allow for inlining of calls through member pointers too. -- jamborm at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jamborm at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-03-11 06:23:54 |2008-04-16 13:27:21 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3713
[Bug fortran/35958] gfortran for Vista
--- Comment #1 from steven at gcc dot gnu dot org 2008-04-16 13:46 --- Looks related to http://gcc.gnu.org/ml/fortran/2008-03/msg00119.html and the thread surrounding it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35958
[Bug java/35923] gcj: error trying to exec 'ecj1': execvp: No such file or directory
--- Comment #4 from david dot griffiths at gmail dot com 2008-04-16 14:31 --- Hi, made no difference. I created a separate gcc-4.3.0-build directory and placed the ecj.jar both in there and in the top level source director (just to be sure). Note that the build directory contains no libjava on completion, not sure if it should? (As that's the only place that seems to refer to ecj1). I am just doing ./configure but that should build java by default, right? The config.log certainly contains lines like build_configargs='--cache-file=../config.cache '--enable-languages=c,c++,fortran,java,objc' --program-transform-name='s,y,y,''. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35923
[Bug java/35923] gcj: error trying to exec 'ecj1': execvp: No such file or directory
--- Comment #5 from brian at dessent dot net 2008-04-16 14:50 --- Subject: Re: gcj: error trying to exec 'ecj1': execvp: No such file or directory david dot griffiths at gmail dot com wrote: Note that the build directory contains no libjava on completion, not sure if it should? (As that's the only place that seems to refer to ecj1). I am just doing ./configure but that should build java by default, right? The config.log certainly contains lines like build_configargs='--cache-file=../config.cache '--enable-languages=c,c++,fortran,java,objc' --program-transform-name='s,y,y,''. Oh, this is Cygwin. Ick. gcj support for Cygwin is very iffy. Last time I tried you had to --enable-libjava to get it to build libjava as it was disabled by default. And even then it will only build a static libjava which is not very useful. Also the default SJLJ EH makes performance nearly intolerable, so you'll probably want to switch to Dwarf-2 EH. I'm not sure if all the required patches for DW2 EH to function correctly on MinGW/Cygwin are in the FSF tree or not. (Along with the other problems with DW2 EH on Win32...) If you google a little I think you can find hacks for building a MinGW shared libjava which you might be able to adapt, but I don't know. I wouldn't expect much. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35923
[Bug fortran/35958] gfortran for Vista
--- Comment #2 from DHConsultancy at skynet dot be 2008-04-16 15:08 --- Subject: Re: gfortran for Vista it is... I got a response on the previous one which helped for some compilations, but not for all so, now I'm basically stuck without gfortran... steven at gcc dot gnu dot org wrote: --- Comment #1 from steven at gcc dot gnu dot org 2008-04-16 13:46 --- Looks related to http://gcc.gnu.org/ml/fortran/2008-03/msg00119.html and the thread surrounding it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35958
[Bug fortran/35944] [4.3, 4.4 regression] wrong result for MOD with kind=10 for some array argument values
--- Comment #5 from uros at gcc dot gnu dot org 2008-04-16 15:54 --- Subject: Bug 35944 Author: uros Date: Wed Apr 16 15:53:59 2008 New Revision: 134348 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134348 Log: PR target/35944 * config/i386/i386.md (fmodxf3): Copy operand 1 and operand 2 into temporary registers. Change operand predicate to general_operand. (remainderxf3): Ditto. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.md -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35944
[Bug target/35662] [4.3/4.4 regression] gfortran interfaces badly with glibc sincosf() causing breakage
--- Comment #2 from jakub at gcc dot gnu dot org 2008-04-16 15:57 ---
Subject: Bug 35662
Author: jakub
Date: Wed Apr 16 15:56:58 2008
New Revision: 134349
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134349
Log:
PR target/35662
* f95-lang.c (gfc_init_builtin_functions): Make sure
BUILT_IN_SINCOS{,F,L} types aren't varargs.
* gfortran.dg/pr35662.f90: New test.
Added:
trunk/gcc/testsuite/gfortran.dg/pr35662.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/f95-lang.c
trunk/gcc/testsuite/ChangeLog
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35662
[Bug tree-optimization/35899] [4.3/4.4 Regression] ICE on filesystem code
--- Comment #5 from jakub at gcc dot gnu dot org 2008-04-16 16:01 --- Subject: Bug 35899 Author: jakub Date: Wed Apr 16 16:00:34 2008 New Revision: 134350 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134350 Log: PR tree-optimization/35899 * tree-inline.c (expand_call_inline): Use GIMPLE_STMT_OPERAND rather than TREE_OPERAND. * gcc.dg/pr35899.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr35899.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-inline.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35899
[Bug c/35739] [4.3/4.4 regression] ICE with _Decimal128 and va_list
--- Comment #5 from jakub at gcc dot gnu dot org 2008-04-16 16:02 --- Subject: Bug 35739 Author: jakub Date: Wed Apr 16 16:01:57 2008 New Revision: 134351 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134351 Log: PR c/35739 * tree-nrv.c (tree_nrv): Don't optimize if result_type is GIMPLE reg type. * gcc.dg/dfp/pr35739.c: New test. Added: trunk/gcc/testsuite/gcc.dg/dfp/pr35739.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-nrv.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35739
[Bug fortran/35944] [4.3 Regression] wrong result for MOD with kind=10 for some array argument values
--- Comment #6 from ubizjak at gmail dot com 2008-04-16 16:05 --- Fixed in mainline. I'm not a fortran person; can someone please construct a testcase from the example in the description to be committed to SVN? -- ubizjak at gmail dot com changed: What|Removed |Added Summary|[4.3, 4.4 regression] wrong |[4.3 Regression] wrong |result for MOD with kind=10 |result for MOD with kind=10 |for some array argument |for some array argument |values |values http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35944
[Bug target/35662] [4.3/4.4 regression] gfortran interfaces badly with glibc sincosf() causing breakage
--- Comment #3 from jakub at gcc dot gnu dot org 2008-04-16 16:06 ---
Subject: Bug 35662
Author: jakub
Date: Wed Apr 16 16:05:51 2008
New Revision: 134352
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134352
Log:
PR target/35662
* f95-lang.c (gfc_init_builtin_functions): Make sure
BUILT_IN_SINCOS{,F,L} types aren't varargs.
* gfortran.dg/pr35662.f90: New test.
Added:
branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/pr35662.f90
Modified:
branches/gcc-4_3-branch/gcc/fortran/ChangeLog
branches/gcc-4_3-branch/gcc/fortran/f95-lang.c
branches/gcc-4_3-branch/gcc/testsuite/ChangeLog
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35662
[Bug tree-optimization/35899] [4.3/4.4 Regression] ICE on filesystem code
--- Comment #6 from jakub at gcc dot gnu dot org 2008-04-16 16:08 --- Subject: Bug 35899 Author: jakub Date: Wed Apr 16 16:07:46 2008 New Revision: 134353 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134353 Log: PR tree-optimization/35899 * tree-inline.c (expand_call_inline): Use GIMPLE_STMT_OPERAND rather than TREE_OPERAND. * gcc.dg/pr35899.c: New test. Added: branches/gcc-4_3-branch/gcc/testsuite/gcc.dg/pr35899.c Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/testsuite/ChangeLog branches/gcc-4_3-branch/gcc/tree-inline.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35899
[Bug c/35739] [4.3/4.4 regression] ICE with _Decimal128 and va_list
--- Comment #6 from jakub at gcc dot gnu dot org 2008-04-16 16:10 --- Subject: Bug 35739 Author: jakub Date: Wed Apr 16 16:10:04 2008 New Revision: 134354 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134354 Log: PR c/35739 * tree-nrv.c (tree_nrv): Don't optimize if result_type is GIMPLE reg type. * gcc.dg/dfp/pr35739.c: New test. Added: branches/gcc-4_3-branch/gcc/testsuite/gcc.dg/dfp/pr35739.c Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/testsuite/ChangeLog branches/gcc-4_3-branch/gcc/tree-nrv.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35739
[Bug target/35662] [4.3/4.4 regression] gfortran interfaces badly with glibc sincosf() causing breakage
--- Comment #4 from jakub at gcc dot gnu dot org 2008-04-16 16:11 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35662
[Bug libstdc++/35954] [4.3/4.4 Regression] cannot build from read-only source tree
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||bkoz at gcc dot gnu dot org Severity|normal |major Keywords||build Summary|cannot build from read-only |[4.3/4.4 Regression] cannot |source tree |build from read-only source ||tree Target Milestone|--- |4.3.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35954
[Bug tree-optimization/35899] [4.3/4.4 Regression] ICE on filesystem code
--- Comment #7 from jakub at gcc dot gnu dot org 2008-04-16 16:11 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35899
[Bug c/35739] [4.3/4.4 regression] ICE with _Decimal128 and va_list
--- Comment #7 from jakub at gcc dot gnu dot org 2008-04-16 16:12 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35739
[Bug ada/35791] [Ada] V-table messed up with interface composition
-- 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|2008-04-01 20:49:40 |2008-04-16 16:20:53 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35791
[Bug preprocessor/35859] preprocessor segfaults when #include directive passed to macro
--- Comment #2 from tromey at gcc dot gnu dot org 2008-04-16 16:57 --- This works ok with 4.1 and with svn trunk. So, I'm closing this, since 4.0 is a closed branch. -- tromey at gcc dot gnu dot org changed: What|Removed |Added CC||tromey at gcc dot gnu dot ||org Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35859
[Bug fortran/35958] gfortran for Vista
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-04-16 17:40 --- Isn't this the same bug as PR 35916 ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35958
[Bug fortran/35958] gfortran for Vista
--- Comment #4 from DHConsultancy at skynet dot be 2008-04-16 17:44 --- Subject: Re: gfortran for Vista in a sense, yes, except that now also gcc 4.3.0 doesnt work anymore on Vista pinskia at gcc dot gnu dot org wrote: --- Comment #3 from pinskia at gcc dot gnu dot org 2008-04-16 17:40 --- Isn't this the same bug as PR 35916 ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35958
[Bug fortran/35958] gfortran for Vista
--- Comment #5 from pinskia at gcc dot gnu dot org 2008-04-16 17:48 --- The driver has not changed since January. *** This bug has been marked as a duplicate of 35916 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35958
[Bug fortran/35916] problem running gfortran 4.4.0 in Vista
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-04-16 17:48 --- *** Bug 35958 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35916
[Bug driver/35956] gcc/g++ print different trunk revision #
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-04-16 17:54 --- I don't have this problem: [EMAIL PROTECTED] local]$ ~/gcc-spu/bin/spu-elf-gcc -v Using built-in specs. Target: spu-elf Configured with: /home/apinski/src/local/gcc/configure --target=spu-elf --prefix=/home/apinski/gcc-spu --with-mpfr=/usr/local --with-newlib --enable-languages=c,c++,objc --with-headers Thread model: single gcc version 4.4.0 20080415 (experimental) [trunk revision 134325] (GCC) [EMAIL PROTECTED] local]$ ~/gcc-spu/bin/spu-elf-g++ -v Using built-in specs. Target: spu-elf Configured with: /home/apinski/src/local/gcc/configure --target=spu-elf --prefix=/home/apinski/gcc-spu --with-mpfr=/usr/local --with-newlib --enable-languages=c,c++,objc --with-headers Thread model: single gcc version 4.4.0 20080415 (experimental) [trunk revision 134325] (GCC) Are you sure you did not run gcc_update while doing a build? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35956
[Bug fortran/35940] Array BACK ignored in INDEX intrinsic when other args scalar
--- Comment #2 from tkoenig at gcc dot gnu dot org 2008-04-16 18:09 --- Confirmed, not a regression. -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added Keywords||wrong-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35940
[Bug libstdc++/35915] [4.4 Regression] atomic.cc:31:20: error: stdint.h: No such file
--- Comment #6 from andreast at gcc dot gnu dot org 2008-04-16 18:12 --- I have a patch in testing. Looks ok so far. One question, is it ok to place gstdint.h into the include directory? And not like others in the toplevel build dir? Index: configure.ac === --- configure.ac(revision 134344) +++ configure.ac(working copy) @@ -147,6 +147,8 @@ GLIBCXX_CHECK_COMPLEX_MATH_SUPPORT GLIBCXX_CHECK_STDLIB_SUPPORT + GCC_HEADER_STDINT(include/gstdint.h) + # For showmanyc_helper(). AC_CHECK_HEADERS(sys/ioctl.h sys/filio.h) GLIBCXX_CHECK_POLL Index: src/atomic.cc === --- src/atomic.cc (revision 134344) +++ src/atomic.cc (working copy) @@ -28,7 +28,7 @@ // invalidate any other reasons why the executable file might be covered by // the GNU General Public License. -#include stdint.h +#include gstdint.h #include cstdatomic #define LOGSIZE 4 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35915
[Bug fortran/35952] Segmentation fault with character strings only when compiling with -funroll-loops and -O3
--- Comment #3 from tkoenig at gcc dot gnu dot org 2008-04-16 18:15 --- I cannot reproduce this on i686-pc-linux-gnu; valgrind shows no errors. This may be target specific. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35952
[Bug fortran/35947] [4.3, 4.4 regression] wrong answers with array constructor argument to IEOR
--- Comment #1 from tkoenig at gcc dot gnu dot org 2008-04-16 18:19 --- Confirmed, a regression: $ gfortran foo.f $ ./a.out 1 2 3 4 5 6 7 8 9 10 10 9 8 7 6 5 4 3 2 1 8 10 4 2 0 2 4 10 8*** 11 11 11 3 3 3 3 11 11 11 $ ifort foo.f $ ./a.out 1 2 3 4 5 6 7 8 9 10 10 9 8 7 6 5 4 3 2 1 11 11 11 3 3 3 3 11 11 11 11 11 11 3 3 3 3 11 11 11 $ gfortran-4.2 foo.f $ ./a.out 1 2 3 4 5 6 7 8 9 10 10 9 8 7 6 5 4 3 2 1 11 11 11 3 3 3 3 11 11 11 11 11 11 3 3 3 3 11 11 11 $ gfortran-4.3 -static foo.f $ ./a.out 1 2 3 4 5 6 7 8 9 10 10 9 8 7 6 5 4 3 2 1 8 10 4 2 0 2 4 10 8 10 11 11 11 3 3 3 3 11 11 11 -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||wrong-code Last reconfirmed|-00-00 00:00:00 |2008-04-16 18:19:41 date|| Summary|wrong answers with array|[4.3, 4.4 regression] wrong |constructor argument to IEOR|answers with array ||constructor argument to IEOR Target Milestone|--- |4.3.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35947
[Bug fortran/35940] Array BACK ignored in INDEX intrinsic when other args scalar
-- tkoenig at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-04-16 18:16:05 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35940
[Bug fortran/35946] wrong result with array constructor as argument to ATAN2
--- Comment #1 from tkoenig at gcc dot gnu dot org 2008-04-16 18:36 --- Confirmed, a regression vs. 4.2.3: $ gfortran fa.f $ ./a.out 10.0 9.0 8.0 7.0 6.0 5.0 4.0 3.0 2.0 1.0 1 0.11066 0.09967 -0.01099 2 0.24498 0.21867 -0.02631 3 0.40489 0.35877 -0.04612 4 0.58800 0.51915 -0.06886 5 0.78540 0.69474 -0.09066 6 0.98279 0.87606 -0.10674 7 1.16590 1.05165 -0.11425 8 1.32582 1.21203 -0.11379 9 1.46014 1.35213 -0.10801 10 3.14159 1.47113 -1.67047 $ ifort fa.f $ ./a.out 10.0 9.0 8.0 7.0 6.0 5.0 4.0 3.0 2.0 1.0 1 0.09967 0.09967 0.0 2 0.21867 0.21867 0.0 3 0.35877 0.35877 0.0 4 0.51915 0.51915 0.0 5 0.69474 0.69474 0.0 6 0.87606 0.87606 0.0 7 1.05165 1.05165 0.0 8 1.21203 1.21203 0.0 9 1.35213 1.35213 0.0 10 1.47113 1.47113 0.0 $ gfortran-4.2 fa.f $ ./a.out 10.0 9.0 8.0 7.0 6.0 5.0 4.0 3.0 2.0 1.0 1 0.09967 0.09967 0.0 2 0.21867 0.21867 0.0 3 0.35877 0.35877 0.0 4 0.51915 0.51915 0.0 5 0.69474 0.69474 0.0 6 0.87606 0.87606 0.0 7 1.05165 1.05165 0.0 8 1.21203 1.21203 0.0 9 1.35213 1.35213 0.0 10 1.47113 1.47113 0.0 $ gfortran-4.3 fa.f $ ./a.out 10.0 9.0 8.0 7.0 6.0 5.0 4.0 3.0 2.0 1.0 1 0.11066 0.09967 -0.01099 2 0.24498 0.0 -0.24498 3 0.40489 0.0 -0.40489 4 0.58800 0.0 -0.58800 5 0.78540 0.0 -0.78540 6 0.98279 0.87606 -0.10674 7 1.16590 1.05165 -0.11425 8 1.32582 1.21203 -0.11379 9 1.46014 1.35213 -0.10801 10 3.14159 1.47113 -1.67047 -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Known to fail||4.3.1 4.4.0 Known to work||4.2.3 Last reconfirmed|-00-00 00:00:00 |2008-04-16 18:36:40 date|| Target Milestone|--- |4.3.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35946
[Bug libstdc++/35915] [4.4 Regression] atomic.cc:31:20: error: stdint.h: No such file
--- Comment #7 from bkoz at gcc dot gnu dot org 2008-04-16 18:39 --- Hey Andreas. This is fine for the time being. If (include/gstdint.h) ends up being a problem (as include directory may not exist when being output?), you can just do (gstdint.h) and then add a special rule in include/Makefile.am for host_headers_noist to copy from builddir to include dir. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35915
[Bug fortran/35944] [4.3 Regression] wrong result for MOD with kind=10 for some array argument values
--- Comment #7 from uros at gcc dot gnu dot org 2008-04-16 18:39 --- Subject: Bug 35944 Author: uros Date: Wed Apr 16 18:39:08 2008 New Revision: 134359 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134359 Log: PR target/35944 * gfortran.dg/pr35944-1.f90: New test. * gfortran.dg/pr35944-2.f90: Ditto. Added: trunk/gcc/testsuite/gfortran.dg/pr35944-1.f90 trunk/gcc/testsuite/gfortran.dg/pr35944-2.f90 Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35944
[Bug libstdc++/35915] [4.4 Regression] atomic.cc:31:20: error: stdint.h: No such file
--- Comment #8 from bkoz at gcc dot gnu dot org 2008-04-16 18:52 --- in configure.ac please put GCC_STDINT out of native/cross bit of configure, and run unconditionally like so: GCC_LINUX_FUTEX([AC_DEFINE(HAVE_LINUX_FUTEX, 1, [Define if futex syscall is available.])]) GCC_HEADER_STDINT(include/gstdint.h) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35915
[Bug gcov-profile/34609] [4.3 regression] ICE with -ftest-coverage and references
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-04-16 19:50 --- I see this issue even with 4.1.1 and even without -ftest-coverage. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34609
[Bug fortran/35959] New: Recursive function with allocatable array
Problem with gfortran while developing a recursive function which allocates an array stored in a derived-type. This is the sample test : module testmod #define _DYNAMIC_TYPE allocatable !#define _DYNAMIC_TYPE pointer type, public :: t_type integer, dimension(:), _DYNAMIC_TYPE :: chars end type t_type integer, save :: callnb = 0 contains recursive function recursivefunc ( this ) result ( match ) type(t_type), intent(in) :: this type(t_type) :: subpattern logical :: thisalloc integer :: thislength logical :: match write ( * , * ) recursivefunc [ , callnb , ] thislength = size ( this % chars ) write ( * , * ) length :, thislength callnb = callnb + 1 thisalloc = allocated ( this % chars ) !thisalloc = associated ( this % chars ) if ( .NOT. thisalloc ) then write ( 6 , * ) STOP with error ! stop endif if ( thislength == 0 ) then match = .true. return endif allocate ( subpattern % chars ( thislength - 1 ) ) match = recursivefunc ( subpattern ) end function recursivefunc end module testmod program testprog use testmod implicit none type(t_type) :: this logical :: match allocate ( this % chars ( 10 )) match = recursivefunc ( this ) print * , match :, match end program testprog Compile it with : gfortran -x f95-cpp-input testZeroSizeRecursive2.f90 -o testZeroSizeRecursive2.exe (flibs-workbench) 60 % testZeroSizeRecursive2.exe recursivefunc [ 0 ] length : 10 recursivefunc [ 1 ] length : 9 STOP with error ! This is because the allocated statement return .false., even if the array is really allocated. Trying the pointer version by modifying the #define preprocessing statement and the allocated to associated make the problem disappear : recursivefunc [ 0 ] length : 10 recursivefunc [ 1 ] length : 9 recursivefunc [ 2 ] length : 8 recursivefunc [ 3 ] length : 7 recursivefunc [ 4 ] length : 6 recursivefunc [ 5 ] length : 5 recursivefunc [ 6 ] length : 4 recursivefunc [ 7 ] length : 3 recursivefunc [ 8 ] length : 2 recursivefunc [ 9 ] length : 1 recursivefunc [ 10 ] length : 0 match : T This is the version of gfortran I currently use ( I downloaded it today and I think that it is up-todate ) : (flibs-workbench) 61 % gfortran -v Using built-in specs. Target: i586-pc-mingw32 Configured with: ../trunk/configure --prefix=/mingw --enable-languages=c,fortran --with-gmp=/home/FX/local --with-ld=/mingw/bin/ld --with-as=/mingw/bin/as --disable-werror --enable-bootstrap --enable-threads --disable-nls --build=i586-pc-mingw32 --enable-libgomp --disable-shared Thread model: win32 gcc version 4.4.0 20080312 (experimental) [trunk revision 133139] (GCC) Regards, Michaël Baudin -- Summary: Recursive function with allocatable array Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: michael dot baudin at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35959
[Bug preprocessor/33415] Can't compile .cpp file with UTF-8 BOM.
--- Comment #3 from tromey at gcc dot gnu dot org 2008-04-16 20:37 --- I think some BOMs will be handled by iconv. In particular I tried UTF-16 and this seemed to work ok. UTF-8 is a special problem in two ways. First, glibc's iconv does not appear to recognize the UTF-8 BOM. And, even if it did, we special-case UTF-8 (at least on non-EBCDIC hosts). This could be fixed in files.c without too much difficulty (it makes a few inconvenient assumptions), except that files.c does not know the name of the source charset. -- tromey at gcc dot gnu dot org changed: What|Removed |Added CC||tromey at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33415
[Bug fortran/35932] [4.3/4.4 Regression] ICE: CHAR with array arg and also a KIND arg
--- Comment #2 from pault at gcc dot gnu dot org 2008-04-16 20:53 --- Subject: Bug 35932 Author: pault Date: Wed Apr 16 20:53:07 2008 New Revision: 134364 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134364 Log: 2008-04-16 Paul Thomas [EMAIL PROTECTED] PR fortran/35932 * trans-intrinsic.c (gfc_conv_intrinsic_char): Even though KIND is not used, the argument must be converted. 2008-04-16 Paul Thomas [EMAIL PROTECTED] PR fortran/35932 * gfortran.dg/intrinsic_char_1.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/intrinsic_char_1.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-intrinsic.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35932
[Bug libstdc++/35915] [4.4 Regression] atomic.cc:31:20: error: stdint.h: No such file
--- Comment #9 from andreast at gcc dot gnu dot org 2008-04-16 20:56 --- Patch is here, the changes from comment #8 are included. http://gcc.gnu.org/ml/gcc-patches/2008-04/msg01320.html -- andreast at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|bkoz at gcc dot gnu dot org |andreast at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35915
[Bug driver/35916] problem running GCC under Vista with relocated directory
--- Comment #5 from steven at gcc dot gnu dot org 2008-04-16 21:02 --- This will probably only be fixed once a gfortran developer gets access to Vista... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35916
[Bug fortran/35932] [4.3/4.4 Regression] ICE: CHAR with array arg and also a KIND arg
--- Comment #3 from pault at gcc dot gnu dot org 2008-04-16 21:02 --- Subject: Bug 35932 Author: pault Date: Wed Apr 16 21:02:10 2008 New Revision: 134366 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134366 Log: 2008-04-16 Paul Thomas [EMAIL PROTECTED] PR fortran/35932 * trans-intrinsic.c (gfc_conv_intrinsic_char): Even though KIND is not used, the argument must be converted. 2008-04-16 Paul Thomas [EMAIL PROTECTED] PR fortran/35932 * gfortran.dg/intrinsic_char_1.f90: New test. Added: branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/intrinsic_char_1.f90 Modified: branches/gcc-4_3-branch/gcc/fortran/ChangeLog branches/gcc-4_3-branch/gcc/fortran/trans-intrinsic.c branches/gcc-4_3-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35932
[Bug fortran/35932] [4.3/4.4 Regression] ICE: CHAR with array arg and also a KIND arg
--- Comment #4 from pault at gcc dot gnu dot org 2008-04-16 21:07 --- Fixed on 4.4 and 4.3 Thanks for the report Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35932
[Bug fortran/35960] New: run time abort with assignment of RESHAPEd zero sized array
Each line of the following subroutine causes a run-time abort. Except for the one labeled gf1069. It works if literal constants are used in place of the nf* variables. Dick Hendrickson program try_gf1065 ! fails on Windows XP ! gcc version 4.4.0 20080312 (experimental) [trunk revision 133139] call gf1065(1, 2, 3, 4, 7, 8, 9) end SUBROUTINE GF1065(nf1,nf2,nf3,nf4,nf7,nf8,nf9) !also 1066 thru 1070, 1069 works REAL RDA(10,9) REAL RCA1(90) integer ila(2) !gf1065 RDA(NF9:NF8, NF7:NF3) = RESHAPE(RCA1,(/0,0/), (/1.0/),(/2,1/)) print *, 'gf1065' !gf1066 rDA(NF9:NF8, NF7:NF3) = RESHAPE(rCA1,(/0,0/),ORDER=(/2,1/)) print *, 'gf1066' ILA(1) = 5 ILA(2) = 0 !gf1067 rDA(NF4:NF8, NF7:NF3) = RESHAPE(rcA1,ILA) print *, 'gf1067' !gf1068 RdA(NF4:NF8, NF7:NF3) = RESHAPE(RcA1,ILA,PAD=(/-1.0/)) print *, 'gf1068' ILA(1) = 0 ILA(2) = 5 !gf1069this one works RdA(NF9:NF8,NF4:NF8)=RESHAPE(RcA1,ILA,(/-1.0/),(/NF2,NF1/)) print *, 'gf1069' ILA(1) = 5 ILA(2) = 0 !gf1070 RdA(NF4:NF8, NF7:NF3) = RESHAPE(RcA1,ILA,ORDER=(/NF1,NF2/)) print *, 'gf1070' END SUBROUTINE C:\gfortran:gfortran gf1065.f C:\gfortran:a Fortran runtime error: shape and target do not conform -- Summary: run time abort with assignment of RESHAPEd zero sized array Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dick dot hendrickson at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35960
[Bug preprocessor/33415] Can't compile .cpp file with UTF-8 BOM.
--- Comment #4 from tromey at gcc dot gnu dot org 2008-04-16 21:29 --- Testing a patch. -- tromey at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |tromey at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2007-09-14 09:28:32 |2008-04-16 21:29:21 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33415
[Bug libstdc++/35915] [4.4 Regression] atomic.cc:31:20: error: stdint.h: No such file
--- Comment #10 from andreast at gcc dot gnu dot org 2008-04-16 21:30 --- Subject: Bug 35915 Author: andreast Date: Wed Apr 16 21:30:11 2008 New Revision: 134368 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134368 Log: 2008-04-16 Andreas Tobler [EMAIL PROTECTED] PR libstdc++/35915 * configure.ac: Use GCC_HEADER_STDINT. * src/atomic.cc: Include gstdint.h * configure: Regenerate. * Makefile.in: Likewise. * doc/Makefile.in: Likewise. * include/Makefile.in: Likewise. * libmath/Makefile.in: Likewise. * libsupc++/Makefile.in: Likewise. * po/Makefile.in: Likewise. * src/Makefile.in: Likewise. * testsuite/Makefile.in: Likewise. * aclocal.m4: Likewise. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/Makefile.in trunk/libstdc++-v3/aclocal.m4 trunk/libstdc++-v3/configure trunk/libstdc++-v3/configure.ac trunk/libstdc++-v3/doc/Makefile.in trunk/libstdc++-v3/include/Makefile.in trunk/libstdc++-v3/libmath/Makefile.in trunk/libstdc++-v3/libsupc++/Makefile.in trunk/libstdc++-v3/po/Makefile.in trunk/libstdc++-v3/src/Makefile.in trunk/libstdc++-v3/src/atomic.cc trunk/libstdc++-v3/testsuite/Makefile.in -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35915
[Bug libgcj/35950] jar produces files ecj won't handle
--- Comment #1 from gnu_andrew at member dot fsf dot org 2008-04-16 22:21 --- The difference is noticeable just from the zip output. This is the working tools.zip created by fastjar: 0 04-16-08 03:08 gnu/classpath/tools/tnameserv/ 2391 04-16-08 03:08 gnu/classpath/tools/tnameserv/Main.class 1136 04-16-08 03:08 gnu/classpath/tools/tnameserv/Main$1.class 2066 04-16-08 03:08 gnu/classpath/tools/tnameserv/messages.properties 1082 04-16-08 03:08 gnu/classpath/tools/tnameserv/Main$2.class 1160 04-16-08 03:08 gnu/classpath/tools/tnameserv/Messages.class and the broken version: 0 04-16-08 23:10 ./gnu/classpath/tools/tnameserv/ 2391 04-16-08 23:10 ./gnu/classpath/tools/tnameserv/Main.class 1136 04-16-08 23:10 ./gnu/classpath/tools/tnameserv/Main$1.class 2066 04-16-08 23:10 ./gnu/classpath/tools/tnameserv/messages.properties 1082 04-16-08 23:10 ./gnu/classpath/tools/tnameserv/Main$2.class 1160 04-16-08 23:10 ./gnu/classpath/tools/tnameserv/Messages.class -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35950
[Bug libgcj/35950] jar produces files ecj won't handle
--- Comment #2 from tromey at gcc dot gnu dot org 2008-04-16 22:30 --- If you know of a specific gjar patch, I can pull it over. -- tromey at gcc dot gnu dot org changed: What|Removed |Added CC||tromey at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35950
[Bug libgcj/35950] jar produces files ecj won't handle
--- Comment #3 from tromey at gcc dot gnu dot org 2008-04-16 22:32 --- Never mind, I see it now. -- tromey at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-04-16 22:32:03 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35950
[Bug libgcj/35950] jar produces files ecj won't handle
--- Comment #4 from gnu_andrew at member dot fsf dot org 2008-04-16 23:34 --- I recall there was a CP one that was fixed, but can't seem to find it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35950
[Bug fortran/35724] [4.3/4.4 Regression] Compile time segmentation fault for CSHIFT with negative third arg
--- Comment #9 from jvdelisle at gcc dot gnu dot org 2008-04-17 01:35 --- I failed to take care of the equivalent problem for eoshift. Here is a case from Dick on this. I have a patch testing. SUBROUTINE RA0072(DDA,LDA,nf10,nf1,mf1,nf2) ! fails on Windows XP ! gcc version 4.4.0 20080312 (experimental) [trunk revision 133139] !compile time seq fault REAL DDA(10,10) LOGICAL LDA(10,10) WHERE (LDA) DDA = eoSHIFT(DDA,1,1.0,-MF1) END SUBROUTINE -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35724
[Bug c/35961] New: Erroneous error message using gcc-4.3.0 when signedness warning thrown
When compiling the recent proftpd-1.3.2rc1 source code using gcc-4.3.0, a user
reported a problem where gcc reports a problem with the -Wno-long-double
option:
gcc -DHAVE_CONFIG_H -DLINUX -I.. -I../include -I/usr/include/mysql -O2
-Wall
-Wno-long-double -c mod_sql.c
mod_sql.c: In function 'check_auth_openssl':
mod_sql.c:685: warning: pointer targets in passing argument 3 of
'EVP_DigestFinal' differ in signedness
mod_sql.c:688: warning: pointer targets in passing argument 1 of
'EVP_EncodeBlock' differ in signedness
At top level:
cc1: error: unrecognized command line option -Wno-long-double
make[1]: *** [mod_sql.o] Error 1
However, I verified that gcc-4.3.0 does in fact support -Wno-long-double,
using:
# echo 'void f(){}' conftest.c
# gcc -c -Wno-long-double conftest.c 21
# echo $?
0
So the error about -Wno-long-double appears to be misleading. In fact, a
fuller output from using gcc-4.3.0 for the proftpd-1.3.2rc1 source code shows
several successful gcc invocations with that option:
flecha:/usr/local/src/proftpd/proftpd-1.3.2rc1# make
echo \#define BUILD_STAMP \`date`\ include/buildstamp.h
cd lib/ make lib
make[1]: Entering directory `/usr/local/src/proftpd/proftpd-1.3.2rc1/lib'
gcc -DHAVE_CONFIG_H -DLINUX -I.. -I../include -I/usr/include/mysql -O2
-Wall -Wno-long-double -c pr_fnmatch.c
gcc -DHAVE_CONFIG_H -DLINUX -I.. -I../include -I/usr/include/mysql -O2
-Wall -Wno-long-double -c sstrncpy.c
gcc -DHAVE_CONFIG_H -DLINUX -I.. -I../include -I/usr/include/mysql -O2
-Wall -Wno-long-double -c strsep.c
gcc -DHAVE_CONFIG_H -DLINUX -I.. -I../include -I/usr/include/mysql -O2
-Wall -Wno-long-double -c vsnprintf.c
gcc -DHAVE_CONFIG_H -DLINUX -I.. -I../include -I/usr/include/mysql -O2
-Wall -Wno-long-double -c glibc-glob.c
...
gcc -DHAVE_CONFIG_H -DLINUX -I.. -I../include -I/usr/include/mysql -O2
-Wall -Wno-long-double -c mod_ident.c
gcc -DHAVE_CONFIG_H -DLINUX -I.. -I../include -I/usr/include/mysql -O2
-Wall -Wno-long-double -c mod_auth_pam.c
gcc -DHAVE_CONFIG_H -DLINUX -I.. -I../include -I/usr/include/mysql -O2
-Wall -Wno-long-double -c mod_sql.c
mod_sql.c: In function 'check_auth_openssl':
mod_sql.c:685: warning: pointer targets in passing argument 3 of
'EVP_DigestFinal' differ in signedness
mod_sql.c:688: warning: pointer targets in passing argument 1 of
'EVP_EncodeBlock' differ in signedness
At top level:
cc1: error: unrecognized command line option -Wno-long-double
I suspect that the root problem was the warning about the signedness
discrepancy, and not the -Wno-long-double option at all.
For comparison, using gcc-4.2 works.
--
Summary: Erroneous error message using gcc-4.3.0 when signedness
warning thrown
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tj at castaglia dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35961
[Bug fortran/35724] [4.3/4.4 Regression] Compile time segmentation fault for CSHIFT with negative third arg
--- Comment #10 from jvdelisle at gcc dot gnu dot org 2008-04-17 04:31 --- Subject: Bug 35724 Author: jvdelisle Date: Thu Apr 17 04:30:04 2008 New Revision: 134376 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134376 Log: 2008-04-16 Jerry DeLisle [EMAIL PROTECTED] PR fortran/35724 * iresolve.c (gfc_resolve_eoshift): Check for NULL symtree in test for optional argument attribute. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/iresolve.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35724
[Bug fortran/35724] [4.3/4.4 Regression] Compile time segmentation fault for CSHIFT with negative third arg
--- Comment #11 from jvdelisle at gcc dot gnu dot org 2008-04-17 04:33 --- Subject: Bug 35724 Author: jvdelisle Date: Thu Apr 17 04:33:11 2008 New Revision: 134377 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134377 Log: 2008-04-16 Jerry DeLisle [EMAIL PROTECTED] PR fortran/35724 * gfortran.dg/eoshift_2.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/eoshift_2.f90 Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35724
[Bug fortran/35724] [4.3/4.4 Regression] Compile time segmentation fault for CSHIFT with negative third arg
--- Comment #12 from jvdelisle at gcc dot gnu dot org 2008-04-17 04:38 --- I need to backport this to 4.3.1. Also, Dick, please let me know if you see any other combinations like this that fail. Thanks for reporting. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35724
[Bug driver/35956] gcc/g++ print different trunk revision #
--- Comment #2 from dimhen at gmail dot com 2008-04-17 05:05 --- i reproduce err with #134344. 1. pre condition 'svnversion -n' print 134340 'gcc -v' print 134340 'g++ -v' print 134339 2. gcc_update. Update to #134344. No files has changed. 3. make install 'gcc -v' print 134344 'g++ -v' print 134339 4. make make install 'gcc -v' print 134344 'g++ -v' print 134344 Need i close PR as INVALID or there are missed dependence(s) in Makefile? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35956
