[Bug c++/30225] builtins's decl is copied in some cases where it is not needed to be copied
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-12-22 08:31 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30225
[Bug c++/30225] builtins's decl is copied in some cases where it is not needed to be copied
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-12-22 08:31 --- Subject: Bug 30225 Author: pinskia Date: Fri Dec 22 08:31:03 2006 New Revision: 120145 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120145 Log: 2006-12-21 Andrew Pinski <[EMAIL PROTECTED]> PR C++/30225 * decl.c (cxx_builtin_function): Only copy the decl if adding it to the std namespace Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30225
[Bug c++/30274] [4.2/4.3 Regression] bool bit-field: wrong increment and decremenet
--- Comment #3 from s__nakayama at infoseek dot jp 2006-12-22 08:39 ---
(In reply to comment #2)
> When is the justification that we expect a value of 2? Bool in C++ is
> a one-bit type and when you do x.x++ I would imagine that you overflow
> the range of that type. The fact that you declare it as a bit-field of
> length 4 is immaterial, in my opinion: you also don't get a 128-bit integer
> simply by declaring a variable as
> struct X {
> int x : 128;
> };
It is a result of g++4.2 not a expectation that a value becomes 2.
Bit-size is immaterial.
The problem is that std 5.3.2 isn't applied for bit-field.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30274
[Bug c++/30274] [4.2/4.3 Regression] bool bit-field: wrong increment and decremenet
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-12-22 08:45 --- This is a very simple patch to fix this issue also: -if (same_type_p (TREE_TYPE (arg), boolean_type_node)) +if (TREE_CODE (TREE_TYPE (arg)) == BOOLEAN_TYPE) -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |ASSIGNED Last reconfirmed|2006-12-21 18:13:05 |2006-12-22 08:45:50 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30274
[Bug target/9539] [Windows] builtin [long/set]jmp not working properly with signals
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |NEW Last reconfirmed|2005-09-24 17:04:36 |2006-12-22 09:20:06 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9539
[Bug c++/30274] [4.2/4.3 Regression] bool bit-field: wrong increment and decremenet
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-12-22 09:24 --- Actually I was wrong in saying this is an easy fix. That part of the fix is still needed but there is another issue in that we are getting the wrong type for the increment: unit size align 8 symtab 0 alias set -1 precision 4 min max > arg 0 unit size align 8 symtab 0 alias set -1 fields X() X(constX&) this=(X&) n_parents=0 use_template=0 interface-unknown pointer_to_this chain > used tree_1 tree_2 tree_3 decl_5 QI file t.cc line 9 size unit size align 8 context initial > arg 1 used unsigned external nonlocal bit-field nonaddressable decl_3 decl_4 QI file t.cc line 4 size unit size align 1 offset_align 128 offset bit offset bit_field_type unit size align 8 symtab 0 alias set -1 precision 1 min max > context chain nonlocal decl_4 VOID file t.cc line 3 align 1 context >>> -- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|pinskia at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30274
[Bug fortran/30276] New: gfortran include problem
This bug has similarities with bug no 20811. For some reason the gfortran compilier cannot locate a file when its absolute path is included. See below: My operating system: $ uname -a Linux lylt0061.terma.com 2.6.18-1.2868.fc6 #1 SMP Fri Dec 15 17:31:29 EST 2006 i686 i686 i386 GNU/Linux The source file: $ more test.f program main include '/home/allan/slot2usl/physcons.inc' stop end The include file: $ ls -l /home/allan/slot2usl/physcons.inc -rw-r--r-- 1 allan users 158 Dec 19 12:05 /home/allan/slot2usl/physcons.inc The call to the compiler and error message: $ gfortran -v -c test.f Using built-in specs. Target: i386-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-libgcj-multifile --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --enable-plugin --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --with-cpu=generic --host=i386-redhat-linux Thread model: posix gcc version 4.1.1 20061011 (Red Hat 4.1.1-30) /usr/libexec/gcc/i386-redhat-linux/4.1.1/f951 test.f -ffixed-form -quiet -dumpbase test.f -mtune=generic -auxbase test -version -I /usr/lib/gcc/i386-redhat-linux/4.1.1/finclude -o /tmp/cc6e5iPa.s GNU F95 version 4.1.1 20061011 (Red Hat 4.1.1-30) (i386-redhat-linux) compiled by GNU C version 4.1.1 20061011 (Red Hat 4.1.1-30). GGC heuristics: --param ggc-min-expand=99 --param ggc-min-heapsize=129304 Error: Can't open included file '/home/allan/slot2usl/physcons.inc' Hope someone can help. Regards Allan -- Summary: gfortran include problem Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: aog at terma dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30276
[Bug target/29682] ICE: in change_pattern, at haifa-sched.c:4066 with -O3 -msched-control-spec
--- Comment #4 from tbm at cyrius dot com 2006-12-22 10:43 --- What's the status of this patch? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29682
[Bug c++/30277] New: bit-filed: wrong overload resolution
test case
#include
struct S
{
signed long l: 32;
};
void foo(long)
{
std::cout << "NG\n";
}
void foo(int)
{
std::cout << "OK\n";
}
int main()
{
S x = {1};
foo(x.l+0);
return 0;
}
result
$g++ a.c -o a; ./a
NG
According to ISO/IEC 14882 4.5 p3, type of `x.l+0' becomes int by integral
promotions. (in the case: int and long are 32 bits)
Therefore, foo(int) shall be called.
But GCC calls foo(long).
Revision of BUG 16376 seems incomplete.
GCC version: 4.2 20061212
--
Summary: bit-filed: wrong overload resolution
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: s__nakayama at infoseek dot jp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30277
[Bug rtl-optimization/29840] [4.3 Regression] build/genconditions ../../gcc/gcc/config/pa/pa.md > tmp-condmd.c: /bin/sh: 13354 Memory fault(coredump)
--- Comment #35 from bonzini at gnu dot org 2006-12-22 12:29 --- Subject: Bug 29840 Author: bonzini Date: Fri Dec 22 12:28:52 2006 New Revision: 120147 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120147 Log: 2006-12-22 Paolo Bonzini <[EMAIL PROTECTED]> PR rtl-optimization/29840 * fwprop.c (forward_propagate_into): Reject artificial uses/defs. (fwprop_init): Add DF_HARD_REGS to df_init call. Modified: trunk/gcc/ChangeLog trunk/gcc/fwprop.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29840
[Bug rtl-optimization/29840] [4.3 Regression] build/genconditions ../../gcc/gcc/config/pa/pa.md > tmp-condmd.c: /bin/sh: 13354 Memory fault(coredump)
--- Comment #36 from bonzini at gnu dot org 2006-12-22 12:52 --- Should be fixed now (by inspection of the reduced test case). Patch committed is at this URL: http://gcc.gnu.org/ml/gcc-patches/2006-12/msg01378.html -- bonzini at gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2006- ||12/msg01378.html Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29840
[Bug fortran/30276] gfortran include problem
--- Comment #1 from burnus at gcc dot gnu dot org 2006-12-22 12:56 ---
Confirmed. I think the following patch should work. I'll take the bug next year
(if I don't forget). Otherwise, if someone wants to take it, feel free to do
so.
The problem is that only
for include_path in include_paths
try-to-open( include_path + filename )
is checked, never the filename itself.
Index: gcc/fortran/scanner.c
===
--- gcc/fortran/scanner.c (Revision 120144)
+++ gcc/fortran/scanner.c (Arbeitskopie)
@@ -199,6 +199,11 @@
gfc_directorylist *p;
FILE *f;
+ f = gfc_open_file (name);
+
+ if (f != NULL)
+return f;
+
for (p = list; p; p = p->next)
{
if (module && !p->use_for_modules)
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
CC||burnus at gcc dot gnu dot
||org
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Known to fail||4.1.1 4.2.0 4.3.0
Last reconfirmed|-00-00 00:00:00 |2006-12-22 12:56:06
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30276
[Bug fortran/30278] New: Inconsistencies with backslash handling
A testcase provided by Eef van Beveren, notice the difference between the
handling of backslash in the format string and in the regular string:
[EMAIL PROTECTED]:~/src> cat backslash.f
call wrt('\backslash')
call wrt('\\backslash')
write (*,100)
write (*,200)
stop
100 format ('\backslash now results in \backslash')
200 format ('\\backslash now results in \\backslash')
end
subroutine wrt(a)
character*(*) a
lena = len(a)
write(*,*) 'results in: ', a(1:lena)
return
end
[EMAIL PROTECTED]:~/src> gfortran backslash.f
[EMAIL PROTECTED]:~/src> ./a.out
results in:ackslash
results in: \backslash
\backslash now results in \backslash
\\backslash now results in \\backslash
[EMAIL PROTECTED]:~/src> gfortran -fno-backslash backslash.f
[EMAIL PROTECTED]:~/src> ./a.out
results in: \backslash
results in: \\backslash
\backslash now results in \backslash
\\backslash now results in \\backslash
[EMAIL PROTECTED]:~/src> g77 backslash.f
[EMAIL PROTECTED]:~/src> ./a.out
results in:ackslash
results in: \backslash
ackslash now results inackslash
\backslash now results in \backslash
[EMAIL PROTECTED]:~/src>
--
Summary: Inconsistencies with backslash handling
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tobi at gcc dot gnu dot org
OtherBugsDependingO 19292
nThis:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30278
[Bug middle-end/7651] Define -Wextra strictly in terms of other warning flags
--- Comment #10 from manu at gcc dot gnu dot org 2006-12-22 15:54 --- Subject: Bug 7651 Author: manu Date: Fri Dec 22 15:54:05 2006 New Revision: 120151 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120151 Log: 2006-12-22 Manuel Lopez-Ibanez <[EMAIL PROTECTED]> PR middle-end/7651 * c.opt (Wclobbered): New. * doc/invoke.texi (Wclobbered): Document it. (Wextra): Enabled by -Wextra. * c-opts.c (c_common_post_options): Enabled by -Wextra. * flow.c (rest_of_handle_life): Replace Wextra with Wclobbered. * function.c (setjmp_vars_warning): Only warn for Wclobbered. (setjmp_args_warning): Likewise. testsuite/ * gcc.dg/attr-returns_twice-1.c: Replace Wextra with Wclobbered. * gcc.dg/setjmp-1.c: Add explicit Wclobbered. Modified: trunk/gcc/ChangeLog trunk/gcc/c-opts.c trunk/gcc/c.opt trunk/gcc/doc/invoke.texi trunk/gcc/flow.c trunk/gcc/function.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/attr-returns_twice-1.c trunk/gcc/testsuite/gcc.dg/setjmp-1.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7651
[Bug c++/30279] New: Not finding pointer to function
I have a friend sorting function defined in my class and the compiler complains it has not been declared. It works perfectly on a i686-redhat-linux-gnu with gcc 4.0.2. The compiler has been installed from the RPM distributed with Fedora Core 5. The command line used is the following: g++ -Wall -o test -save-temps sorting.cxx and the compiler ouput is sorting.cxx: In member function void MyVect::sortClass(): sorting.cxx:12: error: cmp was not declared in this scope I will try to post the *i* files. Regards, Antonio -- Summary: Not finding pointer to function Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: antonio dot bulgheroni at gmail dot com GCC build triplet: x86_64-redhat-linux-gnu GCC host triplet: x86_64-redhat-linux-gnu GCC target triplet: x86_64-redhat-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30279
[Bug c++/30279] Not finding pointer to function
--- Comment #1 from antonio dot bulgheroni at gmail dot com 2006-12-22 16:27 --- Created an attachment (id=12833) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12833&action=view) The intermediate temporary file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30279
[Bug c++/30279] Not finding pointer to function
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-12-22 17:10 ---
Please read:
http://gcc.gnu.org/gcc-4.1/changes.html
ARM-style name-injection of friend declarations is no longer the default. For
example:
struct S {
friend void f();
};
void g() { f(); }
will not be accepted; instead a declaration of f will need to be present
outside of the scope of S. The new -ffriend-injection option will enable the
old behavior.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution||INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30279
[Bug target/29867] [4.3 Regression] building libgfortran fails because of multiple definitions gcc-4.3-20061111
--- Comment #16 from Jean-pierre dot vial at wanadoo dot fr 2006-12-22 19:20 --- Created an attachment (id=12836) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12836&action=view) complet error message x86_64 suse linux 10.1 in case it may help, here is the list of conflicting files (latest gcc-4.3: 20061216) /usr/include/bits/mathinline.h /usr/include/bits/sigset.h /usr/include/bits/stdio.h /usr/include/bits/string2.h /usr/include/ctype.h /usr/include/stdlib.h /usr/include/sys/stat.h /usr/include/sys/sysmacros.h extracted from the error file using : grep -o -P '^\/.+\.h' erreur |sort -u -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29867
[Bug libstdc++/30280] New: SIGSEGV on operator==(valarray, bool)
The (strictly speaking ill-formed) program below successfully compiles with
gcc 4.1.0 but fails with a SIGSEGV at runtime. I think it should either fail
to compile or, if it compiles because of a gcc extension, it should also run
successfully to completion.
$ cat u.cpp && g++ u.cpp && ./a.out
#include
#include
int main ()
{
std::valarray a (1);
assert (a == false);
}
Segmentation Fault (core dumped)
--
Summary: SIGSEGV on operator==(valarray, bool)
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30280
[Bug libstdc++/30280] SIGSEGV on operator==(valarray, bool)
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-12-22 19:52 --- What target is this one, all I get is: t.cc:8: error: cannot convert 'std::_Expr > >, bool>' to 'long int' for argument '1' to 'long int __builtin_expect(long int, long int)' -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30280
[Bug libstdc++/30280] SIGSEGV on operator==(valarray, bool)
--- Comment #2 from sebor at roguewave dot com 2006-12-22 20:22 --- (In reply to comment #1) This was gcc 4.1.0 on sparc-sun-solaris2.9. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30280
[Bug fortran/30084] segmentation fault when compiling certain code
--- Comment #7 from pault at gcc dot gnu dot org 2006-12-22 20:49 --- Subject: Bug 30084 Author: pault Date: Fri Dec 22 20:49:00 2006 New Revision: 120155 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120155 Log: 2006-12-22 Paul Thomas <[EMAIL PROTECTED]> PR fortran/25818 * trans-array.c (gfc_trans_g77_array): If the variable is optional or not always present, make the statement conditional on presence of the argument. * gfortran.h : Add symbol_attribute not_always_present. * resolve.c (check_argument_lists): New function to check if arguments are not present in all entries. PR fortran/30084 * module.c (mio_component_ref): Move treatment of unique name variables, during output, to fix_mio_expr. (fix_mio_expr): New function that fixes defective expressions before they are written to the module file. (mio_expr): Call the new function. (resolve_entries): Call check_argument_lists. 2006-12-22 Paul Thomas <[EMAIL PROTECTED]> PR fortran/25818 * gfortran.dg/entry_array_specs_2.f: New test. PR fortran/30084 * gfortran.dg/nested_modules_6.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/entry_array_specs_2.f trunk/gcc/testsuite/gfortran.dg/nested_modules_6.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/module.c trunk/gcc/fortran/resolve.c trunk/gcc/fortran/trans-array.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30084
[Bug fortran/25818] Problem with handling optional and entry master arguments
--- Comment #21 from pault at gcc dot gnu dot org 2006-12-22 20:49 --- Subject: Bug 25818 Author: pault Date: Fri Dec 22 20:49:00 2006 New Revision: 120155 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120155 Log: 2006-12-22 Paul Thomas <[EMAIL PROTECTED]> PR fortran/25818 * trans-array.c (gfc_trans_g77_array): If the variable is optional or not always present, make the statement conditional on presence of the argument. * gfortran.h : Add symbol_attribute not_always_present. * resolve.c (check_argument_lists): New function to check if arguments are not present in all entries. PR fortran/30084 * module.c (mio_component_ref): Move treatment of unique name variables, during output, to fix_mio_expr. (fix_mio_expr): New function that fixes defective expressions before they are written to the module file. (mio_expr): Call the new function. (resolve_entries): Call check_argument_lists. 2006-12-22 Paul Thomas <[EMAIL PROTECTED]> PR fortran/25818 * gfortran.dg/entry_array_specs_2.f: New test. PR fortran/30084 * gfortran.dg/nested_modules_6.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/entry_array_specs_2.f trunk/gcc/testsuite/gfortran.dg/nested_modules_6.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/module.c trunk/gcc/fortran/resolve.c trunk/gcc/fortran/trans-array.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25818
[Bug c++/30281] New: [reject valid?] mismatch type of virtual method.
#include
struct my_error : public std::runtime_error
{
my_error( std::string const& );
};
template < typename T >
struct wrapper
{
template < typename R >
void add_method( R ( T::* )() const );
};
void test()
{
wrapper< my_error >().add_method( &my_error::what );
}
g++ rejects this code:
error: no matching function for call to ‘wrapper::add_method(
const char* (std::runtime_error::*)()const)’
&my_error::what has &std::runtime_error::what type? weird.
btw.
non-templated add_method( char const* ( my_error::* )() const )
works fine, so i suppose it's a bug in c++ frontend.
--
Summary: [reject valid?] mismatch type of virtual method.
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pluto at agmk dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30281
[Bug libstdc++/30280] SIGSEGV on operator==(valarray, bool)
--- Comment #3 from pcarlini at suse dot de 2006-12-22 21:42 --- Hi. In fact, I'm getting the same as Andrew on x86-linux, x86_64-linux and powerpc-darwin. Seems a really weird target-dependent issue, I hope Eric can help, a minimum of debugging, a backtrace (thanks in advance, anyway) -- pcarlini at suse dot de changed: What|Removed |Added CC||ebotcazou at libertysurf dot ||fr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30280
[Bug libstdc++/30280] SIGSEGV on operator==(valarray, bool)
--- Comment #4 from ebotcazou at gcc dot gnu dot org 2006-12-22 22:17 --- No SIGSEGV for me with 4.1.1: gax% ./pr30280 Assertion failed: a == false, file pr30280.C, line 7 zsh: IOT instruction (core dumped) ./pr30280 Please provide the missing info as per http://gcc.gnu.org/bugs.html -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30280
[Bug libstdc++/30280] SIGSEGV on operator==(valarray, bool)
--- Comment #5 from sebor at roguewave dot com 2006-12-22 22:25 --- Regardless of whether the program aborts with SIGSEGV or SIGABRT, the point is that it should either not compile or it should run succesfully to completion. Here's the output of g++ -v if it helps: $ g++ -v Using built-in specs. Target: sparc-sun-solaris2.9 Configured with: /build/sebor/gcc-4.1.0/configure --enable-languages=c,c++ --prefix=/usr/local/gcc-4.1.0 : (reconfigured) /build/sebor/gcc-4.1.0/configure --enable-languages=c,c++ --prefix=/usr/local/gcc-4.1.0 : (reconfigured) /build/sebor/gcc-4.1.0/configure --enable-languages=c,c++ --prefix=/usr/local/gcc-4.1.0 --with-gnu-as --with-gnu-ld Thread model: posix gcc version 4.1.0 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30280
[Bug target/30272] Build failure under SGI Irix (GFortran)
-- dfranke at gcc dot gnu dot org changed: What|Removed |Added Component|bootstrap |target GCC build triplet||mips-sgi-irix6.5 GCC host triplet||mips-sgi-irix6.5 GCC target triplet||mips-sgi-irix6.5 Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30272
[Bug libgomp/28209] None of the GOMP_* environment variables are documented
--- Comment #2 from dfranke at gcc dot gnu dot org 2006-12-22 22:49 --- Documented in trunk. Backport to 4.2 will follow soon. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28209
[Bug libstdc++/30280] SIGSEGV on operator==(valarray, bool)
--- Comment #6 from pcarlini at suse dot de 2006-12-22 23:01 --- Yes, the "crazy" thing is that apparently the snippet *compiles* only on sparc-solaris (and shouldn't, of course). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30280
[Bug preprocessor/30001] out-of-bounds access when processing empty file
--- Comment #3 from patchapp at dberlin dot org 2006-12-23 03:00 --- Subject: Bug number PR preprocessor/30001 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2006-12/msg01602.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30001
