Mike Stump <[EMAIL PROTECTED]> wrote:
> Ok, question about the merge tool. Does revision N mean all changes
> that predate N that apply, or just N-1 to N?
N-1 to N. You can specify a single commit and it will apply only that.
> So, let's say that 3, 4, 5, 6, 7 are available, can I merge 3 today
Hello, gcc
I think it's very interesting. I want to split a insn of loading SF
data through SI symbol, such as (set (reg:SF 5 $5) (mem/u/f:SF
(symbol_ref/u:SI ("*$LC0".
I want to it firstly load the address into a register, then load the
data through
the register. So I define the insn as follo
Daniel Jacobowitz wrote:
I am currently working on the debug_frame info emission in our C/C++
compiler (based on Open64) and I have recently come across optimized
code which I don't know how to handle.
Reposting this question to increasingly unrelated lists is not likely
to help you find an a
Jim Wilson wrote:
Christophe LYON wrote:
I have been look at the Dwarf2 frame info generated by GCC, and how it
works.
From what I can see, only the register saves are recorded, and not
the restores. Why?
The frame info is primarily used for C++ EH stack unwinding. Since you
can't throw
On 2005-10-24 18:59:44 -0700, Mike Stump wrote:
> On Oct 24, 2005, at 5:52 PM, Vincent Lefevre wrote:
> >But then, copy-paste would no longer always work since spaces are
> >sometimes added at the end of some lines (depending on the terminal
> >and the context).
>
> Please name such systems. We c
(define_insn "loadsf"
[(set (match_operand:SF 0 "register_operand" "=r")
(mem:SF (match_operand:SI 1 "immediate_operand" "m")))]
This makes no sense, because the constraint means that the mem's operand
is an immediate before reload (and you want it to be a register), and a
mem afte
Neil Booth wrote:
> Howard Hinnant wrote:-
>
>> I've been reviewing the age-old issue of interpreting
>> * as the end-of-line indicator as is the current
>> practice with gcc.
>
> FWIW I support abandoning this behaviour too.
>
> Neil.
I would like it to be retained in at least one case: CRL
Eric Fisher wrote:
> I think it's very interesting. I want to split a insn of loading SF
> data through SI symbol, such as (set (reg:SF 5 $5) (mem/u/f:SF
> (symbol_ref/u:SI ("*$LC0".
> I want to it firstly load the address into a register, then load the
> data through the register. So I define
Dave Korn wrote:-
>
> I would like it to be retained in at least one case: CRLF line endings
> should still work, specifically backslash-CR-LF should be usable to indicate
> a continued line. So how about having gcc accept
>
> ?
>
> instead?
This is entirely orthogonal; the two issues sho
'Neil Booth' wrote:
> Dave Korn wrote:-
>
>>
>> I would like it to be retained in at least one case: CRLF line endings
>> should still work, specifically backslash-CR-LF should be usable to
>> indicate a continued line. So how about having gcc accept
>>
>> ?
>>
>> instead?
>
> This is ent
On Tue, 2005-10-25 at 10:13 +0530, Ranjit Mathew wrote:
> On 10/25/05, Mike Stump <[EMAIL PROTECTED]> wrote:
> > >
> > > First off, several fields are marked "skip", though the
> > > documents seem to strongly discourage this. For example,
> > > see ssa_use_operand_t in tree.h.
> >
> > Was this a q
On Tue, 2005-10-25 at 09:36 -0400, Daniel Berlin wrote:
> On Tue, 2005-10-25 at 10:13 +0530, Ranjit Mathew wrote:
> > On 10/25/05, Mike Stump <[EMAIL PROTECTED]> wrote:
> > > >
> > > > First off, several fields are marked "skip", though the
> > > > documents seem to strongly discourage this. For ex
On Mon, Oct 24, 2005 at 06:59:44PM -0700, Mike Stump wrote:
> On Oct 24, 2005, at 5:52 PM, Vincent Lefevre wrote:
> >But then, copy-paste would no longer always work since spaces are
> >sometimes added at the end of some lines (depending on the terminal
> >and the context).
>
> Please name such sy
I just finished reading the SVN manual. This was the 1.1 version, so I hope
there's nothing important in the newer versions.
Somebody at one point asked how to have a subdirectory of the repository
that wouldn't be touched so they could have something entirely different
in it. I think "svn switch
On Tue, Oct 25, 2005 at 01:05:46PM -0400, Richard Kenner wrote:
> I just finished reading the SVN manual. This was the 1.1 version, so I hope
> there's nothing important in the newer versions.
>
> Somebody at one point asked how to have a subdirectory of the repository
> that wouldn't be touched s
It was simpler than that: Dan created an empty directory in the GCC
repository to switch to.
Ah!
Googling for "gcc svn switch" took me directly to the Wiki page, which
covers this; it's under setup:
I didn't Google, but searched the GCC list for "svn switch". That's why
I di
* Richard Kenner:
> Here's what I need to do and I welcome suggestions: one of the working
> directories I have is the FSF GCC repository (from HEAD), but the
> gcc/ada subdirectory is the AdaCore repository. For cvs, what I do in
> gcc/CVS/Entries is delete the line for "ada" and then checkout t
I'm trying to build svn from sources on my x86-64 machine and get:
cd subversion/libsvn_subr && /bin/sh /gcc/gcc/subversion-1.2.3/libtool --tag=CC
--silent --mode=link gcc -g -O2 -g -O2 -pthread -DNEON_ZLIB -rpath
/usr/local/lib -o libsvn_subr-1.la auth.lo cmdline.lo config.lo config_auth.
On Tue, Oct 25, 2005 at 01:16:30PM -0400, Richard Kenner wrote:
> I think you would need to do something a bit more complicated for
> this, using svk. Among other things, this should let you combine
> multiple conceptual "repositories". But I'll defer this one to our
> experts
In http://gcc.gnu.org/ml/gcc/2005-10/msg00823.html, Jim Wilson wrote:
> The frame info is primarily used for C++ EH stack unwinding. Since
you can't throw a C++ exception in an epilogue, epilogue frame info
isn't needed > for this, and was never implemented for most targets.
Which is a shame.
Hi!
While looking at PR c++/24512, I have noticed that for
#pragma omp {,parallel }for loops we don't handle -fno-for-scope
and don't emit the default error messages that point people to
the problem otherwise.
So my question is, should we consider #pragma omp for and
#pragma omp parallel for a se
On Tue, Oct 25, 2005 at 01:43:28PM -0400, Richard Kenner wrote:
> I'm trying to build svn from sources on my x86-64 machine and get:
>
> cd subversion/libsvn_subr && /bin/sh /gcc/gcc/subversion-1.2.3/libtool
> --tag=CC --silent --mode=link gcc -g -O2 -g -O2 -pthread -DNEON_ZLIB
> -rpath /us
Do you have the 64bit version of libgdbm.so under /usr/lib64?
Yes. The question is why it isn't getting used.
On Tue, Oct 25, 2005 at 03:10:58PM -0400, Richard Kenner wrote:
> Do you have the 64bit version of libgdbm.so under /usr/lib64?
>
> Yes. The question is why it isn't getting used.
Add --verbose to ld and post the ld command line as well as its output.
H.J.
On Tue, Oct 25, 2005 at 11:50:00AM -0700, Eric Christopher wrote:
>
> On Oct 25, 2005, at 8:54 AM, Joe Buck wrote:
> >Often when I cut and paste a program example from Firefox into
> >Emacs, I
> >wind up with extra whitespace.
>
> I've got an elisp file that removes trailing whitespace if you'd
On Oct 25, 2005, [EMAIL PROTECTED] (Richard Kenner) wrote:
> cd subversion/libsvn_subr && /bin/sh /gcc/gcc/subversion-1.2.3/libtool
> --tag=CC --silent --mode=link gcc -g -O2 -g -O2 -pthread -DNEON_ZLIB
> -rpath /usr/local/lib -o libsvn_subr-1.la auth.lo cmdline.lo config.lo
> config_auth
On Tue, 2005-10-25 at 11:34, Joern RENNECKE wrote:
> It can't be easily implemented in target-specific code alone. Sometimes
> there is code after the epilogue, so there would have to be
> a mechanism to get the dwarf virtual machine back to the pre-epilogue state.
There is.
I'm more conversant
On Oct 25, 2005, at 11:56 AM, Jakub Jelinek wrote:
While looking at PR c++/24512, I have noticed that for
#pragma omp {,parallel }for loops we don't handle -fno-for-scope
Issue a sorry and don't worry about it? -fno-for-scope is for legacy
code for people that can't be bothered to spend a fe
On Tue, 2005-10-25 at 01:08, Christophe LYON wrote:
> On occasions, I wonder whether it wouldn't make sense to generate
> different infos in debug_frame and eh_frame:
That is probably a reasonable solution if it can be implemented
cleanly. There are already some differences. debug_frame info can
On Tue, Oct 25, 2005 at 12:44:42PM -0700, James E Wilson wrote:
> On Tue, 2005-10-25 at 01:08, Christophe LYON wrote:
> > On occasions, I wonder whether it wouldn't make sense to generate
> > different infos in debug_frame and eh_frame:
>
> That is probably a reasonable solution if it can be imple
On Oct 24, 2005, at 10:39 PM, Florian Weimer wrote:
Emacs in an xterm, from time to time.
Yeah, I knew about that one, cutting and pasting from any full screen
program running in a terminal emulator tends to be wrong. Tab
characters are usually the first causalities, along with long
line
> "Joe" == Joe Buck <[EMAIL PROTECTED]> writes:
Joe> Not needed; the following sequence removes trailing whitespace in Emacs:
Joe> ESC-x picture-mode NL
Joe> CTL-c CTL-c
Joe> (picture-mode cleans up trailing whitespace on exit).
There's also the more direct M-x delete-trailing-whitespace
Tom
On Tue, Oct 25, 2005 at 12:53:23PM -0700, Mike Stump wrote:
> On Oct 24, 2005, at 10:39 PM, Florian Weimer wrote:
> >Emacs in an xterm, from time to time.
>
> Yeah, I knew about that one, cutting and pasting from any full screen
> program running in a terminal emulator tends to be wrong. Tab
Hello,
We just bought a HP Integrity Itanium server and are running VMS 8.2.
Does a Gnu C-compiler exist ?
Best regards,
Sincerely,
Rudy Campe
Annabel Textiles
Belgium - Europe
[EMAIL PROTECTED]
On Oct 25, 2005, at 12:50 AM, Giovanni Bajo wrote:
Uhm, I'm not sure how to explain this without being too pedantic.
Does this
sound clearer?
This tool tracks each individual change (fine-grained) and will never
reapply an already applied change.
I think that is a high level answer, and c
On Tuesday 25 October 2005 22:19, [EMAIL PROTECTED] wrote:
> Hello,
>
> We just bought a HP Integrity Itanium server and are running VMS 8.2.
> Does a Gnu C-compiler exist ?
So, you're saying you can find this mailing list, but not the compiler
that is being discussed here?
Gr.
Steven
The Wiki mentiones it, but not where to get it. Google searches don't
see to find the tar file for it.
* Mike Stump:
> On Oct 24, 2005, at 10:39 PM, Florian Weimer wrote:
>> Emacs in an xterm, from time to time.
>
> Yeah, I knew about that one, cutting and pasting from any full screen
> program running in a terminal emulator tends to be wrong. Tab
> characters are usually the first causalities
On Tue, 2005-10-25 at 16:39 -0400, Richard Kenner wrote:
> The Wiki mentiones it, but not where to get it. Google searches don't
> see to find the tar file for it.
I will email the list when the release candidate is released.
Richard Kenner <[EMAIL PROTECTED]> wrote:
> The Wiki mentiones it, but not where to get it. Google searches don't
> see to find the tar file for it.
I'll add a note to the wiki about this. Subversion 1.3 RC1 should be out
real soon now, you can use (and test) that one. The idea is that if the GC
Joe Buck <[EMAIL PROTECTED]> writes:
> On Tue, Oct 25, 2005 at 11:50:00AM -0700, Eric Christopher wrote:
>>
>> On Oct 25, 2005, at 8:54 AM, Joe Buck wrote:
>> >Often when I cut and paste a program example from Firefox into
>> >Emacs, I
>> >wind up with extra whitespace.
>>
>> I've got an elisp
On 2005-10-25 12:12:31 -0700, Joe Buck wrote:
> Not needed; the following sequence removes trailing whitespace in Emacs:
>
> ESC-x picture-mode NL
> CTL-c CTL-c
>
> (picture-mode cleans up trailing whitespace on exit).
What about M-x delete-trailing-whitespace?
Anyway by removing trailing white
On Tue, Oct 25, 2005 at 02:56:54PM -0400, Jakub Jelinek wrote:
> So my question is, should we consider #pragma omp for and
> #pragma omp parallel for a separate scope around the for loop for
> this kind of purpose or not? I think it would be better to be
> consistent with -fno-openmp (i.e. if ther
On Oct 24, 2005, at 9:43 PM, Ranjit Mathew wrote:
1. we want to reduce time spent in the GC,
Doesn't really help on time.
2. we know it doesn't matter for PCH, so we do it to
reduce the size of the PCH and its loading time,
No, doesn't reduce the size, nor the load time. We can only know
On Oct 25, 2005, at 1:31 PM, Steven Bosscher wrote:
So, you're saying you can find this mailing list, but not the compiler
that is being discussed here?
No, he is asking if it really does work, which isn't as obvious. :-)
After that, he might be asking for a pointer to a binary to bootstrap
On 2005-10-25 16:01:43 -0400, Daniel Jacobowitz wrote:
> On Tue, Oct 25, 2005 at 12:53:23PM -0700, Mike Stump wrote:
> > Yeah, I knew about that one, cutting and pasting from any full screen
> > program running in a terminal emulator tends to be wrong. Tab
> > characters are usually the first
On Tue, Oct 25, 2005 at 11:16:23PM +0200, Vincent Lefevre wrote:
> On 2005-10-25 16:01:43 -0400, Daniel Jacobowitz wrote:
> > On Tue, Oct 25, 2005 at 12:53:23PM -0700, Mike Stump wrote:
> > > Yeah, I knew about that one, cutting and pasting from any full screen
> > > program running in a terminal
On Oct 24, 2005, at 3:52 PM, Neil Booth wrote:
Howard Hinnant wrote:-
I've been reviewing the age-old issue of interpreting
* as the end-of-line indicator as is the current
practice with gcc.
FWIW I support abandoning this behaviour too.
I filed bugzilla 24531 about this.
Haven't heard J
>
> > OK, so it must be this, then
>
> Installed.
>
> That works. Thanks.
>
>
>
> On Oct 24, 2005, at 3:52 PM, Neil Booth wrote:
>
> > Howard Hinnant wrote:-
> >
> >> I've been reviewing the age-old issue of interpreting
> >> * as the end-of-line indicator as is the current
> >> practice with gcc.
> >
> > FWIW I support abandoning this behaviour too.
>
> I filed bugzil
On Tue, Oct 25, 2005 at 10:08:59AM +0200, Christophe LYON wrote:
> On occasions, I wonder whether it wouldn't make sense to generate
> different infos in debug_frame and eh_frame: IIUC, GCC tries to
> 'compress' the debug frame info by generating few advance_loc
> instructions (eg only 1 for the wh
On Tue, Oct 25, 2005 at 10:08:59AM +0200, Christophe LYON wrote:
> On occasions, I wonder whether it wouldn't make sense to generate
> different infos in debug_frame and eh_frame
And we do this.
r~
>
> >
> > > OK, so it must be this, then
> >
> > Installed.
> >
> > That works. Thanks.
> >
Ignore this, this was a typo.
-- Pinski
[EMAIL PROTECTED] wrote:
Hello,
We just bought a HP Integrity Itanium server and are running VMS 8.2.
Does a Gnu C-compiler exist ?
Note that AdaCore is currently busy doing a GNAT Pro port for this
target (funded by HP), we have to get a C compiler working as part
of this effort.
On Mon, Oct 24, 2005 at 03:39:53PM -0500, Bryan Ford wrote:
> My question: does GCC-generated code ever actually depend on this aspect of
> the x86 architecture - i.e., on instructions that architecturally change some
> but not all condition codes _not_ changing those bits that they're not
> sup
Oh, one more thing. This seems like the normal problem of not
reading the docs
if something does not work the way you want it to work.
So?
The only thing we can do is point it out that it is documented
behavior and
then move on to the next issue. Also why are we discussing this when
th
>
> >
> >
> > On Oct 24, 2005, at 3:52 PM, Neil Booth wrote:
> >
> > > Howard Hinnant wrote:-
> > >
> > >> I've been reviewing the age-old issue of interpreting
> > >> * as the end-of-line indicator as is the current
> > >> practice with gcc.
> > >
> > > FWIW I support abandoning this behaviour
On Mon, Oct 24, 2005 at 10:07:33PM -0400, DJ Delorie wrote:
>
> > Please name such systems. We can then know to not use them, and can
> > document in the manual they are broken if we wish.
>
> IIRC the Windows cut-n-paste cuts a rectangle, not as-printed.
Yes, to this day, even using their la
>
> >
> > Oh, one more thing. This seems like the normal problem of not
> > reading the docs
> > if something does not work the way you want it to work.
>
> So?
>
> > The only thing we can do is point it out that it is documented
> > behavior and
> > then move on to the next issue. Also wh
This is not a regression really.
It is a regression against 2.95.
-eric
Snapshot gcc-3.4-20051025 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/3.4-20051025/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 3.4 CVS branch
with the following options: -rgcc-ss-3_4-20051025
You'll
On Tue, Oct 25, 2005 at 03:14:27PM -0700, Eric Christopher wrote:
> This is, as Mr. Buck has noted, a regression from 2.95.
No, it is not (and I did not say that); it is a behavior change, which I
vaguely recall was requested.
Still, many of us have to get code past multiple compilers, so the
war
On Tue, Oct 25, 2005 at 03:45:36PM -0700, Eric Christopher wrote:
> >
> >This is not a regression really.
> >
>
> It is a regression against 2.95.
As I said, no it is not. A behavior change is only a regression when
the first behavior is correct and the second is not.
In this case, there is no
The man page information for the gcc c++98 option says that the
compiler will be compliant with "The 1998 ISO C++ standard plus
amendments." Are the amendments referring to the changes to the C++
standard that is now "ISO/IEC 14882:2003". I need to know if "ISO/IEC
14882:2003" is supported by gcc
As I said, no it is not. A behavior change is only a regression when
the first behavior is correct and the second is not.
Fair enough. :)
-eric
Andrew Pinski wrote:
Oh, one more thing. This seems like the normal problem of not
reading the docs
if something does not work the way you want it to work.
So?
The only thing we can do is point it out that it is documented
behavior and
then move on to the next issue. Also why are we d
On Tue, Oct 25, 2005 at 04:05:55PM -0700, Stan Shebs wrote:
> I think you've managed to get everything backwards. We have potential
> customers (dunno if I'm allowed to name them, so I won't) who can't
> use GCC because of its current behavior.
I had thought that a numer of users had requested the
On Oct 25, 2005, at 6:22 PM, Andrew Pinski wrote:
We have people already complaining about removing extensions. Why
should we change
this implementionation defined documented behavior.
I'm not convinced that "extension" is a proper term for this
behavior. It is more like an incompatibili
>
> On Oct 25, 2005, at 6:22 PM, Andrew Pinski wrote:
>
> > We have people already complaining about removing extensions. Why
> > should we change
> > this implementionation defined documented behavior.
>
> I'm not convinced that "extension" is a proper term for this
> behavior. It is more
Joe Buck <[EMAIL PROTECTED]> writes:
> I had thought that a numer of users had requested the current
> behavior back in the egcs days, though I can't track down the brain cell I
> stored that info in;
For the record, the current behaviour was implemented here:
http://gcc.gnu.org/ml/gcc-patche
Andrew Pinski <[EMAIL PROTECTED]> writes:
| Please read what implemenation defined means, this is what you
| are talking about.
Andrew --
Before taking your time to insult people; please do spend a little
bit of that time on your homework on their background.
-- Gaby
On Tue, Oct 25, 2005 at 07:41:11PM -0400, Howard Hinnant wrote:
> I'm not convinced that "extension" is a proper term for this
> behavior. It is more like an incompatibility with the rest of the
> world's compilers. The reason for change is to conform to a de-facto
> standard, and thus ease
On Oct 25, 2005, at 7:44 PM, Andrew Pinski wrote:
But this is not an extension at all. This is an implementation
defined
behavior which is different than what an extension would do.
People depending on this is not the correct thing do any ways as
there could be another compiler besides which
>
> On Oct 25, 2005, at 7:44 PM, Andrew Pinski wrote:
>
> > But this is not an extension at all. This is an implementation
> > defined
> > behavior which is different than what an extension would do.
> >
> > People depending on this is not the correct thing do any ways as
> > there could be an
On Oct 25, 2005, at 8:11 PM, Joe Buck wrote:
// A poorly formatted comment \\
int x = 0;
int y = 1;
...
Howard,
Have you tested the sequence above with various compilers?
I only know of the results on gcc 4.x, MS, EDG-based, and Freescale
CodeWarrior.
I just
have. The behavior depen
On Tue, Oct 25, 2005 at 08:22:15PM -0400, Howard Hinnant wrote:
> And it is not my assertion that gcc's behavior is better or worse
> than other compilers. Only that gcc's behavior is unique in the
> industry (I actually haven't tried all other modern compilers) and
> that uniqueness in this
On Oct 25, 2005, at 8:22 PM, Andrew Pinski wrote:
Why not get other compilers to change to what GCC does? Why does GCC
have to follow what other compilers do, maybe other compilers
would be in the best interest of following what GCC does.
Why not instead get the standard changed and then GCC w
On Tue, Oct 25, 2005 at 08:22:12PM -0400, Andrew Pinski wrote:
> Why not get other compilers to change to what GCC does? Why does GCC
> have to follow what other compilers do, maybe other compilers
> would be in the best interest of following what GCC does.
The problem, I think, is that the beha
On 2005-10-25 17:28:14 -0400, Daniel Jacobowitz wrote:
> I invite you to talk to Thomas about that one; he may well agree.
> That doesn't affect the general case.
I've just seen that it was fixed two years ago. From the ncurses
changelog:
20030719
+ use clr_eol in preference to blanks for bce
On Oct 25, 2005, at 3:22 PM, Andrew Pinski wrote:
I don't think we should change it at all since it is one more thing
to break old gcc code like stuff in Linux kernel.
To get concrete, how many times does \ SP SP * NL occur in old/
current linux kernels?
On Oct 25, 2005, at 4:25 PM, Joe Buck wrote:
I'm having a hard time picturing source code that
a) exhibits different behavior because of this bug, and
b) is maintainable (remember, the behavior depends on the presence
of characters that are completely invisible to many tools).
Perhaps you
On Oct 25, 2005, at 4:44 PM, Andrew Pinski wrote:
People depending on this is not the correct thing do any ways as
there could be another compiler besides which GCC which does this.
Let's enumerate them, what other compilers do this besides gcc?
At 12:00PM EST tomorrow, GCC CVS, excluding wwwdocs, will become
readonly.
I will announce when the new SVN repository is ready.
I will make the final commit to the cvs repository noting it has moved.
in the toplevel dir of *both* /cvs/gcc and /cvs/gcc/gcc
In the meanwhile, 1.3.0rc1 of SVN will
>
> On Oct 25, 2005, at 4:44 PM, Andrew Pinski wrote:
> > People depending on this is not the correct thing do any ways as
> > there could be another compiler besides which GCC which does this.
>
> Let's enumerate them, what other compilers do this besides gcc?
Does that really matter?
-- Pinsk
On Oct 25, 2005, at 5:11 PM, Joe Buck wrote:
I personally like the fact that gcc's behavior does not depend on
invisible characters
All other things being equal, this is a nice design goal. I like it
too. Should we break peoples otherwise portable code to have an
implementation defined b
>
> On Oct 25, 2005, at 4:25 PM, Joe Buck wrote:
> > I'm having a hard time picturing source code that
> >
> > a) exhibits different behavior because of this bug, and
> > b) is maintainable (remember, the behavior depends on the presence
> > of characters that are completely invisible to man
Mike Stump wrote:
On Oct 25, 2005, at 3:22 PM, Andrew Pinski wrote:
I don't think we should change it at all since it is one more thing
to break old gcc code like stuff in Linux kernel.
To get concrete, how many times does \ SP SP * NL occur in old/ current
linux kernels?
$ egrep -r '\
>
> On Oct 25, 2005, at 3:22 PM, Andrew Pinski wrote:
> > I don't think we should change it at all since it is one more thing
> > to break old gcc code like stuff in Linux kernel.
>
> To get concrete, how many times does \ SP SP * NL occur in old/
> current linux kernels?
I was just showing w
>
> On Oct 25, 2005, at 5:11 PM, Joe Buck wrote:
> > I personally like the fact that gcc's behavior does not depend on
> > invisible characters
>
> All other things being equal, this is a nice design goal. I like it
> too. Should we break peoples otherwise portable code to have an
> imple
On Oct 25, 2005, at 5:40 PM, Joe Buck wrote:
1) a C++ comment
But case 1 is the nasty one, as users think they can put anything
in a comment. A backslash at the end is likely to be an accident,
since just starting the next line with a // is easy enough.
Be interesting to see the results of
On Oct 25, 2005, at 6:45 PM, Andrew Pinski wrote:
Does that really matter?
gcc is free to ignore users, existing code, porting problems from
other platforms and other C implementations, if we so choose. I'm
not used to writing such factors off wholesale. I tend to think a
balance is bet
>
> On Oct 25, 2005, at 6:45 PM, Andrew Pinski wrote:
> > Does that really matter?
>
> gcc is free to ignore users, existing code, porting problems from
> other platforms and other C implementations, if we so choose. I'm
> not used to writing such factors off wholesale. I tend to think a
On Oct 25, 2005, at 6:43 PM, Andrew Pinski wrote:
In fact the removal of the warning for comment cases was that exact
case
so ...
http://gcc.gnu.org/ml/gcc-patches/2001-04/msg00603.html
Curious, the backslash2.c testcase is now:
/* Test warnings for backslash-space-newline.
Source: Neil
On Oct 25, 2005, at 6:46 PM, Andrew Pinski wrote:
Hint, hint it was not an accident that this was done.
I am not unaware of the history. What we are addressing is, if this
was a mistake.
On Oct 25, 2005, at 6:50 PM, Andrew Pinski wrote:
but it is not portable code. That is my point.
I'm sorry, what word/phrase do you mean for code that compiles and
runs on a plethora of actual C++ implementations? Pretend I used
that word/phrase instead.
On Tue, Oct 25, 2005 at 06:45:55PM -0700, Mike Stump wrote:
> On Oct 25, 2005, at 5:11 PM, Joe Buck wrote:
> >I personally like the fact that gcc's behavior does not depend on
> >invisible characters
>
> All other things being equal, this is a nice design goal. I like it
> too. Should we bre
On Tue, Oct 25, 2005 at 07:07:08PM -0700, Mike Stump wrote:
> gcc is free to ignore users, existing code, porting problems from
> other platforms and other C implementations, if we so choose.
You still have not demonstrated that this is a real problem. If someone
is having a real problem, then
On Tue, Oct 25, 2005 at 06:51:45PM -0700, Mike Stump wrote:
> On Oct 25, 2005, at 5:40 PM, Joe Buck wrote:
> >1) a C++ comment
>
> >But case 1 is the nasty one, as users think they can put anything
> >in a comment. A backslash at the end is likely to be an accident,
> >since just starting the nex
You're forgetting something: GNU/Linux distros are built with
thousands of lines of patches to support new/different gcc behavior.
Thousands were added for the 2->3 transition, and thousands more for
3->4. Please don't claim that all upstream programs in all
distributions support gcc 3.4.4
On 10/26/05, Mike Stump <[EMAIL PROTECTED]> wrote:
>
> > That array ("str") in "tree_string" is of variable length and
> > its length is indicated by the "length" field. So technically
> > at least it should be marked with a GTY((length(...)))
> > marker.
>
> I don't believe it is necessary.
Just
1 - 100 of 104 matches
Mail list logo
