[Bug c++/58372] internal compiler error: ix86_compute_frame_layout

2018-10-29 Thread ktietz at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58372

--- Comment #16 from Kai Tietz  ---
(In reply to Uroš Bizjak from comment #15)
> (In reply to David Grayson from comment #14)
> 
> > Does anyone have an idea of how to fix this bug for real?  What values
> > should crtl->preferred_stack_boundary crtl->stack_alignment_needed really
> > have  on Windows, and should they be controllable from the command-line? 
> > Where do they get set?
> > 
> > --David
> 
> Reading symbols from /ssd/uros/gcc-build-xxx/gcc/cc1plus...done.
> (gdb) watch x_rtl.preferred_stack_boundary 
> 
> Hardware watchpoint 1: x_rtl.preferred_stack_boundary
> 
> (gdb) r
> Starting program: /ssd/uros/gcc-build-xxx/gcc/cc1plus pr58372.C
> Hardware watchpoint 1: x_rtl.preferred_stack_boundary
> 
> Old value = 0
> New value = 32
> 0x00b930dc in rtl_data::init_stack_alignment (this=0x23c8ac0
> ) at /home/uros/gcc-svn/trunk/gcc/emit-rtl.c:6636
> 6636  preferred_stack_boundary = STACK_BOUNDARY;
> 
> Hardware watchpoint 1: x_rtl.preferred_stack_boundary
> 
> Old value = 32
> New value = 128
> emit_library_call_value_1(int, rtx_def*, rtx_def*, libcall_type,
> machine_mode, int, std::pair*) ()
> at /home/uros/gcc-svn/trunk/gcc/calls.c:4744
> 4744  if (outmode != VOIDmode)
> 
> (gdb) list
> 4739  if (crtl->preferred_stack_boundary < PREFERRED_STACK_BOUNDARY)
> 4740crtl->preferred_stack_boundary = PREFERRED_STACK_BOUNDARY;
> 4741
> 4742  /* If this kind of value comes back in memory,
> 4743 decide where in memory it should come back.  */
> 4744  if (outmode != VOIDmode)
> 4745{
> 4746  tfom = lang_hooks.types.type_for_mode (outmode, 0);
> 4747  if (aggregate_value_p (tfom, 0))
> 4748{
> 
> This happen when building SjLj landing pads:
> 
> #0  emit_library_call_value_1(int, rtx_def*, rtx_def*, libcall_type,
> machine_mode, int, std::pair*)
> () at /home/uros/gcc-svn/trunk/gcc/calls.c:4744
> #1  0x00b9b36c in emit_library_call (arg1_mode=,
> arg1=, outmode=E_VOIDmode, 
> fn_type=LCT_NORMAL, fun=) at
> /home/uros/gcc-svn/trunk/gcc/rtl.h:4123
> #2  sjlj_emit_function_enter(rtx_code_label*) () at
> /home/uros/gcc-svn/trunk/gcc/except.c:1202
> #3  0x00b9f20a in sjlj_build_landing_pads () at
> /home/uros/gcc-svn/trunk/gcc/except.c:1481
> #4  finish_eh_generation() () at /home/uros/gcc-svn/trunk/gcc/except.c:1510
> 
> Adding -mpreferred-stack-boundary=2 "fixes" compilation.
> 
> If you want to experiment, try the following patch:
> 
> Index: config/i386/mingw32.h
> ===
> --- config/i386/mingw32.h   (revision 265582)
> +++ config/i386/mingw32.h   (working copy)
> @@ -251,6 +251,10 @@
>  #undef  CHECK_EXECUTE_STACK_ENABLED
>  #define CHECK_EXECUTE_STACK_ENABLED flag_setstackexecutable
>  
> +#undef PREFERRED_STACK_BOUNDARY_DEFAULT
> +#define PREFERRED_STACK_BOUNDARY_DEFAULT   \
> +  (TARGET_64BIT ? 128 : MIN_STACK_BOUNDARY)
> +
>  /* This matches SHLIB_SONAME and SHLIB_SOVERSION in t-cygming. */
>  /* This matches SHLIB_SONAME and SHLIB_SOVERSION in t-cygwin. */
>  #if DWARF2_UNWIND_INFO> 
> But I don't know the details of MS ABI, so I can't tell if the patch is
> correct.

The x64 ABI part is correct, as for x64 abit there is just 16-byte stack
alignment. For x86 ms abi things aren't that strict AFAIK. The common stack
alignment on function entry is the natural one, but there is in general no
strict requirement for it. So the patch looks fine, but should be commented in
the release notes, as there might be fallout seen caused by it.

[Bug target/85238] [8 Regression] lto-wrapper: fatal error: simple_object_copy_lto_debug_sections not implemented: Invalid argument on Cygwin

2018-04-06 Thread ktietz at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85238

Kai Tietz  changed:

   What|Removed |Added

 CC||ktietz at gcc dot gnu.org

--- Comment #2 from Kai Tietz  ---
as intermediate the duplication of darwin's logic is fine. Nevertheless I would
prefer proper support of COFF here.

[Bug c++/52792] this pointer and return pointer are passed in wrong order when ms_abi is used (x86_64)

2018-02-28 Thread ktietz at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52792

--- Comment #5 from Kai Tietz  ---
For the c++ sample:
typedef struct agg { long a; long b; long c; } agg;

class abc {
   long m;
public:
   agg foo(long a, long b, long c);
   agg boo(void);
};


agg abc::foo(long a, long b, long c)
{
  agg r = { a, b, c};
  m = a + b +c;
  return r;
}

MS' compiler produces for foo() method:
?foo@abc@@QAE?AUagg@@JJJ@Z:
 pushebp
 mov ebp, esp
 mov eax, [ebp+8]
 mov edx, [ebp+10h]
 pushesi
 mov esi, [ebp+14h]
 pushedi
 mov edi, [ebp+0Ch]
 mov [eax+4], edx
 add edx, edi
 mov [eax], edi
 add edx, esi
 pop edi
 mov [eax+8], esi
 mov [ecx], edx
 pop esi
 pop ebp
 retn10h

g++ produces on x86 (with -O2 -fno-omit-frame-pointer):
__ZN3abc3fooElll:
pushl   %ebp
movl%ecx, %eax
movl%esp, %ebp
pushl   %ebx
movl16(%ebp), %ecx
movl12(%ebp), %ebx
movl20(%ebp), %edx
movl%ecx, 4(%eax)
addl%ebx, %ecx
movl%ebx, (%eax)
movl%edx, 8(%eax)
addl%ecx, %edx
movl8(%ebp), %ecx
movl%edx, (%ecx)
popl%ebx
popl%ebp
ret $16

As we can see are for the ms compiler the argument 'this' passed in ecx, and
the aggregate pointer as first stack argument.  For g++ 'this' is passed on
stack, and the aggregate uses the 'ecx' register.

For x64 ms' compiler produces for foo() member:
?foo@abc@@QEAA?AUagg@@JJJ@Z:; DATA XREF: .rdata:off_140002748↓o
 mov r10d, [rsp+28h]
 lea eax, [r8+r9]
 add eax, r10d
 mov [rdx], r8d
 mov [rcx], eax
 mov rax, rdx
 mov [rdx+4], r9d
 mov [rdx+8], r10d
 retn

g++ (with -O2) produces for x86_64 msabi:
_ZN3abc3fooElll:
.LFB0:
.seh_endprologue
movq%rcx, %rax
movl40(%rsp), %ecx
movl%r9d, 4(%rax)
addl%r8d, %r9d
movl%r8d, (%rax)
movl%ecx, 8(%rax)
addl%r9d, %ecx
movl%ecx, (%rdx)
ret

For ms' compiler it passes 'this' in rcx, and the aggregate pointer in 'rdx'.
For g++ it passes 'this' in rdx, and the aggregate pointer in 'rcx'.

[Bug c++/52792] this pointer and return pointer are passed in wrong order when ms_abi is used (x86_64)

2018-02-28 Thread ktietz at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52792

Kai Tietz  changed:

   What|Removed |Added

 Target||i?86-*-* x86_64-*-*

--- Comment #4 from Kai Tietz  ---
This issue isn't just about c++. It is for calling conventions using register
as arguments.

For following small sample (using ms_abi by default):

typedef struct agg { long a; long b; long c; } agg;

__declspec(dllexport) struct agg __fastcall c_fastcall(long a, long b, long c)
{
  agg r = { a, b, c};
  return r;
}

MS' compiler produces:
@c_fastcall@12:
  pushebp
  mov ebp, esp
  mov eax, [ebp+8]
  mov [eax], ecx
  mov ecx, [ebp+0Ch]
  mov [eax+4], edx
  mov [eax+8], ecx
  pop ebp
  retn8

but gcc produces for x86:

@c_fastcall@12:
pushl   %ebp
movl%edx, (%ecx)
movl%ecx, %eax
movl%esp, %ebp
movl8(%ebp), %edx
movl%edx, 4(%ecx)
movl12(%ebp), %edx
popl%ebp
movl%edx, 8(%ecx)
ret $8

(using -O2 -fno-omit-frame-pointer)

as you can see is the aggregate pointer passed by ms via stack, but by gcc via
first argument register.

[Bug c++/52792] this pointer and return pointer are passed in wrong order when ms_abi is used (x86_64)

2018-02-28 Thread ktietz at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52792

Kai Tietz  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-02-28
 Ever confirmed|0   |1

--- Comment #3 from Kai Tietz  ---
confirmed. It is related to implicit argument ordering of 'this' and the
aggregate.

[Bug rtl-optimization/84527] missed optimization for special ternary operation

2018-02-23 Thread ktietz at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84527

Kai Tietz  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #6 from Kai Tietz  ---
ah, right. sorry for the noise. thanks for pointing out

[Bug rtl-optimization/84527] missed optimization for special ternary operation

2018-02-23 Thread ktietz at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84527

--- Comment #4 from Kai Tietz  ---
(In reply to Jakub Jelinek from comment #3)
> ..., but that just means it is not the right code for f1 and f3.

Right, that produced code depends on the sign of the condition arguments seems
to be pretty wrong

[Bug rtl-optimization/84527] missed optimization for special ternary operation

2018-02-23 Thread ktietz at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84527

--- Comment #1 from Kai Tietz  ---
For x86 we produce for sample:
movl8(%esp), %eax
cmpl%eax, 4(%esp)
setge   %al
movzbl  %al, %eax
leal-1(%eax,%eax), %eax
ret

which could be expressed with one instruction less as
movl4(%esp), %eax
cmpl%eax, 8(%esp)
sbbl%eax, %eax
orb $1, %al
ret

[Bug rtl-optimization/84527] New: missed optimization for special ternary operation

2018-02-23 Thread ktietz at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84527

Bug ID: 84527
   Summary: missed optimization for special ternary operation
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ktietz at gcc dot gnu.org
  Target Milestone: ---

The following sample:

int foo(int a, int b)
{
  return a < b ? -1 : 1;
}

gets translated to

...
xorl%eax, %eax
cmpl%edx, %ecx
setge   %al
leal-1(%rax,%rax), %eax
ret
...

There would be instead a better representation for such kind of patterns as

... cmpl %ecx, %edx
sbb  %eax, %eax
orb  $1, %al
ret

The missed patterns are 'result = COND ? -1 : VAL' and its permutations.

The same applies to the pattern 'result = COND ? VAL : 0' and its permuations,
which can be expressed as 'CMP a, b; SBB reg, reg; AND $VAL, reg;'

[Bug target/66488] segfault on sizeof(long) < sizeof(void*) and large GCC memory usage

2016-08-11 Thread ktietz at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66488

Kai Tietz  changed:

   What|Removed |Added

 CC||ktietz at gcc dot gnu.org

--- Comment #11 from Kai Tietz  ---
Patch is obviously correct. Please send it to ML. It is pre-approved.

[Bug c++/70869] [6/7 Regression] internal compiler error: Segmentation fault on array of pointer to function members

2016-05-12 Thread ktietz at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70869

Kai Tietz  changed:

   What|Removed |Added

  Attachment #38472|0   |1
is obsolete||

--- Comment #15 from Kai Tietz  ---
Created attachment 38477
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38477=edit
updated patch

Updated patch.  If approved feel free to commit.  I am currently not able to
commit to repository due I need to recover my key-files ... and didn't found
time

[Bug c++/71082] Internal compiler error when create initializer list with pointers to members

2016-05-12 Thread ktietz at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71082

Kai Tietz  changed:

   What|Removed |Added

 CC||ktietz at gcc dot gnu.org

--- Comment #2 from Kai Tietz  ---
Looks to me like a dup of PR/70869.
Testcase looks pretty much like report for dup pr/71054

[Bug c++/70869] [6/7 Regression] internal compiler error: Segmentation fault on array of pointer to function members

2016-05-12 Thread ktietz at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70869

Kai Tietz  changed:

   What|Removed |Added

  Attachment #38469|0   |1
is obsolete||
  Attachment #38470|0   |1
is obsolete||

--- Comment #13 from Kai Tietz  ---
Created attachment 38472
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38472=edit
updated patch

I just noticed I missed to provide my current change.  It might be related to
the build failure you noticed.

In general it isn't clear, if we should prevent deeper recursions of
DECL_INITIAL.  In some cases "var = var;" seems to be valid, so we need to
handle that.

[Bug c++/70869] [6/7 Regression] internal compiler error: Segmentation fault on array of pointer to function members

2016-05-12 Thread ktietz at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70869

--- Comment #11 from Kai Tietz  ---
this doesn't seem to be related with my patch at all.  It looks more like you
are trying to re-use an old build tree.  Patch is made against trunk. 
Nevertheless should work for 6.x branch, too.
I build in general just a cross-compiler, and this works with and without this
patch flawless.

[Bug c++/70869] [6/7 Regression] internal compiler error: Segmentation fault on array of pointer to function members

2016-05-11 Thread ktietz at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70869

--- Comment #9 from Kai Tietz  ---
Created attachment 38470
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38470=edit
updated patch

Well, DECL_P check is indeed superfluous, but I added to point out we are
checking here for declarations.  but VAR_P should be indeed enough.

The OBJ_TYPE_REF hunk is related to PR/71029, and can be ignored. I removed it
from update.

[Bug c++/70869] [6/7 Regression] internal compiler error: Segmentation fault on array of pointer to function members

2016-05-11 Thread ktietz at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70869

Kai Tietz  changed:

   What|Removed |Added

 CC||john.ettedgui at gmail dot com

--- Comment #6 from Kai Tietz  ---
*** Bug 71054 has been marked as a duplicate of this bug. ***

[Bug c++/70869] [6/7 Regression] internal compiler error: Segmentation fault on array of pointer to function members

2016-05-11 Thread ktietz at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70869

Kai Tietz  changed:

   What|Removed |Added

 CC||ktietz at gcc dot gnu.org

--- Comment #7 from Kai Tietz  ---
Created attachment 38469
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38469=edit
suggested patch

This fixes the issue for me. Additionally this change addresse reported issue
for PR 71029, which was about too long folding about OBJ_TYPE_REFs.

[Bug c++/71054] [6/7 Regression] ICE: in expand_expr_real_2, at expr.c:8097

2016-05-11 Thread ktietz at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71054

Kai Tietz  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||ktietz at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #5 from Kai Tietz  ---
it is a duplicate.

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

[Bug c++/70847] [6/7 Regression] exponential time in cp_fold for chained virtual function calls

2016-04-28 Thread ktietz at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70847

--- Comment #4 from Kai Tietz  ---
As side-note:  There is something pretty fishy in tree-pretty-print.c for
OBJ_TYPE_REF, too.  We do here recurse endless.  Simply add to command line
'-fdump-tree-original' for reproducing.

[Bug c++/70847] [6/7 Regression] exponential time in cp_fold for chained virtual function calls

2016-04-28 Thread ktietz at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70847

Kai Tietz  changed:

   What|Removed |Added

 CC||ktietz at gcc dot gnu.org

--- Comment #3 from Kai Tietz  ---
This seems to be related to cp_fold_r's behavior to walk subtree for
OBJ_TYPE_REF.
Normally we can assume that in case of an OBJ_TYPE_REF tree, it was already
folded.  So we don't need to walk it again .

The following patch solves the issue for me on m32c.

Index: ../gcc/cp/cp-gimplify.c
===
--- ../gcc/cp/cp-gimplify.c (revision 235430)
+++ ../gcc/cp/cp-gimplify.c (working copy)
@@ -986,7 +986,8 @@
   cp_walk_tree (_FOR_PRE_BODY (stmt), cp_fold_r, data, NULL);
   *walk_subtrees = 0;
 }
-
+  else if (code == OBJ_TYPE_REF)
+*walk_subtrees = 0;
   return NULL;
 }

[Bug target/62109] __gthr_i486_lock_cmp_xchg missing clobber

2015-10-23 Thread ktietz at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62109

--- Comment #11 from Kai Tietz  ---
(In reply to David from comment #10)
> (In reply to Kai Tietz from comment #5)
> > This patch is clear stage 1 material. 
> 
> We're in stage 1.  Is it time?

Sure, patch for it is welcome.

> The patch adds the memory clobber, but I think the conclusion here was to
> remove __gthr_i486_lock_cmp_xchg since it only applies to (the no longer
> supported) win95.

Right, I prefer this.


[Bug target/51726] LTO and attribute 'selectany'

2015-10-02 Thread ktietz at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51726

--- Comment #9 from Kai Tietz  ---
Author: ktietz
Date: Fri Oct  2 08:06:52 2015
New Revision: 228370

URL: https://gcc.gnu.org/viewcvs?rev=228370=gcc=rev
Log:
PR target/51726
* config/i386/winnt.c (ix86_handle_selectany_attribute): Handle
selectany within this function without need to keep attribute.
(i386_pe_encode_section_info): Remove selectany-code.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/winnt.c


[Bug target/51726] LTO and attribute 'selectany'

2015-10-02 Thread ktietz at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51726

--- Comment #10 from Kai Tietz  ---
Author: ktietz
Date: Fri Oct  2 08:08:38 2015
New Revision: 228371

URL: https://gcc.gnu.org/viewcvs?rev=228371=gcc=rev
Log:
PR target/51726
* g++.dg/ext/selectany2.C: Allow uninitialized variable case.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/ext/selectany2.C


[Bug target/67688] [MinGW/Cygwin] Attributes selectany and section cannot be used together

2015-10-01 Thread ktietz at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67688

Kai Tietz  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||ktietz at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #1 from Kai Tietz  ---
This report is a duplicate of PR/51726.
Fix for it also resolves this problem.

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


[Bug target/51726] LTO and attribute 'selectany'

2015-10-01 Thread ktietz at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51726

Kai Tietz  changed:

   What|Removed |Added

 CC||thiago at kde dot org

--- Comment #8 from Kai Tietz  ---
*** Bug 67688 has been marked as a duplicate of this bug. ***


[Bug target/51726] LTO and attribute 'selectany'

2015-09-30 Thread ktietz at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51726

--- Comment #6 from Kai Tietz  ---
Created attachment 36427
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36427=edit
Suggested patch

I will do some further testing with that patch, and later on send patch
upstream with a testcase for the common-case with selectany-attribute.

It would be appreciated  if you could test patch too.


[Bug target/65782] Assembly failure (invalid register for .seh_savexmm) with -O3 -mavx512f on mingw-w64

2015-09-22 Thread ktietz at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65782

Kai Tietz  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-09-22
 CC||ktietz at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Kai Tietz  ---
This issue is related to output in gcc for SEH-prologue pseudos.  It tries to
output registers not being supported 8-byte SSE ones.

Generally, AVX512 can't be supported in an 32-byte aligned way on x64 target
anyway.


[Bug c++/54895] the compiler treats '__cdecl' & '__stdcall' as the same.

2015-09-22 Thread ktietz at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54895

--- Comment #12 from Kai Tietz  ---
This bug got partially fixed for x86 (32-bit) by PR/44282.  For x64 we have the
issue that there is made no difference between different calling-conventions,
as all variants are treated as standard fastcall-convention under the hood.


[Bug target/54412] Request for 32-byte stack alignment with -mavx on Windows

2015-09-22 Thread ktietz at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54412

Kai Tietz  changed:

   What|Removed |Added

 Status|UNCONFIRMED |SUSPENDED
   Last reconfirmed||2015-09-22
 Ever confirmed|0   |1

--- Comment #12 from Kai Tietz  ---
It is good to hear that issue is fixed for 32-bit.  But for 64-bit - as I
already explained in comment above - this issue isn't fixable for
stack-variables.

The problem is that for x64 ABI we are tighten bound to SEH-prologue
information, and this can't express alignment-operations.  The x64 ABI
guarantee 16 byte alignment on function entry, therefore sse 128-bit operations
are possible to be placed fully aligned on stack, but higher alignment is
simply not expressible.

Therefore I will need to set this bug to suspended.  If this information gets
in future extended to allow such prologue-information we need for alignment,
then we will be able to fix that.  So long it is suspended.


[Bug bootstrap/67546] bootstrap broken on x86_64-w64-mingw32, error: '::unsetenv' has not been declared in gcc.c

2015-09-11 Thread ktietz at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67546

Kai Tietz  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-09-11
 CC||ktietz at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Kai Tietz  ---
I added to mingw-w64's libwinpthread a work-a-round for this sloopy code in
libgomp.  Nevertheless issue should be fixed IMO in libgomp, too


[Bug libgomp/67141] wrong libgomp mutex initialisation order

2015-09-11 Thread ktietz at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67141

Kai Tietz  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-09-11
 CC||ktietz at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #4 from Kai Tietz  ---
I added to mingw-w64's libwinpthread a work-a-round for this sloppy code. 
Nevertheless the issue should be fixed IMO in libgomp, too


[Bug bootstrap/67546] bootstrap broken on x86_64-w64-mingw32, error: '::unsetenv' has not been declared in gcc.c

2015-09-11 Thread ktietz at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67546

--- Comment #3 from Kai Tietz  ---
Thanks Rainer for pointing on this.  Yes, comment wasn't intended for this bug.
 I added comment to proper pr ...

This issue is related to the fact that msvcrt doesn't provide unsetenv (as it
doesn't provide setenv).  Instead all this functionality needs to be expressed
via getenv/putenv instead.


[Bug bootstrap/67546] bootstrap broken on x86_64-w64-mingw32, error: '::unsetenv' has not been declared in gcc.c

2015-09-11 Thread ktietz at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67546

Kai Tietz  changed:

   What|Removed |Added

 Target|x86_64-w64-mingw32  |*-*-mingw32
   Priority|P3  |P1
 CC||dmalcolm at gcc dot gnu.org

--- Comment #4 from Kai Tietz  ---
Hi David,

this issue was introduced by your commit done at 2015-08-25


[Bug bootstrap/67546] bootstrap broken on x86_64-w64-mingw32, error: '::unsetenv' has not been declared in gcc.c

2015-09-11 Thread ktietz at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67546

--- Comment #6 from Kai Tietz  ---
Initially in PR/67363 just the missing strndup due failed libiberty-linking was
noticed.  Later comments are duplicate of this.
So feel free to mark one of these bugs as duplicate, if you prefer.


[Bug libstdc++/66030] [5.1.0] std::codecvt_byname missing from libstdc++ DLL

2015-06-06 Thread ktietz at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66030

--- Comment #10 from Kai Tietz ktietz at gcc dot gnu.org ---
Yeah, thanks for working on that.  With extensions shown by Jouni, the patch is
preapproved.  Jonathan, will you take care?


[Bug c++/59759] internal compiler error: in unify, using std::enable_if on classes

2015-05-26 Thread ktietz at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59759

Kai Tietz ktietz at gcc dot gnu.org changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #13 from Kai Tietz ktietz at gcc dot gnu.org ---
Is patch in comment #11 ok for apply to branch/trunk?


[Bug lto/65559] [5/6 Regression] lto1.exe: internal compiler error: in read_cgraph_and_symbols, at lto/lto.c:2947

2015-05-04 Thread ktietz at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65559

--- Comment #35 from Kai Tietz ktietz at gcc dot gnu.org ---
Author: ktietz
Date: Mon May  4 10:16:23 2015
New Revision: 222759

URL: https://gcc.gnu.org/viewcvs?rev=222759root=gccview=rev
Log:
PR target/65559
* lto-wrapper.c (run_gcc): Open filename
with in binary-mode.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/lto-wrapper.c


[Bug lto/65559] [5/6 Regression] lto1.exe: internal compiler error: in read_cgraph_and_symbols, at lto/lto.c:2947

2015-05-04 Thread ktietz at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65559

--- Comment #36 from Kai Tietz ktietz at gcc dot gnu.org ---
Author: ktietz
Date: Mon May  4 10:23:55 2015
New Revision: 222761

URL: https://gcc.gnu.org/viewcvs?rev=222761root=gccview=rev
Log:
Backmerge from trunk.

PR lto/65559
* lto-wrapper.c (run_gcc): Open filename
in binary-mode.

Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/lto-wrapper.c


[Bug lto/65559] [5/6 Regression] lto1.exe: internal compiler error: in read_cgraph_and_symbols, at lto/lto.c:2947

2015-05-04 Thread ktietz at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65559

Kai Tietz ktietz at gcc dot gnu.org changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

--- Comment #37 from Kai Tietz ktietz at gcc dot gnu.org ---
Fixed on trunk and on 5-branch.


[Bug lto/65995] LTO: ICE in add_symbol_to_partition_1 for debug build

2015-05-04 Thread ktietz at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65995

Kai Tietz ktietz at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2015-05-04
 CC||ktietz at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Kai Tietz ktietz at gcc dot gnu.org ---
It might be that this bug is a duplicate of pr/65559.
Could you please check if with current trunk (or 5-branch) problem still
exists?


[Bug lto/65559] [5/6 Regression] lto1.exe: internal compiler error: in read_cgraph_and_symbols, at lto/lto.c:2947

2015-05-01 Thread ktietz at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65559

--- Comment #31 from Kai Tietz ktietz at gcc dot gnu.org ---
(In reply to Richard Biener from comment #23)
 The patch looks pretty obvious to me - though I wonder if archives still
 work on x86_64-linux after it (or rather I wonder how they worked before...).
 
 I'm not aware of @ doing any magic for filenames - do they?

No, me neither.

 So - please test this with boostrap-lto on x86_64-linux as well.

I did bootstrap for all languages (including lto) for x86_64-unknown-linux-gnu
without any new regressions.

Ok to apply to trunk?  Ok for release-branch 5, too?


[Bug lto/65559] [5/6 Regression] lto1.exe: internal compiler error: in read_cgraph_and_symbols, at lto/lto.c:2947

2015-04-30 Thread ktietz at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65559

--- Comment #22 from Kai Tietz ktietz at gcc dot gnu.org ---
I will be able to test this tomorrow (or this evening) for a linux bootstrap.

Patch tested is:

Index: lto-wrapper.c
===
--- lto-wrapper.c   (Revision 69)
+++ lto-wrapper.c   (Arbeitskopie)
@@ -934,7 +934,7 @@ run_gcc (unsigned argc, char *argv[])
  filename[p - argv[i]] = '\0';
  file_offset = (off_t) loffset;
}
-  fd = open (argv[i], O_RDONLY);
+  fd = open (filename, O_RDONLY | O_BINARY);
   if (fd == -1)
{
  lto_argv[lto_argc++] = argv[i];

Honza, Jakub, when regression-test passes is it ok to apply?
The O_BINARY change is pretty obvious, but the filename vs argv[i] change
should indeed affect other targets using the @n decoration, too.


[Bug lto/65559] [5/6 Regression] lto1.exe: internal compiler error: in read_cgraph_and_symbols, at lto/lto.c:2947

2015-04-29 Thread ktietz at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65559

--- Comment #18 from Kai Tietz ktietz at gcc dot gnu.org ---
Does the following patch fixes your problem?

Index: lto-wrapper.c
===
--- lto-wrapper.c   (Revision 69)
+++ lto-wrapper.c   (Arbeitskopie)
@@ -934,7 +934,7 @@ run_gcc (unsigned argc, char *argv[])
  filename[p - argv[i]] = '\0';
  file_offset = (off_t) loffset;
}
-  fd = open (argv[i], O_RDONLY);
+  fd = open (argv[i], O_RDONLY|O_BINARY);
   if (fd == -1)
{
  lto_argv[lto_argc++] = argv[i];


[Bug c++/57335] internal compiler error: in cxx_eval_bit_field_ref, at cp/semantics.c:6977

2015-04-27 Thread ktietz at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57335

Kai Tietz ktietz at gcc dot gnu.org changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |ktietz at gcc dot 
gnu.org

--- Comment #11 from Kai Tietz ktietz at gcc dot gnu.org ---
Mine.


[Bug c++/49171] [C++0x][constexpr] Constant expressions support reinterpret_cast

2015-04-27 Thread ktietz at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49171

Kai Tietz ktietz at gcc dot gnu.org changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |ktietz at gcc dot 
gnu.org

--- Comment #11 from Kai Tietz ktietz at gcc dot gnu.org ---
Fixed with delayed-folding for C++.  Therefore mine.


[Bug c/61240] [4.8/4.9/5/6 Regression] Incorrect warning integer overflow in expression on pointer-pointer subtraction

2015-04-27 Thread ktietz at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61240

Kai Tietz ktietz at gcc dot gnu.org changed:

   What|Removed |Added

 CC||ktietz at gcc dot gnu.org

--- Comment #11 from Kai Tietz ktietz at gcc dot gnu.org ---
Issue is fixed for C++ delayed folding.


[Bug c/65891] -Wlogical-op now warns about logical ‘and’ of equal expressions even when different types/sizeofs are involved

2015-04-27 Thread ktietz at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65891

Kai Tietz ktietz at gcc dot gnu.org changed:

   What|Removed |Added

 CC||ktietz at gcc dot gnu.org

--- Comment #3 from Kai Tietz ktietz at gcc dot gnu.org ---
For C++ delayed folding this issue won't be warned anymore, as for it sizeof
isn't folded early.


[Bug c++/56868] Constexpr example in 7.1.5/5 fails to compile correctly

2015-04-27 Thread ktietz at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56868

Kai Tietz ktietz at gcc dot gnu.org changed:

   What|Removed |Added

 CC||ktietz at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |ktietz at gcc dot 
gnu.org

--- Comment #7 from Kai Tietz ktietz at gcc dot gnu.org ---
This issue gets fixed with delayed-folding. Therefore assign it to me.


[Bug target/65867] [5/6 Regression] bootstrap fails for mingw32 due to missing header in ssp.c

2015-04-25 Thread ktietz at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65867

Kai Tietz ktietz at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-04-25
 Ever confirmed|0   |1

--- Comment #2 from Kai Tietz ktietz at gcc dot gnu.org ---
Well, that this include is required seems to me like a bug in mingw.org, as
wincrypt.h should be auto-included by windows.h.  Nevertheless this is a
trivial patch, so it is ok.  Please post it to ML, and I will take care to
apply.

Thanks


[Bug lto/65559] [5 Regression] lto1.exe: internal compiler error: in read_cgraph_and_symbols, at lto/lto.c:2947

2015-04-08 Thread ktietz at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65559

--- Comment #15 from Kai Tietz ktietz at gcc dot gnu.org ---
That is my issue too.  I try to reproduce this issue with cross and native.
But I see some issues only in combination with upstream binutils, and here only
in native case, which is the curious part ...
I am still on to find the underlying issue ...


[Bug target/65568] ptrmem8.C:9:9: internal compiler error: in build_ptrmemfunc, at cp/typeck.c:7940

2015-03-26 Thread ktietz at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65568

--- Comment #2 from Kai Tietz ktietz at gcc dot gnu.org ---
Issue is related to -fms-extensions.  This option is for mingw targets on by
default.  By the following patch issue in testsuite gets solved (it makes sense
to apply this patch for such testcases, as here indeed -fno-ms-extensions is
tested).  
The point - as already noticed and spoken with Jason - that some C++-extensions
are buggy in C++-FE.

Index: ptrmem8.C
===
--- ptrmem8.C   (Revision 221690)
+++ ptrmem8.C   (Arbeitskopie)
@@ -1,5 +1,6 @@
 // PR c++/33844
 // { dg-do compile }
+// { dg-additional-options -fno-ms-extensions { target *-*-mingw* } }

 struct A {};


[Bug target/65562] chkp-lifetime-1.c:17:1: internal compiler error: in size_binop_loc, at fold-const.c:1761

2015-03-26 Thread ktietz at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65562

Kai Tietz ktietz at gcc dot gnu.org changed:

   What|Removed |Added

 Status|WAITING |NEW
 CC||ktietz at gcc dot gnu.org

--- Comment #2 from Kai Tietz ktietz at gcc dot gnu.org ---
Backtrace is:

Can be reproduced manually with:

gcc.exe -S -o t.s chkp-lifetime-1.c -O2 -fcheck-pointer-bounds -mmpx

#0  internal_error (
gmsgid=gmsgid@entry=0x155babe void
va_heap::reservefcache::line_info(vec
fcache::line_info, va_heap, vl_embed*, unsigned int, bool)::__FUNCTION__+187
in %s, at %s:%d) at ../../gcc/gcc/diagnostic.c:1217
#1  0x01077daf in fancy_abort (
file=file@entry=0x12b9f2c void va_heap::reserveggc_root_tab
const*(vecgg
c_root_tab const*, va_heap, vl_embed*, unsigned int,
bool)::__FUNCTION__+1854
 ../../gcc/gcc/fold-const.c, line=line@entry=1761,
function=function@entry=0x12bd002 size_binop_loc(unsigned int, tree_code,
t
ree_node*, tree_node*)::__FUNCTION__ size_binop_loc)
at ../../gcc/gcc/diagnostic.c:1291
#2  0x007e554c in size_binop_loc (loc=loc@entry=0,
code=code@entry=MINUS_EXPR, arg0=arg0@entry=0xffe4c300, arg1=0xffef0420)
at ../../gcc/gcc/fold-const.c:1760
#3  0x006765ef in chkp_output_static_bounds (stmts=0xc1baac8,
var=optimized out, bnd_var=0xffe60580) at ../../gcc/gcc/tree-chkp.c:1024
#4  chkp_finish_file () at ../../gcc/gcc/tree-chkp.c:3735
#5  0x0077df4b in compile_file () at ../../gcc/gcc/toplev.c:627
#6  0x01199823 in do_compile () at ../../gcc/gcc/toplev.c:2076
#7  toplev::main (this=this@entry=0xc1bab8e, argc=argc@entry=8,
argv=argv@entry=0xc1babbc) at ../../gcc/gcc/toplev.c:2174
#8  0x012096d2 in main (argc=8, argv=0xc1babbc) at ../../gcc/gcc/main.c:39


[Bug c++/65573] 13908.C:20:33: internal compiler error: in cp_build_addr_expr_1, at cp/typeck.c:5527

2015-03-26 Thread ktietz at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65573

Kai Tietz ktietz at gcc dot gnu.org changed:

   What|Removed |Added

 Status|WAITING |NEW
 CC||ktietz at gcc dot gnu.org

--- Comment #2 from Kai Tietz ktietz at gcc dot gnu.org ---
Confirmed.

#0  internal_error (
gmsgid=gmsgid@entry=0x1763f5e lang_independent_params+3774 in %s, at
%s:%
d) at ../../gcc/gcc/diagnostic.c:1217
#1  0x0125459f in fancy_abort (
file=file@entry=0x141add5 gt_ggc_r_gt_cp_rtti_h+437
../../gcc/gcc/cp/type
ck.c, line=line@entry=5531,
function=function@entry=0x141da23 cp_build_addr_expr_1(tree_node*, bool,
in
t)::__FUNCTION__ cp_build_addr_expr_1) at ../../gcc/gcc/diagnostic.c:1291
#2  0x0057ef13 in cp_build_addr_expr_1 (arg=optimized out,
strict_lvalue=optimized out, complain=3)
at ../../gcc/gcc/cp/typeck.c:5531
#3  0x0057f34c in cp_build_addr_expr_strict (complain=3, arg=0xffc90eb8)
at ../../gcc/gcc/cp/typeck.c:5628
#4  build_x_unary_op (loc=loc@entry=2582, code=code@entry=ADDR_EXPR,
xarg=0xffc90eb8, complain=complain@entry=3)
at ../../gcc/gcc/cp/typeck.c:5265
#5  0x005418b2 in cp_parser_unary_expression (parser=parser@entry=0xffeb04b0,
pidk=optimized out, address_p=address_p@entry=22, cast_p=true,
decltype_p=false) at ../../gcc/gcc/cp/parser.c:7418
#6  0x005420e4 in cp_parser_cast_expression (parser=parser@entry=0xffeb04b0,
address_p=address_p@entry=false, cast_p=cast_p@entry=true,
decltype_p=true, decltype_p@entry=false, pidk=pidk@entry=0x0)
at ../../gcc/gcc/cp/parser.c:8083
#7  0x00542193 in cp_parser_cast_expression (parser=parser@entry=0xffeb04b0,
address_p=address_p@entry=false, cast_p=cast_p@entry=false,
decltype_p=decltype_p@entry=false, pidk=pidk@entry=0x0)
at ../../gcc/gcc/cp/parser.c:8051
#8  0x00542459 in cp_parser_binary_expression (
parser=parser@entry=0xffeb04b0, cast_p=optimized out,
no_toplevel_fold_p=no_toplevel_fold_p@entry=false,
decltype_p=decltype_p@entry=false, prec=prec@entry=PREC_NOT_OPERATOR,
pidk=pidk@entry=0x0) at ../../gcc/gcc/cp/parser.c:8185
#9  0x00542d60 in cp_parser_assignment_expression (
parser=parser@entry=0xffeb04b0, pidk=pidk@entry=0x0,
cast_p=cast_p@entry=false, decltype_p=decltype_p@entry=false)
at ../../gcc/gcc/cp/parser.c:8442
#10 0x005431e6 in cp_parser_constant_expression (parser=0xffeb04b0,
allow_non_constant_p=optimized out, non_constant_p=0xd60a63f)
at ../../gcc/gcc/cp/parser.c:8688
#11 0x00542ef0 in cp_parser_assignment_expression (
parser=parser@entry=0xffeb04b0, pidk=pidk@entry=0x0,
cast_p=cast_p@entry=false, decltype_p=decltype_p@entry=false)
at ../../gcc/gcc/cp/parser.c:8461
#12 0x00545a56 in cp_parser_expression (parser=parser@entry=0xffeb04b0,
pidk=pidk@entry=0x0, cast_p=cast_p@entry=false,
decltype_p=decltype_p@entry=false) at ../../gcc/gcc/cp/parser.c:8596
#13 0x00546267 in cp_parser_expression_statement (
in_statement_expr=in_statement_expr@entry=0x0)
at ../../gcc/gcc/cp/parser.c:10005
#14 0x0055e123 in cp_parser_statement (parser=parser@entry=0xffeb04b0,
in_statement_expr=in_statement_expr@entry=0x0,
in_compound=in_compound@entry=true, if_p=if_p@entry=0x0)
at ../../gcc/gcc/cp/parser.c:9854
#15 0x0055f0c1 in cp_parser_statement_seq_opt (
parser=parser@entry=0xffeb04b0,
in_statement_expr=in_statement_expr@entry=0x0)
at ../../gcc/gcc/cp/parser.c:10128
#16 0x0055f1ff in cp_parser_compound_statement (
parser=parser@entry=0xffeb04b0,
in_statement_expr=in_statement_expr@entry=0x0, in_try=in_try@entry=false,
function_body=function_body@entry=true) at ../../gcc/gcc/cp/parser.c:10082
#17 0x0055f45c in cp_parser_function_body (in_function_try_block=false,
parser=0xffeb04b0) at ../../gcc/gcc/cp/parser.c:19223
#18 cp_parser_ctor_initializer_opt_and_function_body (
parser=parser@entry=0xffeb04b0,
in_function_try_block=in_function_try_block@entry=false)
at ../../gcc/gcc/cp/parser.c:19259
#19 0x00560480 in cp_parser_function_definition_after_declarator (
parser=parser@entry=0xffeb04b0, inline_p=inline_p@entry=false)
at ../../gcc/gcc/cp/parser.c:23501
#20 0x00561224 in cp_parser_function_definition_from_specifiers_and_declarator
...

Another case related to -fms-extensions switch. Testcase assume that option is
off.  so following patch papers over this issue:

Index: 13908.C
===
--- 13908.C (Revision 221690)
+++ 13908.C (Arbeitskopie)
@@ -1,4 +1,5 @@
 // { dg-do assemble  }
+// { dg-additional-options -fno-ms-extensions -pedantic { target *-*-mingw*
} }
 // 981203 bkoz
 // g++/13908


[Bug target/65572] ptrmem5.C:7:26: internal compiler error: in gimplify_expr, at gimplify.c:8629

2015-03-26 Thread ktietz at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65572

Kai Tietz ktietz at gcc dot gnu.org changed:

   What|Removed |Added

 Status|WAITING |NEW
 CC||ktietz at gcc dot gnu.org

--- Comment #2 from Kai Tietz ktietz at gcc dot gnu.org ---
Confirmed.

Backtrace is:

#0  internal_error (
gmsgid=gmsgid@entry=0x1763f5e lang_independent_params+3774 in %s, at
%s:%
d) at ../../gcc/gcc/diagnostic.c:1217
#1  0x0125459f in fancy_abort (
file=file@entry=0x14c6840 tls_model_names+40 ../../gcc/gcc/gimplify.c,
l
ine=line@entry=8629,
function=function@entry=0x14c8288 gimplify_expr(tree_node**,
gimple_stateme
nt_base**, gimple_statement_base**, bool (*)(tree_node*), int)::__FUNCTION__
g
implify_expr) at ../../gcc/gcc/diagnostic.c:1291
#2  0x009fedcc in gimplify_expr (expr_p=expr_p@entry=0xffc90e68,
pre_p=pre_p@entry=0xd60a7e8, post_p=0xd60a6d0, post_p@entry=0x0,
gimple_test_f=gimple_test_f@entry=0x9f0be0 is_gimple_stmt(tree),
fallback=fallback@entry=0) at ../../gcc/gcc/gimplify.c:8629
#3  0x00a0149a in gimplify_stmt (stmt_p=0xffc90e68,
seq_p=seq_p@entry=0xd60a7e8) at ../../gcc/gcc/gimplify.c:5514
#4  0x009fc559 in gimplify_cleanup_point_expr (pre_p=0xd60a89c,
expr_p=0xffe75cf0) at ../../gcc/gcc/gimplify.c:5290
#5  gimplify_expr (expr_p=expr_p@entry=0xffe75cf0,
pre_p=pre_p@entry=0xd60a89c, post_p=0xd60a7c0, post_p@entry=0x0,
gimple_test_f=gimple_test_f@entry=0x9f0be0 is_gimple_stmt(tree),
fallback=fallback@entry=0) at ../../gcc/gcc/gimplify.c:8260
#6  0x00a0149a in gimplify_stmt (stmt_p=stmt_p@entry=0xffe75cf0,
seq_p=seq_p@entry=0xd60a89c) at ../../gcc/gcc/gimplify.c:5514
#7  0x00a030af in gimplify_body (fndecl=fndecl@entry=0xffe75c80,

This is once again an issue related to -fms-extensions switch.  By turning this
option off, ICE disappears.

So suggested patch for the testcase (as again we are assuming here
-fno-ms-extensions):
Index: ptrmem5.C
===
--- ptrmem5.C   (Revision 221690)
+++ ptrmem5.C   (Arbeitskopie)
@@ -1,4 +1,5 @@
 // PR c++/15696
+// { dg-additional-options -fno-ms-extensions { target *-*-mingw* } }


[Bug target/65566] thread-local-var-1-lbv.c:34:1: internal compiler error: Segmentation fault

2015-03-26 Thread ktietz at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65566

Kai Tietz ktietz at gcc dot gnu.org changed:

   What|Removed |Added

 Status|WAITING |NEW
 CC||ktietz at gcc dot gnu.org

--- Comment #2 from Kai Tietz ktietz at gcc dot gnu.org ---
Confirmed.

We see an segfault (caused by cfun being NULL).

Program received signal SIGSEGV, Segmentation fault.
0x00cee933 in lower_emutls_function_body (node=optimized out)
at ../../gcc/gcc/tree-emutls.c:644
644   FOR_EACH_BB_FN (d.bb, cfun)
(gdb) print cfun
$1 = (function *) 0x0

(gdb) bt
#0  0x00cee933 in lower_emutls_function_body (node=optimized out)
at ../../gcc/gcc/tree-emutls.c:644
#1  ipa_lower_emutls () at ../../gcc/gcc/tree-emutls.c:810
#2  (anonymous namespace)::pass_ipa_lower_emutls::execute (this=0x800524b0)
at ../../gcc/gcc/tree-emutls.c:850
#3  0x007354b5 in execute_one_pass (pass=pass@entry=0x800524b0)
at ../../gcc/gcc/passes.c:2330
#4  0x00736010 in execute_ipa_pass_list (pass=0x800524b0)
at ../../gcc/gcc/passes.c:2729
#5  0x0074253d in ipa_passes () at ../../gcc/gcc/cgraphunit.c:2154
#6  symbol_table::compile (this=this@entry=0xfff2)
at ../../gcc/gcc/cgraphunit.c:2295
#7  0x007447af in symbol_table::finalize_compilation_unit (this=0xfff2)
at ../../gcc/gcc/cgraphunit.c:2444
#8  0x0041fbbc in c_write_global_declarations ()
at ../../gcc/gcc/c/c-decl.c:10801
#9  0x0077dd37 in compile_file () at ../../gcc/gcc/toplev.c:608
#10 0x01199823 in do_compile () at ../../gcc/gcc/toplev.c:2076
#11 toplev::main (this=this@entry=0xc1bab8e, argc=argc@entry=7,
argv=argv@entry=0xc1babbc) at ../../gcc/gcc/toplev.c:2174
#12 0x012096d2 in main (argc=7, argv=0xc1babbc) at ../../gcc/gcc/main.c:39


[Bug target/65581] [5 Regression] testsuite lto issue: multiple definition of `main', undefined reference to `WinMain'

2015-03-26 Thread ktietz at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65581

Kai Tietz ktietz at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||ktietz at gcc dot gnu.org
 Resolution|--- |INVALID

--- Comment #4 from Kai Tietz ktietz at gcc dot gnu.org ---
This issue is related to building of crt. so it doesn't have something to do
with gcc's lto in first hand.


[Bug target/65581] [5 Regression] testsuite lto issue: multiple definition of `main', undefined reference to `WinMain'

2015-03-26 Thread ktietz at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65581

Kai Tietz ktietz at gcc dot gnu.org changed:

   What|Removed |Added

 CC||hubicka at ucw dot cz

--- Comment #6 from Kai Tietz ktietz at gcc dot gnu.org ---
As far as I understand this issue does LTO now handle stuff used from object
file different to prior versions. I add Jan.  He might be able to give us some
more points


[Bug libgomp/64972] [5 Regression] Build failure in libgomp for i686-w64-mingw32 target after latest merge from gomp-4_0-branch

2015-03-25 Thread ktietz at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64972

--- Comment #17 from Kai Tietz ktietz at gcc dot gnu.org ---
Author: ktietz
Date: Wed Mar 25 15:05:02 2015
New Revision: 221665

URL: https://gcc.gnu.org/viewcvs?rev=221665root=gccview=rev
Log:
PR libgomp/64972
* oacc-parallel.c (GOACC_parallel): Use PRIu64 if available.
(GOACC_data_start): Likewise.
* target.c (gomp_map_vars): Likewise.


Modified:
trunk/libgomp/ChangeLog
trunk/libgomp/oacc-parallel.c
trunk/libgomp/target.c


[Bug libgomp/64972] [5 Regression] Build failure in libgomp for i686-w64-mingw32 target after latest merge from gomp-4_0-branch

2015-03-25 Thread ktietz at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64972

Kai Tietz ktietz at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #18 from Kai Tietz ktietz at gcc dot gnu.org ---
Fixed on trunk.


[Bug lto/65559] [5 Regression] lto1.exe: internal compiler error: in read_cgraph_and_symbols, at lto/lto.c:2947

2015-03-25 Thread ktietz at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65559

Kai Tietz ktietz at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-03-25
 CC||ktietz at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Kai Tietz ktietz at gcc dot gnu.org ---
Yeah, I noticed such failures too.
AFAI researched them, they are related to out-of-stack issues.

The problem seems to be that within lto a lot of vec-s are passed on stack and
lead for stack-limited targets easily to out-of-stack issues.

Not sure if this is here really the reason, but my gut feeling would say so.

Nevertheless I can confirm this ice


[Bug target/65560] [Regression 5] pr24683.c:11:1: internal compiler error: in extract_insn, at recog.c:2343

2015-03-25 Thread ktietz at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65560

Kai Tietz ktietz at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-03-25
 CC||ktietz at gcc dot gnu.org
Summary|pr24683.c:11:1: internal|[Regression 5]
   |compiler error: in  |pr24683.c:11:1: internal
   |extract_insn, at|compiler error: in
   |recog.c:2343|extract_insn, at
   ||recog.c:2343
 Ever confirmed|0   |1

--- Comment #1 from Kai Tietz ktietz at gcc dot gnu.org ---
confirmed.


[Bug target/65564] [Regression 5] builtin-bnd-narrow-ptr-bounds-2-nov.c:15:1: internal compiler error: in simplify_subreg, at simplify-rtx.c:5745

2015-03-25 Thread ktietz at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65564

Kai Tietz ktietz at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-03-25
 CC||ktietz at gcc dot gnu.org
   Target Milestone|--- |5.0
Summary|builtin-bnd-narrow-ptr-boun |[Regression 5]
   |ds-2-nov.c:15:1: internal   |builtin-bnd-narrow-ptr-boun
   |compiler error: in  |ds-2-nov.c:15:1: internal
   |simplify_subreg, at |compiler error: in
   |simplify-rtx.c:5745 |simplify_subreg, at
   ||simplify-rtx.c:5745
 Ever confirmed|0   |1

--- Comment #1 from Kai Tietz ktietz at gcc dot gnu.org ---
Confirmed.

Backtrace:
#1  0x010771df in fancy_abort (
file=file@entry=0x12d0e80 inchash::add_rtx(rtx_def const*,
inchash::hash):
:__FUNCTION__+8 ../../gcc/gcc/simplify-rtx.c, line=line@entry=5745,
function=function@entry=0x12d170a simplify_subreg(machine_mode, rtx_def*,
m
achine_mode, unsigned int)::__FUNCTION__ simplify_subreg)
at ../../gcc/gcc/diagnostic.c:1291
#2  0x008fa8dd in simplify_subreg (outermode=outermode@entry=BLKmode,
op=op@entry=0xfff5b2c0, innermode=innermode@entry=DImode,
byte=byte@entry=0) at ../../gcc/gcc/simplify-rtx.c:5745
#3  0x008fac8f in simplify_gen_subreg (outermode=BLKmode, op=0xfff5b2c0,
innermode=DImode, byte=byte@entry=0) at ../../gcc/gcc/simplify-rtx.c:5967
#4  0x006ffb7f in ix86_delegitimize_address (x=optimized out)
at ../../gcc/gcc/config/i386/i386.c:14914
#5  0x00ead454 in adjust_mems (loc=0xfff5b7f0, old_rtx=0x0, data=0xc1aa890)
at ../../gcc/gcc/var-tracking.c:1057
#6  0x008fe4fc in simplify_replace_fn_rtx (x=0xfff5b7f0,
old_rtx=old_rtx@entry=0x0,
fn=fn@entry=0xead280 adjust_mems(rtx, const_rtx, void*),
data=data@entry=0xc1aa890) at ../../gcc/gcc/simplify-rtx.c:467
#7  0x008fe038 in simplify_replace_fn_rtx (x=0xfff5b800,

assert happens due on call of simplify_subreg the outermode is a BLKmode.

I think we should check within simplify_get_subreg for outermode == BLKmode and
avoid calling of simplify_subreg for it.


[Bug target/65561] avx512fintrin.h:5344:1: internal compiler error: in curr_insn_transform, at lra-constraints.c:3494

2015-03-25 Thread ktietz at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65561

Kai Tietz ktietz at gcc dot gnu.org changed:

   What|Removed |Added

 CC||ktietz at gcc dot gnu.org

--- Comment #1 from Kai Tietz ktietz at gcc dot gnu.org ---
Hmm, this failure I can't reproduce.  But I have right now some local changes
in tree, so I will retry without them.


[Bug target/65564] [Regression 5] builtin-bnd-narrow-ptr-bounds-2-nov.c:15:1: internal compiler error: in simplify_subreg, at simplify-rtx.c:5745

2015-03-25 Thread ktietz at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65564

--- Comment #2 from Kai Tietz ktietz at gcc dot gnu.org ---
As more I look as more I guess it is related to recent pic-code changes in
i386.c for Darwin.
I will check at what places we now assume that for PIC (especially for UNSPEC
UNSPEC_PCREL) we assume that x64-code only uses path with GOT-table for PIC.


[Bug libgomp/64972] [5 Regression] Build failure in libgomp for i686-w64-mingw32 target after latest merge from gomp-4_0-branch

2015-03-24 Thread ktietz at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64972

--- Comment #10 from Kai Tietz ktietz at gcc dot gnu.org ---
I agree that suggested patch changes here behavior on non LP64 targets. 
Nevertheless it would be something to live by until we reach stage 1 to address
this more accurate.
To us uintptr_t is by idea ok, just have the weakness that size_t not
necessarily has same precision as uintptr_t.  If gomp maintainer will say that
inttypes.h header use and casting to uintptr_t would be ok for them, I agree.

A real solution would be to add in configure a test for used size_t
printf-formatter sign, and then use it in source.  For gnu-style
width-specifier is 'z', for ms-style it is 'I'.


[Bug libgomp/64972] [5 Regression] Build failure in libgomp for i686-w64-mingw32 target after latest merge from gomp-4_0-branch

2015-03-24 Thread ktietz at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64972

--- Comment #13 from Kai Tietz ktietz at gcc dot gnu.org ---
Rainer: does following patch works for you?

Index: oacc-parallel.c
===
--- oacc-parallel.c(Revision 221640)
+++ oacc-parallel.c(Arbeitskopie)
@@ -31,6 +31,9 @@
 #include libgomp_g.h
 #include gomp-constants.h
 #include oacc-int.h
+#ifdef HAVE_INTTYPES_H
+# include inttypes.h  /* For PRIu64.  */
+#endif
 #include string.h
 #include stdarg.h
 #include assert.h
@@ -99,9 +102,14 @@ GOACC_parallel (int device, void (*fn) (void *),
 gomp_fatal (num_workers (%d) different from one is not yet supported,
 num_workers);

+#ifdef HAVE_INTTYPES_H
+  gomp_debug (0, %s: mapnum=%PRIu64, hostaddrs=%p, size=%p, kinds=%p, 
+ async = %d\n,
+  __FUNCTION__, (uint64_t) mapnum, hostaddrs, sizes, kinds, async);
+#else
   gomp_debug (0, %s: mapnum=%zd, hostaddrs=%p, sizes=%p, kinds=%p,
async=%d\n,
   __FUNCTION__, mapnum, hostaddrs, sizes, kinds, async);
-
+#endif
   select_acc_device (device);

   thr = goacc_thread ();
@@ -178,8 +186,13 @@ GOACC_data_start (int device, size_t mapnum,
   bool host_fallback = device == GOMP_DEVICE_HOST_FALLBACK;
   struct target_mem_desc *tgt;

+#ifdef HAVE_INTTYPES_H
+  gomp_debug (0, %s: mapnum=%PRIu64, hostaddrs=%p, size=%p, kinds=%p\n,
+  __FUNCTION__, (uint64_t) mapnum, hostaddrs, sizes, kinds);
+#else
   gomp_debug (0, %s: mapnum=%zd, hostaddrs=%p, sizes=%p, kinds=%p\n,
   __FUNCTION__, mapnum, hostaddrs, sizes, kinds);
+#endif

   select_acc_device (device);

Index: target.c
===
--- target.c(Revision 221640)
+++ target.c(Arbeitskopie)
@@ -33,6 +33,9 @@
 #include limits.h
 #include stdbool.h
 #include stdlib.h
+#ifdef HAVE_INTTYPES_H
+# include inttypes.h  /* For PRIu64.  */
+#endif
 #include string.h
 #include assert.h

@@ -438,9 +441,16 @@ gomp_map_vars (struct gomp_device_descr *devicep,
   /* We already looked up the memory region above and it
  was missing.  */
   size_t size = k-host_end - k-host_start;
+#ifdef HAVE_INTTYPES_H
   gomp_fatal (present clause: !acc_is_present (%p, 
+  PRIu64 (0xPRIx64)),
+  (void *) k-host_start,
+  (uint64_t) size, (uint64_t) size);
+#else
+  gomp_fatal (present clause: !acc_is_present (%p, 
   %zd (0x%zx)), (void *) k-host_start,
   size, size);
+#endif
 }
 break;
   case GOMP_MAP_FORCE_DEVICEPTR:


[Bug libgomp/64972] [5 Regression] Build failure in libgomp for i686-w64-mingw32 target after latest merge from gomp-4_0-branch

2015-03-24 Thread ktietz at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64972

--- Comment #15 from Kai Tietz ktietz at gcc dot gnu.org ---
Ok, I am fine.  So patch should be something like:

Index: oacc-parallel.c
===
--- oacc-parallel.c(Revision 221640)
+++ oacc-parallel.c(Arbeitskopie)
@@ -31,6 +31,9 @@
 #include libgomp_g.h
 #include gomp-constants.h
 #include oacc-int.h
+#ifdef HAVE_INTTYPES_H
+# include inttypes.h  /* For PRIu64.  */
+#endif
 #include string.h
 #include stdarg.h
 #include assert.h
@@ -99,9 +102,15 @@ GOACC_parallel (int device, void (*fn) (void *),
 gomp_fatal (num_workers (%d) different from one is not yet supported,
 num_workers);

-  gomp_debug (0, %s: mapnum=%zd, hostaddrs=%p, sizes=%p, kinds=%p,
async=%d\n,
-  __FUNCTION__, mapnum, hostaddrs, sizes, kinds, async);
-
+#ifdef HAVE_INTTYPES_H
+  gomp_debug (0, %s: mapnum=%PRIu64, hostaddrs=%p, size=%p, kinds=%p, 
+ async = %d\n,
+  __FUNCTION__, (uint64_t) mapnum, hostaddrs, sizes, kinds, async);
+#else
+  gomp_debug (0, %s: mapnum=%lu, hostaddrs=%p, sizes=%p, kinds=%p,
async=%d\n,
+  __FUNCTION__, (unsigned long) mapnum, hostaddrs, sizes, kinds,
+  async);
+#endif
   select_acc_device (device);

   thr = goacc_thread ();
@@ -178,8 +187,13 @@ GOACC_data_start (int device, size_t mapnum,
   bool host_fallback = device == GOMP_DEVICE_HOST_FALLBACK;
   struct target_mem_desc *tgt;

-  gomp_debug (0, %s: mapnum=%zd, hostaddrs=%p, sizes=%p, kinds=%p\n,
-  __FUNCTION__, mapnum, hostaddrs, sizes, kinds);
+#ifdef HAVE_INTTYPES_H
+  gomp_debug (0, %s: mapnum=%PRIu64, hostaddrs=%p, size=%p, kinds=%p\n,
+  __FUNCTION__, (uint64_t) mapnum, hostaddrs, sizes, kinds);
+#else
+  gomp_debug (0, %s: mapnum=%lu, hostaddrs=%p, sizes=%p, kinds=%p\n,
+  __FUNCTION__, (unsigned long) mapnum, hostaddrs, sizes, kinds);
+#endif

   select_acc_device (device);

Index: target.c
===
--- target.c(Revision 221640)
+++ target.c(Arbeitskopie)
@@ -33,6 +33,9 @@
 #include limits.h
 #include stdbool.h
 #include stdlib.h
+#ifdef HAVE_INTTYPES_H
+# include inttypes.h  /* For PRIu64.  */
+#endif
 #include string.h
 #include assert.h

@@ -438,9 +441,16 @@ gomp_map_vars (struct gomp_device_descr *devicep,
   /* We already looked up the memory region above and it
  was missing.  */
   size_t size = k-host_end - k-host_start;
+#ifdef HAVE_INTTYPES_H
   gomp_fatal (present clause: !acc_is_present (%p, 
-  %zd (0x%zx)), (void *) k-host_start,
-  size, size);
+  PRIu64 (0xPRIx64)),
+  (void *) k-host_start,
+  (uint64_t) size, (uint64_t) size);
+#else
+  gomp_fatal (present clause: !acc_is_present (%p, 
+  %lu (0x%lx)), (void *) k-host_start,
+  (unsigned long) size, (unsigned long) size);
+#endif
 }
 break;
   case GOMP_MAP_FORCE_DEVICEPTR:


[Bug libgomp/64972] [5 Regression] Build failure in libgomp for i686-w64-mingw32 target after latest merge from gomp-4_0-branch

2015-03-24 Thread ktietz at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64972

Kai Tietz ktietz at gcc dot gnu.org changed:

   What|Removed |Added

  Known to work||4.9.3
  Known to fail||5.0

--- Comment #3 from Kai Tietz ktietz at gcc dot gnu.org ---
Issue is that libgomp uses gnu-style printf formatters without checking, if
formatter is available on that platform.

Due it operates on size_t, the defines provided by inttypes.h are of not much
help.


[Bug libgomp/64972] [5 Regression] Build failure in libgomp for i686-w64-mingw32 target after latest merge from gomp-4_0-branch

2015-03-24 Thread ktietz at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64972

Kai Tietz ktietz at gcc dot gnu.org changed:

   What|Removed |Added

   Target Milestone|--- |5.0


[Bug target/65523] ICE: in gimple_op, at gimple.h:2270 with -fcheck-pointer-bounds -mmpx

2015-03-23 Thread ktietz at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65523

Kai Tietz ktietz at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-03-23
 CC||ktietz at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Kai Tietz ktietz at gcc dot gnu.org ---
Confirmed


[Bug preprocessor/8270] [4.8/4.9/5 Regression] back-slash white space newline with comments, no warning

2015-03-23 Thread ktietz at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=8270

--- Comment #57 from Kai Tietz ktietz at gcc dot gnu.org ---
(In reply to doug mcilroy from comment #56)
 (In reply to Kai Tietz from comment #55)
 Comment #55 overlooks the Standard's translation phase 1, which replaces an
 implementation-defined end-of-line indicator with a new-line character.
 GCC's convention of including in the end-of-line indicator any white space
 that is preceded by a backslash conforms, though it may be a surprise.

Sure, sorry for omitting that.  Common understanding of multibyte (this term
is indeed misleading here) newline characters are in common the combination of
'\r' and '\n'.  So by interpreting any whitespace + new-line being seen as a
single-character is valid, but has indeed semantic differences.

 The surprise is perversely out of sympathy with the raison d'etre of the
 standard--maximal portability. It is incompatible with the most direct (and
 historically prior) implementations, wherein the end-of-line indicator is
 simply a new-line character.

Agreed, and we should at least consider to provide an option - beside the
necessary warning - to not strip whitespaces from right-handside of lines
containing a backslash at line's end.
Should we use an existing option (like -ansi), or introduce new option for
this?

 A suitable fix is to warn when white space occurs in an end-of-line
 indicator. This will break no code that GCC currently compiles, yet draw
 attention to the nonportable construct.

Well, in general we are warning, but within comments.  For C-style comments
there is indeed not much reason to warn, as there is no semantic difference. 
But for C++-style comments we should, as here indeed a semantic difference can
occure for gnu-style end-of-line treating


[Bug target/62109] __gthr_i486_lock_cmp_xchg missing clobber

2015-03-20 Thread ktietz at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62109

--- Comment #9 from Kai Tietz ktietz at gcc dot gnu.org ---
(In reply to David from comment #8)
 (In reply to Kai Tietz from comment #7)
 The first code block in comment #6 is what is in the code now.  As you can
 see, it already has the #define you are describing.  I don't understand what
 you mean by change it to this, since it is already there.
 
 Are you suggesting we delete the entire #ifdef
 __GTHREAD_I486_INLINE_LOCK_PRIMITIVES block and replace it with the single
 #define? 
Right, this I suggest.

 I would be ok with that.  Using the #error (the second code block
 in comment #6) seemed like a more backward-compatible way to do this, since
 it would tell people what has happened and what to do to fix it rather than
 (silently) assuming we know what they want to do.

If a target doesn't provide the Interlocked-API, build with fail caused by it. 
I don't think we need to error out on such cases.  (We don't try to cover win
3.14 incompatibilities, so why we should start for Windows 9X?)

 But I am ok with either of these two solutions.


[Bug c++/17729] [4.8/4.9/5 Regression] Duplicate __attribute__((deprecated)) warning

2015-03-20 Thread ktietz at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=17729

Kai Tietz ktietz at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||ktietz at gcc dot gnu.org

--- Comment #32 from Kai Tietz ktietz at gcc dot gnu.org ---
We call function warn_deprecated_use twice within finish_id_expression.  Once
indirectly via mark_used, and the second time directly.  So by checking if
TREE_USED (t) is false this double-warning should be omitted.

Testing right now following patch:

Index: semantics.c
===
--- semantics.c (Revision 221533)
+++ semantics.c (Arbeitskopie)
@@ -3649,7 +3668,7 @@ finish_id_expression (tree id_expression,

   /* Handle references (c++/56130).  */
   tree t = REFERENCE_REF_P (decl) ? TREE_OPERAND (decl, 0) : decl;
-  if (TREE_DEPRECATED (t))
+  if (TREE_DEPRECATED (t)  !TREE_USED (t))
 warn_deprecated_use (t, NULL_TREE);

   return decl;


[Bug target/62109] __gthr_i486_lock_cmp_xchg missing clobber

2015-03-19 Thread ktietz at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62109

--- Comment #7 from Kai Tietz ktietz at gcc dot gnu.org ---
I agree that we change it to
#define __GTHR_W32_InterlockedCompareExchange InterlockedCompareExchange

not sure if we actually should error out here at all.  We might want to remove
instead the use of __GTHREAD_I486_INLINE_LOCK_PRIMITIVES completely.


[Bug c++/56636] strange interaction of dynamic_cast and unique_ptr

2015-03-19 Thread ktietz at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56636

Kai Tietz ktietz at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #6 from Kai Tietz ktietz at gcc dot gnu.org ---
So tested it for 4.8 (branch), 4.9 (branch), and 5.0 (trunk).

I can't reproduce this ICE, so I close this bug as fixed worksforme.


[Bug preprocessor/8270] [4.8/4.9/5 Regression] back-slash white space newline with comments, no warning

2015-03-19 Thread ktietz at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=8270

Kai Tietz ktietz at gcc dot gnu.org changed:

   What|Removed |Added

 CC||ktietz at gcc dot gnu.org

--- Comment #55 from Kai Tietz ktietz at gcc dot gnu.org ---
Well, by looking into the standard ISO/IEC 9899:TC3 I found the following
statement:

5.1.12 Translation phase
2. Each instance of a backslash character (\) immediately followed by a
new-line
character is deleted, splicing physical source lines to form logical source
lines.
Only the last backslash on any physical source line shall be eligible for being
part of such a splice. A source file that is not empty shall end in a new-line
character, which shall not be immediately preceded by a backslash character
before any such splicing takes place.

For ISO/IEC 14882:2003 we see at topic 2 Lexical Convention

2 Each instance of a new-line character and an immediately preceding backslash
character is deleted, splicing physical source lines to form logical source
lines. If, as a result, a character sequence that matches the syntax of a
universal-character-name is produced, the behavior is undefined. If a source
file that is not empty does not end in a new-line character, or ends in a
new-line character immediately preceded by a backslash character, the behavior
is undefined.

So the handling of backslash whitespace newline is clearly a gnu-extension and
not part of the standard.

I suggest something like this patch for fixing standard-requirement. 
Additionally we could check here for cpp_option lang being gnu-style for
allowing 'backslash,whitespaces,newling' too.

Index: lex.c
===
--- lex.c   (Revision 221514)
+++ lex.c   (Arbeitskopie)
@@ -896,6 +896,11 @@ _cpp_clean_line (cpp_reader *pfile)
p--;
   if (p - 1 != pbackslash)
goto done;
+  if (p != d)
+   {
+ ++p;
+ goto done;
+   }

   /* Have an escaped newline; process it and proceed to
 the slow path.  */
@@ -917,13 +922,19 @@ _cpp_clean_line (cpp_reader *pfile)
  if (s == buffer-rlimit)
break;

- /* Escaped?  */
+ /* Escaped?
+But make sure it isn't a backslash followed by a
+whitespace.  */
  p = d;
  while (p != buffer-next_line  is_nvspace (p[-1]))
p--;
  if (p == buffer-next_line || p[-1] != '\\')
break;
-
+ if (p != d)
+   {
+ ++p;
+ break;
+   }
  add_line_note (buffer, p - 1, p != d ? ' ': '\\');
  d = p - 2;
  buffer-next_line = p - 1;


[Bug target/62109] __gthr_i486_lock_cmp_xchg missing clobber

2015-03-17 Thread ktietz at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62109

Kai Tietz ktietz at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-03-17
 Ever confirmed|0   |1

--- Comment #5 from Kai Tietz ktietz at gcc dot gnu.org ---
This patch is clear stage 1 material. Patch itself looks ok, but raises a
completely different question.  Modern versions of mingw provides all
Interlocked-functions, so we might want to use this instead.  The argument
about Win95/98 compatibility is actually pretty borged, as we have already in
some of gcc's target-libraries strong requirements of using at least NT 4.0,
and/or even more modern.


[Bug c++/65390] ICE in strip_typedefs, at cp/tree.c:1361

2015-03-16 Thread ktietz at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65390

Kai Tietz ktietz at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code
 CC||ktietz at gcc dot gnu.org

--- Comment #4 from Kai Tietz ktietz at gcc dot gnu.org ---
This sample is undefined behavior.  It will use delete on the allocated memory,
and not delete [] as it would need.
Additionally the type 'int [n]' is no valid type for template argument.


[Bug libgcj/52579] [4.8/4.9/5 regression] i386_w32_fallback_frame_state should care ffi raw-closure stub function

2015-03-12 Thread ktietz at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52579

Kai Tietz ktietz at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2015-03-12
 CC||ktietz at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #7 from Kai Tietz ktietz at gcc dot gnu.org ---
This issue seems to be fixed in 5.0 by Richard's work on libffi.

Could you please check, if issue is fixed for you?


[Bug c++/65323] [4.8/4.9/5 Regression] duplicate -Wzero-as-null-pointer-constant warnings

2015-03-10 Thread ktietz at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65323

Kai Tietz ktietz at gcc dot gnu.org changed:

   What|Removed |Added

 CC||ktietz at gcc dot gnu.org

--- Comment #3 from Kai Tietz ktietz at gcc dot gnu.org ---
Hmm, the issue seems to be that we emit within check_default_argument () two
times the call to maybe_warn_zero_as_null_pointer_constant ().  Once indirectly
via perform_implicit_conversion_flags () call, and then later on directly
within if-condition for returning nullptr_node.
It seems that second call is superflous in terms of warning.  So I suggest the
following patch:

Index: decl.c
===
--- decl.c  (Revision 221277)
+++ decl.c  (Arbeitskopie)
@@ -11231,7 +11233,8 @@ check_default_argument (tree decl, tree arg, tsub
TYPE_PTR_OR_PTRMEM_P (decl_type)
null_ptr_cst_p (arg)
(complain  tf_warning)
-   maybe_warn_zero_as_null_pointer_constant (arg, input_location))
+   c_inhibit_evaluation_warnings == 0
+   !NULLPTR_TYPE_P(TREE_TYPE (arg)))
 return nullptr_node;

   /* [dcl.fct.default]


[Bug preprocessor/65238] [5 Regression] __has_attribute is not handled properly with -traditional-cpp.

2015-03-08 Thread ktietz at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65238

Kai Tietz ktietz at gcc dot gnu.org changed:

   What|Removed |Added

 CC||ktietz at gcc dot gnu.org

--- Comment #6 from Kai Tietz ktietz at gcc dot gnu.org ---
Well, the new ICE (with your patch applied) is a call off free on a
damaged/wrong pointer for macro.
For testing I disabled free for mc-pointer in question, but this leads to new
issues about too big text-buffer containing random values.  So I guess we have
here an inconsistency about traditional whitespace-handling and
none-traditional one.


[Bug middle-end/61207] [4.9 Regression] Win64 gcc 4.9.0: ICE in in expand_expr_addr_expr_1 at -Os compiling some C++ code

2015-03-07 Thread ktietz at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61207

--- Comment #9 from Kai Tietz ktietz at gcc dot gnu.org ---
well, it might be same issue, but on x64 target the testcase of comment #6
works without issues.
As SRA seems to be involved here, the changes on trunk for DOM might be the
solution.


[Bug tree-optimization/65216] [5 Regression] wrong code at -O3 on x86_64-linux-gnu

2015-03-04 Thread ktietz at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65216

Kai Tietz ktietz at gcc dot gnu.org changed:

   What|Removed |Added

 CC||madars+gccbug at gmail dot com

--- Comment #8 from Kai Tietz ktietz at gcc dot gnu.org ---
*** Bug 65307 has been marked as a duplicate of this bug. ***


[Bug tree-optimization/65307] [4.9 Regression] Incorrect optimization breaks basic arithmetic

2015-03-04 Thread ktietz at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65307

Kai Tietz ktietz at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||ktietz at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #4 from Kai Tietz ktietz at gcc dot gnu.org ---
This is a duplicate of PR/65216.  Underlying issue is in reassoc1-pass.  This
issue is fixed for 5.0

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


[Bug tree-optimization/65307] [4.9 Regression] Incorrect optimization breaks basic arithmetic

2015-03-04 Thread ktietz at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65307

--- Comment #7 from Kai Tietz ktietz at gcc dot gnu.org ---
Well, it looked like the same issue by inspection dumps, as folding issue
happens in reassoc-pass.  Of course it might be that forward-prop patch is the
actual issue.

I noticed for -O3 on 4.9.x that valid computation (dse1):

...
g (const unsigned int from_f)
{
  const unsigned int thirty_four;
  unsigned int _3;
  unsigned int _4;
  unsigned int global.0_8;
  unsigned int _9;
  unsigned int _10;

  bb 2:
  global.0_8 = global;
  _9 = global.0_8 * 2;
  _3 = _9 * 2;
  _10 = _9 * 3;
  _4 = _10 * 5;
  thirty_four_5 = _3 + _4;
...

Shows after reassoc1 pass:
...
g (const unsigned int from_f)
{
  const unsigned int thirty_four;
  unsigned int _3;
  unsigned int _4;
  unsigned int global.0_8;
  unsigned int _9;
  unsigned int _10;

  bb 2:
  global.0_8 = global;
  _9 = global.0_8 * 2;
  _4 = 15;
  _3 = _4 + 2;
  _10 = _9 * _3;
  thirty_four_5 = _10;
...

so it seems to be the forward-propagate patch.

Sorry for the noise


[Bug bootstrap/15212] [4.8/4.9/5 Regression] bootstrap fails on interix3

2015-03-03 Thread ktietz at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=15212

Kai Tietz ktietz at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||ktietz at gcc dot gnu.org
 Resolution|--- |WONTFIX

--- Comment #48 from Kai Tietz ktietz at gcc dot gnu.org ---
The Interix target got obsoleted at 4.6 (see
https://gcc.gnu.org/gcc-4.6/changes.html ).
Therefore I close this bug as WONTFIX.  If status for Interix changes in
future, feel free to reopen this bug.


[Bug target/65288] [5 Regression] ICE (in address_matters_p, at symtab.c:1908) on powerpc64le-linux-gnu

2015-03-03 Thread ktietz at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65288

Kai Tietz ktietz at gcc dot gnu.org changed:

   What|Removed |Added

 CC||ktietz at gcc dot gnu.org

--- Comment #2 from Kai Tietz ktietz at gcc dot gnu.org ---
This looks a bit like a duplicate of PR/65287


[Bug c++/65277] [5 Regression] ice in get_untransformed_body with -O2

2015-03-02 Thread ktietz at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65277

Kai Tietz ktietz at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-03-02
 CC||ktietz at gcc dot gnu.org,
   ||maxim at trivialbugs dot com
 Ever confirmed|0   |1

--- Comment #1 from Kai Tietz ktietz at gcc dot gnu.org ---
Issue seems to be happend in expand_all_functions.  In prior versions we called
expand_function, but now we are calling directly expand ().  Expand () itself
makes use of function get_untransformed_body, which checks for in-LTO-mode,
which of course fails.
Anyway the most funny thing here is that this change is not mentioned in any
ChangeLog.  It is caused by r214422


[Bug lto/65130] [5 Regression] ICE with LTO on valid code on x86_64-linux-gnu

2015-03-02 Thread ktietz at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65130

--- Comment #12 from Kai Tietz ktietz at gcc dot gnu.org ---
I confirm that bug is fixed with that patch.  Only for the case that trying to
link with objects created with prior revision will still fail.  Later might be
acceptable.


[Bug ipa/61916] Internal compiler error in symtab_nonoverwritable_alias with -O2

2015-03-02 Thread ktietz at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61916

Kai Tietz ktietz at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||ktietz at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #8 from Kai Tietz ktietz at gcc dot gnu.org ---
Already fixed. A dup of 64212

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


[Bug target/64212] [4.9/5 Regression] ICE [in noninterposable_alias, at symtab.c:1706]

2015-03-02 Thread ktietz at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64212

Kai Tietz ktietz at gcc dot gnu.org changed:

   What|Removed |Added

 CC||timothygu99 at gmail dot com

--- Comment #11 from Kai Tietz ktietz at gcc dot gnu.org ---
*** Bug 61916 has been marked as a duplicate of this bug. ***


[Bug c++/65277] [5 Regression] ice in get_untransformed_body with -O2

2015-03-02 Thread ktietz at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65277

--- Comment #3 from Kai Tietz ktietz at gcc dot gnu.org ---
(In reply to Marek Polacek from comment #2)
 221040(In reply to Kai Tietz from comment #1)
  It is caused by r214422
 
 No, I think this started with r221040.

Yes, it got shown with r221040.  Nevertheless code-change mentioned before
happend in r214256 (svn blame lied).  So I am testing right now:

Index: cgraphunit.c
===
--- cgraphunit.c(Revision 221103)
+++ cgraphunit.c(Arbeitskopie)
@@ -1847,7 +1847,8 @@ cgraph_node::expand (void)
   announce_function (decl);
   process = 0;
   gcc_assert (lowered);
-  get_untransformed_body ();
+  if (in_lto_p)
+get_untransformed_body ();

   /* Generate RTL for the body of DECL.  */


[Bug libgcc/65038] [regression 5] Unable to find ftw.h for libgcov-util.c

2015-02-27 Thread ktietz at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65038

--- Comment #6 from Kai Tietz ktietz at gcc dot gnu.org ---
Author: ktietz
Date: Fri Feb 27 13:19:38 2015
New Revision: 221059

URL: https://gcc.gnu.org/viewcvs?rev=221059root=gccview=rev
Log:
PR target/65038
* config.in: Regenerated.
* configure: Likewise.
* configure.ac (AC_HEADER_STDC): Added explicit.
(AC_CHECK_HEADERS): Check for default headers  plus
for ftw.h header.
* libgcov-util.c (gcov_read_profile_dir): Disable use
of ftw-function, if header is not found.
(ftw_read_file): Likewise.


Modified:
trunk/libgcc/ChangeLog
trunk/libgcc/config.in
trunk/libgcc/configure
trunk/libgcc/configure.ac
trunk/libgcc/libgcov-util.c


[Bug libgcc/65038] [regression 5] Unable to find ftw.h for libgcov-util.c

2015-02-27 Thread ktietz at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65038

Kai Tietz ktietz at gcc dot gnu.org changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

--- Comment #7 from Kai Tietz ktietz at gcc dot gnu.org ---
Now fixed without regression.
Problem was that header-checks were done before gcc-no-execution.


[Bug libgcc/65038] [regression 5] Unable to find ftw.h for libgcov-util.c

2015-02-27 Thread ktietz at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65038

Kai Tietz ktietz at gcc dot gnu.org changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

--- Comment #5 from Kai Tietz ktietz at gcc dot gnu.org ---
I had to revert patch as on boostrap libgcc now tries to test ability to
compile, which is of course not possible.
Other miracle is that configure.ac and actual present configure seem to be
divergent ...


[Bug c/35330] [4.8/4.9/5 regression] ICE with invalid pragma weak

2015-02-27 Thread ktietz at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35330

Kai Tietz ktietz at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #14 from Kai Tietz ktietz at gcc dot gnu.org ---
I don't intend to backport this change.  therefore I close as fixed.


[Bug target/57982] GetModuleHandle in __register_frame_info causes abort on unload

2015-02-27 Thread ktietz at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57982

--- Comment #3 from Kai Tietz ktietz at gcc dot gnu.org ---
The problem here is the use of weak on pe-coff.  The change you see on gcc is
just addressing the fact that for 64-bit the weak symbol never can get 0 due
relocation-limitations.
We try to address this.
On the other hand we have here to work-a-round a binutils quirk that
default-implementation of a weak is used in its definition TU always, even if a
none-weak symbol is present in a different TU.  This can be worked-a-round by
moving default-implementation into different TU.

Hope this answered some of your questions.

(anyway IMHO, in general we should have used here a variant without any
weak-symbol)


[Bug c/35330] [4.8/4.9/5 regression] ICE with invalid pragma weak

2015-02-27 Thread ktietz at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35330

--- Comment #13 from Kai Tietz ktietz at gcc dot gnu.org ---
Author: ktietz
Date: Fri Feb 27 10:44:43 2015
New Revision: 221053

URL: https://gcc.gnu.org/viewcvs?rev=221053root=gccview=rev
Log:
2015-02-27  Kai Tietz  kti...@redhat.com

PR c/35330
* c-pragma.c (handle_pragma_weak): Do not try to create
weak/alias of declarations not being function, or variable
declarations.

2015-02-27  Kai Tietz  kti...@redhat.com

PR c/35330
* gcc.dg/weak/weak-17.c: New file.


Added:
trunk/gcc/testsuite/gcc.dg/weak/weak-17.c
Modified:
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-pragma.c
trunk/gcc/testsuite/ChangeLog


[Bug libgcc/65038] [regression 5] Unable to find ftw.h for libgcov-util.c

2015-02-27 Thread ktietz at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65038

--- Comment #3 from Kai Tietz ktietz at gcc dot gnu.org ---
Author: ktietz
Date: Fri Feb 27 12:05:02 2015
New Revision: 221055

URL: https://gcc.gnu.org/viewcvs?rev=221055root=gccview=rev
Log:
PR target/65038
* config.in: Regenerated.
* configure: Likewise.
* configure.ac (AC_HEADER_STDC): Add explicit.
(AC_CHECK_HEADERS): Check for default headers
plus for ftw.h one.
* libgcov-util.c (gcov_read_profile_dir): Disable use
of ftw-function, if header not found.
(ftw_read_file): Don't translate if ftw header isn't
present.


Modified:
trunk/libgcc/ChangeLog
trunk/libgcc/config.in
trunk/libgcc/configure
trunk/libgcc/configure.ac
trunk/libgcc/libgcov-util.c


[Bug libgcc/65038] [regression 5] Unable to find ftw.h for libgcov-util.c

2015-02-27 Thread ktietz at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65038

Kai Tietz ktietz at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from Kai Tietz ktietz at gcc dot gnu.org ---
Bootstrap fixed


  1   2   3   4   5   6   7   8   9   >