[Bug debug/55364] ICE: in remove_addr_table_entry, at dwarf2out.c:4201 with -O -gsplit-dwarf

[mpolacek at gcc dot gnu.org]

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



Marek Polacek  changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed||2012-11-20

 CC||mpolacek at gcc dot

   ||gnu.org, sterling at gcc

   ||dot gnu.org

   Target Milestone|--- |4.8.0

 Ever Confirmed|0   |1



--- Comment #1 from Marek Polacek  2012-11-20 
08:00:13 UTC ---

Confirmed.  Started with

http://gcc.gnu.org/viewcvs?view=revision&revision=193267

[Bug c++/55408] ICE for member template definition with non-type variadic parameter

[mpolacek at gcc dot gnu.org]

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



Marek Polacek  changed:



   What|Removed |Added



 CC||mpolacek at gcc dot gnu.org



--- Comment #1 from Marek Polacek  2012-11-20 
08:18:57 UTC ---

Happens even with r188998.

[Bug middle-end/55403] [4.8 Regression] ICE building libitm

[rsandifo at gcc dot gnu.org]

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



rsand...@gcc.gnu.org  changed:



   What|Removed |Added



 CC||rsandifo at gcc dot gnu.org



--- Comment #4 from rsandifo at gcc dot gnu.org  
2012-11-20 08:26:25 UTC ---

(In reply to comment #1)

> Richard S, I suspect your bit field changes.  I'll have a look at it

> myself tomorrow if you don't find it first.



Yeah, I expect it is, sorry.  'Fraid I couldn't get the testcase to fail

in a cross compiler though.  At first I was getting a load of warnings

about visiblity not being supported, etc., so I built cross binutils

and pointed configure at them.  That silenced all the warnings but the

cc1plus command still succeeded.  I suspect something important is

still configured out, but I couldn't tell what from a scan of auto-host.h.

[Bug middle-end/54921] [4.8 Regression] wrong code with -Os -fno-omit-frame-pointer -fsched2-use-superblocks -fstack-protector -ftree-slp-vectorize

[jakub at gcc dot gnu.org]

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



--- Comment #5 from Jakub Jelinek  2012-11-20 
08:34:51 UTC ---

Author: jakub

Date: Tue Nov 20 08:34:43 2012

New Revision: 193647



URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=193647

Log:

PR rtl-optimization/54921

* cselib.h (fp_setter_insn): New prototype.

* cselib.c (fp_setter_insn): New function.

(cselib_process_insn): If frame_pointer_needed,

call cselib_invalidate_rtx (stack_pointer_rtx) after

processing a frame pointer setter.

* var-tracking.c (fp_setter): Removed.

(vt_initialize): Use fp_setter_insn instead of fp_setter.



* gcc.dg/pr54921.c: New test.



Added:

trunk/gcc/testsuite/gcc.dg/pr54921.c

Modified:

trunk/gcc/ChangeLog

trunk/gcc/cselib.c

trunk/gcc/cselib.h

trunk/gcc/testsuite/ChangeLog

trunk/gcc/var-tracking.c

[Bug bootstrap/55370] [4.8 Regression] Bad libgcc.map

[jakub at gcc dot gnu.org]

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



--- Comment #2 from Jakub Jelinek  2012-11-20 
08:36:37 UTC ---

Author: jakub

Date: Tue Nov 20 08:36:31 2012

New Revision: 193648



URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=193648

Log:

PR bootstrap/55370

* libgcc-std.ver.in: Add GCC_4.8.0 and %inherit for it.



Modified:

trunk/libgcc/ChangeLog

trunk/libgcc/libgcc-std.ver.in

[Bug debug/55094] [4.7/4.8 Regression] ICE in maybe_record_trace_start, at dwarf2cfi.c:2224

[jakub at gcc dot gnu.org]

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



--- Comment #3 from Jakub Jelinek  2012-11-20 
08:38:22 UTC ---

Author: jakub

Date: Tue Nov 20 08:38:11 2012

New Revision: 193649



URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=193649

Log:

PR middle-end/55094

* builtins.c (expand_builtin_trap): Add REG_ARGS_SIZE note

on the trap insn for !ACCUMULATE_OUTGOING_ARGS.

* cfgcleanup.c (outgoing_edges_match): Don't look at debug insns

on the first old_insns_match_p call.  For !ACCUMULATE_OUTGOING_ARGS

fail if the last real insn doesn't have REG_ARGS_SIZE note.



* gcc.dg/pr55094.c: New test.



Added:

trunk/gcc/testsuite/gcc.dg/pr55094.c

Modified:

trunk/gcc/ChangeLog

trunk/gcc/builtins.c

trunk/gcc/cfgcleanup.c

trunk/gcc/testsuite/ChangeLog

[Bug middle-end/54921] [4.8 Regression] wrong code with -Os -fno-omit-frame-pointer -fsched2-use-superblocks -fstack-protector -ftree-slp-vectorize

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



 Status|ASSIGNED|RESOLVED

 Resolution||FIXED



--- Comment #6 from Jakub Jelinek  2012-11-20 
08:39:58 UTC ---

Fixed.

[Bug bootstrap/55370] [4.8 Regression] Bad libgcc.map

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



 Status|ASSIGNED|RESOLVED

 Resolution||FIXED



--- Comment #3 from Jakub Jelinek  2012-11-20 
08:41:54 UTC ---

Fixed.

[Bug debug/55094] [4.7 Regression] ICE in maybe_record_trace_start, at dwarf2cfi.c:2224

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



Summary|[4.7/4.8 Regression] ICE in |[4.7 Regression] ICE in

   |maybe_record_trace_start,   |maybe_record_trace_start,

   |at dwarf2cfi.c:2224 |at dwarf2cfi.c:2224



--- Comment #4 from Jakub Jelinek  2012-11-20 
08:42:46 UTC ---

Fixed on the trunk so far.

[Bug rtl-optimization/55396] -O2 -m32 -fno-omit-frame-pointer: internal compiler error: in check_rtl, at lra.c:2007

[markus at trippelsdorf dot de]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||markus at trippelsdorf dot
   ||de

--- Comment #1 from Markus Trippelsdorf  
2012-11-20 08:43:17 UTC ---
markus@x4 /tmp % cat test.i
int a[0];
struct thread_struct
{
int sp;
int ip;
}
;
struct task_struct
{
struct thread_struct thread;
struct task_struct *curr;
}
b, h, *l;
int c, d, e, f, g, m;
void
fn1 ()
{
struct task_struct *i;
int *j;
int k;
need_resched:
k = 0;
h = *(typeof (&b)) a[k];
j = 0;
i = 0;
++*j;
struct task_struct *n = i;
asm ("popl %%ebp\n\t" : "=c" (d), "=d" (e), "=S" (f),
 "=D" (g):[next_sp] "mm" (n->thread.ip), [prev] "ad" (0));
goto need_resched;
}

markus@x4 /tmp % gcc -O2 -c -m32 -fno-omit-frame-pointer test.i
test.i: In function ‘fn1’:
test.i:31:1: error: unrecognizable insn:
 }
 ^
(insn 25 47 26 3 (parallel [
(set (reg:SI 2 cx [77])
(asm_operands:SI ("popl %%ebp
") ("=c") 0 [
(mem:SI (plus:SI (reg:SI 2 cx [88])
(const_int 4 [0x4])) [2 MEM[(struct task_struct
*)0B].thread.ip+0 S4 A32])
(reg:SI 2 cx [88])
]
 [
(asm_input:SI ("mm") (null):0)
(asm_input:SI ("ad") (null):0)
]
 [] test.i:28))
(set (reg:SI 1 dx [78])
(asm_operands:SI ("popl %%ebp
") ("=d") 1 [
(mem:SI (plus:SI (reg:SI 2 cx [88])
(const_int 4 [0x4])) [2 MEM[(struct task_struct
*)0B].thread.ip+0 S4 A32])
(reg:SI 2 cx [88])
]
 [
(asm_input:SI ("mm") (null):0)
(asm_input:SI ("ad") (null):0)
]
 [] test.i:28))
(set (reg:SI 4 si [79])
(asm_operands:SI ("popl %%ebp
") ("=S") 2 [
(mem:SI (plus:SI (reg:SI 2 cx [88])
(const_int 4 [0x4])) [2 MEM[(struct task_struct
*)0B].thread.ip+0 S4 A32])
(reg:SI 2 cx [88])
]
 [
(asm_input:SI ("mm") (null):0)
(asm_input:SI ("ad") (null):0)
]
 [] test.i:28))
(set (reg:SI 5 di [80])
(asm_operands:SI ("popl %%ebp
") ("=D") 3 [
(mem:SI (plus:SI (reg:SI 2 cx [88])
(const_int 4 [0x4])) [2 MEM[(struct task_struct
*)0B].thread.ip+0 S4 A32])
(reg:SI 2 cx [88])
]
 [
(asm_input:SI ("mm") (null):0)
(asm_input:SI ("ad") (null):0)
]
 [] test.i:28))
(clobber (reg:QI 18 fpsr))
(clobber (reg:QI 17 flags))
]) test.i:28 -1
 (expr_list:REG_DEAD (reg:SI 2 cx [88])
(nil)))
test.i:31:1: internal compiler error: in reload_cse_simplify_operands, at
postreload.c:413
0x780d4a _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/home/markus/gcc/gcc/rtl-error.c:110
0x780d79 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/home/markus/gcc/gcc/rtl-error.c:118
0x73bfbb reload_cse_simplify_operands
/home/markus/gcc/gcc/postreload.c:413
0x73d52c reload_cse_simplify
/home/markus/gcc/gcc/postreload.c:183
0x73d52c reload_cse_regs_1
/home/markus/gcc/gcc/postreload.c:222
0x73d98b reload_cse_regs
/home/markus/gcc/gcc/postreload.c:70
0x73d98b rest_of_handle_postreload
/home/markus/gcc/gcc/postreload.c:2289
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug libstdc++/55409] New: std::list not properly wrapping access to custom allocator through allocator_traits

[benjamin.kircher at gmail dot com]

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

 Bug #: 55409
   Summary: std::list not properly wrapping access to custom
allocator through allocator_traits
Classification: Unclassified
   Product: gcc
   Version: 4.7.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: benjamin.kirc...@gmail.com


Created attachment 28741
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28741
Small example showing simple custom allocator with std::list and std::vector

The attached source file compiles fine with a std::vector as container_type.
Using std::list however, compilation fails with the error message given below.
Expected behavior is that it compiles with std::list as like with std::vector.

$ gcc --version
gcc (Debian 4.7.2-4) 4.7.2


$ cat main.cpp
template class my_alloc
{
// class template supporting the minimal interface according to 17.6.3.5
};

int main()
{
//typedef std::vector> container_type;
typedef std::list> container_type;
container_type cont;
cont.push_back(11);
cont.push_back(22);
cont.push_back(33);
return 0;
}


$ g++ -g -std=c++11 -Wall -Wextra -pedantic main.cpp

/usr/include/c++/4.7/bits/stl_list.h: In instantiation of ‘class std::list >’:
main.cpp:56:20:   required from here
/usr/include/c++/4.7/bits/stl_list.h:449:58: error: no type named ‘pointer’ in
‘std::list >::_Tp_alloc_type {aka class my_alloc}’
/usr/include/c++/4.7/bits/stl_list.h:450:58: error: no type named
‘const_pointer’ in ‘std::list >::_Tp_alloc_type {aka class
my_alloc}’
/usr/include/c++/4.7/bits/stl_list.h:451:58: error: no type named ‘reference’
in ‘std::list >::_Tp_alloc_type {aka class my_alloc}’
/usr/include/c++/4.7/bits/stl_list.h:452:58: error: no type named
‘const_reference’ in ‘std::list >::_Tp_alloc_type {aka class
my_alloc}’

and so on.

[Bug testsuite/55188] [4.8 regression] FAIL: gcc.dg/pr19105.c scan-tree-dump-times reassoc1 "Optimizing range tests v_[0-9]*.D. -.2, 2. and -.3, 4.[\n\r]* into" 1

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



 Status|ASSIGNED|RESOLVED

 Resolution||FIXED



--- Comment #4 from Jakub Jelinek  2012-11-20 
09:06:12 UTC ---

Fixed.

[Bug libstdc++/55409] std::list not properly wrapping access to custom allocator through allocator_traits

[redi at gcc dot gnu.org]

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



--- Comment #1 from Jonathan Wakely  2012-11-20 
09:13:36 UTC ---

This is known and documented.  I'm actually working on std::list next, but I

don't know if it will be done for 4.8 or not.

[Bug middle-end/54630] [4.8 Regression] GCC 4.8 --enable-languages=c build fails: Undefined symbols: ___cxa_guard_acquire and ___cxa_guard_release

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



 Status|NEW |RESOLVED

 CC||jakub at gcc dot gnu.org

 Resolution||INVALID



--- Comment #12 from Jakub Jelinek  2012-11-20 
09:23:33 UTC ---

Closing as user error, although the usage of local statics has been changed,

but future local statics might appear.

[Bug libstdc++/55409] std::list not properly wrapping access to custom allocator through allocator_traits

[redi at gcc dot gnu.org]

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



--- Comment #2 from Jonathan Wakely  2012-11-20 
09:24:53 UTC ---

N.B. the minimal allocator interface requires operator== and operator!=, and 

max_size and rebind are not required.

[Bug rtl-optimization/54540] [4.8 regression] postreload incorrectly simplifies stack adjustment into constant load into SP

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



 CC||jakub at gcc dot gnu.org



--- Comment #5 from Jakub Jelinek  2012-11-20 
09:26:52 UTC ---

Can this be closed now?

[Bug libstdc++/55409] std::list not properly wrapping access to custom allocator through allocator_traits

[benjamin.kircher at gmail dot com]

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



--- Comment #3 from Benjamin Kircher  
2012-11-20 09:31:07 UTC ---

Thank you for working on it and for the remark.



NB: For the next time, where can I find the documentation?

[Bug other/55410] New: [asan] bit field accesses are not instrumented

[konstantin.s.serebryany at gmail dot com]

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



 Bug #: 55410

   Summary: [asan] bit field accesses are not instrumented

Classification: Unclassified

   Product: gcc

   Version: unknown

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: other

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: konstantin.s.serebry...@gmail.com

CC: dseke...@redhat.com, dvyu...@google.com,

ja...@gcc.gnu.org, w...@gcc.gnu.org





[There is no rush with this, I just want this issue to be recorded]



% cat bitf.c 

typedef struct {

  int a:12;

  int b:20;

} foo;



int geta(foo *f) {

  return f->a;

}

% clang -fsanitize=address -O2 -S -o - bitf.c 2>&1 | grep __asan_report 

callq   __asan_report_load4

% gcc -faddress-sanitizer -O2 -S -o - bitf.c 2>&1 | grep __asan_report 

%

[Bug rtl-optimization/54540] [4.8 regression] postreload incorrectly simplifies stack adjustment into constant load into SP

[rearnsha at gcc dot gnu.org]

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



--- Comment #6 from Richard Earnshaw  2012-11-20 
09:35:02 UTC ---

(In reply to comment #5)

> Can this be closed now?



Well the comment 4 is still relevant, I suspect that there are still latent

issues in postreload.

[Bug libgomp/55411] New: OMP threads lose their OMP_WAIT_POLICY when another OMP thread gets destructed

[jk3064 at arcor dot de]

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



 Bug #: 55411

   Summary: OMP threads lose their OMP_WAIT_POLICY when another

OMP thread gets destructed

Classification: Unclassified

   Product: gcc

   Version: 4.6.3

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: libgomp

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: jk3...@arcor.de





So there are 2 bugs:

 * the omp workers of a boost::thread are ignoring OMP_WAIT_POLICY

 * once the boost::thread gets destructed the main-thread's omp worker's

WAIT_POLICY get lost



used to compile the example:

g++ -fopenmp -lgomp -lboost_system -lboost_thread-mt -o foo.bin -O2 foo_omp.c



tested with gentoo:

Just run the example with `export OMP_WAIT_POLICY="ACTIVE"` and watch it in

another window with htop. First all created omp threads use 100%, then the

boost::thread and its omp workers are spawned (all with ~0% cpu usage, still

the main-thread's omp workers use 100%). Then the boost::thread gets destructed

and the main-threads omp workers fallback to 0% cpu usage.



PS: It would be nice if there was a GOMP_DEBUG to enable a more verbose output,

esp. to debug GOMP_SPINCOUNT & OMP_PROC_BIND.

[Bug libgomp/55411] OMP threads lose their OMP_WAIT_POLICY when another OMP thread gets destructed

[jk3064 at arcor dot de]

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



--- Comment #1 from jk3064 at arcor dot de 2012-11-20 10:04:08 UTC ---

Created attachment 28742

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28742

example testcase



compile with: g++ -fopenmp -lgomp -lboost_system -lboost_thread-mt -o foo.bin

-O2 foo_omp.c

[Bug other/55376] [asan] libsanitizer/README.gcc must contain the exact steps to do code changes and to port code from upstream

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #7 from Manuel López-Ibáñez  2012-11-20 
10:17:15 UTC ---
> When pulling a new update, what text do we expect in the ChangeLog? 
> Is the upstream SVN revision enough, or we want to copy all commit messages?

Why do you want to bother with a ChangeLog? libsanitizer is a upstream non-GNU
library, and for those the GNU coding conventions do not (need to) apply. The
go FE does not have a Changelog (only the glue code).

[Bug libstdc++/55409] std::list not properly wrapping access to custom allocator through allocator_traits

[redi at gcc dot gnu.org]

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



Jonathan Wakely  changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed||2012-11-20

 Ever Confirmed|0   |1



--- Comment #4 from Jonathan Wakely  2012-11-20 
10:30:32 UTC ---

in the manual

http://gcc.gnu.org/onlinedocs/libstdc++/manual/status.html#status.iso.2011

"Only vector meets the requirements relating to allocator use and propagation."



and the release notes for 4.7

http://gcc.gnu.org/gcc-4.7/changes.html

"vector meets the allocator-aware container requirements"



In GCC 4.8 std::forward_list is also allocator-aware, but I haven't updated the

release notes yet.



Confirming but don't hold your breath for it to be fixed in 4.8

[Bug c++/55408] ICE for member template definition with non-type variadic parameter

[paolo.carlini at oracle dot com]

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



Paolo Carlini  changed:



   What|Removed |Added



   Keywords||ice-on-invalid-code

 Status|UNCONFIRMED |NEW

   Last reconfirmed||2012-11-20

 Ever Confirmed|0   |1

[Bug treelang/55412] New: pr47276.c fails with -fpic option.

[aivchenk at gmail dot com]

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

 Bug #: 55412
   Summary: pr47276.c fails with -fpic option.
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: treelang
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: aivch...@gmail.com


When trying to compile pr47276.c with additional -fpic option I've got the
following error:

pr47276.c:36:1: warning: asm declaration ignored due to conflict with previous
rename [-Wpragmas]
 extern __typeof (__vsyslog_chk) __vsyslog_chk __asm__ ("" ASMNAME
("__GI___vsyslog_chk")) __attribute__ ((visibility ("hidden")));
 ^
../../../../gcc/gcc/testsuite/gcc.dg/pr47276.c:25:123: error:
‘__EI___vsyslog_chk’ aliased to undefined symbol ‘__GI___vsyslog_chk’
 extern __typeof (__vsyslog_chk) __EI___vsyslog_chk __asm__("" ASMNAME
("__vsyslog_chk")); extern __typeof (__vsyslog_chk) __EI___vsyslog_chk
__attribute__((alias ("" "__GI___vsyslog_chk")));

[Bug rtl-optimization/54540] postreload incorrectly simplifies stack adjustment into constant load into SP

[steven at gcc dot gnu.org]

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



Steven Bosscher  changed:



   What|Removed |Added



 CC||steven at gcc dot gnu.org



--- Comment #7 from Steven Bosscher  2012-11-20 
11:09:12 UTC ---

(In reply to comment #6)

> (In reply to comment #5)

> > Can this be closed now?

> 

> Well the comment 4 is still relevant, I suspect that there are still latent

> issues in postreload.



Are we going to keep a bug report open because of a _suspected_ bug, with

no test case to reproduce the problem with the current trunk?  Any new bug

report without a test case would be almost immediately closed as INVALID,

and I see no good reason to do things differently for an existing PR with

a fix applied and no test case remaining to reproduce the issue.



Have you at least looked at postreload (using a compiler without your fix

for reload) to see where things go bad?  I suspect the bad insn is created

in reload_combine_recognize_pattern.  You could try to rule out move2add

using debug counters (-fdbg-cnt=cse2_move2add:0) at least.

[Bug c++/55402] Compiling large initializer lists never finishes

[paolo.carlini at oracle dot com]

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



Paolo Carlini  changed:



   What|Removed |Added



 CC||steven at gcc dot gnu.org



--- Comment #7 from Paolo Carlini  2012-11-20 
11:13:10 UTC ---

Steven, are you willing to have a look and figure out what we are doing wrong?

[Bug c++/55402] Compiling large initializer lists never finishes

[steven at gcc dot gnu.org]

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



Steven Bosscher  changed:



   What|Removed |Added



   Keywords||compile-time-hog

 Status|NEW |ASSIGNED

 CC|steven at gcc dot gnu.org   |

 AssignedTo|unassigned at gcc dot   |steven at gcc dot gnu.org

   |gnu.org |



--- Comment #8 from Steven Bosscher  2012-11-20 
11:20:23 UTC ---

I'll have a look...

[Bug tree-optimization/55260] [4.8 Regression] ICE: in ipa_get_parm_lattices, at ipa-cp.c:263 with -O2 -fno-inline -fipa-cp-clone

[jamborm at gcc dot gnu.org]

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



--- Comment #5 from Martin Jambor  2012-11-20 
11:20:47 UTC ---

Author: jamborm

Date: Tue Nov 20 11:20:41 2012

New Revision: 193657



URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=193657

Log:

2012-11-20  Martin Jambor  



PR tree-optimization/55260

* ipa-cp.c (find_aggregate_values_for_callers_subset): Rename info to

dest_info, use caller_info instead of info when determining whether

callee is a clone.



* testsuite/g++.dg/torture/pr55260-1.C: New test.





Added:

trunk/gcc/testsuite/g++.dg/torture/pr55260-1.C

Modified:

trunk/gcc/ChangeLog

trunk/gcc/ipa-cp.c

trunk/gcc/testsuite/ChangeLog

[Bug c++/55402] Compiling large initializer lists never finishes

[jakub at gcc dot gnu.org]

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



--- Comment #9 from Jakub Jelinek  2012-11-20 
11:43:27 UTC ---

I believe the expensive part here is the EH, we end up with > 56000 nested

try/finally constructs.  With -fno-exceptions this compiles in reasonable time

(even for the insane testcase), at least without optimizations, with

optimizations costly phases are e.g. the inliner (remember there are hundreds

of thousands of calls to inline).

For EH, I think it would help if at least for the larger initializer list the

compiler emitted just a single try/finally, where if exception is thrown during

construction of some element, it would just loop over all the older elements in

the array (starting from previous one down to first) that would destruct them.

[Bug tree-optimization/54471] [4.8 Regression] FAIL: gcc.dg/sms-8.c execution test

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



 Status|UNCONFIRMED |WAITING

   Last reconfirmed|2012-09-28 00:00:00 |2012-11-20

 CC||jakub at gcc dot gnu.org

 Ever Confirmed|0   |1



--- Comment #1 from Jakub Jelinek  2012-11-20 
12:06:16 UTC ---

Can't reproduce that with a cross.  The tree optimizers definitely don't

optimize it into abort, and neither the assembly looks like what you are

mentioning above.

[Bug treelang/55412] pr47276.c fails with -fpic option.

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



 CC||jakub at gcc dot gnu.org



--- Comment #1 from Jakub Jelinek  2012-11-20 
12:15:01 UTC ---

This fails all the way back to gcc 4.0 this way, and given that glibc itself

builds fine even with gcc 4.7, I assume the testcase just doesn't match what

glibc contained accurately.

[Bug libfortran/30162] [4.7/4.8 Regression] I/O with named pipes does not work

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



   Priority|P3  |P4

 CC||jakub at gcc dot gnu.org

[Bug c++/55402] Compiling large initializer lists never finishes

[paolo.carlini at oracle dot com]

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



Paolo Carlini  changed:



   What|Removed |Added



 CC||jason at gcc dot gnu.org



--- Comment #10 from Paolo Carlini  2012-11-20 
12:26:13 UTC ---

I see, thanks Jakub. Let's add Jason too in CC. For now only wanted to add

that, for the exceptions, an hackish but effective local workaround would be

marking the constructor noexcept.

[Bug middle-end/54860] [4.8 Regression]: build fails when configuring libgfortran due to recent "attribute" changes in core gcc

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



 Status|ASSIGNED|RESOLVED

 CC||jakub at gcc dot gnu.org

 Resolution||FIXED

   Target Milestone|--- |4.8.0



--- Comment #19 from Jakub Jelinek  2012-11-20 
12:26:29 UTC ---

Assuming fixed.

[Bug fortran/55314] [4.6/4.7/4.8 Regression] Rejects some valid ALLOCATE statements

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



   Priority|P3  |P4

 CC||jakub at gcc dot gnu.org

[Bug middle-end/55381] [4.8 Regression]: build fails on cris-elf building libgfortran with host-gcc-4.4, ICE compiling matmul_i1.c

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

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

--- Comment #7 from Andreas Schwab  2012-11-20 13:01:31 
UTC ---
Also broken on ia64 with gcc 4.3.2.

/usr/local/gcc/test/Build/./gcc/xgcc -B/usr/local/gcc/test/Build/./gcc/
-B/usr/ia64-suse-linux/bin/ -B/usr/ia64-suse-linux/lib/ -isystem
/usr/ia64-suse-linux/include -isystem /usr/ia64-suse-linux/sys-include-O2
-g -O2  -O2 -g -DIN_GCC   -DUSE_LIBUNWIND_EXCEPTIONS -W -Wall -Wwrite-strings
-Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition 
-isystem ./include   -fPIC -DUSE_GAS_SYMVER -g -DIN_LIBGCC2 -fbuilding-libgcc
-fno-stack-protector   -fPIC -DUSE_GAS_SYMVER -I. -I. -I../.././gcc
-I../../../libgcc -I../../../libgcc/. -I../../../libgcc/../gcc
-I../../../libgcc/../include  -DHAVE_CC_TLS  -o _mulvdi3.o -MT _mulvdi3.o -MD
-MP -MF _mulvdi3.dep -DL_mulvdi3 -c ../../../libgcc/libgcc2.c
-fvisibility=hidden -DHIDE_EXPORTS
../../../libgcc/libgcc2.c: In function ‘__mulvti3’:
../../../libgcc/libgcc2.c:397:1: internal compiler error: Segmentation fault
 }
 ^
0x408bc6cf crash_signal
../../gcc/toplev.c:334
0x40cb49bf vec::reserve(unsigned int, bool)
../../gcc/vec.h:1443
0x40cb49bf vec::safe_push(rtx_def* const&)
../../gcc/vec.h:1540
0x40cb49bf values_to_stack
../../gcc/var-tracking.c:8585
0x41083dcf htab_traverse_noresize
../../libiberty/hashtab.c:784
0x40cabdbf process_changed_values
../../gcc/var-tracking.c:8704
0x40cac1bf emit_notes_for_changes
../../gcc/var-tracking.c:8743
0x40cadaaf emit_notes_for_differences
../../gcc/var-tracking.c:8863
0x40cadaaf vt_emit_notes
../../gcc/var-tracking.c:9238
0x40cb476f variable_tracking_main_1
../../gcc/var-tracking.c:10066
0x40cb476f variable_tracking_main()
../../gcc/var-tracking.c:10080
0x40d0254f ia64_reorg
../../gcc/config/ia64/ia64.c:9798
0x407fd05f rest_of_handle_machine_reorg
../../gcc/reorg.c:4152

[Bug target/54781] [4.8 Regression] ICE in refs_may_alias_p_1, at tree-ssa-alias.c:1124

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed||2012-11-20

 CC||jakub at gcc dot gnu.org,

   ||ramana at gcc dot gnu.org

  Component|middle-end  |target

   Target Milestone|--- |4.8.0

 Ever Confirmed|0   |1



--- Comment #3 from Jakub Jelinek  2012-11-20 
13:50:08 UTC ---

Looks like a target bug to me, neon_dereference_pointer creates an invalid

MEM_REF (the first operand on it doesn't satisfy the required

is_gimple_mem_ref_addr predicate) and this invalid MEM_REF is then added by

expand_normal into the MEM_EXPR of the MEM, and the aliasing code is then upset

about it.



In particular, the MEM_REF operand is &z[x_5(D)].  The reason why &z[x_5(D)] is

in the CALL_EXPR_ARG of the builtin is expand_call_stmt optimization:

  /* TER addresses into arguments of builtin functions so we have a

 chance to infer more correct alignment information.  See PR39954.  */

Best would be if in this case the backend could find out the original argument,

which was a SSA_NAME, and use that as the MEM_REF operand instead, but I'm

afraid we don't have such a way right now.  So perhaps the backend could clear

MEM_EXPR

if it is invalid:

case NEON_ARG_MEMORY:

...

  if (MEM_EXPR (op[argc]) && TREE_CODE (MEM_EXPR (op[argc])) == MEM_REF

  && !is_gimple_mem_ref_addr (TREE_OPERAND (MEM_EXPR (op[argc]), 0)))

/* Make sure MEM_EXPR created by neon_dereference_pointer isn't

invalid.  */

set_mem_expr (op[argc], NULL_RTX);

[Bug libstdc++/55413] New: [LTO] hashtable.h:1648 '__bbegin_bkt' may be used uninitialized in this function [-Werror=maybe-uninitialized]

[david.abdurachmanov at gmail dot com]

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



 Bug #: 55413

   Summary: [LTO] hashtable.h:1648 '__bbegin_bkt' may be used

uninitialized in this function

[-Werror=maybe-uninitialized]

Classification: Unclassified

   Product: gcc

   Version: 4.7.2

Status: UNCONFIRMED

  Severity: minor

  Priority: P3

 Component: libstdc++

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: david.abdurachma...@gmail.com





Hi,



I have enabled -Werror=maybe-uninitialized and normal builds works fine. LTO

builds crashed with error coming from hashtable.h. According to he code,

__bbegin_bkt is not explicitly initialized to anything.



1637   std::size_t __bbegin_bkt;



1648 __new_buckets[__bbegin_bkt] = __p; 

1649 __bbegin_bkt = __bkt;



Similar issues MIGHT be on the next (in file) template.



1678   std::size_t __bbegin_bkt;



1724 __new_buckets[__bbegin_bkt] = __p;

1725   __bbegin_bkt = __bkt;



This is a minor issue, but comments would be welcomed. Is LTO + diagnostics

issue or STL issue? Is the a way to silence them from user-code side? (I tried

GCC diagnostics pragma w/o results).



Attaching *.ii.



## GCC VERSION ##



Using built-in specs.

COLLECT_GCC=gcc

COLLECT_LTO_WRAPPER=/afs/cern.ch/cms/slc5_amd64_gcc472/external/gcc/4.7.2/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.7.2/lto-wrapper

Target: x86_64-unknown-linux-gnu

Configured with: ../configure

--prefix=/build/davidlt/build-BOOTSTRAP_slc5_amd64_gcc472/b/tmp/BUILDROOT/3526ecf0ad2656770a1b0f9f5e8d92a9/opt/cmssw/slc5_amd64_gcc472/external/gcc/4.7.2

--disable-multilib --disable-nls --enable-languages=c,c++,fortran

--enable-gold=yes --enable-lto

--with-gmp=/build/davidlt/build-BOOTSTRAP_slc5_amd64_gcc472/b/tmp/BUILDROOT/3526ecf0ad2656770a1b0f9f5e8d92a9/opt/cmssw/slc5_amd64_gcc472/external/gcc/4.7.2

--with-mpfr=/build/davidlt/build-BOOTSTRAP_slc5_amd64_gcc472/b/tmp/BUILDROOT/3526ecf0ad2656770a1b0f9f5e8d92a9/opt/cmssw/slc5_amd64_gcc472/external/gcc/4.7.2

--with-mpc=/build/davidlt/build-BOOTSTRAP_slc5_amd64_gcc472/b/tmp/BUILDROOT/3526ecf0ad2656770a1b0f9f5e8d92a9/opt/cmssw/slc5_amd64_gcc472/external/gcc/4.7.2

--with-ppl=/build/davidlt/build-BOOTSTRAP_slc5_amd64_gcc472/b/tmp/BUILDROOT/3526ecf0ad2656770a1b0f9f5e8d92a9/opt/cmssw/slc5_amd64_gcc472/external/gcc/4.7.2

--with-cloog=/build/davidlt/build-BOOTSTRAP_slc5_amd64_gcc472/b/tmp/BUILDROOT/3526ecf0ad2656770a1b0f9f5e8d92a9/opt/cmssw/slc5_amd64_gcc472/external/gcc/4.7.2

--enable-cloog-backend=isl --enable-shared CC='gcc -fPIC' CXX='c++ -fPIC'

CPP=cpp CXXCPP='c++ -E'

Thread model: posix

gcc version 4.7.2 (GCC)



## FULL ERROR ##



In file included from

/afs/cern.ch/cms/slc5_amd64_gcc472/external/gcc/4.7.2/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.2/../../../../include/c++/4.7.2/bits/stl_algobase.h:1026:0,

 from :97:

test.cc: In function 'main':

/afs/cern.ch/cms/slc5_amd64_gcc472/external/gcc/4.7.2/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.2/../../../../include/c++/4.7.2/bits/hashtable.h:1648:3:

error: '__bbegin_bkt' may be used uninitialized in this function

[-Werror=maybe-uninitialized]

In file included from

/afs/cern.ch/cms/slc5_amd64_gcc472/external/gcc/4.7.2/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.2/../../../../include/c++/4.7.2/bits/stl_algobase.h:1017:0,

 from :97:

/afs/cern.ch/cms/slc5_amd64_gcc472/external/gcc/4.7.2/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.2/../../../../include/c++/4.7.2/bits/hashtable.h:1637:19:

note: '__bbegin_bkt' was declared here

lto1: some warnings being treated as errors

lto-wrapper: /afs/cern.ch/cms/slc5_amd64_gcc472/external/gcc/4.7.2/bin/c++

returned 1 exit status

/afs/cern.ch/cms/slc5_amd64_gcc472/external/gcc/4.7.2/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.2/../../../../x86_64-unknown-linux-gnu/bin/ld:

fatal error: lto-wrapper failed

collect2: error: ld returned 1 exit status



## TESTCASE ##



#include 

struct S {  int id;  S(): id(0) {} };

int main(void) {

  std::unordered_map tmap;

  S & res = tmap[0];

  return 0;

}



## COMPILE LINE ##



c++ -v -save-temps -c -DGNU_GCC -D_GNU_SOURCE -O2 -pedantic -pthread -pipe

-Wno-vla -Werror=overflow -Wstrict-overflow -std=c++0x -msse3 -ftree-vectorize

-Wno-strict-overflow -Werror=array-bounds -Werror=format-contains-nul

-Werror=type-limits -fvisibility-inlines-hidden -fno-math-errno --param

vect-max-version-for-alias-checks=50 -felide-constructors -fmessage-length=0

-ftemplate-depth-300 -Wall -Wno-non-template-friend -Wno-long-long

-Wreturn-type -Wunused -Wparentheses -Wno-deprecated -Werror=return-type

-Werror=missing-braces -Werror=unused-value -Werror=address -Werror=format

-Werror=sign-compare -Werror=write-strings -Werror=delete-non-virtual-dtor

-Werror=maybe-uninitialized -Werror=strict-aliasing -Werror=narrowing

-We

[Bug libstdc++/55413] [LTO] hashtable.h:1648 '__bbegin_bkt' may be used uninitialized in this function [-Werror=maybe-uninitialized]

[david.abdurachmanov at gmail dot com]

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



--- Comment #1 from David Abdurachmanov  
2012-11-20 14:07:57 UTC ---

Created attachment 28743

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28743

Testcase used.

[Bug bootstrap/55387] [4.8 Regression] Build problem: malloc error in genautomata

[dnovillo at gcc dot gnu.org]

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



Diego Novillo  changed:



   What|Removed |Added



 CC||dnovillo at gcc dot gnu.org



--- Comment #3 from Diego Novillo  2012-11-20 
14:10:43 UTC ---

Can you show me the value of equiv_classes at frame #6? (inside minimize_DFA)

and frame #4?  (inside copy_equiv_class).  In both cases, it should be

{

  _vec = 0x0;

}



If not, then there is a problem with the initializer of equiv_classes in

minimize_DFA.

[Bug middle-end/55398] [4.8 Regression] va_arg usage with non-POD

[dnovillo at gcc dot gnu.org]

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



Diego Novillo  changed:



   What|Removed |Added



 CC||dnovillo at gcc dot gnu.org

 AssignedTo|unassigned at gcc dot   |dnovillo at gcc dot gnu.org

   |gnu.org |



--- Comment #7 from Diego Novillo  2012-11-20 
14:12:43 UTC ---

Fixing.

[Bug libstdc++/55413] [LTO] hashtable.h:1648 '__bbegin_bkt' may be used uninitialized in this function [-Werror=maybe-uninitialized]

[paolo.carlini at oracle dot com]

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



Paolo Carlini  changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed||2012-11-20

 CC||fdumont at gcc dot gnu.org

 AssignedTo|unassigned at gcc dot   |paolo.carlini at oracle dot

   |gnu.org |com

 Ever Confirmed|0   |1

   Severity|minor   |normal



--- Comment #2 from Paolo Carlini  2012-11-20 
14:15:54 UTC ---

I'm testing the obvious fix of initializing it to zero, likewise for __prev_bkt

[Bug rtl-optimization/55414] New: spec2006 416.gamess compilation fails on LRA

[evstupac at gmail dot com]

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

 Bug #: 55414
   Summary: spec2006 416.gamess compilation fails on LRA
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: evstu...@gmail.com


416.gamess fails to compile by trunk gfortran with options: “-m32
-fschedule-insns --param sched-pressure-algorithm=1 -fsched-pressure -O2
-mfpmath=sse -ffast-math -march=corei7-avx”:

internal compiler error: in insn_rhs_dead_pseudo_p, at lra-constraints.c:3242
   END
^
0x87d243 insn_rhs_dead_pseudo_p
/export/users/mstester/stability/svn/trunk/gcc/lra-constraints.c:3242
0x88377a init_insn_rhs_dead_pseudo_p
/export/users/mstester/stability/svn/trunk/gcc/lra-constraints.c:3258
0x88377a lra_constraints(bool)
/export/users/mstester/stability/svn/trunk/gcc/lra-constraints.c:3323
0x8769ae lra(_IO_FILE*)
/export/users/mstester/stability/svn/trunk/gcc/lra.c:2269
0x83e8a8 do_reload
/export/users/mstester/stability/svn/trunk/gcc/ira.c:4624
0x83e8a8 rest_of_handle_reload
/export/users/mstester/stability/svn/trunk/gcc/ira.c:4737
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

Test passes without avx (-march=corei7).

[Bug libstdc++/55413] [LTO] hashtable.h:1648 '__bbegin_bkt' may be used uninitialized in this function [-Werror=maybe-uninitialized]

[paolo at gcc dot gnu.org]

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



--- Comment #3 from paolo at gcc dot gnu.org  
2012-11-20 14:54:22 UTC ---

Author: paolo

Date: Tue Nov 20 14:54:11 2012

New Revision: 193663



URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=193663

Log:

2012-11-20  Paolo Carlini  



PR libstdc++/55413

* include/bits/hashtable.h (_Hashtable<>::_M_rehash_aux): Initialize

__bbegin_bkt and __prev_bkt to avoid uninitialized warnings.

* testsuite/23_containers/unordered_set/instantiation_neg.cc: Adjust

dg-error line number.



Modified:

trunk/libstdc++-v3/ChangeLog

trunk/libstdc++-v3/include/bits/hashtable.h

   

trunk/libstdc++-v3/testsuite/23_containers/unordered_set/instantiation_neg.cc

[Bug libstdc++/55413] [LTO] hashtable.h:1648 '__bbegin_bkt' may be used uninitialized in this function [-Werror=maybe-uninitialized]

[paolo at gcc dot gnu.org]

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



--- Comment #4 from paolo at gcc dot gnu.org  
2012-11-20 14:54:48 UTC ---

Author: paolo

Date: Tue Nov 20 14:54:36 2012

New Revision: 193664



URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=193664

Log:

2012-11-20  Paolo Carlini  



PR libstdc++/55413

* include/bits/hashtable.h (_Hashtable<>::_M_rehash_aux): Initialize

__bbegin_bkt and __prev_bkt to avoid uninitialized warnings.

* testsuite/23_containers/unordered_set/instantiation_neg.cc: Adjust

dg-error line number.



Modified:

branches/gcc-4_7-branch/libstdc++-v3/ChangeLog

branches/gcc-4_7-branch/libstdc++-v3/include/bits/hashtable.h

   

branches/gcc-4_7-branch/libstdc++-v3/testsuite/23_containers/unordered_set/instantiation_neg.cc

[Bug libstdc++/55413] [LTO] hashtable.h:1648 '__bbegin_bkt' may be used uninitialized in this function [-Werror=maybe-uninitialized]

[paolo.carlini at oracle dot com]

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



Paolo Carlini  changed:



   What|Removed |Added



 Status|NEW |RESOLVED

 Resolution||FIXED

   Target Milestone|--- |4.7.3



--- Comment #5 from Paolo Carlini  2012-11-20 
14:56:03 UTC ---

Fixed mainline and 4.7.3.

Promozione Vodafone 1000 Minuti al giorno

[Comunicazione di servizio]

Offerta limitata,  VODAFONE
per un anno intero al costo di 15,00 euro di spesa 
ricevi SMART 1000+ comprende : 
1000 minuti gratis al giorno verso i numeri Vodafone. 
1000 minuti gratis al mese verso tutti i numeri. 
Internet 5 GB mese, 
SMS illimitati Vodafone e 2500 sms verso tutti mese

http://www.vdfshop.com/

[Bug target/55351] can't build libgcc for -m5-compact variant in SH64

[dhowells at redhat dot com]

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



--- Comment #2 from dhowells at redhat dot com  
2012-11-20 15:09:42 UTC ---

The first hunk of the patch that adds:



   MULTILIB_EXCEPTIONS = *m5-64media* *m5-64media-nofpu*



to gcc/config/sh/t-linux causes the sh-linux-gnu build to fail.  Commenting out

this line allows both sh- and sh64-linux-gnu to build.

[Bug target/55351] can't build libgcc for -m5-compact variant in SH64

[dan at danny dot cz]

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

--- Comment #3 from Dan Horák  2012-11-20 15:15:50 UTC ---
(In reply to comment #2)
> The first hunk of the patch that adds:
> 
>MULTILIB_EXCEPTIONS = *m5-64media* *m5-64media-nofpu*
> 
> to gcc/config/sh/t-linux causes the sh-linux-gnu build to fail.  Commenting 
> out
> this line allows both sh- and sh64-linux-gnu to build.

I guess there is a conflict with the "!" values in
--with-multilib-list=m1,m2,m2e,m4,m4-single,m4-single-only,m2a,m2a-single,!m2a,!m2a-single
passed to the sh-linux compiler

[Bug middle-end/54860] [4.8 Regression]: build fails when configuring libgfortran due to recent "attribute" changes in core gcc

[hp at gcc dot gnu.org]

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



--- Comment #20 from Hans-Peter Nilsson  2012-11-20 
15:26:43 UTC ---

(In reply to comment #19)

> Assuming fixed.



Well yes!  Maybe we should clear the issue on who's supposed to close PR's

after a fix?  I'd be happy to do it for PR's I've opened, I've just left it to

whomever is "assigned" who may want to keep the PR open pending a backport.

[Bug c++/55355] internal compiler error: in tree_low_cst, at tree.c:6415

[rcp at sentientmeat dot ca]

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



--- Comment #9 from Richard Perrin  2012-11-20 
15:45:06 UTC ---

(In reply to comment #8)

> Note that, as I said already, I can't reproduce anywhere, not even in current

> 4_6-branch (on x86_64-linux -m32). Did you actually try it?



I have reproduced the ICE in an i386 build of gcc-4_6-branch at r193571.



I then switched to an x86_64-linux platform and built gcc from the same

codebase, and could not reproduce the ICE with the x86_64 gcc binary against

the test code.

[Bug c++/54046] [4.6/4.7/4.8 Regression] wrong control reaches end of non-void function for switch case with throw and default

[jakub at gcc dot gnu.org]

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



--- Comment #5 from Jakub Jelinek  2012-11-20 
16:02:33 UTC ---

I don't see how.  The thing is, e.g. lower_stmt resets data->cannot_fallthru on

most of the statements, even if it got changed to reset it only on

GIMPLE_LABELs (or few selected others), such that say a noreturn call which

sets data->cannot_fallthru followed by assignment or another call would keep

cannot_fallthru set even when it is currently cleared, on GIMPLE_LABELs we'd

need to reset anyway, as we don't have the CFG yet and don't have info how many

gotos or other control transfer stmts to each GIMPLE_LABEL there are (and the

values of cannot_fallthru at those points).  So even just the break; after the

__cxa_throw which got gimplified into goto ; : would

reset cannot_fallthru.  And the gimplifier doesn't see break; but already the

goto

[Bug target/55268] gcc4.8 mingw-w64 wrong stdcall import symbols generated after rev 193204

[ktietz at gcc dot gnu.org]

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



--- Comment #4 from Kai Tietz  2012-11-20 16:17:30 
UTC ---

Author: ktietz

Date: Tue Nov 20 16:17:16 2012

New Revision: 193666



URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=193666

Log:

PR target/55268

* i386.c (ix86_mangle_decl_assembler_name): Use

SUBTARGET_MANGLE_DECL_ASSEMBLER_NAME if defined.

* cygming.h (TARGET_MANGLE_DECL_ASSEMBLER_NAME): Rename

to SUBTARGET_MANGLE_DECL_ASSEMBLER_NAME.





Modified:

trunk/gcc/ChangeLog

trunk/gcc/config/i386/cygming.h

trunk/gcc/config/i386/i386.c

[Bug middle-end/55398] [4.8 Regression] va_arg usage with non-POD

[dnovillo at gcc dot gnu.org]

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



--- Comment #8 from Diego Novillo  2012-11-20 
16:26:24 UTC ---

Author: dnovillo

Date: Tue Nov 20 16:26:09 2012

New Revision: 193667



URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=193667

Log:

Convert vec<> into a POD.



This fixes PR 55398 by making vec<> a true POD.  I thought we could get

away with having private fields, but we can't.  We fail to pass vec<>

instances through varargs.



The patch makes every field public and mangles the field names in the

hope that no future patch will try to make use of them directly.  It's

horrible, but I could not think of anything better.



Tested with clang++ as the host compiler.



2012-11-20  Diego Novillo  



PR middle-end/55398

* vec.h (class vec_prefix): Make every field public.

Rename field alloc_ to alloc_PRIVATE_.

Rename field num_ to num_PRIVATE_.

Update all users.

(class vec): Make every field public.

Rename field pfx_ to pfx_PRIVATE_.

Rename field data_ to data_PRIVATE_.

Update all users.

(class vec): Make every field public.

Rename field vec_ to vec_PRIVATE_.

Update all users.



Modified:

trunk/gcc/ChangeLog

trunk/gcc/vec.c

trunk/gcc/vec.h

[Bug middle-end/55398] [4.8 Regression] va_arg usage with non-POD

[dnovillo at gcc dot gnu.org]

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



Diego Novillo  changed:



   What|Removed |Added



 Status|NEW |RESOLVED

 Resolution||FIXED



--- Comment #9 from Diego Novillo  2012-11-20 
16:30:14 UTC ---

Fixed.

[Bug middle-end/55403] [4.8 Regression] ICE building libitm

[rth at gcc dot gnu.org]

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



--- Comment #5 from Richard Henderson  2012-11-20 
16:34:20 UTC ---

I now suspect you're missing --with-long-double-128, which would have been

auto-detected given alpha glibc headers in --with-sysroot, as I have.



Proposed patch here:

http://gcc.gnu.org/ml/gcc-patches/2012-11/msg01681.html

[Bug middle-end/55381] [4.8 Regression]: build fails on cris-elf building libgfortran with host-gcc-4.4, ICE compiling matmul_i1.c

[dnovillo at gcc dot gnu.org]

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



--- Comment #8 from Diego Novillo  2012-11-20 
16:50:00 UTC ---

I don't have access to old compilers locally.  I'm trying with a cross from one

of the sparc boxes in the farm that has gcc 4.3.2.

[Bug tree-optimization/55415] New: Early SRA produces unaligned complex types

[rth at gcc dot gnu.org]

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



 Bug #: 55415

   Summary: Early SRA produces unaligned complex types

Classification: Unclassified

   Product: gcc

   Version: unknown

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: tree-optimization

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: r...@gcc.gnu.org





While looking at PR55403 one has to wonder where the unaligned

complex long double type came from in the first place:



#0  copy_node_stat (node=0x71aeb9d8) at ../../git-master/gcc/tree.c:961

#1  0x00e33162 in build_distinct_type_copy (type=0x71aeb9d8)

at ../../git-master/gcc/tree.c:5856

#2  0x00e332d5 in build_variant_type_copy (type=0x71aeb9d8)

at ../../git-master/gcc/tree.c:5890

#3  0x00e33119 in build_aligned_type (type=0x71aeb9d8, align=8)

at ../../git-master/gcc/tree.c:5842

#4  0x00a39b7d in ipa_modify_call_arguments (cs=0x711493a8, 

stmt=0x71147428, adjustments=...)

at ../../git-master/gcc/ipa-prop.c:2967



I'm still not quite sure why ipa_modify_call_arguments *ever* wants to

create misaligned types as function interfaces?

[Bug tree-optimization/55415] Early SRA produces unaligned complex types

[rth at gcc dot gnu.org]

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



--- Comment #1 from Richard Henderson  2012-11-20 
17:08:15 UTC ---

The call to get_pointer_alignment_1 at ipa-prop.c:2959

does not do what the author intended.  In particular we

really really need to notice the "false" return value

when the results are conservative, and do nothing.

[Bug c++/54770] sibling call optimization is not applied where it ought to be

[andy.m.jost at gmail dot com]

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



--- Comment #8 from Andy Jost  2012-11-20 
17:14:18 UTC ---

The workaround I mentioned in comment #5 does seem to do the trick. 

Specifically, something like this works in all the cases I've tried:



  struct MainNode : Node

  {

virtual void H()

{

  helper()

  this->H();

}

__attribute__((noinline)) void helper()

{

  NodePtr tmp(arg);

  this->~Node();

  new(this) MainNode(tmp);

}

  };

[Bug c++/54046] [4.6/4.7/4.8 Regression] wrong control reaches end of non-void function for switch case with throw and default

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



 Status|NEW |ASSIGNED

 AssignedTo|unassigned at gcc dot   |jakub at gcc dot gnu.org

   |gnu.org |



--- Comment #6 from Jakub Jelinek  2012-11-20 
17:27:03 UTC ---

Created attachment 28744

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28744

gcc48-pr54046.patch



Actually, with a langhook we can already at the C++ FE level get rid of the

warning for most of the cases, similarly how we don't warn for

g++.dg/warn/Wreturn-type-7.C (PR20681).

[Bug bootstrap/55387] [4.8 Regression] Build problem: malloc error in genautomata

[howarth at nitro dot med.uc.edu]

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



--- Comment #4 from Jack Howarth  2012-11-20 
17:43:37 UTC ---

This problem no longer exists at r193669 on x86_64-apple-darwin12 with Xcode

4.5.2 so it appears that...



r193667 | dnovillo | 2012-11-20 11:26:09 -0500 (Tue, 20 Nov 2012) | 26 lines



Convert vec<> into a POD.



This fixes PR 55398 by making vec<> a true POD.  I thought we could get

away with having private fields, but we can't.  We fail to pass vec<>

instances through varargs.



The patch makes every field public and mangles the field names in the

hope that no future patch will try to make use of them directly.  It's

horrible, but I could not think of anything better.



Tested with clang++ as the host compiler.



2012-11-20  Diego Novillo  



PR middle-end/55398

* vec.h (class vec_prefix): Make every field public.

Rename field alloc_ to alloc_PRIVATE_.

Rename field num_ to num_PRIVATE_.

Update all users.

(class vec): Make every field public.

Rename field pfx_ to pfx_PRIVATE_.

Rename field data_ to data_PRIVATE_.

Update all users.

(class vec): Make every field public.

Rename field vec_ to vec_PRIVATE_.

Update all users.



likely fixed this issue.

[Bug tree-optimization/55350] [4.8 Regression] verify_gimple failed with invalid (pointer) operands to plus/minus

[aldyh at gcc dot gnu.org]

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



Aldy Hernandez  changed:



   What|Removed |Added



 Status|NEW |WAITING

 CC||aldyh at gcc dot gnu.org



--- Comment #3 from Aldy Hernandez  2012-11-20 
17:48:47 UTC ---

Proposed fix:

http://gcc.gnu.org/ml/gcc-patches/2012-11/msg01689.html

[Bug rtl-optimization/19398] secondary reloads don't consider "m" alternatives

[uros at gcc dot gnu.org]

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



--- Comment #14 from uros at gcc dot gnu.org 2012-11-20 18:02:49 UTC ---

Author: uros

Date: Tue Nov 20 18:02:36 2012

New Revision: 193671



URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=193671

Log:

2012-11-20  Uros Bizjak  



* config/i386/i386.md (fix_trunc_sse): Macroize

insn from fix_trunc{si,di}_sse using SWI48 mode iterator.

(peephole2 to avoid vector decoded forms): Macroize peephole2

using MODEF mode iterator.  Use SWI48 mode iterator instead of SWI48x.



2012-11-20  Uros Bizjak  



PR target/19398

* config/i386/i386.md

(peephole2 to shorten x87->SSE reload sequences): Remove peephole2.

* config/i386/i386.h (enum ix86_tune_indices)

: Remove.

* config/i386/i386.h (initial_ix86_tune_features): Update.



2012-11-20  Vladimir Makarov  



PR target/19398

* lra-constraints.c (process_alt_operands): Discourage reloads

through secodnary memory.



testsuite/ChangeLog:



2012-11-20  Uros Bizjak  



PR target/19398

* gcc.target/i386/pr19398.c: New test.





Added:

trunk/gcc/testsuite/gcc.target/i386/pr19398.c

Modified:

trunk/gcc/ChangeLog

trunk/gcc/config/i386/i386.c

trunk/gcc/config/i386/i386.h

trunk/gcc/config/i386/i386.md

trunk/gcc/lra-constraints.c

trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/55213] vectorizer ignores __restrict__

[josh.m.conner at gmail dot com]

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



Joshua Conner  changed:



   What|Removed |Added



 CC||josh.m.conner at gmail dot

   ||com



--- Comment #3 from Joshua Conner  2012-11-20 
18:05:26 UTC ---

I'm running into a similar problem in code like this:



void

inner (float * restrict x, float * restrict y, int n)

{

  int i;



  for (i = 0; i < n; i++)

x[i] *= y[i];

}



void

outer (float *arr, int offset, int bytes)

{

  inner (&arr[0], &arr[offset], bytes);

}



In the out-of-line instance of inner(), no alias detection code is generated

(correctly, since the pointers are restricted).



When inner() is inlined into outer(), however, alias detection code is

unnecessarily generated.  This alone isn't a terrible penalty except that the

generation of a versioned loop to handle aliasing prevents us from performing

loop peeling for alignment, and so we end up with a vectorized unaligned loop

with poor performance.



Note that the place where I'm actually running into the problem is in fortran,

where pointer arguments are implicitly non-aliasing.

[Bug middle-end/55381] [4.8 Regression]: build fails on cris-elf building libgfortran with host-gcc-4.4, ICE compiling matmul_i1.c

[hp at gcc dot gnu.org]

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



--- Comment #9 from Hans-Peter Nilsson  2012-11-20 
18:11:10 UTC ---

(In reply to comment #8)

> I don't have access to old compilers locally.  I'm trying with a cross from 
> one

> of the sparc boxes in the farm that has gcc 4.3.2.



Revision r193667 seems to have fixed this, not unexpectedly.

[Bug middle-end/54860] [4.8 Regression]: build fails when configuring libgfortran due to recent "attribute" changes in core gcc

[hp at gcc dot gnu.org]

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



--- Comment #21 from Hans-Peter Nilsson  2012-11-20 
18:16:08 UTC ---

(In reply to comment #20)

> (In reply to comment #19)

> > Assuming fixed.

> 

> Well yes!  Maybe we should clear the issue on who's supposed to close PR's

> after a fix?  I'd be happy to do it for PR's I've opened, I've just left it to

> whomever is "assigned" who may want to keep the PR open pending a backport.



To wit, the original issue is resolved, but the new tests mentioned in comment

#13 still fail, so I'm going to clone this PR.

[Bug target/55268] gcc4.8 mingw-w64 wrong stdcall import symbols generated after rev 193204

[ktietz at gcc dot gnu.org]

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



Kai Tietz  changed:



   What|Removed |Added



 Status|NEW |RESOLVED

 Resolution||FIXED



--- Comment #5 from Kai Tietz  2012-11-20 18:20:27 
UTC ---

Fixed

[Bug middle-end/55416] New: New tests g++.dg/cpp0x/gen-attrs-17.2.C (et al) fail

[hp at gcc dot gnu.org]

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



 Bug #: 55416

   Summary: New tests g++.dg/cpp0x/gen-attrs-17.2.C (et al) fail

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: middle-end

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: h...@gcc.gnu.org

CC: do...@gcc.gnu.org

Depends on: 54860

  Host: x86_64-unknown-linux-gnu

Target: cris-axis-elf





+++ This bug was initially created as a clone of Bug #54860 +++



A patch in the revision range 192197:192199 introduced new failing tests:



Running /tmp/hpautotest-gcc1/gcc/gcc/testsuite/g++.dg/dg.exp ...

FAIL: g++.dg/abi/vbase10.C -std=gnu++98  (test for warnings, line 13)

FAIL: g++.dg/abi/vbase10.C -std=gnu++11  (test for warnings, line 13)

FAIL: g++.dg/cpp0x/gen-attrs-17.2.C -std=c++11  (test for errors, line 19)

FAIL: g++.dg/cpp0x/gen-attrs-21.C -std=c++11 (test for excess errors)

FAIL: g++.dg/cpp0x/gen-attrs-39.C -std=gnu++11 (test for excess errors)

FAIL: g++.dg/cpp0x/gen-attrs-51.C -std=c++11 (test for excess errors)

FAIL: g++.dg/cpp0x/gen-attrs-52.C -std=c++11 (test for excess errors)



Excerpt from g++.log attached at PR54860, i.e. at

.

[Bug tree-optimization/55350] [4.8 Regression] verify_gimple failed with invalid (pointer) operands to plus/minus

[aldyh at gcc dot gnu.org]

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



--- Comment #4 from Aldy Hernandez  2012-11-20 
18:28:30 UTC ---

Author: aldyh

Date: Tue Nov 20 18:28:09 2012

New Revision: 193672



URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=193672

Log:

PR tree-optimization/55350

* gimple-ssa-strength-reduction.c (replace_dependent): Handle

POINTER_{PLUS,MINUS}_EXPR correctly.



Added:

trunk/gcc/testsuite/gcc.c-torture/compile/pr55350.c

Modified:

trunk/gcc/ChangeLog

trunk/gcc/gimple-ssa-strength-reduction.c

[Bug rtl-optimization/19398] secondary reloads don't consider "m" alternatives

[ubizjak at gmail dot com]

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



Uros Bizjak  changed:



   What|Removed |Added



 Status|NEW |RESOLVED

URL||http://gcc.gnu.org/ml/gcc-p

   ||atches/2012-11/msg01693.htm

   ||l

 Resolution||FIXED

   Target Milestone|--- |4.8.0

  Known to fail|4.8.0   |



--- Comment #15 from Uros Bizjak  2012-11-20 18:28:43 
UTC ---

Implemented in 4.8.0.

[Bug tree-optimization/55350] [4.8 Regression] verify_gimple failed with invalid (pointer) operands to plus/minus

[aldyh at gcc dot gnu.org]

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



Aldy Hernandez  changed:



   What|Removed |Added



 Status|WAITING |RESOLVED

 Resolution||FIXED



--- Comment #5 from Aldy Hernandez  2012-11-20 
18:30:03 UTC ---

fixed on trunk

[Bug bootstrap/54329] [4.8 Regression] gcc/cfgcleanup.o differs

[wbrana at gmail dot com]

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



wbrana  changed:



   What|Removed |Added



 Status|WAITING |RESOLVED

 Resolution||FIXED



--- Comment #9 from wbrana  2012-11-20 18:43:32 UTC ---

it seems to be fixed

[Bug gcov-profile/55417] New: [4.8 Regression] AddressSanitizer reports stack-buffer-overflow in profiling code

[markus at trippelsdorf dot de]

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



 Bug #: 55417

   Summary: [4.8 Regression] AddressSanitizer reports

stack-buffer-overflow in profiling code

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: gcov-profile

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: mar...@trippelsdorf.de





% g++ -fprofile-generate -O3 -march=native tramp3d-v4.cpp

 % ./a.out --cartvis 1.0 0.0 --rhomin 1e-8 -n 20

...



(gcc built with gcc's address-sanitizer)

 % /var/tmp/gcc_sani_gcc/usr/local/bin/g++ -w -fprofile-use -O3 -march=native

tramp3d-v4.cpp 2>&1 | asan_symbolize.py | c++filt

=

==12985== ERROR: AddressSanitizer stack-buffer-overflow on address

0x79616080 at pc 0x12c1613 bp 0x79615b60 sp 0x79615b58

READ of size 8 at 0x79616080 thread T0

#0 0x12c1612 in compute_working_sets /home/markus/gcc/gcc/profile.c:294

Address 0x79616080 is located at offset 1184 in frame

 of T0's stack:

  This frame has 2 object(s):

[32, 112) 'hist_br_prob'

[160, 1184) 'working_set_cum_values'

HINT: this may be a false positive if your program uses some custom stack

unwind mechanism

  (longjmp and C++ exceptions *are* supported)

Shadow byte and word:

  0x1f2c2c10: f3

  0x1f2c2c10: f3 f3 f3 f3 00 00 00 00

More shadow bytes:

  0x1f2c2bf0: 00 00 00 00 00 00 00 00

  0x1f2c2bf8: 00 00 00 00 00 00 00 00

  0x1f2c2c00: 00 00 00 00 00 00 00 00

  0x1f2c2c08: 00 00 00 00 00 00 00 00

=>0x1f2c2c10: f3 f3 f3 f3 00 00 00 00

  0x1f2c2c18: 00 00 00 00 00 00 00 00

  0x1f2c2c20: 00 00 00 00 00 00 00 00

  0x1f2c2c28: 00 00 00 00 00 00 00 00

  0x1f2c2c30: 00 00 00 00 00 00 00 00

Stats: 6791M malloced (6303M for red zones) by 9376941 calls

Stats: 56M realloced by 304143 calls

Stats: 6701M freed by 9250298 calls

Stats: 6668M really freed by 9204559 calls

Stats: 323M (82726 full pages) mmaped in 620 calls

  mmaps   by size class: 7:139230; 8:26611; 9:7161; 10:2044; 11:3060; 12:16256;

13:19264; 14:576; 15:1184; 16:96; 17:16; 18:6; 19:3; 20:3; 21:4; 22:1;

  mallocs by size class: 7:5705562; 8:1531884; 9:365712; 10:67535; 11:73243;

12:1213506; 13:240088; 14:40078; 15:139014; 16:242; 17:39; 18:18; 19:7; 20:5;

21:7; 22:1;

  frees   by size class: 7:5603422; 8:1521617; 9:365436; 10:67516; 11:73162;

12:1212827; 13:226955; 14:40078; 15:139010; 16:204; 17:39; 18:16; 19:7; 20:5;

21:4;

  rfrees  by size class: 7:5575038; 8:1513474; 9:363702; 10:67156; 11:72856;

12:1208081; 13:225869; 14:39895; 15:138214; 16:204; 17:39; 18:16; 19:7; 20:5;

21:3;

Stats: malloc large: 139333 small slow: 278410

==12985== ABORTING



(gcc built with clang's address-sanitizer)

 % /var/tmp/gcc_sani_clang/usr/local/bin/g++ -w -fprofile-use -O3 -march=native

tramp3d-v4.cpp 2>&1 | asan_symbolize.py | c++filt

=

==13020== ERROR: AddressSanitizer: stack-buffer-overflow on address

0x7fff6d236680 at pc 0x1393105 bp 0x7fff6d236090 sp 0x7fff6d236088

READ of size 8 at 0x7fff6d236680 thread T0

#0 0x1393104 in get_exec_counts(unsigned int, unsigned int)

/home/markus/gcc/gcc/profile.c:294

#1 0x16de490 in tree_profiling() /home/markus/gcc/gcc/tree-profile.c:483

Address 0x7fff6d236680 is located at offset 1312 in frame  of

T0's stack:

  This frame has 15 object(s):

[32, 60) 'n_histogram_counters.i'

[96, 152) 'histogram_counts.i'

[192, 248) 'act_count.i'

[288, 1312) 'working_set_cum_values.i.i.i'

[1344, 1424) 'hist_br_prob.i'

[1472, 1504) ''

[1536, 1568) ''

[1600, 1608) 'values'

[1664, 1696) ''

[1728, 1760) ''

[1792, 1824) ''

[1856, 1888) ''

[1920, 1924) 'offset8'

[1984, 2016) 'curr_location'

[2048, 2080) 'curr_location9'

HINT: this may be a false positive if your program uses some custom stack

unwind mechanism

  (longjmp and C++ exceptions *are* supported)

Shadow byte and word:

  0x1fffeda46cd0: f2

  0x1fffeda46cd0: f2 f2 f2 f2 00 00 00 00

More shadow bytes:

  0x1fffeda46cb0: 00 00 00 00 00 00 00 00

  0x1fffeda46cb8: 00 00 00 00 00 00 00 00

  0x1fffeda46cc0: 00 00 00 00 00 00 00 00

  0x1fffeda46cc8: 00 00 00 00 00 00 00 00

=>0x1fffeda46cd0: f2 f2 f2 f2 00 00 00 00

  0x1fffeda46cd8: 00 00 00 00 00 00 f4 f4

  0x1fffeda46ce0: f2 f2 f2 f2 00 00 00 00

  0x1fffeda46ce8: f2 f2 f2 f2 00 00 00 00

  0x1fffeda46cf0: f2 f2 f2 f2 00 f4 f4 f4

Stats: 6791M malloced (6302M for red zones) by 9367325 calls

Stats: 56M realloced by 303356 calls

Stats: 6701M freed by 9242907 calls

Stats: 6668M really freed by 9197073 calls

Stats: 322M (82470 full pages) mmaped in 618 calls

  mmaps   by size class: 7:135135; 8:24564; 9:7161; 10:2044; 11:3060; 12:16256;

13:19264

[Bug c++/54325] [4.7/4.8 Regression] C++11 uniform initialization syntax for argument-less abstract base class constructor fails

[paolo.carlini at oracle dot com]

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



--- Comment #4 from Paolo Carlini  2012-11-20 
19:08:21 UTC ---

I just tried and r175673 also rejects the reduced code in Comment #1. Let's see

if I can find the exact revision where we regressed.

[Bug middle-end/55403] [4.8 Regression] ICE building libitm

[rsandifo at gcc dot gnu.org]

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



--- Comment #6 from rsandifo at gcc dot gnu.org  
2012-11-20 19:49:38 UTC ---

Author: rsandifo

Date: Tue Nov 20 19:49:26 2012

New Revision: 193674



URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=193674

Log:

gcc/

PR middle-end/55403

PR middle-end/55391

* expmed.c (store_bit_field_1): Use adjust_bitfield_address_size

rather than adjust_bitfield_address to change the mode of a reference.

(extract_bit_field_1): Likewise.



Modified:

trunk/gcc/ChangeLog

trunk/gcc/expmed.c

[Bug middle-end/55391] [4.8 regression] ICE in adjust_address_1 at emit-rtl.c:2180 breaks bulding cross to sparc64-linux

[rsandifo at gcc dot gnu.org]

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



--- Comment #4 from rsandifo at gcc dot gnu.org  
2012-11-20 19:49:39 UTC ---

Author: rsandifo

Date: Tue Nov 20 19:49:26 2012

New Revision: 193674



URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=193674

Log:

gcc/

PR middle-end/55403

PR middle-end/55391

* expmed.c (store_bit_field_1): Use adjust_bitfield_address_size

rather than adjust_bitfield_address to change the mode of a reference.

(extract_bit_field_1): Likewise.



Modified:

trunk/gcc/ChangeLog

trunk/gcc/expmed.c

[Bug middle-end/55403] [4.8 Regression] ICE building libitm

[rsandifo at gcc dot gnu.org]

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



rsand...@gcc.gnu.org  changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 Resolution||FIXED



--- Comment #7 from rsandifo at gcc dot gnu.org  
2012-11-20 19:51:06 UTC ---

Patch applied to trunk.  Thanks for the help.

[Bug middle-end/55391] [4.8 regression] ICE in adjust_address_1 at emit-rtl.c:2180 breaks bulding cross to sparc64-linux

[rsandifo at gcc dot gnu.org]

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



--- Comment #5 from rsandifo at gcc dot gnu.org  
2012-11-20 19:53:10 UTC ---

I optimistically included this PR in the changelog,

but please let me know if the patch doesn't in fact

fix the ICE.

[Bug middle-end/54630] [4.8 Regression] GCC 4.8 --enable-languages=c build fails: Undefined symbols: ___cxa_guard_acquire and ___cxa_guard_release

[baker at usgs dot gov]

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



--- Comment #13 from Larry Baker  2012-11-20 19:57:41 
UTC ---

Jakub,



The root of the problem is because GCC required a C++ linker, but the logic in

gcc/Makefile forces the linker to be $(CC) when HOST_LIBS are specified:



# The name of the compiler to use.

COMPILER = $(CXX)

COMPILER_FLAGS = $(CXXFLAGS)

# If HOST_LIBS is set, then the user is controlling the libraries to

# link against.  In that case, link with $(CC) so that the -lstdc++

# library is not introduced.  If HOST_LIBS is not set, link with

# $(CXX) to pick up -lstdc++.

ifeq ($(HOST_LIBS),)

LINKER = $(CXX)

LINKER_FLAGS = $(CXXFLAGS)

else

LINKER = $(CC)

LINKER_FLAGS = $(CFLAGS)

endif



Since GCC from now on will be implemented in C++, we can expect there will be

C++-only features (local statics, as you say).  This, in turn, implies to me

that GCC should be linked with a C++ compiler, not a C compiler.  Maybe this

Makefile should just honor what the user specifies, instead of switching to

$(CC).  E.g., if the user requires gcc, then they can define CXX=gcc.  This

also means that HOST_LIBS can use g++ syntax when CXX=g++.  Thus,

HOST_LIBS='-static-libgcc -static-libstdc++' will work as expected.



I hope someone will look at the cause of this error and think about whether the

Makefile behavior really makes sense the way it is.  I think not.

[Bug middle-end/54630] [4.8 Regression] GCC 4.8 --enable-languages=c build fails: Undefined symbols: ___cxa_guard_acquire and ___cxa_guard_release

[jakub at gcc dot gnu.org]

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



--- Comment #14 from Jakub Jelinek  2012-11-20 
20:19:58 UTC ---

It is intentionally that way, so that one can fine tune the C++ libraries

linked into the binary with --with-host-libstdcxx, but you are responsible for

specifying there all the needed libraries.  Don't use this configure option if

you don't need it.

[Bug tree-optimization/55415] Early SRA produces unaligned complex types

[jamborm at gcc dot gnu.org]

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



Martin Jambor  changed:



   What|Removed |Added



 Status|UNCONFIRMED |ASSIGNED

   Last reconfirmed||2012-11-20

 AssignedTo|unassigned at gcc dot   |jamborm at gcc dot gnu.org

   |gnu.org |

 Ever Confirmed|0   |1



--- Comment #2 from Martin Jambor  2012-11-20 
20:33:37 UTC ---

I'm looking into this.

[Bug tree-optimization/38785] [4.5/4.6/4.7/4.8 Regression] huge performance regression on EEMBC bitmnp01

[izamyatin at gmail dot com]

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



--- Comment #34 from Igor Zamyatin  2012-11-20 
21:00:39 UTC ---

(In reply to comment #32)

> Would be possible to double check if this problem is still fixed after the fix

> to the tree-ssa-pre patch?



Unfortunately the regression happened after the fix...

[Bug gcov-profile/55417] [4.8 Regression] AddressSanitizer reports stack-buffer-overflow in profiling code

[markus at trippelsdorf dot de]

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



--- Comment #1 from Markus Trippelsdorf  
2012-11-20 21:06:46 UTC ---

Valgrind shows:



 % /var/tmp/gcc_valgrind/usr/local/bin/g++ -w -fprofile-use -O3

/home/markus/bench.cpp   

==522== Conditional jump or move depends on uninitialised value(s)

==522==at 0x9E082B: compute_branch_probabilities(unsigned int, unsigned

int) (profile.c:294)

==522==by 0x9E2544: branch_prob() (profile.c:1371)

==522==by 0xAFF5F5: tree_profiling() (tree-profile.c:483)

==522==by 0x9CBD2A: execute_one_pass(opt_pass*) (passes.c:2327)

==522==by 0x9CC789: execute_ipa_pass_list(opt_pass*) (passes.c:2692)

==522==by 0x79429F: compile() (cgraphunit.c:1869)

==522==by 0x794B99: finalize_compilation_unit() (cgraphunit.c:2120)

==522==by 0x5B4A0E: cp_write_global_declarations() (decl2.c:4287)

==522==by 0xA6D5BC: compile_file() (toplev.c:559)

==522==by 0xA6F479: toplev_main(int, char**) (toplev.c:1881)

==522==by 0x4ECD894: (below main) (libc-start.c:258)

==522== 

 %

[Bug rtl-optimization/55396] -O2 -m32 -fno-omit-frame-pointer: internal compiler error: in check_rtl, at lra.c:2007

[vmakarov at gcc dot gnu.org]

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



--- Comment #2 from Vladimir Makarov  2012-11-20 
21:33:12 UTC ---

Author: vmakarov

Date: Tue Nov 20 21:32:59 2012

New Revision: 193678



URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=193678

Log:

2012-11-20  Vladimir Makarov  



PR rtl-optimization/55396

* lra-constraints.c (get_reload_reg): Change class if it is

different from reg class.





Modified:

trunk/gcc/ChangeLog

trunk/gcc/lra-constraints.c

[Bug c++/55418] New: Valgrind: Conditional jump or move depends on uninitialised value(s) in implicitly_declare_fn() method.c:1623

[markus at trippelsdorf dot de]

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



 Bug #: 55418

   Summary: Valgrind: Conditional jump or move depends on

uninitialised value(s) in implicitly_declare_fn()

method.c:1623

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: c++

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: mar...@trippelsdorf.de





Just saw this during a -enable-checking=yes,valgrind build:



 % /var/tmp/gcc_valgrind/usr/local/bin/g++ -std=gnu++11 -c

/home/markus/gcc/libstdc++-v3/src/c++11/functexcept.cc

==1267== Conditional jump or move depends on uninitialised value(s)

==1267==at 0x637C0F: implicitly_declare_fn(special_function_kind,

tree_node*, bool, tree_node*, tree_node*) (method.c:1623)

==1267==by 0x6392DF: lazily_declare_fn(special_function_kind, tree_node*)

(method.c:1894)

==1267==by 0x63FB74: lookup_fnfields_1(tree_node*, tree_node*)

(search.c:1441)

==1267==by 0x63FD3B: lookup_fnfields_slot(tree_node*, tree_node*)

(search.c:1471)

==1267==by 0x64367B: lookup_field_r(tree_node*, void*) (search.c:1031)

==1267==by 0x6400CE: dfs_walk_all(tree_node*, tree_node* (*)(tree_node*,

void*), tree_node* (*)(tree_node*, void*), void*) (search.c:1572)

==1267==by 0x6402E7: lookup_member(tree_node*, tree_node*, int, bool, int)

(search.c:1204)

==1267==by 0x640640: lookup_fnfields(tree_node*, tree_node*, int)

(search.c:1295)

==1267==by 0x4DF3B0: build_special_member_call(tree_node*, tree_node*,

vec**, tree_node*, int, int) (call.c:7282)

==1267==by 0x4E0693: convert_like_real(conversion*, tree_node*, tree_node*,

int, int, bool, bool, int) (call.c:5718)

==1267==by 0x4E1D91: build_over_call(z_candidate*, int, int) (call.c:6867)

==1267==by 0x4DE229: build_new_method_call(tree_node*, tree_node*,

vec**, tree_node*, int, tree_node**, int)

(call.c:7668)

==1267== 



Looks like some booleans in implicitly_declare_fn should be initialised.

[Bug middle-end/55391] [4.8 regression] ICE in adjust_address_1 at emit-rtl.c:2180 breaks bulding cross to sparc64-linux

[mikpe at it dot uu.se]

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



Mikael Pettersson  changed:



   What|Removed |Added



 Status|NEW |RESOLVED

 Resolution||FIXED



--- Comment #6 from Mikael Pettersson  2012-11-20 
22:13:11 UTC ---

r193674 does fix the ICE.  Thanks -- closing as fixed.

[Bug bootstrap/55388] [4.8 regression] ICE in int_mode_for_mode at stor-layout.c:423 breaks sparc64-linux bootstrap

[mikpe at it dot uu.se]

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



--- Comment #2 from Mikael Pettersson  2012-11-20 
22:21:45 UTC ---

It's caused by r193599:

http://gcc.gnu.org/ml/gcc-cvs/2012-11/msg00546.html

[Bug c++/55419] New: internal compiler error: in gimplify_init_ctor_preeval, at gimplify.c:3587

[jasongross9+bugzilla at gmail dot com]

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

 Bug #: 55419
   Summary: internal compiler error: in
gimplify_init_ctor_preeval, at gimplify.c:3587
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jasongross9+bugzi...@gmail.com


Created attachment 28745
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28745
intermediate .ii file from g++

I get the following output from g++, and it creates the attached .ii file

Using built-in specs.
COLLECT_GCC=/afs/csail.mit.edu/proj/courses/6.172/gcc-cilkplus/bin/g++
Target: x86_64-unknown-linux-gnu
Configured with: ./configure
--prefix=/afs/csail/proj/courses/6.172/gcc-cilkplus --enable-languages=c,c++
Thread model: posix
gcc version 4.8.0 20120618 (experimental) (GCC) 
COLLECT_GCC_OPTIONS='-std=c++11' '-v' '-save-temps' '-c' '-o' 'fen.o'
'-shared-libgcc' '-mtune=generic' '-march=x86-64'

/afs/csail.mit.edu/proj/courses/6.172/gcc-cilkplus/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.8.0/cc1plus
-E -quiet -v -iprefix
/afs/csail.mit.edu/proj/courses/6.172/gcc-cilkplus/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.8.0/
-D_GNU_SOURCE fen.cpp -mtune=generic -march=x86-64 -std=c++11 -fpch-preprocess
-o fen.ii
ignoring nonexistent directory
"/afs/csail.mit.edu/proj/courses/6.172/gcc-cilkplus/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../../x86_64-unknown-linux-gnu/include"
ignoring duplicate directory
"/afs/csail.mit.edu/proj/courses/6.172/gcc-cilkplus/bin/../lib/gcc/../../lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../../include/c++/4.8.0"
ignoring duplicate directory
"/afs/csail.mit.edu/proj/courses/6.172/gcc-cilkplus/bin/../lib/gcc/../../lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../../include/c++/4.8.0/x86_64-unknown-linux-gnu"
ignoring duplicate directory
"/afs/csail.mit.edu/proj/courses/6.172/gcc-cilkplus/bin/../lib/gcc/../../lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../../include/c++/4.8.0/backward"
ignoring duplicate directory
"/afs/csail.mit.edu/proj/courses/6.172/gcc-cilkplus/bin/../lib/gcc/../../lib/gcc/x86_64-unknown-linux-gnu/4.8.0/include"
ignoring duplicate directory
"/afs/csail.mit.edu/proj/courses/6.172/gcc-cilkplus/bin/../lib/gcc/../../lib/gcc/x86_64-unknown-linux-gnu/4.8.0/include-fixed"
ignoring nonexistent directory
"/afs/csail.mit.edu/proj/courses/6.172/gcc-cilkplus/bin/../lib/gcc/../../lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../../x86_64-unknown-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /opt/intel/composer_xe_2013.0.079/mkl/include
 /opt/intel/composer_xe_2013.0.079/tbb/include

/afs/csail.mit.edu/proj/courses/6.172/gcc-cilkplus/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../../include/c++/4.8.0

/afs/csail.mit.edu/proj/courses/6.172/gcc-cilkplus/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../../include/c++/4.8.0/x86_64-unknown-linux-gnu

/afs/csail.mit.edu/proj/courses/6.172/gcc-cilkplus/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../../include/c++/4.8.0/backward

/afs/csail.mit.edu/proj/courses/6.172/gcc-cilkplus/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.8.0/include

/afs/csail.mit.edu/proj/courses/6.172/gcc-cilkplus/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.8.0/include-fixed
 /usr/local/include

/afs/csail.mit.edu/proj/courses/6.172/gcc-cilkplus/bin/../lib/gcc/../../include
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-std=c++11' '-v' '-save-temps' '-c' '-o' 'fen.o'
'-shared-libgcc' '-mtune=generic' '-march=x86-64'

/afs/csail.mit.edu/proj/courses/6.172/gcc-cilkplus/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.8.0/cc1plus
-fpreprocessed fen.ii -quiet -dumpbase fen.cpp -mtune=generic -march=x86-64
-auxbase-strip fen.o -std=c++11 -version -o fen.s
GNU C++ (GCC) version 4.8.0 20120618 (experimental) (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.8.0 20120618 (experimental), GMP version 5.0.2,
MPFR version 3.1.0, MPC version 0.9
warning: GMP header version 5.0.2 differs from library version 4.3.2.
warning: MPFR header version 3.1.0 differs from library version 3.0.0-p3.
warning: MPC header version 0.9 differs from library version 0.8.2.
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU C++ (GCC) version 4.8.0 20120618 (experimental) (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.8.0 20120618 (experimental), GMP version 5.0.2,
MPFR version 3.1.0, MPC version 0.9
warning: GMP header version 5.0.2 differs from library version 4.3.2.
warning: MPFR header version 3.1.0 differs from library version 3.0.0-p3.
warning: MPC header version 0.9 differs from library version 0.8.2.
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: 9140df29c77763bd28b47359117a6952
fen.cpp: In function ‘int fen_to_pos(position_t*, const c

[Bug middle-end/54630] [4.8 Regression] GCC 4.8 --enable-languages=c build fails: Undefined symbols: ___cxa_guard_acquire and ___cxa_guard_release

[baker at usgs dot gov]

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



--- Comment #15 from Larry Baker  2012-11-20 22:24:46 
UTC ---

Jakub,



I undertand the reason for the --with-host-libstdcxx option.  The documentation

for --with-host-libstdcxx doesn't say anything about the side effect of

changing the LINKER from $(CXX) to $(CC).  It is that effect that I believe is

undesirable, especially given the change of GCC's implementation language from

C to C++.

[Bug c/55420] New: Gcc produces an internal compiler error (nested function with variably modified return)

[cookevillain at yahoo dot com]

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

 Bug #: 55420
   Summary: Gcc produces an internal compiler error (nested
function with variably modified return)
Classification: Unclassified
   Product: gcc
   Version: 4.4.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: cookevill...@yahoo.com


When compiling:
--
int f(void) {

  int n;

  int (*g(int a))[n]{

return NULL;

  }

  return 0;

}

with:
--
gcc -Wall -c ice.c 
--
gcc reports:
--
ice.c: In function ‘f’:
ice.c:5: internal compiler error: in put_pending_sizes, at stor-layout.c:108
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
--

gcc version information:

Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
4.4.3-4ubuntu5.1' --with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared
--enable-multiarch --enable-linker-build-id --with-system-zlib
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.4 --program-suffix=-4.4 --enable-nls
--enable-clocale=gnu --enable-libstdcxx-debug --enable-plugin --enable-objc-gc
--enable-targets=all --disable-werror --with-arch-32=i486 --with-tune=generic
--enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu
--target=i486-linux-gnu
Thread model: posix
gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5.1) 

--

I can reproduce this in 4.6, as well.

[Bug middle-end/55421] New: [4.8 Regression] ICE in adjust _address_1, at emit-rtl.c:2180

[danglin at gcc dot gnu.org]

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



 Bug #: 55421

   Summary: [4.8 Regression] ICE in adjust _address_1, at

emit-rtl.c:2180

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: middle-end

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: dang...@gcc.gnu.org

CC: rsand...@gcc.gnu.org

  Host: hppa2.0w-hp-hpux11.11

Target: hppa2.0w-hp-hpux11.11

 Build: hppa2.0w-hp-hpux11.11





Created attachment 28746

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28746

Preprocessed source



libtool: compile:  /test/gnu/gcc/objdir/./gcc/xgcc

-B/test/gnu/gcc/objdir/./gcc/

 -B/opt/gnu/gcc/gcc-4.8/hppa2.0w-hp-hpux11.11/bin/

-B/opt/gnu/gcc/gcc-4.8/hppa2.

0w-hp-hpux11.11/lib/ -isystem

/opt/gnu/gcc/gcc-4.8/hppa2.0w-hp-hpux11.11/include

 -isystem /opt/gnu/gcc/gcc-4.8/hppa2.0w-hp-hpux11.11/sys-include

-DHAVE_CONFIG_H

 -I. -I../../../gcc/libquadmath -g -O2 -MT math/complex.lo -MD -MP -MF

math/.dep

s/complex.Tpo -c ../../../gcc/libquadmath/math/complex.c  -fPIC -DPIC -o

math/.l

ibs/complex.o

../../../gcc/libquadmath/math/complex.c: In function 'cpowq':

../../../gcc/libquadmath/math/complex.c:59:1: internal compiler error: in

adjust

_address_1, at emit-rtl.c:2180

 cpowq (__complex128 base, __complex128 power)

 ^



../../../gcc/libquadmath/math/complex.c:59:1: internal compiler error: Aborted



Breakpoint 1, _Z16adjust_address_1P7rtx_def12machine_modeliiil (

memref=0x7af38820, mode=BLKmode, offset=0, validate=1, adjust_address=1, 

adjust_object=1, size=0) at ../../gcc/gcc/emit-rtl.c:2180

2180  gcc_assert (!adjust_object);

(gdb) bt

#0  _Z16adjust_address_1P7rtx_def12machine_modeliiil (memref=0x7af38820, 

mode=BLKmode, offset=0, validate=1, adjust_address=1, adjust_object=1, 

size=0) at ../../gcc/gcc/emit-rtl.c:2180

#1  0x0042c4d8 in _ZL17store_bit_field_1P7rtx_def12machine_modeS0_b (

str_rtx=0x7af38820, bitsize=128, bitnum=0, bitregion_start=0, 

bitregion_end=0, fieldmode=TFmode, value=0x7af348e0, fallback_p=true)

at ../../gcc/gcc/expmed.c:648

#2  0x0042cfd4 in _Z15store_bit_fieldP7rtx_def12machine_modeS0_ (

str_rtx=0x7af38820, bitsize=128, bitnum=0, bitregion_start=0, 

bitregion_end=0, fieldmode=TFmode, value=0x7af348e0)

at ../../gcc/gcc/expmed.c:889

#3  0x00455a88 in _ZL11store_fieldP7rtx_defllmm12machine_modeP9tree_nodeib (

target=0x7af38820, bitsize=128, bitpos=0, bitregion_start=0, 

bitregion_end=0, mode=TFmode, exp=0x7af30bb8, alias_set=2, 

nontemporal=false) at ../../gcc/gcc/expr.c:6466

#4  0x0044e03c in _Z17expand_assignmentP9tree_nodeS0_b (to=0x7af31498, 

from=0x7af30bb8, nontemporal=false) at ../../gcc/gcc/expr.c:4832

#5  0x0028aebc in _ZL20expand_gimple_stmt_1P18gimple_statement_d (

stmt=0x7af1acf0) at ../../gcc/gcc/cfgexpand.c:2209

#6  0x0028b3cc in _ZL18expand_gimple_stmtP18gimple_statement_d (

stmt=0x7af1acf0) at ../../gcc/gcc/cfgexpand.c:2305

#7  0x00292a04 in _ZL25expand_gimple_basic_blockP15basic_block_defb (

bb=0x7ae1c9c0, disable_tail_calls=false) at ../../gcc/gcc/cfgexpand.c:4084

---Type  to continue, or q  to quit---

#8  0x00294d44 in gimple_expand_cfg() () at ../../gcc/gcc/cfgexpand.c:4603

#9  0x007dc1bc in _Z16execute_one_passP8opt_pass (

pass=0x40033af8 ) at ../../gcc/gcc/passes.c:2327

#10 0x007dc580 in _Z17execute_pass_listP8opt_pass (

pass=0x40033af8 ) at ../../gcc/gcc/passes.c:2387

#11 0x002d5d18 in _ZL15expand_functionP11cgraph_node (node=0x7aed2498)

at ../../gcc/gcc/cgraphunit.c:1641

#12 0x002d6300 in _ZL20expand_all_functionsv ()

at ../../gcc/gcc/cgraphunit.c:1745

#13 0x002d7314 in _Z7compilev () at ../../gcc/gcc/cgraphunit.c:2043

#14 0x002d758c in finalize_compilation_unit() ()

at ../../gcc/gcc/cgraphunit.c:2120

#15 0x000792e0 in _Z27c_write_global_declarationsv ()

at ../../gcc/gcc/c/c-decl.c:10120

#16 0x00955264 in _ZL12compile_filev () at ../../gcc/gcc/toplev.c:559

#17 0x00958a1c in _ZL10do_compilev () at ../../gcc/gcc/toplev.c:1881

#18 0x00958d30 in _Z11toplev_mainiPPc (argc=14, argv=0x7eff053c)

at ../../gcc/gcc/toplev.c:1957

#19 0x00dc2464 in main (argc=14, argv=0x7eff053c) at ../../gcc/gcc/main.c:36

[Bug middle-end/55421] [4.8 Regression] ICE in adjust _address_1, at emit-rtl.c:2180

[pinskia at gcc dot gnu.org]

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



--- Comment #1 from Andrew Pinski  2012-11-20 
23:44:52 UTC ---

I think this was fixed by:

http://gcc.gnu.org/ml/gcc-cvs/2012-11/msg00621.html

[Bug middle-end/55421] [4.8 Regression] ICE in adjust _address_1, at emit-rtl.c:2180

[pinskia at gcc dot gnu.org]

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



Andrew Pinski  changed:



   What|Removed |Added



   Keywords||build, ice-on-valid-code

   Target Milestone|--- |4.8.0

[Bug c/55422] New: gcc does not diagnose change of linkage for a function.

[cookevillain at yahoo dot com]

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



 Bug #: 55422

   Summary: gcc does not diagnose change of linkage for a

function.

Classification: Unclassified

   Product: gcc

   Version: 4.4.3

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: c

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: cookevill...@yahoo.com





compiling:



static void ff(int a) {



  return;



}



int f(void) {



  ff(0);

  int ff = 0;



  {



extern void ff(int);



  }



  return ff;



}





with:

gcc -Wall -c ice.c





produces no diagnostic, however, clause 6.2.2(3) of the ISO standard requires

that the first declaration of ff results in ff having internal linkage; then,

since the file scope declaration is hidden, according to 6.2.2(4), ff's linkage

is now external.



gcc correctly diagnoses this in the code below, so it seems to be related to

the declaration of ff as a function. the standard makes no distinction between

these two cases though.



---



static int ff;



int f(void) {



  int ff = 0;



  {



extern int ff;



  }



  return ff;



}

[Bug c/55422] gcc does not diagnose change of linkage for a function.

[cookevillain at yahoo dot com]

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



--- Comment #1 from cookevillain at yahoo dot com 2012-11-20 23:55:16 UTC ---

gcc -v output, omitted in the report:



-



Using built-in specs.

Target: i486-linux-gnu

Configured with: ../src/configure -v --with-pkgversion='Ubuntu

4.4.3-4ubuntu5.1' --with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs

--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared

--enable-multiarch --enable-linker-build-id --with-system-zlib

--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix

--with-gxx-include-dir=/usr/include/c++/4.4 --program-suffix=-4.4 --enable-nls

--enable-clocale=gnu --enable-libstdcxx-debug --enable-plugin --enable-objc-gc

--enable-targets=all --disable-werror --with-arch-32=i486 --with-tune=generic

--enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu

--target=i486-linux-gnu

Thread model: posix

gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5.1)

[Bug c++/54325] [4.7/4.8 Regression] C++11 uniform initialization syntax for argument-less abstract base class constructor fails

[paolo.carlini at oracle dot com]

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



--- Comment #5 from Paolo Carlini  2012-11-21 
00:41:19 UTC ---

We regressed with r175639, the implementation of DR 990:



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

[Bug c++/55245] [4.6/4.7/4.8 Regression] Compiler segfault when compiling a small test case

[dnovillo at gcc dot gnu.org]

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



Diego Novillo  changed:



   What|Removed |Added



 CC||dnovillo at gcc dot gnu.org



--- Comment #4 from Diego Novillo  2012-11-21 
00:52:57 UTC ---

David's analysis is correct.  The type of the element at the point of the

failure is not a complete type.



At this point, I think all the types should've been completed, so I'm not sure

why this one still isn't.  Jason, this patchlet (which is very likely papering

over the issue) allows the file to build.



Index: gimplify.c

===

--- gimplify.c  (revision 193508)

+++ gimplify.c  (working copy)

@@ -2123,6 +2123,8 @@

  if (TREE_OPERAND (t, 3) == NULL_TREE)

{ 

  tree elmt_type = TREE_TYPE (TREE_TYPE (TREE_OPERAND (t, 0)));

+ if (!COMPLETE_TYPE_P (elmt_type))

+   layout_type (elmt_type);

  tree elmt_size = unshare_expr (array_ref_element_size (t));

  tree factor = size_int (TYPE_ALIGN_UNIT (elmt_type));



In this case, we have



t ==> mosaic_position[tri]

elmt_type ==> struct Vector2_f[3], but we cannot compute its element size

because it has not yet been laid out.



Jason, what would be a better place to make sure the type is laid out?





Thanks.  Diego.

[Bug c++/55419] [4.8 Regression] ICE in gimplify_init_ctor_preeval, at gimplify.c:3587

[paolo.carlini at oracle dot com]

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



Paolo Carlini  changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed||2012-11-21

Summary|internal compiler error: in |[4.8 Regression] ICE in

   |gimplify_init_ctor_preeval, |gimplify_init_ctor_preeval,

   |at gimplify.c:3587  |at gimplify.c:3587

 Ever Confirmed|0   |1



--- Comment #1 from Paolo Carlini  2012-11-21 
01:06:40 UTC ---

It's a regression.