[Bug rtl-optimization/15023] -frename-registers is slow
--- Comment #15 from ebotcazou at gcc dot gnu dot org 2007-11-03 07:57 --- Paolo, do you know what the status of this PR is? Ian said in comment #14 that the pass should be rewritten to use the DF framework. Has this happened? TIA. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15023
[Bug rtl-optimization/28940] [4.0/4.1/4.2 Regression] address selection does not work correctly
--- Comment #17 from ebotcazou at gcc dot gnu dot org 2007-11-03 07:54 --- Fixed in the upcoming 4.3 series. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28940
[Bug rtl-optimization/28940] [4.0/4.1/4.2 Regression] address selection does not work correctly
--- Comment #16 from ebotcazou at gcc dot gnu dot org 2007-11-03 07:53 --- Subject: Bug 28940 Author: ebotcazou Date: Sat Nov 3 07:53:01 2007 New Revision: 129868 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129868 Log: PR rtl-optimization/28940 * gcc.target/i386/addr-sel-1.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/addr-sel-1.c Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28940
[Bug c++/33871] [4.3 Regression] typeinfo name referenced in ... defined in discarded section
--- Comment #28 from gcc at magfr dot user dot lysator dot liu dot se 2007-11-03 07:47 --- That both files are named S1.C doesn't matter. If one do cp S1.C S2.C g++ -c S1.C g++ -c S2.C g++ S1.o S2.o one get the same behaviour and the same linker error. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33871
[Bug middle-end/33670] [4.3 Regression] cc1 segfault with -O2 -fsched-stalled-insns=0 for twolf
--- Comment #4 from maxim at codesourcery dot com 2007-11-03 07:45 ---
Subject: Re: [4.3 Regression] cc1 segfault with -O2
-fsched-stalled-insns=0 for twolf
jakub at gcc dot gnu dot org wrote:
> --- Comment #3 from jakub at gcc dot gnu dot org 2007-11-02 23:17 ---
> Fixed for ppc64.
>
> I haven't added the requested stop at the start of bb, Maxim, if you want to
> do that, please go ahead.
> Also, I have just found that this testcase fails on ia64 native for a
> different
> reason (wonder why I haven't reproduced that with cross ia64 before).
> On ia64 the problem is that the backend sets DO_SPECULATION in flags
> in ia64_set_sched_flags - mflag_sched_ar_data_spec is 1 by default and
> when user asks for -fsched-stalled-insns=5 (or =0), then
> /* Perform a few consistency checks of flags in different data structures. */
> static void
> check_sched_flags (void)
> {
> unsigned int f = current_sched_info->flags;
>
> if (flag_sched_stalled_insns)
> gcc_assert (!(f & DO_SPECULATION));
> if (f & DO_SPECULATION)
> gcc_assert (!flag_sched_stalled_insns
> && spec_info
> && spec_info->mask);
> }
> fails. It compiles with -O2 -fno-sched-stalled-insns or -O2
> -fsched-stalled-insns=0 -mno-sched-ar-data-spec
> I see no code that would try to do anything to satisfy this assert, should
> ia64 disallow -fsched-stalled-insns by setting flag_sched_stalled_insns = 0?
> Or if it is non-zero don't set DO_SPECULATION? Something else?
I don't really remember why I enforced this check. I believe,
-fsched-stalled-insns doesn't make sense for ia64, but, anyway, if user
wants to do that, compiler should deal with it.
There is no code in ia64 backend that will turn off either of the flags
depending on presence of the other. I think, this check (the whole
function) should be simply removed, given that compiler won't ICE
somewhere else.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33670
[Bug rtl-optimization/31360] [4.2 Regression] RTL loop invariant is not aggressive enough
--- Comment #35 from ebotcazou at gcc dot gnu dot org 2007-11-03 07:28 --- Fixed in the upcoming 4.3 series. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31360
[Bug rtl-optimization/31360] [4.2 Regression] RTL loop invariant is not aggressive enough
--- Comment #34 from ebotcazou at gcc dot gnu dot org 2007-11-03 07:27 --- Reopening... -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|WONTFIX | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31360
[Bug rtl-optimization/31360] [4.2 Regression] RTL loop invariant is not aggressive enough
--- Comment #33 from ebotcazou at gcc dot gnu dot org 2007-11-03 07:24 --- By silent consensus. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31360
[Bug c++/33871] [4.3 Regression] typeinfo name referenced in ... defined in discarded section
--- Comment #27 from geoffk at geoffk dot org 2007-11-03 07:21 --- Subject: Re: [4.3 Regression] typeinfo name referenced in ... defined in discarded section On 30/10/2007, at 9:03 PM, amodra at bigpond dot net dot au wrote: > --- Comment #26 from amodra at bigpond dot net dot au > 2007-10-31 04:03 --- > I believe the linker is correct to reject relocations against local > symbols in > discarded sections. The reason being that the linker allows > linkonce (and > comdat group) section contents to differ between two files, so that > for > example, two files may be compiled with different optimisations yet > still link > correctly. Since the contents may differ, the location of symbols > within the > section may also differ between files. Using the value of > "local_sym + offset" > in one file (in the discarded section) may point to an entirely > wrong location > in the other file (in the kept section). In this case, though, the contents of the linkonce section will never actually differ; and I believe in this case the offset is zero, so even if they did differ it would not matter. Perhaps a zero offset should be special-cased? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33871
[Bug tree-optimization/33707] scev not handling unsigned conversion
--- Comment #2 from spop at gcc dot gnu dot org 2007-11-03 06:38 --- Confirmed, scev does not handle unsigned conversion. -- spop at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-11-03 06:38:34 date|| Summary|missed optimization with|scev not handling unsigned |dependency checker |conversion http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33707
[Bug tree-optimization/33707] missed optimization with dependency checker
--- Comment #1 from sebpop at gmail dot com 2007-11-03 06:31 ---
Subject: Re: New: missed optimization with dependency checker
> int
> foo (char *a, unsigned n)
> {
> int i;
> a[0] = 0;
> for (i = 16; i < n; i++)
> a[i] = a[i-16];
> }
>
We're failing to analyse the base of the array 'a' for this code, as
there is a cast from "signed int" to "unsigned int" for the main iv:
# i.0D.1181_20 = PHI
# iD.1177_19 = PHI
D.1182_7 = aD.1173_2(D) + i.0D.1181_20;
iD.1177_12 = iD.1177_19 + 1;
i.0D.1181_4 = (unsigned intD.3) iD.1177_12;
if (i.0D.1181_4 < nD.1174_5(D))
This is due to the fact that we have to convert 'i' to unsigned before
comparing with 'n'. The exact same testcase with just a signed type
for 'n' is vectorized:
int
foo (char *a, int n)
{
int i;
a[0] = 0;
for (i = 16; i < n; i++)
a[i] = a[i-16];
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33707
[Bug tree-optimization/32540] [4.3 Regression] Exponential time behavior in PRE
--- Comment #15 from sebpop at gmail dot com 2007-11-03 05:54 --- Subject: Re: [4.3 Regression] Exponential time behavior in PRE And I just saw that there is already a patch for this bug attached unfortunately to PR32575. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32540
[Bug tree-optimization/32540] [4.3 Regression] Exponential time behavior in PRE
--- Comment #14 from sebpop at gmail dot com 2007-11-03 05:26 --- Subject: Re: [4.3 Regression] Exponential time behavior in PRE With the patch, compile time goes down also for PR33922. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32540
[Bug tree-optimization/32540] [4.3 Regression] Exponential time behavior in PRE
--- Comment #13 from sebpop at gmail dot com 2007-11-03 05:19 --- Subject: Re: [4.3 Regression] Exponential time behavior in PRE > Yes, the heuristics can sometimes generate a very large number of > copies to eliminate a single redundancy. > This is jsut the way the standard PRE heuristics work. > If you want to try to come up with a better one, you are welcome to :) > What about stopping the computation when we see that there are too many values that are anticipable? Here is a patch that restores the compile time on all the reported testcases. The constant should be a param, and the default value should be higher probably. Index: tree-ssa-pre.c === --- tree-ssa-pre.c (revision 129775) +++ tree-ssa-pre.c (working copy) @@ -1847,6 +1847,13 @@ compute_partial_antic_aux (basic_block b if (block_has_abnormal_pred_edge) goto maybe_dump_sets; + /* If there are too many partially anticipatable values in the + block, phi_translate_set can take an exponential time: stop + before the translation starts. */ + if (single_succ_p (block) + && bitmap_count_bits (PA_IN (single_succ (block))->expressions) > 10) +goto maybe_dump_sets; + old_PA_IN = PA_IN (block); PA_OUT = bitmap_set_new (); -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32540
[Bug tree-optimization/33987] [4.3 regression] internal compiler error: in get_initial_def_for_reduction, at tree-vect-transform.c:2110 with -O3 -msse2
--- Comment #2 from dorit at gcc dot gnu dot org 2007-11-03 04:06 --- testing this fix: Index: tree-vect-transform.c === *** tree-vect-transform.c (revision 129763) --- tree-vect-transform.c (working copy) *** get_initial_def_for_reduction (tree stmt *** 2107,2113 tree vector_type; bool nested_in_vect_loop = false; ! gcc_assert (INTEGRAL_TYPE_P (type) || SCALAR_FLOAT_TYPE_P (type)); if (nested_in_vect_loop_p (loop, stmt)) nested_in_vect_loop = true; else --- 2107,2113 tree vector_type; bool nested_in_vect_loop = false; ! gcc_assert (POINTER_TYPE_P (type) || INTEGRAL_TYPE_P (type) || SCALAR_FLOAT_TYPE_P (type)); if (nested_in_vect_loop_p (loop, stmt)) nested_in_vect_loop = true; else *** get_initial_def_for_reduction (tree stmt *** 2120,2136 case WIDEN_SUM_EXPR: case DOT_PROD_EXPR: case PLUS_EXPR: ! if (nested_in_vect_loop) ! *adjustment_def = vecdef; ! else ! *adjustment_def = init_val; ! /* Create a vector of zeros for init_def. */ ! if (INTEGRAL_TYPE_P (type)) ! def_for_init = build_int_cst (type, 0); else def_for_init = build_real (type, dconst0); ! for (i = nunits - 1; i >= 0; --i) ! t = tree_cons (NULL_TREE, def_for_init, t); vector_type = get_vectype_for_scalar_type (TREE_TYPE (def_for_init)); gcc_assert (vector_type); init_def = build_vector (vector_type, t); --- 2120,2136 case WIDEN_SUM_EXPR: case DOT_PROD_EXPR: case PLUS_EXPR: ! if (nested_in_vect_loop) ! *adjustment_def = vecdef; else + *adjustment_def = init_val; + /* Create a vector of zeros for init_def. */ + if (SCALAR_FLOAT_TYPE_P (type)) def_for_init = build_real (type, dconst0); ! else ! def_for_init = build_int_cst (type, 0); ! for (i = nunits - 1; i >= 0; --i) ! t = tree_cons (NULL_TREE, def_for_init, t); vector_type = get_vectype_for_scalar_type (TREE_TYPE (def_for_init)); gcc_assert (vector_type); init_def = build_vector (vector_type, t); *** vectorizable_reduction (tree stmt, block *** 2716,2721 --- 2716,2724 return false; scalar_dest = GIMPLE_STMT_OPERAND (stmt, 0); scalar_type = TREE_TYPE (scalar_dest); + if (!POINTER_TYPE_P (scalar_type) && !INTEGRAL_TYPE_P (scalar_type) + && !SCALAR_FLOAT_TYPE_P (scalar_type)) + return false; /* All uses but the last are expected to be defined in the loop. The last use is the reduction variable. */ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33987
[Bug tree-optimization/33987] [4.3 regression] internal compiler error: in get_initial_def_for_reduction, at tree-vect-transform.c:2110 with -O3 -msse2
-- dorit at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-11-03 03:35:30 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33987
[Bug tree-optimization/33987] [4.3 regression] internal compiler error: in get_initial_def_for_reduction, at tree-vect-transform.c:2110 with -O3 -msse2
--- Comment #1 from bero at arklinux dot org 2007-11-03 01:59 --- Created an attachment (id=14477) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14477&action=view) bzip2-ed preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33987
[Bug tree-optimization/33987] New: [4.3 regression] internal compiler error: in get_initial_def_for_reduction, at tree-vect-transform.c:2110 with -O3 -msse2
$ gcc -O3 -msse2 -c concurrentMarkSweepGeneration.ii /usr/src/ark/BUILD/icedtea/openjdk/hotspot/src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp:7235: internal compiler error: in get_initial_def_for_reduction, at tree-vect-transform.c:2110 Please submit a full bug report, with preprocessed source if appropriate. -- Summary: [4.3 regression] internal compiler error: in get_initial_def_for_reduction, at tree-vect- transform.c:2110 with -O3 -msse2 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bero at arklinux dot org GCC build triplet: i586-pc-linux-gnu GCC host triplet: i586-pc-linux-gnu GCC target triplet: i586-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33987
[Bug libfortran/33985] access="stream",form="unformatted" doesn't buffer
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2007-11-03 01:17 --- I have discovered something that may make this easy to fix. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jvdelisle at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2007-11-02 22:43:14 |2007-11-03 01:17:50 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33985
[Bug libfortran/33985] access="stream",form="unformatted" doesn't buffer
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2007-11-03 00:42 --- Created an attachment (id=14476) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14476&action=view) -fdump-tree-original output This is an optimization issue in the front-end. We have to be smart enough to lift the st_write_done out of the loop. A different example of this is PR32382. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33985
[Bug fortran/33698] FAIL: gfortran.dg/gamma_5.f90
--- Comment #12 from dave at hiauly1 dot hia dot nrc dot ca 2007-11-02 23:45 --- Subject: Re: FAIL: gfortran.dg/gamma_5.f90 > Can anybody test this? John? I'm on it. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33698
[Bug middle-end/33670] [4.3 Regression] cc1 segfault with -O2 -fsched-stalled-insns=0 for twolf
--- Comment #3 from jakub at gcc dot gnu dot org 2007-11-02 23:17 ---
Fixed for ppc64.
I haven't added the requested stop at the start of bb, Maxim, if you want to
do that, please go ahead.
Also, I have just found that this testcase fails on ia64 native for a different
reason (wonder why I haven't reproduced that with cross ia64 before).
On ia64 the problem is that the backend sets DO_SPECULATION in flags
in ia64_set_sched_flags - mflag_sched_ar_data_spec is 1 by default and
when user asks for -fsched-stalled-insns=5 (or =0), then
/* Perform a few consistency checks of flags in different data structures. */
static void
check_sched_flags (void)
{
unsigned int f = current_sched_info->flags;
if (flag_sched_stalled_insns)
gcc_assert (!(f & DO_SPECULATION));
if (f & DO_SPECULATION)
gcc_assert (!flag_sched_stalled_insns
&& spec_info
&& spec_info->mask);
}
fails. It compiles with -O2 -fno-sched-stalled-insns or -O2
-fsched-stalled-insns=0 -mno-sched-ar-data-spec
I see no code that would try to do anything to satisfy this assert, should
ia64 disallow -fsched-stalled-insns by setting flag_sched_stalled_insns = 0?
Or if it is non-zero don't set DO_SPECULATION? Something else?
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
CC||mkuvyrkov at gcc dot gnu dot
||org
AssignedTo|jakub at gcc dot gnu dot org|unassigned at gcc dot gnu
||dot org
Status|ASSIGNED|NEW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33670
[Bug fortran/33698] FAIL: gfortran.dg/gamma_5.f90
--- Comment #11 from tkoenig at gcc dot gnu dot org 2007-11-02 23:07 --- Created an attachment (id=14475) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14475&action=view) proposed patch This implements the fallback functions, but naturally doesn't do anything on my linux system (which has all tgamma* and lgamma* functions). Can anybody test this? John? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33698
[Bug middle-end/33670] [4.3 Regression] cc1 segfault with -O2 -fsched-stalled-insns=0 for twolf
--- Comment #2 from jakub at gcc dot gnu dot org 2007-11-02 23:06 --- Subject: Bug 33670 Author: jakub Date: Fri Nov 2 23:06:36 2007 New Revision: 129863 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129863 Log: PR middle-end/33670 * haifa-sched.c (ok_for_early_queue_removal): Don't walk out of the current sched region. * gcc.dg/pr33670.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr33670.c Modified: trunk/gcc/ChangeLog trunk/gcc/haifa-sched.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33670
[Bug fortran/33986] ICE on allocatable function result
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-11-02 23:06 --- Confirmed on x86_64-linux, with latest mainline. The reduced testcase is: $ cat j.f90 function transform_to_spectral_from() result(spectral) integer, allocatable :: spectral(:) call scram(spectral) end function transform_to_spectral_from $ ./bin/gfortran j.f90 j.f90: In function transform_to_spectral_from: j.f90:1: internal compiler error: in gfc_conv_descriptor_data_get, at fortran/trans-array.c:147 -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org Severity|critical|normal Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC build triplet|i386-apple-darwin8.10.1 | GCC host triplet|i386-apple-darwin8.10.1 | GCC target triplet|i386-apple-darwin8.10.1 | Keywords||ice-on-valid-code Known to fail||4.3.0 Last reconfirmed|-00-00 00:00:00 |2007-11-02 23:06:18 date|| Summary|internal compiler error on |ICE on allocatable function |integer assignment |result http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33986
[Bug libfortran/33985] access="stream",form="unformatted" doesn't buffer
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-11-02 22:43:14 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33985
[Bug fortran/33986] internal compiler error on integer assignment
--- Comment #1 from damian at rouson dot net 2007-11-02 22:35 --- Created an attachment (id=14474) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14474&action=view) The offending procedure is "transform_to_spectral_from()" in chebyshev.f90. The text of the error message follows: chebyshev.f90: In function 'transform_to_spectral_from': chebyshev.f90:1130: internal compiler error: in gfc_conv_descriptor_data_get, at fortran/trans-array.c:147 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. make: *** [chebyshev.o] Error 1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33986
[Bug fortran/33986] New: internal compiler error on integer assignment
An internal compiler results from assigning an integer constant to an integer variable in Fortran on Mac OS X. The problem occurs inside a wrapper for a FFT procedure. I've read the instructions, but I don't see how to attach the code to this submission. -- Summary: internal compiler error on integer assignment Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: critical Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: damian at rouson dot net GCC build triplet: i386-apple-darwin8.10.1 GCC host triplet: i386-apple-darwin8.10.1 GCC target triplet: i386-apple-darwin8.10.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33986
[Bug libfortran/33985] New: access="stream",form="unformatted" doesn't buffer
Reduced test case from http://gcc.gnu.org/ml/fortran/2007-10/msg00412.html $ cat write.f90 program main implicit none integer :: i open(95,form="unformatted",access="stream") do i=0,255 write(95) int(i,kind=1) end do end program main $ gfortran write.f90 $ strace -etrace=write ./a.out write(3, "\0", 1) = 1 write(3, "\1", 1) = 1 write(3, "\2", 1) = 1 write(3, "\3", 1) = 1 write(3, "\4", 1) = 1 write(3, "\5", 1) = 1 write(3, "\6", 1) = 1 write(3, "\7", 1) = 1 write(3, "\10", 1) = 1 write(3, "\t", 1) = 1 write(3, "\n", 1) = 1 write(3, "\v", 1) = 1 write(3, "\f", 1) = 1 write(3, "\r", 1) = 1 write(3, "\16", 1) = 1 write(3, "\17", 1) = 1 write(3, "\20", 1) = 1 write(3, "\21", 1) = 1 write(3, "\22", 1) = 1 write(3, "\23", 1) = 1 write(3, "\24", 1) = 1 write(3, "\25", 1) = 1 write(3, "\26", 1) = 1 write(3, "\27", 1) = 1 write(3, "\30", 1) = 1 write(3, "\31", 1) = 1 write(3, "\32", 1) = 1 write(3, "\33", 1) = 1 write(3, "\34", 1) = 1 ... and so on. -- Summary: access="stream",form="unformatted" doesn't buffer Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tkoenig at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33985
[Bug libffi/31937] libffi doesn't support ppc without FPU
--- Comment #2 from andreast at gcc dot gnu dot org 2007-11-02 22:01 --- Working on support for. -- andreast at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |andreast at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-11-02 22:01:59 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31937
[Bug c++/33516] [4.1/4.2 Regression] Rejects typedef qualified name-lookup
--- Comment #8 from jakub at gcc dot gnu dot org 2007-11-02 21:40 --- Fixed on the trunk so far. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Known to fail|4.0.0 4.1.2 4.2.1 4.3.0 |4.0.0 4.1.2 4.2.1 Known to work|3.4.6 |3.4.6 4.3.0 Summary|[4.1/4.2/4.3 Regression]|[4.1/4.2 Regression] Rejects |Rejects typedef qualified |typedef qualified name- |name-lookup |lookup http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33516
[Bug c++/33516] [4.1/4.2/4.3 Regression] Rejects typedef qualified name-lookup
--- Comment #7 from jakub at gcc dot gnu dot org 2007-11-02 21:37 --- Subject: Bug 33516 Author: jakub Date: Fri Nov 2 21:37:35 2007 New Revision: 129862 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129862 Log: PR c++/33516 * parser.c (cp_parser_nested_name_specifier_opt): Use TYPE_MAIN_VARIANT (new_scope) as scope if new_scope is an incomplete typedef of currently open class. * g++.dg/lookup/typedef1.C: New test. Added: trunk/gcc/testsuite/g++.dg/lookup/typedef1.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33516
[Bug c++/32256] [4.0/4.1/4.2/4.3 regression] pragma system_header doesn't suppress warnings in tree-cfg
--- Comment #5 from pcarlini at suse dot de 2007-11-02 21:12 --- Cool. Then maybe recategorizing is now just a waste of time ;) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32256
[Bug c++/32368] warnings from system headers not suppressed.
-- 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-11-02 21:02:44 |2007-11-02 21:02:56 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32368
[Bug c++/32368] warnings from system headers not suppressed.
--- Comment #4 from tromey at gcc dot gnu dot org 2007-11-02 21:02 --- Testing a patch. -- 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 |2007-11-02 21:02:44 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32368
[Bug c++/32256] [4.0/4.1/4.2/4.3 regression] pragma system_header doesn't suppress warnings in tree-cfg
--- Comment #4 from tromey at gcc dot gnu dot org 2007-11-02 21:02 --- Recategorizing is fine by me -- though I wouldn't consider my opinion authoritative :) FWIW I have a patch to set_cfun that appears to fix both these bugs. I'll bootstrap and test it and see what people think. -- 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-11-02 20:43:14 |2007-11-02 21:02:27 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32256
[Bug c++/32256] [4.0/4.1/4.2/4.3 regression] pragma system_header doesn't suppress warnings in tree-cfg
--- Comment #3 from pcarlini at suse dot de 2007-11-02 20:53 --- Thanks Tom, your help is appreciated. Note we have also c++/32368: shall we recategorize both as middle-end bugs then? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32256
[Bug fortran/33162] INTRINSIC functions as ACTUAL argument
--- Comment #19 from jaydub66 at gmail dot com 2007-11-02 20:53 --- Hi Jerry, I tried your patch (part 3b), and noticed that it fails on the following code: real function t(x) real ::x t = x end function program p implicit none intrinsic sin procedure(sin):: t print *,t(1.0) end program Seems like this is due to the stuff which you added to decl.c (match_procedure_decl): + if (proc_if != NULL && proc_if->attr.intrinsic + && gfc_intrinsic_actual_ok (proc_if->name, 0)) + goto set_if; + if (!sym->attr.pointer && gfc_add_external (&sym->attr, NULL) == FAILURE) return MATCH_ERROR; if (gfc_add_proc (&sym->attr, sym->name, NULL) == FAILURE) return MATCH_ERROR; /* Set interface. */ +set_if: This prevents the procedure from getting the "external" and "procedure" attributes, if the interface is an intrinsic routine. This is wrong. A symbol declared by a PROCEDURE() statement should always get the "procedure" attribute. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33162
[Bug c++/32256] [4.0/4.1/4.2/4.3 regression] pragma system_header doesn't suppress warnings in tree-cfg
--- Comment #2 from tromey at gcc dot gnu dot org 2007-11-02 20:43 --- You can reproduce this in C by using -funit-at-a-time. IMO this is a general bug in unit-at-a-time. Perhaps cgraph_analyze_function or something similar should set in_system_header. Maybe set_cfun. -- tromey at gcc dot gnu dot org changed: What|Removed |Added CC||tromey at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-11-02 20:43:14 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32256
[Bug java/33765] [4.3 regression] gcj internal compiler error when reading an empty file
--- Comment #10 from tromey at gcc dot gnu dot org 2007-11-02 20:02 --- Subject: Bug 33765 Author: tromey Date: Fri Nov 2 20:02:35 2007 New Revision: 129860 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129860 Log: PR java/33765: * jcf-parse.c (java_parse_file): Ignore ZIPEMPTYMAGIC files. * zipfile.h (ZIPEMPTYMAGIC): New define. Modified: trunk/gcc/java/ChangeLog trunk/gcc/java/jcf-parse.c trunk/gcc/java/zipfile.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33765
[Bug java/33765] [4.3 regression] gcj internal compiler error when reading an empty file
--- Comment #11 from jakub at gcc dot gnu dot org 2007-11-02 20:08 --- Fixed, thanks. -- 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=33765
[Bug bootstrap/33781] [4.3 Regression] "Arg list too long" building libgcc.a
--- Comment #13 from dj at redhat dot com 2007-11-02 18:58 --- Created an attachment (id=14473) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14473&action=view) sclsh - short command line shell Here's a short perl script that acts as a "short command line shell" - it complains about any command line longer than 3k bytes. Use "make SHELL=sclsh ...". Edit as needed. It also tells you how long each command line is, although it doesn't work around command lines that exceed system limits. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33781
[Bug bootstrap/33781] [4.3 Regression] "Arg list too long" building libgcc.a
--- Comment #12 from dj at redhat dot com 2007-11-02 18:56 --- Created an attachment (id=14472) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14472&action=view) test patch 3 This one just breaks up #15 into three chunks, with everything else in a single chunk. -- dj at redhat dot com changed: What|Removed |Added Attachment #14457|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33781
[Bug c++/33984] [4.2/4.3 Regression] bit-fields, references and overloads
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-11-02 18:45 --- Confirmed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-11-02 18:45:22 date|| Target Milestone|--- |4.2.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33984
[Bug bootstrap/33781] [4.3 Regression] "Arg list too long" building libgcc.a
--- Comment #11 from jakub at gcc dot gnu dot org 2007-11-02 18:40 --- No wonder I haven't seen so big $$objects in my x86_64-linux build (not that 20KB would be a big deal there). I guess we shouldn't then split libgcc-objects into so many small objects, but instead just use objects="$(filter-out _fract% _satfract%, $(objects))" and then run AR_FOR_TARGET again also for $(filter _fract%, $(objects)) and $(filter _satfract%, $(objects)) if either is not empty. That could cure libgcc.a, but libgcc-s-objects is probably big as well. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33781
[Bug fortran/22244] dimension information is lost for multi-dimension array
--- Comment #10 from fxcoudert at gcc dot gnu dot org 2007-11-02 18:26 --- I think there are other issues with array information, so I think this PR shouldn't be closed yet. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org URL|http://gcc.gnu.org/ml/gcc- | |patches/2007- | |08/msg00851.html| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22244
[Bug testsuite/32076] "gcc.dg/tree-ssa/pr17141-1.c scan-tree-dump locp.*->i =" is the same name twice
--- Comment #2 from janis at gcc dot gnu dot org 2007-11-02 17:54 --- Subject: Bug 32076 Author: janis Date: Fri Nov 2 17:54:12 2007 New Revision: 129858 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129858 Log: PR testsuite/32076 * lib/scandump.exp (dump-suffix): New. (scan-dump, scan-dump-times, scan-dump-dem, scan-dump-dem-not): Include dump suffix in pass/fail messages, put regexp in quotes. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/lib/scandump.exp -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32076
[Bug target/33624] [4.3 Regression] ICE in speculate_insn, at haifa-sched.c:4053
--- Comment #8 from vmakarov at redhat dot com 2007-11-02 17:54 --- I've checked patch http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129378 and as Jakub I confirm too that the patch fixed the bug. So it is really fixed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33624
[Bug c++/33984] New: [4.2/4.3 Regression] bit-fields, references and overloads
The following C++ program should not compile:
struct S {
unsigned int bar : 3;
} s;
int foo(unsigned int &);
int foo(double);
int
main ()
{
return foo(s.bar); // invalid
}
According to the C++ standard, clause 13.3.3.1.4, paragraph 4, the 'bar' should
match against 'foo(unsigned int &)' because both use unsigned int, not the
alternative overload, 'foo(double)'. However, it should then fail because a
bit-field may not be bound to a reference.
GCC 4.1.1 and 4.1.2 did this correctly.
GCC 4.2.0+ silently accept it. The call is incorrectly bound to foo(double).
--
Summary: [4.2/4.3 Regression] bit-fields, references and
overloads
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: andrew dot stubbs at st dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33984
[Bug bootstrap/33781] [4.3 Regression] "Arg list too long" building libgcc.a
--- Comment #10 from dj at redhat dot com 2007-11-02 17:41 --- Subject: Re: [4.3 Regression] "Arg list too long" building libgcc.a You could try splitting that one in two with gmake's $(filter ) and $(filter-out ) functions. The only trick would be finding a simple pattern that matches half the objects. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33781
[Bug target/33624] [4.3 Regression] ICE in speculate_insn, at haifa-sched.c:4053
--- Comment #7 from jakub at gcc dot gnu dot org 2007-11-02 17:15 --- Yes, http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129378 fixed this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33624
[Bug bootstrap/33781] [4.3 Regression] "Arg list too long" building libgcc.a
--- Comment #9 from roger at eyesopen dot com 2007-11-02 17:12 --- Doh! DJ's patch gets us a little further, but it things are still broken. However, it's an excellent debugging tool which shows that its the invocation with libgcc-objects-15 that's broken. Applying the same trick as above shows that $libgcc-objects-15 alone is 19962 bytes, which combined with the "ar" etc.. at the beginning of the command line exceeds the limits. So it's the "fixed-conv-funcs" that are to blame. Perhaps "gen-fixed.sh" has gone insane with the large number of integer-like machine modes on MIPS. The correct fix might actually be in the optabs handling of the middle-end, so we don't need quite so many conversion functions in MIPS' libgcc.a. Or perhaps mips.md need improved support (patterns) for this functionality. I've no idea what _satfractunsUTIUHA is, it's a recent addition and I've not been following gcc-patches lately. Splitting "_fract*" from "_sat*" with a patch similar to DJ's should work. I hope this is enlightening. Is there a --disable-option to avoid building fixed point conversion support? Looks like our command line usage is O(n^2) in the number of backend integer machine modes? Thanks again for everyone's help on this. I'll owe you beers at the next GCC summit. Roger -- -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33781
[Bug middle-end/33981] Compiler ICE when using -fopenmp with C++ code
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-11-02 17:04 --- Likely a dup of PR33361. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||33361 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33981
[Bug c++/33981] Compiler ICE when using -fopenmp with C++ code
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-11-02 17:02 --- Btw, the ICE is graph.cc: In member function void get_vertex_histogram::operator()(const Graph&, Hist&) const [with Graph = boost::adjacency_list, boost::no_property, boost::listS>, Hist = std::tr1::unordered_map, std::equal_to, std::allocator >, false>, DegreeSelector = graph_tool::scalarS]: graph.cc:422: internal compiler error: in find_outermost_region_in_block, at tree-cfg.c:4803 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. For Debian GNU/Linux specific bug reporting instructions, see . also happens with plain -O -fopenmp. The testcase is not compatible with trunk. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33981
[Bug c/33823] bitfields on packed struct aligns by a few bits if the types differ
--- Comment #6 from alexandre dot nunes at gmail dot com 2007-11-02 16:58 --- >From the gcc internals (http://gcc.gnu.org/onlinedocs/gccint/Storage-Layout.html): Target Hook: bool TARGET_MS_BITFIELD_LAYOUT_P (tree record_type) This target hook returns true if bit-fields in the given record_type are to be laid out following the rules of Microsoft Visual C/C++, namely: (i) a bit-field won't share the same storage unit with the previous bit-field if their underlying types have different sizes, and the bit-field will be aligned to the highest alignment of the underlying types of itself and of the previous bit-field; (ii) a zero-sized bit-field will affect the alignment of the whole enclosing structure, even if it is unnamed; except that (iii) a zero-sized bit-field will be disregarded unless it follows another bit-field of nonzero size. If this hook returns true, other macros that control bit-field layout are ignored. When a bit-field is inserted into a packed record, the whole size of the underlying type is used by one or more same-size adjacent bit-fields (that is, if its long:3, 32 bits is used in the record, and any additional adjacent long bit-fields are packed into the same chunk of 32 bits. However, if the size changes, a new field of that size is allocated). In an unpacked record, this is the same as using alignment, but not equivalent when packing. If both MS bit-fields and `__attribute__((packed))' are used, the latter will take precedence. If `__attribute__((packed))' is used on a single field when MS bit-fields are in use, it will take precedence for that field, but the alignment of the rest of the structure may affect its placement. ... it seems like that the packed attribute has the power of nulify the ms_struct attribute, but not the gcc_struct one, regarding a rather non-uniform behaviour if the underlying ABIs are different. It also means that I could use ms_struct,packed in a portable way (even on architetures where the ms_struct isn't even an alternative), but gcc_struct,packed is less portable. Right? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33823
[Bug c++/33960] [4.3 Regression] r129030 breaks -fopenmp -static compile of tramp3d-v4
--- Comment #11 from rguenth at gcc dot gnu dot org 2007-11-02 16:43 --- Linking pthread with --whole-archive works. Re comment #6 - here's the output of nm tramp3d-v4 | grep " pthread_" 00569440 T pthread_attr_destroy 00569480 T pthread_attr_getstacksize 00569420 W pthread_attr_init 0056a980 W pthread_attr_setaffinity_np 00569460 T pthread_attr_setdetachstate 005694a0 T pthread_attr_setstacksize 0056a150 T pthread_cancel w pthread_cond_broadcast w pthread_cond_wait 00568400 W pthread_create 0056a7d0 W pthread_getaffinity_np 00569fd0 T pthread_getspecific 00569f70 T pthread_key_create 005694c0 T pthread_mutex_lock 00569f30 T pthread_mutex_unlock 0056a1c0 T pthread_once 00569410 T pthread_self 0056a8d0 W pthread_setaffinity_np w pthread_setcancelstate 0056a050 T pthread_setspecific -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |NEW Ever Confirmed|0 |1 Last reconfirmed|2007-11-02 14:05:30 |2007-11-02 16:43:03 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33960
[Bug bootstrap/33781] [4.3 Regression] "Arg list too long" building libgcc.a
--- Comment #8 from roger at eyesopen dot com 2007-11-02 16:41 --- Created an attachment (id=14471) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14471&action=view) Default libgcc.a objects on mips-sgi-irix6.5 I'll respond to Jakub's latest comments before trying DJ's more recent patch. Running "getconf ARG_MAX" on my IRIX box, returns 20480, which is 20K. I believe this is the default, out of the box setting for my machine which is running IRIX 6.5.19m. Using cut'n'paste from the failing "make" output, I measure the current "$$objects" to be 25949 bytes. I've attached the "attempted" value of $objects to this e-mail. I'll give DJ's patch a spin... I apologise that this box isn't that speedy. Roger -- -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33781
[Bug c++/33960] [4.3 Regression] r129030 breaks -fopenmp -static compile of tramp3d-v4
--- Comment #10 from rguenth at gcc dot gnu dot org 2007-11-02 16:39 --- The trick from comment #7 doesn't work. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33960
[Bug target/33624] [4.3 Regression] ICE in speculate_insn, at haifa-sched.c:4053
--- Comment #6 from rguenth at gcc dot gnu dot org 2007-11-02 16:34 --- So, fidex. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33624
[Bug target/33624] [4.3 Regression] ICE in speculate_insn, at haifa-sched.c:4053
--- Comment #5 from rguenther at suse dot de 2007-11-02 16:33 --- Subject: Re: [4.3 Regression] ICE in speculate_insn, at haifa-sched.c:4053 On Fri, 2 Nov 2007, vmakarov at redhat dot com wrote: > --- Comment #4 from vmakarov at redhat dot com 2007-11-02 15:20 --- > I've tried GfxFont.ii and the reduced test on Itanium-2 under RHEL > 4.4 for today gcc (revision 129849). There are no crashes anymore. > Everything looks fine. Probably, latest Maxim Kuvyrkov's patches > fixed this. > > Richard, could you tell what gcc revision you tried. I don't remember, but the ICEs vanished for me as well with at least a snapshot from 20071016. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33624
[Bug c++/33983] and invalid_argument name clash with -std=gnu++0x
--- Comment #4 from bkoz at gcc dot gnu dot org 2007-11-02 16:25 --- Doug told me about this pre-Kona. I will invesigate now that post-Kona draft is out... -- bkoz at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |bkoz at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2007-11-02 15:28:50 |2007-11-02 16:25:38 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33983
[Bug libstdc++/33892] [libstdc++ v3 parallel mode] Parallel mode algorithms use critical sections with global scope
--- Comment #7 from bkoz at gcc dot gnu dot org 2007-11-02 16:24 --- That plan sounds good to me as well Johannes. The library API for atomics is in atomicity.h. -benjamin -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33892
[Bug java/33765] [4.3 regression] gcj internal compiler error when reading an empty file
--- Comment #9 from tromey at gcc dot gnu dot org 2007-11-02 16:11 --- Testing my 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-10-31 18:26:32 |2007-11-02 16:11:58 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33765
[Bug libstdc++/33892] [libstdc++ v3 parallel mode] Parallel mode algorithms use critical sections with global scope
--- Comment #6 from pcarlini at suse dot de 2007-11-02 15:59 --- (In reply to comment #5) > Well, there is a lot of obsolete code for compatibility to other compilers. > Most of that could probably be kicked out, when we rely on the GCC > infrastructure. Yes, can be definitely kicked out. Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33892
[Bug libstdc++/33892] [libstdc++ v3 parallel mode] Parallel mode algorithms use critical sections with global scope
--- Comment #5 from singler at ira dot uka dot de 2007-11-02 15:50 --- (In reply to comment #4) > (In reply to comment #2) > > BTW, compatibility.h is horribly i?86/x86_64 centric, there are many other > > arches > > which support 64-bit __sync_fetch_and_add and __sync_bool_compare_and_swap > > (e.g. ia64, ppc64, sparc64, sparcv9, s390x, I believe also s390, etc.). Well, there is a lot of obsolete code for compatibility to other compilers. Most of that could probably be kicked out, when we rely on the GCC infrastructure. > About that, wanted to remind Johannes that we also have the various > __GCC_HAVE_SYNC_COMPARE_AND_SWAP_* which may be useful in such cases... Okay. Then, there should only two cases be necessary: *natively supported by the GCC infrastructure, use __sync_fetch_and_add and __sync_bool_compare_and_swap *not supported by the GCC infrastructure, use OpenMP locks For the latter case, this means bad performance, but the usefulness of the parallel mode is questionable anyway on platforms that do not support these atomic operations. What about that? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33892
[Bug libstdc++/33892] [libstdc++ v3 parallel mode] Parallel mode algorithms use critical sections with global scope
--- Comment #4 from pcarlini at suse dot de 2007-11-02 15:42 --- (In reply to comment #2) > BTW, compatibility.h is horribly i?86/x86_64 centric, there are many other > arches > which support 64-bit __sync_fetch_and_add and __sync_bool_compare_and_swap > (e.g. ia64, ppc64, sparc64, sparcv9, s390x, I believe also s390, etc.). About that, wanted to remind Johannes that we also have the various __GCC_HAVE_SYNC_COMPARE_AND_SWAP_* which may be useful in such cases... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33892
[Bug libstdc++/33892] [libstdc++ v3 parallel mode] Parallel mode algorithms use critical sections with global scope
--- Comment #3 from singler at gcc dot gnu dot org 2007-11-02 15:34 --- Subject: Bug 33892 Author: singler Date: Fri Nov 2 15:34:24 2007 New Revision: 129852 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129852 Log: 2007-11-02 Johannes Singler <[EMAIL PROTECTED]> PR libstdc++/33892 * include/parallel/workstealing.h: Replaced pragma by function call lock. * include/parallel/search.h: Same * include/parallel/partition.h: Same * include/parallel/find.h: Same Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/parallel/find.h trunk/libstdc++-v3/include/parallel/partition.h trunk/libstdc++-v3/include/parallel/search.h trunk/libstdc++-v3/include/parallel/workstealing.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33892
[Bug fortran/33945] PROCEDURE in module somtimes wrongly rejected
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-11-02 15:31:25 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33945
[Bug tree-optimization/33870] [4.3 Regression] miscompiles sqlite
--- Comment #19 from dnovillo at gcc dot gnu dot org 2007-11-02 15:31 --- Working on a fix. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33870
[Bug c++/33983] and invalid_argument name clash with -std=gnu++0x
--- Comment #3 from pcarlini at suse dot de 2007-11-02 15:28 --- Confirmed. I think the issue can (should) be fixed by moving enum posix_errno inside namespace posix_error, per n2461. Benjamin can you have a look? -- pcarlini at suse dot de changed: What|Removed |Added CC||bkoz at redhat dot com Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-11-02 15:28:50 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33983
[Bug fortran/33234] -stf=f* and passing intrinsic function as actual argument without INTRINSIC
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||accepts-invalid Last reconfirmed|-00-00 00:00:00 |2007-11-02 15:27:57 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33234
[Bug fortran/33904] OpenMP: Default(shared) and wrong "lastprivate variable is private in outer context"
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-11-02 15:26:55 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33904
[Bug bootstrap/30589] [4.3 regression] C99 extern inline patch broke bootstrap on i386-pc-mingw32
--- Comment #14 from jakub at gcc dot gnu dot org 2007-11-02 15:23 --- Created an attachment (id=14470) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14470&action=view) gcc43-pr30589.patch Updated patch that could (from eyeballing mingw-runtime-3.*.tar.gz tarballs) fix this for mingw-runtime-3.2 and above (so roughly Oct 2003ish or newer). Can anybody with actual access to this target test it (ideally one test with mignw-runtime <= 3.10, one with 3.11 (which has the __gnu__inline instead of __gnu_inline__ attribute) and one with 3.12 or newer (which does not need fixincluding)? Thanks. -- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30589
[Bug target/33624] [4.3 Regression] ICE in speculate_insn, at haifa-sched.c:4053
--- Comment #4 from vmakarov at redhat dot com 2007-11-02 15:20 --- I've tried GfxFont.ii and the reduced test on Itanium-2 under RHEL 4.4 for today gcc (revision 129849). There are no crashes anymore. Everything looks fine. Probably, latest Maxim Kuvyrkov's patches fixed this. Richard, could you tell what gcc revision you tried. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33624
[Bug c++/33983] and invalid_argument name clash with -std=gnu++0x
--- Comment #2 from cppljevans at suddenlink dot net 2007-11-02 15:17 --- Created an attachment (id=14469) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14469&action=view) output of preprocessor -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33983
[Bug c++/33983] and invalid_argument name clash with -std=gnu++0x
--- Comment #1 from cppljevans at suddenlink dot net 2007-11-02 15:10 --- Created an attachment (id=14468) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14468&action=view) Shows nameclash when using -std=-std=gnu++0x The following is compile commands and output: /home/evansl/download/gcc/4.3-20071026/install/bin/g++ -c -std=gnu++0x -Wall -ftemplate-depth-100 -O0 -fno-inline -I/home/evansl/prog_dev/boost-svn/ro/trunk/sandbox/.. -I/home/evansl/prog_dev/boost-svn/ro/trunk/sandbox/lje /home/evansl/prog_dev/boost-svn/ro/trunk/sandbox/lje/libs/xpressive/proto/example/std_invalid_argument_name_clash.cpp -o /home/evansl/prog_dev/boost-svn/ro/trunk/sandbox/build/gcc4_3v/lje/libs/xpressive/proto/example/std_invalid_argument_name_clash.o -MMD /home/evansl/prog_dev/boost-svn/ro/trunk/sandbox/lje/libs/xpressive/proto/example/std_invalid_argument_name_clash.cpp:10: error: expected constructor, destructor, or type conversion before 'const' -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33983
[Bug c++/33983] New: and invalid_argument name clash with -std=gnu++0x
Both these system include files define invalid_argument. ostream does this by indrectly including i686-pc-linux-gnu/bits/error_constants.h. This is for the 20071026 snapshot. -- Summary: and invalid_argument name clash with -std=gnu++0x Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: cppljevans at suddenlink dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33983
[Bug fortran/28722] Fortran front-end produces mismatch trees
--- Comment #9 from fxcoudert at gcc dot gnu dot org 2007-11-02 14:55 --- Type-checking is now in mainline, and PR31608 is tracking the last remaining failure exposed in the testsuite. Closing this PR. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28722
[Bug c++/33960] [4.3 Regression] r129030 breaks -fopenmp -static compile of tramp3d-v4
--- Comment #9 from jakub at redhat dot com 2007-11-02 14:24 --- The only at least partially workable way of linking statically against NPTL libpthread.a is -Wl,--whole-archive -lpthread -Wl,--no-whole-archive. There is just a huge amount of issues if you don't have everything in there in (e.g. the various cancellation wrappers, which for dynamically linked code can handle cancellation even in libc.so, but not so for the heavily unsupported static linking. Guess we should just change glibc Makefiles to ld -r all libpthread.a objects together and install that as libpthread.a instead. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33960
[Bug other/22368] [meta-bug] mis-match types in GCC
--- Comment #18 from rguenther at suse dot de 2007-11-02 14:22 ---
Subject: Re: [meta-bug] mis-match types in GCC
On Fri, 2 Nov 2007, fxcoudert at gcc dot gnu dot org wrote:
> --- Comment #17 from fxcoudert at gcc dot gnu dot org 2007-11-02 14:16
> ---
> I was willing to check the current state of the Fortran failures (PR28722). I
> have thus applied these patches to current trunk, and bootstrap fails due to:
>
> $ cat foo.i
> char * getc_unlocked (char *foo) { return foo++; }
> $ ../prev-gcc/cc1 -fpreprocessed foo.i -quiet
> foo.i: In function getc_unlocked:
> foo.i:1:1: error: types mismatch in comparsion
> char *
>
> long unsigned int
>
> foo + 1;
>
> foo.i:1:1: internal compiler error: verify_stmts failed
>
>
> (In the patches, tree_ssa_useless_type_conversion_1 needs to be changed into
> useless_type_conversion_p)
I think all these patches are way out-of-date. If the fortran FE still
produces mismatched trees (as PR28722 suggests), those should be catched
by --enable-checking=yes,types.
Richard.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22368
[Bug rtl-optimization/3507] appalling optimisation with sub/cmp on multiple targets
-- rask at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rask at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2007-08-23 20:10:25 |2007-11-02 14:17:51 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3507
[Bug other/22368] [meta-bug] mis-match types in GCC
--- Comment #17 from fxcoudert at gcc dot gnu dot org 2007-11-02 14:16
---
I was willing to check the current state of the Fortran failures (PR28722). I
have thus applied these patches to current trunk, and bootstrap fails due to:
$ cat foo.i
char * getc_unlocked (char *foo) { return foo++; }
$ ../prev-gcc/cc1 -fpreprocessed foo.i -quiet
foo.i: In function getc_unlocked:
foo.i:1:1: error: types mismatch in comparsion
char *
long unsigned int
foo + 1;
foo.i:1:1: internal compiler error: verify_stmts failed
(In the patches, tree_ssa_useless_type_conversion_1 needs to be changed into
useless_type_conversion_p)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22368
[Bug c++/33981] Compiler ICE when using -fopenmp with C++ code
--- Comment #1 from tiago at forked dot de 2007-11-02 14:16 --- Created an attachment (id=14467) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14467&action=view) Code which causes the ICE -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33981
[Bug c++/33981] New: Compiler ICE when using -fopenmp with C++ code
The attached C++ (preprocessed) code gives me a compiler ICE when compiled with -fopenmp, but compiles cleanly otherwise. Environment: Linux finn 2.6.23-mactel #1 SMP PREEMPT Mon Oct 15 01:36:04 BRST 2007 i686 Genuine Intel(R) CPU 1500 @ 2.00GHz GenuineIntel GNU/Linux $ gcc -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: /var/tmp/portage/sys-devel/gcc-4.2.2/work/gcc-4.2.2/configure --prefix=/usr --bindir=/usr/i686-pc-linux-gnu/gcc-bin/4.2.2 --includedir=/usr/lib/gcc/i686-pc-linux-gnu/4.2.2/include --datadir=/usr/share/gcc-data/i686-pc-linux-gnu/4.2.2 --mandir=/usr/share/gcc-data/i686-pc-linux-gnu/4.2.2/man --infodir=/usr/share/gcc-data/i686-pc-linux-gnu/4.2.2/info --with-gxx-include-dir=/usr/lib/gcc/i686-pc-linux-gnu/4.2.2/include/g++-v4 --host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --disable-altivec --enable-nls --without-included-gettext --with-system-zlib --disable-checking --disable-werror --enable-secureplt --disable-libunwind-exceptions --disable-multilib --enable-libmudflap --disable-libssp --enable-java-awt=gtk --with-arch=i686 --enable-languages=c,c++,java,objc,obj-c++,fortran --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu Thread model: posix gcc version 4.2.2 (Gentoo 4.2.2 p1.0) How-To-Repeat: Compile the attached file with: -march=i686 -O3 -Wall -ftemplate-depth-150 -fvisibility=hidden -fvisibility-inlines-hidden -fopenmp -- Summary: Compiler ICE when using -fopenmp with C++ code Product: gcc Version: 4.2.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tiago at forked dot de 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=33981
[Bug c++/33495] [4.1/4.2 regression] Broken diagnostic: Trouble pretty-printing statement expressions
--- Comment #5 from pcarlini at suse dot de 2007-11-02 14:09 --- Fixed for mainline. -- pcarlini at suse dot de changed: What|Removed |Added AssignedTo|pcarlini at suse dot de |unassigned at gcc dot gnu ||dot org Status|ASSIGNED|NEW Summary|[4.1/4.2/4.3 regression]|[4.1/4.2 regression] Broken |Broken diagnostic: Trouble |diagnostic: Trouble pretty- |pretty-printing statement |printing statement |expressions |expressions http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33495
[Bug c++/33495] [4.1/4.2/4.3 regression] Broken diagnostic: Trouble pretty-printing statement expressions
--- Comment #4 from paolo at gcc dot gnu dot org 2007-11-02 14:06 --- Subject: Bug 33495 Author: paolo Date: Fri Nov 2 14:06:43 2007 New Revision: 129850 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129850 Log: 2007-11-02 Paolo Carlini <[EMAIL PROTECTED]> PR c++/33495 * error.c (dump_expr): Deal specially with statements. 2007-11-02 Paolo Carlini <[EMAIL PROTECTED]> PR c++/33495 * g++.dg/other/error19.C: New. Added: trunk/gcc/testsuite/g++.dg/other/error19.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/error.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33495
[Bug c++/33960] [4.3 Regression] r129030 breaks -fopenmp -static compile of tramp3d-v4
--- Comment #8 from rguenth at gcc dot gnu dot org 2007-11-02 14:05 --- Yes, the analysis from comment #6 looks correct - Jakub, can you take care of the required glibc fix? I'll check if Ians trick works as well. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||jakub at gcc dot gnu dot org Last reconfirmed|-00-00 00:00:00 |2007-11-02 14:05:30 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33960
[Bug c++/33975] [4.1/4.2/4.3 Regression] Incomplete types may be derefenced
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-11-02 13:59 --- Confirmed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||accepts-invalid Last reconfirmed|-00-00 00:00:00 |2007-11-02 13:59:28 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33975
[Bug debug/29436] [4.0/4.1/4.2/4.3 Regression] ICE in modified_type_die
-- jason at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2007-08-06 15:15:45 |2007-11-02 13:50:43 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29436
[Bug c++/28560] [4.0/4.1/4.2/4.3 regression] Trouble with __attribute__ in template parameter
-- jason at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-11-02 13:49:52 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28560
[Bug fortran/33945] PROCEDURE in module somtimes wrongly rejected
--- Comment #3 from jvdelisle at verizon dot net 2007-11-02 13:29 --- Subject: Re: PROCEDURE in module somtimes wrongly rejected burnus at gcc dot gnu dot org wrote: > --- Comment #2 from burnus at gcc dot gnu dot org 2007-11-02 07:40 > --- > Note: MODULE PROCEDURE and PROCEDURE mean different things. > > "MODULE PROCEDURE" can only be a procedure which is a procedure from that > module. "PROCEDURE" can be any procedure whose interface is explicitly known: > Module procedures, use-associated procedures, external procedures (via > INTERFACE or PROCEDURE(...) statement). > Is that PROCEDURE(...) with or without the parenthesis? We need to parse this correctly without a doubt or we have to search the module to tell the difference? (If the 'MODULE' key word is optional for "MODULE PROCEDURE".) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33945
[Bug target/33624] [4.3 Regression] ICE in speculate_insn, at haifa-sched.c:4053
--- Comment #3 from vmakarov at redhat dot com 2007-11-02 13:23 --- I'll look at this. -- vmakarov at redhat dot com changed: What|Removed |Added CC||vmakarov at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33624
[Bug c/33980] New: Precompiled header file not removed on error
$ cat err.h #error err $ gcc -c err.h err.h:1:2: error: #error err $ ls err.h.gch err.h.gch -- Summary: Precompiled header file not removed on error Product: gcc Version: 4.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: photon at seznam dot cz GCC host triplet: Linux OpenSuse 10.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33980
[Bug fortran/25252] ICE on invalid code
--- Comment #15 from jvdelisle at gcc dot gnu dot org 2007-11-02 13:18 --- I still get segfault with the original case and garbled text on the case in comment #7 -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Last reconfirmed|2006-01-27 20:44:57 |2007-11-02 13:18:42 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25252
[Bug middle-end/33670] [4.3 Regression] cc1 segfault with -O2 -fsched-stalled-insns=0 for twolf
--- Comment #1 from jakub at gcc dot gnu dot org 2007-11-02 13:10 ---
Testing a fix.
--- haifa-sched.c.jj9 2007-10-15 15:28:39.0 +0200
+++ haifa-sched.c 2007-11-02 14:10:20.0 +0100
@@ -1590,6 +1590,12 @@ ok_for_early_queue_removal (rtx insn)
{
int cost;
+ if (prev_insn == current_sched_info->prev_head)
+ {
+ prev_insn = NULL;
+ break;
+ }
+
if (!NOTE_P (prev_insn))
{
dep_t dep;
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org
|dot org |
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2007-11-02 13:10:38
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33670
[Bug rtl-optimization/30113] [4.1 Regression] ICE in trunc_int_for_mode
--- Comment #9 from ebotcazou at gcc dot gnu dot org 2007-11-02 12:26 --- Everywhere. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30113
[Bug rtl-optimization/30113] [4.1 Regression] ICE in trunc_int_for_mode
--- Comment #8 from ebotcazou at gcc dot gnu dot org 2007-11-02 12:24 --- Subject: Bug 30113 Author: ebotcazou Date: Fri Nov 2 12:24:44 2007 New Revision: 129849 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129849 Log: Backport from mainline: 2006-12-11 Zdenek Dvorak <[EMAIL PROTECTED]> PR rtl-optimization/30113 * loop-iv.c (implies_p): Require the mode of the operands to be scalar. Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/loop-iv.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30113
[Bug rtl-optimization/28062] ICE in simplify_subreg, at simplify-rtx.c:4466
--- Comment #21 from ebotcazou at gcc dot gnu dot org 2007-11-02 11:58 --- Subject: Bug 28062 Author: ebotcazou Date: Fri Nov 2 11:57:51 2007 New Revision: 129848 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129848 Log: PR rtl-optimization/28062 * gcc.c-torture/compile/20071102-1.c: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gcc.c-torture/compile/20071102-1.c Modified: branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28062
[Bug rtl-optimization/28062] ICE in simplify_subreg, at simplify-rtx.c:4466
--- Comment #20 from ebotcazou at gcc dot gnu dot org 2007-11-02 11:57 --- Subject: Bug 28062 Author: ebotcazou Date: Fri Nov 2 11:57:28 2007 New Revision: 129847 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129847 Log: PR rtl-optimization/28062 * gcc.c-torture/compile/20071102-1.c: New test. Added: branches/gcc-4_2-branch/gcc/testsuite/gcc.c-torture/compile/20071102-1.c Modified: branches/gcc-4_2-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28062
[Bug rtl-optimization/28062] ICE in simplify_subreg, at simplify-rtx.c:4466
--- Comment #19 from ebotcazou at gcc dot gnu dot org 2007-11-02 11:57 --- Subject: Bug 28062 Author: ebotcazou Date: Fri Nov 2 11:57:05 2007 New Revision: 129846 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129846 Log: PR rtl-optimization/28062 * gcc.c-torture/compile/20071102-1.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/compile/20071102-1.c Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28062
