MB == Miles Bader mi...@gnu.org writes:
MB [Or, perhaps, not -Wall perse, but maybe a new option which
MB is a little more conservative, -Wstandard or something...]
Sure. Making a few more of the -W flags on by default may be OK,
depending on the chosen list. It is the idea of turing all
On Sun, Apr 8, 2012 at 10:16 AM, James Cloos cl...@jhcloos.com wrote:
MB == Miles Bader mi...@gnu.org writes:
MB [Or, perhaps, not -Wall perse, but maybe a new option which
MB is a little more conservative, -Wstandard or something...]
Sure. Making a few more of the -W flags on by default
What are the possibilities of adding a GCC extension to allow:
switch (foo) {
case 1:
case 2:
case 3 to 8:
case 9:
default:
}
in C/C++ case statements?
Best regards,
Rick C. Hodgin
On Sun, Apr 8, 2012 at 10:59 AM, Rick Hodgin foxmuldrs...@yahoo.com wrote:
What are the possibilities of adding a GCC extension to allow:
switch (foo) {
case 1:
case 2:
case 3 to 8:
case 9:
default:
}
in C/C++ case statements?
GCC used to have a range extension for case:
case 3..8
On Sun, Apr 08, 2012 at 08:59:46AM -0700, Rick Hodgin wrote:
What are the possibilities of adding a GCC extension to allow:
switch (foo) {
case 1:
case 2:
case 3 to 8:
case 9:
default:
}
This already exists (and is a GNU extension):
switch (foo)
{
case 1:
break;
On 4/8/2012 11:59 AM, Rick Hodgin wrote:
What are the possibilities of adding a GCC extension to allow:
switch (foo) {
case 1:
case 2:
case 3 to 8:
case 9:
default:
}
in C/C++ case statements?
Best regards,
Rick C. Hodgin
I think there is very little enthusiasm these days for adding
Thank you!
I'd like to find out some day exactly how much I _don't_ know. :-)
Best regards,
Rick C. Hodgin
--- On Sun, 4/8/12, Marek Polacek pola...@redhat.com wrote:
From: Marek Polacek pola...@redhat.com
Subject: Re: Switch statement case range
To: Rick Hodgin foxmuldrs...@yahoo.com
Cc:
On Sun, 2012-04-08 at 09:07 -0700, Rick Hodgin wrote:
Thank you!
I'd like to find out some day exactly how much I _don't_ know. :-)
Knock yourself out ;)
http://gcc.gnu.org/onlinedocs/gcc/C-Extensions.html
Cheers,
Oleg
An update on the GNU Tools Cauldron (http://gcc.gnu.org/wiki/cauldron2012)
If you are starting to organize your trip, we have added some
suggestions about accomodation on the Cauldron page. We have not
negotiated special prices with any hotel in Prague.
If you need an invitation letter for a
Hello Diego,
I am all set with my plans for Prague, but I have to
leave on a flight at 2pm on Wednesday. I hope my
presentation can be scheduled consistently with these
travel plans?
Robert Dewar
As comprehensive as that list is (and it is indeed quite impressive), it is yet
a small subset I assure you. LOL! :-)
I have to be honest ... the more I learn about GCC the more impressed I am. I
think it is, without a doubt, the best GNU project in history.
Has there ever been any talk of
On 07/04/2012 23:58, Gabriel Dos Reis wrote:
On Sat, Apr 7, 2012 at 5:41 PM, Dave Korn wrote:
-Wunused-function
-Wunused-label
-Wunused-value
-Wunused-variable
IMHO we should move the -Wunused ones into -Wextra if we're going to turn on
-Wall by default. The rest seem pretty reasonable
Hi Paul,
I put some debugging on here:
op0 = XEXP (operands[0], 0);
if (GET_CODE (op0) == REG
|| (GET_CODE (op0) == PLUS GET_CODE (XEXP (op0, 0)) == REG
GET_CODE (XEXP (op0, 1)) == CONST_INT
(unsigned) INTVAL (XEXP (op0, 1)) 4096))
{
op0 = operands[0];
On 8 April 2012 16:16, James Cloos wrote:
Sure. Making a few more of the -W flags on by default may be OK,
depending on the chosen list. It is the idea of turing all possible
warning options on by default which is unreasonable.
Noone's suggested doing that. As Gaby said, -Wall doesn't turn
On 4/8/2012 1:56 PM, Jonathan Wakely wrote:
The people who don't want -Wall (or
-Wstandard) enabled are likely to be the ones who know how to use
-Wno-all or whatever to get what they want.
I see no evidence that supports that guess. On the contrary, I
would guess that if -Wall is set by
On Sun, Apr 8, 2012 at 1:51 PM, Robert Dewar de...@adacore.com wrote:
On 4/8/2012 1:56 PM, Jonathan Wakely wrote:
The people who don't want -Wall (or
-Wstandard) enabled are likely to be the ones who know how to use
-Wno-all or whatever to get what they want.
I see no evidence that
On 8 April 2012 19:51, Robert Dewar wrote:
On 4/8/2012 1:56 PM, Jonathan Wakely wrote:
The people who don't want -Wall (or
-Wstandard) enabled are likely to be the ones who know how to use
-Wno-all or whatever to get what they want.
I see no evidence that supports that guess. On the
On 4/8/2012 3:33 PM, Gabriel Dos Reis wrote:
On Sun, Apr 8, 2012 at 1:51 PM, Robert Dewarde...@adacore.com wrote:
On 4/8/2012 1:56 PM, Jonathan Wakely wrote:
The people who don't want -Wall (or
-Wstandard) enabled are likely to be the ones who know how to use
-Wno-all or whatever to get
On 4/8/2012 3:37 PM, Jonathan Wakely wrote:
Again, that also applies when people use -Wall today: a false positive
is unwanted even if you use -Wall, and those false positives are bugs
and so having them in bugzilla is good.
Do you really want me to file hundreds of bug reports that are for
On 8 April 2012 20:54, Robert Dewar wrote:
On 4/8/2012 3:37 PM, Jonathan Wakely wrote:
Again, that also applies when people use -Wall today: a false positive
is unwanted even if you use -Wall, and those false positives are bugs
and so having them in bugzilla is good.
Do you really want me
On 4/8/2012 4:02 PM, Jonathan Wakely wrote:
No, because those are already in bugzilla, and there's a whole wiki
page about improving that particular warning.
Yes, I know, and that page is to me good justification for NOT including
this warning in the set that is on by default.
But I'd be
On Sun, Apr 8, 2012 at 2:53 PM, Robert Dewar de...@adacore.com wrote:
On 4/8/2012 3:33 PM, Gabriel Dos Reis wrote:
On Sun, Apr 8, 2012 at 1:51 PM, Robert Dewarde...@adacore.com wrote:
On 4/8/2012 1:56 PM, Jonathan Wakely wrote:
The people who don't want -Wall (or
-Wstandard) enabled are
On Sun, Apr 8, 2012 at 2:54 PM, Robert Dewar de...@adacore.com wrote:
On 4/8/2012 3:37 PM, Jonathan Wakely wrote:
Again, that also applies when people use -Wall today: a false positive
is unwanted even if you use -Wall, and those false positives are bugs
and so having them in bugzilla is
On Sun, Apr 8, 2012 at 3:13 PM, Robert Dewar de...@adacore.com wrote:
On 4/8/2012 4:02 PM, Jonathan Wakely wrote:
But I'd be just as happy with a -Wstandard (by any name) enabled by
default as I would be with -Wall on by default. Only enabling warnings
with very little chance of false
On 4/8/2012 4:23 PM, Gabriel Dos Reis wrote:
I think I agree with this. I suspect the only difference might be that
I do not believe the fix is necessarily to turn them off.
Well there are three possibilities
a) fix the false positives, at the possible expense of introducing
new false
On 4/8/2012 4:25 PM, Gabriel Dos Reis wrote:
On Sun, Apr 8, 2012 at 2:54 PM, Robert Dewarde...@adacore.com wrote:
On 4/8/2012 3:37 PM, Jonathan Wakely wrote:
Again, that also applies when people use -Wall today: a false positive
is unwanted even if you use -Wall, and those false positives
On 4/8/2012 4:26 PM, Gabriel Dos Reis wrote:
On Sun, Apr 8, 2012 at 3:13 PM, Robert Dewarde...@adacore.com wrote:
On 4/8/2012 4:02 PM, Jonathan Wakely wrote:
But I'd be just as happy with a -Wstandard (by any name) enabled by
default as I would be with -Wall on by default. Only enabling
On Sun, Apr 8, 2012 at 3:28 PM, Robert Dewar de...@adacore.com wrote:
On 4/8/2012 4:23 PM, Gabriel Dos Reis wrote:
I think I agree with this. I suspect the only difference might be that
I do not believe the fix is necessarily to turn them off.
Well there are three possibilities
a) fix
On Sun, Apr 8, 2012 at 3:29 PM, Robert Dewar de...@adacore.com wrote:
On 4/8/2012 4:26 PM, Gabriel Dos Reis wrote:
On Sun, Apr 8, 2012 at 3:13 PM, Robert Dewarde...@adacore.com wrote:
On 4/8/2012 4:02 PM, Jonathan Wakely wrote:
But I'd be just as happy with a -Wstandard (by any name)
On 4/8/2012 4:59 PM, Gabriel Dos Reis wrote:
no, -Wstandard wasn't in my original proposal. It is the name suggested
by Miles for the list I gave Arnaud upon request.
I know that, I can read -:)
I am just saying I think this issue still needs discussion (and you
were complaining about
Snapshot gcc-4.8-20120408 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.8-20120408/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.8 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/trunk
Hi
GCC does warn if returning a pointer to a local variable (stack memory).
But there are alot of more cases where GCC could possibly warn,
eg. when references are made to local variables or stack memory.
See this attached example code.
GCC warns for first case, but not the others.
I think all
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40973
--- Comment #4 from Tobias Burnus burnus at gcc dot gnu.org 2012-04-08
07:15:12 UTC ---
Author: burnus
Date: Sun Apr 8 07:15:01 2012
New Revision: 186223
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=186223
Log:
2012-04-08 Tobias Burnus
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52751
--- Comment #3 from Tobias Burnus burnus at gcc dot gnu.org 2012-04-08
07:15:12 UTC ---
Author: burnus
Date: Sun Apr 8 07:15:01 2012
New Revision: 186223
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=186223
Log:
2012-04-08 Tobias Burnus
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48496
--- Comment #17 from Eric Botcazou ebotcazou at gcc dot gnu.org 2012-04-08
07:42:36 UTC ---
Reload maintainers, do you have objections to removing the problematic block of
code as suggested by Vlad in comment #4? If so, please propose something
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40973
Tobias Burnus burnus at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52751
Tobias Burnus burnus at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52724
--- Comment #4 from Thomas Koenig tkoenig at gcc dot gnu.org 2012-04-08
08:55:42 UTC ---
Yes, my original test case was bogus.
Slightly reduced test case:
program main
implicit none
integer :: i
character(len=100,kind=4) :: buffer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52904
Bug #: 52904
Summary: -Wstrict-overflow false alarm with bounded loop
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52904
--- Comment #1 from eggert at gnu dot org 2012-04-08 08:59:43 UTC ---
Created attachment 27114
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27114
gcc -v output, for test case
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52904
eggert at gnu dot org changed:
What|Removed |Added
Attachment #27113|0 |1
is obsolete|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52630
Eric Botcazou ebotcazou at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|WAITING
---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52904
Andrew Pinski pinskia at gcc dot gnu.org changed:
What|Removed |Added
Keywords||diagnostic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44786
Ivan Sorokin vanyacpp at gmail dot com changed:
What|Removed |Added
CC||vanyacpp at gmail
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42143
Roumen Petrov bugtrack at roumenpetrov dot info changed:
What|Removed |Added
CC||bugtrack
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52883
Eric Botcazou ebotcazou at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|NEW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52901
Daniel Krügler daniel.kruegler at googlemail dot com changed:
What|Removed |Added
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16612
--- Comment #35 from Jonathan Wakely redi at gcc dot gnu.org 2012-04-08
13:59:20 UTC ---
(In reply to comment #34)
For what it's worth, it appears as if I was just bitten by this issue in a
slightly different context.
You haven't given enough
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44786
--- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org 2012-04-08
14:06:31 UTC ---
Indeed. I think it's meant to be useful for catching some of the problems that
valgrind identifies, and valgrind has even more performance overhead.
That
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52901
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52867
--- Comment #4 from Richard Earnshaw rearnsha at gcc dot gnu.org 2012-04-08
14:38:23 UTC ---
If the problem is with your installed compiler, there are a number of ways in
which you might work around the problem:
- Build stage1 with optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52867
--- Comment #5 from Szűcs, Gábor surrano at gmail dot com 2012-04-08 15:12:53
UTC ---
Thanks a lot!
For the records: I managed to proceed with compilation till stage3 where I had
to disable compare as per install docs. Afterwards, cc1 seems to
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52901
Marc Glisse marc.glisse at normalesup dot org changed:
What|Removed |Added
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52905
Bug #: 52905
Summary: [C++0x] ice on invalid brace-enclosed initializer of
vector of enums
Classification: Unclassified
Product: gcc
Version: 4.6.1
Status:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52905
--- Comment #1 from Dirk Moermans dirkmoermans at gmail dot com 2012-04-08
16:17:40 UTC ---
I compile with g++ -std=c++0x
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48496
--- Comment #18 from Ulrich Weigand uweigand at gcc dot gnu.org 2012-04-08
17:32:23 UTC ---
According to Vlad's comment #4, the validity check fails because a reload insn
contains a spilled pseudo that will later be replaced by a MEM.
However,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52905
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Keywords|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52901
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Severity|major |normal
---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52901
--- Comment #5 from Jonathan Wakely redi at gcc dot gnu.org 2012-04-08
18:09:06 UTC ---
See also PR 51066 and PR 51270 and PR 38958 for similar RFEs for better
diagnostics about creating dangling references
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49974
--- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org 2012-04-08
18:15:04 UTC ---
As pointed out in PR 52901 comment 3, this missing warning is likely to bite
people misusing std::move like so:
X f()
{
X x;
return std::move(x);
}
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52906
Bug #: 52906
Summary: [4.7/4.8 Regression] ICE: SIGSEGV in check_tag_decl
(decl.c:4230) with __attribute__ ((__deprecated__));
alone
Classification: Unclassified
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44786
--- Comment #5 from Andrew Pinski pinskia at gcc dot gnu.org 2012-04-08
18:57:51 UTC ---
# Subscripting where the static type of one operand is variable which is
decayed from an array type and the other operand is greater than the size of
the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52907
Bug #: 52907
Summary: Underflowing floating point expressions wrongly folded
to zero
Classification: Unclassified
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52908
Bug #: 52908
Summary: xop-mul-1:f9 miscompiled on bulldozer (-mxop)
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52909
Bug #: 52909
Summary: Procedure pointers not private to modules
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52910
Bug #: 52910
Summary: xop-mul-1:f13 miscompiled on bulldozer (-mxop)
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52909
janus at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
On Sat, 31 Mar 2012, Eddie Kohler wrote:
The syntax is very simple. The extra argument, an even-length C string
constant, is interpreted as a set of character pairs. For example, % says
interpret the character '' like you would '%': as a conversion specifier
that consumes no arguments from
Hi,
The attached patch updates the top comment block in constraints.md and
removes the unused Sr0 constraint.
Tested with 'make all-gcc'.
OK?
Cheers,
Oleg
ChangeLog:
* config/sh/constraints.md: Update list of constraints in
comment block.
(Sr0): Remove unused memory
Hi H.J.
On 31 Mar 2012, at 20:24, Jack Howarth wrote:
The latest gcc-pr52784-2.patch patch also allows current gcc trunk
to
bootstrap on i386-apple-darwin10.
Despite the fact that bootstrap is restored, there remain problems
with this patch and some more work is needed.
(a)
On 8 April 2012 06:09, Jason Merrill ja...@redhat.com wrote:
On 04/07/2012 06:29 PM, Manuel López-Ibáńez wrote:
I'll be happy to change it to whatever is more understandable. I think
in CSS is called padding.
That wouldn't be any clearer; my confusion was that I thought you were
padding
On Thu, 29 Mar 2012, Sriraman Tallam wrote:
Hi,
I have made a new patch to only have two builtins :
* __builtin_cpu_is (CPUNAME)
* __builtin_cpu_supports (FEATURE)
apart from the cpu init builtin, __builtin_cpu_init.
I don't see any .texi file as part of this change. Shouldn't
On Sun, Apr 8, 2012 at 4:38 AM, Iain Sandoe idsan...@googlemail.com wrote:
Hi H.J.
On 31 Mar 2012, at 20:24, Jack Howarth wrote:
The latest gcc-pr52784-2.patch patch also allows current gcc trunk to
bootstrap on i386-apple-darwin10.
Despite the fact that bootstrap is restored, there
On 8 April 2012 17:14, Gabriel Dos Reis g...@integrable-solutions.net wrote:
On Sun, Apr 8, 2012 at 7:06 AM, Manuel López-Ibáñez
lopeziba...@gmail.com wrote:
On 8 April 2012 06:09, Jason Merrill ja...@redhat.com wrote:
On 04/07/2012 06:29 PM, Manuel López-Ibáńez wrote:
I'll be happy to
On 8 April 2012 06:09, Jason Merrill ja...@redhat.com wrote:
On 04/07/2012 06:29 PM, Manuel López-Ibáńez wrote:
+getenv_columns (void)
I had been thinking to check COLUMNS once at the beginning of compilation; I
don't think the value can change while the compiler is running since we
don't
On Sun, Apr 8, 2012 at 11:10 AM, Manuel López-Ibáñez
lopeziba...@gmail.com wrote:
On 8 April 2012 17:14, Gabriel Dos Reis g...@integrable-solutions.net wrote:
On Sun, Apr 8, 2012 at 7:06 AM, Manuel López-Ibáñez
lopeziba...@gmail.com wrote:
On 8 April 2012 06:09, Jason Merrill ja...@redhat.com
On Sun, Apr 8, 2012 at 11:13 AM, Manuel López-Ibáñez
lopeziba...@gmail.com wrote:
On 8 April 2012 06:09, Jason Merrill ja...@redhat.com wrote:
On 04/07/2012 06:29 PM, Manuel López-Ibáńez wrote:
+getenv_columns (void)
I had been thinking to check COLUMNS once at the beginning of compilation;
On 8 April 2012 18:35, Gabriel Dos Reis g...@integrable-solutions.net wrote:
On Sun, Apr 8, 2012 at 11:13 AM, Manuel López-Ibáñez
lopeziba...@gmail.com wrote:
On 8 April 2012 06:09, Jason Merrill ja...@redhat.com wrote:
On 04/07/2012 06:29 PM, Manuel López-Ibáńez wrote:
+getenv_columns
On Apr 8, 2012, at 3:25 AM, Joseph S. Myers wrote:
In principle we want extensibility of format checking, and want it to be
as flexible as the built-in checking is regarding the peculiarities of
different formats - but we also don't want to export implementation
details of format checking
On Sun, Apr 8, 2012 at 11:52 AM, Manuel López-Ibáñez
lopeziba...@gmail.com wrote:
On 8 April 2012 18:35, Gabriel Dos Reis g...@integrable-solutions.net wrote:
On Sun, Apr 8, 2012 at 11:13 AM, Manuel López-Ibáñez
lopeziba...@gmail.com wrote:
On 8 April 2012 06:09, Jason Merrill ja...@redhat.com
On 8 Apr 2012, at 15:54, H.J. Lu wrote:
Despite the fact that bootstrap is restored, there remain problems
with this
patch and some more work is needed.
(a) [trivial] the option 'mx32' is in i386.opt, which means it is
exposed to
all sub-targets, even if they don't support it.
$
Oleg Endo oleg.e...@t-online.de wrote:
The attached patch updates the top comment block in constraints.md and
removes the unused Sr0 constraint.
Tested with 'make all-gcc'.
OK?
OK.
Regards,
kaz
Committed as obvious. I wasn't sure if one should move the declaration
to c-pretty-printer.h, but updating the comment cannot make any harm.
(And why default_tree_printer is in toplev.c?)
Index: gcc/tree-pretty-print.h
===
---
Recently I was hunting for bugs in __cxa_guard_acquire/release that
might result in pr52839. No bugs found, but I did notice that these
functions use excessive memory barriers, no doubt from their
conversion from sync to atomic builtins.
Making the second __atomic_compare_exchange_n in
On Fri, 2012-04-06 at 23:53 +0200, Oleg Endo wrote:
On Fri, 2012-04-06 at 10:46 +0900, Kaz Kojima wrote:
From: Oleg Endo oleg.e...@t-online.de
Exposing three-letter macro MSW and LSW globally looks not
a good idea to me.
Would 'HIGH_WORD' and 'LOW_WORD' be OK as an alternative?
On 04/08/2012 12:13 PM, Manuel López-Ibáñez wrote:
To focus on the issue at hand, and independently of whether any bugs
exist or not, and whether I am capable or not to fix them. What you
are proposing is to change the current default of no line-wrapping to
line-wrap at getenv(COLUMNS), isn't
gcc.dg/guality/pr45003-*.c have regressed with reordering of the
exploration of the loc expansion space, in a way that didn't always
privilege expansions without ENTRY_VALUEs over ones with it.
This patch fixes it, by ensuring that we'll only ever use ENTRY_VALUEs
if we can't help it given a
Ping? (Updated with improved docs; should the options be renamed to
-ftree-copyrename-* to match the option that covers the entire pass?)
On Jun 4, 2011, Alexandre Oliva aol...@redhat.com wrote:
On Oct 13, 2009, Alexandre Oliva aol...@redhat.com wrote:
On Jun 1, 2009, Alexandre Oliva
88 matches
Mail list logo
