For small micros such as MSP430 friends and many of the Renasis
MCUs,
some of which only have 2K or ram on board, this could be a real
issue.
Although I reproduced the same behaviour on i386 using a stock
compiler,
I was wondering if there was something missing in my port that
prevents
I've got a small test case there the ira pass produces this ...
(insn 35 38 36 5 (set (reg/v:SI 29 [orig:17 _b ] [17])
(reg/v:SI 17 [ _b ])) 48 {*ldsi}
(expr_list:REG_DEAD (reg/v:SI 17 [ _b ])
(nil)))
and the LRA processes it as follows ...
Spilling non-eliminable
On 4/16/2014 03:22, Ian Lance Taylor wrote:
On Tue, Apr 15, 2014 at 4:45 AM, Douglas B Rupp r...@adacore.com wrote:
On 04/14/2014 02:01 PM, Ian Lance Taylor wrote:
No I considered that but I think that number will be very small. Will you
concede, in hindsight, that it would be better had the
Ran into a fragile test case:
FAIL: g+.dg/cpp0x/nsdmi-union5.C -std=c+11 scan-assembler 7
$ cat nsdmi-union5.C
// PR c++/58701
// { dg-require-effective-target c++11 }
// { dg-final { scan-assembler 7 } }
static union
{
union
{
int i = 7;
};
};
Two issues make it very fragile. It only
On Apr 16, 2014, at 12:42 AM, Joey Ye joey...@arm.com wrote:
Ran into a fragile test case:
FAIL: g+.dg/cpp0x/nsdmi-union5.C -std=c+11 scan-assembler 7
$ cat nsdmi-union5.C
// PR c++/58701
// { dg-require-effective-target c++11 }
// { dg-final { scan-assembler 7 } }
static union
{
On Wed, Apr 16, 2014 at 10:24 AM, pins...@gmail.com wrote:
On Apr 16, 2014, at 12:42 AM, Joey Ye joey...@arm.com wrote:
Ran into a fragile test case:
FAIL: g+.dg/cpp0x/nsdmi-union5.C -std=c+11 scan-assembler 7
$ cat nsdmi-union5.C
// PR c++/58701
// { dg-require-effective-target c++11 }
Forwarding this to the gcc list, since it seems to be more releavant
to the topic of this list. Sorry for the confusion.
Regards,
Akos Vandra
-- Forwarded message --
From: Akos Vandra axo...@gmail.com
Date: 16 April 2014 12:48
Subject: Using GCC to convert markup to C++
To:
I have made a curious performance observation with gcc under 64 bit
cygwin on a corei7. I'm genuinely puzzled and couldn't find any
information about it. Perhaps this is only indirectly a gcc question
though, bear with me.
I have two trivial programs which assign a loop variable to a local
Hi,
You cannot learn useful timing information from a single run of a short
test like this - there are far too many other factors that come into play.
You cannot learn useful timing information from unoptimised code.
There is too much luck involved in a test like this to be useful. You
need
Hello,
I completely agree with David.
Note that your results will greatly vary depending on the machine you
run the tests on. Performance on such tests it is very
machine-dependant, so the conclusion cannot be generalized.
David
2014-04-16 16:49 GMT+02:00 David Brown da...@westcontrol.com:
Hi David,
Sorry, I had included more information in an earlier draft which I
edited out for brevity.
You cannot learn useful timing
information from a single run of a short
test like this - there are far too many
other factors that come into play.
I didn't mention that I have run it
On 04/16/2014 12:01 AM, John Marino wrote:
On 4/16/2014 03:22, Ian Lance Taylor wrote:
On Tue, Apr 15, 2014 at 4:45 AM, Douglas B Rupp r...@adacore.com wrote:
On 04/14/2014 02:01 PM, Ian Lance Taylor wrote:
No I considered that but I think that number will be very small. Will you
concede, in
In order to see what difference a different processor makes I also tried
the same code on a fairly old 32 bit AMD Athlon(tm) XP 3000+ with the
current stable gcc (4.7.2). The difference is even more striking
(dereferencing is much faster). I see that the size of the code inside
the loop for
On April 16, 2014 7:45:55 PM CEST, Peter Schneider schneid...@gmx.net wrote:
In order to see what difference a different processor makes I also
tried
the same code on a fairly old 32 bit AMD Athlon(tm) XP 3000+ with the
current stable gcc (4.7.2). The difference is even more striking
Because GCC would then be already incompatible with the Intel compiler from
which this interface was drawn, way back when the ia64 support was added to
GCC and we redesigned GCC's exception handling.
The irony being that WindRiver is now owned by Intel...
Doug, what does this unwind.h from
On 04/16/2014 12:38 PM, Eric Botcazou wrote:
Because GCC would then be already incompatible with the Intel compiler from
which this interface was drawn, way back when the ia64 support was added to
GCC and we redesigned GCC's exception handling.
The irony being that WindRiver is now owned by
On Wed, Apr 16, 2014 at 12:01 AM, John Marino gnu...@marino.st wrote:
On 4/16/2014 03:22, Ian Lance Taylor wrote:
On Tue, Apr 15, 2014 at 4:45 AM, Douglas B Rupp r...@adacore.com wrote:
On 04/14/2014 02:01 PM, Ian Lance Taylor wrote:
No I considered that but I think that number will be very
On 04/16/2014 12:48 PM, Douglas B Rupp wrote:
On 04/16/2014 12:38 PM, Eric Botcazou wrote:
Because GCC would then be already incompatible with the Intel compiler from
which this interface was drawn, way back when the ia64 support was added to
GCC and we redesigned GCC's exception handling.
On 04/16/2014 12:55 PM, Richard Henderson wrote:
Is it a (reasonably) close match, interface-wise? Ought we be using
--with-system-libunwind for VxWorks7, like we do for hpux?
It looks reasonable at first glance, but there's a disturbing comment in
the code something to the effect:
until
On 04/16/14 00:30, pshor...@dataworx.com.au wrote:
I had left the movsi patterns unimplemented because I was told that if I
did this then gcc would create expands/splits to use 16 bit moves. So, I
removed my movsi patterns and all seemed well.
Correct. GCC can synthesize movsi from movhi.
Solved... kind of.
*ldsi is one of the patterns movsi is expanded to and as the name
suggests it only handles register loads. I know that at some
stages memory references will pass the register_operand predicate
so I changed the predicate for operand 0 and added an alternative
to *ldsi that
On 04/16/2014 03:05 PM, Paul Shortis wrote:
Solved... kind of.
*ldsi is one of the patterns movsi is expanded to and as the name suggests it
only handles register loads. I know that at some stages memory references will
pass the register_operand predicate so I changed the predicate for
Snapshot gcc-4.9-20140416 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.9-20140416/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.9 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
It looks reasonable at first glance, but there's a disturbing comment in
the code something to the effect:
until we have a GCC compatible unwinding library, hide the API
Indeed, it looks like it was written from scratch for the Diab compiler and
is not fully compatible, but it is meant to
On Wed, Apr 16, 2014 at 3:53 PM, Eric Botcazou ebotca...@adacore.com wrote:
It looks reasonable at first glance, but there's a disturbing comment in
the code something to the effect:
until we have a GCC compatible unwinding library, hide the API
Indeed, it looks like it was written from
On 04/16/2014 05:56 PM, Ian Lance Taylor wrote:
I'm still not clear on what the real problem is.
It seems to me that when using GCC, if you #include unwind.h, you
will get the GCC version, since it will come from the installed
GCC include directory, which is searched ahead of /usr/include.
On 04/16/14 16:19, Richard Henderson wrote:
The register allocators only select an alternative for a move. They do not
choose between N different patterns, separately describing loads, stores, and
register-to-register movement.
I'm fairly sure the documentation is quite clear on this, and GCC
While debugging some gdb-related FAILs, I discovered that gcc's
-fstack-check option effectively calls alloca() to adjust the stack
pointer.
However, it doesn't mark the stack adjustment as FRAME_RELATED even
when it's setting up the local variables for the function.
In the case of rx-elf, for
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60830
Denis Excoffier g...@denis-excoffier.org changed:
What|Removed |Added
CC||mikpelinux at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60855
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Keywords|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60858
Bug ID: 60858
Summary: 64-bit multi-character constants
Product: gcc
Version: 4.10.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60856
rsandifo at gcc dot gnu.org rsandifo at gcc dot gnu.org changed:
What|Removed |Added
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60854
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60858
--- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org ---
Doing A('a', 'b', 'c', 'd', 'e', 'f', 'g', 'h'); is not that bloated and works
independent of the endian.
Also patches go to gcc-patches@ and should include a testcase or two.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60852
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|WAITING |NEW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60849
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60841
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54107
Bernd Edlinger bernd.edlinger at hotmail dot de changed:
What|Removed |Added
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60656
Bernd Edlinger bernd.edlinger at hotmail dot de changed:
What|Removed |Added
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60656
--- Comment #12 from Jakub Jelinek jakub at gcc dot gnu.org ---
Should be fixed already with r209363.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60851
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60817
--- Comment #5 from Rainer Orth ro at gcc dot gnu.org ---
Author: ro
Date: Wed Apr 16 09:09:42 2014
New Revision: 209440
URL: http://gcc.gnu.org/viewcvs?rev=209440root=gccview=rev
Log:
Correctly detect native TLS support with 64-bit gas on
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60850
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||jakub at gcc dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60817
Rainer Orth ro at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60839
Sebastian Huber sebastian.hu...@embedded-brains.de changed:
What|Removed |Added
Status|UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60844
--- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org ---
Author: jakub
Date: Wed Apr 16 09:25:52 2014
New Revision: 209442
URL: http://gcc.gnu.org/viewcvs?rev=209442root=gccview=rev
Log:
PR tree-optimization/60844
*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60852
--- Comment #5 from Jonathan Wakely redi at gcc dot gnu.org ---
Further reduced:
struct D
{
template class T D (T);
};
int operator~(const D );
template typename T T make ();
template typename Rhs struct H
{
static const int value = sizeof
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60852
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||jakub at gcc dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60844
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Known to work||4.10.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60852
--- Comment #7 from Jonathan Wakely redi at gcc dot gnu.org ---
Both clang and G++ reject:
static const int value = sizeof ~makeE();
Whereas clang accepts (and G++ rejects) the same expression using a dependent
type:
template typename Rhs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60852
Paolo Carlini paolo.carlini at oracle dot com changed:
What|Removed |Added
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60850
Manuel López-Ibáñez manu at gcc dot gnu.org changed:
What|Removed |Added
Keywords||patch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60852
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||aoliva at gcc dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60256
Marek Polacek mpolacek at gcc dot gnu.org changed:
What|Removed |Added
CC||mpolacek at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60852
Paolo Carlini paolo.carlini at oracle dot com changed:
What|Removed |Added
Status|NEW |ASSIGNED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60256
Manuel López-Ibáñez manu at gcc dot gnu.org changed:
What|Removed |Added
CC||manu at gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60859
Bug ID: 60859
Summary: Value-initialization of scalar in aggregate yields
braces around scalar initializer
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60852
--- Comment #11 from Jonathan Wakely redi at gcc dot gnu.org ---
I don't know if it's valid, but the discrepancy noted in comment 7 is probably
relevant, one way or another
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60830
Kai Tietz ktietz at gcc dot gnu.org changed:
What|Removed |Added
Status|WAITING |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60852
--- Comment #12 from Markus Trippelsdorf trippels at gcc dot gnu.org ---
The guys on stackoverflow think it's invalid:
http://stackoverflow.com/questions/23108590/is-this-valid-c11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60851
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||vmakarov at gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60841
--- Comment #13 from Richard Biener rguenth at gcc dot gnu.org ---
Created attachment 32615
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32615action=edit
patch
Patch limiting the SLP tree size (to the number of stmts in the loop/bb, not
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60852
Nicolas Silvagni galopin at gmail dot com changed:
What|Removed |Added
CC||galopin at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60849
--- Comment #4 from Richard Biener rguenth at gcc dot gnu.org ---
Created attachment 32616
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32616action=edit
patch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60860
Bug ID: 60860
Summary: Friend function declaration incorrectly hides function
in outer namespace
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60836
--- Comment #3 from Richard Biener rguenth at gcc dot gnu.org ---
Created attachment 32617
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32617action=edit
patch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60860
--- Comment #1 from David Rodriguez Ibeas dibeas at ieee dot org ---
Created this as a new bug as I cannot say for sure whether this is the same
issue as 53012, but they maybe related.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53012
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60852
Markus Trippelsdorf trippels at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60851
--- Comment #3 from Richard Henderson rth at gcc dot gnu.org ---
Oh poo. This is essentially the same as PR60704.
There I chose to fix it in the backend, in a very hacky sort of way,
because I thought these insns were passing constrain_operands
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60810
--- Comment #13 from Orion Poplawski orion at cora dot nwra.com ---
Jakub - Could we get this into Fedora Rawhide? Need it to fix a broken dep in
plplot. Thanks.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60861
Bug ID: 60861
Summary: out of bounds access of global var in .rodata/.bss
not detected
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58114
Teodor Petrov fuscated at gmail dot com changed:
What|Removed |Added
CC||fuscated at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60862
Bug ID: 60862
Summary: bad location in invalid conversion error
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60825
--- Comment #2 from Yufeng Zhang yufeng at gcc dot gnu.org ---
Apart from the parameter passing and C++ name mangling issues, there is also an
issue w.r.t. the implicit conversion between the scalar types and their
vector-type peers. For
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47642
--- Comment #25 from Anton Shterenlikht mexas at bristol dot ac.uk ---
yes, seems to work ok on amd64 FreeBSD gcc47, 48, 49
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60050
Steve Ellcey sje at gcc dot gnu.org changed:
What|Removed |Added
CC||sje at gcc dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60050
--- Comment #3 from Kai Tietz ktietz at gcc dot gnu.org ---
we took care that gcc's abort-redefinition doesn't break the platform-internal
use.
For further information take a look to mingw-w64's headers. This is the wrong
place to discuss that.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60864
Bug ID: 60864
Summary: Compilation Library GNATColl: gnatcoll-scripts.adb
under Debian armhf
Product: gcc
Version: 4.6.3
Status: UNCONFIRMED
Severity: blocker
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58114
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Keywords||diagnostic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43452
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
CC||tilman.vogel at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58114
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59295
--- Comment #3 from ppluzhnikov at gcc dot gnu.org ---
Author: ppluzhnikov
Date: Wed Apr 16 17:39:45 2014
New Revision: 209444
URL: http://gcc.gnu.org/viewcvs?rev=209444root=gccview=rev
Log:
2014-04-16 Paul Pluzhnikov ppluzhni...@google.com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59295
Paul Pluzhnikov ppluzhnikov at google dot com changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60256
--- Comment #5 from Marek Polacek mpolacek at gcc dot gnu.org ---
We call c_fully_fold on strcpy (s, s);, and because this CALL_EXPR is
tcc_vl_exp, we call fold () on it. fold () then via fold_call_expr - ...
calls fold_builtin_strcpy and that
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60823
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60861
--- Comment #1 from Kostya Serebryany kcc at gcc dot gnu.org ---
Will adding -fno-common help?
Or building the test as C++?
See https://code.google.com/p/address-sanitizer/wiki/Flags
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60865
Bug ID: 60865
Summary: ICE: verify_cgraph_node failed: comdat-local function
called by built-in outside its comdat
Product: gcc
Version: 4.10.0
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60866
Bug ID: 60866
Summary: [4.7/4.8/4.9/4.10 Regression] ICE: in
get_seqno_for_a_jump, at sel-sched-ir.c:4068 with
-fselective-scheduling -fno-if-conversion
Product: gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60256
--- Comment #6 from Manuel López-Ibáñez manu at gcc dot gnu.org ---
(In reply to Marek Polacek from comment #5)
We call c_fully_fold on strcpy (s, s);, and because this CALL_EXPR is
tcc_vl_exp, we call fold () on it. fold () then via
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60867
Bug ID: 60867
Summary: std::atomicstd::unique_ptrT should fail to compile
since unique_ptr is not trivial to copy
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44054
--- Comment #5 from Manuel López-Ibáñez manu at gcc dot gnu.org ---
Created attachment 32622
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32622action=edit
proof of concept
The attached patch is a proof of concept. It gives the following
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60852
--- Comment #15 from Marc Glisse glisse at gcc dot gnu.org ---
Did someone file a corresponding PR for clang? It is useful for them, but also
for gcc because it gives them a chance to give a different interpretation of
the standard.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60862
Manuel López-Ibáñez manu at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60852
--- Comment #16 from Markus Trippelsdorf trippels at gcc dot gnu.org ---
(In reply to Marc Glisse from comment #15)
Did someone file a corresponding PR for clang? It is useful for them, but
also for gcc because it gives them a chance to give a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60764
--- Comment #2 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org ---
Author: paolo
Date: Wed Apr 16 20:17:46 2014
New Revision: 209447
URL: http://gcc.gnu.org/viewcvs?rev=209447root=gccview=rev
Log:
2014-04-16 Patrick Palka
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60765
--- Comment #3 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org ---
Author: paolo
Date: Wed Apr 16 20:17:46 2014
New Revision: 209447
URL: http://gcc.gnu.org/viewcvs?rev=209447root=gccview=rev
Log:
2014-04-16 Patrick Palka
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60764
Paolo Carlini paolo.carlini at oracle dot com changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60765
Paolo Carlini paolo.carlini at oracle dot com changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53552
Manuel López-Ibáñez manu at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53934
Bug 53934 depends on bug 53552, which changed state.
Bug 53552 Summary: Add support for !GCC$ warning directive (cf. #pragma warning)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53552
What|Removed |Added
1 - 100 of 240 matches
Mail list logo
