[Bug target/27681] [4.1 regression] Missing DImode float conversion functions with -msoft-float
--- Comment #5 from richard at codesourcery dot com 2006-07-24 06:03 --- Subject: Re: [4.1 regression] Missing DImode float conversion functions with -msoft-float "echristo at apple dot com" <[EMAIL PROTECTED]> writes: > I doubt we're going to backport that patch to 4.1 at all, should we > just close this bug? I hope we're going to backport it ;) It's on my to-do list. Richard -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27681
[Bug driver/28437] [4.1/4.2 Regression] multiple fno-builtin-* flags broken
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |blocker http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28437
[Bug driver/28437] [4.1/4.2 Regression] multiple fno-builtin-* flags broken
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-07-24 05:55 --- I bet a beer or two it was caused by: 2006-05-16 H.J. Lu <[EMAIL PROTECTED]> PR driver/26885 -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||hjl at gcc dot gnu dot org Component|c |driver http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28437
[Bug other/25035] [4.1/4.2 regression] libssp causes a failure with cross compilers
--- Comment #12 from pinskia at gcc dot gnu dot org 2006-07-24 05:53 --- It works, just the problem is that library's configure is incorrect, there have been threads about this issue which I cannot find right now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25035
[Bug middle-end/23868] [4.1/4.2 regression] builtin_apply uses wrong mode for multi-hard-register return values
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-07-24 05:51 --- (In reply to comment #8) > Is this a problem with mainline? It has 4.2 regression marked on it. Why do you think otherwise, the commits were all to a developmental branch and the patch is up on the patch queue so why are you asking about the status of this bug when it is obviously still there. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23868
[Bug other/25035] [4.1/4.2 regression] libssp causes a failure with cross compilers
--- Comment #11 from echristo at apple dot com 2006-07-24 05:51 --- Is libssp even assumed to be OK for non-native targets? I think that it should probably be turned off by default on the embedded targets and just left that way. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25035
[Bug c/28437] [4.1/4.2 Regression] multiple fno-builtin-* flags broken
--- Comment #2 from steven at gcc dot gnu dot org 2006-07-24 05:46 --- gcc -v shows that only the last -fno-builtin-* is passed to cc1: $ /xgcc -B. -fno-builtin-iswalpha -fno-builtin-iswalnum -c b.c -v Reading specs from ./specs Target: x86_64-unknown-linux-gnu Configured with: ../trunk/configure --enable-languages=c,c++,objc,fortran Thread model: posix gcc version 4.2.0 20060723 (experimental) ./cc1 -quiet -v -iprefix /home/steven/devel/build-trunk-test/gcc/../lib/gcc/x86_64-unknown-linux-gnu/4.2.0/ -isystem ./include t.c -quiet -dumpbase t.c -mtune=generic -auxbase t -version -fno-builtin-iswalnum -o /tmp/cc6JyivL.s (etc.) Likewise for cc1plus. -- 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 |2006-07-24 05:46:26 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28437
[Bug middle-end/23868] [4.1/4.2 regression] builtin_apply uses wrong mode for multi-hard-register return values
--- Comment #8 from echristo at apple dot com 2006-07-24 05:45 --- Is this a problem with mainline? It has 4.2 regression marked on it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23868
[Bug target/27543] [4.2 Regression] attribute ms_struct is now also for rs6000 but not documented
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-07-24 05:32 --- (In reply to comment #2) > Removing regression. It is a QOI regression. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Summary|attribute ms_struct is now |[4.2 Regression] attribute |also for rs6000 but not |ms_struct is now also for |documented |rs6000 but not documented http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27543
[Bug target/27544] [4.0/4.1/4.2 Regression] attribute altivec is not documented
--- Comment #3 from steven at gcc dot gnu dot org 2006-07-24 05:29 --- Yup. New feature lacking documentation. We've always treated those as documentation quality regressions. So confirmed. -- 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 |2006-07-24 05:29:26 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27544
[Bug target/27544] [4.0/4.1/4.2 Regression] attribute altivec is not documented
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-07-24 05:20 --- (In reply to comment #1) > This can't possibly be a regression. Why? It is a user visible regression as now preprocessed sources include the altivec attribute while before it used vector_size. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27544
[Bug target/27544] [4.0/4.1/4.2 Regression] attribute altivec is not documented
--- Comment #1 from echristo at apple dot com 2006-07-24 05:07 --- This can't possibly be a regression. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27544
[Bug target/26792] [4.2 Regression] C++ is broken on *-*-darwin*
--- Comment #14 from echristo at apple dot com 2006-07-24 04:54 --- The bug says c++, feel like opening another one or fixing the title on the bug you opened? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26792
[Bug target/27303] crash at unalign access
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-07-24 04:46 --- Invalid as mentioned by Eric because we don't have a testcase. -- 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=27303
[Bug target/27303] crash at unalign access
--- Comment #9 from echristo at apple dot com 2006-07-24 03:22 --- No testcase after 3 mos. No need to keep this open. -- echristo at apple dot com changed: What|Removed |Added CC||echristo at apple dot com Status|WAITING |UNCONFIRMED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27303
[Bug target/27681] [4.1 regression] Missing DImode float conversion functions with -msoft-float
--- Comment #4 from echristo at apple dot com 2006-07-24 03:20 --- I doubt we're going to backport that patch to 4.1 at all, should we just close this bug? -- echristo at apple dot com changed: What|Removed |Added CC||echristo at apple dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27681
[Bug debug/27473] [4.0/4.1/4.2 Regression] g++.dg/other/unused1.C and gcc.dg/20060410.c fail on powerpc-darwin
--- Comment #3 from drow at gcc dot gnu dot org 2006-07-24 03:00 --- Subject: Bug 27473 Author: drow Date: Mon Jul 24 02:59:36 2006 New Revision: 115704 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115704 Log: PR debug/27473 * dbxout.c (output_used_types_helper, output_used_types): New. (dbxout_symbol): Call output_used_types. Modified: trunk/gcc/ChangeLog trunk/gcc/dbxout.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27473
[Bug c++/28460] [4.0/4.1/4.2 Regression] g++ emits bogus namespace DIE
--- Comment #14 from drow at gcc dot gnu dot org 2006-07-24 02:58 --- Subject: Bug 28460 Author: drow Date: Mon Jul 24 02:58:08 2006 New Revision: 115703 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115703 Log: PR c++/28460 * decl.c (grokvardecl): Use FROB_CONTEXT. * pt.c (register_specialization): Likewise. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/cp/pt.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28460
[Bug gcov/profile/28441] Need atomic increment of gcov counters for MP programs
--- Comment #6 from gnb at sgi dot com 2006-07-24 02:23 ---
Ian Lance Taylor says:
> Please send e-mail to [EMAIL PROTECTED] first. When that process is
> complete, send the patch to [EMAIL PROTECTED]
Thanks, that was the guidance I needed ;-) The process is underway.
Seongbae Park says:
> It seems that you didn't change libgcov.c,
> which suggests that you didn't address __gcov_{pow2,interval}_profiler.
That's correct, I haven't addressed those, for the simple
reason that I don't use them and so hadn't noticed an issue.
> so it would be very nice if you can fix that as well
> (this is just a suggestion).
I'm willing to try ;-) but no promises.
> I think there are three choices:
>
> #1 make above profiler routines to use atomic increment *always*
I decided not to do this for the -fprofile-arcs case because:
a. Atomic increment is a new feature of gcc and so I assume it's not
available on all platforms, even all those whose ISA supports it.
b. Even when available, atomic increment may incur additional overhead
which isn't necessary in a single-threaded context, e.g. the mf
(memory fence) instruction on ia64.
I expect the same arguments apply to -fprofile-values.
> #2 introduce a new environment variable to pick atomic/non-atomic increment
The -fprofile-arcs instrumentation would be hard to make behave this
way without incurring additional runtime overhead, so I think this
approach would just provide an opportunity for the two options to
behave inconsistently.
> #3 make atomic increment version of those routines and
> -fprofile-multithread to generate codes to call them.
>
> I prefer #3, [...]
Agreed.
> Another comment is about the name of -fprofile-multithread.
> There's an alternative MT-safe profiling scheme of making counters TLS.
Yes, actually that was my first approach. However I couldn't figure
out a way to make it work in the kernel context (need to gather coverage
for dynamically loaded kernel modules), safe (need to aggregate counters
from multiple threads/cpus atomically while the code may be running),
and efficient (avoid one or two indirections). It would clearly be a
better approach if it could be made to work, because it avoid the problem
of bouncing counter cachelines in large multiprocessor machines such as
SGI makes. Using the atomic increment builtins is a lesser but easier
solution.
> So I'd prefer if the option for atomic increment is more explicit,
> something like -fprofile-atomic-increment.
Fair enough, I'll make that change.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28441
[Bug c++/28460] [4.0/4.1/4.2 Regression] g++ emits bogus namespace DIE
--- Comment #13 from gdr at integrable-solutions dot net 2006-07-24 01:34 --- Subject: Re: [4.0/4.1/4.2 Regression] g++ emits bogus namespace DIE "drow at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes: | Subject: Re: [4.0/4.1/4.2 Regression] g++ emits bogus namespace DIE | | On Sun, Jul 23, 2006 at 11:47:32PM -, gdr at integrable-solutions dot net | wrote: | > I agree that is the correct representation. Can we agree to have it | > for GCC-4.3 or higher? | | Judging from this one PR, and the tangled bits of the middle end that I | could not untangle to sort out how to skip the global namespace, I | think this will be a lot of work. Thanks for the feedback; that is much appreciated. So, I suspect we would have to live with this for quite some time. Not a big deal though, compared to other issues. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28460
[Bug fortran/28465] [gomp] Statically linked OpenMP Fortran programs cause segment fault
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-07-24 01:03 --- This is a bug in glibc I think, can you get a backtrace? Also what version of glibc are you using? Also static linking is on its way out for glibc in general which is why I would not doubt this is a bug in glibc. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28465
[Bug fortran/28465] New: [gomp] Statically linked OpenMP Fortran programs cause segment fault
All statically linked OpenMP Fortran programs cause segment fault when executed on i686-pc-linux-gnu platform. -- Summary: [gomp] Statically linked OpenMP Fortran programs cause segment fault Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: canqun at nudt dot edu dot cn 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=28465
[Bug other/22313] [4.2 Regression] profiledbootstrap is broken on the mainline
--- Comment #39 from roger at eyesopen dot com 2006-07-24 00:45 --- My latest analysis and a possible patch/workaround have been posted here: http://gcc.gnu.org/ml/gcc-patches/2006-07/msg01015.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22313
[Bug libfortran/25289] Cannot handle record numbers large than huge(0_4)
--- Comment #7 from jvdelisle at gcc dot gnu dot org 2006-07-24 00:26 --- Subject: Bug 25289 Author: jvdelisle Date: Mon Jul 24 00:26:08 2006 New Revision: 115702 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115702 Log: 2006-07-24 Jerry DeLisle <[EMAIL PROTECTED]> PR fortran/25289 * gfortran.dg/direct_io_6.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/direct_io_6.f90 Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25289
[Bug libfortran/25289] Cannot handle record numbers large than huge(0_4)
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2006-07-24 00:19 --- Subject: Bug 25289 Author: jvdelisle Date: Mon Jul 24 00:19:45 2006 New Revision: 115700 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115700 Log: 2006-07-23 Jerry DeLisle <[EMAIL PROTECTED]> PR fortran/25289 * gfortran.h: Declare gfc_large_io_int_kind. * trans-types.c (gfc_init_kinds): Set gfc_large_io_int_kind to size 8 or 4. * trans-io.c (enum iofield_type): Add large_io_int type. (gfc_build_st_parameter): Same. (gfc_build_io_library_fndecls): Same. * ioparm_def: Use large_io_int to define rec. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/ioparm.def trunk/gcc/fortran/trans-io.c trunk/gcc/fortran/trans-types.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25289
[Bug libfortran/25289] Cannot handle record numbers large than huge(0_4)
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2006-07-24 00:18 --- Subject: Bug 25289 Author: jvdelisle Date: Mon Jul 24 00:17:52 2006 New Revision: 115698 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115698 Log: 2006-07-23 Jerry DeLisle <[EMAIL PROTECTED]> PR libgfortran/25289 * libgfortran.h: Add conditional definition of GFC_LARGE_IO_INT type. * io/io.h (st_parameter_dt): Define rec as type GFC_LARGE_IO_INT. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/io/io.h trunk/libgfortran/libgfortran.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25289
[Bug c++/27369] [4.1/4.2 Regression] tree check ICE when attribute externally_visible used
--- Comment #15 from hubicka at gcc dot gnu dot org 2006-07-24 00:16 --- Subject: Bug 27369 Author: hubicka Date: Mon Jul 24 00:16:16 2006 New Revision: 115693 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115693 Log: PR c/25795 PR c++/27369 * cgraph.c (cgraph_varpool_nodes): Export. (decide_is_variable_needed): Ignored "used" attribute in unit-at-a-time mode. * cgraph.h (cgraph_varpool_nodes): Declare. * cgraphunit.c (decide_is_function_needed): Ignored "used" attribute in unit-at-a-time mode. * gcc.dg/pr25795.c: New test. * gcc.dg/pr25795-1.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr25795-1.c trunk/gcc/testsuite/gcc.dg/pr25795.c Modified: trunk/gcc/ChangeLog trunk/gcc/c-common.c trunk/gcc/c-decl.c trunk/gcc/cgraph.c trunk/gcc/cgraph.h trunk/gcc/cgraphunit.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27369
[Bug c/25795] Proccessing the attribute externally_visible too early
--- Comment #2 from hubicka at gcc dot gnu dot org 2006-07-24 00:16 --- Subject: Bug 25795 Author: hubicka Date: Mon Jul 24 00:16:16 2006 New Revision: 115693 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115693 Log: PR c/25795 PR c++/27369 * cgraph.c (cgraph_varpool_nodes): Export. (decide_is_variable_needed): Ignored "used" attribute in unit-at-a-time mode. * cgraph.h (cgraph_varpool_nodes): Declare. * cgraphunit.c (decide_is_function_needed): Ignored "used" attribute in unit-at-a-time mode. * gcc.dg/pr25795.c: New test. * gcc.dg/pr25795-1.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr25795-1.c trunk/gcc/testsuite/gcc.dg/pr25795.c Modified: trunk/gcc/ChangeLog trunk/gcc/c-common.c trunk/gcc/c-decl.c trunk/gcc/cgraph.c trunk/gcc/cgraph.h trunk/gcc/cgraphunit.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25795
[Bug c++/28460] [4.0/4.1/4.2 Regression] g++ emits bogus namespace DIE
--- Comment #12 from drow at gcc dot gnu dot org 2006-07-24 00:11 --- Subject: Re: [4.0/4.1/4.2 Regression] g++ emits bogus namespace DIE On Sun, Jul 23, 2006 at 11:47:32PM -, gdr at integrable-solutions dot net wrote: > I agree that is the correct representation. Can we agree to have it > for GCC-4.3 or higher? Judging from this one PR, and the tangled bits of the middle end that I could not untangle to sort out how to skip the global namespace, I think this will be a lot of work. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28460
[Bug c++/28460] [4.0/4.1/4.2 Regression] g++ emits bogus namespace DIE
--- Comment #11 from mark at codesourcery dot com 2006-07-24 00:05 ---
Subject: Re: [4.0/4.1/4.2 Regression] g++ emits bogus namespace
DIE
gdr at integrable-solutions dot net wrote:
> --- Comment #10 from gdr at integrable-solutions dot net 2006-07-23
> 23:47 ---
> Subject: Re: [4.0/4.1/4.2 Regression] g++ emits bogus namespace DIE
>
> "mark at codesourcery dot com" <[EMAIL PROTECTED]> writes:
>
> [...]
>
> | (IMO, the ideal representation would have global_namespace for
> | DECL_CONTEXT -- but that's not a change we can make without affecting
> | the middle end, as you've noticed, so I think having
> | {SET_,}CP_DECL_CONTEXT to insulate us would be a nice improvement.
>
> I agree that is the correct representation. Can we agree to have it
> for GCC-4.3 or higher?
Not necessarily. It depends on the middle-end impact. This is just a
cleanup; the current representation is certainly adequate to represent
C++, despite having a special case.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28460
[Bug rtl-optimization/28071] [4.1/4.2 regression] A file that can not be compiled in reasonable time/space
--- Comment #18 from patchapp at dberlin dot org 2006-07-24 00:05 --- Subject: Bug number PR28071 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-07/msg01011.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28071
[Bug c++/28464] template inheritance loses base class scope
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-07-23 23:59 --- The Error is correct. See http://gcc.gnu.org/gcc-3.4/changes.html . -- 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=28464
[Bug c++/28351] SIGSEGV rethrowing an exception with -m64 -static on ppc/linux
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-07-23 23:56 --- *** Bug 28456 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28351
[Bug libgomp/28456] [gomp] Segmentation fault with statically linked binaries
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-07-23 23:56 --- No, it is still the same bug in glibc even though it is a different target and 32bit vs 64bit. *** This bug has been marked as a duplicate of 28351 *** -- 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=28456
[Bug c++/28460] [4.0/4.1/4.2 Regression] g++ emits bogus namespace DIE
--- Comment #10 from gdr at integrable-solutions dot net 2006-07-23 23:47
---
Subject: Re: [4.0/4.1/4.2 Regression] g++ emits bogus namespace DIE
"mark at codesourcery dot com" <[EMAIL PROTECTED]> writes:
[...]
| (IMO, the ideal representation would have global_namespace for
| DECL_CONTEXT -- but that's not a change we can make without affecting
| the middle end, as you've noticed, so I think having
| {SET_,}CP_DECL_CONTEXT to insulate us would be a nice improvement.
I agree that is the correct representation. Can we agree to have it
for GCC-4.3 or higher?
-- Gaby
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28460
[Bug c++/28460] [4.0/4.1/4.2 Regression] g++ emits bogus namespace DIE
--- Comment #9 from gdr at integrable-solutions dot net 2006-07-23 23:45 --- Subject: Re: [4.0/4.1/4.2 Regression] g++ emits bogus namespace DIE "drow at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes: | Subject: Re: [4.0/4.1/4.2 Regression] g++ emits bogus namespace DIE | | On Sun, Jul 23, 2006 at 06:03:46PM -, gdr at integrable-solutions dot net | wrote: | > I believe the situation has been that clear for DECLs for a long time | > now. | | Hi Gaby, | | Is there supposed to be a "not" in that sentence somewhere? Yes, "obviously". I meant "has NOT been". Sorry for the confusion. I should not hold a baby and answer bugzilla PRs stuff at the same time. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28460
[Bug libfortran/28452] __gfortran_random_r10 not found
--- Comment #4 from kargl at gcc dot gnu dot org 2006-07-23 23:32 --- Thomas, Don't you need a HAVE_GFC_REAL_16 section or is random_r10 used for random_r16? Also, I noticed that you've eliminated the normalize_* calls. I think may actually be able to remove these functions and the file that contains them. -- kargl at gcc dot gnu dot org changed: What|Removed |Added CC||kargl at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28452
[Bug target/27907] [4.2 regression] ICE in expand_simple_unop, at optabs.c:2307
-- rakdver at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rakdver at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|-00-00 00:00:00 |2006-07-23 22:14:31 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27907
[Bug c++/28025] [4.1/4.2 Regression] multiple template friend compile error
--- Comment #5 from mmitchel at gcc dot gnu dot org 2006-07-23 22:02 --- Fixed in 4.1.2. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28025
[Bug c++/28464] New: template inheritance loses base class scope
#include
template
struct Base {
Base() {
//this unqualified call works fine within the base class
voidFunc();
}
void voidFunc() {
printf("voidFunc()!\n");
}
//a public variable
TYPE m_publicVar;
};
template
struct Child : public Base {
Child() {
//calling fully qualified works fine
Base::voidFunc();
//this spits out
//"error: there are no arguments to `voidFunc' that depend on a
template parameter, so a declaration of `voidFunc' must be available
//(if you use `-fpermissive', G++ will accept your
code, but allowing the use of an undeclared name is deprecated)"
//and will compile and link with -fpermissive
voidFunc();
if (m_publicVar) { //this var access will not compile regardles
of -fpermissive
printf("m_publicVar!\n");
}
}
};
int main(int argc, const char* argv) {
Child child;
return 0;
}
--
Summary: template inheritance loses base class scope
Product: gcc
Version: 3.4.6
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tim at deadlyninja dot com
GCC host triplet: i686-pc-linux-gnu-3.4.6
GCC target triplet: i686-pc-linux-gnu-3.4.6
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28464
[Bug libfortran/28452] __gfortran_random_r10 not found
--- Comment #3 from tkoenig at gcc dot gnu dot org 2006-07-23 21:14 --- Created an attachment (id=11926) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11926&action=view) patch This implements random for KIND=10 and KIND=16 REALs. It is regression-tested on i686-pc-linux-gnu, but not on a system with KIND=16 REALs. It also speeds up the random numbers for the real case: $ gfortran random-single.f90 $ ./a.out && time ./a.out real0m0.300s user0m0.266s sys 0m0.034s (same program as before). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28452
[Bug libgomp/28456] [gomp] Segmentation fault with statically linked binaries
--- Comment #4 from anlauf at gmx dot de 2006-07-23 21:06 --- (In reply to comment #3) > Because less people test glibc staticly. Anyways this is a glibc bug which > has > since been fixed and it is the same problem as mentioned in PR 28351 so > closing > as a dup of that bug. Negative. I cannot reproduce the bug PR 28351 on the machines I have access to which are i386 (32 bit). I don't believe it is the same bug. -- anlauf at gmx dot de changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|DUPLICATE | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28456
[Bug c++/28025] [4.1/4.2 Regression] multiple template friend compile error
--- Comment #4 from mmitchel at gcc dot gnu dot org 2006-07-23 20:32 --- Subject: Bug 28025 Author: mmitchel Date: Sun Jul 23 20:32:28 2006 New Revision: 115688 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115688 Log: PR c++/28025 * cp-tree.h (LOOKUP_HIDDEN): New macro. Reformat comments. * name-lookup.c (unqualified_namespace_lookup): There is no way to have a hidden name in non-namespace scopes. * pt.c (tsubst_friend_class): Look for hidden names. * decl.c (lookup_and_check_tag): Fix typo in comment. * semantics.c (finish_compound_literal): Fix typo in comment. PR c++/28025 * g++.dg/template/friend45.C: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/g++.dg/template/friend45.C Modified: branches/gcc-4_1-branch/gcc/cp/ChangeLog branches/gcc-4_1-branch/gcc/cp/cp-tree.h branches/gcc-4_1-branch/gcc/cp/decl.c branches/gcc-4_1-branch/gcc/cp/name-lookup.c branches/gcc-4_1-branch/gcc/cp/pt.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28025
[Bug bootstrap/17383] [4.0 Regression] Building in src dir fails
--- Comment #28 from echristo at apple dot com 2006-07-23 20:30 --- We're not going to support building 4.0 in the source directory. Closing. -- echristo at apple dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17383
[Bug c++/28025] [4.1/4.2 Regression] multiple template friend compile error
--- Comment #3 from mmitchel at gcc dot gnu dot org 2006-07-23 20:28 --- Subject: Bug 28025 Author: mmitchel Date: Sun Jul 23 20:28:26 2006 New Revision: 115687 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115687 Log: PR c++/28025 * cp-tree.h (LOOKUP_HIDDEN): New macro. Reformat comments. * name-lookup.c (unqualified_namespace_lookup): There is no way to have a hidden name in non-namespace scopes. * pt.c (tsubst_friend_class): Look for hidden names. * decl.c (lookup_and_check_tag): Fix typo in comment. * semantics.c (finish_compound_literal): Fix typo in comment. PR c++/28025 * g++.dg/template/friend45.C: New test. Added: trunk/gcc/testsuite/g++.dg/template/friend45.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-tree.h trunk/gcc/cp/decl.c trunk/gcc/cp/name-lookup.c trunk/gcc/cp/pt.c trunk/gcc/cp/semantics.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28025
[Bug target/27543] attribute ms_struct is now also for rs6000 but not documented
--- Comment #3 from echristo at apple dot com 2006-07-23 20:28 --- Patch submitted. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27543
[Bug c++/28460] [4.0/4.1/4.2 Regression] g++ emits bogus namespace DIE
--- Comment #8 from mark at codesourcery dot com 2006-07-23 20:17 ---
Subject: Re: [4.0/4.1/4.2 Regression] g++ emits bogus namespace
DIE
drow at gcc dot gnu dot org wrote:
> It did so by introducing FROB_CONTEXT. Right now, FROB_CONTEXT is used at a
> number of places which set DECL_CONTEXT, but not at a number of others (13
> with, 55 without). Some of those without obviously don't need it. Others are
> less clear. But after going through them all, I think only two need it. The
> obvious patch works for my testcase. I will regression test it more
> thoroughly.
It sounds to me like the best thing might be to have:
#define SET_CP_DECL_CONTEXT(NODE, CONTEXT) \
(DECL_CONTEXT (NODE) = FROB_CONTEXT (NODE, CONTEXT))
and use that everywhere. I'd rather not be clever about where we might
have to use it and where we might not.
(IMO, the ideal representation would have global_namespace for
DECL_CONTEXT -- but that's not a change we can make without affecting
the middle end, as you've noticed, so I think having
{SET_,}CP_DECL_CONTEXT to insulate us would be a nice improvement.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28460
[Bug target/28247] [4.1/4.2 regression] libstdc++ cannot be build with Solaris threads
--- Comment #4 from sayle at gcc dot gnu dot org 2006-07-23 20:14 --- Subject: Bug 28247 Author: sayle Date: Sun Jul 23 20:14:44 2006 New Revision: 115686 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115686 Log: PR target/28247 * gthr-solaris.h: Prototype __gthrw forms of thr_self, mutex_init and mutex_destroy even when !_LIBOOBJC. Remove duplicate prototype of the __gthrw form of thr_keycreate. (__gthread_key_delete): Silence the unused argument warning. Modified: trunk/gcc/ChangeLog trunk/gcc/gthr-solaris.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28247
[Bug c++/28460] [4.0/4.1/4.2 Regression] g++ emits bogus namespace DIE
--- Comment #7 from drow at gcc dot gnu dot org 2006-07-23 19:55 --- grokvardecl uses a NULL scope to indicate the current scope, and current_scope never returns NULL. It used to, before revision 89627, but then grokvardecl explicitly tried current_namespace. This patch instituted the NULL context for globals, presumably: 1998-06-24 Martin v. Löwis <[EMAIL PROTECTED]> Set DECL_CONTEXT for globals to NULL_TREE instead of global_namespace. It did so by introducing FROB_CONTEXT. Right now, FROB_CONTEXT is used at a number of places which set DECL_CONTEXT, but not at a number of others (13 with, 55 without). Some of those without obviously don't need it. Others are less clear. But after going through them all, I think only two need it. The obvious patch works for my testcase. I will regression test it more thoroughly. -- drow at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |drow at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28460
[Bug middle-end/27770] [4.2 Regression] wrong code in spec tests for -ftree-vectorize -maltivec
--- Comment #19 from dorit at il dot ibm dot com 2006-07-23 19:03 --- > The fix we've agreed is best in principle is to speculatively increase > the DECL_ALIGN of vectorisable variables before compiling functions. > Dorit says that there is a patch related to this on the autovect branch, > which I'll look at when I get back from Ottawa. > Richard Turns out the patch I was thinking about is only for the rs6000 port: http://gcc.gnu.org/ml/gcc-patches/2006-05/msg00266.html so that's not much help. Do we want to implement this as a separate pass? at which point of the compilation? (doing it during ipa might be a problem if ipa is not enabled?) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27770
[Bug c++/28460] [4.0/4.1/4.2 Regression] g++ emits bogus namespace DIE
--- Comment #6 from drow at gcc dot gnu dot org 2006-07-23 18:48 --- Subject: Re: [4.0/4.1/4.2 Regression] g++ emits bogus namespace DIE On Sun, Jul 23, 2006 at 06:03:46PM -, gdr at integrable-solutions dot net wrote: > I believe the situation has been that clear for DECLs for a long time > now. Hi Gaby, Is there supposed to be a "not" in that sentence somewhere? If not, I don't understand what you mean. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28460
[Bug libgomp/25938] [4.2 regression] libgomp installs header files in version and target independent location
--- Comment #9 from steven at gcc dot gnu dot org 2006-07-23 18:05 --- Jakub, ping. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25938
[Bug c++/28460] [4.0/4.1/4.2 Regression] g++ emits bogus namespace DIE
--- Comment #5 from gdr at integrable-solutions dot net 2006-07-23 18:03 --- Subject: Re: [4.0/4.1/4.2 Regression] g++ emits bogus namespace DIE "mark at codesourcery dot com" <[EMAIL PROTECTED]> writes: | drow at gcc dot gnu dot org wrote: | > --- Comment #3 from drow at gcc dot gnu dot org 2006-07-23 16:44 --- | > Subject: Re: [4.0/4.1/4.2 Regression] g++ emits bogus namespace DIE | > | > On Sun, Jul 23, 2006 at 03:59:58PM -, mark at codesourcery dot com wrote: | >> If we're setting TYPE_CONTEXT to global_namespace, I think that's a C++ | >> front end bug. Which type is getting set up like that? | > | > I was wrong; TYPE_CONTEXT looks OK. How about for DECLs? | | The same rule applies; DECL_CONTEXT should also be NULL_TREE for an | entity in the global namespace. I believe the situation has been that clear for DECLs for a long time now. -- Gaby akcc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28460
[Bug debug/25468] [4.0/4.1 Regression] -g makes g++ loop forever
--- Comment #10 from steven at gcc dot gnu dot org 2006-07-23 17:57 --- Fixed on the trunk. -- steven at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.0/4.1/4.2 Regression] -g |[4.0/4.1 Regression] -g |makes g++ loop forever |makes g++ loop forever http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25468
[Bug debug/25468] [4.0/4.1/4.2 Regression] -g makes g++ loop forever
--- Comment #9 from steven at gcc dot gnu dot org 2006-07-23 17:56 --- Subject: Bug 25468 Author: steven Date: Sun Jul 23 17:56:34 2006 New Revision: 115685 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115685 Log: 2006-07-23 Steven Bosscher <[EMAIL PROTECTED]> PR debug/25468 * config/elfos.h (ASM_OUTPUT_ASCII): Remove 'register' marks. Cache the last found '\0' marker to avoid quadratic behavior. Modified: trunk/gcc/ChangeLog trunk/gcc/config/elfos.h trunk/gcc/fortran/ChangeLog trunk/gcc/testsuite/gfortran.fortran-torture/execute/der_init_4.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25468
[Bug c++/26965] [4.0/4.1/4.2 Regression] Unnecessary debug info for unused consts in C++
--- Comment #10 from ian at airs dot com 2006-07-23 17:35 --- I believe that patch is responsible because this behaviour does not happen in gcc 4.0.1, and it does happen in gcc 4.0.2, and that was the obvious change. I admit that I haven't actually tried reverting that specific patch to see what happens. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26965
[Bug gcov/profile/28441] Need atomic increment of gcov counters for MP programs
--- Comment #5 from seongbae dot park at gmail dot com 2006-07-23 17:27
---
It seems that you didn't change libgcov.c,
which suggests that you didn't address __gcov_{pow2,interval}_profiler.
Without such change, -fprofile-generate will cause the mismatch between
the value counters and edge counters,
so it would be very nice if you can fix that as well
(this is just a suggestion).
In case someone wants to address that issue,
I think there are three choices:
#1 make above profiler routines to use atomic increment *always*
#2 introduce a new environment variable to pick atomic/non-atomic increment
#3 make atomic increment version of those routines and -fprofile-multithread to
generate codes to call them.
I prefer #3, but #1 might be simple enough without much bad affect.
Another comment is about the name of -fprofile-multithread.
There's an alternative MT-safe profiling scheme of making counters TLS.
So I'd prefer if the option for atomic increment is more explicit,
something like -fprofile-atomic-increment.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28441
[Bug libfortran/28452] __gfortran_random_r10 not found
--- Comment #2 from tkoenig at gcc dot gnu dot org 2006-07-23 17:23 --- While I work on this, I might as well tackle some other issues. Before I start work, some timings with a vanilla tree as of today. The timing isn't terrible (within a factor of two with Intel 8.1), but of course, I don't know Intel's quality of RNG. $ cat random-single.f90 program main real, dimension(10**7) :: a call random_number(a) end program main $ gfortran random-single.f90 $ ./a.out && time ./a.out real0m0.765s user0m0.730s sys 0m0.036s $ ifort random-single.f90 $ ./a.out && time ./a.out real0m0.362s user0m0.313s sys 0m0.049s $ cat random-double.f90 program main real(kind=8), dimension(10**7) :: a call random_number(a) end program main $ gfortran random-double.f90 $ ./a.out && time ./a.out real0m0.886s user0m0.804s sys 0m0.077s $ ifort random-double.f90 $ ./a.out && time ./a.out real0m0.402s user0m0.328s sys 0m0.074s -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |tkoenig at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28452
[Bug libfortran/28452] __gfortran_random_r10 not found
--- Comment #1 from tkoenig at gcc dot gnu dot org 2006-07-23 17:14 --- I'll take a look at this. See http://gcc.gnu.org/ml/fortran/2006-07/msg00311.html and follow-ups for the discussion of this bug. -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added CC||tkoenig at gcc dot gnu dot ||org Keywords||wrong-code Known to fail||4.2.0 4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28452
[Bug debug/28460] [4.0/4.1/4.2 Regression] g++ emits bogus namespace DIE
--- Comment #4 from mark at codesourcery dot com 2006-07-23 16:48 ---
Subject: Re: [4.0/4.1/4.2 Regression] g++ emits bogus namespace
DIE
drow at gcc dot gnu dot org wrote:
> --- Comment #3 from drow at gcc dot gnu dot org 2006-07-23 16:44 ---
> Subject: Re: [4.0/4.1/4.2 Regression] g++ emits bogus namespace DIE
>
> On Sun, Jul 23, 2006 at 03:59:58PM -, mark at codesourcery dot com wrote:
>> If we're setting TYPE_CONTEXT to global_namespace, I think that's a C++
>> front end bug. Which type is getting set up like that?
>
> I was wrong; TYPE_CONTEXT looks OK. How about for DECLs?
The same rule applies; DECL_CONTEXT should also be NULL_TREE for an
entity in the global namespace.
> (gdb) call debug_tree (decl.decl_minimal.context)
> line 0
> align 1
>>
>
> So, the variable is in the global namespace explicitly.
Ugh. I'm not surprised that this works (in the C++ front end) since we
have logic that basically equates NULL_TREE with global_namespace, for
those situations in which we explicitly need to have a namespace around.
However, the global_namespace should never end up as
{DECL,TYPE}_CONTEXT of anything.
So, I think you should reclassify this as a C++ front end bug. You're
still free to fix it of course. :-)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28460
[Bug debug/28460] [4.0/4.1/4.2 Regression] g++ emits bogus namespace DIE
--- Comment #3 from drow at gcc dot gnu dot org 2006-07-23 16:44 ---
Subject: Re: [4.0/4.1/4.2 Regression] g++ emits bogus namespace DIE
On Sun, Jul 23, 2006 at 03:59:58PM -, mark at codesourcery dot com wrote:
> If we're setting TYPE_CONTEXT to global_namespace, I think that's a C++
> front end bug. Which type is getting set up like that?
I was wrong; TYPE_CONTEXT looks OK. How about for DECLs?
Compile "int var;" with cc1plus -g, and set a breakpoint on
gen_namespace_die. Up a couple of frames, you'll see:
#6 0x008599ad in gen_decl_die (decl=0x2b17b370,
context_die=0x2b176ea0)
at /space/fsf/commit/gcc/gcc/dwarf2out.c:13117
13117 declare_in_namespace (decl, context_die);
(gdb) call debug_tree (decl)
unit size
align 32 symtab 0 alias set -1 precision 32 min max
pointer_to_this >
asm_written public static tree_1 SI file /space/fsf/namespace.cc line 1
size unit size
align 32 context
(mem/c/i:SI (symbol_ref:DI ("var") [flags 0x2] ) [0 var+0 S4 A32]) chain >
(gdb) call debug_tree (decl.decl_minimal.context)
line 0
align 1
>
So, the variable is in the global namespace explicitly.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28460
[Bug libfortran/27964] Wrong line ends on windows (XP)
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2006-07-23 16:17 --- I don't think it's a curse, but its spooky. :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27964
[Bug debug/28460] [4.0/4.1/4.2 Regression] g++ emits bogus namespace DIE
--- Comment #2 from mark at codesourcery dot com 2006-07-23 15:59 --- Subject: Re: [4.0/4.1/4.2 Regression] g++ emits bogus namespace DIE drow at gcc dot gnu dot org wrote: > --- Comment #1 from drow at gcc dot gnu dot org 2006-07-23 00:12 --- > Mark, did the old C++ parser have TYPE_CONTEXT == NULL for the global scope > and > the new one have it pointing to the global namespace, or something like that? No, I don't think so. The representation has "always" (i.e., for as long as I can remember) been that the global namespace was represented as NULL_TREE, while other namespaces are represented by NAMESPACE_DECL. (One could argue that's a silly non-uniformity, but that's how it's always been.) > If so, I guess we'll have to strip that out in dwarf2out. We can't compare > against global_namespace, so do you have a recommendation on how to identify > it? If we're setting TYPE_CONTEXT to global_namespace, I think that's a C++ front end bug. Which type is getting set up like that? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28460
[Bug middle-end/28463] [4.0/4.1/4.2 Regression] Using -fdump-tree-optimized causes a huge compile time memory regression
--- Comment #1 from steven at gcc dot gnu dot org 2006-07-23 15:22 --- Yup. And a regression too because previous GCCs could dump without sending your machine to swap space land. -- 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 |2006-07-23 15:22:25 date|| Summary|Using -fdump-tree-optimized |[4.0/4.1/4.2 Regression] |causes a huge compile time |Using -fdump-tree-optimized |memory regression |causes a huge compile time ||memory regression http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28463
[Bug middle-end/28463] New: Using -fdump-tree-optimized causes a huge compile time memory regression
Enabling some tree dumps causes a tramp3d-v4 compile to run into swap,
requiring
about 50% more ram than a non-dumped compile.
Pinskia suggests
Index: gcc/cgraph.c
===
--- gcc/cgraph.c(revision 115684)
+++ gcc/cgraph.c(working copy)
@@ -509,7 +509,7 @@ cgraph_remove_node (struct cgraph_node *
kill_body = true;
}
- if (kill_body && !dump_enabled_p (TDI_tree_all) && flag_unit_at_a_time)
+ if (kill_body && flag_unit_at_a_time)
{
DECL_SAVED_TREE (node->decl) = NULL;
DECL_STRUCT_FUNCTION (node->decl) = NULL;
Index: gcc/cgraphunit.c
===
--- gcc/cgraphunit.c(revision 115684)
+++ gcc/cgraphunit.c(working copy)
@@ -1466,7 +1466,6 @@ cgraph_optimize (void)
/* Double check that all inline clones are gone and that all
function bodies have been released from memory. */
if (flag_unit_at_a_time
- && !dump_enabled_p (TDI_tree_all)
&& !(sorrycount || errorcount))
{
struct cgraph_node *node;
but there may be non-GCable cost of dumping itself.
--
Summary: Using -fdump-tree-optimized causes a huge compile time
memory regression
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Keywords: memory-hog
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28463
[Bug debug/25468] [4.0/4.1/4.2 Regression] -g makes g++ loop forever
--- Comment #8 from steven at gcc dot gnu dot org 2006-07-23 14:54 --- Created an attachment (id=11925) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11925&action=view) proposed fix, nukes quadratic behavior needs detailed testing, but this cuts the time spent in debug info writing to almost nothing. Or, for targets that use the defitition of ASM_OUTPUT_ASCII that is in config/elfos.h, anyway. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25468
[Bug libfortran/27964] Wrong line ends on windows (XP)
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2006-07-23 13:17 --- My XP box died last week (is that a curse?) It's being taken care of, but I won't be able to work on it for some time. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27964
[Bug debug/25468] [4.0/4.1/4.2 Regression] -g makes g++ loop forever
--- Comment #7 from steven at gcc dot gnu dot org 2006-07-23 13:11 --- Happens on at least all the targets that includes elfos.h, cris/aout.h, i386/ptx4-i.h, i386/i386-interix.h, i386/sysv4.h, i386/i386elf.h. I'm only fixing elfos.h, but others can copy over the same idea. -- steven at gcc dot gnu dot org changed: What|Removed |Added GCC host triplet|i686-pc-linux-gnu | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25468
[Bug libgcj/28442] libtool: link: cannot find the library `'
--- Comment #2 from arno at heho dot snv dot jussieu dot fr 2006-07-23 13:05 --- Created an attachment (id=11924) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11924&action=view) test if found dependency lib in fact has a name I use this patch for months to prevent this bug. It works independent of the version of libtool -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28442
[Bug debug/25468] [4.0/4.1/4.2 Regression] -g makes g++ loop forever
--- Comment #6 from steven at gcc dot gnu dot org 2006-07-23 11:51 --- Consider these lines in elfos.h:ASM_OUTPUT_ASCII: \ for (p = _ascii_bytes; p < limit && *p != '\0'; p++) \ continue; \ \ Now take a string of 4+ characters with no '\0' terminator. This will trigger quadratic behavior. We'll go look for a 0 terminator thousands of time and not find it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25468
[Bug c++/27369] [4.1/4.2 Regression] tree check ICE when attribute externally_visible used
--- Comment #14 from patchapp at dberlin dot org 2006-07-23 10:15 --- Subject: Bug number PR c++/27369 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-07/msg00993.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27369
[Bug target/28270] [4.0/4.1/4.2 regression] ICE on invalid inline asm
--- Comment #2 from patchapp at dberlin dot org 2006-07-23 09:35 --- Subject: Bug number PR target/28270 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-07/msg00992.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28270
[Bug debug/28460] [4.0/4.1/4.2 Regression] g++ emits bogus namespace DIE
-- 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 |2006-07-23 09:11:20 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28460
