[Bug rtl-optimization/54294] [4.8 Regression]: [alpha] Bootstrap comparison failure due to fwprop handling of debug insns

[ubizjak at gmail dot com]

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

--- Comment #3 from Uros Bizjak  2012-08-17 08:10:07 
UTC ---
(In reply to comment #1)
> Created attachment 28040 [details]
> Preprocessed source of the object file that triggers comparison failure
> 
> ~/gcc-build/stage1-gcc/xgcc -B ~/gcc-build/stage1-gcc -O2 -fno-exceptions
> -fno-rtti -fno-common -fcompare-debug cprop.ii
> xgcc: error: cprop.ii: -fcompare-debug failure (length)

Adding -fno-forward-propagate to the above flags fixes compare-debug failure.

[Bug rtl-optimization/54294] [4.8 Regression]: [alpha] Bootstrap comparison failure due to fwprop handling of debug insns

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2012-08-17
 CC||jakub at gcc dot gnu.org
 AssignedTo|unassigned at gcc dot   |jakub at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

--- Comment #4 from Jakub Jelinek  2012-08-17 
08:39:24 UTC ---
Looking into it.

[Bug fortran/54285] [F03] Calling a PPC with proc-ptr result

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2012-08-17
 AssignedTo|unassigned at gcc dot   |janus at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

--- Comment #2 from janus at gcc dot gnu.org 2012-08-17 08:59:13 UTC ---
The error message mentioned in comment 1 can be fixed by this additional hunk:


Index: gcc/fortran/expr.c
===
--- gcc/fortran/expr.c(revision 190419)
+++ gcc/fortran/expr.c(working copy)
@@ -3504,8 +3504,16 @@ gfc_check_pointer_assign (gfc_expr *lvalue, gfc_ex
   comp = gfc_get_proc_ptr_comp (rvalue);
   if (comp)
 {
-  s2 = comp->ts.interface;
-  name = comp->name;
+  if (rvalue->expr_type == EXPR_FUNCTION)
+{
+  s2 = comp->ts.interface->result;
+  name = comp->ts.interface->result->name;
+}
+  else
+{
+  s2 = comp->ts.interface;
+  name = comp->name;
+}
 }
   else if (rvalue->expr_type == EXPR_FUNCTION)
 {

[Bug middle-end/54146] Very slow compile with attribute((flatten))

[steven at gcc dot gnu.org]

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

--- Comment #54 from Steven Bosscher  2012-08-17 
09:42:15 UTC ---
Author: steven
Date: Fri Aug 17 09:42:06 2012
New Revision: 190475

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190475
Log:
PR middle-end/54146
* tree-ssa-loop-im.c (lim_bitmap_obstack): New bitmap_obstack.
(memref_free): Don't free the bitmaps individually here.
(mem_ref_alloc): Allocate the bitmaps on the new bitmap obstack.
(analyze_memory_references): Likewise.
(tree_ssa_lim_initialize): Initialize the new bitmap obstack.
(tree_ssa_lim_finalize): Release it.
* dse.c (dse_bitmap_obstack): New bitmap obstack.
(dse_obstack): New obstack.
(get_group_info): Allocate the bitmaps on the new bitmap obstack.
(dse_step0): Allocate the scratch bitmap on reg_obstack.  Initialize
the new bitmap obstack and normal obstack.  Use XNEWVEC for bb_table.
(record_store): Allocate regs_set on reg_obstack.
(dse_step1): Allocate regs_live on reg_obstack.
(dse_step2_init): Allocate offset_map_n and offset_map_p on the new
obstack.
(dse_step3_scan): Allocate bitmaps on the new bitmap obstack.
(dse_step3): Likewise.
(dse_confluence_0): Likewise.
(dse_confluence_n): Likewise.
(dse_transfer_function): Likewise.
(dse_step7): Destroy the new obstacks, and everything allocated on
them, in one big sweep.
(rest_of_handle_dse): Update.
* cfgexpand.c (stack_var_bitmap_obstack): New bitmap obstack.
(add_stack_var_conflict): Allocate bitmaps on it.
(add_scope_conflicts_1): Likewise.
(add_scope_conflicts): Likewise.
(update_alias_info_with_stack_vars): Likewise.
(init_vars_expansion): Move TREE_USED fiddling expand_used_vars.
Initialize the new bitmap obstack.
(fini_vars_expansion): Release it.
(estimated_stack_frame_size): Use init_vars_expansion to set things up
and always clean up at the end.
(expand_used_vars): Do the TREE_USED trickery here.  Always call
fini_vars_expansion.
* tree-ssa-live.h (struct tree_live_info_d): Make livein and liveout
arrays of bitmap_head to avoid one indirection per bitmap access.
(live_on_entry, live_on_exit, live_var_map, live_merge_and_clear,
make_live_on_entry): Update.
* tree-ssa-live.c (partition_view_bitmap): Don't double-free 'used'.
(liveness_bitmap_obstack): New bitmap obstack.
(remove_unused_locals): Use it to allocate all bitmaps on.  Update
for livein/liveout changes in tree-ssa-live.h.
(delete_tree_live_info): Release the bitmap obstack.
(loe_visit_block, live_worklist, set_var_live_on_entry,
calculate_live_on_exit, dump_live_info): Update.
(calculate_live_ranges): Initialize the bitmap.
* tree-ssa-ter.c (ter_bitmap_obstack): New bitmap obstack.
(new_temp_expr_table): Allocate bitmap on it.
(make_dependent_on_partition, add_to_partition_kill_list,
add_dependence, process_replaceable): Likewise.
(find_replaceable_exprs): Initialize and release the new obstack here.
* df-problems.c (df_lr_add_problem): Allocate persistent bitmap
for out_of_date_transfer_functions on df_bitmap_obstack.
(df_live_add_problem): Likewise.
(df_chain_add_problem): Likewise.
(df_word_lr_add_problem): Likewise.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/cfgexpand.c
trunk/gcc/df-problems.c
trunk/gcc/dse.c
trunk/gcc/tree-ssa-live.c
trunk/gcc/tree-ssa-live.h
trunk/gcc/tree-ssa-loop-im.c
trunk/gcc/tree-ssa-loop-manip.c
trunk/gcc/tree-ssa-ter.c

[Bug rtl-optimization/54294] [4.8 Regression]: [alpha] Bootstrap comparison failure due to fwprop handling of debug insns

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||bonzini at gnu dot org
   Target Milestone|--- |4.8.0

[Bug rtl-optimization/54294] [4.8 Regression]: [alpha] Bootstrap comparison failure due to fwprop handling of debug insns

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  2012-08-17 
10:29:20 UTC ---
Created attachment 28041
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28041
gcc48-pr54294.patch

Seems my other PR42728 patch fixes the -fcompare-debug failure and is IMHO
desirable in any case.  What is going on here is that we have:
(insn 14254 14253 512 423 (set (reg:DI 1196 [ ei ])
(sign_extend:DI (subreg:SI (reg:DI 1196 [ ei ]) 0))) 2 {*extendsidi2_1}
 (nil))
insn where (subreg:SI (reg:DI 1196 [ ei ]) 0) is replaced by (reg:SI 2915). 
But fwprop is df_set_flags (DF_DEFER_INSN_RESCAN);.  When replacing the next
insn,
which without -g turns to be another set, but with -g there are several debug
insns in between and next insn is the first of them, we take a shortcut.  As
rescan is deferred, we see both 1196 and 2915 regs as "uses" of def_insn.  The
shortcut performs a rtx_equal_p check on DF_REF_REG (use) which fails though,
as DF_REF_REG (use) is the subreg, thus we replace the subreg in the
immediately following insn.  But when trying to replace it in following debug
insns and with -g in the first following non-debug insn, it is not NEXT_INSN,
shortcut is not taken and we do both the rtx_equal_p check (fine, DF_REF_REG is
again a subreg), but also do use_killed_between including def_insn, and that
calls local_ref_killed_between_p, which compares DF_REF_REGNO instead of using
rtx_equal_p and therefore says that the (already non-existing) use in def_insn
is killed by the set in the def_insn.

So, IMHO we should possibly replace the rtx_equal_p checks with simple
DF_REF_REGNO comparisons instead, which will be more conservatively correct,
but we risk code quality regressions.

So, perhaps another thing to do could be that when walking uses of def_insn in
all_uses_available_at, we'd double check if the reg in question is really still
used in the insn pattern (perhaps conditionally on whether the insn is still
marked for rescanning or not).

[Bug fortran/54285] [F03] Calling a PPC with proc-ptr result

[janus at gcc dot gnu.org]

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

--- Comment #3 from janus at gcc dot gnu.org 2012-08-17 11:00:26 UTC ---
The combined patches of comment 1 and 2 regtest cleanly.

[Bug rtl-optimization/54294] [4.8 Regression]: [alpha] Bootstrap comparison failure due to fwprop handling of debug insns

[ubizjak at gmail dot com]

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

--- Comment #6 from Uros Bizjak  2012-08-17 11:14:45 
UTC ---
(In reply to comment #5)
> Created attachment 28041 [details]
> gcc48-pr54294.patch

This patch fixes the debug-compare failure with testcase on alpha. I am running
bootstrap now.

[Bug bootstrap/54292] [4.8 Regression] Errors due to conflicting strsignal headers

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.8.0

--- Comment #3 from Richard Guenther  2012-08-17 
12:28:54 UTC ---
Offending patch has been reverted.

[Bug bootstrap/54292] [4.8 Regression] Errors due to conflicting strsignal headers

[tobi at gcc dot gnu.org]

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

--- Comment #4 from Tobias Schlüter  2012-08-17 
12:31:13 UTC ---
Yes, I now see a new failure that also strikes me as fairly weird (again, I'm
using an in-tree gmp, mpfr, mpc):

/Users/tobi/src/gcc/build/./prev-gcc/g++
-B/Users/tobi/src/gcc/build/./prev-gcc/
-B/usr/local/x86_64-apple-darwin11.4.0/bin/ -nostdinc++
-B/Users/tobi/src/gcc/build/prev-x86_64-apple-darwin11.4.0/libstdc++-v3/src/.libs
-B/Users/tobi/src/gcc/build/prev-x86_64-apple-darwin11.4.0/libstdc++-v3/libsupc++/.libs
-I/Users/tobi/src/gcc/build/prev-x86_64-apple-darwin11.4.0/libstdc++-v3/include/x86_64-apple-darwin11.4.0
-I/Users/tobi/src/gcc/build/prev-x86_64-apple-darwin11.4.0/libstdc++-v3/include
-I/Users/tobi/src/gcc/libstdc++-v3/libsupc++
-L/Users/tobi/src/gcc/build/prev-x86_64-apple-darwin11.4.0/libstdc++-v3/src/.libs
-L/Users/tobi/src/gcc/build/prev-x86_64-apple-darwin11.4.0/libstdc++-v3/libsupc++/.libs
  -g -O2 -mdynamic-no-pic -gtoggle -DIN_GCC   -fno-exceptions -fno-rtti -W
-Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute
-pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror
-fno-common  -DHAVE_CONFIG_H -static-libstdc++ -static-libgcc -Wl,-no_pie -o
f951 \
fortran/arith.o fortran/array.o fortran/bbt.o fortran/check.o
fortran/class.o fortran/constructor.o fortran/cpp.o fortran/data.o
fortran/decl.o fortran/dump-parse-tree.o fortran/error.o fortran/expr.o
fortran/interface.o fortran/intrinsic.o fortran/io.o fortran/iresolve.o
fortran/match.o fortran/matchexp.o fortran/misc.o fortran/module.o
fortran/openmp.o fortran/options.o fortran/parse.o fortran/primary.o
fortran/resolve.o fortran/scanner.o fortran/simplify.o fortran/st.o
fortran/symbol.o fortran/target-memory.o darwin-f.o fortran/convert.o
fortran/dependency.o fortran/f95-lang.o fortran/trans.o fortran/trans-array.o
fortran/trans-common.o fortran/trans-const.o fortran/trans-decl.o
fortran/trans-expr.o fortran/trans-intrinsic.o fortran/trans-io.o
fortran/trans-openmp.o fortran/trans-stmt.o fortran/trans-types.o
fortran/frontend-passes.o libbackend.a main.o tree-browser.o libcommon-target.a
libcommon.a ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a libcommon.a
../libcpp/libcpp.a -lintl -L/opt/local/lib -liconv  ../libiberty/libiberty.a
../libdecnumber/libdecnumber.a  attribs.o 
-L/Users/tobi/src/gcc/build/./gmp/.libs
-L/Users/tobi/src/gcc/build/./mpfr/.libs
-L/Users/tobi/src/gcc/build/./mpc/src/.libs -lmpc -lmpfr -lgmp   -L../zlib -lz
Undefined symbols for architecture x86_64:
  "_mpfr_get_z_exp", referenced from:
  gfc_mpfr_to_mpz(__mpz_struct*, __mpfr_struct*, locus*) in arith.o
ld: symbol(s) not found for architecture x86_64
collect2: error: ld returned 1 exit status
make[3]: *** [f951] Error 1
make[2]: *** [all-stage2-gcc] Error 2
make[1]: *** [stage2-bubble] Error 2
make: *** [all] Error 2

Should I open a new PR?

[Bug tree-optimization/54295] New: [4.7 regression] Widening multiply-accumulate operation uses wrong value extension

[rearnsha at gcc dot gnu.org]

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

 Bug #: 54295
   Summary: [4.7 regression] Widening multiply-accumulate
operation uses wrong value extension
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: rearn...@gcc.gnu.org
Target: arm aarch64


A widening multiply-accumulate operation can generate an incorrect result if
there are casts in expression.

Compile the attached test-case on ARM at -O2, the result is:

$./a.out 


Correct result, as seen at -O1 is

$./a.out
$

[Bug tree-optimization/54295] [4.7 regression] Widening multiply-accumulate operation uses wrong value extension

[rearnsha at gcc dot gnu.org]

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

--- Comment #1 from Richard Earnshaw  2012-08-17 
12:47:35 UTC ---
Created attachment 28042
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28042
Testcase

[Bug tree-optimization/54295] [4.7 regression] Widening multiply-accumulate operation uses wrong value extension

[rearnsha at gcc dot gnu.org]

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

--- Comment #2 from Richard Earnshaw  2012-08-17 
12:50:32 UTC ---
Testing a fix

[Bug libstdc++/54296] New: using the object in the map to erase element from the map crashes

[plasmahh at gmx dot net]

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

 Bug #: 54296
   Summary: using the object in the map to erase element from the
map crashes
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: plasm...@gmx.net


I found a crash in my program, which boils down to the following code. (Note
that this does usually not crash, but will be reported by valgrind with invalid
read after free. Also note that depending no possible internals of the bucket
hashing stuff, the value for i where it crashes might change, so you can use
the random part multiple times to figure out a new one)

#include 
#include 
#include 
#include 
#include 
#include 

struct A
{
int x;
};

int main ( )
{
srand(time(0));
std::unordered_map map;
map.max_load_factor(2.0);

for (size_t i = 0; i < 50; ++i)
{
A a;
a.x = i;
map.insert({i,a});
}

//  int i = rand() % map.size();
int i = 47;
std::cout << "i = " << i << "\n";

const A& a = map[i];

map.erase(a.x);
}
// vim: tabstop=4 shiftwidth=4 noexpandtab ft=cpp






This seems to be due to the while condition in hashtable.h:1526 accessing __k
after the _M_deallocate_node(__p) of line 1517

while (__next_bkt == __bkt && this->_M_equals(__k, __code, __next_n));

I think it is better that after the erase of the node, __k should not be
touched anymore as it migh be part of the object being erased.

[Bug tree-optimization/54295] [4.7/4.8 regression] Widening multiply-accumulate operation uses wrong value extension

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Target Milestone|--- |4.7.2
Summary|[4.7 regression] Widening   |[4.7/4.8 regression]
   |multiply-accumulate |Widening
   |operation uses wrong value  |multiply-accumulate
   |extension   |operation uses wrong value
   ||extension

[Bug libstdc++/54296] using the object in the map to erase element from the map crashes

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||fdumont at gcc dot gnu.org

--- Comment #1 from Jonathan Wakely  2012-08-17 
13:17:06 UTC ---
Francois, could you take a look please?  Thanks.

It reminds me of PR 51866, it might be good to review all the code for similar
lifetime issues following deallocation or moving.

[Bug bootstrap/54292] [4.8 Regression] Errors due to conflicting strsignal headers

[tobi at gcc dot gnu.org]

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

--- Comment #5 from Tobias Schlüter  2012-08-17 
13:46:13 UTC ---
It seems the build picks up the wrong mpfr.h header, the function was renamed
in mpfr > 3.0.0, but API compatibility is ensured via a macro, see:


My system mpfr is 3.1.0, but the one inside the compiler tree is 2.4.2.  So it
seems to link against 3.1.0 while using the header from 2.4.2.  I think this is
consistent with the command line flags given.

[Bug c++/54293] When a reference is bound to subobject of a temporary, lifetime of the temporary is not extended

[aaw at gcc dot gnu.org]

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

--- Comment #3 from Ollie Wild  2012-08-17 14:18:59 UTC 
---
No, this is a different failure.  With my patch applied, the testcase still
fails exactly as described.

[Bug rtl-optimization/54294] [4.8 Regression]: [alpha] Bootstrap comparison failure due to fwprop handling of debug insns

[ubizjak at gmail dot com]

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

--- Comment #7 from Uros Bizjak  2012-08-17 14:25:52 
UTC ---
(In reply to comment #6)
> (In reply to comment #5)
> > Created attachment 28041 [details]
> > gcc48-pr54294.patch
> 
> This patch fixes the debug-compare failure with testcase on alpha. I am 
> running
> bootstrap now.

Bootstrap finished OK, all interesting regression test passed on
alphaev68-unknown-linux-gnu.

[Bug c++/54293] When a reference is bound to subobject of a temporary, lifetime of the temporary is not extended

[jpalecek at web dot de]

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

Jiří Paleček  changed:

   What|Removed |Added

 CC||jpalecek at web dot de

--- Comment #4 from Jiří Paleček  2012-08-17 14:54:50 
UTC ---
Is that even a bug? In the standard (8.5.3/5), there is:

— If the initializer expression
— is an xvalue, *class prvalue*, array prvalue or function lvalue and “cv1 T1”
is reference-
compatible with “cv2 T2”, or
— has a class type (i.e., T2 is a class type), where T1 is not
reference-related to T2, and can be
implicitly converted to an xvalue, class prvalue, or function lvalue of type
“cv3 T3”, where
“cv1 T1” is reference-compatible with “cv3 T3”,

I don't think an rvalue of type int (which you have there as the initializer)
is a class prvalue, so the initialization should proceed by the next stanza,
ie. creating a temporary of type int thereby not extending the lifetime of
ValueHolder temporary.

[Bug libstdc++/54297] New: [C++11] Segmentation fault with std::async and released shared state

[ai.azuma at gmail dot com]

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

 Bug #: 54297
   Summary: [C++11] Segmentation fault with std::async and
released shared state
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ai.az...@gmail.com


Created attachment 28043
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28043
Command-line log

The following code causes segfault with GCC 4.8.0 20120812, -std=c++11 and
-pthread.

/
#include 
#include 
#include 

int work()
{
  std::this_thread::sleep_for(std::chrono::seconds(1));
  return 0;
}

int main()
{
  // Note that the following explicitly named future object
  // is not necessary to reproduce the problem.
  std::future f = std::async(std::launch::async, &work);
}
/

The last invocation of std::future's destructor blocks the calling thread
until the thread launched by std::async finishes the work, according to the 4th
bullet of [futures.async]/5. Therefore, this program should terminate
successfully.

This program also results in segfault with GCC 4.7.2 20120811, but not with
4.6.4 20120810.

[Bug fortran/54298] New: Add warning when doing equal/nonequal floating-point comparisons

[burnus at gcc dot gnu.org]

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

 Bug #: 54298
   Summary: Add warning when doing equal/nonequal floating-point
comparisons
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bur...@gcc.gnu.org


Suggested by ISO/IEC Project 22.24772 "Guidance for Avoiding Vulnerabilities
through Language Selection and Use"  (see links at
http://gcc.gnu.org/wiki/GFortranStandards)

>From the Fortran appendix (draft at
http://grouper.ieee.org/groups/plv/DocLog/400-499/400-419/22-WG23-N-0410/n0410.pdf)


"Fortran.5 Floating-point Arithmetic [PFL]
...
"Fortran.5.2 Guidance to Fortran Users"
...
"* Do not create a logical value from a test for equality or inequality between
two floating-point expressions. Use compiler options where available to detect
such a usage"


gfortran doesn't have such a warning.

[Bug libstdc++/54297] [C++11] Segmentation fault with std::async and released shared state

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2012-08-17
 AssignedTo|unassigned at gcc dot   |redi at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

[Bug middle-end/54299] New: Array parameter does not allow for iterator syntax

[drepper.fsp at gmail dot com]

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

 Bug #: 54299
   Summary: Array parameter does not allow for iterator syntax
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: drepper@gmail.com


Compile the following code:

~~
int aa[10] = { 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 };

int f(int arr[10])
{
  int s = 0;
  for (auto i : arr)
s += i;
  return s;
}

int main()
{
  return f(aa);
}
~~

This fails with

u.cc: In function ‘int f(int*)’:
u.cc:18:17: error: ‘begin’ was not declared in this scope
u.cc:18:17: error: ‘end’ was not declared in this scope
u.cc:18:17: error: unable to deduce ‘auto’ from ‘’



This indicates that the problem is that the parameter is seen as 'int *'
instead of as 'int [10]'.  According to Andrew another problem caused by the
too-early decay of arguments to pointers (bug 24666).

Changing the code as follows makes it compile:

~~
int aa[1][10] = { { 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 } };

int f(int arr[1][10])
{
  int s = 0;
  for (auto i : arr[0])
s += i;
  return s;
}

int main()
{
  return f(aa);
}
~~

[Bug target/54300] New: [4.7/4.8 Regression] Erroneous optimization causes wrong Neon data management

[eric.batut at allegorithmic dot com]

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

 Bug #: 54300
   Summary: [4.7/4.8 Regression] Erroneous optimization causes
wrong Neon data management
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: eric.ba...@allegorithmic.com


Created attachment 28044
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28044
Small repro case

Using gcc trunk at rev 190381, compiled with the Android NDK r8b build-gcc.sh
script (so an arm-linux-androideabi target) and the command line below, the
attached repro case generates wrong code:

arm-linux-androideabi-g++ -march=armv7-a -mfloat-abi=softfp -mfpu=vfp
-mfpu=neon -marm -O2 test.cpp -S -o test.s

The core loop is pasted below:
for(unsigned int sv=0 ; sv!=dv0 ; sv=(sv+s1v)&smask_v)
{
int32x4_t s;
s = vmovl_s16(vget_low_s16(_loadlo_8i16((cv8i16*)_Inp, sv )));
c = vaddq_s32(c, s);
}

8 bytes are fetched from "_Inp (in bytes) + sv", then sign-extended from 4
16bits values to 4 32bits values, then accumulated in "c".

The generated assembly code for the loop is:
.L3:
addr4, r0, ip
vmov.i32d18, #0  @ v4hi   <= d18 is full of 0's
addip, ip, r2
vld1.16{d19}, [r4:64]<= d19 holds useful data
andip, ip, r5
cmpr3, ip
vswpd18, d19  <= d19 is now full of 0's
vmovl.s16q9, d19   <= d19 (full of 0's) gets expanded
vadd.i32q8, q8, q9<= q9 is always zero when accumulated
bne.L3

When using "-O1" or "-O2 -fno-gcse", correct code is generated:
.L3:
addr4, r0, ip
addip, ip, r2
andip, ip, r5
vld1.16{d18}, [r4:64]<= d18 holds useful data
cmpr3, ip
vmovl.s16q9, d18   <= d18 is sign-extended
vadd.i32q8, q8, q9<= q9 is accumulated
bne.L3

This also happens with gcc 4.7.1, but not with gcc 4.6

Also, in the loadlo_8i16 function, if we replace the call to zero_64 by the
proper vdup_n_s16(0), then correct code is generated at -O2.

The (stripped down in the repro case) _v16u8_ and _v8u8_ structures are the way
we implemented some kind of compiler-performed polymorphism for Neon variables,
since not all ARM compilers have -flax-vector-conversions.

[Bug libstdc++/54297] [C++11] Segmentation fault with std::async and released shared state

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  2012-08-17 
15:32:29 UTC ---
I suspect the problem is that when _Async_state_common calls _M_thread.join()
to wait for the async task, the derived destructor of _Async_state_impl has
already run and has destroyed the shared state.

If that's correct, the fix would be to add:

  ~_Async_state_impl() { _M_join(); }

[Bug c++/52026] [c++0x] g++: Constexpr Variable Appears Uninitialized in Lambda

[jpalecek at web dot de]

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

Jiří Paleček  changed:

   What|Removed |Added

 CC||jpalecek at web dot de

--- Comment #4 from Jiří Paleček  2012-08-17 15:35:22 
UTC ---
Could it be a duplicate of http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53488";>53488?

[Bug bootstrap/54281] [4.8 Regression] Fails to bootstrap with --disable-nls

[dnovillo at gcc dot gnu.org]

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

--- Comment #10 from Diego Novillo  2012-08-17 
15:38:03 UTC ---
Author: dnovillo
Date: Fri Aug 17 15:37:57 2012
New Revision: 190487

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190487
Log:
2012-08-17  Diego Novillo  

PR bootstrap/54281
* configure.ac: Add libintl.h to AC_CHECK_HEADERS list.
* config.in: Regenerate.
* configure: Regenerate.
* intl.h: Always include libintl.h if HAVE_LIBINTL_H is
set.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config.in
trunk/gcc/configure
trunk/gcc/configure.ac
trunk/gcc/intl.h

[Bug middle-end/54299] Array parameter does not allow for iterator syntax

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  2012-08-17 
15:40:42 UTC ---
I think the compiler's correct to reject the first example, the type of arr is
int* so it's not an array, and so the for loop calls begin(arr) and end(arr)

In the second example the parameter type is int(*)[10] so arr[0] is an array of
known bound, and so the for loop works.

[Bug middle-end/54299] Array parameter does not allow for iterator syntax

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  2012-08-17 
15:43:02 UTC ---
It would be nice if G++ told you the type of the range, as Clang++ does:

a.cc:9:15: error: use of undeclared identifier 'begin'
  for (auto i : arr)
  ^
a.cc:9:15: note: range has type 'int *'

[Bug fortran/54298] Add warning when doing equal/nonequal floating-point comparisons

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2012-08-17
 CC||tkoenig at gcc dot gnu.org
 AssignedTo|unassigned at gcc dot   |tkoenig at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

--- Comment #1 from Thomas Koenig  2012-08-17 
16:07:43 UTC ---
Sounds doable.

I'll give it a shot.

[Bug bootstrap/54281] [4.8 Regression] Fails to bootstrap with --disable-nls

[dnovillo at gcc dot gnu.org]

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

--- Comment #11 from Diego Novillo  2012-08-17 
16:17:20 UTC ---
Fixed.  http://gcc.gnu.org/ml/gcc-patches/2012-08/msg01181.html

[Bug bootstrap/54281] [4.8 Regression] Fails to bootstrap with --disable-nls

[dnovillo at gcc dot gnu.org]

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

Diego Novillo  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||FIXED

--- Comment #12 from Diego Novillo  2012-08-17 
16:19:02 UTC ---
.

[Bug fortran/54301] New: Add optional warning if pointer assigning a local variable to a nonlocal pointer

[burnus at gcc dot gnu.org]

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

 Bug #: 54301
   Summary: Add optional warning if pointer assigning a local
variable to a nonlocal pointer
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bur...@gcc.gnu.org
CC: tkoe...@gcc.gnu.org


Suggested by ISO/IEC Project 22.24772 "Guidance for Avoiding Vulnerabilities
through Language Selection and Use"  (see links at
http://gcc.gnu.org/wiki/GFortranStandards)

From the Fortran appendix (draft at
ftp://ftp.nag.co.uk/sc22wg5/N1901-N1950/N1929.pdf)

At the end there is the suggestion:

"Fortran.58.1 Implications for Standardization"
"Future standardization eorts should consider:"
...
"* Requiring that processors have the ability to detect and report the
occurrence within a submitted program unit of pointer assignment of
a pointer whose lifetime is known to be longer than the lifetime of the
target."


I think can be diagnosed with some -W... warning in the following case: The LHS
of the pointer assignment is

a) A function result variable
b) A dummy argument
c) A host- or use-associated variable
d) A common-block variable

and the RHS is a local variable (local to the procedure or local to a BLOCK) -
but, crucially, RHS variable is not a pointer.

[At least the case (a) I have already seen in some bugreport.]

[Bug fortran/54298] Add warning when doing equal/nonequal floating-point comparisons

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu.org

--- Comment #2 from Tobias Burnus  2012-08-17 
16:24:44 UTC ---
(In reply to comment #1)
> Sounds doable.
> I'll give it a shot.

Thanks. I think it can help to find some real-world issues, even if comparisons
such as "a == 0.0" are generally safe.

(In reply to comment #0)
> Suggested by ISO/IEC Project 22.24772 "Guidance for Avoiding Vulnerabilities
> through Language Selection and Use"  (see links at
> http://gcc.gnu.org/wiki/GFortranStandards)
> 
> From the Fortran appendix (draft at

Wrong link (that's the current 2nd-version draft of the TR, still the Fortran
part). The Fortran link is:
  ftp://ftp.nag.co.uk/sc22wg5/N1901-N1950/N1929.pdf


The issue is also mentioned in "Fortran.58 Implications for Standardization"
under "Future standardization efforts should consider:"

"Requiring that processors have the ability to detect and report the occurrence
within a submitted program unit of tests for equality between two objects of
type real or complex."

[Bug fortran/54302] New: Add optional warning when declaring a identifier in a nested scope, which matches on otherwise available one

[burnus at gcc dot gnu.org]

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

 Bug #: 54302
   Summary: Add optional warning when declaring a identifier in a
nested scope, which matches on otherwise available one
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bur...@gcc.gnu.org
CC: tkoe...@gcc.gnu.org


Suggested by ISO/IEC Project 22.24772 "Guidance for Avoiding Vulnerabilities
through Language Selection and Use"  (see links at
http://gcc.gnu.org/wiki/GFortranStandards)

From the Fortran appendix (draft at
ftp://ftp.nag.co.uk/sc22wg5/N1901-N1950/N1929.pdf)

At the end there is the suggestion:

"Fortran.58.1 Implications for Standardization"
"Future standardization eorts should consider:"
...
"Requiring that processors have the ability to detect and report the occurrence
within a submitted program unit of the reuse of a name within a nested scope."


This suggestion it about cases like host association:

  integer :: i
contains
  subroutine foo()
integer :: i
  end subroutine
end

And in BLOCK:

subroutine bar()
  integer :: i
  block
integer :: i
  end block
end subroutine bar



However, given that one cannot disable host association (contrary to USE
association and IMPORT, where one can selectively import certain variables),
one could consider also warn when accessing a host-associated variable. Often
one wants to access some host variables, but often one doesn't.

Best would be some standard support ("noimport" / "import :: list" / "import"),
which could then be enforced via "-fnoimport" similarly to "-fintent-none".
However, until that's in the standard, one could consider providing a warning.
(Or one waits for that one until something like (no)import has emerged for the
next revision of the standard.)

(Such a functionality has been requested several times - and it is also
mentioned in the same Fortran.58 section of the draft Fortran appendix to
TR24772.)


I think both warning are probably not suitable for -Wall, but they can be
helpful.

[Bug target/28896] -fstack-limit-symbol and m68k and non 68020

[baker at usgs dot gov]

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

--- Comment #16 from Larry Baker  2012-08-17 16:45:22 
UTC ---
Here are some notes about the patches I made.

1. An alternative to my m68k.md patch:

-  rtx temp = reload_in_progress ? operands[0] : gen_reg_rtx (Pmode);
+  rtx temp = can_create_pseudo_p() ? gen_reg_rtx (Pmode) : operands[0];

might be the approach taken by m68k_output_mi_thunk() in m68k.c:

 /* Pretend to be a post-reload pass while generating rtl.  */
 reload_completed = 1;
:
 if (!TARGET_SEP_DATA)
{
 /* Use the static chain register as a temporary (call-clobbered)
GOT pointer for this function.  We can use the static chain
register because it isn't live on entry to the thunk.  */
 SET_REGNO (pic_offset_table_rtx, STATIC_CHAIN_REGNUM);
 emit_insn (gen_load_got (pic_offset_table_rtx));
}
:
 /* Clean up the vars set above.  */
 reload_completed = 0;

 /* Restore the original PIC register.  */
 if (flag_pic)
   SET_REGNO (pic_offset_table_rtx, PIC_REG);

This fools the compiler by pretending to run post-reload pass (reload_completed
= 1).  That might have been for the same reason I made the one-line patch above
to m68k.md.  I am not sure the approach taken in m68k_output_mi_thunk() would
be correct in m68k_expand_prologue() in m68k.c:

• The alternative code does not undo the effects of an instruction that sets
crtl->uses_pic_offset_table while the temporary PIC offset table register is
being used.  That might cause an unnecessary load of the true PIC offset table
register (emit_insn (gen_load_got (pic_offset_table_rtx)) at the end of
m68k_expand_prologue()).
• I do not know if the prerequisite holds that the static chain register is
available in m68k_expand_prologue().
• I do not know if a pseudo register could be created in the stack check code
but never be assigned to an actual register since the reload pass has already
been run.

I decided the patch I made to m68k.md was safe since it followed the intent of
the existing conditional that decided whether or not to call gen_reg_rtx() and
it did not try to use any registers designated for other purposes or not yet
saved.  All I did was move the code as-is from before to after the code that
set up the PIC offset table register, and, only when that was required
(!TARGET_SEP_DATA && crtl->uses_pic_offset_table).

2. From what I understand of the GCC Internal Manual, the define_expand
TARGET_M68020 condition on ctrapdi4, ctrapsi4, ctraphi4, and ctrapqi4 is
ignored by the time those expansions are inserted into the RTL list (by the
define_expand "prologue" pattern).  In fact, my implementation of a conditional
trap pattern for the other architectures would not have been invoked if it had
been otherwise.  The correct insn's for conditional_traps will be selected when
the define_insn patterns are matched and expanded.  I concluded it is correct
to remove the TARGET_M68020 condition on ctrapdi4, ctrapsi4, ctraphi4, and
ctrapqi4 in m68k.md.

[Bug fortran/54301] Add optional warning if pointer assigning a local variable to a nonlocal pointer

[mikael at gcc dot gnu.org]

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

Mikael Morin  changed:

   What|Removed |Added

 CC||mikael at gcc dot gnu.org

--- Comment #1 from Mikael Morin  2012-08-17 
16:58:54 UTC ---
As always, that's a nice to have feature, but without a thorough control
flow/value range/whatever analysis, it would either give a warning in trivial
cases only or have many false positives.

A warning for b) makes sense to me; for the others:
 a) I don't see what prevents a function from returning a short lived
pointer
 c) d)  The pointer is globally accessible, so I'm not so sure how it could be
   nullified or re-associated.

[Bug c/54303] New: -fdata-sections -ffunction-sections and -fmerge-constants do not work well together

[tom.rini at gmail dot com]

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

 Bug #: 54303
   Summary: -fdata-sections -ffunction-sections and
-fmerge-constants do not work well together
Classification: Unclassified
   Product: gcc
   Version: 4.6.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: tom.r...@gmail.com


Created attachment 28045
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28045
Testcase for the issue

The attached test-case demonstrates the problem I see:
$ arm-linux-gnueabi-gcc -Wall -fdata-sections -ffunction-sections -o
non-collected-strings.o -c non-collected-strings.c
$ arm-linux-gnueabi-gcc -Wl,--gc-sections -o non-collected-strings
non-collected-strings.o
$ strings non-collected-strings | grep here
This string should not be here
This string should be here
$ arm-linux-gnueabi-nm non-collected-strings| grep me
004004d0 t frame_dummy
004004f2 T keep_me
$ arm-linux-gnueabi-nm non-collected-strings.o | grep me
 T garbage_collect_me
 T keep_me
$ arm-linux-gnueabi-objdump -h non-collected-strings.o | grep str
non-collected-strings.o: file format elf32-littlearm
  3 .rodata.str1.4 003c      0034  2**2

And all strings in the object file are coalesced into a single section.

Note that on x86-64 this works as expected as the last step shows instead:
$ objdump -h non-collected-strings.o  | grep str
non-collected-strings.o: file format elf64-x86-64
  3 .rodata.str1.8 001f      0040  2**3
  5 .rodata.str1.1 001b      006f  2**0

I've verified this with a few different arm-linux-gnueabi toolchains (ELDK 4.2,
ELDK 5.2.1, Linaro (4:4.6.2-7 in Ubuntu) and this seems like a long-standing
thing, not Linaro-patch specific.

[Bug fortran/54301] Add optional warning if pointer assigning a local variable to a nonlocal pointer

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu.org

--- Comment #2 from Tobias Burnus  2012-08-17 
18:29:28 UTC ---
(In reply to comment #1)
>  a) I don't see what prevents a function from returning a short lived
> pointer

Nothing - except that it is bad if the pointer target is gone at the instance
of returning. Example:

function f () result (ptr)
  integer, pointer :: ptr(:)
  integer, allocatable, target :: a(:)
  allocate(a(5))

  ptr => a
  a = [1,2,3,4,5]
end function

(There is some closed as INVALID PR which used such a code; the code above is
perfectly valid, one just may not dereference the returned function result.)

Here, "ptr" is a perfectly valid pointer within "f", however, "f" returns as
function result an "undefined" pointer. The program is perfectly valid, except,
one may not access the returned function result – which is a bit pointless. Of
course, the code works, if one reassociates "ptr" with some other target which
lives longer; still it is a bad programming style and asks for trouble.

That's the idea of the warning: Warn for questionable code.


Similarly for (c):

subroutine foo()
  integer, pointer :: ptr(:)
  ...
  call bar ()
  ...
contains
  subroutine bar ()
integer, target :: tgt(5)
ptr => tgt
  end subroutine bar
  ...
end subroutine foo

That's perfectly valid, but a dangerous way of programming. It becomes more
reliably if "tgt" has the SAVE attribute – but I believe that it is still
invalid to access "tgt" outside of "bar".


Note: I only talked about a local nonpointer target on the RHS for which one
should warn. For instance:
   function foo(tgt)
 integer, target :: tgt
 integer, pointer :: foo
 foo => tgt
   end function
is perfectly valid and sensible if the actual argument is either a pointer or a
target. (It is also valid if the nonpointer actual argument has no target
attribute, but then the function result is an undefined pointer.) Hence, we
cannot warn for this case.

[Bug rtl-optimization/46829] ICE: in spill_failure, at reload1.c:2105 with -fschedule-insns -fsched-pressure and variadic function

[ubizjak at gmail dot com]

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

Uros Bizjak  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
URL||http://gcc.gnu.org/ml/gcc-p
   ||atches/2012-08/msg01202.htm
   ||l
 AssignedTo|unassigned at gcc dot   |ubizjak at gmail dot com
   |gnu.org |

--- Comment #11 from Uros Bizjak  2012-08-17 18:37:44 
UTC ---
Patch at [1].

[1] http://gcc.gnu.org/ml/gcc-patches/2012-08/msg01202.html

[Bug fortran/54301] Add optional warning if pointer assigning a local variable to a nonlocal pointer

[burnus at gcc dot gnu.org]

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

--- Comment #3 from Tobias Burnus  2012-08-17 
18:50:53 UTC ---
F2008, 16.5.2.5:

"The association status of a pointer becomes undefined when
...
"(5) completion of execution of an instance of a subprogram causes the
pointer's target to become undefined (item (3) of 16.6.6),
"(6) completion of execution of a BLOCK construct causes the pointer's target
to become undefined (item (22) of 16.6.6),"


F2008, 16.6.6:

"(3) When execution of an instance of a subprogram completes,
   (a) its unsaved local variables become undefined,
   (b) unsaved variables in a named common block that appears in the
   subprogram become undefined if they have been dened or redefined,
unless
   another active scoping unit is referencing the common block, and
   (c) a variable of type C PTR whose value is the C address of an unsaved
   local variable of the subprogram becomes undefined."
...
"(22) When a BLOCK construct completes execution, its unsaved local variables
become undefined, and a variable of type C PTR whose value is the C address of
an unsaved local variable of the BLOCK construct becomes undefined."


Given the potential badness, I still think one should warn for (a) to (d).
Though, one probably should think of not warning if the target has the SAVE
attribute.

The other question is whether the warning should be enabled by -Wall or not. (I
would enable it with -Wall.)

[Bug bootstrap/54304] New: linking stage picks up system mpfr instead of in-tree version

[tobi at gcc dot gnu.org]

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

 Bug #: 54304
   Summary: linking stage picks up system mpfr instead of in-tree
version
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: t...@gcc.gnu.org


This is an old bug, I found mention of it all over the internet, and also on
the gcc mailing list .

What happens is that with an in-tree gmp, mpfr, mpc (I used
contrib/download_prerequisites) the linking stage picks up the system libraries
instead of the in-tree versions.  This causes a problem when the system libmpfr
< 3.0.0 and the in-tree version is >= 3.0.0 and vice versa, because
mpfr_get_z_exp was renamed to mpfr_get_z_2exp between the two (hidden behind a
macro).  The error I'm seeing with today's tree is:

/Users/tobi/src/gcc/build/./prev-gcc/g++
-B/Users/tobi/src/gcc/build/./prev-gcc/
-B/usr/local/x86_64-apple-darwin11.4.0/bin/ -nostdinc++
-B/Users/tobi/src/gcc/build/prev-x86_64-apple-darwin11.4.0/libstdc++-v3/src/.libs
-B/Users/tobi/src/gcc/build/prev-x86_64-apple-darwin11.4.0/libstdc++-v3/libsupc++/.libs
-I/Users/tobi/src/gcc/build/prev-x86_64-apple-darwin11.4.0/libstdc++-v3/include/x86_64-apple-darwin11.4.0
-I/Users/tobi/src/gcc/build/prev-x86_64-apple-darwin11.4.0/libstdc++-v3/include
-I/Users/tobi/src/gcc/libstdc++-v3/libsupc++
-L/Users/tobi/src/gcc/build/prev-x86_64-apple-darwin11.4.0/libstdc++-v3/src/.libs
-L/Users/tobi/src/gcc/build/prev-x86_64-apple-darwin11.4.0/libstdc++-v3/libsupc++/.libs
  -g -O2 -mdynamic-no-pic -gtoggle -DIN_GCC   -fno-exceptions -fno-rtti -W
-Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute
-pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror
-fno-common  -DHAVE_CONFIG_H -static-libstdc++ -static-libgcc -Wl,-no_pie -o
f951 \
fortran/arith.o fortran/array.o fortran/bbt.o fortran/check.o
fortran/class.o fortran/constructor.o fortran/cpp.o fortran/data.o
fortran/decl.o fortran/dump-parse-tree.o fortran/error.o fortran/expr.o
fortran/interface.o fortran/intrinsic.o fortran/io.o fortran/iresolve.o
fortran/match.o fortran/matchexp.o fortran/misc.o fortran/module.o
fortran/openmp.o fortran/options.o fortran/parse.o fortran/primary.o
fortran/resolve.o fortran/scanner.o fortran/simplify.o fortran/st.o
fortran/symbol.o fortran/target-memory.o darwin-f.o fortran/convert.o
fortran/dependency.o fortran/f95-lang.o fortran/trans.o fortran/trans-array.o
fortran/trans-common.o fortran/trans-const.o fortran/trans-decl.o
fortran/trans-expr.o fortran/trans-intrinsic.o fortran/trans-io.o
fortran/trans-openmp.o fortran/trans-stmt.o fortran/trans-types.o
fortran/frontend-passes.o libbackend.a main.o tree-browser.o libcommon-target.a
libcommon.a ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a libcommon.a
../libcpp/libcpp.a -lintl -L/opt/local/lib -liconv  ../libiberty/libiberty.a
../libdecnumber/libdecnumber.a  attribs.o 
-L/Users/tobi/src/gcc/build/./gmp/.libs
-L/Users/tobi/src/gcc/build/./mpfr/.libs
-L/Users/tobi/src/gcc/build/./mpc/src/.libs -lmpc -lmpfr -lgmp   -L../zlib -lz
Undefined symbols for architecture x86_64:
  "_mpfr_get_z_exp", referenced from:
  gfc_mpfr_to_mpz(__mpz_struct*, __mpfr_struct*, locus*) in arith.o
ld: symbol(s) not found for architecture x86_64
collect2: error: ld returned 1 exit status
make[3]: *** [f951] Error 1
make[2]: *** [all-stage2-gcc] Error 2
make[1]: *** [stage2-bubble] Error 2
make: *** [all] Error 2

(I mentioned this in the aftermath to PR54292)

Cheers

[Bug bootstrap/54292] [4.8 Regression] Errors due to conflicting strsignal headers

[tobi at gcc dot gnu.org]

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

--- Comment #6 from Tobias Schlüter  2012-08-17 
19:07:35 UTC ---
This latter issue is now PR54304.

[Bug target/54305] New: [4.8 regression] FAIL: gcc.target/m68k/pr36134.c scan-assembler lea

[sch...@linux-m68k.org]

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

 Bug #: 54305
   Summary: [4.8 regression] FAIL: gcc.target/m68k/pr36134.c
scan-assembler lea
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: sch...@linux-m68k.org
Target: m68k-*-*


@@ -7,31 +7,29 @@
 f:
link.w %fp,#0
move.l a,%a1
-   move.l %a3,-(%sp)
move.l b,%a0
-   move.l %a2,-(%sp)
cmp.l %a1,%a0
jcc .L1
 .L5:
move.l (%a0),(%a1)
-   move.l %a0,%a3
-   move.l %a1,%a2
+   move.l %a1,%d1
+   move.l %a0,%d0
+   add.l #16,%d1
+   add.l #16,%d0
move.l 4(%a0),4(%a1)
move.l 8(%a0),8(%a1)
-   lea (16,%a1),%a1
-   lea (16,%a0),%a0
-   move.l 12(%a3),12(%a2)
-   cmp.l %a1,%a0
+   move.l 12(%a0),12(%a1)
+   move.l %d1,%a1
+   move.l %d0,%a0
+   cmp.l %d1,%d0
jcs .L5
-   move.l %a1,a
-   move.l %a0,b
+   move.l %d1,a
+   move.l %d0,b
 .L1:
-   move.l (%sp)+,%a2
-   move.l (%sp)+,%a3
unlk %fp
rts
.size   f, .-f
.comm   b,4,2
.comm   a,4,2
-   .ident  "GCC: (GNU) 4.8.0 20120810 (experimental)"
+   .ident  "GCC: (GNU) 4.8.0 20120817 (experimental)"
.section.note.GNU-stack,"",@progbits


First appeared in r190284.

[Bug bootstrap/54304] linking stage picks up system mpfr instead of in-tree version

[pinskia at gmail dot com]

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

--- Comment #1 from pinskia at gmail dot com  
2012-08-17 19:13:50 UTC ---
This is a darwin only issue.
On Aug 17, 2012 12:07 PM, "tobi at gcc dot gnu.org" <
gcc-bugzi...@gcc.gnu.org> wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54304
>
>  Bug #: 54304
>Summary: linking stage picks up system mpfr instead of in-tree
> version
> Classification: Unclassified
>Product: gcc
>Version: 4.8.0
> Status: UNCONFIRMED
>   Severity: normal
>   Priority: P3
>  Component: bootstrap
> AssignedTo: unassig...@gcc.gnu.org
> ReportedBy: t...@gcc.gnu.org
>
>
> This is an old bug, I found mention of it all over the internet, and also
> on
> the gcc mailing list  >.
>
> What happens is that with an in-tree gmp, mpfr, mpc (I used
> contrib/download_prerequisites) the linking stage picks up the system
> libraries
> instead of the in-tree versions.  This causes a problem when the system
> libmpfr
> < 3.0.0 and the in-tree version is >= 3.0.0 and vice versa, because
> mpfr_get_z_exp was renamed to mpfr_get_z_2exp between the two (hidden
> behind a
> macro).  The error I'm seeing with today's tree is:
>
> /Users/tobi/src/gcc/build/./prev-gcc/g++
> -B/Users/tobi/src/gcc/build/./prev-gcc/
> -B/usr/local/x86_64-apple-darwin11.4.0/bin/ -nostdinc++
>
> -B/Users/tobi/src/gcc/build/prev-x86_64-apple-darwin11.4.0/libstdc++-v3/src/.libs
>
> -B/Users/tobi/src/gcc/build/prev-x86_64-apple-darwin11.4.0/libstdc++-v3/libsupc++/.libs
>
> -I/Users/tobi/src/gcc/build/prev-x86_64-apple-darwin11.4.0/libstdc++-v3/include/x86_64-apple-darwin11.4.0
>
> -I/Users/tobi/src/gcc/build/prev-x86_64-apple-darwin11.4.0/libstdc++-v3/include
> -I/Users/tobi/src/gcc/libstdc++-v3/libsupc++
>
> -L/Users/tobi/src/gcc/build/prev-x86_64-apple-darwin11.4.0/libstdc++-v3/src/.libs
>
> -L/Users/tobi/src/gcc/build/prev-x86_64-apple-darwin11.4.0/libstdc++-v3/libsupc++/.libs
>   -g -O2 -mdynamic-no-pic -gtoggle -DIN_GCC   -fno-exceptions -fno-rtti -W
> -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute
> -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings
> -Werror
> -fno-common  -DHAVE_CONFIG_H -static-libstdc++ -static-libgcc -Wl,-no_pie
> -o
> f951 \
> fortran/arith.o fortran/array.o fortran/bbt.o
> fortran/check.o
> fortran/class.o fortran/constructor.o fortran/cpp.o fortran/data.o
> fortran/decl.o fortran/dump-parse-tree.o fortran/error.o fortran/expr.o
> fortran/interface.o fortran/intrinsic.o fortran/io.o fortran/iresolve.o
> fortran/match.o fortran/matchexp.o fortran/misc.o fortran/module.o
> fortran/openmp.o fortran/options.o fortran/parse.o fortran/primary.o
> fortran/resolve.o fortran/scanner.o fortran/simplify.o fortran/st.o
> fortran/symbol.o fortran/target-memory.o darwin-f.o fortran/convert.o
> fortran/dependency.o fortran/f95-lang.o fortran/trans.o
> fortran/trans-array.o
> fortran/trans-common.o fortran/trans-const.o fortran/trans-decl.o
> fortran/trans-expr.o fortran/trans-intrinsic.o fortran/trans-io.o
> fortran/trans-openmp.o fortran/trans-stmt.o fortran/trans-types.o
> fortran/frontend-passes.o libbackend.a main.o tree-browser.o
> libcommon-target.a
> libcommon.a ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a libcommon.a
> ../libcpp/libcpp.a -lintl -L/opt/local/lib -liconv
>  ../libiberty/libiberty.a
> ../libdecnumber/libdecnumber.a  attribs.o
> -L/Users/tobi/src/gcc/build/./gmp/.libs
> -L/Users/tobi/src/gcc/build/./mpfr/.libs
> -L/Users/tobi/src/gcc/build/./mpc/src/.libs -lmpc -lmpfr -lgmp   -L../zlib
> -lz
> Undefined symbols for architecture x86_64:
>   "_mpfr_get_z_exp", referenced from:
>   gfc_mpfr_to_mpz(__mpz_struct*, __mpfr_struct*, locus*) in arith.o
> ld: symbol(s) not found for architecture x86_64
> collect2: error: ld returned 1 exit status
> make[3]: *** [f951] Error 1
> make[2]: *** [all-stage2-gcc] Error 2
> make[1]: *** [stage2-bubble] Error 2
> make: *** [all] Error 2
>
> (I mentioned this in the aftermath to PR54292)
>
> Cheers
>

[Bug bootstrap/54304] linking stage picks up system mpfr instead of in-tree version

[tobi at gcc dot gnu.org]

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

Tobias Schlüter  changed:

   What|Removed |Added

   Host||darwin

--- Comment #2 from Tobias Schlüter  2012-08-17 
19:24:36 UTC ---
Sorry, forgot to fill in the field.

One additional piece of information: note that this certainly applies to GMP
and MPC as well, but their ABIs didn't change, so the error happens silently.

[Bug bootstrap/54304] linking stage picks up system mpfr instead of in-tree version

[glisse at gcc dot gnu.org]

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

--- Comment #3 from Marc Glisse  2012-08-17 19:27:08 
UTC ---
When you say: "the system libraries", where are they? /opt/local/lib?

[Bug bootstrap/54304] linking stage picks up system mpfr instead of in-tree version

[tobi at gcc dot gnu.org]

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

--- Comment #4 from Tobias Schlüter  2012-08-17 
19:29:56 UTC ---
BTW PR50914, though closed as invalid, indicates that similar mixups can also
happen on i686-linux.

[Bug bootstrap/54304] linking stage picks up system mpfr instead of in-tree version

[tobi at gcc dot gnu.org]

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

--- Comment #5 from Tobias Schlüter  2012-08-17 
19:31:37 UTC ---
It seems I have them in /usr/lib and in /opt/local/lib.  How can I find out
which one it picks up?

[Bug bootstrap/54304] linking stage picks up system mpfr instead of in-tree version

[tobi at gcc dot gnu.org]

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

--- Comment #6 from Tobias Schlüter  2012-08-17 
19:33:44 UTC ---
Sorry, my mistake, it's ~/usr/lib not /usr/lib.  I'll have to find out if that
is included in any search path (I doubt it).  About the one in /opt/local/lib I
wasn't mistaken.

[Bug bootstrap/54304] linking stage picks up system mpfr instead of in-tree version

[tobi at gcc dot gnu.org]

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

--- Comment #7 from Tobias Schlüter  2012-08-17 
19:35:30 UTC ---
Ok, the one in ~/usr/lib is 2.2.1, so this error wouldn't appear if it got
picked up.

[Bug bootstrap/54304] linking stage picks up system mpfr instead of in-tree version

[tobi at gcc dot gnu.org]

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

--- Comment #8 from Tobias Schlüter  2012-08-17 
19:38:54 UTC ---
Sorry, didn't mean to hit "Save Changes" yet.

In the past I had to configure with
  ../configure --with-libiconv-prefix=/opt/local --enable-languages=fortran
because otherwise the build breaks with iconv issues (also something you find
all over google).  And now I see why you asked: this of course puts the system
gmp etc in the search path ahead of the ones built in-tree.  Not a desirable
state admittedly.

[Bug bootstrap/54304] linking stage picks up system mpfr instead of in-tree version

[glisse at gcc dot gnu.org]

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

--- Comment #9 from Marc Glisse  2012-08-17 19:40:19 
UTC ---
Well, there is the usual problem that if you use external libraries A and B
that are both installed in both path1 and path2 and you want A from path1 and B
from path2, that's not possible.

The difference here is that we know in-tree locations are safe (no unwanted
library in there). So instead of just putting -I and -L flags to these
locations as they appear, we should put the safe ones in front. That
complicates things a bit...

[Bug rtl-optimization/54294] [4.8 Regression]: [alpha] Bootstrap comparison failure due to fwprop handling of debug insns

[ubizjak at gmail dot com]

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

--- Comment #8 from Uros Bizjak  2012-08-17 19:50:10 
UTC ---
(In reply to comment #7)

> Bootstrap finished OK, all interesting regression test passed on
> alphaev68-unknown-linux-gnu.

Regression test is also ok [1].

[1] http://gcc.gnu.org/ml/gcc-testresults/2012-08/msg01654.html

[Bug target/20020] x86_64 - 128 bit structs not targeted to TImode

[hjl at gcc dot gnu.org]

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

--- Comment #48 from hjl at gcc dot gnu.org  2012-08-17 
19:59:51 UTC ---
Author: hjl
Date: Fri Aug 17 19:59:46 2012
New Revision: 190492

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190492
Log:
Define MAX_FIXED_MODE_SIZE/TARGET_MEMBER_TYPE_FORCES_BLK for i386

gcc/

PR target/20020
* config/i386/i386.c (ix86_member_type_forces_blk): New function.
(TARGET_MEMBER_TYPE_FORCES_BLK): New macro.

* config/i386/i386.h (MAX_FIXED_MODE_SIZE): New macro.

gcc/testsuite/

PR target/20020
* gcc.target/i386/pr20020-1.c: New test.
* gcc.target/i386/pr20020-2.c: Likewise.
* gcc.target/i386/pr20020-3.c: Likewise.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr20020-1.c
trunk/gcc/testsuite/gcc.target/i386/pr20020-2.c
trunk/gcc/testsuite/gcc.target/i386/pr20020-3.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/config/i386/i386.h
trunk/gcc/testsuite/ChangeLog

[Bug target/20020] x86_64 - 128 bit structs not targeted to TImode

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.8.0

--- Comment #48 from hjl at gcc dot gnu.org  2012-08-17 
19:59:51 UTC ---
Author: hjl
Date: Fri Aug 17 19:59:46 2012
New Revision: 190492

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190492
Log:
Define MAX_FIXED_MODE_SIZE/TARGET_MEMBER_TYPE_FORCES_BLK for i386

gcc/

PR target/20020
* config/i386/i386.c (ix86_member_type_forces_blk): New function.
(TARGET_MEMBER_TYPE_FORCES_BLK): New macro.

* config/i386/i386.h (MAX_FIXED_MODE_SIZE): New macro.

gcc/testsuite/

PR target/20020
* gcc.target/i386/pr20020-1.c: New test.
* gcc.target/i386/pr20020-2.c: Likewise.
* gcc.target/i386/pr20020-3.c: Likewise.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr20020-1.c
trunk/gcc/testsuite/gcc.target/i386/pr20020-2.c
trunk/gcc/testsuite/gcc.target/i386/pr20020-3.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/config/i386/i386.h
trunk/gcc/testsuite/ChangeLog

--- Comment #49 from H.J. Lu  2012-08-17 20:00:41 
UTC ---
Fixed.

[Bug target/20020] x86_64 - 128 bit structs not targeted to TImode

[hjl at gcc dot gnu.org]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.8.0

--- Comment #49 from H.J. Lu  2012-08-17 20:00:41 
UTC ---
Fixed.

[Bug c/54306] New: ARM iwmmxt2 commit adds imbalanced #endif in mmintrin.h

[dsd at laptop dot org]

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

 Bug #: 54306
   Summary: ARM iwmmxt2 commit adds imbalanced #endif in
mmintrin.h
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: d...@laptop.org
CC: matts...@gmail.com, ni...@redhat.com


The commit that added iwmmxt2 support:
http://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=6b8f7c284d4443660a1ce94ae695940930a5708c

adds an imbalanced number of #endif to gcc/config/arm/mmintrin.h

This means that iwmmxt support doesn't work, compiles fail when building with
-march=iwmmxt2 due to this imbalance.

I believe the very last line added by the patch to mmintin.h should be removed:
+#endif /* __IWMMXT__ */

The __IWMMXT__ check was already done (and terminated) at the top of the file.

[Bug bootstrap/54304] linking stage picks up system mpfr instead of in-tree version

[tobi at gcc dot gnu.org]

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

--- Comment #10 from Tobias Schlüter  2012-08-17 
20:56:40 UTC ---
You don't need the -L flags for the in-tree libraries at all as you could just
put, say, "path_to_mpfr/libmpfr.a" on the command line.  I understand that this
might need some major Makefile surgery.

Anyway, a build without --with-libiconv-prefix=/opt/local succeeded, I have
updated my system in the meantime, so I can't investigate this further.  (The
iconv issue was of the type described e.g. here
).

Anyway, I think this can be closed as INVALID unless you find the suggestion to
do away with -L for in-tree stuff worthwhile.

[Bug bootstrap/54304] linking stage picks up system mpfr instead of in-tree version

[glisse at gcc dot gnu.org]

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

--- Comment #11 from Marc Glisse  2012-08-17 
21:21:57 UTC ---
(In reply to comment #10)
> You don't need the -L flags for the in-tree libraries at all as you could just
> put, say, "path_to_mpfr/libmpfr.a" on the command line.  I understand that 
> this
> might need some major Makefile surgery.

That wouldn't be so hard, but it doesn't help for -I. And it seems preferable
to handle -I and -L in the same way so they have less chances of disagreeing
(which they sadly do here).

[Bug bootstrap/54304] linking stage picks up system mpfr instead of in-tree version

[tobi at gcc dot gnu.org]

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

--- Comment #12 from Tobias Schlüter  2012-08-17 
21:35:50 UTC ---
Well, directories given by -I are searched before system directories, -L adds
directories to the end of the library search list, so their functions are not
equivalent.  Which is the root of my problem, and which will always lead to
conflicts if a library is installed both in a system dir and under some prefix
specified via a --with-lib-prefix= option.  Ugly.

[Bug libstdc++/54307] New: [4.7 regression] increases in memory usage by some C++11 (and C++03) standard containers

[matt at use dot net]

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

 Bug #: 54307
   Summary: [4.7 regression] increases in memory usage by some
C++11 (and C++03) standard containers
Classification: Unclassified
   Product: gcc
   Version: 4.7.1
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: m...@use.net


Between 4.6 and 4.7.x, the memory used by a few standard containers has
increased, resulting in some OOM and performance issues on an amd64 application
I work on.

4.7:
list size = 24
unordered_map size = 64
unordered_set size = 64

4.6:
list size = 16
unordered_map size = 56
unordered_set size = 56

comparing to VC11:
list size   = 16
unordered_map size = 64
unordered_set size = 64

compile commandline is just -std=c++0x. testcase program below:

#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

using namespace std;

int main(void)
{
vector v; printf("vector size\t = %d\n", sizeof(v));
array a; printf("array size\t = %d\n", sizeof(a));
deque d; printf("deque size\t = %d\n", sizeof(d));
forward_list f; printf("forward_list size\t = %d\n", sizeof(f));
list l; printf("list size\t = %d\n", sizeof(l));
queue q; printf("queue size\t = %d\n", sizeof(q));
stack s; printf("stack size\t = %d\n", sizeof(s));
tuple t; printf("tuple size\t = %d\n",
sizeof(t));
map m; printf("map size\t = %d\n", sizeof(m));
set set; printf("set size\t = %d\n", sizeof(set));
unordered_map um; printf("unordered_map size\t = %d\n",
sizeof(um));
unordered_set us; printf("unordered_set size\t = %d\n",
sizeof(us));
string str; printf("string size\t = %d\n", sizeof(string));
return 0;
}

[Bug bootstrap/54304] linking stage picks up system mpfr instead of in-tree version

[glisse at gcc dot gnu.org]

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

--- Comment #13 from Marc Glisse  2012-08-17 
22:06:07 UTC ---
(In reply to comment #12)
> Well, directories given by -I are searched before system directories,

Yes (system directories are those given by -isystem or hardcoded in the
compiler).

> -L adds directories to the end of the library search list,

No, there are also system directories afterwards.

Not that system directories are relevant here...

[Bug bootstrap/54304] linking stage picks up system mpfr instead of in-tree version

[tobi at gcc dot gnu.org]

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

--- Comment #14 from Tobias Schlüter  2012-08-17 
22:25:15 UTC ---
Ah, true, further down in the ld manpage this is stated clearly.  Thanks!

[Bug libstdc++/54307] [4.7 regression] increases in memory usage by some C++11 (and C++03) standard containers

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2012-08-17
   Target Milestone|--- |4.7.2
 Ever Confirmed|0   |1

--- Comment #1 from H.J. Lu  2012-08-17 22:59:26 
UTC ---
I believe it has been fixed on 7.2 branch by

http://gcc.gnu.org/ml/gcc-cvs/2012-07/msg00090.html

Can you verified it?

[Bug libstdc++/54307] [4.7 regression] increases in memory usage by some C++11 (and C++03) standard containers

[paolo.carlini at oracle dot com]

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

--- Comment #2 from Paolo Carlini  2012-08-18 
00:05:37 UTC ---
Note that the unordered containers have been profoundly reworked to conform to
C++11, the size isn't going to change.

[Bug middle-end/48784] #pragma pack(1) + -fstrict-volatile-bitfields = bad codegen

[sandra at codesourcery dot com]

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

Sandra Loosemore  changed:

   What|Removed |Added

 CC||sandra at codesourcery dot
   ||com

--- Comment #1 from Sandra Loosemore  
2012-08-18 01:11:12 UTC ---
I just checked the test case on mainline head for a couple other builds I have
handy.

ARM EABI prints "1ff" whether or not you compile with
-fstrict-volatile-bitfields.

MIPS ELF prints "0" with -fstrict-volatile-bitfields and "fff" without.

[Bug other/54308] New: build regression in 190498 on ppc64/linux: legitimate_indirect_address_p undefined

[PHHargrove at lbl dot gov]

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

 Bug #: 54308
   Summary: build regression in 190498 on ppc64/linux:
legitimate_indirect_address_p undefined
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: phhargr...@lbl.gov


I pulled gcc-trunk from svn (revision 190498) today hoping to build on my
PPC64/Linux host, knowing that bug 54142 had been fixed in 190427.

Unfortunately something (the build-with-cxx merge being the most obvious
candidate) seems to have broken this build for me when using Red Hat's gcc/g++
4.2.1 from the Linux distro (Fedora Core 6).  The key info appears below, but I
can provide any additional info that might be necessary.

As soon as I am able I will be trying the build on this host with a GCC more
recent than 4.2.1 (and not when patched up by Red Hat).  I will report
success/failure when that has been completed.

-Paul


Script started on Fri 17 Aug 2012 05:36:08 PM PDT
$ svn -q co svn://gcc.gnu.org/svn/gcc/trunk gcc-trunk
$ svn up gcc-trunkK
At revision 190498.
$ cd gcc-trunk
$ ./contrib/gcc_update --touch
[...]
$ cd ..
$ mkdir BLD
$ cd BLD
$ gcc --version
gcc (GCC) 4.1.2 20070626 (Red Hat 4.1.2-13)
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ env 'CFLAGS=-g -O0' \
  ../gcc-trunk/configure --enable-languages=c \
--disable-bootstrap --enable-checking 'CC=gcc -m64' 'CXX=g++ -m64' \
--with-mpc=/usr/local/pkg/mpc-0.8.1 \
--with-mpfr=/usr/local/pkg/mpfr-2.4.2 \
--with-gmp=/usr/local/pkg/gmp-4.3.2
checking build system type... powerpc64-unknown-linux-gnu
checking host system type... powerpc64-unknown-linux-gnu
checking target system type... powerpc64-unknown-linux-gnu
[...]

$ make
[...]
g++ -m64 -c  -DIN_GCC_FRONTEND -g -O2 -DIN_GCC   -fno-exceptions -fno-rtti -W
-Wall -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -fno-common 
-DHAVE_CONFIG_H -I. -I. -I../../gcc-trunk/gcc -I../../gcc-trunk/gcc/.
-I../../gcc-trunk/gcc/../include -I../../gcc-trunk/gcc/../libcpp/include
-I/usr/local/pkg/gmp-4.3.2/include -I/usr/local/pkg/mpfr-2.4.2/include
-I/usr/local/pkg/mpc-0.8.1/include  -I../../gcc-trunk/gcc/../libdecnumber
-I../../gcc-trunk/gcc/../libdecnumber/dpd -I../libdecnumbercc1-checksum.c
-o cc1-checksum.o
g++ -m64   -g -O2 -DIN_GCC   -fno-exceptions -fno-rtti -W -Wall -Wwrite-strings
-Wcast-qual -Wmissing-format-attribute -fno-common  -DHAVE_CONFIG_H  -o cc1
c/c-lang.o c-family/stub-objc.o attribs.o c/c-errors.o c/c-decl.o c/c-typeck.o
c/c-convert.o c/c-aux-info.o c/c-objc-common.o c/c-parser.o c-family/c-common.o
c-family/c-cppbuiltin.o c-family/c-dump.o c-family/c-format.o
c-family/c-gimplify.o c-family/c-lex.o c-family/c-omp.o c-family/c-opts.o
c-family/c-pch.o c-family/c-ppoutput.o c-family/c-pragma.o
c-family/c-pretty-print.o c-family/c-semantics.o c-family/c-ada-spec.o
tree-mudflap.o default-c.o rs6000-c.o \
  cc1-checksum.o libbackend.a main.o tree-browser.o libcommon-target.a
libcommon.a ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a libcommon.a
../libcpp/libcpp.a   ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a  
-L/usr/local/pkg/gmp-4.3.2/lib -L/usr/local/pkg/mpfr-2.4.2/lib
-L/usr/local/pkg/mpc-0.8.1/lib -lmpc -lmpfr -lgmp -rdynamic -ldl  -L../zlib -lz
libbackend.a(insn-preds.o): In function `stmw_operation_1':
/home/phargrov/tmp/gcc/BLD/gcc/../../gcc-trunk/gcc/config/rs6000/predicates.md:1374:
undefined reference to `legitimate_indirect_address_p(rtx_def*, int)'
/home/phargrov/tmp/gcc/BLD/gcc/../../gcc-trunk/gcc/config/rs6000/predicates.md:1404:
undefined reference to `legitimate_indirect_address_p(rtx_def*, int)'
libbackend.a(insn-preds.o): In function `lmw_operation_1':
/home/phargrov/tmp/gcc/BLD/gcc/../../gcc-trunk/gcc/config/rs6000/predicates.md:1299:
undefined reference to `legitimate_indirect_address_p(rtx_def*, int)'
/home/phargrov/tmp/gcc/BLD/gcc/../../gcc-trunk/gcc/config/rs6000/predicates.md:1329:
undefined reference to `legitimate_indirect_address_p(rtx_def*, int)'
collect2: ld returned 1 exit status
make[2]: *** [cc1] Error 1
make[2]: Leaving directory `/home/phargrov/tmp/gcc/BLD/gcc'
make[1]: *** [all-gcc] Error 2
make[1]: Leaving directory `/home/phargrov/tmp/gcc/BLD'
make: *** [all] Error 2

[Bug other/54308] build regression in 190498 on ppc64/linux: legitimate_indirect_address_p undefined

[hp at gcc dot gnu.org]

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

Hans-Peter Nilsson  changed:

   What|Removed |Added

 CC||hp at gcc dot gnu.org

--- Comment #1 from Hans-Peter Nilsson  2012-08-18 
02:32:31 UTC ---
(Note, apparent s/4.2.1/4.1.2/g in initial description.)

I'd suggest updating to just a later gcc build, if you can find *only slightly
newer* rpm:s; as for a x86_64-linux F 8 with gcc-4.1.2-33 ("gcc (GCC) 4.1.2
20070925 (Red Hat 4.1.2-33)"), I'm well into stage 1 for r190498.

[Bug other/54308] build regression in 190498 on ppc64/linux: legitimate_indirect_address_p undefined

[PHHargrove at lbl dot gov]

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

--- Comment #2 from Paul H. Hargrove  2012-08-18 
02:38:21 UTC ---
(In reply to comment #1)
> (Note, apparent s/4.2.1/4.1.2/g in initial description.)

Correct, I am sorry about that.

> I'd suggest updating to just a later gcc build, if you can find *only slightly
> newer* rpm:s; as for a x86_64-linux F 8 with gcc-4.1.2-33 ("gcc (GCC) 4.1.2
> 20070925 (Red Hat 4.1.2-33)"), I'm well into stage 1 for r190498.

I already have a 4.5.1 on that system and am well past the previous failure
point by using it.  I'll see how old I can go after that build is complete.

-Paul

[Bug other/54308] build regression in 190498 on ppc64/linux: legitimate_indirect_address_p undefined

[PHHargrove at lbl dot gov]

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

--- Comment #3 from Paul H. Hargrove  2012-08-18 
03:02:36 UTC ---
(In reply to comment #1)
> I'd suggest updating to just a later gcc build, if you can find *only slightly
> newer* rpm:s; as for a x86_64-linux F 8 with gcc-4.1.2-33 ("gcc (GCC) 4.1.2
> 20070925 (Red Hat 4.1.2-33)"), I'm well into stage 1 for r190498.

Alas use of the Fedora 8 binary RPMs is out as the libmudflap depends on the
Fedora 8 glib, and therefore would require a complete update of my system.

I am looking at the SRPMS for 4.1.2-27.fc7 and later may try 4.1.2-33 as you've
suggested.

I CAN report that building w/ GCC 4.5.1 (built from pristine gcc.gnu.org
sources) works fine.

[Bug c/52991] attribute packed broken on mingw32?

[daniel.c.klauer at web dot de]

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

daniel.c.klauer at web dot de changed:

   What|Removed |Added

 CC||daniel.c.klauer at web dot
   ||de

--- Comment #1 from daniel.c.klauer at web dot de 2012-08-18 03:37:01 UTC ---
I think I may have encountered this issue aswell. For example, given the
following example program:


#include 
#include 

struct A {
short s;
struct { int i; };
} __attribute__((__packed__));

struct B {
short s;
struct { int i; } __attribute__((__packed__));
} __attribute__((__packed__));

struct C {
struct { int i; };
short s;
} __attribute__((__packed__));

int main() {
printf("sizeof(struct A) == %i\n", (int)sizeof(struct A));
printf("sizeof(struct B) == %i\n", (int)sizeof(struct B));
printf("sizeof(struct C) == %i\n", (int)sizeof(struct C));
return 0;
}


with TDM-GCC's mingw32 gcc 4.6.1, all sizes are 6, and for comparison, with
Ubuntu's i686-linux-gnu gcc 4.6.3, all sizes are 6.

However, with mingw.org's gcc 4.7.0, sizeof(A) == 8. B and C still are 6, as
expected; A on the other hand apparently is not being packed, despite the
__attribute__((__packed__)).

[Bug c/52991] attribute packed broken on mingw32?

[daniel.c.klauer at web dot de]

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

--- Comment #2 from daniel.c.klauer at web dot de 2012-08-18 04:00:51 UTC ---
The -mms-bitfields option seems to trigger the wrong behaviour. As pointed out
by http://gcc.gnu.org/gcc-4.7/changes.html it is enabled by default since
4.7.0, and using -mms-bitfields when compiling with TDM-GCC 4.6.1 also causes
the wrong behaviour.

In contrast, compiling with -mno-ms-bitfields makes the example programs work
as expected under gcc 4.7.0.

[Bug c++/54309] New: type alias accessing class template enum type member fails

[paul at preney dot ca]

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

 Bug #: 54309
   Summary: type alias accessing class template enum type member
fails
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: p...@preney.ca


Created attachment 28046
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28046
Source code demonstrating the bug.

This is easier to see not working than to describe. The code that does not work
(i.e., "not ok: BUG" comment in the example) works if you replace the using
type alias with a typedef instead though (which means that is a work-around for
now).

This bug was tested with these versions of GCC:

  g++ v4.7.0
  g++ v4.8.0 (snapshot 20120812)

The error message (from GCC v4.8):

$ g++-4.8.0-alpha20120812 -std=c++11 gcc-cxx-bug.cxx 
gcc-cxx-bug.cxx: In instantiation of ‘void func() [with T = int]’:
gcc-cxx-bug.cxx:25:13:   required from here
gcc-cxx-bug.cxx:15:24: error: no type named ‘Stuff’ in ‘using test = class
Foo’
   typename test::Stuff b = test::Stuff::beta; // not ok: BUG
^
gcc-cxx-bug.cxx:15:24: error: no type named ‘Stuff’ in ‘using test = class
Foo’
gcc-cxx-bug.cxx:15:24: error: no type named ‘Stuff’ in ‘using test = class
Foo’
$

(I also tried this code with clang++ (v3.1) and it compiles successfully as
expected.)


It appears to only occur when a using type alias (i.e., the "test" alias in the
example) is used to access a template class' member that is an enum type (i.e.,
"Foo::Stuff" in the example) when the class template parameter is not
hard-coded using the using type alias (i.e., Foo is used but Foo is
okay). The code triggering the issue follows and is attached.


template 
class Foo
{
  public:
enum class Stuff { alpha, beta };
};

template 
void func()
{
  typename Foo::Stuff a = Foo::Stuff::alpha; // ok
  a = a;

  using test = Foo;
  typename test::Stuff b = test::Stuff::beta; // not ok: BUG
  b = b;

  typedef Foo test2;
  typename test2::Stuff c = test2::Stuff::beta; // ok
  c = c;
}

int main()
{
  func();

  {
Foo::Stuff a = Foo::Stuff::alpha; // ok
a = a;

using test = Foo;
typename test::Stuff b = test::Stuff::beta; // ok
b = b;

typedef Foo test2;
typename test2::Stuff c = test2::Stuff::beta; // ok
c = c;
  }
}

[Bug c++/54309] [C++11] type alias accessing class template enum type member fails

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Keywords||rejects-valid
   Last reconfirmed||2012-08-18
 Ever Confirmed|0   |1
Summary|type alias accessing class  |[C++11] type alias
   |template enum type member   |accessing class template
   |fails   |enum type member fails
   Severity|major   |normal

--- Comment #1 from Andrew Pinski  2012-08-18 
06:02:03 UTC ---
It looks like the using alias is not setup to late bind.

[Bug c++/54309] [C++11] type alias accessing class template typename

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|[C++11] type alias  |[C++11] type alias
   |accessing class template|accessing class template
   |enum type member fails  |typename

--- Comment #2 from Andrew Pinski  2012-08-18 
06:05:37 UTC ---
Also enum is not the only issue, it is an issue with any subnames of the type
alias.
template 
struct Foo
{
typedef int Stuff;
};

template 
void func()
{
  typename Foo::Stuff a = 1;
  a = a;

  using test = Foo;
  typename test::Stuff b;
  b = b;

  typedef Foo test2;
  typename test2::Stuff c = 2;
  c = c;
}

int main()
{
  func();

  {
Foo::Stuff a = 1;
a = a;

using test = Foo;
typename test::Stuff b = 2;
b = b;

typedef Foo test2;
typename test2::Stuff c = 3;
c = c;
  }
}