Trunk bootstrup failure with SMS flags

Hello, Recent trunk (-r174631) is broken when bootstrap it with SMS flags on ARM (configured with --with-arch=armv7-a). The last version of trunk that I'm aware of that passes bootsrap with SMS flags is 173786. Unfortunately I still can not put my finger on the cause for this fail and I begin to

Re: patch trunk: seek plugin also in a language specific directory when given a short name

On 6 June 2011 06:35, Basile Starynkevitch wrote: +slashes). When simply passing @option{-fplugin=@var{name}}, the plugin +is loaded from the @file{plugin} directory using if needed a front-end +specific subdirectory, so @option{-fplugin=@var{name}} is the same as +@option{-fplugin=`gcc -print-fil

Re: Strange git commit on master branch in gcc git mirror

On Sun, Jun 5, 2011 at 9:38 PM, Andreas Schwab wrote: > "H.J. Lu" writes: > >> http://gcc.gnu.org/git/?p=gcc.git;a=commit;h=6681e82c16913119b6a3ca0052efe9259d7377a9 >> >>  in git mit mirror, which isn't in svn gcc trunk. > > It's right here: > > http://gcc.gnu.org/viewcvs?limit_changes=0&view=rev

Re: Strange git commit on master branch in gcc git mirror

On 06/06/2011 11:47 AM, Richard Guenther wrote: Looks like an accident, modifying both trunk and branches/fortran-dev. But the git mirror splits it between the trunk and fortran-dev branches. Jerry, can you fix it up please? This has been fixed else thread (cf. "Strange commit from fortran-de

Re: Strange git commit on master branch in gcc git mirror

On Mon, Jun 6, 2011 at 12:14 PM, Tobias Burnus wrote: > On 06/06/2011 11:47 AM, Richard Guenther wrote: >>> >>> Looks like an accident, modifying both trunk and branches/fortran-dev. >>> But the git mirror splits it between the trunk and fortran-dev branches. >> >> Jerry, can you fix it up please?

Re: Strange git commit on master branch in gcc git mirror

On 06/06/2011 04:40 AM, Richard Guenther wrote: On Mon, Jun 6, 2011 at 12:14 PM, Tobias Burnus wrote: On 06/06/2011 11:47 AM, Richard Guenther wrote: Looks like an accident, modifying both trunk and branches/fortran-dev. But the git mirror splits it between the trunk and fortran-dev branches.

badly broken?!?

Hi, I just built Rev 174696 and if I run the following snippet in the bash shell of an x86_64-linux machine, today I don't get any meaningful output, in particular I don't get 'ok', instead '|+000|', which I have no idea what it means: #include int main() { std::cout << "ok\n"; } Can an

Re: using plugin and lto: problem linking c-pragma symbol

On Wed, 1 Jun 2011, Basile Starynkevitch wrote: > In my view, you are talking of the mythical > ModularGCC project, While there is a serious problem with a lack of reviewers reviewing modularization patches (such as Joern's patch to avoid target.h including tm.h, now in its fourth ping

Re: badly broken?!?

On Mon, 6 Jun 2011, Paolo Carlini wrote: I just built Rev 174696 and if I run the following snippet in the bash shell of an x86_64-linux machine, today I don't get any meaningful output, in particular I don't get 'ok', instead '|+000|', which I have no idea what it means: #include int main

Re: badly broken?!?

On 06/06/2011 03:10 PM, Marc Glisse wrote: 174683 here on linux x64 and everything is fine. Thanks. I built --disable-checking, let me see what happens without. Crazy, I have never seen something like this. Paolo.

Re: badly broken?!?

... sorry about the false alarm, a stupid typo of mine. Sorry again, Paolo.

Re: Strange git commit on master branch in gcc git mirror

On 06/06/2011 02:00 PM, jerry DeLisle wrote: This whole thing has me puzzled. The branch was created before go and libgo existed on trunk. Then I did a plain vanilla merge and got a whole bunch of tree conflicts just for those two directories. Then I attempted to manually resolve those tree co

Re: using plugin and lto: problem linking c-pragma symbol

On Mon, Jun 06, 2011 at 12:55:20PM +, Joseph S. Myers wrote: > On Wed, 1 Jun 2011, Basile Starynkevitch wrote: > > > In my view, you are talking of the mythical > > ModularGCC project, > Then, very probably, I Basile don't understand what is called "modularization", and "defining a stable AP

Re: using plugin and lto: problem linking c-pragma symbol

On Mon, 6 Jun 2011, Basile Starynkevitch wrote: > Then, I don't understand what modularization should be. My point is, imagine > we want to get rid of most global variable and state (and indeed, we I don't think this is what most people mean by modularization, although maybe some people want to

Re: using plugin and lto: problem linking c-pragma symbol

On 6/6/2011 10:33 AM, Joseph S. Myers wrote: Now, if we wanted to pack all the state of GCC inside some (very few, perhaps only one) variable, we would have to change most of the functions inside it. Perhaps the patch would be cosmetic, but it certainly would be very big. I can't see any reaso

[google] Merged google/integration -> google/main

This merge did not bring any code changes. The only patch merged from google/integration was the addition of -Wself-assign to c.opt that we already have in google/main. Diego.

Re: Disabling Secondary Tests

On 06/03/2011 11:14 AM, Lawrence Crowl wrote: > The PPH project has tests that compile two different ways, and > then compare the assembly. If either of the compiles fails, the > comparison will fail. We'd like to simply not run the comparison. > > We currently have: > > set have_errs [llength

Re: using plugin and lto: problem linking c-pragma symbol

On Mon, 06 Jun 2011 10:41:49 -0400 Robert Dewar wrote: > On 6/6/2011 10:33 AM, Joseph S. Myers wrote: > > >> Now, if we wanted to pack all the state of GCC inside some (very few, > >> perhaps only one) variable, we would have to change most of the functions > >> inside it. Perhaps the patch woul

Re: using plugin and lto: problem linking c-pragma symbol

On 6 June 2011 18:35, Basile Starynkevitch wrote: > > This is why I thought that "modularization" is a distant goal: in my > very naive opinion, it would mean removing important global data like > lang_hook, and I still believe that such a patch would be very big: one > can't remove that variable l

strict aliasing: cast from char[] or char *

Hi, Sorry, if it has been discussed before, I found a lot of information on strict aliasing in gcc, but nothing about this particular case. I'd like to code a custom container class: it has a char[] (or dynamically allocated "char *") for storage, putting an element is done with placement ne