2011-07-16 3 views
3

Je suis en train d'utiliser le pragma optimize GCC pour définir des optimisations globales dans mon code C. La version de GCC est 4.4.3 sur Ubuntu. L'idée de base est d'utiliser des niveaux d'optimisation spécifiques à la fonction.optimisation de code C en utilisant GCC#pragma optimiser

#pragma GCC optimize ("O3") 

Je reçois une erreur de compilation juste avant ma fonction principale dans mon code C

Mais quand je construis, j'obtiens l'erreur de compilation comme ci-dessous -

passrecovery.c: In function âmainâ: 
passrecovery.c:493: internal compiler error: Segmentation fault 
Please submit a full bug report, 
with preprocessed source if appropriate. 
See <file:///usr/share/doc/gcc-4.4/README.Bugs> for instructions. 
make: *** [all] Error 1 

J'ai vérifié le README Fichier .Bugs, mentionné dans l'erreur, mais n'a trouvé aucun indice à ce sujet.

est-#pragma optimize pris en charge dans GCC 4.4.3 ou non?

Si oui, qu'est-ce que je fais mal à utiliser ce pragma pour optimiser le code.

Toute autre directive GCC alternative pour l'optimisation du code pour la vitesse?

EDIT: J'ai même essayé #pragma GCC push_options puis #pragma GCC optimize ("O3") et à la fin du fichier #pragma GCC pop_options; même erreur.

Répondre

8

Un ICE (erreur interne du compilateur) conduisant à une erreur de segmentation est toujours un bogue dans le compilateur, C'est pourquoi il vous demande de signaler le bug. Vous ne devriez pas être en mesure de planter le compilateur avec un code source, valide ou invalide. (Il y a toutes sortes de choses qui peuvent arriver, le plus souvent impliquant un refus de compiler le code invalide, mais le crash n'en est pas un.)

Puisque GCC 4.6.1 est actuel, pourquoi ne pas envisager une mise à niveau vers un version plus récente de GCC (pas que 4.4.3 est tout ce vieux).

Avant de soumettre un rapport de bogue, vous devriez essayer de réduire votre reproduction. Tout à partir de la ligne 494 est probablement sans importance; avec de la chance, vous pouvez réduire le matériel entre les lignes 1 et 493 de près de 500 à 20 ou plus. Vous devriez certainement viser à le réduire autant que possible tout en préservant l'erreur. Avant de commencer à couper le code, conservez la version qui bloque le compilateur. Lorsque vous supprimez le code avec succès tout en préservant le crash, vérifiez chaque version successive dans votre VCS. (Vous êtes en utilisant un VCS, n'est-ce pas?) C'est une question rhétorique, si vous ne l'êtes pas, c'est le bon moment pour commencer, vous en avez besoin pour éviter de faire des changements qui ne peuvent être annulés. en-têtes non standard (ceux que vous avez écrits) avant d'éliminer les en-têtes standard. Essayez de vous débarrasser du plus d'en-têtes possible. Notez la demande de source pré-traitée - la réduction de code dont je parle réduit la taille de la source pré-traitée.

+0

Pour votre information, j'ai essayé d'utiliser cette directive sur optimize principale(). Cela semble être le problème. Cette directive fonctionne bien (Atleast compilé ok) si elle est utilisée sur une autre fonction (autre que main) – goldenmean

+0

@Would voudrait plus de globes oculaires pour passer en revue le code qui provoque cette situation. Seule la bibliothèque utilisée par ce code est -lcrypt (crypt.h), string.h, stdio.h, stdlib.h, ctype.h. – goldenmean

+0

@goldenmean: recommande d'essayer d'enlever '' et tout ce qui en dépend en premier ... enfin, deuxième. Vous devriez regarder ce qui est dans les 490 premières lignes et voir ce qui peut être supprimé en gros tout en préservant le crash. Vous pouvez d'abord utiliser les commentaires, puis les supprimer. Il y a une chance que vous ne puissiez déplacer aucune ligne de code.Mais c'est plutôt improbable. Et chaque ligne supprimée est un avantage. Que votre programme n'utilise aucun de vos en-têtes simplifie la vie. –

4

Pour la dernière question: vous pouvez le mettre dans une unité de compilation séparée et utilisez le commutateur de ligne de commande: -O3