[Bug c/53871] Please warn about endless loops if they are obvious

[manu at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53871

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #1 from Manuel López-Ibáñez  2012-07-07 
07:11:23 UTC ---
(In reply to comment #0)
> Obvious endless loops could be reported, e.g. if the loop condition doesn't
> change and the loop can't be left otherwise.

There has been discussions about this since more than ten years ago and nothing
has happened:

http://gcc.gnu.org/ml/gcc/1999-08n/msg00720.html

My understanding is that the probability of an existing GCC dev implementing
this is very close to zero for various reasons: People are busy with other
things, not trivial to implement for non-trivial code, risk of being too noisy,
and there are other tools better at this job like splint and Clang's static
analyzer.

I can see some advantages in implementing this in GCC (sharing code, working in
any GCC FE), but those are not enough to make current developers drop what they
are doing and put time and effort on this.

So someone else will have to step up to the task. I suggest that you implement
it as a plugin and demonstrate that it works and it is not too noisy.

[Bug middle-end/53884] New: [4.7/4.8 Regression] ICE: in function_and_variable_visibility, at ipa.c:818 with -flto -fno-weak

[zsojka at seznam dot cz]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53884

 Bug #: 53884
   Summary: [4.7/4.8 Regression] ICE: in
function_and_variable_visibility, at ipa.c:818 with
-flto -fno-weak
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz


Created attachment 27757
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27757
reduced testcase

Compiler output:
$ gcc -flto -fno-weak testcase.C 
testcase.C:9:12: internal compiler error: in function_and_variable_visibility,
at ipa.c:818
 S < foo > s;
^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Tested revisions:
r189247 - crash
4.7 r188682 - crash
4.6 r188682 - OK
4.5 r188682 - OK

[Bug fortran/53885] New: seg. fault during assignment to allocatable component withing type-bounded proc.

[wangmianzhi1 at linuxmail dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53885

 Bug #: 53885
   Summary: seg. fault during assignment to allocatable component
withing type-bounded proc.
Classification: Unclassified
   Product: gcc
   Version: 4.6.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: wangmianz...@linuxmail.org


Assignment within the type-bounded procedure to an UN-allocated component
causes seg. fault.
It seems, according to 7.2.1.2 & 7.2.1.3 of f2008 standard, the assignment to
unallocated item of intrinsic type should be valid.
Such assignment works if not within a type-bounded procedure.
The attached is a reduced example.

[Bug fortran/53885] seg. fault during assignment to allocatable component withing type-bounded proc.

[wangmianzhi1 at linuxmail dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53885

--- Comment #1 from wangmianzhi  2012-07-07 
12:08:03 UTC ---
Created attachment 27758
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27758
a reduced example

[Bug c++/53882] [4.7/4.8 Regression] ICE in type_contains_placeholder_1, at tree.c:3015

[hjl.tools at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53882

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2012-07-07
 Ever Confirmed|0   |1

--- Comment #2 from H.J. Lu  2012-07-07 12:34:48 
UTC ---
Works for me on Linux/x86-64 with GCC 4.7 revision 189343 and
trunk revision 189334.

[Bug tree-optimization/53881] [4.8 regression] ICE in hoist_edge_and_branch_if_true

[steven at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53881

--- Comment #5 from Steven Bosscher  2012-07-07 
12:35:49 UTC ---
Author: steven
Date: Sat Jul  7 12:35:44 2012
New Revision: 189349

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=189349
Log:
gcc/
PR tree-optimization/53881
* tree-switch-conversion.c (emit_case_bit_tests): Do not rely on
comparing labels to establish uniqueness of a switch case target,
use the CFG instead.

testsuite/
PR tree-optimization/53881
* gcc.dg/pr53881.c: New test.


Added:
trunk/gcc/testsuite/gcc.dg/pr53881.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-switch-conversion.c

[Bug tree-optimization/53881] [4.8 regression] ICE in hoist_edge_and_branch_if_true

[steven at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53881

Steven Bosscher  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #6 from Steven Bosscher  2012-07-07 
12:41:48 UTC ---
.

[Bug driver/53883] GCC 4.7.1 doesn't build on Mac OS X 10.4.11 Tiger/PowerPC (32-bit)

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53883

--- Comment #2 from Jonathan Wakely  2012-07-07 
12:46:54 UTC ---
(In reply to comment #0)
> (Should I try building GCC 4.7.1 straight from you guys, without going through
> MacPorts?)

Yes, probably.

[Bug middle-end/53884] [4.7/4.8 Regression] ICE: in function_and_variable_visibility, at ipa.c:818 with -flto -fno-weak

[hjl.tools at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53884

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-07-07
 CC||hubicka at gcc dot gnu.org
 Ever Confirmed|0   |1

--- Comment #1 from H.J. Lu  2012-07-07 13:47:27 
UTC ---
It is caused by revision 174952:

http://gcc.gnu.org/ml/gcc-cvs/2011-06/msg00441.html

[Bug debug/53235] [4.8 Regression] 20120504 broke -fdebug-types-section

[jason at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53235

--- Comment #9 from Jason Merrill  2012-07-07 
14:13:38 UTC ---
(In reply to comment #8)
> -fdebug-types-section regresses static scope of types
> http://sourceware.org/bugzilla/show_bug.cgi?id=14148
> 
> suggests the stub DW_TAG_struct_type should not have DW_AT_declaration as we
> need definition of the type at its proper scope.

We have had declarations at the type's proper scope and definitions at CU scope
for a very long time, and moving the definition to a type unit should work
similarly.  But I'm currently not putting a name on the stub to save space;
would giving it a DW_AT_name make a difference?

[Bug target/53886] New: Seg fault in sh_insn_length_adjustment

[rmansfield at qnx dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53886

 Bug #: 53886
   Summary: Seg fault in sh_insn_length_adjustment
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: rmansfi...@qnx.com
  Host: x86_64-linux-gnu
Target: sh4-unknown-linux-gnu
 Build: x86_64-linux-gnu


$ ./xgcc -v
Using built-in specs.
COLLECT_GCC=./xgcc
Target: sh4-unknown-linux-gnu
Configured with: ../configure --target=sh4-unknown-linux-gnu
--prefix=/home/ryan/x-tools/sh4-unknown-linux-gnuc
--with-local-prefix=/home/ryan/x-tools/sh4-unknown-linux-gnu/sh4-unknown-linux-gnu/sys-root
--disable-multilib
--with-sysroot=/home/ryan/x-tools/sh4-unknown-linux-gnu/sh4-unknown-linux-gnu/sys-root
--with-newlib --enable-threads=no --disable-shared --enable-__cxa_atexit
--disable-nls --enable-symvers=gnu --enable-languages=c
--enable-target-optspace --enable-checking --disable-libmudflap
--disable-libssp
Thread model: single
gcc version 4.8.0 20120707 (experimental) [trunk revision 189349] (GCC) 

$ ./xgcc -B. /home/ryan/r.i -c -Os
/home/ryan/r.i: In function 'i2d_ECPrivateKey':
/home/ryan/r.i:31:17: warning: assignment makes pointer from integer without a
cast [enabled by default]
   if ((priv_key = EC_PRIVATEKEY_new ()) == 0)
 ^
/home/ryan/r.i:47:6: warning: initialization makes pointer from integer without
a cast [enabled by default]
  CRYPTO_realloc ((char *) buffer, (int) tmp_len, "", 1293);
  ^
/home/ryan/r.i:60:1: internal compiler error: Segmentation fault
 }
 ^
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.

(gdb) bt
#0  0x00abcab6 in sh_insn_length_adjustment (insn=0x77053168)
at ../../gcc/config/sh/sh.c:9665
#1  0x0066d00c in get_attr_length_1 (fallback_fn=, 
insn=0x77053168) at ../../gcc/final.c:433
#2  get_attr_length (insn=0x77053168) at ../../gcc/final.c:448
#3  0x00ac6e1b in get_attr_in_delay_slot (insn=0x77053168)
at ../../gcc/config/sh/sh.md:241
#4  0x00ac6fc6 in get_attr_cond_delay_slot (insn=0x77053168)
at ../../gcc/config/sh/sh.md:239
#5  0x00aca638 in eligible_for_annul_true (delay_insn=0x770507d0, 
slot=4, candidate_insn=0x77053168, flags=)
at ../../gcc/config/sh/sh.md:444
#6  0x00825f8e in optimize_skip (insn=0x770507d0)
at ../../gcc/reorg.c:864
#7  fill_simple_delay_slots (non_jumps_p=0) at ../../gcc/reorg.c:2201
#8  0x00826c71 in dbr_schedule (first=0x77042f40)
at ../../gcc/reorg.c:3931
#9  0x00828640 in rest_of_handle_delay_slots ()
at ../../gcc/reorg.c:4115
#10 0x007d5a17 in execute_one_pass (pass=0x108a600)
at ../../gcc/passes.c:2165
---Type  to continue, or q  to quit---
#11 0x007d5d85 in execute_pass_list (pass=0x108a600)
at ../../gcc/passes.c:2220
#12 0x007d5d97 in execute_pass_list (pass=0x1089aa0)
at ../../gcc/passes.c:2221
#13 0x007d5d97 in execute_pass_list (pass=0x1089a40)
at ../../gcc/passes.c:2221
#14 0x005af9ac in expand_function (node=0x77043000)
at ../../gcc/cgraphunit.c:1615
#15 0x005b13ea in expand_all_functions ()
at ../../gcc/cgraphunit.c:1720
#16 compile () at ../../gcc/cgraphunit.c:2018
#17 0x005b1d65 in finalize_compilation_unit ()
at ../../gcc/cgraphunit.c:2095
#18 0x0049fbe8 in c_write_global_declarations ()
at ../../gcc/c/c-decl.c:10116
#19 0x0088158d in compile_file () at ../../gcc/toplev.c:564
#20 0x00883134 in do_compile () at ../../gcc/toplev.c:1867
#21 toplev_main (argc=10, argv=0x7fffe118) at ../../gcc/toplev.c:1943
#22 0x7715c76d in __libc_start_main ()
   from /lib/x86_64-linux-gnu/libc.so.6
#23 0x00483011 in _start ()

[Bug middle-end/53887] New: ICE in hoist_edge_and_branch_if_true, at tree-switch-conversion.c:79

[rmansfield at qnx dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53887

 Bug #: 53887
   Summary: ICE in hoist_edge_and_branch_if_true, at
tree-switch-conversion.c:79
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: rmansfi...@qnx.com
  Host: x86_64-unknown-linux-gnu
Target: x86_64-unknown-linux-gnu
 Build: x86_64-unknown-linux-gnu


Created attachment 27759
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27759
preprocessed src

$ ./xgcc -v
Using built-in specs.
COLLECT_GCC=./xgcc
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --disable-bootstrap --enable-languages=c
Thread model: posix
gcc version 4.8.0 20120707 (experimental) [trunk revision 189349] (GCC) 

$ ./xgcc -B. ~/t.i -O2
/home/ryan/t.i: In function ‘fdc_setup’:
/home/ryan/t.i:51:1: internal compiler error: in hoist_edge_and_branch_if_true,
at tree-switch-conversion.c:79
 }
 ^
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.

[Bug libstdc++/53578] include/ext/concurrence.h relies on ill-formed narrowing conversions

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53578

--- Comment #13 from Jonathan Wakely  2012-07-07 
18:13:24 UTC ---
Author: redi
Date: Sat Jul  7 18:13:19 2012
New Revision: 189351

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=189351
Log:
PR libstdc++/53578
* include/ext/concurrence.h (__recursive_mutex::_S_destroy): Fix
narrowing conversion.
* include/std/mutex (__recursive_mutex_base::_S_destroy): Likewise.

Modified:
branches/gcc-4_7-branch/libstdc++-v3/ChangeLog
branches/gcc-4_7-branch/libstdc++-v3/include/ext/concurrence.h
branches/gcc-4_7-branch/libstdc++-v3/include/std/mutex

[Bug target/53888] New: gthr-win32.h defines __gthread_mutex_destroy with wrong return type

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53888

 Bug #: 53888
   Summary: gthr-win32.h defines __gthread_mutex_destroy with
wrong return type
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: r...@gcc.gnu.org
Target: *-mingw32


gthr.h documents the required function

 int __gthread_mutex_destroy (__gthread_mutex_t *mutex);

but gthr-win32.h defines:

static inline void
__gthread_mutex_destroy (__gthread_mutex_t *__mutex)
{
  __gthr_win32_mutex_destroy (__mutex);
}

This means code using __gthread_mutex_destroy can't check the return value, as
it would fail to compile on Windows.

[Bug libstdc++/53578] include/ext/concurrence.h relies on ill-formed narrowing conversions

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53578

--- Comment #14 from Jonathan Wakely  2012-07-07 
18:35:58 UTC ---
Author: redi
Date: Sat Jul  7 18:35:52 2012
New Revision: 189352

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=189352
Log:
PR libstdc++/53578
* include/ext/concurrence.h (__recursive_mutex::_S_destroy): Fix
narrowing conversion.
* include/std/mutex (__recursive_mutex_base::_S_destroy): Likewise.

Modified:
branches/gcc-4_6-branch/libstdc++-v3/ChangeLog
branches/gcc-4_6-branch/libstdc++-v3/include/ext/concurrence.h
branches/gcc-4_6-branch/libstdc++-v3/include/std/mutex

[Bug libstdc++/53578] include/ext/concurrence.h relies on ill-formed narrowing conversions

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53578

Jonathan Wakely  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||FIXED

--- Comment #14 from Jonathan Wakely  2012-07-07 
18:35:58 UTC ---
Author: redi
Date: Sat Jul  7 18:35:52 2012
New Revision: 189352

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=189352
Log:
PR libstdc++/53578
* include/ext/concurrence.h (__recursive_mutex::_S_destroy): Fix
narrowing conversion.
* include/std/mutex (__recursive_mutex_base::_S_destroy): Likewise.

Modified:
branches/gcc-4_6-branch/libstdc++-v3/ChangeLog
branches/gcc-4_6-branch/libstdc++-v3/include/ext/concurrence.h
branches/gcc-4_6-branch/libstdc++-v3/include/std/mutex

--- Comment #15 from Jonathan Wakely  2012-07-07 
18:36:27 UTC ---
This should be fixed on all active branches then.

[Bug libstdc++/53578] include/ext/concurrence.h relies on ill-formed narrowing conversions

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53578

Jonathan Wakely  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||FIXED

--- Comment #15 from Jonathan Wakely  2012-07-07 
18:36:27 UTC ---
This should be fixed on all active branches then.

[Bug target/53888] gthr-win32.h defines __gthread_mutex_destroy with wrong return type

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53888

--- Comment #1 from Jonathan Wakely  2012-07-07 
18:39:45 UTC ---
Untested patch

diff --git a/libgcc/config/i386/gthr-win32.h b/libgcc/config/i386/gthr-win32.h
index 53f8396..f2dded2 100644
--- a/libgcc/config/i386/gthr-win32.h
+++ b/libgcc/config/i386/gthr-win32.h
@@ -474,6 +474,7 @@ static inline void
 __gthread_mutex_destroy (__gthread_mutex_t *__mutex)
 {
   __gthr_win32_mutex_destroy (__mutex);
+  return 0;
 }

 static inline int
@@ -635,6 +636,7 @@ static inline void
 __gthread_mutex_destroy (__gthread_mutex_t *__mutex)
 {
   CloseHandle ((HANDLE) __mutex->sema);
+  return 0;
 }

 static inline int

[Bug other/53889] New: Gthreads doesn't support destroying recursive mutexes

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53889

 Bug #: 53889
   Summary: Gthreads doesn't support destroying recursive mutexes
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: r...@gcc.gnu.org


There is no __gthread_recursive_mutex_destroy function in the gthreads API.

Using __gthread_mutex_destroy fails to compile on platforms where the mutex
types are different. This means to avoid resource leaks libstdc++ needs to hack
around it with:

// FIXME: gthreads doesn't define __gthread_recursive_mutex_destroy
// so we need to obtain a __gthread_mutex_t to destroy
  private:
template
  static void
  _S_destroy_win32(_Mx* __mx, _Rm const* __rmx)
  {
__mx->counter = __rmx->counter;
__mx->sema = __rmx->sema;
__gthread_mutex_destroy(__mx);
  }

// matches a gthr-win32.h recursive mutex
template
  static typename __enable_if<(bool)sizeof(&_Rm::sema), void>::__type
  _S_destroy(_Rm* __mx)
  {
__gthread_mutex_t __tmp;
_S_destroy_win32(&__tmp, __mx);
  }

// matches a recursive mutex with a member 'actual'
template
  static typename __enable_if<(bool)sizeof(&_Rm::actual), void>::__type
  _S_destroy(_Rm* __mx)
  { __gthread_mutex_destroy(&__mx->actual); }

// matches when there's only one mutex type
template
  static typename
  __enable_if::__value,
void>::__type
  _S_destroy(_Rm* __mx)
  { __gthread_mutex_destroy(__mx); }


Gthreads should define __gthread_recursive_mutex_destroy

[Bug other/53889] Gthreads doesn't support destroying recursive mutexes

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53889

--- Comment #1 from Jonathan Wakely  2012-07-07 
18:50:29 UTC ---
Created attachment 27760
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27760
Add __gthread_recursive_mutex_destroy.

Untested.

[Bug c/53890] New: bogus array bounds warning

[nathan at acm dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53890

 Bug #: 53890
   Summary: bogus array bounds warning
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: nat...@acm.org


Created attachment 27761
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27761
test case

compile the attached with:
./cc1 ary.cc -O2 -Wall -quiet

(don't worry that it's a .cc file, I found the bug in c++ code, but it
manifests in both C and C++ compilers)

see following warning:

ary.cc: In function 'Foo':
ary.cc:12:6: warning: array subscript is above array bounds [-Warray-bounds]
   tmp[jx] = 4;
  ^

This is incorrect, the compiler cannot deduce that jx is out of range at this
point -- indeed in correct calls of Foo it won't be.

[Bug c/53890] bogus array bounds warning

[pinskia at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53890

--- Comment #1 from Andrew Pinski  2012-07-07 
21:27:27 UTC ---
What happens here is that we do a jump threading for the case where words == 0
which produces an out of bounds array reference.

[Bug other/53891] New: CFLAGS set in configure don't propagate

[jimis at gmx dot net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53891

 Bug #: 53891
   Summary: CFLAGS set in configure don't propagate
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: other
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ji...@gmx.net


In a standard autotooled application it is only necessary to set CFLAGS on the
./configure command or in the environment. In gcc this is not enough, and at
least BOOT_CFLAGS needs to be set on the make command line. For example the
following is not enough:

$ CFL="-O0 -g3 -fno-inline -march=i586"
$ export -p | grep FLAG
declare -x BOOT_CFLAGS="-O0 -g3 -fno-inline -march=i586"
declare -x BOOT_CXXFLAGS="-O0 -g3 -fno-inline -march=i586"
declare -x CFLAGS="-O0 -g3 -fno-inline -march=i586"
declare -x CXXFLAGS="-O0 -g3 -fno-inline -march=i586"
$ ~/path/to/gcc/configure --prefix=`pwd` --enable-checking=release
--disable-multilib --disable-plugins --enable-languages=c,c++ CFLAGS="$CFL"
BOOT_CFLAGS="$CFL" CXXFLAGS="$CFL" BOOT_CXXFLAGS="$CFL"
$ make

And I need this to actually get a final gcc compiled with my flags:

$ make BOOT_CFLAGS="$CFL" BOOT_CXXFLAGS="$CFL"


I think we should require setting the flags only on ./configure, and it would
also be nice if CFLAGS propagated aumatically to CXXFLAGS.

[Bug other/53891] CFLAGS set in configure don't propagate

[pinskia at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53891

--- Comment #1 from Andrew Pinski  2012-07-08 
03:05:56 UTC ---
If you want a debuggable GCC there is a better way than using CFLAGS and
BOOT_CFLAGS and without using --disable-bootstrap.  Do the following:
configure for a normal build
make all-gcc
cd gcc
make clean
make all

[Bug libfortran/49970] "make prefix=... install" doesn't work

[jimis at gmx dot net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49970

jimis  changed:

   What|Removed |Added

 Status|RESOLVED|VERIFIED

--- Comment #7 from jimis  2012-07-08 03:26:07 UTC ---
I'm really tired of invalidating whole builds by reconfiguring just to install
in a separate dir. I'm reopening this as a wishlist. 

Joseph: where can I track this for upstream libtool? I remember I had pinged
the libtool ML back then, but got no feedback.

[Bug libfortran/49970] "make prefix=... install" doesn't work

[jimis at gmx dot net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49970

jimis  changed:

   What|Removed |Added

   Severity|normal  |enhancement

--- Comment #8 from jimis  2012-07-08 03:30:45 UTC ---
It seems I can't reopen it, but this bug certainly isn't INVALID. It could be a
bug in libtool, but it manifests itself clearly in GCC.