[Bug target/37989] PR37528 fix broke --disable-shared on mingw32
--- Comment #2 from dannysmith at users dot sourceforge dot net 2008-11-03 07:45 --- Created an attachment (id=16614) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16614&action=view) revised patch to quard with ENABLE_SHARED_LIBGCC Hi Mikael, I have modified your patch slightly and added a ChangeLog entry. It works for me with host=build=target=mingw32. Does attached it work for you. Danny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37989
[Bug c++/37967] [4.4 regression] ICE with function returning auto
--- Comment #4 from reichelt at gcc dot gnu dot org 2008-11-03 07:41 --- *** Bug 37964 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37967
[Bug c++/37964] [4.4 regression] ICE with operator auto
--- Comment #4 from reichelt at gcc dot gnu dot org 2008-11-03 07:41 --- ... to mark as duplicate as PR37967 as the bug was fixed with the patch for PR37967. *** This bug has been marked as a duplicate of 37967 *** -- reichelt at gcc dot gnu dot org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37964
[Bug c++/37964] [4.4 regression] ICE with operator auto
--- Comment #3 from reichelt at gcc dot gnu dot org 2008-11-03 07:40 --- Reopen ... -- reichelt at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|DUPLICATE | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37964
[Bug c/37995] using fails if gcc invoked in a directory which has a subdirectory called "gcc"
--- Comment #3 from mvanier at cs dot caltech dot edu 2008-11-03 07:38 --- The operating system is Arch Linux, and the package manager is Arch-specific and is called pacman. There is a separate package manager for building packages from scratch called ABS (Arch Build System). I'm attaching their build script (called PKGBUILD). However, in this particular case I built gcc myself and installed it in /pkg/gcc. Here is the test you asked for: > gcc --save-temps -v hello.c Using built-in specs. Target: i686-pc-linux-gnu Configured with: /src/gcc/gcc-4.3.2/configure --prefix=/pkg/gcc --enable-languages=c,c++,objc Thread model: posix gcc version 4.3.2 (GCC) COLLECT_GCC_OPTIONS='-save-temps' '-v' '-mtune=generic' /usr/lib/gcc/i686-pc-linux-gnu/4.3.2/cc1 -E -quiet -v -iprefix /home/mvanier/tmp/../lib/gcc/i686-pc-linux-gnu/4.3.2/ hello.c -mtune=generic -fpch-preprocess -o hello.i ignoring nonexistent directory "/home/mvanier/tmp/../lib/gcc/i686-pc-linux-gnu/4.3.2/include" ignoring nonexistent directory "/home/mvanier/tmp/../lib/gcc/i686-pc-linux-gnu/4.3.2/include-fixed" ignoring nonexistent directory "/home/mvanier/tmp/../lib/gcc/i686-pc-linux-gnu/4.3.2/../../../../i686-pc-linux-gnu/include" ignoring nonexistent directory "/home/mvanier/tmp/../lib/gcc/../../lib/gcc/i686-pc-linux-gnu/4.3.2/include" ignoring nonexistent directory "/home/mvanier/tmp/../lib/gcc/../../lib/gcc/i686-pc-linux-gnu/4.3.2/include-fixed" ignoring nonexistent directory "/home/mvanier/tmp/../lib/gcc/../../lib/gcc/i686-pc-linux-gnu/4.3.2/../../../../i686-pc-linux-gnu/include" #include "..." search starts here: #include <...> search starts here: /usr/local/include /usr/include End of search list. In file included from hello.c:1: /usr/include/stdio.h:34:21: error: stddef.h: No such file or directory In file included from /usr/include/stdio.h:75, from hello.c:1: /usr/include/libio.h:53:21: error: stdarg.h: No such file or directory One thing that jumps out at me is that it is using /usr/include and /usr/local/include as the only locations for looking up include files. stddefs.h and stdarg.h are not there, but they aren't there in any other distro I've looked at either, so I assumed that they were somehow handled specially by gcc. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37995
[Bug c/37995] using fails if gcc invoked in a directory which has a subdirectory called "gcc"
--- Comment #2 from mvanier at cs dot caltech dot edu 2008-11-03 07:37 --- Created an attachment (id=16613) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16613&action=view) build script for gcc on Arch Linux See other posts for this bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37995
[Bug fortran/37821] [4.4 Regression] gfortran is ignoring #includes with the syntax
--- Comment #9 from burnus at gcc dot gnu dot org 2008-11-03 07:35 --- FIXED on the trunk. Thanks for the report and sorry that it took that long to commit the fix. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37821
[Bug fortran/37821] [4.4 Regression] gfortran is ignoring #includes with the syntax
--- Comment #8 from burnus at gcc dot gnu dot org 2008-11-03 07:21 --- Subject: Bug 37821 Author: burnus Date: Mon Nov 3 07:20:24 2008 New Revision: 141544 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141544 Log: 2008-11-03 Tobias Burnus <[EMAIL PROTECTED]> PR fortran/37821 * cpp.c (gfc_cpp_add_include_path): Use BRACKET. * scanner.c (add_path_to_list): Argument to add at head. (gfc_add_include_path): Add new argument. (gfc_add_intrinsic_modules_path) Update call. (load_file): Print filename/line in the error message. * gfortran.h (gfc_add_include_path): Update prototype. * options.c (gfc_post_options,gfc_handle_module_path_options, gfc_handle_option): Update call. * lang-spec.h (F951_OPTIONS): Don't insert include path twice. * arith.c (arith_error): Add -fno-range-error to the message. 2008-11-03 Tobias Burnus <[EMAIL PROTECTED]> PR fortran/37821 * gfortran.dg/include_4.f90: New. * gfortran.dg/include_5.f90: New. * gfortran.dg/include_4.inc: New. Added: trunk/gcc/testsuite/gfortran.dg/include_4.f90 trunk/gcc/testsuite/gfortran.dg/include_4.inc trunk/gcc/testsuite/gfortran.dg/include_5.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/arith.c trunk/gcc/fortran/cpp.c trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/lang-specs.h trunk/gcc/fortran/options.c trunk/gcc/fortran/scanner.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37821
[Bug fortran/37445] Host-associated proc not found if same-name generic is use-associated
--- Comment #16 from pault at gcc dot gnu dot org 2008-11-03 06:46 --- Subject: Bug 37445 Author: pault Date: Mon Nov 3 06:44:47 2008 New Revision: 141543 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141543 Log: 2008-11-03 Paul Thomas <[EMAIL PROTECTED]> PR fortran/37445 * resolve.c (resolve_actual_arglist ): Correct comparison of FL_VARIABLE with e->expr_type. (resolve_call): Check that host association is correct. (resolve_actual_arglist ): Remove return is old_sym is use associated. Only reparse expression if old and new symbols have different types. PR fortran/PR35769 * resolve.c (gfc_resolve_assign_in_forall): Change error to a warning. 2008-11-03 Paul Thomas <[EMAIL PROTECTED]> PR fortran/37445 * gfortran.dg/host_assoc_call_3.f90: New test. * gfortran.dg/host_assoc_call_4.f90: New test. * gfortran.dg/host_assoc_function_4.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/host_assoc_call_3.f90 trunk/gcc/testsuite/gfortran.dg/host_assoc_call_4.f90 trunk/gcc/testsuite/gfortran.dg/host_assoc_function_4.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37445
[Bug target/37989] PR37528 fix broke --disable-shared on mingw32
-- dannysmith at users dot sourceforge dot net changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dannysmith at users dot |dot org |sourceforge dot net Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-11-03 06:09:24 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37989
[Bug fortran/37832] System_Clock
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2008-11-03 02:17 --- I will add this to my list and see if we can get to what g77 does. -- 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|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-11-03 02:17:47 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37832
[Bug fortran/37999] Fortran shape and kind intrinsic
--- Comment #1 from kargl at gcc dot gnu dot org 2008-11-03 00:00 --- Code works with 4.3.2 and trunk. Note you probably want to 1) Update to a 4.3.2 or newer compiler. 2) Change the example to program test_shape integer :: i print *, size(shape(i)) ! Shape of a scalar allowed by f95 standards. end program test_shape because shape(i) is a zero sized array. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37999
[Bug fortran/37999] New: Fortran shape and kind intrinsic
Shape intrinsic does not allow scalar arguments as required by f90/f95/f03
standards. Example code follows:
program test_shape ! Segmentation fault generated when executable executed
integer :: i
print *, shape( i ) ! Shape of a scalar allowed by f90, f95, f03
! standards.
end program test_shape
Kind intrinsic with character argument in type declaration fails: Example
follows:
! Compiler version:
! GNU Fortran (GCC) 4.2.4 (Ubuntu 4.2.4-1ubuntu3)
! Copyright (C) 2007 Free Software Foundation, Inc.
character (len = 3, kind = kind("a" ) c ! Compiler fails with internal error
-- invalid syntax
! character (len = 3, kind = kind("a") ) c ! Fails compilation -- invalid
kind
! value returned -- that is, minus
! integer huge. Notice the
! kind("a") is correctly returned
! as 1 in print statement below
and
! kind=1 works in a character
! declaration.
! character (len = 3, kind = 1) c ! Works
c = "b"
print *, kind("a"), c
end program
--
Summary: Fortran shape and kind intrinsic
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: carbess at swcp dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37999
[Bug tree-optimization/37991] [4.4 Regression] excessive memory consumption - possible hang
--- Comment #8 from dberlin at gcc dot gnu dot org 2008-11-02 20:53 ---
Subject: Re: [4.4 Regression] excessive memory consumption - possible hang
On Sun, Nov 2, 2008 at 7:04 AM, rguenth at gcc dot gnu dot org
<[EMAIL PROTECTED]> wrote:
>
>
> --- Comment #5 from rguenth at gcc dot gnu dot org 2008-11-02 12:04
> ---
> More reduced:
>
> typedef int Int32;
> void use_it(int);
> void FindAndReadSignature(int processedSize)
> {
>int numPrevBytes = 1;
>for (;;)
> {
>int numBytesInBuffer = numPrevBytes + processedSize;
>Int32 numTests = numBytesInBuffer - 1;
>use_it (numTests);
>numPrevBytes = numBytesInBuffer - numTests;
> }
> }
>
> to not oscillate we rely on numTests _not_ be varying. It happens to be
> with the typedef as we forget to strip useless conversions. Otherwise
> we oscillate numPrevBytes (loop entry vs. back edge) between 1 and varying.
>
> Which may hint at that the speedup brought up by Danny (not processing a
> use further if it got varying) is even a correctness thing...
Things should never go up the lattice :)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37991
[Bug other/37998] New: Unclear documentation of -fno-common
The gcc.1 manpage states: >-fno-common > In C, allocate even uninitialized global variables in the data sec- > tion of the object file, rather than generating them as common > blocks. This has the effect that if the same variable is declared > (without "extern") in two different compilations, you will get an > error when you link them. That description is confusing because it's unclear which of the two opposite situations in the first sentence is the antecedent of the "This" in the second sentence. Alternative and clearer wordings for second sentence could be: > If the same variable is declared (without "extern") in two > different compilations and is allocated in the common blocks, you > will get an error when you link them due to multiple allocations of > the same global symbol. -- Summary: Unclear documentation of -fno-common Product: gcc Version: 4.3.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dmacks at netspace dot org GCC build triplet: powerpc-apple-darwin8.11.0 GCC host triplet: powerpc-apple-darwin8.11.0 GCC target triplet: powerpc-apple-darwin8.11.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37998
[Bug ada/37977] Missing ada multilib support for s390x
--- Comment #4 from krebbel at gcc dot gnu dot org 2008-11-02 18:48 --- Fixed with the patch above. -- krebbel at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37977
[Bug ada/37977] Missing ada multilib support for s390x
--- Comment #3 from krebbel at gcc dot gnu dot org 2008-11-02 18:43 --- Subject: Bug 37977 Author: krebbel Date: Sun Nov 2 18:42:04 2008 New Revision: 141537 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141537 Log: 2008-11-02 Andreas Krebbel <[EMAIL PROTECTED]> PR target/37977 * gcc-interface/Makefile.in: Add multilib handling for s390-linux and s390x-linux. Modified: trunk/gcc/ada/ChangeLog trunk/gcc/ada/gcc-interface/Makefile.in -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37977
[Bug middle-end/31029] Fold does not fold C - a == a
--- Comment #7 from rguenth at gcc dot gnu dot org 2008-11-02 18:23 --- Actually we can fold C - a == a only for odd C. But more generally a +- b == a to b == 0. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31029
[Bug fortran/37992] [4.4 Regression] ICE segfault for "character(len=len(x)) :: foo,x"
--- Comment #4 from mikael dot morin at tele2 dot fr 2008-11-02 18:03 --- Created an attachment (id=16612) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16612&action=view) hackish patch I think I got it. When the statement is rejected, all changes are reverted. However, the namespace is still holding the expression for len(x) in cl_list. So, when resolving len(x) we have a pointer to len's freed symtree. This patch solves the problem by adding a old_cl_list field which is copied back to cl_list if the statement is rejected. I'm not sure it is the right way to do it though. As an inquiry function, len should always be reachable, whatever happens. What's your opinion? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37992
[Bug fortran/37992] [4.4 Regression] ICE segfault for "character(len=len(x)) :: foo,x"
--- Comment #3 from mikael dot morin at tele2 dot fr 2008-11-02 17:50 --- (In reply to comment #1) > First valgrind error: > > ==21621== Invalid read of size 8 > ==21621==at 0x46AAEA: gfc_resolve_expr (resolve.c:4248) > Second valgrind error: > > ==21621== Address 0x65b2ef8 is 40 bytes inside a block of size 56 free'd > ==21621==at 0x4C243AF: free (in > /usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so) > ==21621==by 0x482C6A: gfc_delete_symtree (symbol.c:2269) Those are the same error (look carefully, the second one is indented). The first part indicates where the error appears. The second one precises the error (here access to a freed block) and where (in this case) the free was. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37992
[Bug middle-end/31029] Fold does not fold a + C == a
--- Comment #6 from rguenth at gcc dot gnu dot org 2008-11-02 16:08 --- This is because fold doesn't fold ig_1 == 1 - ig_1 to a constant. Which is just because it doesn't handle this canonical form but expects X +- CST always. Fixing that makes the first forwprop pass optimize the comparison to false. I have a patch, queued for 4.5. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Severity|normal |enhancement Status|NEW |ASSIGNED Component|tree-optimization |middle-end Last reconfirmed|2008-08-28 15:40:02 |2008-11-02 16:08:21 date|| Summary|missed optimization |Fold does not fold a + C == ||a http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31029
[Bug tree-optimization/37997] New: PHI translation does not simplify to non-constants
Split from PR37542.
int foo (int i, int b)
{
int mask;
int result;
if (b)
mask = -1;
else
mask = 0;
result = result & mask;
return result;
}
should be optimized to
int foo (int i, int b)
{
int mask;
int result;
if (b)
result = result;
else
result = 0;
return result;
}
But we need to be careful with simplifying to SSA_NAMEs as the following
example
shows:
int foo (int i, int b)
{
int mask;
int result;
if (b)
mask = -1;
else
mask = 0;
result = i + 1;
result = result & mask;
return result;
}
we have a phi-translation for result & mask that is 0 or result dependent
on the path through the CFG. But we cannot insert this as a PHI as one
argument (result with value i + 1) is not available there.
The PRE of 4.3 inserts i + 1, re-generating the expression recursively and
exposing a code hoisting opportunity:
:
if (b_2(D) != 0)
goto ;
else
goto ;
:
pretmp.6_10 = i_5(D) + 1;
pretmp.6_11 = pretmp.6_10;
goto ;
:
pretmp.6_13 = i_5(D) + 1;
:
# prephitmp.7_14 = PHI
# prephitmp.7_12 = PHI
# mask_1 = PHI <-1(5), 0(3)>
result_6 = prephitmp.7_14;
result_7 = prephitmp.7_12;
return result_7;
I don't think we want to do this now (without code hoisting implemented), but
for cases where result_6 is available we surely want it.
I'm trying to find a way to detect whether it is safe to phi-translate to
result_6.
--
Summary: PHI translation does not simplify to non-constants
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P3
Component: tree-optimization
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=37997
[Bug tree-optimization/37542] [4.4 Regression] PRE doesn't simplify during phi-translation
--- Comment #7 from rguenth at gcc dot gnu dot org 2008-11-02 15:27 --- Fixed as far as constants are concerned. For the non-constant case I'll open another bug. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37542
[Bug tree-optimization/37542] [4.4 Regression] PRE doesn't simplify during phi-translation
--- Comment #6 from rguenth at gcc dot gnu dot org 2008-11-02 15:27 --- Subject: Bug 37542 Author: rguenth Date: Sun Nov 2 15:26:04 2008 New Revision: 141534 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141534 Log: 2008-11-02 Richard Guenther <[EMAIL PROTECTED]> PR tree-optimization/37542 * tree-ssa-pre.c (fully_constant_expression): Handle more cases. * tree-ssa-sccvn.c (vn_get_expr_for): Fix typo. (vn_nary_op_lookup_stmt): Adjust for unary reference trees. (vn_nary_op_insert_stmt): Likewise. (visit_use): Likewise. * gcc.dg/tree-ssa/ssa-pre-22.c: New testcase. * gcc.c-torture/compile/20081101-1.c: Likewise. Added: trunk/gcc/testsuite/gcc.c-torture/compile/20081101-1.c trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-pre-22.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-pre.c trunk/gcc/tree-ssa-sccvn.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37542
[Bug bootstrap/37996] New: libgcc.mvars missing dependency on the variable tmake_file, maybe others
In an already-built objdir, touch or modify any of your target-specific t-* files, then in gcc "make libgcc.mvars". Observe that libgcc.mvars is unmodified. To fix, just add $(tmake_file) to the dependencies for libgcc.mvars. Almost as simple as writing a bugzilla entry, but only almost... and I'd have to check other similar variables should also be dependencies. -- Summary: libgcc.mvars missing dependency on the variable tmake_file, maybe others Product: gcc Version: 4.3.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hp at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37996
[Bug fortran/37159] RANDOM_SEED: PUT= check array size at compile time
--- Comment #6 from burnus at gcc dot gnu dot org 2008-11-02 14:18 --- > Not closing yet, as the GET array could also be checked, > see http://gcc.gnu.org/ml/fortran/2008-10/msg00281.html . Another item: If the default integer is 8 instead of 4, the array sizes are half as big (see also URL). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37159
[Bug tree-optimization/37991] [4.4 Regression] excessive memory consumption - possible hang
--- Comment #7 from rguenth at gcc dot gnu dot org 2008-11-02 13:36 --- Subject: Bug 37991 Author: rguenth Date: Sun Nov 2 13:34:58 2008 New Revision: 141532 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141532 Log: 2008-11-02 Richard Guenther <[EMAIL PROTECTED]> PR tree-optimization/37991 * tree-ssa-sccvn.h (copy_vuses_from_stmt): Remove. * tree-ssa-sccvn.c (copy_vuses_from_stmt): Make static. (set_ssa_val_to): Print if the value changed. (simplify_binary_expression): Strip useless conversions. * gcc.c-torture/compile/pr37991.c: New testcase. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr37991.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-sccvn.c trunk/gcc/tree-ssa-sccvn.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37991
[Bug tree-optimization/37991] [4.4 Regression] excessive memory consumption - possible hang
--- Comment #6 from rguenth at gcc dot gnu dot org 2008-11-02 13:35 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37991
[Bug c++/35652] [4.2/4.3/4.4 Regression] offset warning should be given in the front-end
--- Comment #12 from pinskia at gmail dot com 2008-11-02 13:07 ---
Subject: Re: [4.2/4.3/4.4 Regression] offset warning should be given in the
front-end
Sent from my iPhone
On Nov 2, 2008, at 4:53 AM, "manu at gcc dot gnu dot org"
<[EMAIL PROTECTED]
> wrote:
>
>
> --- Comment #10 from manu at gcc dot gnu dot org 2008-11-02
> 12:53 ---
> (In reply to comment #9)
>>> This is my current patch and it works in this testcase. However,
>>> it also
>>> triggers on cases like: const char *p = str + sizeof(str)
>>>
>>> Perhaps I am doing this at the wrong place. Any suggestions?
>>
>> Keep in mind that one-after the string is ok, so ...
>
> Do you mean one after the null character? If you have str = "abcd".
> Then
> sizeof(str) is 5 and str + sizeof(str) points outside the string.
> (str[4] is
> the null character).
That is still well defined. Taking the address of one element past the
end of the array is well defined. Just you can not derefence it.
Thanks,
Andrew Pinski
>
>
>>>
>>> @@ -3322,10 +3323,36 @@ pointer_int_sum (enum tree_code resultco
>>> + {
>>> + HOST_WIDE_INT max = TREE_STRING_LENGTH (string_cst) - 1;
>>
>> ... the -1 is wrong here.
>>
>
> TREE_STRING_LENGTH is the size of the character array, not the
> string. Are you
> sure it is wrong?
>
>
> --
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35652
>
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35652
Re: [Bug c++/35652] [4.2/4.3/4.4 Regression] offset warning should be given in the front-end
Sent from my iPhone
On Nov 2, 2008, at 4:53 AM, "manu at gcc dot gnu dot org" <[EMAIL PROTECTED]
> wrote:
--- Comment #10 from manu at gcc dot gnu dot org 2008-11-02
12:53 ---
(In reply to comment #9)
This is my current patch and it works in this testcase. However,
it also
triggers on cases like: const char *p = str + sizeof(str)
Perhaps I am doing this at the wrong place. Any suggestions?
Keep in mind that one-after the string is ok, so ...
Do you mean one after the null character? If you have str = "abcd".
Then
sizeof(str) is 5 and str + sizeof(str) points outside the string.
(str[4] is
the null character).
That is still well defined. Taking the address of one element past the
end of the array is well defined. Just you can not derefence it.
Thanks,
Andrew Pinski
@@ -3322,10 +3323,36 @@ pointer_int_sum (enum tree_code resultco
+ {
+ HOST_WIDE_INT max = TREE_STRING_LENGTH (string_cst) - 1;
... the -1 is wrong here.
TREE_STRING_LENGTH is the size of the character array, not the
string. Are you
sure it is wrong?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35652
[Bug c++/35652] [4.2/4.3/4.4 Regression] offset warning should be given in the front-end
--- Comment #11 from rguenth at gcc dot gnu dot org 2008-11-02 13:02 --- I'm not sure. Does TREE_STRING_LENGTH in the particular case include the NULL character? Does sizeof(str) include the NULL character? In principle it is allowed to have a pointer point one after the last element of an array. That IMHO would include the NULL character, so for "foo" pointing to "foo" + 4 would be ok. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35652
[Bug c++/35652] [4.2/4.3/4.4 Regression] offset warning should be given in the front-end
--- Comment #10 from manu at gcc dot gnu dot org 2008-11-02 12:53 ---
(In reply to comment #9)
> > This is my current patch and it works in this testcase. However, it also
> > triggers on cases like: const char *p = str + sizeof(str)
> >
> > Perhaps I am doing this at the wrong place. Any suggestions?
>
> Keep in mind that one-after the string is ok, so ...
Do you mean one after the null character? If you have str = "abcd". Then
sizeof(str) is 5 and str + sizeof(str) points outside the string. (str[4] is
the null character).
> >
> > @@ -3322,10 +3323,36 @@ pointer_int_sum (enum tree_code resultco
> > + {
> > + HOST_WIDE_INT max = TREE_STRING_LENGTH (string_cst) - 1;
>
> ... the -1 is wrong here.
>
TREE_STRING_LENGTH is the size of the character array, not the string. Are you
sure it is wrong?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35652
[Bug tree-optimization/36439] [4.3 Regression] infinite loop in PRE building gimp-plugin-registry
--- Comment #7 from rguenth at gcc dot gnu dot org 2008-11-02 12:48 ---
We take a long time in compute_antic in the loop
for (i = 0; i < last_basic_block - NUM_FIXED_BLOCKS; i++)
{
if (TEST_BIT (changed_blocks, postorder[i]))
{
basic_block block = BASIC_BLOCK (postorder[i]);
changed |= compute_antic_aux (block,
TEST_BIT (has_abnormal_preds,
block->index));
}
}
(gdb) print cfun->cfg->x_last_basic_block
$22 = 3220
and some invocations of compute_antic_aux take a really long time during
phi_translate_set because the to translate set is really large (it has
in one case 11885 elements).
probably not much to do here ...
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Last reconfirmed|2008-06-05 11:37:39 |2008-11-02 12:48:47
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36439
[Bug tree-optimization/36439] [4.3 Regression] infinite loop in PRE building gimp-plugin-registry
--- Comment #6 from rguenth at gcc dot gnu dot org 2008-11-02 12:33 --- It seems to work on the trunk now. I'm trying to reduce it on the branch. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Known to fail||4.3.2 Known to work||4.2.4 4.4.0 Summary|[4.3/4.4 Regression]|[4.3 Regression] infinite |infinite loop in PRE|loop in PRE building gimp- |building gimp-plugin- |plugin-registry |registry| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36439
[Bug c++/35652] [4.2/4.3/4.4 Regression] offset warning should be given in the front-end
--- Comment #9 from rguenther at suse dot de 2008-11-02 12:20 ---
Subject: Re: [4.2/4.3/4.4 Regression] offset warning should
be given in the front-end
On Sat, 1 Nov 2008, manu at gcc dot gnu dot org wrote:
> --- Comment #8 from manu at gcc dot gnu dot org 2008-11-01 17:44 ---
> This is my current patch and it works in this testcase. However, it also
> triggers on cases like: const char *p = str + sizeof(str)
>
> Perhaps I am doing this at the wrong place. Any suggestions?
Keep in mind that one-after the string is ok, so ...
>
> @@ -3322,10 +3323,36 @@ pointer_int_sum (enum tree_code resultco
>
>/* Create the sum or difference. */
>if (resultcode == MINUS_EXPR)
> intop = fold_build1 (NEGATE_EXPR, sizetype, intop);
>
> +
> + if (TREE_CODE (intop) == INTEGER_CST)
> +{
> + tree offset_node;
> + tree string_cst = string_constant (ptrop, &offset_node);
> +
> + if (string_cst != 0
> + && !(offset_node && TREE_CODE (offset_node) != INTEGER_CST))
> + {
> + HOST_WIDE_INT max = TREE_STRING_LENGTH (string_cst) - 1;
... the -1 is wrong here.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35652
[Bug tree-optimization/37991] [4.4 Regression] excessive memory consumption - possible hang
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-11-02 12:04 ---
More reduced:
typedef int Int32;
void use_it(int);
void FindAndReadSignature(int processedSize)
{
int numPrevBytes = 1;
for (;;)
{
int numBytesInBuffer = numPrevBytes + processedSize;
Int32 numTests = numBytesInBuffer - 1;
use_it (numTests);
numPrevBytes = numBytesInBuffer - numTests;
}
}
to not oscillate we rely on numTests _not_ be varying. It happens to be
with the typedef as we forget to strip useless conversions. Otherwise
we oscillate numPrevBytes (loop entry vs. back edge) between 1 and varying.
Which may hint at that the speedup brought up by Danny (not processing a
use further if it got varying) is even a correctness thing...
I have a patch for this particular case.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||dberlin at gcc dot gnu dot
||org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37991
[Bug tree-optimization/37991] [4.4 Regression] excessive memory consumption - possible hang
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-11-02 11:27 ---
The following fails this way with plain -O. The key is the typedef - if you
replace the use of UInt32 with unsinged int the testcase succeeds. Mine.
typedef unsigned int UInt32;
int Read(unsigned int *processedSize);
void FindAndReadSignature(void)
{
unsigned int numPrevBytes = 31;
for (;;)
{
unsigned int numReadBytes = (1 << 16) - numPrevBytes;
unsigned int processedSize;
int __result__ = Read(&processedSize);
unsigned int numBytesInBuffer = numPrevBytes + processedSize;
UInt32 numTests = numBytesInBuffer - 31;
for (unsigned int pos = 0; pos < numTests; pos++)
;
numPrevBytes = numBytesInBuffer - numTests;
}
}
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot
|dot org |org
Status|NEW |ASSIGNED
Last reconfirmed|2008-11-02 10:42:12 |2008-11-02 11:27:05
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37991
[Bug c/37995] using fails if gcc invoked in a directory which has a subdirectory called "gcc"
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-11-02 11:02 --- Works for me. What is the output if you add -v to the commandline? This may be a packaging bug of your operating system vendor - which is? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37995
[Bug c/37990] -Os produces redundant instructions
--- Comment #2 from reza at parvan dot net 2008-11-02 11:01 --- Arrrg! I'm very sorry. Please ignore this bug report. I'll change the status to INVALID if that's okay. Thanks for your response. Reza. -- reza at parvan dot net changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37990
[Bug tree-optimization/37991] [4.4 Regression] excessive memory consumption - possible hang
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-11-02 10:58 --- Reducing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37991
[Bug ada/37993] [4.4 Regression] bootstrap with ada fails: a-direct.ads:426:09: alignment for "Search_Typeb82s" must be at least 8
--- Comment #1 from charlet at adacore dot com 2008-11-02 10:57 --- Subject: Re: [4.4 Regression] bootstrap with ada fails: a-direct.ads:426:09: alignment for "Search_Typeb82s" must be at least 8 This is yet again a failure due to having multilibs enabled by default for Ada with no proper support for it (this time on darwin). Do we have the many times discussed option --disable-multilibada yet or not by the way? Otherwise I suspect this issue will become a real FAQ. Arno -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37993
[Bug ada/37993] [4.4 Regression] bootstrap with ada fails: a-direct.ads:426:09: alignment for "Search_Typeb82s" must be at least 8
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Keywords||build Summary|bootstrap with ada fails: a-|[4.4 Regression] bootstrap |direct.ads:426:09: alignment|with ada fails: a- |for "Search_Typeb82s" must |direct.ads:426:09: alignment |be at least 8 |for "Search_Typeb82s" must ||be at least 8 Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37993
[Bug tree-optimization/37991] [4.4 Regression] excessive memory consumption - possible hang
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-11-02 10:42 --- Confirmed. We seem to be very slowly eating all of memory during processing a single SCC in FRE - which means iteration doesn't converge. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Component|c++ |tree-optimization Ever Confirmed|0 |1 GCC host triplet|suse-linux-x86_64 | GCC target triplet||i?86-*-*, x86_64-*-* Keywords||compile-time-hog, memory-hog Known to work||4.3.2 Priority|P3 |P1 Last reconfirmed|-00-00 00:00:00 |2008-11-02 10:42:12 date|| Summary|excessive memory consumption|[4.4 Regression] excessive |- possible hang |memory consumption - ||possible hang Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37991
[Bug c/37990] -Os produces redundant instructions
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-11-02 10:33 --- What exactly do you mean with redundant stack manipulation? Note that the ABI requires the stack to be aligned properly at function entry which makes stack adjustment necessary before the call. Note also that you can use -maccumulate-outgoing-args to reduce the number of stack operations, but that may cause bigger code in some cases. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37990
[Bug c/37995] New: using fails if gcc invoked in a directory which has a subdirectory called "gcc"
I tried to compile the following trivial program, called 'hello.c':
#include
int main(void)
{
printf("hello, world!\n");
return 0;
}
using gcc, in a directory which had a subdirectory called "gcc". This caused
the compile to fail with the following output:
> gcc hello.c
In file included from hello.c:1:
/usr/include/stdio.h:34:21: error: stddef.h: No such file or directory
In file included from /usr/include/stdio.h:75,
from hello.c:1:
/usr/include/libio.h:53:21: error: stdarg.h: No such file or directory
In file included from /usr/include/stdio.h:75,
from hello.c:1:
/usr/include/libio.h:332: error: expected specifier-qualifier-list before
size_t
/usr/include/libio.h:364: error: expected declaration specifiers or ...
before size_t
/usr/include/libio.h:373: error: expected declaration specifiers or ...
before size_t
/usr/include/libio.h:489: error: expected declaration specifiers or ...
before __gnuc_va_list
/usr/include/libio.h:491: error: expected declaration specifiers or ...
before __gnuc_va_list
/usr/include/libio.h:493: error: expected =, ,, ;, asm or
__attribute__ before _IO_sgetn
In file included from hello.c:1:
/usr/include/stdio.h:312: error: expected declaration specifiers or ...
before size_t
/usr/include/stdio.h:319: error: expected declaration specifiers or ...
before size_t
/usr/include/stdio.h:347: error: expected declaration specifiers or ...
before __gnuc_va_list
/usr/include/stdio.h:352: error: expected declaration specifiers or ...
before __gnuc_va_list
/usr/include/stdio.h:355: error: expected declaration specifiers or ...
before __gnuc_va_list
/usr/include/stdio.h:361: error: expected declaration specifiers or ...
before size_t
/usr/include/stdio.h:363: error: format string argument not a string type
/usr/include/stdio.h:365: error: expected declaration specifiers or ...
before size_t
/usr/include/stdio.h:366: error: expected declaration specifiers or ...
before __gnuc_va_list
/usr/include/stdio.h:367: error: format string argument not a string type
/usr/include/stdio.h:678: error: expected =, ,, ;, asm or
__attribute__ before fread
/usr/include/stdio.h:684: error: expected =, ,, ;, asm or
__attribute__ before fwrite
/usr/include/stdio.h:706: error: expected =, ,, ;, asm or
__attribute__ before fread_unlocked
/usr/include/stdio.h:708: error: expected =, ,, ;, asm or
__attribute__ before fwrite_unlocked
The compile works fine if there is no subdirectory called "gcc". Although this
seems trivial, some programs' source code do indeed have subdirectories called
"gcc" and this causes them to fail to compile. I don't know if this is
intended behavior or not, but I can't find any information about it in the gcc
documentation. This compile was on an up-to-date Arch Linux system with gcc
4.2.3 which I compiled myself from source. I have tried it on a Mac Pro using
gcc 4.0.1 and the problem does not manifest in that version. gcc 4.2.3 was
built with standard compilation options; the only non-standard configure option
was --enable-languages=c,c++,objc and there were no options used for make or
make install.
If the -save-temps option is passed to gcc:
> gcc -save-temps hello.c
the result is:
> gcc -save-temps hello.c
In file included from hello.c:1:
/usr/include/stdio.h:34:21: error: stddef.h: No such file or directory
In file included from /usr/include/stdio.h:75,
from hello.c:1:
/usr/include/libio.h:53:21: error: stdarg.h: No such file or directory
and when gcc is run on hello.i, the errors output are the same as those above.
Interestingly, when I manually invoke cpp to generate hello.i:
> cpp hello.c > hello.i
> gcc hello.i
there are no errors and the a.out file generated works as intended. This is
with cpp version 4.2.3, created in the same compile as that which created gcc.
However, substituting gcc -E for cpp doesn't work:
> gcc -E hello.c > hello.i
In file included from hello.c:1:
/usr/include/stdio.h:34:21: error: stddef.h: No such file or directory
In file included from /usr/include/stdio.h:75,
from hello.c:1:
/usr/include/libio.h:53:21: error: stdarg.h: No such file or directory
--
Summary: using fails if gcc invoked in a directory
which has a subdirectory called "gcc"
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mvanier at cs dot caltech dot edu
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=37995
