[Bug java/56372] New: Missing libgcj caused ICE (stack overflow) in jc1

[k2k at narod dot ru]

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



 Bug #: 56372

   Summary: Missing libgcj caused ICE (stack overflow) in jc1

Classification: Unclassified

   Product: gcc

   Version: 4.7.2

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: java

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

ReportedBy: k...@narod.ru

  Host: i686-pc-mingw32

Target: i686-w64-mingw32, x86_64-w64-mingw32

 Build: i686-pc-mingw32





When building cross-compiler, this command caused stack overflow



i686-pc-mingw32-gcj -o ecjx.exe -findirect-dispatch

--main=org.eclipse.jdt.internal.compiler.batch.GCCMain

../../../../source/gcc-4.7.2/libjava/../ecj.jar ecjx.o



That internally calls



"t:/dvlp/mingw-w64-i686/libexec/gcc/i686-w64-mingw32/4.7.2/jc1.exe"

"../../../../source/gcc-4.7.2/libjava/../ecj.jar" "-fhash-synchronization"

"-fuse-divide-subroutine" "-fcheck-references" "-fuse-boehm-gc"

"-fkeep-inline-functions" "-quiet" "-dumpbase" "ecj.jar" "-mtune=generic"

"-march=pentium3" "-auxbase" "ecj" "-g1" "-findirect-dispatch"

"-fbootclasspath=./;T:/dvlp/mingw-w64-i686/share/java/libgcj-4.7.2.jar" "-o"

"C:\Users\UserName\AppData\Local\Temp\ccgbcsCW.s"



If libgcj-4.7.2.jar is missing than jc1.exe is closed with error (stack

overflow). Even with increased stack to 140 MB.

Situation with missing libgcj is not valid, but I believe that jc1 must print

some error message and not to crash.

[Bug tree-optimization/56366] [4.8 Regression] ICE: verify_gimple failed (incompatible types in PHI argument)

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



 Status|NEW |ASSIGNED

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

   |gnu.org |



--- Comment #2 from Richard Biener  2013-02-18 
09:15:00 UTC ---

Mine.

[Bug tree-optimization/56349] ICE in create_preheader at cfgloopmanip.c:1525

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



 Status|NEW |ASSIGNED

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

   |gnu.org |



--- Comment #2 from Richard Biener  2013-02-18 
09:17:33 UTC ---

Mine.

[Bug tree-optimization/56349] ICE in create_preheader at cfgloopmanip.c:1525

[rguenth at gcc dot gnu.org]

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



--- Comment #3 from Richard Biener  2013-02-18 
09:40:39 UTC ---

The issue here is that we have an inner loop that has an exit edge that is

at the same time the latch edge for its outer loop (that is, its latch

does not belong to it - but we do not have LOOPS_HAVE_SIMPLE_LATCHES - yet).

In this case it seems that loop->latch may be not set, even if

we disambiguated loops with multiple latches.  We do not verify that

with disambiguated multiple latch loops we have ->latch set, which reveals

one bug in flow_loops_find.  Which transforms this bug into sth totally

different ;)

[Bug tree-optimization/56350] [4.7/4.8 Regression] ICE in vectorizable_reduction, at tree-vect-loop.c:4731

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



 Status|NEW |ASSIGNED

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

   |gnu.org |



--- Comment #3 from Jakub Jelinek  2013-02-18 
10:41:16 UTC ---

Created attachment 29481

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

gcc48-pr56350.patch



Untested fix.

[Bug libgomp/56357] [4.8 Regression] missing symbol references for libgomp when using -flto -fopenmp on mingw32

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



   Target Milestone|--- |4.8.0

[Bug tree-optimization/56355] abs and multiplication

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed||2013-02-18

 Ever Confirmed|0   |1



--- Comment #2 from Richard Biener  2013-02-18 
10:45:23 UTC ---

We lack gimple-level standard math function combining (basically all of

fold_* in builtins.c needs to be replicated by GIMPLE functionality).

[Bug middle-end/55030] [4.8 Regression]: gcc.c-torture/execute/builtins/memcpy-chk.c execution, -Os (et al)

[ebotcazou at gcc dot gnu.org]

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



--- Comment #13 from Eric Botcazou  2013-02-18 
10:48:18 UTC ---

> I've lost track. What was "the original patch", what do you mean by "the

> blockage patch" (that has been installed) and I'm pretty sure there were

> several follow-up patches, so I can't say I'm confident about reverting

> something from just this subset.  (To wit: if it's something that causes

> volatile asms to again be treated different from (other) blockages, then 
> that's

> wrong, as a volatile asm is the default blockage.)



The original patch was the patch you reverted in comment #1 and the fix for the

original issue.  As far as I can see, you didn't put it back after installing

the blockage patch, which is the patch in comment #5.  The dse.c and cselib.c

hunks were not necessary and not in the submission, but I asked you to add them

for the sake of consistency; then Jakub pointed out that they pessimize

volatile asms.

[Bug tree-optimization/56360] Loop invariant motion by default can introduce speculative store

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed||2013-02-18

Summary|Loop invariant motion can   |Loop invariant motion by

   |introduce speculative store |default can introduce

   ||speculative store

 Ever Confirmed|0   |1



--- Comment #7 from Richard Biener  2013-02-18 
10:49:12 UTC ---

It's a bit late to flip the bit for 4.8 (fallout from little testing coverage

of the disallow-store-data-racse paths).  Also the --param should become a

regular switch before we flip its default anywhere.



I changed the summary according to facts.

[Bug c++/56359] [4.8 regression] Bogus "error: no matching function for call to ..."

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



Version|unknown |4.8.0

   Target Milestone|--- |4.8.0

[Bug middle-end/56362] bitfield refs over-optimized?

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 Resolution||INVALID



--- Comment #1 from Richard Biener  2013-02-18 
10:50:53 UTC ---

BIT_FIELD_REFs never involve a sign-extension - the result has exactly the

precision of the number of bits referenced.

[Bug middle-end/56363] over aggressive division folding ignores sign conversion

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



   Keywords||wrong-code

 Status|UNCONFIRMED |NEW

   Last reconfirmed||2013-02-18

 Ever Confirmed|0   |1



--- Comment #1 from Richard Biener  2013-02-18 
10:54:03 UTC ---

Well, it should simply look at op0/op1 instead.

[Bug c/56370] RFE: warn on 'foo = realloc(foo, …)'

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



   Keywords||diagnostic

 Status|UNCONFIRMED |NEW

   Last reconfirmed||2013-02-18

 Ever Confirmed|0   |1



--- Comment #1 from Richard Biener  2013-02-18 
10:54:41 UTC ---

Confirmed.

[Bug debug/56307] FAIL: gcc.dg/tree-ssa/pr55579.c scan-tree-dump esra "Created a debug-only replacement for s"

[jamborm at gcc dot gnu.org]

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



--- Comment #2 from Martin Jambor  2013-02-18 
10:55:32 UTC ---

Probably not because s is a local variable, not a parameter and the

only function parameter in the testcase is an integer.  Unfortunately,

I cannot reproduce the failure on hppa-linux-gnu (gcc61 on compile

farm) and trunk revision 195939 and thus I'm afraid I cannot do

anything about it.

[Bug tree-optimization/56365] Missed opportunities for smin/smax standard name patterns

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed||2013-02-18

 Ever Confirmed|0   |1



--- Comment #1 from Richard Biener  2013-02-18 
10:58:13 UTC ---

I see, at -O2, on x86_64 in 070t.phiopt:



test_04 (int a, int b)

{

  int D.1744;

  int D.1741;

  int _3;

  int _4;



  :

  _3 = MIN_EXPR ;

  _4 = MAX_EXPR <_3, -128>;

  return _4;



}



for the other cases you run into the issue that the tree-level phiopt

can be confused by phi-merging:



test_05 (int a)

{

  :

  if (a_2(D) > 126)

goto ;

  else

goto ;



  :

  if (a_2(D) < -127)

goto ;

  else

goto ;



  :



  :

  # a_1 = PHI <127(2), a_2(D)(4), -128(3)>

  return a_1;

[Bug target/56347] [4.8 Regression] FAIL: gfortran.dg/integer_exponentiation_2.f90 -O2 execution test

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



   Target Milestone|--- |4.8.0

[Bug middle-end/56077] [4.6/4.7/4.8 Regression] volatile ignored when function inlined

[abel at gcc dot gnu.org]

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



--- Comment #9 from Andrey Belevantsev  2013-02-18 
11:08:10 UTC ---

I will test the patch removing the JUMP_P part of the conditional on x86-64 and

ia64, but for 4.8 I'd suggest trying some more platforms, like ppc at the

minimum.

[Bug middle-end/56344] ICE for program with very large structs returned by value

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



   Keywords||diagnostic

 Status|UNCONFIRMED |NEW

   Last reconfirmed||2013-02-18

Summary|ICE for program with larger |ICE for program with very

   |automatic structs   |large structs returned by

   ||value

 Ever Confirmed|0   |1



--- Comment #2 from Richard Biener  2013-02-18 
11:09:32 UTC ---

Confirmed.  Returning a struct of size > 2^31 by value ICEs like the following:



t.c: In function 'main':

t.c:34:10: internal compiler error: Segmentation fault

   result = mulm(m1, m2);

  ^

0xad765d crash_signal

/space/rguenther/src/svn/trunk/gcc/toplev.c:332

0x6d405b store_one_arg

/space/rguenther/src/svn/trunk/gcc/calls.c:4707

0x6ceba4 expand_call(tree_node*, rtx_def*, int)

/space/rguenther/src/svn/trunk/gcc/calls.c:3042

0x7f3634 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,

expand_modifier, rtx_def**)

/space/rguenther/src/svn/trunk/gcc/expr.c:10207



Program received signal SIGSEGV, Segmentation fault.

0x0065b81f in store_one_arg (arg=0x7fffaf20, 

argblock=0x75ac2560, flags=0, variable_size=0, reg_parm_stack_space=0)

at /space/rguenther/src/svn/gcc-4_7-branch/gcc/calls.c:4675

4675  stack_usage_map[i] = 1;

(gdb) p i

$1 = -1990967296



my advice: don't do it ;) (it won't work at runtime anyway)



I think the middle-end should sorry (), the frontends eventually warn

(or reject if possible).

[Bug middle-end/56341] GCC produces unaligned data access

[rguenth at gcc dot gnu.org]

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



--- Comment #4 from Richard Biener  2013-02-18 
11:20:43 UTC ---

There is now better ways of implementing -fstrict-volatile-bitfields which

I repeatedly told the arm people.  Not for 4.6, but for 4.7 and trunk.

[Bug middle-end/56363] over aggressive division folding ignores sign conversion

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



 CC||jakub at gcc dot gnu.org



--- Comment #2 from Jakub Jelinek  2013-02-18 
11:31:06 UTC ---

Do you mean in the && multiple_of_p check, or rather just in

return fold_build2_loc (loc, EXACT_DIV_EXPR, type, arg0, arg1);

call?  Anyway, it would be better to see a testcase.

[Bug c++/56373] New: -Wzero-as-null-pointer-constant: does not catch issues with smart pointers

[akim.demaille at gmail dot com]

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



 Bug #: 56373

   Summary: -Wzero-as-null-pointer-constant: does not catch issues

with smart pointers

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: minor

  Priority: P3

 Component: c++

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

ReportedBy: akim.demai...@gmail.com





Hi all,



Sorry if this report is bogus.  I would expect GCC to complain about the

following uses of 0 instead of nullptr, but it does not.



$ cat foo.cc

#include 

struct foo {};



int main ()

{

  std::shared_ptr a = 0;

  std::shared_ptr b(0);

  std::shared_ptr c{0};

  foo *d = 0;

}

$ g++-mp-4.8 -std=c++11 -Wall -Wzero-as-null-pointer-constant /tmp/foo.cc 

/tmp/foo.cc: In function 'int main()':

/tmp/foo.cc:9:12: warning: zero as null pointer constant

[-Wzero-as-null-pointer-constant]

   foo *d = 0;

^

/tmp/foo.cc:9:8: warning: unused variable 'd' [-Wunused-variable]

   foo *d = 0;

^

$ g++-mp-4.8  --version

g++-mp-4.8 (MacPorts gcc48 4.8-20130210_0) 4.8.0 20130210 (experimental)

Copyright (C) 2013 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.



It's also a bit sad that only d is diagnosed as useless, although I do

understand that the shared_ptr has a constructor and a destructor that use

it.



Cheers!

[Bug tree-optimization/56366] [4.8 Regression] ICE: verify_gimple failed (incompatible types in PHI argument)

[rguenth at gcc dot gnu.org]

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



--- Comment #3 from Richard Biener  2013-02-18 
11:50:13 UTC ---

The bug must be latent before, added by vectorizing of sign-conversions.

I missed the induction initial value case in case of outer loop vectorization.

[Bug c++/56373] -Wzero-as-null-pointer-constant: does not catch issues with smart pointers

[redi at gcc dot gnu.org]

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



--- Comment #1 from Jonathan Wakely  2013-02-18 
12:07:49 UTC ---

The warning isn't issued when 0 converts to std::nullptr_t, only when it

converts to a pointer type.



struct shared_ptr

{

shared_ptr(decltype(nullptr)) { }

~shared_ptr() { }

};



int main ()

{

  shared_ptr a = 0;

  shared_ptr b(0);

  shared_ptr c{0};

}





(In reply to comment #0)

> It's also a bit sad that only d is diagnosed as useless, although I do

> understand that the shared_ptr has a constructor and a destructor that use

> it.



It's necessary, because otherwise you get bogus warnings from ScopeGuard-style

RAII types.

[Bug tree-optimization/56321] [4.8 Regression] ICE:segfault in midend for -funsafe-math-optimizations -O3

[rguenth at gcc dot gnu.org]

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



--- Comment #12 from Richard Biener  2013-02-18 
12:11:59 UTC ---

Author: rguenth

Date: Mon Feb 18 12:11:47 2013

New Revision: 196117



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

Log:

2013-02-18  Richard Biener  



PR tree-optimization/56321

* tree-ssa-reassoc.c (propagate_op_to_single_use): Properly

order SSA name release and virtual operand unlinking.



* gcc.dg/torture/pr56321.c: New testcase.



Added:

trunk/gcc/testsuite/gcc.dg/torture/pr56321.c

Modified:

trunk/gcc/ChangeLog

trunk/gcc/testsuite/ChangeLog

trunk/gcc/tree-ssa-reassoc.c

[Bug tree-optimization/56321] [4.8 Regression] ICE:segfault in midend for -funsafe-math-optimizations -O3

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



 Status|ASSIGNED|RESOLVED

 Resolution||FIXED



--- Comment #13 from Richard Biener  2013-02-18 
12:12:14 UTC ---

Fixed.

[Bug tree-optimization/56294] BOOT_CFLAGS='-O2 -g -fno-ipa-sra' leads to bootstrap comparison failure

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



 CC||jakub at gcc dot gnu.org



--- Comment #7 from Jakub Jelinek  2013-02-18 
12:15:26 UTC ---

More reduced testcase for -O2 -fno-ipa-sra -fcompare-debug:

struct comp_cost { int cost; unsigned complexity; };

struct cost_pair { struct iv_cand *cand; };

struct iv_use { unsigned n_map_members; cost_pair *cost_map; };

struct iv_cand { unsigned id; };



void

bar (comp_cost, comp_cost)

{

}



void

foo (iv_use *use, iv_cand *cand)

{

  unsigned i, s = cand->id & (use->n_map_members - 1);

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

if (use->cost_map[i].cand)

  goto found;

found:

  use->cost_map[i].cand = cand;

  comp_cost elim_cost, express_cost, bound_cost;

  bar (elim_cost, express_cost);

}

[Bug middle-end/56301] [4.7 Regression] wrong code with the fix for PR53844

[doko at gcc dot gnu.org]

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



--- Comment #1 from Matthias Klose  2013-02-18 
12:31:31 UTC ---

Created attachment 29482

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

test case



no reduced test case yet, but there is a diff in the tree dump with

-fdump-tree-dse in the test_deserialise_ptrace function:



diff -u  



--- revert/upstart-1.6.1/init/test_job.c.132t.dse2

+++ norevert/upstart-1.6.1/init/test_job.c.132t.dse2

@@ -367,12 +367,8 @@

   abort ();



 :

-  job_64->goal = 1;

-  job_64->state = 3;

   D.9269_65 = job_64->pid;

   *D.9269_65 = pid_49;

-  job_64->trace_forks = 0;

-  job_64->trace_state = 3;



 :

   __ret_66 = nih_str_array_new (0B);

[Bug c++/56374] New: N3276 Incomplete return types Implent in gcc 4.8

[c1326909 at rmqkr dot net]

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



 Bug #: 56374

   Summary: N3276  Incomplete return types Implent in gcc 4.8

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: enhancement

  Priority: P3

 Component: c++

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

ReportedBy: c1326...@rmqkr.net





Will this draft implement in gcc version 4.8??

[Bug middle-end/56301] [4.7 Regression] wrong code with the fix for PR53844

[doko at gcc dot gnu.org]

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



Matthias Klose  changed:



   What|Removed |Added



 Status|WAITING |NEW



--- Comment #2 from Matthias Klose  2013-02-18 
12:37:50 UTC ---

with -fdump-tree-dse-details:



--- revert/upstart-1.6.1/init/test_job.c.132t.dse2

+++ norevert/upstart-1.6.1/init/test_job.c.132t.dse2

@@ -35,6 +35,14 @@



 ;; Function test_deserialise_ptrace (test_deserialise_ptrace, funcdef_no=60,

decl_uid=9022, cgraph_uid=60)



+  Deleted dead store 'job_64->trace_state = 3;

+'

+  Deleted dead store 'job_64->trace_forks = 0;

+'

+  Deleted dead store 'job_64->state = 3;

+'

+  Deleted dead store 'job_64->goal = 1;

+'

 test_deserialise_ptrace ()

 {

   long unsigned int D.9415;

@@ -367,12 +375,8 @@

   abort ();



 :

-  job_64->goal = 1;

-  job_64->state = 3;

   D.9269_65 = job_64->pid;

   *D.9269_65 = pid_49;

-  job_64->trace_forks = 0;

-  job_64->trace_state = 3;



 :

   __ret_66 = nih_str_array_new (0B);

[Bug c++/56374] N3276 Incomplete return types Implent in gcc 4.8

[redi at gcc dot gnu.org]

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



Jonathan Wakely  changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 Resolution||DUPLICATE



--- Comment #1 from Jonathan Wakely  2013-02-18 
12:47:32 UTC ---

No, it doesn't look like it will be in 4.8



*** This bug has been marked as a duplicate of bug 52748 ***

[Bug c++/52748] [C++11] N3276 changes to decltype

[redi at gcc dot gnu.org]

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



--- Comment #4 from Jonathan Wakely  2013-02-18 
12:47:32 UTC ---

*** Bug 56374 has been marked as a duplicate of this bug. ***

[Bug middle-end/56301] [4.7 Regression] wrong code with the fix for PR53844

[rguenth at gcc dot gnu.org]

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



--- Comment #3 from Richard Biener  2013-02-18 
12:48:13 UTC ---

I don't see how this is a bug.



  job_64 = job_new (class_39, "");

  # DEBUG job => job_64

  if (job_64 == 0B)

goto ;

  else

goto ;



:

  # DEBUG __fmt => "BAD: wrong value for %s, got unexpected %p\n\tat %s:%d

(%s).\n"

  __printf_chk (1, "BAD: wrong value for %s, got unexpected %p\n\tat %s:%d

(%s).\n", "job", 0B, "tests/test_job.c", 111, &__FUNCTION__);

  abort ();



:

  D.9269_65 = job_64->pid;

  *D.9269_65 = pid_49;



that was the last use of the memory pointed to by job_64 (job_new is marked as

malloc).  In fact, job_64->pid is uninitialized!  To quote the documentation

of the malloc attribute:



@item malloc

@cindex @code{malloc} attribute

The @code{malloc} attribute is used to tell the compiler that a function

may be treated as if any non-@code{NULL} pointer it returns cannot

alias any other pointer valid when the function returns and that the memory

has undefined content.

This will often improve optimization.

Standard functions with this property include @code{malloc} and

@code{calloc}.  @code{realloc}-like functions do not have this

property as the memory pointed to does not have undefined content.



it appears that the returned memory does not have undefined contents.

[Bug middle-end/56301] [4.7 Regression] wrong code with the fix for PR53844

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



 Status|NEW |RESOLVED

 Resolution||INVALID



--- Comment #4 from Richard Biener  2013-02-18 
12:48:48 UTC ---

Thus, invalid.

[Bug c++/56373] -Wzero-as-null-pointer-constant: does not catch issues with smart pointers

[akim.demaille at gmail dot com]

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



--- Comment #2 from Akim Demaille  2013-02-18 
12:52:46 UTC ---

Thanks a lot for the detailed answer.



> The warning isn't issued when 0 converts to std::nullptr_t, only when it

> converts to a pointer type.



And shouldn't it?



>> It's also a bit sad that only d is diagnosed as useless, although I do

>> understand that the shared_ptr has a constructor and a destructor that use

>> it.



> It's necessary, because otherwise you get bogus warnings from ScopeGuard-style

> RAII types.



In which case the constructor and destructor would be meaningful,

which is not the case here.  But again, thanks for explaining!

[Bug tree-optimization/56350] [4.7/4.8 Regression] ICE in vectorizable_reduction, at tree-vect-loop.c:4731

[rguenth at gcc dot gnu.org]

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



--- Comment #4 from Richard Biener  2013-02-18 
13:03:24 UTC ---

Author: rguenth

Date: Mon Feb 18 13:03:15 2013

New Revision: 196118



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

Log:

2013-02-18  Richard Biener  



PR middle-end/56350

* cfghooks.c (merge_blocks): If we merge a latch into another

block adjust references to it.

* cfgloop.c (flow_loops_find): Reset latch before recomputing it.

(verify_loop_structure): Verify that a recorded latch is in fact

a latch.



* gcc.dg/torture/pr56350.c: New testcase.



Added:

trunk/gcc/testsuite/gcc.dg/torture/pr56350.c

Modified:

trunk/gcc/ChangeLog

trunk/gcc/cfghooks.c

trunk/gcc/cfgloop.c

trunk/gcc/testsuite/ChangeLog

[Bug middle-end/56349] [4.8 Regression] ICE in create_preheader at cfgloopmanip.c:1525

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



  Component|tree-optimization   |middle-end

Summary|ICE in create_preheader at  |[4.8 Regression] ICE in

   |cfgloopmanip.c:1525 |create_preheader at

   ||cfgloopmanip.c:1525



--- Comment #4 from Richard Biener  2013-02-18 
13:03:52 UTC ---

Fixed.

[Bug middle-end/56349] [4.8 Regression] ICE in create_preheader at cfgloopmanip.c:1525

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



 Status|ASSIGNED|RESOLVED

 Resolution||FIXED



--- Comment #5 from Richard Biener  2013-02-18 
13:05:49 UTC ---

Eh, fixed!

[Bug middle-end/56349] [4.8 Regression] ICE in create_preheader at cfgloopmanip.c:1525

[rguenth at gcc dot gnu.org]

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



--- Comment #6 from Richard Biener  2013-02-18 
13:09:24 UTC ---

Author: rguenth

Date: Mon Feb 18 13:09:17 2013

New Revision: 196119



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

Log:

2013-02-18  Richard Biener  



PR middle-end/56349

* gcc.dg/torture/pr56350.c: Move ...

* gcc.dg/torture/pr56349.c: ... here.



Added:

trunk/gcc/testsuite/gcc.dg/torture/pr56349.c

  - copied unchanged from r196118,

trunk/gcc/testsuite/gcc.dg/torture/pr56350.c

Removed:

trunk/gcc/testsuite/gcc.dg/torture/pr56350.c

Modified:

trunk/gcc/ChangeLog

trunk/gcc/testsuite/ChangeLog

[Bug c++/56373] -Wzero-as-null-pointer-constant: does not catch issues with smart pointers

[redi at gcc dot gnu.org]

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



--- Comment #3 from Jonathan Wakely  2013-02-18 
13:20:41 UTC ---

(In reply to comment #2)

> > It's necessary, because otherwise you get bogus warnings from 
> > ScopeGuard-style

> > RAII types.

> 

> In which case the constructor and destructor would be meaningful,

> which is not the case here.



~shared_ptr() has non-trivial side-effects, the compiler isn't smart enough to

determine they won't fire when its empty, so it's always meaningful.



If you're smart enough to know the object isn't used then don't create it :)

[Bug c++/56373] -Wzero-as-null-pointer-constant: does not catch issues with smart pointers

[akim.demaille at gmail dot com]

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



--- Comment #4 from Akim Demaille  2013-02-18 
13:23:08 UTC ---

> If you're smart enough to know the object isn't used then don't create it :)



:) :) :)



> ~shared_ptr() has non-trivial side-effects, the compiler isn't smart enough to

> determine they won't fire when its empty, so it's always meaningful.



I had in mind providing the library authors with an attribute that would

help them influence this diagnostic.

[Bug middle-end/56301] [4.7 Regression] wrong code with the fix for PR53844

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



 CC||jakub at gcc dot gnu.org



--- Comment #5 from Jakub Jelinek  2013-02-18 
13:31:28 UTC ---

Well, perhaps we need to improve documentation, because for calloc the memory

doesn't have undefined contents either, it is well defined to be all zeros.

[Bug middle-end/56301] [4.7 Regression] wrong code with the fix for PR53844

[rguenther at suse dot de]

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



--- Comment #6 from rguenther at suse dot de  
2013-02-18 13:34:31 UTC ---

On Mon, 18 Feb 2013, jakub at gcc dot gnu.org wrote:



> 

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

> 

> Jakub Jelinek  changed:

> 

>What|Removed |Added

> 

>  CC||jakub at gcc dot gnu.org

> 

> --- Comment #5 from Jakub Jelinek  2013-02-18 
> 13:31:28 UTC ---

> Well, perhaps we need to improve documentation, because for calloc the memory

> doesn't have undefined contents either, it is well defined to be all zeros.



Well, it points to nothing ;)  The bug here is that probably

job_new links the allocated memory into some global list or so,

so it's not about initializing the memory but the fact that it

_is_ aliased by other things.



Yes, we can probably give a few examples of what is not appropriate

use of 'malloc'.



Do you think I should revert the patch on the branch nevertheless?

(it was a fix for a missed-optimization regression only ...)

[Bug c/56375] New: SIGSEGV when assign SIMD variable to member of allocated structure

[cjxgm at 126 dot com]

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

 Bug #: 56375
   Summary: SIGSEGV when assign SIMD variable to member of
allocated structure
Classification: Unclassified
   Product: gcc
   Version: 4.7.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: cj...@126.com


The code:

#include 
typedef float v4 __attribute__((vector_size(sizeof(float)*4)));
typedef struct IpuImage
{
v4 data[256*256];
}
IpuImage;
int main()
{
IpuImage * I = malloc(sizeof(IpuImage));
v4 color = {1, 0, 1, 0};
I->data[0] = color;
return 0;
}

I use this to compile:
gcc -o a a.c -std=gnu11 -march=native

SIGSEGV happens at "I->data[0] = color"
Then I tried to debug in assembly mode, following is the gdb's output:

┌──Register group:
general─┐
│eax0xb7d29008   -1210937336  
│
│ecx0x101000 1052672  
│
│edx0xb7d29008   -1210937336  
│
│ebx0xb7fd8000   -1208123392  
│
│esp0xb370   0xb370   
│
│ebp0xb3a8   0xb3a8   
│
│esi0x0  0
│
│edi0x0  0
│
│eip0x804842a0x804842a   
│
│eflags 0x210282 [ SF IF RF ID ]  
│
 cs 0x73 115  
│
│ss 0x7b 123  
│
└──┘
   │0x8048411  mov%eax,0x2c(%esp)
│
   │0x8048415  movaps 0x80484e0,%xmm0
│
   │0x804841c  movaps %xmm0,0x10(%esp)   
│
   │0x8048421  mov0x2c(%esp),%eax
│
   │0x8048425  movaps 0x10(%esp),%xmm0   
│
  >│0x804842a  movaps %xmm0,(%eax)   
│
   │0x804842d  mov$0x0,%eax  
│
   │0x8048432  leave 
│
   │0x8048433  ret   
│
   │0x8048434   xchg   %ax,%ax
│
   │0x8048436   xchg   %ax,%ax
│
   │0x8048438   xchg   %ax,%ax
│
   │0x804843a   xchg   %ax,%ax
│
  
└───┘
child process 7781 In: mainLine: ??   PC: 0x804842a 
(gdb) ni
0x08048402 in main ()
0x08048405 in main ()
0x0804840c in main ()
0x08048411 in main ()
0x08048415 in main ()
0x0804841c in main ()
0x08048421 in main ()
0x08048425 in main ()
0x0804842a in main ()

Program received signal SIGSEGV, Segmentation fault.
0x0804842a in main ()
(gdb) 

%eax is non-zero, showing that malloc succeeded, and SIGSEGV is occured at
"movaps %xmm0,(%eax)"

[Bug middle-end/56301] [4.7 Regression] wrong code with the fix for PR53844

[jakub at gcc dot gnu.org]

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



--- Comment #7 from Jakub Jelinek  2013-02-18 
13:42:24 UTC ---

(In reply to comment #6)

> Do you think I should revert the patch on the branch nevertheless?

> (it was a fix for a missed-optimization regression only ...)



Yeah, missed-optimization regression can wait for 4.8, but just the

tree-ssa-dse.c part + related testcase, not all the other fixes.

[Bug c/56375] SIGSEGV when assign SIMD variable to member of allocated structure

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 CC||jakub at gcc dot gnu.org

 Resolution||INVALID



--- Comment #1 from Jakub Jelinek  2013-02-18 
13:46:39 UTC ---

User error, malloc doesn't guarantee sufficient alignment of the pointer, which

you are relying on.  You need to use posix_memalign or memalign or align it by

hand yourself (allocate more for the padding).

[Bug middle-end/53844] [4.6 Regression] GCC generates suboptimal code for unused members of classes in some cases on multiple targets.

[rguenth at gcc dot gnu.org]

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



--- Comment #14 from Richard Biener  2013-02-18 
13:46:46 UTC ---

Author: rguenth

Date: Mon Feb 18 13:46:37 2013

New Revision: 196120



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

Log:

2013-02-18  Richard Biener  



Revert

2013-02-04  Richard Biener  



Backport from mainline

2012-07-04  Richard Guenther  



PR tree-optimization/53844

* tree-ssa-dse.c (dse_possible_dead_store_p): Properly handle

the loop virtual PHI.



* g++.dg/tree-ssa/pr53844.C: New testcase.



Removed:

branches/gcc-4_7-branch/gcc/testsuite/g++.dg/tree-ssa/pr53844.C

Modified:

branches/gcc-4_7-branch/gcc/ChangeLog

branches/gcc-4_7-branch/gcc/testsuite/ChangeLog

branches/gcc-4_7-branch/gcc/tree-ssa-dse.c

[Bug middle-end/53844] [4.6/4.7 Regression] GCC generates suboptimal code for unused members of classes in some cases on multiple targets.

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



  Known to work|4.7.3   |

   Target Milestone|4.7.3   |4.8.0

Summary|[4.6 Regression] GCC|[4.6/4.7 Regression] GCC

   |generates suboptimal code   |generates suboptimal code

   |for unused members of   |for unused members of

   |classes in some cases on|classes in some cases on

   |multiple targets.   |multiple targets.



--- Comment #15 from Richard Biener  2013-02-18 
13:47:33 UTC ---

Reverted even on the 4.7 branch.  Fixed for 4.8.

[Bug tree-optimization/56366] [4.8 Regression] ICE: verify_gimple failed (incompatible types in PHI argument)

[rguenth at gcc dot gnu.org]

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



--- Comment #4 from Richard Biener  2013-02-18 
13:58:30 UTC ---

Author: rguenth

Date: Mon Feb 18 13:58:21 2013

New Revision: 196121



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

Log:

2013-02-18  Richard Biener  



PR tree-optimization/56366

* tree-vect-loop.c (get_initial_def_for_induction): Properly

handle sign-conversion of outer-loop initial induction value.



* gcc.dg/torture/pr56366.c: New testcase.



Added:

trunk/gcc/testsuite/gcc.dg/torture/pr56366.c

Modified:

trunk/gcc/ChangeLog

trunk/gcc/testsuite/ChangeLog

trunk/gcc/tree-vect-loop.c

[Bug tree-optimization/56366] [4.8 Regression] ICE: verify_gimple failed (incompatible types in PHI argument)

[rguenth at gcc dot gnu.org]

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



--- Comment #5 from Richard Biener  2013-02-18 
13:58:47 UTC ---

Fixed.

[Bug tree-optimization/56350] [4.7/4.8 Regression] ICE in vectorizable_reduction, at tree-vect-loop.c:4731

[jakub at gcc dot gnu.org]

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



--- Comment #5 from Jakub Jelinek  2013-02-18 
14:19:04 UTC ---

The previous commit was for PR56349.

[Bug debug/56376] New: gdb needs a way to associate a vtable symbol with a class type

[tromey at gcc dot gnu.org]

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



 Bug #: 56376

   Summary: gdb needs a way to associate a vtable symbol with a

class type

Classification: Unclassified

   Product: gcc

   Version: unknown

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: debug

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

ReportedBy: tro...@gcc.gnu.org





gdb needs a way to associate a vtable symbol with a type.

Some background:



gdb has a feature ("set print object on") where it tries to

examine an object's vtable to find the object's real, dynamic

type.



It examines the vtable pointer, then finds the vtable's ELF symbol,

demangles the symbol name, and finally (e) strips off

"vtable for" from the demangled name and looks up the result

as a type name in the DWARF.



However, this approach doesn't work in some cases.  For example,

it fails if the type is defined locally to a function.

See http://sourceware.org/bugzilla/show_bug.cgi?id=14235



Here (at least in the example in comment #10), there is no way to

associate a vtable with the appropriate type.



To solve these problems it would be nice if, at the very least for

the defined-in-a-function case, GCC emitted some DWARF that would

associate a vtable with a type.  I think for this to really work

it would have to do this for all vtables thus defined -- e.g., so that

inspecting an object that is partially constructed would also DTRT.



One approach would be to emit it as an artificial variable.

For gdb it would be more convenient if it were top-level, but anywhere

sane would work.  Like:



DW_TAG_variable

   DW_AT_linkage_name _Zblahblah

   DW_AT_artificial

   DW_AT_containing_type 



But perhaps this is too magical and a new DW_TAG_GNU_vtable would

be better.

[Bug libgomp/56357] [4.8 Regression] missing symbol references for libgomp when using -flto -fopenmp on mingw32

[jakub at gcc dot gnu.org]

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



--- Comment #1 from Jakub Jelinek  2013-02-18 
14:24:50 UTC ---

Works just fine on x86_64-linux.

[Bug tree-optimization/56265] [4.8 Regression] ICE in ipa_make_edge_direct_to_target

[jakub at gcc dot gnu.org]

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



--- Comment #6 from Jakub Jelinek  2013-02-18 
14:27:29 UTC ---

Honza, any progress on this?

[Bug c++/56359] [4.8 regression] Bogus "error: no matching function for call to ..."

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed||2013-02-18

 CC||jakub at gcc dot gnu.org,

   ||jason at gcc dot gnu.org

 Ever Confirmed|0   |1



--- Comment #1 from Jakub Jelinek  2013-02-18 
14:33:00 UTC ---

Started with http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190664

[Bug tree-optimization/56366] [4.8 Regression] ICE: verify_gimple failed (incompatible types in PHI argument)

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



 Status|ASSIGNED|RESOLVED

 CC||jakub at gcc dot gnu.org

 Resolution||FIXED



--- Comment #6 from Jakub Jelinek  2013-02-18 
14:34:43 UTC ---

.

[Bug debug/37237] Debug information for virtual destructors omits DW_AT_vtable_elem_location

[tromey at gcc dot gnu.org]

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



--- Comment #11 from Tom Tromey  2013-02-18 15:20:56 
UTC ---

(In reply to comment #10)

> I don't think such an attribute belongs in the DWARF standard, since this is

> very much an internal detail of the ABI; another ABI might have just a single

> destructor with magic arguments, like the old G++ ABI.

> 

> You need to know a lot about the destructor ABI as it is; looking for D0/D1

> doesn't seem like a major additional burden to me.



With git master I actually see multiple destructors now:



 <1>: Abbrev Number: 15 (DW_TAG_subprogram)

   DW_AT_abstract_origin: <0x93>

   DW_AT_linkage_name: (indirect string, offset: 0x10): _ZN1AD2Ev   

   DW_AT_low_pc  : 0x0  

   DW_AT_high_pc : 0x39 0x0 

   DW_AT_frame_base  : 1 byte block: 9c (DW_OP_call_frame_cfa)

   DW_AT_object_pointer: <0xe1> 

   DW_AT_GNU_all_tail_call_sites: 1 

   DW_AT_sibling : <0xea>   

[...]

 <1>: Abbrev Number: 17 (DW_TAG_subprogram)

   DW_AT_abstract_origin: <0x93>

   DW_AT_linkage_name: (indirect string, offset: 0x3e): _ZN1AD0Ev   

   DW_AT_low_pc  : 0x3a 

   DW_AT_high_pc : 0x26 0x0 

<103>   DW_AT_frame_base  : 1 byte block: 9c(DW_OP_call_frame_cfa)

<105>   DW_AT_object_pointer: <0x109>   

<109>   DW_AT_GNU_all_tail_call_sites: 1





What I'd like to know is what is guaranteed.

Previously gcc didn't emit the linkage name for any destructor -- but

this would make the proposed solution much harder to implement (gdb

would have to implement name mangling...).

So I suppose I'd like a guarantee that the destructor will be emitted

with at least one linkage name.

[Bug target/56214] [4.8 Regression] FAIL: gcc.c-torture/execute/20050121-1.c compilation, ICE

[danglin at gcc dot gnu.org]

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



--- Comment #2 from John David Anglin  2013-02-18 
15:21:41 UTC ---

Author: danglin

Date: Mon Feb 18 15:21:32 2013

New Revision: 196122



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

Log:

PR target/56214

* config/pa/predicates.md (base14_operand): Except for BLKmode, QImode

and HImode, require all displacements to be an integer multiple of the

mode size.

* config/pa/pa.c (pa_legitimate_address_p): For REG+BASE addresses,

only allow QImode and HImode when reload is in progress and strict is

true.  Likewise for symbolic addresses.  Use base14_operand to check

displacements in REG+BASE addresses.





Modified:

trunk/gcc/ChangeLog

trunk/gcc/config/pa/pa.c

trunk/gcc/config/pa/predicates.md

[Bug target/56214] [4.8 Regression] FAIL: gcc.c-torture/execute/20050121-1.c compilation, ICE

[danglin at gcc dot gnu.org]

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



John David Anglin  changed:



   What|Removed |Added



 Status|ASSIGNED|RESOLVED

 Resolution||FIXED



--- Comment #3 from John David Anglin  2013-02-18 
15:25:55 UTC ---

Fixed.

[Bug middle-end/56341] GCC produces unaligned data access

[sandra at codesourcery dot com]

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



Sandra Loosemore  changed:



   What|Removed |Added



 CC||sandra at codesourcery dot

   ||com



--- Comment #5 from Sandra Loosemore  
2013-02-18 15:30:16 UTC ---

The patch linked from the initial message was rejected.  I did not (and still

do not) have the time to rewrite it; if someone else can figure out how to fix

this in a way that's acceptable to the maintainers, that would be great.

[Bug c/56375] SIGSEGV when assign SIMD variable to member of allocated structure

[pinskia at gcc dot gnu.org]

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



--- Comment #2 from Andrew Pinski  2013-02-18 
16:04:49 UTC ---

(In reply to comment #1)

> User error, malloc doesn't guarantee sufficient alignment of the pointer, 
> which

> you are relying on.  You need to use posix_memalign or memalign or align it by

> hand yourself (allocate more for the padding).



Actually it does but that is an open question for the glibc list or where ever

the supplied malloc is from.

[Bug c++/56377] New: [4.8 Regression] template args in substitution-failure diagnostics

[pl.smith.mail at gmail dot com]

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

 Bug #: 56377
   Summary: [4.8 Regression]  template args in
substitution-failure diagnostics
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: pl.smith.m...@gmail.com


When a candidate function for which substituion failed is listed in a
diagnostic, if the failure stems from a template parameter that have an
explicit argument, the explicit arguments are listed as .

For example:

template 
typename T::type f();

int main () {
  f();
}

Produces (4.8, no flags):

test.cpp: In function ג€˜int main()ג€™:
test.cpp:5:10: error: no matching function for call to 'f()'
   f();
  ^
test.cpp:5:10: note: candidate is:
test.cpp:2:18: note: template typename T::type f()
 typename T::type f();
  ^
test.cpp:2:18: note:   template argument deduction/substitution failed:
  *
test.cpp: In substitution of 'template typename T::type f() [with T =
]':
  *
test.cpp:5:10:   required from here
test.cpp:2:18: error: 'int' is not a class, struct, or union type

In 4.7 it is "[with T = int]".

[Bug c++/56373] -Wzero-as-null-pointer-constant: does not catch issues with smart pointers

[paolo.carlini at oracle dot com]

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



Paolo Carlini  changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed||2013-02-18

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

   |gnu.org |com

 Ever Confirmed|0   |1



--- Comment #5 from Paolo Carlini  2013-02-18 
16:05:40 UTC ---

So confirming the first issue. I have a simple patch in testing for it.



About the second issue, it was definitely discussed somewhere else too: there

is always a tension between consistently treating in a similar way elementary

types and classes and avoiding warning for common patterns like RAII.

[Bug c++/56373] -Wzero-as-null-pointer-constant: does not catch issues with smart pointers

[paolo.carlini at oracle dot com]

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



Paolo Carlini  changed:



   What|Removed |Added



 Status|NEW |ASSIGNED

[Bug c++/56377] [4.8 Regression] template args in substitution-failure diagnostics

[pl.smith.mail at gmail dot com]

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



--- Comment #1 from Paul Smith  2013-02-18 
16:12:00 UTC ---

Looks like this was introduced in rev. 190664, with the merging of

'deduction_tsubst_fntype' into 'fn_type_unification'.



The instantiation context is constructed with 'targs' as the vector of template

arguments, which is still empty when substituting the explicit arguments into

the function type the first time. This can be fixed by either constructing the

instantiation context using 'explicit_targs' when non-null, or by copying

'explicit_targs' into 'targs' before the substitution.

[Bug c++/56377] [4.8 Regression] template args in substitution-failure diagnostics

[paolo.carlini at oracle dot com]

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



Paolo Carlini  changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed||2013-02-18

 CC||jason at gcc dot gnu.org

 Ever Confirmed|0   |1

[Bug target/47333] [4.6, 4.8 regression] g++.dg/lto/20091219 FAILs on Solaris 2 with SUN as

[ro at CeBiTec dot Uni-Bielefeld.DE]

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



--- Comment #30 from ro at CeBiTec dot Uni-Bielefeld.DE  2013-02-18 16:16:18 UTC ---

I've run another reghunt, which revealed that the 4.8 regression was

caused by this patch:



2012-05-23  Jan Hubicka  



   * tree.h (alias_diag_flags): Remove.

   (alias_pair): Remove emitted_diags.

   (finish_aliases_1, finish_aliases_2, remove_unreachable_alias_pairs,

   symbol_alias_set_t, symbol_alias_set_destroy,

   symbol_alias_set_contains, propagate_aliases_backward): Remove.

   * toplev.c (compile_file): Do not call finish_aliases_2

   * cgraphunit.c (cgraph_process_new_functions): Do not call

finish_aliases_1.

   (handle_alias_pairs): Output diagnostics about aliases to externals.

   (assemble_thunks_and_aliases): Use do_assemble_alias.

   (output_weakrefs): Likewise.

   (finalize_compilation_unit): Do not call finish_aliases_1.

   * ipa.c (symtab_remove_unreachable_nodes): De not call

remove_unreachable_alias_pairs.

   * varasm.c (do_assemble_alias): Export.

   (symbol_alias_set_create, symbol_alias_set_destroy,

symbol_alias_set_contains,

   symbol_alias_set_insert, propagate_aliases_forward,

propagate_aliases_backward,

   propagate_aliases_backward, trivially_visible_alias,

trivially_defined_alias,

   remove_unreachable_alias_pairs, finish_aliases_1, finish_aliases_2, 

   assemble_alias): Remove.

   * output.h (do_assemble_alias): Declare.

   * varpool.c (varpool_remove_unreferenced_decls): Do not call

finish_aliases_1.



Jan, could you please have a look?



Thanks.

Rainer

[Bug c/56375] SIGSEGV when assign SIMD variable to member of allocated structure

[jakub at gcc dot gnu.org]

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



--- Comment #3 from Jakub Jelinek  2013-02-18 
16:17:35 UTC ---

If you mean Joseph's http://sourceware.org/bugzilla/show_bug.cgi?id=6527

comment, then that is about _Decimal128, thus something not part of ISO C89 nor

ISO C99.

[Bug fortran/56378] New: gfortran internal compiler error

[david.sagan at gmail dot com]

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



 Bug #: 56378

   Summary: gfortran internal compiler error

Classification: Unclassified

   Product: gcc

   Version: 4.7.2

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: fortran

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

ReportedBy: david.sa...@gmail.com





1) Unpack and cd to the attached directory



2) Run the "doit" script. The result is:



DCS:erpsim1:~/dcs/bmad_distribution/bmad_dist/bad> gfortran --version

GNU Fortran (GCC) 4.6.2

Copyright (C) 2011 Free Software Foundation, Inc.



DCS:erpsim1:~/dcs/bmad_distribution/bmad_dist/bad> ./doit

compiling: precision_def.f90

compiling: bmad_struct.f90

compiling: fortran_cpp_utils.f90

compiling: bmad_cpp_convert_mod.f90

bmad_cpp_convert_mod.f90: In function 'lat_to_c':

bmad_cpp_convert_mod.f90:5622:0: internal compiler error: Segmentation fault

Please submit a full bug report,

with preprocessed source if appropriate.

See  for instructions.





This bug also appears with 4.6.3 and 4.7.2 (GNU Fortran (MacPorts gcc47

4.7.2_2). I have reproduced this bug on Linux and Mac.

[Bug target/56347] [4.8 Regression] FAIL: gfortran.dg/integer_exponentiation_2.f90 -O2 execution test

[danglin at gcc dot gnu.org]

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



--- Comment #6 from John David Anglin  2013-02-18 
16:29:56 UTC ---

Author: danglin

Date: Mon Feb 18 16:29:49 2013

New Revision: 196123



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

Log:

PR target/56347

* config/pa/pa.c (pa_conditional_register_usage): On HP-UX, mark

registers %fr12 and %fr12R as call used.





Modified:

trunk/gcc/ChangeLog

trunk/gcc/config/pa/pa.c

[Bug fortran/56378] gfortran internal compiler error

[kargl at gcc dot gnu.org]

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



kargl at gcc dot gnu.org changed:



   What|Removed |Added



 CC||kargl at gcc dot gnu.org



--- Comment #1 from kargl at gcc dot gnu.org 2013-02-18 16:34:12 UTC ---

(In reply to comment #0)

> 1) Unpack and cd to the attached directory

> 



There's no attachment.

[Bug fortran/56378] gfortran internal compiler error

[david.sagan at gmail dot com]

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



--- Comment #2 from David Sagan  2013-02-18 
16:34:30 UTC ---

Created attachment 29483

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

3 *.f90 files and script to run them

[Bug fortran/56378] gfortran internal compiler error

[david.sagan at gmail dot com]

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



--- Comment #3 from David Sagan  2013-02-18 
16:36:14 UTC ---

Somehow the attachment did not get sent with the initial writeup Now it is

downloaded.



(In reply to comment #1)

> (In reply to comment #0)

> > 1) Unpack and cd to the attached directory

> > 

> 

> There's no attachment.

[Bug libquadmath/56379] New: libquadmath: Wrong result for strtoflt128.c if compiled with -O0

[burnus at gcc dot gnu.org]

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

 Bug #: 56379
   Summary: libquadmath: Wrong result for strtoflt128.c if
compiled with -O0
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: libquadmath
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bur...@gcc.gnu.org
CC: ja...@gcc.gnu.org


As reported by Tilo Schwarz at
http://gcc.gnu.org/ml/fortran/2013-02/msg00091.html

When libquadmath's strtod/strtoflt128.c is compiled with -O1 or -O2, it gives
the correct result. However, for -O0 it doesn't. Hence, gfortran.dg/quad_2.f90
fails.

Mathematically,
sqrt(2.0) ==
1.414213562373095048801688724209698078569671875376948073176679737990…

The string str3 is (== fp2 and == fp4 with -O1/-O2):
str3 is "1.41421356237309504880168872420969798"

If libquadmath/strtod/strtoflt128.c is compiled with -O0, reading the string to
fp4 and printing its value yields:
   fp4: "1.41421356237309504885589883283397321"
   fp2-fp4: -0.0005421010862427522


Might (or might not) be related to PR48111 (strtoflt128 on MinGW).

[Bug c++/56380] New: Const/reference mutable members are not always rejected in class templates

[pl.smith.mail at gmail dot com]

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



 Bug #: 56380

   Summary: Const/reference mutable members are not always

rejected in class templates

Classification: Unclassified

   Product: gcc

   Version: unknown

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: c++

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

ReportedBy: pl.smith.m...@gmail.com





GCC (all versions?) accepts mutable members of const-qualified/reference type

in class templates, if the const-ness/reference-ness is introduced during

instantiation:



template 

struct X {

  X();

  mutable T x;

};



X a; // no error

X b;  // no error

[Bug c++/56381] New: ICE: cc1plus: internal compiler error: in gimplify_expr, at gimplify.c:7842

[vincenzo.innocente at cern dot ch]

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

 Bug #: 56381
   Summary: ICE: cc1plus: internal compiler error: in
gimplify_expr, at gimplify.c:7842
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: vincenzo.innoce...@cern.ch


on Linux
c++ -std=c++0x -msse3 -ftree-vectorize -O2 -s Cylinder.ii 
In member function 'virtual ReferenceCountingPointer
Cylinder::tangentPlane(const GlobalPoint&) const':
cc1plus: internal compiler error: in gimplify_expr, at gimplify.c:7842

on Mac

c++ -std=c++0x -msse3 -ftree-vectorize -O2 -s Cylinder.ii 
/build1/vin/CMSSW_6_2_X_2013-02-15-1400/src/DataFormats/GeometrySurface/src/Cylinder.cc:
In member function ‘virtual ReferenceCountingPointer
Cylinder::tangentPlane(const GlobalPoint&) const’:
/build1/vin/CMSSW_6_2_X_2013-02-15-1400/src/DataFormats/GeometrySurface/src/Cylinder.cc:23:1:
internal compiler error: Segmentation fault: 11

/build1/vin/CMSSW_6_2_X_2013-02-15-1400/src/DataFormats/GeometrySurface/src/Cylinder.cc:23:1:
internal compiler error: Abort trap: 6

c++: internal compiler error: Abort trap: 6 (program cc1plus)
Abort trap: 6

[Bug c++/56381] ICE: cc1plus: internal compiler error: in gimplify_expr, at gimplify.c:7842

[vincenzo.innocente at cern dot ch]

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



--- Comment #1 from vincenzo Innocente  
2013-02-18 17:10:03 UTC ---

Created attachment 29484

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

preprocessed file of user code (sorry for not reducing)

[Bug c/56370] RFE: warn on 'foo = realloc(foo, …)'

[dmalcolm at redhat dot com]

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



Dave Malcolm  changed:



   What|Removed |Added



 CC||dmalcolm at redhat dot com



--- Comment #2 from Dave Malcolm  2013-02-18 
17:25:22 UTC ---

[FWIW cppcheck has a warning about this specific issue

http://cppcheck.sourceforge.net/ ]

[Bug libquadmath/56379] libquadmath: Wrong result for strtoflt128.c if compiled with -O0

[burnus at gcc dot gnu.org]

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



Tobias Burnus  changed:



   What|Removed |Added



 CC||burnus at gcc dot gnu.org



--- Comment #1 from Tobias Burnus  2013-02-18 
17:31:26 UTC ---

C test case



#include 

#include 

int main ()

{

  __float128 r, sqrt2;

  r = strtoflt128 ("1.41421356237309504880168872420969798", NULL);

  printf ( "sqrt(2)=1.41421356237309504880168872420969798\n");

  printf ( "r  =%37.35Qf\n", r);

  return 0;

}

[Bug c++/56381] ICE: cc1plus: internal compiler error: in gimplify_expr, at gimplify.c:7842

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



 CC||jakub at gcc dot gnu.org



--- Comment #2 from Jakub Jelinek  2013-02-18 
17:33:24 UTC ---

Reducing.

[Bug c++/56380] Const/reference mutable members are not always rejected in class templates

[redi at gcc dot gnu.org]

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



Jonathan Wakely  changed:



   What|Removed |Added



   Keywords||accepts-invalid

 Status|UNCONFIRMED |NEW

   Last reconfirmed||2013-02-18

 Ever Confirmed|0   |1



--- Comment #1 from Jonathan Wakely  2013-02-18 
17:50:16 UTC ---

The mutable reference case was only fixed fairly recently for non-templates, as

PR 33558, it looks like a later check is needed to handle templates.

[Bug rtl-optimization/56348] internal compiler error in assign_by_spills with -m32 -fPIC -msse2

[vmakarov at gcc dot gnu.org]

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



Vladimir Makarov  changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 Resolution||FIXED



--- Comment #4 from Vladimir Makarov  2013-02-18 
18:01:25 UTC ---

I guess it was fixed.

[Bug target/56347] [4.8 Regression] FAIL: gfortran.dg/integer_exponentiation_2.f90 -O2 execution test

[danglin at gcc dot gnu.org]

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



--- Comment #7 from John David Anglin  2013-02-18 
18:04:23 UTC ---

Patch to remove old work around is here:

http://gcc.gnu.org/ml/gcc-patches/2013-02/msg00854.html

[Bug fortran/56378] gfortran internal compiler error

[Joost.VandeVondele at mat dot ethz.ch]

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

Joost VandeVondele  changed:

   What|Removed |Added

   Last reconfirmed||2013-02-18
 CC||Joost.VandeVondele at mat
   ||dot ethz.ch

--- Comment #4 from Joost VandeVondele  
2013-02-18 18:21:08 UTC ---
(In reply to comment #2)
> Created attachment 29483 [details]
> 3 *.f90 files and script to run them

confirmed for trunk.

> gfortran -c -ffree-line-length-none -fdollar-ok precision_def.f90 
> bmad_struct.f90 fortran_cpp_utils.f90 bmad_cpp_convert_mod.f90 
bmad_cpp_convert_mod.f90: In function ‘lat_to_c’:
bmad_cpp_convert_mod.f90:5622:0: internal compiler error: Segmentation fault
 c_logic(F%rf_auto_scale_amp), c_logic(F%use_ptc_layout))
 ^
0x9933bf crash_signal
../../gcc/gcc/toplev.c:332
0x616e18 conv_isocbinding_procedure
../../gcc/gcc/fortran/trans-expr.c:3728
0x616e18 gfc_conv_procedure_call(gfc_se*, gfc_symbol*, gfc_actual_arglist*,
gfc_expr*, vec*)
../../gcc/gcc/fortran/trans-expr.c:3968
0x6187ea gfc_conv_function_expr
../../gcc/gcc/fortran/trans-expr.c:5566
0x613a8a gfc_conv_procedure_call(gfc_se*, gfc_symbol*, gfc_actual_arglist*,
gfc_expr*, vec*)
../../gcc/gcc/fortran/trans-expr.c:4230
0x639e06 gfc_trans_call(gfc_code*, bool, tree_node*, tree_node*, bool)
../../gcc/gcc/fortran/trans-stmt.c:406
0x5de8b1 trans_code
../../gcc/gcc/fortran/trans.c:1500

[Bug middle-end/56382] New: FAIL: gcc.c-torture/compile/pr55921.c (internal compiler error)

[danglin at gcc dot gnu.org]

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



 Bug #: 56382

   Summary: FAIL: gcc.c-torture/compile/pr55921.c  (internal

compiler error)

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

  Host: hppa64-hp-hpux11.11

Target: hppa64-hp-hpux11.11

 Build: hppa64-hp-hpux11.11





This is a problem extracting the first subreg from a SCmode value.  Thia

occurs during reload after the point where pseudos can be created but we

need a pseudo to extract the subreg.  The problem is SCmode is the same

size as DImode on this target, so the subreg can't be extracted by a move.



I marked this a middle-end bug as the documentation indicates that complex

values are handled by it.

[Bug middle-end/56382] FAIL: gcc.c-torture/compile/pr55921.c (internal compiler error)

[danglin at gcc dot gnu.org]

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



--- Comment #1 from John David Anglin  2013-02-18 
18:34:54 UTC ---

Created attachment 29485

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

Patch



I tried the above changes to expmed.c but this

approach eventually reaches a gcc_unreacheable

dead end.

[Bug middle-end/56341] GCC produces unaligned data access

[bernd.edlinger at hotmail dot de]

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



--- Comment #6 from Bernd Edlinger  
2013-02-18 18:41:55 UTC ---

hhmm...



could some one give an example where packedp would be false but the value

is packed or unaligned?

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

[tkoenig at gcc dot gnu.org]

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



--- Comment #44 from Thomas Koenig  2013-02-18 
18:44:02 UTC ---

If unformatted sequential ever worked, it was by chance.



Look at this piece of code:



  /* Seek to the head and overwrite the bogus length with the real

 length.  */



  if (unlikely (sseek (dtp->u.p.current_unit->s, - m - 2 * record_marker, 

   SEEK_CUR) < 0))

goto io_error;



This works if it happens within a buffer, but you cannot rely on that.



I would therefore suggest to resolve this PR by issuing a well-defined

error if we encounter a pipe on opening.



I'll prepare a patch.

[Bug fortran/56378] gfortran internal compiler error

[Joost.VandeVondele at mat dot ethz.ch]

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



--- Comment #5 from Joost VandeVondele  
2013-02-18 18:48:28 UTC ---

simplified testcase:





module t

 use, intrinsic :: iso_c_binding

 interface fvec2vec

   module procedure int_fvec2vec

 end interface

contains

 function int_fvec2vec (f_vec, n) result (c_vec)

 integer f_vec(:)

 integer(c_int), target :: c_vec(n)

 end function int_fvec2vec

 subroutine lat_to_c (Fp, C) bind(c)

 integer, allocatable :: ic(:)

 call lat_to_c2 (c_loc(fvec2vec(ic, n1_ic)))

 end subroutine lat_to_c

end module



looks like related to having a c_loc on an interfacedd function result.

[Bug libstdc++/56383] New: error with multiple enable_shared_from_this base classes

[redi at gcc dot gnu.org]

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



 Bug #: 56383

   Summary: error with multiple enable_shared_from_this base

classes

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Keywords: rejects-valid

  Severity: normal

  Priority: P3

 Component: libstdc++

AssignedTo: r...@gcc.gnu.org

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





This should compile and exit normally:



#include 

#include 



struct A : std::enable_shared_from_this

{

void* a() { return shared_from_this().get(); }

};



struct B : std::enable_shared_from_this

{

};



struct D : A, B

{

};



int main()

{

auto d = std::make_shared();

try

{

d->a();

std::abort();

}

catch (std::bad_weak_ptr const&)

{ }

}



I have a fix in mind, but it can wait for post-4.8.0

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

[dominiq at lps dot ens.fr]

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



--- Comment #45 from Dominique d'Humieres  
2013-02-18 19:15:43 UTC ---

> ...

> I would therefore suggest to resolve this PR by issuing a well-defined

> error if we encounter a pipe on opening.



Are you suggesting to "fix" the non working named pipes on Darwin by removing

them everywhere?

If yes, isn't it a little bit too radical?



If there are pieces of code working only by chance, would not it be better to

fix them?

[Bug fortran/56378] gfortran internal compiler error

[dominiq at lps dot ens.fr]

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



Dominique d'Humieres  changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

 Ever Confirmed|0   |1



--- Comment #6 from Dominique d'Humieres  2013-02-18 
19:21:18 UTC ---

If I do the following changes to the test in comment #5 in order to silence the

warnings " ... may not be C interoperable ... ":



module t

 use, intrinsic :: iso_c_binding



 interface fvec2vec

   module procedure int_fvec2vec

 end interface

contains

 function int_fvec2vec (f_vec, n) result (c_vec)

 integer f_vec(:)

 integer(c_int), target :: c_vec(n)

 end function int_fvec2vec

 subroutine lat_to_c (Fp) bind(c)

 type(c_ptr), value :: Fp

 integer(c_int) :: n1_ic



 integer, allocatable :: ic(:)

 call lat_to_c2 (c_loc(fvec2vec(ic, n1_ic)))

 end subroutine lat_to_c

end module

end



revision 158253 (2010-04-13) gives a (bogus?) error



pr56378_db.f90:17.23:



 call lat_to_c2 (c_loc(fvec2vec(ic, n1_ic)))

   1

Error: Parameter 'fvec2vec' to 'c_loc' at (1) must be either a TARGET or an

associated pointer



while revision 162456 (2010-07-23) gives the ICE.

[Bug c++/56381] ICE: cc1plus: internal compiler error: in gimplify_expr, at gimplify.c:7842

[jakub at gcc dot gnu.org]

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



--- Comment #3 from Jakub Jelinek  2013-02-18 
19:24:28 UTC ---

Created attachment 29486

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

pr56381.ii



Somewhat reduced, just -std=c++11 -O2 is enough to reproduce.

[Bug c++/56381] ICE: cc1plus: internal compiler error: in gimplify_expr, at gimplify.c:7842

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



 Status|UNCONFIRMED |ASSIGNED

   Last reconfirmed||2013-02-18

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

   |gnu.org |

 Ever Confirmed|0   |1



--- Comment #4 from Jakub Jelinek  2013-02-18 
19:36:25 UTC ---

Created attachment 29487

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

gcc48-pr56381.patch



Untested fix.

[Bug target/55939] [4.6/4.7/4.8 regression] gcc miscompiles gmp-5.0.5 on m68k-linux

[aldyh at gcc dot gnu.org]

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



Aldy Hernandez  changed:



   What|Removed |Added



 CC||aldyh at gcc dot gnu.org



--- Comment #21 from Aldy Hernandez  2013-02-18 
19:38:40 UTC ---

Another less invasive option could be to force the return value of my_ldexp()

to go through memory, thus chopping off the excess precision before returning:



--- a.c2013-02-18 20:37:23.0 +0100

+++ b.c2013-02-18 20:36:42.0 +0100

@@ -404,7 +404,11 @@

 e += 1;

 }

 } else

-  return d;

+  {

+volatile double force_round = d;

+return force_round;

+

+  }

 }

 }



But basically, you'd have to carefully keep track of when you have to use

volatiles.

[Bug c++/56381] [4.7/4.8 Regression] ICE: cc1plus: internal compiler error: in gimplify_expr, at gimplify.c:7842

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



   Target Milestone|--- |4.7.3

Summary|ICE: cc1plus: internal  |[4.7/4.8 Regression] ICE:

   |compiler error: in  |cc1plus: internal compiler

   |gimplify_expr, at   |error: in gimplify_expr, at

   |gimplify.c:7842 |gimplify.c:7842



--- Comment #5 from Jakub Jelinek  2013-02-18 
19:39:21 UTC ---

Introduced with http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=178595

thus 4.7/4.8 Regression.

[Bug tree-optimization/56384] New: ICE in fold_binary_loc, at fold-const.c:10422

[antoine.balestrat at gmail dot com]

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

 Bug #: 56384
   Summary: ICE in fold_binary_loc, at fold-const.c:10422
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: antoine.balest...@gmail.com


With GCC 4.8.0 as of 20130218 :

$ cat fold.c
int a, c;

void f(void)
{
unsigned char b;

if(a)
{
for(; b < 1; b++);
lbl1:
c = (b |= 0) ^ (b || a);
}

if((a = b))
{
b = c;
goto lbl1;
}

b = 5;
goto lbl1;
}


$ xgcc -w -O2 fold.c
fold.c: In function ‘f’:
fold.c:3:6: internal compiler error: in fold_binary_loc, at fold-const.c:10422
 void f(void)
  ^
0x70146d fold_binary_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
../../srcdir/gcc/fold-const.c:10422
0x76613f gimple_fold_stmt_to_constant_1(gimple_statement_d*, tree_node*
(*)(tree_node*))
../../srcdir/gcc/gimple-fold.c:2575
0xa3a8d4 try_to_simplify
../../srcdir/gcc/tree-ssa-sccvn.c:3257
0xa3a8d4 visit_use
../../srcdir/gcc/tree-ssa-sccvn.c:3334
0xa3d248 process_scc
../../srcdir/gcc/tree-ssa-sccvn.c:3671
0xa3d248 extract_and_process_scc_for_name
../../srcdir/gcc/tree-ssa-sccvn.c:3728
0xa3d248 DFS
../../srcdir/gcc/tree-ssa-sccvn.c:3782
0xa3d248 run_scc_vn(vn_lookup_kind)
../../srcdir/gcc/tree-ssa-sccvn.c:4028
0xa20437 do_pre
../../srcdir/gcc/tree-ssa-pre.c:4701
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.

[Bug pch/54117] [4.8 Regression] FAIL: ./decl-3.h -O0 -g (internal compiler error)

[jakub at gcc dot gnu.org]

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



--- Comment #20 from Jakub Jelinek  2013-02-18 
19:43:06 UTC ---

Author: jakub

Date: Mon Feb 18 19:42:56 2013

New Revision: 196124



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

Log:

PR pch/54117

* c-opts.c (c_common_post_options): If debug info is enabled

and non-dwarf*, refuse to load PCH files and when writing PCH

file warn.



* lib/dg-pch.exp (pch-init, pch-finish,

check_effective_target_pch_supported_debug): New procs.

(dg-flags-pch): If $pch_unsupported, make tests UNSUPPORTED.

Likewise if $pch_unsupported_debug and $flags include -g.

Skip FAILs about missing *.gch file if $pch_unsupported_debug

and dg-require-effective-target pch_unsupported_debug.

* g++.dg/pch/pch.exp: Call pch-init and pch-finish.

* objc.dg/pch/pch.exp: Likewise.

* gcc.dg/pch/pch.exp: Likewise.

* gcc.dg/pch/valid-1.c: Add dg-require-effective-target

pch_unsupported_debug.

* gcc.dg/pch/valid-1.hs: Likewise.

* gcc.dg/pch/valid-1b.c: Likewise.

* gcc.dg/pch/valid-1b.hs: Likewise.



Modified:

trunk/gcc/c-family/ChangeLog

trunk/gcc/c-family/c-opts.c

trunk/gcc/testsuite/ChangeLog

trunk/gcc/testsuite/g++.dg/pch/pch.exp

trunk/gcc/testsuite/gcc.dg/pch/pch.exp

trunk/gcc/testsuite/gcc.dg/pch/valid-1.c

trunk/gcc/testsuite/gcc.dg/pch/valid-1.hs

trunk/gcc/testsuite/gcc.dg/pch/valid-1b.c

trunk/gcc/testsuite/gcc.dg/pch/valid-1b.hs

trunk/gcc/testsuite/lib/dg-pch.exp

trunk/gcc/testsuite/objc.dg/pch/pch.exp

[Bug pch/54117] [4.8 Regression] FAIL: ./decl-3.h -O0 -g (internal compiler error)

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



 Status|ASSIGNED|RESOLVED

 Resolution||FIXED



--- Comment #21 from Jakub Jelinek  2013-02-18 
19:50:38 UTC ---

Fixed by disabling PCH if producing debug info other than DWARF*.

[Bug fortran/56378] [4.6/4.7/4.8 Regression] gfortran internal compiler error

[janus at gcc dot gnu.org]

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



janus at gcc dot gnu.org changed:



   What|Removed |Added



   Keywords||ice-on-invalid-code

 CC||janus at gcc dot gnu.org

Summary|gfortran internal compiler  |[4.6/4.7/4.8 Regression]

   |error   |gfortran internal compiler

   ||error



--- Comment #7 from janus at gcc dot gnu.org 2013-02-18 19:56:07 UTC ---

Comment 6 segfaults with 4.6, 4.7 and trunk for me, but gives the error message

with 4.3.

[Bug tree-optimization/56365] Missed opportunities for smin/smax standard name patterns

[olegendo at gcc dot gnu.org]

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



--- Comment #2 from Oleg Endo  2013-02-18 20:04:40 
UTC ---

(In reply to comment #1)

> I see, at -O2, on x86_64 in 070t.phiopt:

> 

> test_04 (int a, int b)

> {

>   int D.1744;

>   int D.1741;

>   int _3;

>   int _4;

> 

>   :

>   _3 = MIN_EXPR ;

>   _4 = MAX_EXPR <_3, -128>;

>   return _4;

> 

> }



Ah yes, now I see that here, too.  I don't know where or how I was looking,

sorry.