https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65782
--- Comment #8 from Kai Tietz ---
Hmm, that behavior of gcc seems to be indeed pretty bad. The SEH commands for
registers above index 15 (0..15) for xmm? are indeed undefined, and even worse,
can't be coded proper into the seh table correctly.
An
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 c
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
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 =
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52792
Kai Tietz changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84527
Kai Tietz changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
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
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 w
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, %
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70869
Kai Tietz changed:
What|Removed |Added
Attachment #38472|0 |1
is obsolete|
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70869
Kai Tietz changed:
What|Removed |Added
Attachment #38469|0 |1
is obsolete|
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 gener
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&action=edit
updated patch
Well, DECL_P check is indeed superfluous, but I added to point out we are
checking here for declarati
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70869
Kai Tietz changed:
What|Removed |Added
CC||john.ettedgui at gmail dot com
--- Comment #
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
||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 ***
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.
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
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
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&root=gcc&view=rev
Log:
PR target/51726
* g++.dg/ext/selectany2.C: Allow uninitializ
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&root=gcc&view=rev
Log:
PR target/51726
* config/i386/winnt.c (ix86_handle_selectany_
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 Ka
||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 ***
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&action=edit
Suggested patch
I will do some further testing with that patch, and later on send patch
upstream with a testcase fo
||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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54412
Kai Tietz changed:
What|Removed |Added
Status|UNCONFIRMED |SUSPENDED
Last reconfirmed|
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-conv
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.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67546
Kai Tietz changed:
What|Removed |Added
Target|x86_64-w64-mingw32 |*-*-mingw32
Priority|P3
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 set
||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 fixe
||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 shou
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66030
--- Comment #10 from Kai Tietz ---
Yeah, thanks for working on that. With extensions shown by Jouni, the patch is
preapproved. Jonathan, will you take care?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59759
Kai Tietz changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #13 fro
||2015-05-04
CC||ktietz at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Kai Tietz ---
It might be that this bug is a duplicate of pr/65559.
Could you please check if with current trunk (or 5-branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65559
Kai Tietz changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65559
--- Comment #36 from Kai Tietz ---
Author: ktietz
Date: Mon May 4 10:23:55 2015
New Revision: 222761
URL: https://gcc.gnu.org/viewcvs?rev=222761&root=gcc&view=rev
Log:
Backmerge from trunk.
PR lto/65559
* lto-wrapper.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65559
--- Comment #35 from Kai Tietz ---
Author: ktietz
Date: Mon May 4 10:16:23 2015
New Revision: 222759
URL: https://gcc.gnu.org/viewcvs?rev=222759&root=gcc&view=rev
Log:
PR target/65559
* lto-wrapper.c (run_gcc): Open filename
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65559
--- Comment #31 from Kai Tietz ---
(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 n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65559
--- Comment #22 from Kai Tietz ---
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 (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65559
--- Comment #18 from Kai Tietz ---
Does the following patch fixes your problem?
Index: lto-wrapper.c
===
--- lto-wrapper.c (Revision 69)
+++ lto-wrapper.c (Arbeitsko
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61240
Kai Tietz changed:
What|Removed |Added
CC||ktietz at gcc dot gnu.org
--- Comment #11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49171
Kai Tietz changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |ktietz at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57335
Kai Tietz changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |ktietz at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56868
Kai Tietz changed:
What|Removed |Added
CC||ktietz at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65891
Kai Tietz changed:
What|Removed |Added
CC||ktietz at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65867
Kai Tietz changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65559
--- Comment #15 from Kai Tietz ---
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 stil
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65581
Kai Tietz changed:
What|Removed |Added
CC||hubicka at ucw dot cz
--- Comment #6 from Ka
||ktietz at gcc dot gnu.org
Resolution|--- |INVALID
--- Comment #4 from Kai Tietz ---
This issue is related to building of crt. so it doesn't have something to do
with gcc's lto in first hand.
||ktietz at gcc dot gnu.org
--- Comment #2 from Kai Tietz ---
Confirmed.
#0 internal_error (
gmsgid=gmsgid@entry=0x1763f5e "in %s, at
%s:%
d") at ../../gcc/gcc/diagnostic.c:1217
#1 0x0125459f in fancy_abort (
file=file@entry=0x141add5
"../../gcc/gcc/cp/type
c
||ktietz at gcc dot gnu.org
--- Comment #2 from Kai Tietz ---
Confirmed.
Backtrace is:
#0 internal_error (
gmsgid=gmsgid@entry=0x1763f5e "in %s, at
%s:%
d") at ../../gcc/gcc/diagnostic.c:1217
#1 0x0125459f in fancy_abort (
file=file@entry=0x14c6840 "../../gcc
||ktietz at gcc dot gnu.org
--- Comment #2 from Kai Tietz ---
Confirmed.
We see an segfault (caused by cfun being NULL).
Program received signal SIGSEGV, Segmentation fault.
0x00cee933 in lower_emutls_function_body (node=)
at ../../gcc/gcc/tree-emutls.c:644
644 FOR_EACH_BB_FN
||ktietz at gcc dot gnu.org
--- Comment #2 from Kai Tietz ---
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 (vec<
fcache::line_info, va_heap, vl_embed>*&
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65568
--- Comment #2 from Kai Tietz ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65564
--- Comment #2 from Kai Tietz ---
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 on
||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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65561
Kai Tietz changed:
What|Removed |Added
CC||ktietz at gcc dot gnu.org
--- Comment #1
||2015-03-25
CC||ktietz at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Kai Tietz ---
Yeah, I noticed such failures too.
AFAI researched them, they are related to out-of-stack issues.
The problem seems
||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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64972
Kai Tietz changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64972
--- Comment #17 from Kai Tietz ---
Author: ktietz
Date: Wed Mar 25 15:05:02 2015
New Revision: 221665
URL: https://gcc.gnu.org/viewcvs?rev=221665&root=gcc&view=rev
Log:
PR libgomp/64972
* oacc-parallel.c (GOACC_parallel): Use PRIu64 if a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64972
--- Comment #15 from Kai Tietz ---
Ok, I am fine. So patch should be something like:
Index: oacc-parallel.c
===
--- oacc-parallel.c(Revision 221640)
+++ oacc-parallel.c(Arb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64972
--- Comment #13 from Kai Tietz ---
Rainer: does following patch works for you?
Index: oacc-parallel.c
===
--- oacc-parallel.c(Revision 221640)
+++ oacc-parallel.c(Arbeitskop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64972
--- Comment #10 from Kai Tietz ---
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 ha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64972
Kai Tietz changed:
What|Removed |Added
Target Milestone|--- |5.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64972
Kai Tietz changed:
What|Removed |Added
Known to work||4.9.3
Known to fail|
||2015-03-23
CC||ktietz at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Kai Tietz ---
Confirmed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=8270
--- Comment #57 from Kai Tietz ---
(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
||ktietz at gcc dot gnu.org
--- Comment #32 from Kai Tietz ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62109
--- Comment #9 from Kai Tietz ---
(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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=8270
Kai Tietz changed:
What|Removed |Added
CC||ktietz at gcc dot gnu.org
--- Comment #55
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56636
Kai Tietz changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62109
--- Comment #7 from Kai Tietz ---
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_I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62109
Kai Tietz changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
||ktietz at gcc dot gnu.org
--- Comment #4 from Kai Tietz ---
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.
||2015-03-12
CC||ktietz at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #7 from Kai Tietz ---
This issue seems to be fixed in 5.0 by Richard's work on libffi.
Could you please check, if issue is fixe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65323
Kai Tietz changed:
What|Removed |Added
CC||ktietz at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65238
Kai Tietz changed:
What|Removed |Added
CC||ktietz at gcc dot gnu.org
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61207
--- Comment #9 from Kai Tietz ---
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.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65307
--- Comment #7 from Kai Tietz ---
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 comput
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65216
Kai Tietz changed:
What|Removed |Added
CC||madars+gccbug at gmail dot com
--- Comment #
||ktietz at gcc dot gnu.org
Resolution|--- |DUPLICATE
--- Comment #4 from Kai Tietz ---
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 ***
||ktietz at gcc dot gnu.org
Resolution|--- |WONTFIX
--- Comment #48 from Kai Tietz ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65288
Kai Tietz changed:
What|Removed |Added
CC||ktietz at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65277
--- Comment #3 from Kai Tietz ---
(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 c
||2015-03-02
CC||ktietz at gcc dot gnu.org,
||maxim at trivialbugs dot com
Ever confirmed|0 |1
--- Comment #1 from Kai Tietz ---
Issue seems to be happend in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65130
--- Comment #12 from Kai Tietz ---
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.
||ktietz at gcc dot gnu.org
Resolution|--- |DUPLICATE
--- Comment #8 from Kai Tietz ---
Already fixed. A dup of 64212
*** This bug has been marked as a duplicate of bug 64212 ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64212
Kai Tietz changed:
What|Removed |Added
CC||timothygu99 at gmail dot com
--- Comment #11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65038
Kai Tietz changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65038
--- Comment #6 from Kai Tietz ---
Author: ktietz
Date: Fri Feb 27 13:19:38 2015
New Revision: 221059
URL: https://gcc.gnu.org/viewcvs?rev=221059&root=gcc&view=rev
Log:
PR target/65038
* config.in: Regenerated.
* configure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65038
Kai Tietz changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65038
Kai Tietz changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65038
--- Comment #3 from Kai Tietz ---
Author: ktietz
Date: Fri Feb 27 12:05:02 2015
New Revision: 221055
URL: https://gcc.gnu.org/viewcvs?rev=221055&root=gcc&view=rev
Log:
PR target/65038
* config.in: Regenerated.
* configure: Likewise.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35330
Kai Tietz changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35330
--- Comment #13 from Kai Tietz ---
Author: ktietz
Date: Fri Feb 27 10:44:43 2015
New Revision: 221053
URL: https://gcc.gnu.org/viewcvs?rev=221053&root=gcc&view=rev
Log:
2015-02-27 Kai Tietz
PR c/35330
* c-pragma.c (handle_pragma_weak
1 - 100 of 846 matches
Mail list logo
